From: annae@nortel.ca (Anna Ekstrandh)
> John,
>
> Does anybody know when SNUG and IVC are really planned for next
> year? If you take a look at Synopsys web site and check out their
> calendar of events they say that SNUG will take place between February
> 19 and 21 in San Jose, California. But in the 'Call for papers' for IVC
> that have been submitted on the newsgroups it says that IVC is going to
> take place between March 31 and April 2 in Santa Clara, California.
>
> Are these really the actual dates? And if that is the case - what
> happened to having these two conferences back to back? For us East Coast
> people it's a big bonus to be able to attend both during one visit!
>
> - Anna Ekstrandh
> Nortel of Ottawa, Canada
Anna, I hope one of those two schedules are wrong (or changed) because
otherwise it'll screw up attendence at both conferences (which would be
truely stupid in my opinion....)
- John Cooley
the ESNUG guy
( ESNUG 246 Item 1 ) ---------------------------------------------- [8/8/96]
Subject: ( ESNUG 243 #1 244 #4) I Will Trade My Secret Switches For Yours!
> I look forward to hearing what others find while checking out some of
> those other undocumented commands! ... Maybe we could start a contest to
> see who could figure them all out! (Synopsys employees could contribute,
> but certainly couldn't claim any the prizes!)
From: "Anders Nordstrom" <andersn@nortel.ca>
John,
I can help you with one of the "hidden" compile strings in Synopsys;
"compile_test" is an old command from version 2.2 that does the same thing
as the current "insert_test" command.
- Anders Nordstrom
Nortel
( ESNUG 246 Item 2 ) ---------------------------------------------- [8/8/96]
Subject: (ESNUG 243 #2) Synopsys 3.4b Won't Use 8->1 Multiplexers
>I wrote a test case for the infer_mux directive ... It works (i.e. it builds
>MUX trees) but it will not use an 8->1 MUX! Instead, it builds a 2 stage
>tree, with the input stage containing 4 2->1 MUXes and the output stage
>containing a 4->1 MUX. The design is underconstrained from the timing point
>of view, and has a set_max_area 0. From the area point of view, the order
>of efficiency is:
>
> 8->1 MUX ............ smallest area
> 4 2->1 + one 4->1 ... 21% bigger than 8->1 .... yet this one chosen
> 2 4->1 + one 2->1 ... 23% bigger than 8->1
From: Martin Soques <Martin.Soques@amd.com>
John,
The mux tree solution may not be necessarily bad from a routing point of
view. From my experience, I've found that large N->1 mux cells can result
in routing congestion in the vicinity of the mux cell due to the large
number of signals required by the mux. I'll take the silicon hit to avoid
routing problems due to the mux congestion.
- Marty Soques
Advanced Micro Devices
---- ---- ---- ---- ---- ----
From: rudis@intrinsix.com (Romas Rudis)
Hey John,
Synopsys can not automatically map anything with more than 8 inputs into a
logic funtion. Therefore an 8:1 mux (which has 8+3=11 inputs) will never
get chosen! You must actually instantiate it like so:
// Using Synopsys designware to make a 4 bit wide 8:1 MUX
GTECH_MUX8 mux0(.A(I_sel[0]),.B(I_sel[1]),.C(I_sel[2]),
.D0(I_a[0]),.D1(I_b[0]),.D2(I_c[0]),.D3(I_d[0]),
.D4(I_e[0]),.D5(I_f[0]),.D6(I_g[0]),.D7(I_h[0]),.Z(O_y[0]));
GTECH_MUX8 mux1(.A(I_sel[0]),.B(I_sel[1]),.C(I_sel[2]),
.D0(I_a[1]),.D1(I_b[1]),.D2(I_c[1]),.D3(I_d[1]),
.D4(I_e[1]),.D5(I_f[1]),.D6(I_g[1]),.D7(I_h[1]),.Z(O_y[1]));
GTECH_MUX8 mux2(.A(I_sel[0]),.B(I_sel[1]),.C(I_sel[2]),
.D0(I_a[2]),.D1(I_b[2]),.D2(I_c[2]),.D3(I_d[2]),
.D4(I_e[2]),.D5(I_f[2]),.D6(I_g[2]),.D7(I_h[2]),.Z(O_y[2]));
GTECH_MUX8 mux3(.A(I_sel[0]),.B(I_sel[1]),.C(I_sel[2]),
.D0(I_a[3]),.D1(I_b[3]),.D2(I_c[3]),.D3(I_d[3]),
.D4(I_e[3]),.D5(I_f[3]),.D6(I_g[3]),.D7(I_h[3]),.Z(O_y[3]));
/* sample constraint file for above example */
set_prefer {lca500kv/MUX81 lca500kv/MUX81P}
set_map_only find(reference, GTECH_MUX8)
set_max_delay 2.00 -from I_sel -to O_y
set_max_delay 1.00 -from {I_a I_b I_c I_d I_e I_f I_g I_h} -to O_y
Unfortunately there is no easy way to instantiate multiple components in
Verilog (in VHDL you can use "generate" statements, but even this is crude.)
I have built a user designware module called "mux_gen" where you can just
pass parameters and get one built like you want. (Note: Kurt Baty has
created a module he calls "mux_any", while mine is similar in function, it
uses a different algorithm). I am in the final phases of testing it and
getting it a releaseable form.
An example of how to use mux_gen appears below:
// Instantiate a 16-bit wide 8:1 mux, #(select_lines,bit_width)
mux_gen #(3,16)
mux_u1({I_h,I_g,I_f,I_e,I_d,I_c,I_b,I_a},I_sel,O_y);
If you would like a copy please e-mail me.
- Romas Rudis
Intrinsix Corp.
( ESNUG 246 Item 3 ) ---------------------------------------------- [8/8/96]
Subject: (ESNUG 244 #7) It's DESIGN Compiler *not* Behavioral Compiler Bug!
David Black's orginal wording of ESNUG 244 #7 was:
> As to seeing any bugs... I have seen a few bugs with v3.4b-BC2 and not
> necessarily related to Behavioral Compiler. Here is one that is logged
> with Synopsys, but unresolved at the moment.
>
> Compiling a top level module that merely instantiated two lower level
> modules that were previously compiled produced a weirdness. A control net
> that is definitely functional within the design (pre-synthesis) was
> disconnected between the two modules (it's an output from one, and an
> input to the other). The dangling input was then tied HIGH!? +%#@!! :-(
From: jcooley@world.std.com (John Cooley)
As the ESNUG guy, I'm always looking for ways to condense an engineer's
post down to the core issue. Because I know David Black uses Behavioral
Compiler a lot, I just assumed he was talking about BC in his second
paragraph above. Like an idiot I dropped his first paragraph and reworded
the first sentence in his second paragraph to read:
> While compiling a top level module in Behavioral_Compiler that merely
> instantiated two lower level modules (that were previously compiled)
> produced a weirdness. A control net...
It turns out he was talking about *Design Compiler* in his second paragraph,
not *Behavioral Compiler*! Sorry, folks. My goof!
- John Cooley
the ESNUG guy
( ESNUG 246 Item 4 ) ---------------------------------------------- [8/8/96]
Subject: (ESNUG 245 #1) My Multicycle Path Odyssey With Synopsys So Far...
> [...] ending at the same point can be dangerous. That is exactly what I'm
> doing above, since there is a multicycle path of 3 from A to B, and a
> "multicycle path of 1" from change_B to B.
From: kaufmann@shraero.shraero.co.at (Roland Kaufmann)
Well, IMHO the signal change_B (called ENA in the code below) changes only
every third cycle, so you have a "multicycle path of 3" to your
register B (called STATE below).
I had a design which produced a bit-serial stream of data which was
processed internally in 4-bit chunks, so most of the chip effectively
ran at oune fourth of the clock CLK using a timing signal ENA to
enable the registers every 4th CLK cycle:
-- This is the register, updated on posedge CLK when ENA = '1'
Storage: process (CLK, RESETn)
begin
if (RESETn = '0') then
STATE <= (STATE'range => '0');
elsif (CLK'event) and (CLK = '1') then
if (ENA = '1') then
STATE <= NEXTSTATE;
end if;
end if;
end process;
-- The combinatorial logic (STATE + 1 in Andy's case)
Feedback: process (STATE, inputs)
begin
NEXTSTATE <= f(STATE, inputs)
end process Feedback;
Then I had to tell Synopsys about the multicycle paths for *every*
such register:
set_multicycle_path 4 -setup -hold -to { "INSTANCE_NAME/STATE_reg[*]" }
this was kinda tedious but our design was small enough to allow this.
What I would try next time is to encode the name of the enable signal
in the register so that I can use a 'foreach' construct to set the
multicycle path on these regs.
It gets more difficult when you have several such signals which are
having different periods, as Synopsys' documentation is not very clear
about this. I also was amazed that the construction above was not
mentioned anywhere in the documentation/application notes --- it
sounds like a common problem to me.
- Roland Kaufmann
SCHRACK Aerospace
---- ---- ---- ---- ---- ----
From: Vlad Sindalovsky <vlad@aloft.att.com>
Hi John,
I could not help jumping into discussion on "Multicycle path Odyssey...".
Let me diverge from the usual bug/workaround routine and dwell on design
style in general.
Every time I read or hear: "Our design is fully synchronous", I get
bewildered. Why? Is synchronous design really better or this is just
surrender to the tools which handle synchronous design easier?
When the signal SAMPLE_B had been created in aforementioned design, it
was only one step left to enter "The unknown land" of asynchronous
design. Let us consider:
SACRILEGE: PROCESS (SAMPLE_B)
begin
if (SAMPLE_B'event and SAMPLE_B='1') then
B <= A + 1;
end if;
END PROCESS SACRILEGE;
If SAMPLE_B is generated appropriately, and there is enough time for A+1
to settle, the correct value of A+1 will be written into register B on
the rising edge of the new clock signal.
Advantages:
- register B is always kept clean;
- the description is very well synthesizable in Synopsys (I tried
something like this many times);
- register B is clocked when necessary, reducing power consumption;
- no additional "crazy" schematic (mux's or registers);
Penalty to pay:
- the content of register B changes with some delay from the edge of
the system clock;
If you handle the output of register B as a regular delayed output of
combinational logic, you can literally end sacrilege with the end of the
process, described above, and return to the Holy Land of Synchronous
Design.
- Vlad Sindalovsky
Lucent Technologies
( ESNUG 246 Item 5 ) ---------------------------------------------- [8/8/96]
Subject: (ESNUG 242 #6 243 #4 244 #5) Simulators Giving Frustrating X's
> The simulation problem of 'X' propagation is due to the cell definition
> of all the MUX cells. If users check their simulation library cell MUX,
> it must be built with the simulator primitive ("and", "or", "not" ...).
> To avoid the 'X' propagation, users need to define their MUX cell by
> using a UDP (User defined primitive table).
From: landman@hal.com (Howard Landman)
Not true. Adding a "redundant" gate level primitive gives the same result.
That is, making the mux function be ((s&d1)|(~s&d0)|(d0&d1)) also fixes
the problem. We do this routinely.
Of course, one can argue that users *should* want to know when mux selects
have gone unknown! In practice, however, it seems that this often causes
problems with initialization.
The bigger problem, which is not solvable at the moment, is that many high
level Verilog statements kill the propagation of Xs, but their gate-level
implementations don't. For example, in "if (a)", if a is X it gets treated
as if it were 0. Thus there will always be a difference in X simulation
between HDL and gates, in such a direction that no amount of HDL simulation
can guarantee that the gates won't go to X.
- Howard A. Landman
HAL Computer Systems
---- ---- ---- ---- ---- ----
From: mr@symbionics.co.uk (Martin Ryder)
John,
It should be possible to build a 2-to-1 MUX from logic primitives (AND, OR,
NOT) to give correct behaviour when the two data inputs are the same,
regardless of whether the select is known. I.E. for data inputs A and B,
select S, and output Q .......
_
Q = (A.B) + (A.S) + (B.S)
Of course this relies on the primitves having reasonable X-handling:
_
X = X, X+1 = 1, X+0 = X, X.0 = 0, X.1 = X
- Martin Ryder
Symbionics Developments Ltd.
---- ---- ---- ---- ---- ----
From: erstad@ssec.honeywell.com (Dave Erstad)
John,
It's true that poor library modeling can exacerbate this problem. However,
even with robust simulation models it can be a problem. Around five years
ago we were synthesizing a TM bus slave chip and ran into major headaches.
We were using our own library (Honeywell is an ASIC vendor in the space
and military markets) which correctly handles X's. The problem was that
there can be reconvergent logic where the "correct" X handling occurs across
several primitives. (As a thought experiment, think about a library
without a MUX gate. Synopsys would build the equivalent logic out of
primitives, and the behavior described by you could not be corrected
within the model library.)
The specific problems we had were due to attempting to synthesize scan
logic and synchronous resets. The synchronous reset wouldn't work because
there were two logic paths from the reset to the D input, one gated with
the Q output of the previous stage and another with the Qbar. Boolean-wise,
it reset, but in the simulator it didn't. Of course, nowadays Test Compiler
can insert scan after-the-fact, and there are Synopsys controls specifically
for the synchronous reset problem.
- Dave Erstad
Honeywell SSEC
---- ---- ---- ---- ---- ----
From: "Victor Duvanenko" <victor_duvanenko@quickmail.truevision.com>
John,
On the subject of X's in simulation caused by a synthesis created logic.
Muxes are not the only structures that cause problems (they are simply the
most obvious.) Other synthesized logic can sometimes be very tricky with
X handling; we've run into them many times.
The only true solution is for the logic simulation vendors to keep
track of X and "not X" on each particular net -- but they currently don't.
For simplicity they simply say "not X is an X, and I don't care if not X
is exactly opposite of X on that particular net." Keeping track of this
would be more difficult and would slow gate-level simulations down, -- but
then gate-level simulation would actually behave like gates!
- Victor J. Duvanenko
Truevision
( ESNUG 246 Item 6 ) ---------------------------------------------- [8/8/96]
From: dchan1@ccgate.hac.com (Darrell Chan)
Subject: Is DesignWare Worthwhile Or A Waste For High Speed DSP Designs?
Hi John,
I have a team starting a LSI Logic 0.35 micron CMOS, cell based design. Chip
is fancy two stage FIR filter. First stage is 240 MHz input decimator, no
multiplies, precomputed lookup and add. It outputs into second stage filters
at 120 MHz. The second stage is genuine 8th order 128 tap FIR. The design
will have multiplicities of 26 bit adds and 17 bit multiplies, pipelined to
sustain 120 MHz data flow.
We have been debating the usefulness of DesignWare. Some contend it will
save time to instantiate pre-optimized Designware functions. Some say we
are wasting our time because the speed is so high the Designware functions
are going to require additional optimization and get overhauled like
everything else. Would anyone on ESNUG have any recommendations in view of
the speed of this DSP design?
- Darrell Chan
Hughes Aircraft
( ESNUG 246 Item 7 ) ---------------------------------------------- [8/8/96]
From: Stephen Pollmann <spollman@tst.com>
Subject: HDL Sign-off & 3rd Parties Using Synopsys For Non-Synopsys Customers
John, the company I work for is small, so Paying 100K+ for a DC Expert, an
HDL Compiler, an Analyzer plus Maintenance is a major investment. We were
considering an HDL hand off and let the ASIC Vendor do the synthesis and
Layout (including P&R). Synopsys came in and told me that the only company
that is allowed to use their tool for HDL hand-off is Symbios Logic. Is this
true to your knowledge ? (For instance, I have heard that some Silicon
Vendors provide a design center that allows you to come in use their tool
set, which may or may not include Synopsys. Also, I have heard of consulting
firms that will come into a company that has not purchased Synopsys, take
over the HDL code that has been developed and synthesize it using Synopsys.
This sounds like the same thing as an HDL hand off to me!) Synopsys says
that a customer that purchases the Synopsys synthesis tools must output
only HDL (no gates) otherwise they are breaking the licenses agreement.
I also heard that LSI supposedly used Synopsys to develope some of their
cores and sell the cores to customers that use their FAB. Synopsys says
this is unethical. What are your feelings on these issues ?
- Steve Pollmann
Torrey Science & Technology Corp.
( ESNUG 246 Item 8 ) ---------------------------------------------- [8/8/96]
From: kumar@adttx.sps.mot.com (Jainendra Kumar)
Subject: Seeking Benchmark & User Opinions On Commercial Hardware Emulators
Hello John,
Thanks for running the ESNUG forum. While your introductions are fun to
read, I have also benefited from several discussions on wide ranging
synthesis issues. I am currently engaged in benchmarking several emulation
verification technologies in the market place such as Synopsys' Arkos
Emulator, Mentor's Meta emulator, Aptix, Virtual Machine Works and
fill-me-in on vendor against Quickturn's Emulation Systems. At this time
we are avid users of Quickturn's Emulation Systems and have used it on
more than 15-20 designs with great impact on our verification efforts.
However, we would like to stay tuned to the competition.
I would like to hear comments on ESNUG from people who are thinking
/considering/benchmarking/using any of the above emulation systems.
- Jai Kumar
Motorola
[ Editor's Note: As always, if you need to be anonymous in replying
to anything in ESNUG, just say so in your letter! - John ]
|
|
