Verilog-A[MS] Back Annotation

SDF allows the back annotation of timing data into a digital simulation without disturbing the namespace of the design. For Verilog-A and Verilog-D to be combined in Verilog-AMS with back-annotation to all parts of the simulation a similar mechanism is necessary for Verilog-A. Back annotation in an analog simulator requires the inclusion of extra parasitic components - usually from circuit extraction - and those components can be any mix of passive and active devices which will need to be include in simulation the same way as those components found in the original Verilog-A netlist, therefore the best description for the components being added through back annotation is Verilog-A[MS].

SDF back-annotation results in virtual components being inserted into the digital simulator kernel's internal representation of the circuit at the output ports of affected blocks, which will add extra delay to propagating signals. In a similar manner the analog simulator needs to redirect the topside and bottom-side of ports of modules into an appropriate place in the netlist describing the parasitics. That is basically a modified elaboration, however there may be additional of cross-coupling between modules that will not neccesarily go through ports or declared OOMRs, but connect to module internal nodes directly. An additional problem is that although the Verilog-AMS module may have a single port, there may be multiple "ports" in the physical layout.

Instantiating the components for back annotation only requires that it is possible to add extra top level modules containing the circuitry being added (described as Verilog-A[MS]). Specific connections to module internal nodes can be made using OOMRs for cross-coupling, therefore the only missing functionality is a mechanism for the port redirection. Redirecting the top-side of a port connection from the context of a child is necessary because Verilog supports unnamed nets, also it may be a requirement that if one connection is redirected then all connections should be explicitly redirected to avoid errors. Redirecting a module's ports in the module itself is probably redundant functionality. The mechanism needs to be module bound so that the back-annotated block can be exported into other design hierarchies.


There is a previously proposed syntax for accessing module ports and nodes for setting disciplines, it is re-used here for redirecting OOMRs:

          <redirect block>            ::= redict {<redirect>;} endredirect
          <redirect>                  ::= <ref local> [^]-> <ref remote>[,<ref remote>}
          <ref local>                 ::= <instance signal ref>
          <ref remote>                ::= <instance signal ref>
          <instance signal ref>       ::= [<instance path>:](<signal name>|<OOMR>)
          <OOMR>                      ::= <instance path>.<signal name>
              module back_ann;
                   electrical vdd,vss;
                      top.block.sig1 -> spf0.block.sig1;
                      top.block.sig1 ^-> spf0.sig1;
                      top.block.sig2 -> spf0.block.sig2a,spf0.block.sig2b;
                      top:power.vdd -> vdd;
                 spf spf0 (vdd,vss); // instantiate parasitics


In the case where multiple signals are the target of the redirect, they are "shorted" together for simulation.

Redirect blocks should be processed bottom up in the design hierarchy so that redirects in exported designs can be overriden.

Connect module insertion will be calculated using the structure of the final net, not the pre-redirect net.

SDF/Specify Interoperability

In purely digital blocks SDF works as normal. When SDF back-annotation is applied to an analog block it should be ignored. SDF normally refers to resolved digital signal values, therefore in the case of a digital net with SDF back-annotation driving a mixed signal net the driver used for connect modules is the ouptut of the SDF virtual component (see above).


While intended for back-annotation of Verilog-A, this mechanism would also support buffer insertion and other place-and-route tweaks in purely digital flows.

-- KevinCameron - 28 Mar 2008

Topic revision: r1 - 2008-03-28 - 20:37:59 - KevinCameron
Copyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback