From: Abbie Kendall <Abbie@smtpmail.orcad.com>
>John, it's heartening to know that the Editor-in-Chief of EE Times, Richard
>Wallace, is such a sensitive guy! By the way, have you received any
>response from Joe Costello about this dog food drive you're doing for him?
>
> - Abbie Kendall
> OrCAD
Hey, Abbie, you know those journalist types -- if they ain't airing
someone's dirty laundry, they're waxing philosophic about how cute *their*
junkyard dog is! :^) Concerning Joe, I called him the day I started the
"drive"; his staff (before I got to talk to him) plus Joe himself all
heartily laughed at it. Joe & I have known each other for years; he knows
I won't pass up an opportunity to have some "fun" (especially at his
expense) if given one!
- John Cooley
the ESNUG guy
( ESNUG 226 Item 1 ) ---------------------------------------------- [8/95]
Subject: (ESNUG 225 #1) Synopsys Point-To-Point Timing Exceptions
>If you have a design with point-to-point timing exceptions (i.e. multicycle
>paths, false paths), these exceptions become invisible to the timing
>analyzer when the design is incorporated into the next higher level of
>hierarchy. ... I have a design in which several lower level modules contain
>literally hundreds of point to point exceptions. After I carefully set
>these up & compile the block until I get a clean timing report, I set
>dont_touch on the module and then work on the next level up. But the timing
>analyzer does not take the subdesign's exceptions into account!!!
>Hence, I get ridiculous compile times & a lot of bogus timing violations.
From: myhui@thlayli.newport-beach.ca.us (Michael M.Y. Hui)
John,
I always apply my multicycle path commands at the top level only, using the
full hierarchical instance name. I do this because when I use "characterize",
I do it also at the top level, and obviously "characterize" *requires* that
the multicycle paths be visible to it. This is the only way it can set
sensible timing constraints for the block you're characterizing for,
especially for those ports that are fed by slow paths that have been
"corrected" by the multicycle path command.
After you characterize (from the top level), and before you do a re-compile
or incremental compile, try displaying the timing constraints, and look for
the pins that should belong to a multicycle path. Check to make sure that
those pins have sensible timing constraints (i.e. the limit should be more
than one clock period.)
Generally, as a safety check, I always check the timing constraints before
a compile anyways just to minimize wasting time on a badly set up compile.
- Michael M.Y. Hui
---- ---- ---- ---- ---- ----
From: Karl.Pfalzer@Eng.Sun.COM (Karl Pfalzer)
John, There are 2 "clever" ways of dealing with this issue.
There is a reason why constraints would not automatically propagate up a
design hierarchy: exceptions are design attributes, visible at the current
top-level design. However, when this design is instantiated (now a "cell" in
Synopsys jargon), it may not be the designer's intent to have every instance
(cell) of this design have these exceptions --- as would occur if (previous)
design constraints automatically propagated up a hierarchy and took affect
in every instance (cell/reference) in this design. (The user implies this
"pitfall" in his message, too.)
Anyway, one way of dealing w/ propagating constraints:
1) In the constraint file of the leaf/lowest level module/design where the
exceptions are required write them such that they propagate based upon
whether the current level design is this module or contains a reference
to it (cell).
For example, suppose the lowest level design is called "SyncFF" and you
wanted to specify an exception (false-path) through porrt "D" to a
register QInt_reg. A dc_shell script would be written:
foreach(ThisDesign,find(design,current_design)) {}
if (ThisDesign == "SyncFF") {
set_false_path -from find(port,D) -to find(cell,QInt_reg);}
else { /**2**/
/** cells/instances which reference SyncFF and set exception
** through their top-level port (determined dynamically below) **/
filter(find(cell,-hier),"@ref_name == SyncFF") > /dev/null; /**1**/
foreach(i,dc_shell_status) {
j = find(net,all_connected(find(pin,i + "/D")));
while (1) {
find(port,j) > /dev/null;
if (dc_shell_status != {}) {
break;
}
j = find(net,all_connected(find(pin,j)));
}
set_false_path -from find(port,j) -to find(cell,i +"/QInt_reg");
}
}
Obviously, when compiling SyncFF, the above script is included. However,
when derived/enclosing modules are also compiled, be sure to include the
above script too. By always including lower level include scripts in
derived/enclosing design scripts this is easily accomplished.
The above works fine for primary input to register paths. However, it
also applies to ALL instances/cells of SyncFF (which may not be desired).
Of course, this could be modified by "subtracting" cells from /**1**/
above.
In cases where you have a register to register path, life becomes a little
more difficult. Why ?? Because as you propagate up the hierarchy, until
the path exception is fully enclosed, the path source will be a port.
Once at levels which fully enclose the path, the source is a cell/reg.
The method above in 1) can still be used, however you will need to add an
additional "else if/else" clause at /**2**/.
2) The 2nd method which is the most general is using "path segmentation" (try
SolvIt for details). The method uses set_input/output_delay constraints
on PINS at various levels of the design hierarchy. This also enforces
& eases time budgeting along multicycle paths. By segmenting a path, you
create new startpoint and endpoints and effectively break the normal
[port, reg, clock] <--> [port, reg, clock ] timing paths. However, the
advantage is "significant" when propagating exceptions up a deep design
hierarchy, so you only need to prepend cell names on the pins as you move
up the hierarchy (to move the constraints). The budget delays (arguments
to set_input/output_delays) would likely change to. (report_design will
report on such path segmentation).
- Karl Pfalzer
Sun Microsystems
( ESNUG 226 Item 2 ) ---------------------------------------------- [8/95]
From: michael@canada.lsil.com (Michael Smith)
Subject: (ESNUG 225 #3) Surprising Answer To A Personal Metastability Quest
John: For discussion purposes, I'm duplicating Bob's circuit below:
> Dual-Stage Design:
> _____ ------
> / \--------|D Q|
> ------ ------ SYNC | | | |
> ASYNC ----|D Q|----|D Q|-------| Blob | | | Target
> | | | | / of \ ---|> | Flip-Flop #1
> | | | | | logic | | ------
> --|> | --|> | \_ | | ------
> | ------ | ------ \ |------|D Q|
> | | \____/ | | |
> | | | | | Target
> 40MHZ -------------------------------------------|> | Flip-Flop #2
> ------
>
>
> Single-Stage Design:
> _____ ------
> / \--------|D Q|
> ------ SYNC | | | |
> ASYNC ----|D Q|--------| Blob | | | Target
> | | / of \ ---|> | Flip-Flop #1
> | | | logic | | ------
> --|> | \_ | | ------
> | ------ \ |------|D Q|
> | \____/ | | |
> | | | | Target
> 20MHZ ----------------------------------|> | Flip-Flop #2
> ------
In his discussion on why a single-stage design is a better solution, Bob does
say that the delays in the "Blob of logic" should be made as small as
possible. The value of Tblob, the propogation delay through the "Blob of
logic", will lower the value of Tr which may make the dual-stage design more
attractive. There are a few additional points that also should be considered.
In the dual-stage design, if the output from the first flip-flop goes
metastable, there is only a single signal in the design that is metastable.
In the second design, the entire "Blob of logic" is potentially metastable,
-this will effect your power consumption (although marginally.) A bigger
concern is that in the single-stage design, there is a potentially metastable
signal that is being sampled by multiple flip-flops; this makes design
changes and analysis much more difficult. For example, when determining the
value of Tr, the clocking scheme and clock skew between the two flip-flops,
as well as routing delays and differences in the logic paths may have to be
considered. This might lead to problems such as shown in the following:
T1 T2 T3 T4
Clock: ____----____----_____----____----____
ASYNC: ___________--------------------------
SYNC: ____________xxxxxxx__---------------- <- Metstable
D1: _________________xxxxxxx__----------- <- Metstable
D2: ______________xxxxxxx__-------------- <- Metstable
Q1: _____________________xxxxxxxx-------- <- Unknown Value
Q2: _____________________________--------
In this figure, 'D1' and 'Q1' are the D/Q signals for the first target
flip-flop, while 'D2' and 'Q2' are the D/Q signals for the second target
flip-flop. I'm assuming that the "Blob of logic" is just a propogation
delay for this example. I'm also assuming that the first flip-flop settles
to '0' after going metastable, and then properly samples the '1' input on
the subsequent clock edge (T3).
With this example, the two outputs, Q1 and Q2 are different for clock period
T3. Remember that for real gates, 'x' doesn't exist, there will be a '1' or
a '0' on Q1. Some hand-shake or control schemes will fail at this point.
However, if a dual clock stage is used with half the clock period:
T1 T2 T3 T4
Clock: _--__--__--__--__--__--__--__--__--__
ASYNC: ___________--------------------------
ASYNC': _____________xxxx-------------------- <- Metastable
SYNC: _________________xxxx---------------- <- Unknown Value
D1: ____________________xxxx------------- <- Unknown Value
D2: _________________xxxx---------------- <- Unknown Value
Q1: _____________________xxxx------------ <- Unknown Value
Q2: _____________________xxxx------------ <- Unknown Value
In this second case, ASYNC' is the node between the two synchronization
flip-flops. For this scenario, the potentially metastable signal is only
being sampled by a single flip-flop; the output of this flip-flop is a
stable, albeit an unknown value (of course, it is possible for the second
flip-flop to also go metastable if the settling time is sufficiently large).
The result is that Q1 and Q2, although having a value of 'x', they still
have the same value throughout this example. This reduces the number of
possible failure modes of your design, which will make it more robust.
- Michael Smith
LSI Logic (Canada)
( ESNUG 226 Item 3 ) ---------------------------------------------- [8/95]
Subject: (ESNUG 225 #4) John Cooley, The Idiot Editor of ESNUG
Blithering John Cooley edited hill@synnet.com (Shannon Hill) to read:
>I'm always surprised by how long it takes to get moderately complicated
>scripting recipes working correctly. To prove my point, I'll ask ESNUG
>readers: "How long does it take you to figure out why the following line
>has a syntax error in dc_shell script-land??"
>
> dc_shell>dat_clock_pin = find(pin,*MEM*DAT*REG*/CK, -hierarchy )
sgupta2@mipos2.intel.com (Sravasti Gupta) then rightly replies:
>Maybe there is no syntax error in the command? It seems to be correct to me
>(in which case it would take forever for it to be detected)!
>
> - Sravasti Gupta
> Intel
And Sravasti's right! The reason why is because the orginal "trick"
dc_shell line was supposed to read:
> dc_shell>/* dat_clock_pin = find(pin,*MEM*DAT*REG*/CK, -hierarchy ) */
But, like the simple sheep farmer that I am, I STUPIDLY thought the "/*" and
"*/" were put in accidentally! Aaaaargh! Anyway, here it is in its correct
form with my humblest apologies.
- John Cooley
the occassionally coherant ESNUG guy
( ESNUG 226 Item 4 ) ---------------------------------------------- [8/95]
From: jms@vlsi9.gsfc.nasa.gov (Jeff Solomon)
Subject: Funky Toshiba/VSS VHDL Gate Simulation Methodology
Hey John,
This is Jeff Solomon, your favorite VHDL designer from the SNUG contest. :^)
I am currently taking a VHDL design through Synopsys 3.3b and to Toshiba's
0.7 micron tc170g gate array line. I have a question about their tool
pipeline from synthesis to gate level simulation. To perform gate level
simulation with Toshiba the following steps must be taken:
1. Synthesize gates
2. Write out VHDL netlist
3. Translate VHDL netlist to Toshiba's TDL netlist with Toshiba's vhdl2tdl
application program.
4. Run Toshiba's TDC (Toshiba Delay Calculator) to estimate all delays and
generate sdf file.
5. Use original VHDL netlist and sdf file just generated to simulate in VSS.
I have a few problems with this methodology:
1. Why can't I simply write out the VHDL netlist and the SDF file directly
from dc_shell and simulate that in VSS? It's a lot less steps.
If you say that I can't do that because TDC will give more accurate
delays than Synopsys's own timing analyzer then why did I bother
to set the constraints in Synopsys land if they are going to be
inacurrate? Stated a different way, if Synopsys timing analysis is
good enough for synthesis, why isn't it good enough for simulation?
Can you imagine the iterative process that a designer would have
to go through if the Synopsys timing analysis and the Toshiba
timing analysis were different? Even worse, since they probably
use two different algorithms, the results they return if they
are different will probably not be linear. That is, some delays
will be reported as faster and others as slower, try tweaking that!
(BTW, I have tried to use the Synopsys sdf file in VSS and it
just spews about primitives that couldn't be found. The least they
could do is make both sdf files work and tell you to try both)
2. TDC only allows the specification of a top level die size to estimate
the wire load. This means that TDC takes your whole netlist and
estimates all the wire lengths with no floorplanning information.
In Synopsys land, since you the designer have some idea what the
floor plan will look like, you can assign different size wire loads
to different sections to get a more accurate wire load estimation.
In TDC it seems that half the net will be underestimated and half
will be overestimated. Even if TDC makes guesses about floorplanning
bases on the explicit hierarchy, they might not be the right guesses.
John, I hope that I have explained my issues sucessfully. Do all vendors
have the same tool flow as Toshiba? Do you agree with my concerns?
- Jeff Solomon
NASA, Goddard
( ESNUG 226 Networking Section ) ---------------------------------- [8/95]
Waltham, MA, Mentor Graphics seeks Verilog/AutoLogic II Apps. Engr. to
support Verilog synthesis. Please, No Headhunters. "tom_hill@mentorg.com"
Andover, MA; Santa Clara, CA; Austin, TX; + UK & France: i-Logix Inc. seeks
Apps. Engrs. w/ Verilog/VHDL/Synopsys. NO AGENCIES. "charlie@ilogix.com
|
|
