RE: [sv-dc] Examples of how back-annotated parasitics would be modeled without resolutions functions tied to nets

Kevin,
  I just don't know enough to have a strong opinion on type conversion and late binding. If late binding is the only way to type conversion, perhaps it's worth considering. Is this true?

Kindest Regards,
Jim Lear
Cirrus Logic
(512) 851-4612
(512) 293-7248 (mobile)

From: Kevin Cameron [mailto:edaorg@v-ms.com]
Sent: Friday, February 11, 2011 12:23 PM
To: Lear, Jim
Cc: 'sv-dc@eda.org'
Subject: Re: [sv-dc] Examples of how back-annotated parasitics would be modeled without resolutions functions tied to nets

In this case the drivers are not necessarily heterogeneous but the driver and receiver types definitely differ.

My approach would be to look for a conversion function (or module) that converts logic to Thev_t and another for Thev_t to logic, and resolve in Thev_t.

The general approach for multitype resolution is -

  convert drivers to a common type that has a resolution function
  convert resolved value back to receiver values

If you have a pile of type conversion functions and resolution functions/modules you can work out how to do this implicitly by knowing which conversions are lossless and lossy, i.e. when converting the drivers you want to use lossless conversion if possible, and when converting back to receivers lossy is allowed.

Disciplines come in when you want to dictate rules rather than infer them, i.e. if you have multiple logic drivers on a net and a Thev_t receiver, you may want to resolve the logic before converting to Thev_t, rather than converting each logic driver to Thev_t - the former method may produce Xs which are hard to handle but it is less computationally intensive.

Kev.

On 02/11/2011 04:19 AM, Lear, Jim wrote:
Kevin, I am completely ignorant when it comes to digital back annotation. Your email seems to be suggesting resolution functions with heterogeneous drivers. Is this correct?

Kindest Regards,
Jim Lear
Cirrus Logic
(512) 851-4612
(512) 293-7248 (mobile)

From: Kevin Cameron [mailto:edaorg@v-ms.com]
Sent: Thursday, February 10, 2011 5:38 PM
To: Lear, Jim
Cc: 'sv-dc@eda.org<mailto:sv-dc@eda.org>'
Subject: Re: [sv-dc] Examples of how back-annotated parasitics would be modeled without resolutions functions tied to nets

Jim,

I'm not sure your usage model is clear. The back-annotation proposal I posted is intended for use where the flow is is something like:

UPF/CPF + RTL -> Synthesis -> pre-P+R Verilog (maybe with power connectivity and assertions for power verification)
pre-P+R -> Place and Route -> layout -> extraction -> back-annotation data

The idea is the "back-annotation data" is just the wiring/parasitcs for the cell level description in the pre-P+R Verilog, it could use your Thevenin models or an AMS spice level description.

The cell level description should work with or without the back-annotation, i.e. if the cells are in regular verilog then the drivers and receivers will be of type logic, if back-annotated then they the drivers will be of type logic but their receivers of type Thev_t, and drivers of type Thev_t on the other end of the wiring will have logic receivers. It requires late binding of the resolution scheme because the cells cannot know how they are being connected a priori.

Are you envisaging something different?

Note: the idea with the back-annotation proposal is to allow users/vendors to do back-annotation in whatever way they see fit - assuming that multiple cell views are available and different levels of accuracy in the back-annotation should be supported. You could also use the methodology for ECOs.

Kev

On 02/10/2011 12:45 PM, Lear, Jim wrote:
I've received enough calls and emails that my previous communications haven't been clear. Here's are three examples of back annotation methods that Scott and I went through, and hopefully it will clear up some confusion. In each example, the only language features needed are resolution functions tied to a type, and user-defined types on ports. Feel free to call or email me if there are any questions.

In modeling parasitic resistance between three devices, a distributed parasitic resistance provided by the drives will solve the problem very accurately. For example, consider this Thevenin driver module and interconnect:

module driver #(parameter rParasitic=0.0) (Thev_t w1);

  initial w1 <= {internalDriverVoltage, inernalDriverResistance+rParasitic);

endmodule

module BackAnnotatedNetlist ();

  parameter rParasitic1 = 1.2e3;

 parameter rParasitic2 = 1.5e3;

  parameter rParasitic2 = 1.8e3;

  Thev_t interconnectNet;

  driver #(rParasitic1) inst1(interconnectNet);

  driver #(rParasitic2) inst2(interconnectNet);

  driver #(rParasitic3) inst3(interconnectNet);

endmodule

This is a trivial case and the accuracy degrades for more interconnect branches. For more devices, the branches of the wires get complicated. In this case, actual discrete resistances and/or capacitors can be used. There's probably a limit to how many discrete devices one would be able to use for a net, but that's difficult to determine without a lot of investigation. Here is an example of such an netlist in which three driver devices and two resistors are connected in a Daisy chain (one resistance between driver 1 and driver 2, and a second resistor between driver 2 and driver 3). The resistors are similar to the discrete resistor example I provided in VHDL. Other wiring parasitic topologies are implemented in similar ways.

module BackAnnotatedNetlist ();

  parameter rParasitic1 = 1.2e3;

  parameter rParasitic2 = 1.5e3;

  Thev_t interconnectBranch1, interconnectBranch2, interconnectBranch3;

  driver #(0) inst1(interconnectBranch1);

  resistor #(rParasitic1) branch1(interconnectBranch1, interconnectBranch2);

  driver #(0) inst2(interconnectBranch2);

  resistor #(rParasitc2) branch2(interconnectBranch2, interconnectBranch3);

  driver #(0) inst3(interconnectBranch3);

endmodule

Finally, to solve Achim's desire to have a module for the interconnect, we simply instantiate one specific to an interconnect. This interconnect module can also take in heterogeneous driver types. However, it can not always be implemented in a hierarchically accurate netlist. It must be a flat netlist. This may be a problem in some cases. Maybe someone can comment if this is a concern.

module BackAnnotatedNetlist ();

  parameter rParasitic1 = 1.2e3;

  parameter rParasitic2 = 1.5e3;

  Thev_t interconnectBranch1, interconnectBranch2, interconnectBranch3;

  driver #(0) inst1(interconnectBranch1);

  driver #(0) inst2(interconnectBranch2);

  driver #(0) inst3(interconnectBranch3);

  interconnectModel123 #(rParasitic1, rParasitic2) interconnect(interconnectBranch1, interconnectBranch2, interconnectBranch3);

endmodule

Kindest Regards,
Jim Lear
Cirrus Logic
(512) 851-4612
(512) 293-7248 (mobile)

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.