( ESNUG 151 Item 1 ) ---------------------------------------------- [9/93]
Subject: (ESNUG 142 #1) "Install Problems for VHDL Sim & Synth Users"
> PROBLEM #2: The GTECH packages entities are out-of-date with their
> architectures. This may cause Error messages (i.e. Error: Intermediate
> file "GTECH.XXX.sim" was produced recently. Re-analyze files that depend
> on this file). Because Error messages are issued, this problem is the
> most critical of the two.
>
> CASE III: Synthesis only installations
>
> Synthesis-only customers using VHDL Compiler will need to re-analyze the
> GTECH source files (under $SYNOPSYS/packages/src/gtech). A script has been
> provided below to assist with this process. This workaround will address
> the possible Error messages with GTECH packages.
>
> #!/bin/csh -f
> setenv SCRIPT_HOME <<path to working area>>
> echo "" >> $SCRIPT_HOME/analyze_script
> echo "" >> $SCRIPT_HOME/analyze_script
> cd $SYNOPSYS/packages/gtech/src
> foreach vhd_file ( *.vhd )
> echo "analyze -work GTECH -f vhdl $SYNOPSYS/packages/gtech/src/$vhd_file
> \ >> $SCRIPT_HOME/analyze_script"
> end
> echo "quit" >> $SCRIPT_HOME/analyze_script
> dc_shell -f $SCRIPT_HOME/analyze_script
> rm $SCRIPT_HOME/analyze_script
From: greg@cqt.com (Greg Bell)
I would recommend people not use this script if they can avoid it. First of
all, it has errors... the first line with:
echo "" >> $SCRIPT_HOME/analyze_script
Should be:
echo "" > $SCRIPT_HOME/analyze_script
Also, the line:
echo "analyze -work GTECH -f vhdl $SYNOPSYS/packages/gtech/src/$vhd_file
\ >> $SCRIPT_HOME/analyze_script"
Should be (the " was in the wrong place):
echo "analyze -work GTECH -f vhdl $SYNOPSYS/packages/gtech/src/$vhd_file"\
>> $SCRIPT_HOME/analyze_script
The other problem I ran into was that running the above script, which
recompiles the Gtech packages, made compiling exit with an error because of
the DW01 entities which relied on the Gtech packages (eg. DW01_dec). I
re-analyzed the source for the DW01 entities on advice from the Hotline.
This then caused Synopsys to complain that the specific implementations
(eg. DW01_dec(rpl)) were out of date and that I should re-analyze THOSE.
Unfortunately, the source for these isn't available in the installed
version. Basically, the script caused a domino effect of files thinking
they're out of date ending with some files I didn't have the source for.
The bottom line is that I had to reinstall $SYNOSPYS/sparc/packages/
gtech/lib/* and the $SYNOPSYS/sparc/dw01/lib/* to get the tool to
work again.
- Greg Bell
CommQuest Technologies, Inc.
( ESNUG 151 Item 2 ) ---------------------------------------------- [9/93]
From: epakch@epa.ericsson.se (Kenny Chow)
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.
I ran into similar problem in the days of version 2.2b. Hold time violation
was reported on FFs with Q o/p feedback to D input, typically on muxed input
FFs which we used from Motorola HDC library to implement loadable registers.
I think it should be classifed as bug, although I did not report it. With Q
output feeding back to D input, it is impossible to violate hold time because
you get a perfect zero skew clock (the same clock edge, not the following
clock edge, on that particular FF clock the data into D, as well as clocking
it out to Q).
The "set_clock_skew -uncertainty" (in the 2.2b days was called "set_clock
-plus_skew -minus_skew") tells Synopsys what is the expected max skew from
your final place and route-ed clock tree/buffer. It takes this value
to evaluate the worst case situation of hold time violation, most probably
one FF Q directly driving another FF D, like in a shift register. The
'uncertainty' refer to the uncertainty in P&R that you don't know (or you
don't want to control) which FF is driven by which clock branch. There is
nothing to do with clock jittering. This clock skew uncertainty (some people
call it 'skew budget' because it is a budget that the P&R people should work
with) should be coming from the P&R implementation of the clock buffering.
It is not an arbitary number. You may have to start with an educated guess
with your ASIC vendor what max skew they expect from the technique they use
to implement the clock tree. After one round of place and route, you get a
definite number and you can run Synopsys again with this more realistic
number, and add some safety margin (I recommend 0.3nS margin in the current
technology level). So this number has a practical minimum limit and we
cannot possibly set it smaller just to avoid the hold time violation report.
Therefore, if you keep getting the same problem, I strongly recommend you
report the bug (to supplement that fact that I did not report it in the old
days).
- Kenny Chow
Ericsson Australia Pty. Ltd.
( ESNUG 151 Item 3 ) ---------------------------------------------- [9/93]
From: "Sean Atsatt" <Sean_Atsatt@notes.seagate.com>
Subject: Generating Both Positive & Negative Edge Triggered Flip-Flops
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 positive
_and_ negative edge flip/flops 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.
- Sean Atsatt
Seagate Technology
( ESNUG 151 Item 4 ) ---------------------------------------------- [9/93]
From: epakch@epa.ericsson.se (Kenny Chow)
Subject: (ESNUG 150 #3) "More On Clock Trees"
> In my case I am my own ASIC vendor. I have to do the Automatic Place And
> Route (APAR), the back annotation, and the re-verification. We plan
> to use the APAR tool to help balance wire loads and cluster branches
> properly. But we don't find that it will correctly build the tree or
> proportion it's branches to the right sequential elements. We are
> currently trying to get Synopsys to do this using the balance_buffer
> capability. But that is difficult over hierarchy.
>
> I would really appreciate more detailed information from some of the
> vendors who are inserting clock trees. (If it's mostly automated how is
> it verified and characterized and maybe you could hint at the algorithms,
> process steps, or tool features used.)
I worked with Motorola in the last design. They use Cadence Gate-Ensemble
which has an automatic way of 'synthesizing' clock tree at the stage of
physical layout. (Since I am not an ASIC vendor, I am free to talk about
what technique is used.) As I understand from them, the clock tree is
placed in the floor-plan automatically with hierarchical physical
partitioning. Root buffer in the middle of the chip. Then the chip is
equally disected into equal area divisions and 2nd level buffer placed in
the centroid of each region. This process is done recursively until the
total number of FFs can be driven by the end point buffers with reasonable
fanout. I belief Texas Instruments uses the same package. I worked in
VLSI Technology before and they have a different approach (in the tools now
spun off as Compass Design Automation). They use an output pad transistor
pair to drive the clock back into the chip. Clock source signal is routed
to that clock pad. The clock pad drive is a very big trunk of metal which
runs through the middle of the chip. Then metal wires are routed out to
cell areas (either gate array or standard cell) in a balanced tree manner.
So the clock signal is really distributed like power bus. It is easy for me
to talk about how they do it but it probably does not help you to do it.
So that is not simple way to implement this just by writing separate s/w. It
must be integrated with the P&R. It seems that you are trying take an
approach which builds a clock tree by analysing the circuit structure, which
will bound to be clumbersome. The existing approach from the above 3 vendors
are quite well developed and they all ignore the structure of the circuit
(which FF Q is connected to which FF D). All they care is the total number
of FFs, max fanout of a single clock buffer in the tree, max rise and fall
time. So it is a global physical approach rather than a logical / localized
approach.
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.
I would like to raise a related issue with clock distribution. The timing
calculation with path delay is very critical for clock net. The max skew
calculated after P&R must take path/wire delay into account. Otherwise, the
'uncertainty' in the timing calculation (in the range of 0.5nS) will be
comparable to the max skew. So if you are choosing ASIC vendor, make sure
the ASIC vendor has timing calculation for back annotation simulation with
path delay accuracy.
- Kenny Chow
Ericsson Australia Pty. Ltd.
( ESNUG 151 Item 5 ) ---------------------------------------------- [9/93]
From: uunet!uranus!splinter!flieder (Jeff Flieder)
Subject: Let's Do A Joint Enhancement Request For "dc_shell"
I would like to make a request of all dc_shell users out there who are as
unhappy with the dc_shell syntax as I am. I am currently putting together
an enhancement request for the dc_shell language to cover such things as
support for recursive subroutines (real nice for handling hierarchical
designs), and better variable interpretation and substitution, to name just
a few. I would like to get as much stuff as possible into this request,
with as many requesters as possible. You may mail your responses directly
to me or to ESNUG, it is up to you. Please also let me know if I may use
your name in my final request to Synopsys. I will post the results of this
survey on ESNUG as soon as I get sufficient response (whatever that means).
Just as an aside, I am told by Synopsys that they understand the need for
enhancements, they just do not have the manpower. Maybe if enough of us
request it, this will get moved up in the priority list.
- Jeff Flieder
Ford Microelectronics, Inc.
|
|
