Once again, I'll be in Silicon Valley next week: this time playing Drill
Sargent at the VHDL Users International's Boot Camp. I'll be doing the
tutorial on "Sex, Lies and Synthesizing with VHDL" on Sunday (if I can
find my lost copy of the schedule) and will be around San Jose until
Wednesday. For those of you who'd like to get together in that time,
drop me an e-mail or call and lets see what we can do.
"I want to see you create 20 architectures for this entity, soldier!"
- Sgt. John Cooley
the ESNUG guy
( ESNUG 154 Item 1 ) ---------------------------------------------- [10/7/93]
From: Keskinen Jari Markku <kessi@cs.tut.fi>
Subject: VHDL CONV_PACK_ Is Not Needed
Hello, John !
When I save a design in a VHDL format (after synthesis) Synopsys automatically
includes CONV_PACKAGE_TEST-package and 'use work.CONV_PACK_...'. Is it
possible that this package is not included in the VHDL file, because all type
definitions needed are already done in 'std_logic'-packages ???
Example VHDL code after synthesis:
library IEEE; -- ########## NOT NEEDED #########
library LSI_10K; -- ########## NOT NEEDED #########
use IEEE.std_logic_1164.all; -- ########## NOT NEEDED #########
use IEEE.std_logic_arith.all; -- ########## NOT NEEDED #########
use LSI_10K.components.all; -- ########## NOT NEEDED #########
package CONV_PACK_TEST is -- ########## NOT NEEDED #########
-- define attributes -- ########## NOT NEEDED #########
attribute ENUM_ENCODING : STRING;-- ########## NOT NEEDED #########
-- define any necessary types -- ########## NOT NEEDED #########
type SIGNED is array (INTEGER range <>) of std_logic; -- NOT NEEDED
end CONV_PACK_TEST; -- ########## NOT NEEDED #########
library IEEE; -- needed
library LSI_10K; -- needed
use IEEE.std_logic_1164.all; -- needed
use IEEE.std_logic_arith.all; -- needed
use LSI_10K.components.all; -- needed
use work.CONV_PACK_TEST.all; -- ########## NOT NEEDED ########
entity TEST is
port( CLK, RST, ENA : in std_logic; X : in SIGNED (9 downto 0); ofl,
ufl : out std_logic; Y : out SIGNED (9 downto 0));
end TEST;
An error occurs if I take this CONV_PACK into use, because same type
definition for SIGNED is done in two packages: CONV_PACK & std_logic_arith.
What's wrong here? Am I missing something?
- Jari Keskinen, Signal Processing Laboratory
Tampere University of Technology, Finland
( ESNUG 154 Item 2 ) ---------------------------------------------- [10/7/93]
Subject: (ESNUG 150 #1 152 #2 153 #4) "set_clock_skew -uncertainty"
> I had a single 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.
From: [ Synopsys R & D ]
There is a question on ESNUG Post 150 about clock uncertainty when a flip
flop feeds back to itself. Yes, this is a known problem with the tool. R & D
has added the capability to deal with this in v3.1a) by setting a hidden
variable:
"tvc_uncertainty_handle_self_loops = 1"
The reason this is hidden is because it increases the complexity of timing
analysis, meaning longer excute time, and may not be needed by most users.
In v3.0, you could override the pulse relations by using min_delay on
each register self-loop:
"min_delay <uncertainty_value> -from ff1/CP -to ff1/D"
Uncertainty will be computed in, and will be added to the path length.
- Synopsys R & D
> but to just solve the single flip-flop skew problem, use:
>
> set_false_path -hold -from o_reg/Q -to o_reg/D
>
> true, this is not practical for an entire block, because you need to
> name each flop, but it can help you with a specific problem now.
From: [ Synopsys Applications Engineering ]
In this case, the suggested command:
"set_false_path -hold -from o_reg/Q -to o_reg/D"
is not a legal command. Some of commands where "-from" and "-to"
are restricted:
set_false_path, set_multicycle_path, group_path
To make these commands effective, users must specify "-from" and "-to" by
referencing the clock path. The startpoints must be primary inputs or
registers, and the endpoints should be primary outputs or registers.
The primary inputs and primary outputs all have timing information based
on the reference clock, so they are aligned with the internal register
on the same clock cycle. For "-from" and "-to" option, users can randomly
pick a net or pin in the design, but it will break some of the timing paths
without accomplishing any meaningful tasks.
- Synopsys Applications Engineering
( ESNUG 154 Item 3 ) ---------------------------------------------- [10/7/93]
Subject: (ESNUG 153 #6) "Too Many Nets In Final Designs"
> We are seeing a high percentage of nets per gate in our design using
> Synopsys. It appears that the synthesizer is chosing a lot of simple gates,
> (i.e 2 input) rather than 4 or 5 input gates to implement a logic function.
>
> This is resulting in a large number of nets per gate.
>
> I understand that this is inherent with the use of Synthesis in general.
> However this is resulting in our ASIC being difficult to route. Could you
> make any recommendations or suggestions on how to constrain the synthesizer
> to help this problem?
--- --- --- ---
From: Jon.Kuppinger@FtCollinsCO.NCR.COM (Jon Kuppinger)
We and many of our customers are seeing the same problem of a high net to
gate ratio in designs synthesized by Synopsys. The most damaging results
occur when the customer is targeting their design for gate array. We can
generally realize a 45 to 55% utilization in a given gate array base set.
However, in designs synthesized by Synopsys we do not achieve acceptable
utilization percentages (ie. they're less than 40%) due to the large
number of small nets. This drives the use of gate array base sets that are
one and two sizes larger than predicted based on the number of gates in
a design. Synopsys Vendor Applications has been informed of this issue
and is hopefully looking into possible solutions/helps.
I have tested a number of synthesis commands and library attribute variations
in an effort to improve the problem of large number of nets with no real
success. The wire load model 'area' value is typically given a zero value
by vendors as it appears NOT used during synthesis...only cell area seems
to be used in meeting constraints. I've heard that Synopsys is adding a new
design constraint in 3.1a to account for routability of cells. The current
status is that we have no solution that I am aware of at this time for this
problem. I am hoping that someone at Synopsys or some experienced user or
library developer will be able to shed some light on this subject....
- Jon Kuppinger
NCR Microelectronic Products
--- --- --- ---
[ Editor's Note: And like the proverbial cavalary arriving in nick of time,
Cindy Eisner has a solution! Keep up the good work, Cindy! - John ]
From: cindy@zoran.hellnet.org (Cindy Eisner)
do you have your own library? then make sure that your wire model uses area!
you don't have your own library? then tell your asic vendor that you want
the area field of the wire model to be adjusted. you don't use a wire
model???? then open your manual and start reading fast.
the problem is that for synopsys, the default cost of wire is 0 in both
timing and area. however, you can use a wire load model to tell synopsys
how much time (r & c) wire costs, and how much area (routing).
to see if the wire model you are using contains area, look at the
"net interconnect area" field of the "report_area" report. if the
"net interconnect area" is 0, you have a problem.
following are the results of two syntheses of the following simple block:
module x(o,i);
output o;
input [7:0] i;
assign o = ~(&i); /* a Verilog 8-bit AND gate with inverted output */
endmodule
then synthesis used a wire model in which area of wire is zero:
module x ( o, i );
input [7:0] i;
output o;
wire n15, n16;
NAND4 U7 ( .X(n15), .A(i[7]), .B(i[6]), .C(i[5]), .D(i[4]) );
NAND4 U8 ( .X(n16), .A(i[3]), .B(i[2]), .C(i[1]), .D(i[0]) );
OR2 U6 ( .X(o), .A(n15), .B(n16) );
endmodule
this synthesis used a wire model in which wire costs area as well as timing:
module x ( o, i );
input [7:0] i;
output o;
NAND8 U9 ( .X(o), .A(i[7]), .B(i[6]), .C(i[5]), .D(i[4]),
.E(i[3]), .F(i[2]), .G(i[1]), .H(i[0]) );
endmodule
without a wire model, synopsys chose three gates with a total area of
(2+2+2) 6 units, while the 8-input nand gate has an area of 7 units. as
soon as wire costs area, synopsys recognizes that it is preferable to
use the single gate.
- Cindy Eisner
Zoran Microelectronics LTD
--- --- --- ---
From: [ Synopsys Applications Engineering ]
Too many nets? DC will try to use higher number of inputs gates when you
tighten your timing or area constraint. You always allow to loose constraint
later, and repcompile with "compile -incremental"
- Synopsys Applications Engineering
( ESNUG 154 Item 4 ) ---------------------------------------------- [10/7/93]
From: Paul Zimmer <prz@hprnd.rose.hp.com>
Subject: test_compiler Hates Existing Scan Chains
We're using mux'ed flop scan methodology on a hierarchical chip. We would
LIKE to be able to insert scan on the individual modules when they are
compiled, then just hook them up from the top of the chip.
We have two engineers here (easily identified by the blood on their heads
from repeated contact with the walls) who SWEAR that, despite all the
stuff in the manuals about "set_test_methodology -existing_scan", and
"set_signal_type", etc., there is NO WAY to get test_compiler to hook
up existing scan chains in a hierarchical design.
Before I bloody my head as well, can anyone either confirm or refute their
claims. Has anyone ever succeeded in doing this? Repeated contact with
Synopsys Hotline has not helped....
- Paul Zimmer
Hewlett Packard
|
|
