> From: bezzant@cirrus.com (Dan Bezzant)
> Subject: Poor Farm
>
>From your signature:
>>Snail Mail: Hollistion Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
>> Standard Legal Disclaimer: "Anything said here are only opinions."
>
>John, out of curiosity, is it Hollistion Poor Farm or Holliston Poor Farm?
>Or is the term 'Hollistion' defined as one who is a resident of Holliston?
>
>Keep up the good work,
>
> - Dan Bezzant
> Cirrus
Dan, the place I live is called the Holliston Poor Farm; a sheep farm about
an hour out of Boston. (We have about 2 dozen sheep.) My signature is
a testimony to my extremely poor one finger typing skills -- which is why I
ask people to send ESNUG contributions 77 characters wide with no tabs so
I don't have to do reformating by hand. The Poor Farm was built in 1752
and has functioned as the town's poor farm for many, many years. (Before
welfare and social security each New England town had a poor farm or a
poor house where the financially down & out went to work for food.)
Although the poor farm system ended in the 1940's, there have been times
where I've looked at my bank balance and wondered if the true poor farm
spirit hasn't made an occassional resurgence... ;^)
- John Cooley
EDA & ASIC Design Consultant
(and the ESNUG guy, too!)
( ESNUG 150 Item 1 ) ---------------------------------------------- [9/93]
From: jericho!gord (Gord Wait)
Subject: Seeking Better 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.E. I had a flip flop with a feedback mux connecting Q out to D in for "hold
the state" function. I got a hold violation on this stand alone flip flop.
Synopsys applies the maximum delay clock, propagates the data out from that
edge thru the mux to the d input, and then compares the arrival of the data
at the D input at the minimum delay (I.E. clock - uncertainty value).
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.
Am I missing something here? I would like to have a reasonable skew
value, without having to add delay to state feedback muxen...
- Gord Wait
S-MOS Systems Vancouver Design Centre (B.C. Canada eh!)
( ESNUG 150 Item 2 ) ---------------------------------------------- [9/93]
From: cindy@zoran.hellnet.org (Cindy Eisner)
Subject: (ESNUG 149 #2 & 148 #5) "report_timing Hates Busses / Loves Bits"
hi john,
here's some more on the vector problem:
in response to uunet!uranus!splinter!flieder (Jeff Flieder)
> I am writing in response to ESNUG Post 148 Item 5, in which you were
> saying that V3.0b does not understand vectors on the point timing command.
> The reason for this is that report_timing -to * is a request for a "point
> timing" report, so you have to give the command a point, not a collection
> of points. It is true that it would be nice if the tool would understand
> vectors, and give you point timing to each bit, but this is a minor problem
> compared to all the other real glaring problems with the dc_shell interface.
well, it seems to be more complicated than that. look at the following two
reports from synopsys v3.0b:
dc_shell> report_timing -path end -delay max -to {*UV*}
Performing report_timing on port 'UV3'.
Performing report_timing on port 'UV2'.
Performing report_timing on port 'UV1'.
Performing report_timing on port 'UV0'.
Endpoint Path Delay Path Required Slack
------------------------------------------------------------------------
UV0 (inout) 18.42 r infinity infinity
UV1 (inout) 18.42 r infinity infinity
UV2 (inout) 18.42 r infinity infinity
UV3 (inout) 18.42 r infinity infinity
dc_shell> report_timing -path end -delay max -to ifrc/vh_reg[*]/D
Endpoint Path Delay Path Required Slack
------------------------------------------------------------------------
ifrc/vh_reg[0]/D (DFFRLPH) 19.50 f infinity infinity
ifrc/vh_reg[1]/D (DFFRLPH) 19.50 f infinity infinity
so, point timing reports work on multiple points. notice that on the
registers, i gave a "/D" to specify multiple pins rather than multiple
registers. point timing doesn't seem to understand cells, but only nets
or pins.
- Cindy Eisner
Zoran Microelectronics LTD
( ESNUG 150 Item 3 ) ---------------------------------------------- [9/93]
From: uunet!uranus!joker!martin (Martin Gravenstein)
Subject: More On Clock Trees
ESNUG:
Dialogue is good! I am really pleased and impressed with the response to my
last posting regarding Clock Tree insertion. Although I didn't learn much
new, much of what I knew or suspected was confirmed. I would like continue
the discussion at least one more round and see what comes of it.
My last posting consisted of a narration regarding a hypothetical designer
synthesising an ASIC and wanting to insert a clock tree. The best answer he
received was to let his vendor insert it in the 'back end'. Oh my! That must
hurt.
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 are trying
to do something very similar to what Rainer Makowitz suggests. 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. We have an algorythm which
runs in another verification tool which evaluates proper balancing of clock
trees and verifies that D/Q related sequential elements are clustered on the
same branch to minimize hold violations. We are trying to integrate all of
theses tools into an automated development and verification process but
are finding it very cumbersome.
I would really appreciate more detailed information from some of the vendors
who are inserting clock trees, among other things, in their customer's
'back end'. Are you using:
a) Synopsys
b) your APAR tool
c) in-house software?
Is it:
a) completely automated
b) somewhat automated
c) manual with lots of SPICE?
(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.)
- Martin Gravenstein
Ford Microelectronics
( ESNUG 150 Item 4 ) ---------------------------------------------- [9/93]
From: Jan Heinrich <hein@bk.bosch.de>
Subject: A Stealth Synopsys VHDL Compiler Bug
John,
Recently we encountered a bug in Synopsys VHDL Compiler, which lead to
differences between pre and post synthesis simulation. This bug is quite
serious because there are neither errors nor warnings and it can only be
discovered by simulation, which could take some time.
This bug was presented to Synopsys and they confirmed it (STAR 14691).
I think time has come for more VHDL users to participate and contribute their
experiences to ESNUG. Therefore I would like to share the results of my
investigations with other users.
And here is the VHDL-Code of a simple example which isolates the problem.
In the following example two modulo 7 counters are described. They are
controlled by the Signals Clk (clock), Res (asynchronous reset), Sync1,
Sync2 (synchronous resets), Do1 and Do2 (enable signals). For the internal
counter signals we used the array Count_int. To be able to use a FOR-loop
the synchronous resets and the enable signals are assigned to the arrays
Sync_int and Do_int respectively.
The incorrect synthesis result consists of two counters. One of them (index 0)
works correctly and the other one (index 1) counts up to his maximum value 6
and then keeps this value.
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;
ENTITY tst IS
port (
Clk : in std_logic;
Res : in std_logic;
Sync1 : in std_logic;
Do1 : in std_logic;
Count1 : out std_logic_vector(2 downto 0);
Sync2 : in std_logic;
Do2 : in std_logic;
Count2 : out std_logic_vector(2 downto 0)
);
END tst;
ARCHITECTURE rtl OF tst IS
TYPE cnt_arr_t IS ARRAY (0 to 1) OF integer range 0 to 7;
SIGNAL Count_int : cnt_arr_t;
SIGNAL Sync_int : std_logic_vector(0 to 1);
SIGNAL Do_int : std_logic_vector(0 to 1);
BEGIN -- rtl
Count1 <= std_logic_vector(CONV_UNSIGNED(Count_int(0),3));
Count2 <= std_logic_vector(CONV_UNSIGNED(Count_int(1),3));
Sync_int <= (Sync1, Sync2);
Do_int <= (Do1, Do2);
P1:
PROCESS ( Clk, Res )
BEGIN
IF ( Res = '1' ) THEN
Count_int <= (others => 0);
ELSIF ( Clk'EVENT AND Clk = '1' ) THEN
Li :
FOR i IN 0 to 1 LOOP
IF (Sync_int(i) = '1') THEN -- Synchronous Reset
Count_int(i) <= 0;
ELSIF (Do_int(i) = '1') THEN -- Modulo-7-Counter
IF (Count_int(i) >= 6) THEN
Count_int(i) <= 0;
ELSE
Count_int(i) <= Count_int(i) + 1;
END IF;
END IF;
END LOOP Li;
END IF;
END PROCESS P1;
END rtl;
Considering the IF-Clauses it is obvious that in the cases (Sync(i)='0' and
Do(i)='0') no assignments are made to Count_int(i). As though his is legal
VHDL and means that the counters have to preserve their values, it causes
SYNOPSYS to produce incorrect synthesis results!
The bug seems only to occur when the counter signals are stored in an array.
One of the counters is always processed correctly, the others do not work.
We found two ways to avoid this bug:
1) Use ELSE-Blocks to make sure that there does not exist a path
without an assignment:
...
IF (Sync_int(i) = '1') THEN -- Synchronous Reset
Count_int(i) <= 0;
ELSIF (Do_int(i) = '1') THEN -- Modulo-7-Counter
IF (Count_int(i) >= 6) THEN
Count_int(i) <= 0;
ELSE
Count_int(i) <= Count_int(i) + 1;
END IF;
ELSE -- included line
Count_int(i) <= Count_int(i); -- included line
END IF;
...
2) Use default assignments ahead of the IF-Clauses:
...
ELSIF ( Clk'EVENT AND Clk = '1' ) THEN
Count_int <= Count_int; -- included line
Li :
FOR i IN 0 to 1 LOOP
...
Has anybody discovered other bugs or discrepancies between pre and post
synthesis simulations ? Let me know ! I would like to avoid problems.
- Jan Heinrich
ANT Bosch Telecom
|
|
