For those of you going to next week's Wescon, I'll be giving a talk on
"Zen & the Art of Hierarchically Compiling in Synopsys" plus leading
a panel discussion on "Life in the Synthesis Jungle" next Tuesday in the
Idea '93 conference. To save on air fare, I'll be flying in on Saturday
night and cutting out back to Boston Wednesday morning. There are a few
friends I plan to meet while there, but if any of the California contingent
of ESNUG or fellow out-of-towners want to schedule a get together to talk
shop, go to dinner or play tourist - drop me an e-mail before Saturday!
- John Cooley
the ESNUG guy
( ESNUG 152 Item 1 ) ---------------------------------------------- [9/93]
Subject: (ESNUG 151 #3) "Generating Both Pos & Neg Edge Triggered FF's"
> The following VHDL code causes 3.0b with default settings to use a positive
> edge triggered flip/flop with an inverter on the clock line:
>
> P2:process begin
> wait until clk = '0' and clk'event;
> if (Reset = '0') then
> Q <= '0';
> elsif (Load = '1' ) then
> Q <= D;
> end if;
> end process;
>
> Other parts of my design use the positive edge of clock. Can someone
> provide me with the commands required so that Synopsys will instantiate
> both pos _and_ neg edge FF's as required without placing inverters on the
> clock line? I can find no information on this in their documentation and
> haven't gotten an answer back from them yet.
From: manley@optilink.com (Dave Manley)
In the Design Compiler Reference Manual Supplement, Version 3.0b, June 1993
on page 1-3 there is a section entitled: Mapping to Negative Edge Flip-flops.
You need to set the dc_shell environment variable:
"neg_edge_flip_flop_opt = 1"
Also a Boolean attribute for designs or cell instances is mentioned:
"desired_flip_flop_clock_phase {true, false}"
Quoting the manual:
"If you set this attribute to TRUE on a design, the optimizer prefers the
positive edge triggered devices for all unmapped flip-flops in the design.
If you set it to FALSE, the optimizer perfers negative edge flip-flops in
the design. If you do not define this attribute, the optimizer uses the
flip-flops it determines is best."
"Similiarly, you can set the attribute for individual flip-flop instances
in a design."
- Dave Manley
Optilink
( ESNUG 152 Item 2 ) ---------------------------------------------- [9/93]
Subject: (ESNUG 150 #1) "Seek Understanding of 'set_clock_skew -uncertainty'"
> I don't quite get the results of using the set_clock_skew -uncertainty...
> If you set it too high, you get hold errors on single flip flops!
>
> I think this is a bit harsh, and it seems like the uncertainty value
> is actually more like a clock jitter value in the above case... I do
> expect skew between two different flip flops, but not from one clock edge
> to the next... I had to turn down the uncertainty to avoid what I consider
> spurious hold errors.
From: koy@everest.tandem.com (Ko Yamamoto)
Some time ago (v2.0), I spoke with Synopsys at length about this class of
timing analysis problem which I refer to as a case of reconverging paths.
The guy from Synopsys development listened quietly for about an hour and then
said, gee that's an interesting problem, maybe we can address it sometime
(after 2.2). Then he went on to discribe how they defined skew & (IMHO)
pretty much proved that real skew analysis wasn't in the cards from Synopsys.
One interesting thing he did mention was that the algorithm that they use to
calculate the design "cost" could get fairly expensive if they modelled skews
to the level of detail I wanted (and apparently other users want as well).
As this cost is calculated in an inner loop, it might very well dramatically
increase the optimization time (which we agreed would be a really bad idea).
Bottom line... I'm whining & Synopsys' handling of skew is still busted.
Anybody at Synopsys listening? Perhaps research is now worth it on this
subject.
- Ko Yamamoto
Tandem Computers
Constructive Lecture follows:
In the minimum case, one flip-flop, the "clocks" between sending & receiving
registers are EXACTLY the same (they reconverge inside the flip-flop), thus
there is exactly 0 skew.
For the more complex case with two flip flops, the skew will be based on
tracing back the clock signals and adding up skew/uncertainties/delays until
you "reconverge", ie the two clocks signals have a common source. Using
these skews/uncertainties/delays you can compute the zero cycle skew for
hold time. For the one or more cycle skew for setup time, you also need to
take into account "jitter" in the clock signal at the reconvergence point.
Example:
+------------------------------------------+
| |
Buf1 | Flop1 Flop2 |
a b | k+---------+g h+-------+ |
--|>---+ +--|D Q|----------------|D Q| |
| | /\ | | /\ | |
| +---------+ +-------+ |
| m| d e |n |
+----------+----|>-------------------+ |
c Buf2 f| |
|p |
+-------+j |
|D \/ Q|----+
Flop3 | |
+-------+
For Hold Time:
t(hold,Flop2) >= t(b->c->m) + t(m->g,Flop1) + t(g->h) - t(b->c->d->e->f->n)
t(hold,Flop1) >= t(b->c->d->e->f->p) + t(p->j,Flop3) + t(j->k) - t(b->c->m)
Now, if all the components are on a die that has minimal variation in process
(may not be such a good assumption w/ big die), then:
1) It would be pretty darn coincidental that t(b->c->m) =
t(b->c->d->e->f->p) and that t(b->c->d->e->f->n) = t(b->c->m) !
2) Try modelling this w/ Synopsys "-uncertainty" or "+/- skew." (Note
that it's kinda impossible.)
3) Note that t(a->b) has no bearing as it is before the reconvergence
point, but that it may very well have some affect on other clock skew
calculations.
4) Threshold variation on the macrocells will undoubtly affect delays.
For Setup Time similar problems arise.
( ESNUG 152 Item 3 ) ---------------------------------------------- [9/93]
Subject: (ESNUG 151 #4) "More On Clock Trees"
>I get a strong feeling that Synopsys is also designed to work with this
>approach, using the "set_clock_skew -uncertainty" command, which links the
>max clock skew you got from the global physical P&R to the timing
>optimization to get rid of hold time/race condition.
From: logsdon@hwcae.az.honeywell.com (Brian Logsdon)
The primary concern in clock synthesis, whether the drive is centralized or
localized, is end-to-end clock skew. It is especially important in
asynchronous designs, scan/atpg designs and designs with multiple clock zones.
Personally, given the garbage that I have seen out of Synopsys for synthesis,
I would be scared to death to let Synopsys generate any type of clock tree.
That's all I can say on this topic. I suggest you interrogate your vendor
closely.
- Brian Logsdon
LSI Logic Corporation
( ESNUG 152 Item 4 ) ---------------------------------------------- [9/93]
From: lund@romulus.cray.com (Gregory Lund {x66541 CF/DEV})
Subject: (ESNUG 137) "FSV - for Fixing Synopsys' Stinky Verilog Output"
Jeff Flieder's FSV Perl script in ESNUG 137 looks like it works pretty well,
except if you use register files. When FSV creates the new instance names,
it drops the final dimension in the array name. Example:
Original Synopsys gate level verilog:
MYFF \Reg_reg[2][11] ( .Q(\Reg[2][11] ), .D(n2969), .CK(Clock) );
After FSV:
MYFF Reg_reg_2 ( .Q(Reg_reg_Q[2][11] ), .D(n2969), .CK(Clock) );
Should be something like:
MYFF Reg_reg_2_11 ( .Q(Reg_reg_Q[2][11] ), .D(n2969), .CK(Clock) );
^^^
because otherwise \Reg_reg[2][11] equals \Reg_reg[2][12] after FSV. ( i.e.
they would both be translated to "Reg_reg_2". )
- Greg Lund
Cray Research, Inc.
( ESNUG 152 Item 5 ) ---------------------------------------------- [9/93]
From: maurizio.paolini@cselt.stet.it (Maurizio Paolini)
Subject: The Mysterious "set_output_delay" in 3.0b
I have a question concerning the use of "set_output_delay." If I have it
right:
"set_output_delay -clock CLK -max n { output list }"
imposes that no output in the list moves AFTER n units before the next CLK
rising edge. At this point,
"set_output_delay -clock CLK -min n { output list }"
should impose that no output in the list moves BEFORE n units before the next
CLK rising edge. However, Design Compiler 3.0b seems to ignore the latter.
That makes a minimum output delay impossible to constrain.
Am I using "set_output_delay" improperly? Is this a Design Compiler bug ?
Suggestions are welcome.
- Maurizio Paolini
CSELT - Centro Studi E Laboratori Telecomunicazioni
|
|
