Editor's Note: Some of you have noticed that ESNUG hasn't gone out for 4
weeks. I must apologize. But I've been working for what I believe is a
higher good. I belong to a Massachusetts fathers group (which oddly enough
has 20 percent of its membership being women) that believes that the
patchwork of initially well intended divorce laws and practices here are
actively working to destroy the post-divorce father/child relationship.
And because we don't have the big bucks to "buy" local politicians in the
traditional manner, we've instead given them over 1200 man-hours so we can
get our ideas heard. For the past 4 weeks, we've manned their phone banks,
gone door-to-door distributing their pamphlets, held their signs while
roadside, cheered them at debates, attended their rallies, wrote letters
for them, attended their fundraisers -- anything to get them elected.
Last night, after all that work, all "our" local politicians got elected.
In exchange, they've agreed to support our proposed law that divorced
Massachusetts fathers will have the right to receive a copy of their kid's
school report cards. OK, we know it's not much, but it's a beginning.
And if we can eventually make it so that even just a *few* more kids get
to have their divorced fathers in their lives, it'll all be worth it.
- John Cooley
the ESNUG guy
( ESNUG 254 Item 1 ) -------------------------------------------- [11/6/96]
Subject: (ESNUG 253 #8) DC + Solaris 2.5.1 + 60K Design = Infinite Hang????
> Do you know if anyone out there using Solaris 2.5.1 and Synopsys are
> getting infinite run times? The design I'm working on will compile for
> the smaller blocks, but seems to get hung up with larger chunks. The
> same design and scripts ran in 3 hours on a sparc 20.
From: rsluzewi@procy.gi.com (Ray Sluzewicz)
Greetings John.
The symptom -- long run times, may be related to the physical memory/
swap space combination on your machine. I have been running VERY large
jobs using Solaris/Ultra-sparc and Synopsys 3.3b as well as sparc20's
using Sunos without having more than expected run-time differences.
- Ray Sluzewicz
RCS Technologies Inc.
---- ---- ---- ---- ---- ----
From: AndyM@3Dlabs.com (Andy Maund)
Hi John ...
We also get this having just switched from SS20's to UltraSparcs. Like
you, smaller blocks are OK, but some large blocks hang during the Mapping
phase.
Hotline call due first thing tomorrow I think !
- Andy Maund.
3D Labs Ltd.
( ESNUG 254 Item 2 ) -------------------------------------------- [11/6/96]
Subject: (ESNUG 253 #10) Does Synopsys Synthesis Support VHDL Recursion ?
> I recently heard that Synopsys supports Recursion in VHDL, and will
> synthesize recursive VHDL code! Recursion is a very powerfull tool, and
> for instantiating highly repetitive blocks it would be very useful. ...
> ... Peter Ashenden of University of Cincinatti has an example of a
> recursive call upon a VHDL entity to generate a buffer tree, the paper is
> called "Recursive and Repetitive Hardware Models in VHDL". ... If at all
> possible I would appreciate a simple example, something like a clock tree
> or priority encoder would be nice.
From: jcooley@world.std.com (John Cooley)
The quick & dirty answer is "Yes, Synopsys does support VHDL recursion in
synthesis." (It could even support Verilog recursion if Verilog had it;
the basic software to do it isn't terribly Verilog/VHDL dependent.) Of
course this is just newly supported by Synopsys so a lot of this is still
very experimental. There are some complex restrictions you have to follow
but the big one is that *everything* must be static at elaboration time.
(i.e. You may design an N-bit priority encoder, but N *must* be given an
exact value at synthesis time.) The N-bit priority encoder bellow will
consistently build a better circuit with better area and timing -- plus
it scales nicely.
package pack is
constant N: integer := 5; -- Note: N is statically defined here!
function log2(A: integer) return integer;
function max(A,B: integer) return integer;
end;
package body pack is
function max(A,B: integer) return integer is
begin
if(A<B) then return(B);
else return(A);
end if;
end;
function log2(A: integer) return integer is
begin
for I in 1 to 30 loop -- Works for up to 32 bit integers
if(2**I > A) then return(I-1);
end if;
end loop;
return(30);
end;
end;
use work.pack.all;
entity priority_tree is
port (A: in bit_vector(2**N - 1 downto 0);
P: out bit_vector(N-1 downto 0);
F: out bit);
end;
architecture a of priority_tree is
procedure priority ( A: in bit_vector; -- Input Vector
P: out bit_vector; -- High Priority Index
F: out bit) is -- Found a one?
constant WIDTH: INTEGER := A'length;
constant LOG_WIDTH: INTEGER := log2(WIDTH);
variable AT: bit_vector(WIDTH-1 downto 0);
variable F1, F0: bit;
variable PRET: bit_vector(LOG_WIDTH-1 downto 0);
variable P1, P0, PT: bit_vector(max(LOG_WIDTH-2,0) downto 0);
begin
AT := A; -- Normalize array indexes
if(WIDTH = 1) then -- Handle Degenerate case of single input
F := AT(0);
elsif(WIDTH = 2) then -- Bottom of the recursion: a two-bit encoder
PRET(0) := AT(0);
F := AT(1) or AT(0);
else -- Recurse on the two halves, and compute combined result
priority ( AT(WIDTH-1 downto WIDTH/2), P1, F1);
priority ( AT(WIDTH/2-1 downto 0), P0, F0);
F := F1 or F0; -- We found a one if either half had a one
if(F1 = '1') then -- If the first half had a one, use it's index
PT := P1;
else
PT := P0; -- Otherwise, us the second half's index
end if;
PRET := F1 & PT; -- The result MSB is one if the first half had a 1
end if;
P := PRET;
end;
begin
process(A)
variable PV: bit_vector(N-1 downto 0);
variable FV: bit;
begin
priority (A, PV, FV);
P <= PV;
F <= FV;
end process;
end;
Another more concise way to do this is with a loop (see below). The
loop architecture is a serial, cascaded circuit which can be optimized
effectively up to N=16. At N=32 you begin to see a small variation in
the results. The tree is always better but in small examples the
optimizer will produce the same result.
package pack is
constant WIDTH: integer := 32;
function log2(A: integer) return integer;
end;
package body pack is
function log2(A: integer) return integer is
begin
for I in 1 to 30 loop -- Works for up to 32 bit integers
if(2**I > A) then
return(I-1);
end if;
end loop;
return(30);
end;
end;
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use work.pack.all;
entity priority_long is
port (A: in std_logic_vector(WIDTH - 1 downto 0);
P: out std_logic_vector(log2(WIDTH)-1 downto 0));
end;
architecture a of priority_long is
signal PT : std_logic_vector (log2(WIDTH) downto 0);
signal IT : integer;
begin
process(A,PT,IT)
begin
IT <= 0;
for I in 0 to WIDTH-1 loop
if ( A(I) = '1' ) then
IT <= I;
end if;
end loop;
PT <= CONV_STD_LOGIC_VECTOR(IT,log2(WIDTH)+1);
P <= PT(log2(WIDTH)-1 downto 0);
end process;
end;
The final function call shows how to implement the reduction operator
(function call) using recursion to produce a tree. In many cases a
simple loop can produce the same results but the tree is guaranteed to
give you the best synthesized result. (Many times Synopsys can clean up
bad code but this get harder as the circuit gets bigger or more complex.)
function recurse_XOR (data: std_logic_vector) return std_logic is
variable UPPER_TREE, LOWER_TREE : std_logic;
variable L_BOUND, LEN : integer;
variable i_data : std_logic_vector(data'LENGTH-1 downto 0);
variable result : std_logic;
begin
i_data := data;
if i_data'length = 1 then
result := i_data(i_data'LEFT);
elsif i_data'length = 2 then
result := i_data(i_data'LEFT) XOR i_data(i_data'RIGHT);
else
LEN := i_data'LENGTH;
L_BOUND := (LEN + 1)/2 + i_data'RIGHT;
UPPER_TREE := recurse_XOR (i_data(i_data'LEFT downto L_BOUND));
LOWER_TREE := recurse_XOR (i_data(L_BOUND - 1 downto i_data'RIGHT));
result := UPPER_TREE XOR LOWER_TREE;
end if;
return result;
end;
For an interesting discussion of coding priority encoders, I suggest you
check out the paper by Mike Parkin of SUN Microsystems in your Synopsys
Online Documentation titled "Writing Successful RTL Descriptions in
Verilog" or the SolvIt note 019403.
Of course, all this recursion work is cutting edge, so don't be surprised
to see more details (and restrictions) on how to use recursion in Synopsys
synthesis in future ESNUGs.
- John Cooley
the ESNUG guy
( ESNUG 254 Item 3 ) -------------------------------------------- [11/6/96]
Subject: (ESNUG 253 #9) Different Capacitance On Different Pins Of One Bus
> I've got some cells in my library that have different capacitances on
> different pins of a bus. The most common case is that all the even-
> numbered pins have one capacitance number, and all the odd-numbered ones
> have another capacitance. ... In the past, we have done a fairly kludgey
> thing to work around this: we had our synthesis library have cells with
> individual pins named (e.g.) "\A[0]" (all the affected busses were
> "bit-blasted" into scalar pins). This is pretty messy, since it means
> the Verilog out of (and into) Design Compiler has to not be simulatable
> due to the Verilog library cells being bussed. We have to use scripts to
> "fix" the netlists before we can do anything else with them. But, it does
> mean that we can get the right capacitance (and hence, we hope, accurate
> timing) on each pin.
>
> On page F-28 of the Library Compiler Reference Manual Vol. 2 version 3.3a
> it says that it is legal syntax to have a pin group inside of a bus group:
>
> cell (name) {
> bus (name) {
> pin (name | name_list) {
> ... pin description ...
> }
> }
> }
>
> Has anyone else on ESNUG used this feature of Lib Compiler successfully?
From: Philippe.LARNICOL@st.com (Philippe Larnicol)
Hi John,
I have made black-box cells for DC, from the layout extraction of
macro-cells. Typically, the I/O are bussed, but the bits have different
attributes. In this example, the capacitance (but also the drive strength)
of the Q_out output bits differ. Here is a portion of the model:
type ( BUS9_0 ) { /* bus type declaration */
base_type : array;
data_type : bit;
bit_width : 10;
bit_from : 9;
bit_to : 0;
downto : true;
} /* end of bus type declaration */
...
bus ( Q_out ) { /* Q_out bus description */
bus_type : BUS9_0;
direction : output;
pin ( Q_out[9] ) { /* bit #9 attributes*/
capacitance : 0.195;
timing() {
timing_sense : non_unate
intrinsic_rise : 2.26
intrinsic_fall : 2.15
rise_resistance : 0.81
fall_resistance : 0.89
related_pin : CLK
timing_type : rising_edge
}
}
pin ( Q_out[8] ) { /* bit #8 attributes*/
capacitance : 0.275;
timing() {
timing_sense : non_unate
intrinsic_rise : 2.26
intrinsic_fall : 2.16
rise_resistance : 0.77
fall_resistance : 0.78
related_pin : CLK
timing_type : rising_edge
}
}
...
} /* end of Q_out bus description */
...
- Philippe LARNICOL
Thomson Consumer Electronics Components.
---- ---- ---- ---- ---- ----
From: landman@hal.com (Howard Landman)
John, my interaction with the Synopsys hotline on this was interesting.
At first they said "You can't do that, it doesn't work." When I replied
"That's interesting, I just tried it and it works." they said "Oh great,
we can close the STAR then." and I had to say "Uh, no, there's still this
little problem with inadequate documentation ...".
To be fair, there *was* a bit more documentation than I had at first found.
Almost two paragraphs more. But it still didn't say anything about whether
there was any magic to the pin names inside the bus or whether it was order
dependent (and what order).
- Howard Landman
HAL Computers
( ESNUG 254 Item 4 ) -------------------------------------------- [11/6/96]
Subject: (ESNUG 253 #11) I Can't Resest "max_capacitance" Post-layout? Damn!
> While receiving a post-layout netlist we usually get some/many design rule
> violations depending on the design and the quality of the libraries.
> Usually max_capacitance violations can be ignored if they're less than
> 150% and you do not want to change the netlist more than necessary. It
> seems Design Compiler is not capable of handling this problem since it
> will try to remove *all* violations. It is not possible to increase the
> max_capacitance value?!! (Does anyone not want this? Why?) ... We
> managed by manipulating (subtracting) capacitance from the data in the
> annotation-file. However, this is not our preferred design methodology!
> Anyone else having other ways of solving this problem ?
From: [ Northern Exposure ]
Hi John,
Thanks for your work on ESNUG. From your recent mailings, I get the feeling
your working on a second career in comedy. Please keep me anon.
I've recently been through this and I succesfully used the following
command to change the max capacitance constraint on library cells:
set_attribute LIBRARY_NAME/CELL_NAME/OUTPUT_PIN_NAME max_capacitance X
If you got fancy and used this in a script with the get_attribute command,
you could automate changing all library cells. Also, you could ask your
ASIC vendor to provide a library with all the max capacitance attributes
at 150%, or modify it yourself if you have the source code.
- [ Northern Exposure ]
( ESNUG 254 Item 5 ) -------------------------------------------- [11/6/96]
From: Scott Nogueira <scottn@m2p.scs.philips.com>
Subject: Watch Out! -- The LMC PCI Master Model is Memory Hog!
Hi John,
I've recently reported to Synopsys that the Release 8 of the LMC PCI Master
model, for use with Verilog, seems to have a memory leak of some sort. My
Verilog-XL simulations grow with each LMC command executed, until finally
there is no memory left and VERILOG-XL dies.
Just wanted to flag this to your avid readers and also ask if anyone else
has seen this ?
- Scott Nogueira, an EDA Plus Consultant
at Philips Semiconductor
( ESNUG 254 Item 6 ) -------------------------------------------- [11/6/96]
From: charles@efficient.com (Charles Shelor)
Subject: The DC 3.5 "-scan" Option Is Great! But I Hate Its Licencing!
John,
Some of your ESNUG readers might be as happy as I was to learn about
the "-scan" option to the "compile" command in rev. 3.5 of Design Compiler.
This is a relatively 'painless' way to map scan test devices into a
design. Prior to version 3.5, a "compile" command was required; followed
by the "insert_scan" command which replaced non-scan devices with their
scan equivalents; then another "compile -only_design_rule" had to be
performed as the scan devices would have changed the timing and loading
of the design. My experience has been that a 1 hour compile would be
followed by a 5 minute "insert_scan" followed by a 10 minute compile. Using
the "-scan" option resulted in a single 1 hour compile! Thus, 3.5 required
20% less time to synthesize my design.
Now the 'gotcha'. The "-scan" option checks out a Test Compiler license.
In the version 3.4 compile scenario the Test Compiler license was only
needed during the 5 minute "insert_scan" operation. Thus, I could easily
run 4 or 5 compile jobs that 'shared' a single Test Compiler license by
waiting until the license was available, performing the "insert_scan"
and then releasing the license for the other jobs to use. In 3.5, the
Test-Compiler license is 'held' for the entire duration of the "compile"
operation rather than the 5 minutes of "insert_scan".
Thus, I must shell out additional $$$ to buy enough Test-Compiler licenses
to equal my Design Compiler licenses or I cannot use the "-scan" option.
My opinion is that the "-scan" option should not need a Test Compiler
license. The "-scan" option only affects library element selection, it does
not produce a scanned design, that still requires the "insert_scan"
operation. That should still require the separate Test Compiler license.
- Charles F. Shelor
Efficient Networks, Inc
|
|
