Correction - [Fwd: Re: Back Annotation Proposal(s)]


Subject: Correction - [Fwd: Re: Back Annotation Proposal(s)]
From: Steve Grout (grouts@flash.net)
Date: Sun Sep 09 2001 - 12:02:03 PDT


My note To Keven Cameron on backannotatinon got inadvertently sent
before I was done writing it. Here's the rest of my comments
to Keven as BA task leader. Sorry for the confusion!

-------- Corrected Message --------
From: Steve Grout <grouts@flash.net>
Organization: Design Verification & CAD Consultant
To: Kevin Cameron x3251 <Kevin.Cameron@nsc.com>
CC: Verilog-AMS Reflector <verilog-ams@eda.org>
References: <3B817A18.A03BA2A2@nsc.com>
Kevin -

Let me first give you, as the group leader on backannotation, my
support for the BA package you posted for our review.
 - I do support the approach you detailed in that package as
an update of the current practice. The SPEF/SDF parasitics RC/RCL
update back into the block netlist hierarchy I believe, through
my personal study, can be extended for a couple more technology
generations (down around 0.13u and be successfully used on many
FPGA and ASIC chip designs.)

Later, then, once your BA proposal is considered and adopted,
I would urge we move on to add some or all of the below requirements
needed for HDL for VDSM technology into the scope of this committee/group.

 - There are, for even sub-0.25u designs and/or higher
performance designs, needs for providing:

   + early forcasting of the delay, drive, and loading on
     key data and control paths - nets/wires. The current
     SDF/SPEF annotate paradigm doesn't easily allow designers
     to look at the HDL and the SDF/SPEF data files and
     describe/predict what their design performance/timing
     will be. Yes, one can run the simulators and STA,
     but that doesn't allow one study how the emerging design
     in HDL LOOKS in order to understand how it will perform.

   + more complex nets than just simple fan-out and fan-out
     between block pins in the design hierarchy
     (in order to have the same net details in the HDL
      as the actual later physical design.) E.g, some part of
     the delay is properly a part of local wiring within
     the upper level, and some other part properly a part
     instantiating lower-level blocks in the hierarchy.
     o In a nutshell, the specific wiring of a net needs
        to include specific net-segments (aka 'subnets'),
        vias (aka 'net intersect points' ), local net hierarchy
        (nets often fan-out into multiple segments in order to
        carry load or provide other transmission properties),
        directed coupling to other netsegments (capacitive and inductive)
        regardless if the netsegments are in the same net or in
        some other net.
     o There are a LOT of designers who really DO do early detailed
        net design forecasting (e.g., analog designers, data-path designers,
        oscillator and RF designers, power and power-moding designers, etc.)
        and they don't/cant' let the later floorplanner/placer/router
        and extractor system determine what their net/netsegment
        characteristics are. Those are some of the designers we want
        Verilog-AMS to provide design description support for, right?

   + Provide for fully accurate description within the HDL
     of Signal Integrity 'threat' net couplings,
     including both C and mutual types of coupling effects.

   + Provide a means within the HDL to describe the actual
     nets, their delays, and their parasitic backannotated
     R, L, C, M, as a direct part of the HDL hierarchical
     description, including separating the parasitics,
     delays, loading, and drive effects within the hierarchy
     so that we can specifically deal with the
     design-for-parasitics needs within a block definition
     (aka 'master'), within its instances, and later within
     its occurrences.

   + Providing within the HDL descriptive means for including
     'rate of change' of the process technology and manufacturing
     geometry variations on those same specific detailed
     parasitics, delays, drive, and loading effects.

In my view, these are the key mechanisms that will be needed in
HDL for the coming technologies in order to support what has become
called 'timing-driven design' and 'performance-driven design'.

But back to the present. I support your BA package and will
be glad to work to get it adopted.

Regards,

-- 
--Steve Grout
  Design Verification, CAD Methodology/R&D, Manager, Individual Contributor -
  Design Verification, CAD System, Database, Flows, Tools, Integration,
  and Support for both Digital and Analog/Mixed-Signal Design Teams.
  101 Kenneil Court
  Apex, NC 27502
  Phone: 919-303-5066
  email: grouts@flash.net
  http://www.flash.net/~sgrout/Personal/resume2001.txt (or doc,rtf,pdf)

---------------------- > > Steve and Sri, > > In-place back-annotation (like SDF) for Verilog-A[MS] requires > several thing to work. Since current tools generate SPF/SPEF > (spice netlist), a mechanism to directly read that format is > desirable (since the files can be very large). A method within > Verilog-AMS is required for rewiring the design using the > parasitic and routing data from the SPF, and the semantics of > A/D insertion should work correctly (i.e. model the circuit > most accurately) with the "rewired" design. > > Reading SPF is covered by the "Filters for foreign languages" > proposal - > > http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/0017/index.html > > The rewiring syntax is covered by this proposal - > > http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/misc/back_ann.pdf > > A/D insertion semantics in the rewired design require that disciplines > can be "process bound" rather than port bound - > > http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/0002/fllwup-2.html > > - which implies that A/D conversion modules are placed on the low side > of ports - > > http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/0003/index.html > > Using "Filters for foreign languages" proposal does not require us to > specify any exact translation for spice netlist, and allows vendors to > recognize their own data formats. Adding the "process bound" attribute > to a discipline avoids having to change any existing semantics. > > Regards, > Kev. > > -- > National Semiconductor > 2900 Semiconductor Drive, Mail Stop A1-520, Santa Clara, CA 95052-8090



This archive was generated by hypermail 2b28 : Sun Sep 09 2001 - 19:12:26 PDT