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, and is
believed to be clean.