Editor's Note: Got my "Ventana" today. You know, that Synopsys marketing
newsletter you get four times a year. Its byline is "A Window Into
Synopsys' World." There was something odd about this issue, though. It
took me all of 30 seconds to figure it out. It had VHDL mentioned all
over the place (front page had VHDL 12 times) and no mention of that
"other" hardware description language anywhere! Even the Puzzle Page (my
favorite section) had no references to the most evil Veri-something. (I
solved the word scramble to be sure. You try unscrambling the 10 letters
in MAIDLEIMTY to fit in 11 boxes! No Veri-nothings hidden here.) I started
to make a game of counting the number of times VHDL was said (31 times)
and how the Editor cleverly worked to not say the forbidden Veri-word.
(Best Quote: "Chi-Foon Chan, VP of Enginering at Synopsys sayz 'VHDL
has become the dominant language in the industry.'" -- dominant over what?
And can someone who's leading a team to develope a commercial VHDL simulator
be considered even remotely unbiased on this topic?)
Then I couldn't help but think of the movie "Monty Python & The Search For
The Holy Grail" where brave Sir Robin ran into the Knights-Who-Say-"Ni!"...
These poor knights had one weakness. Say the word "it" to them repeatedly
and they'll winch horribly, make bad faces and fall to the ground screaming.
I couldn't help but wonder what bizzare reaction I'd get if I said the word
"Verilog" mulitple times to any of the people at Synopsys... :^)
- John "Ni!" Cooley
the ESNUG guy
( ESNUG 177 Item 1 ) ---------------------------------------------- [2/93]
Subject: (ESNUG 176 #6) Synopsys Is Inverter 'Happy'!
>We have been anaylzing the buffering that is inserted into designs and have
>found that two inverters are used consistently over a single buffer cell. The
>inverter combination has the same area as the single buffer but the buffer is
>faster than the inverter combination.
>
>Why does it consistently choose the inverters over the buffer? And how can
>I get it to choose the buffers?
--- --- ---
From: knight@acuson.com (Jon Knight)
This response does not address the reasons that Synopsys chooses inverters
over buffers, but the use of back-to-back inverters is a general design issue
that all designers of high-speed submicron ASICs should be aware of. Most
ASIC buffers do not have symmetrical H-L and L-H propagation delays. This
leads to an effect called pulse skew or pulse width shrinkage, i.e., the
duty cycle of the signal is changed by the difference in the rising and
falling delays. The use of back-to-back inverters tends to offset this
effect somewhat because you always have a H-L and a L-H delay in series.
This is not perfect, of course, because of the additional capacitive loading
on the second inverter in the chain, but it does help, particularly in the
generation of high-frequency clock trees.
- Jon Knight
Acuson
( ESNUG 177 Item 2 ) ---------------------------------------------- [2/93]
Subject: (ESNUG 175 #6 176 #2) "Synopsys 3.0c Hates Making Clocking Networks"
>Hello, John. I am having problems with the balance_buffer command. I have
>a design in which different clock nets have to be buffered. The Design
>Compiler processes the circuit for a very short while... But when I
>inspect the design, I notice that nothing has changed! - massive fanout
>violations everywhere and no buffers at all were inserted!
--- --- ---
From: vlsiphx!logsdo_b@enuucp.eas.asu.edu (Brian Logsdon)
John, please post only my name and no company.
I am compelled to repeat my argument of several months ago (ESNUG 152 #3).
Synopsys, or any other synthesis tool, cannot synthesize balanced clock
trees without knowing how to do place & route!
Why? In order to minimize skew (which IS the whole purpose for doing
balanced clock trees to begin with) you must optimize cell placing & routing
in addition to load balancing the branches of the tree.
The reason for this is that the load capacitance for the gates in much less
per unit than the capacitance due to wire loading. For example: in a 0.6
um CMOS process, the input capacitance of an inverter (like that used on
the clock input to a flip-flop) is about 0.04 pf/per, while the wire
capacitance is 0.12-0.15 pf/mm. And that's in two-layer metal processes.
It gets worse in three and four layer processes. When you consider that the
clock tree wire length in the largest net in your die, you have a real
problem trying to balance it from a synthesis level.
If you don't balance the loading at the layout level, then you effectively
end up with 100-200-100,000's of clock-zones and any signal crossing the
zones is subject to hold-time violations and assorted other messy things.
(Including numerous redesigns!)
Net Result: Give up! Tell your ASIC vendor how many FF's you have, etc.
and have them design your clock tree for you!
- Brian Logsdon
[No Company]
--- --- ---
From: jdomas@rwasic12.aud.alcatel.com (Jeremy D. Omas)
I have a process that produces a great clock tree. It is as follows:
1) Compile your design as usual. However, make sure that the clock input
has infinite drive (set_drive 0; which is the default if not being set).
2) After you are happy with your design logic, remove all constraints and
clock definitions.
remove_constraint -all
remove_clock -all
(or just reset_design)
3) Put a dont_touch on all cells in the design. Assuming a flat structure
is being used the command is:
dont_touch find(cell,"*")
4) The next few commands have to be tweeked for your own library and for
the number of FF's being driven. Basically set them relatively high
to your library value.
set_drive 30 Clk
set_load 100 Clk
5) Set a max delay on the clock input to anything it drives.
max_delay 0 -from Clk
6) Compile:
compile -incremental_mapping -map_effort medium
7) Reset the design (reset_design) and reset the constraints (clocks, etc.).
The high value for set_drive tells Synopsys that whatever is driving this
input has long delays and little drive capability. Then, the max_delay forces
a balanced tree, and the high set_load tells Synopsys that this port is
driving a lot. Again, you'll have to experiment with setting the load and
drive values to produce the desired result.
- Jeremy Omas
Alcatel
( ESNUG 177 Item 3 ) ---------------------------------------------- [2/93]
Subject: (ESNUG 173 #2 174 #1) 3.0c DC + High Map Effort = Crashing SPARC 10"
:ESNUG 173 #2:
>If I compile Verilog source with the design_compiler using '-map_effort
>high', after about 15 minutes the work station will trap to the boot prompt
>with the message "watchdog timeout"! ... Any setting other than
>'-map_effort high' appears to work OK.
:ESNUG 174 #1:
>FYI, the local synopsys AE has been here twice. After being somewhat
>amazed that he could even crash the system, he has taken data and left to
>run a test case at his office. I don't think he has filed a 'star' yet.
--- --- ---
From: [Synopsys Support Center]
I'm sorry to report that we can't seem to reproduce Mark's problem either
at Synopsys or at his local FAE field office. (Yes, we were using all the same
designs and scripts he was using orginally but to no avail. The only
thing we haven't used were the custom c-shell scripts he used "on top"
of the dc_shell.) Based on this and the nature of the error (not just a fatal
but an entire system crash), I'm lead to believe the problem to be mainly
due to Mark's c-shell scripts.
We'd like very much to reproduce this problem so it can be fixed, but so far
we have nothing to work with. If Mark comes up with something reproduceable,
we'll come up with a workaround and post it on ESNUG.
- [Synopsys Support Center]
( ESNUG 177 Item 4 ) ---------------------------------------------- [2/93]
Subject: ( ESNUG 174 #7 ESNUG 175 #2) Latches & Forced To Buy DC-Expert
>We are seeing a problem with latch timing and dc-professional.
>
>Synopsys is timing our latches, and reporting setup violations to the
>falling edge of the clock. (Yet the Toshiba databook clearly specs setup
>for an LD2 to the rising edge.) To make matters worse if we happen to run
>on a machine with a dc-expert license, the compile invokes "time borrowing"
>and masks the problem! We feel that timing setup to the wrong clock edge
>is clearly a bug and users should not have to spend more money for a
>dc-expert license that we do not need. Does anyone have a money saving
>workaround so we're not... - [ Being Forced Into Buying DC-Expert ]
--- --- ---
From: [ Being Forced Into Buying DC-Expert? ]
John,
This is the response from the my local Synopsys AE. I basically told him he was
full of shit. They tried to add a feature and broke some basic function. The
compile times latches to the falling edge of the clock and reports setup
violations.
His two "work arounds" are intended to fake the compiler out, so it does not
"see" a latch.
- [ Being Forced Into Buying DC-Expert? ]
--- --- ---
From: [ Your Synopsys FAE ]
To: [ Being Forced Into Buying DC-Expert? ]
Some background first: the handling of latches changed from v2.2 to v3.0, so
that designers wishing to do latch-based design could more effectively use
the tool. Therefore, the tool no longer simply views them as edge-triggered
devices, but now more as devices which open-and-close, and hold data
for some period of time. Thus, in a standard 2-phase clock latch design
data is expected to arrive by the time the latch is opening. If the data has
not yet arrived, the circuit may still work, but the latch will have to
borrow the time into the next latch's period. (Please see the DesignTime
Reference Manual for a more complete description and example of latched-based
time borrowing.) I think that once you read this section you will perhaps
better understand why the tool "sees" latches the way it does.
Unfortunately, the information that the hotline provided you (that this is a
bug) was not correct. To ensure that a latch-based design is being timed
(and will work) properly, it must "see" latches in this manner. In addition,
the "set_false_path -rise" workaround shown in ESNUG 175 #2 will not work; the
user has misunderstood this command. "-rise" refers to data rising, not to a
clock event. Also, set_false_path does not work on library pins. It must be
applied to valid paths in a design.
To solve your current problem I have found 2 options thus far:
1). Disable the timing arc between G and Q (& QN) to do this use the
disable_timing command on a library part. (This will automatically
execute this command for all latches in the design rather than having
to perform this command individually on each instance of a latch.)
disable_timing tc160g/LD2P -from GN -to Q
disable_timing tc160g/LD2P -from GN -to QN
.....
The potential downside I see with this approach, is that it disables
the constraints on all paths flowing from the latches (starting at
LD2P/Q and going thru logic to a flop or output). If these paths need
to be optimized, we may need to try option 2.
2). Synthesize & optimize with "regular" latch library on 1st pass
then check the timing with a "timing-only" version of the library
where we have developed a timing-black box model for the latch cell.
Although timing-black box cells can not be synthesized from Verilog,
they can be used, in this case, to force the latch to appear as a
simple edge triggered device. The downside to this approach is that
it requires access to the source code for the vendor's library, in
order to develop an accurate timing model. (Actually, we don't
need the whole library, just the latches). I have done this sort
of thing in the past successfully, and requires close communication
between all parties involved (you, Synopsys and the ASIC vendor).
Thus, option 1 appears to be the quickest and easiest, but may not
be able to completely fill your needs.
Note, that these are the options I have uncovered thus far, and there may be
others (or more likely we may need to use a combination of the above
techniques). So let's keep in touch to work thru these issues together.
- [ Your Synopsys FAE ]
|
|
