More info from class NetlistCrossReference

sekigawa

@Matthias I am trying to develop a customized resistor extractor for LSV.
So far, so good.
However, during the development process, I realized that it would be helpful to have such a function in the class NetlistCrossReference.

The dummy code is as below.

def ExamineCrossReference( tol_rel, dataXRef )
  devHash = Hash.new()
  dataXRef.each_circuit_pair do |cir|
    dataXRef.each_device_pair(cir) do |dev|
      devF  = dev.first   # usually from the layout
      devS  = dev.second  # usually from the reference net
      if devF != nil and devS != nil # devF will be nil if "unmatched"
        nameF = devF.expanded_name
        nameS = devS.expanded_name
        devHash[ [nameF, nameS] ] = [devF, devS]
      end

      # <<< Future Request >>> --------------------------------------------------------------------
      #
      # If the cause of the discrepancy is due to parameter values only, including tolerances,
      # I want to investigate the details with a method like...
      #   NetlistCrossReference::each_unmatched_parameter_pair().
      #                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      # Suppose a case of resistor, where Rext(layout)=44.278[Ω] and Rref(reference)=43.0[Ω],
      # then Abs.diff=1.278[Ω] and Rel.diff=2.973[%].
      # If the relative tolerance is 3.0[%], Rext and Rref match but do not if it is 2.5[%].
      #--------------------------------------------------------------------------------------------
      dataXRef.each_unmatched_parameter_pair(dev) do |par|
        if par != nil
          id   = par.id      # like RBA::DeviceClassResistor::PARAM_R
          valF = par.first   # first unmatched parameter value  like "44.278[Ω]"
          valS = par.second  # second unmatched parameter value  like "43.0[Ω]"
          CheckWhyThisParameterUnmatched( dev, id, tol_rel, valF, valS )
        end
      end # par
    end # dev
  end # cir
end

The attached PPT document and associated ZIP file capture the whole story.

Thanks
Kazzz-S

Matthias

Hello @kazzz,

specifically the tolerances are not available when you load a LVS database. Recording the tolerances is kind of difficult as the compare operator can be a complex class beyond simple numeric tolerances.

The problem with device mismatching is that the effect is depending on the topology. If for a device the netlist position is uniquely defined by the nets involved, the device is force-matched, even if parameters do not match. In that case, a device mismatch is reported, but both devices are known.

The more common case is that a mismatching device inhibits further analysis of the net topology (the device parameters are part of the net signature). So usually mismatching devices lead to net mismatches and in consequence non-matching devices. In that case, one of the devices is nil.

For your problem I'd suggest a modified procedure: define a 100% relative tolerance for the devices. This will make all devices match in the first place (provided the net topology is correct). Then do the parameter matching in the second step, reading the LVS databases and comparing the individual parameters to your liking.

Do you think this is a feasible way to go?

Matthias

dick_freebird

The way I see it, this is about making the parameter comparison
for a topoloy-matched device incorporate an "error band" rather
than demanding strict numerical equality.

Now if PCell:symbol properties 1:1 enforces that matchup,
then there's nothing for such a "toleranced" param compare
to do. But that's the point of checking, isn't it? The "if"?

Seems to me that the param-compare bit could have a
modal "breakout" which simply re-looks-at the values it
was just presented during the normal flow, and barfs out
a param-mismatch complaint when it finds one, to a
completely separate file if that makes things easier.
And if nobody sets that flag, nobody complains.

sekigawa

Hello @Matthias,

Thanks for your explanations and suggestions.

For your problem I'd suggest a modified procedure: define a 100% relative tolerance for the devices. This will make all devices match in the first place (provided the net topology is correct). Then do the parameter matching in the second step, reading the LVS databases and comparing the individual parameters to your liking.

Do you think this is a feasible way to go?

Yes, this seems to be a feasible solution.
I'll try it.

Warm regards,
Kazzz-S

sekigawa

Hello @Matthias,

The proposed two-step approach works very well.
Thanks a lot.

I've attached a modified PPT document for my future reference.

Best regards,
Kazzz-S

Matthias

Very good. I'm in awe of the documentation you're writing ... I can only recommend that for other readers of that post!

Thanks a lot!

Matthias