Subject: Back Annotation (again)
From: Kevin Cameron (dkc@galaxy.nsc.com)
Date: Tue Jan 29 2002 - 16:37:05 PST
Previous Postings:
http://www.eda.org/verilog-ams/hm/0143.html
http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/misc/back_ann.pdf
http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/0017/index.html
It is possible to say "there will be no back-annotation in Verilog-AMS", and just
let users re-netlist however they want to achieve the desired result, but that
has various associated data-management and coherency problems.
Verilog-A back-annotation is (IMO) required for SoC flows and interoperability
with SDF is required for Verilog-AMS.
My preferred approach is to allow specification of components for back-annotation
in Verilog-AMS, and provide a "re-wiring" mechanism in the language for changing
the connectivity at the ports of the instances to attach the back-annotated components.
That is a general purpose mechanism that is equally applicable to digital verilog for
buffer insertion and other ECO type design changes.
The argument that it is more expensive in processing than re-netlisting seems
specious to me as you should end up with the same number of components in the
simulation whichever way you read the netlists, and therfore the run-time
footprint is likely to be identical for a modern compiled-code simulator.
While generating back-annotation in Verilog-A[MS] might be a [long term]
desirable goal, it isn't yet a standard for back-annotation. Also, I don't want to
have to synchronize multiple versions of the same data (i.e. SPF,Verilog-A,
Milkyway etc.), so I'd still prefer to have a mechanism like that in the "filters"
proposal that lets the simulator read the raw data directly and avoids having
to do seperate external translation and copying of (very) large files.
NB: If folks don't like the existing proposals for some reason, I'll be happy to
rework them.
Regards,
Kev.
This archive was generated by hypermail 2b28 : Tue Jan 29 2002 - 16:31:19 PST