Synopsys just gobbled up CADIS GmbH, an EDA company that specializes in
simulation of complex data flow oriented DSP designs, for roughly $4
million. As part of the purchase, Synopsys is also buying CADIS' design
consulting business, which specialized in telecommunications oriented
designs. Aart de Geus, Prez & CEO of Synopsys commented:
"The technical missing link between DSP design and silcon implementation
has always been practical behavorial synthesis. Bringing together CADIS
and Synopsys, for the first time, builds a connection from a domain
specific engineering such as DSP design all the way down to the ASIC."
CADIS' main competitor in the US DSP EDA market has historically been
Comdisco Systems -- which was gobbled up by Cadence within the past year.
(At the time this was quite a surprize because at last year's DAC, Comdisco
and Synopsys had their booths radio linked through a joint demo using both
company's products. To the casual observer it appeared that the two
companies were working together very closely on a business and technical
basis.) When pressed to comment on comparing Comdisco & CADIS, Aart
tactfully refused to badmouth Comdisco (& Cadence) but felt strongly that
the CADIS/Synopsys combo was the hottest stuff commercially available. The
official Synopsys press release also alluded to this with:
'"After a detailed technical benchmark, ALCATEL TELSPACE has decided to
use CADIS' COSSAP for all systems simulations and DSP designs because
of its ease of use and its high performance," said Mr. Pontif,
Electronic CAE/CAD Manager at ALCATEL TELSPACE.'
No details of the benchmark were provided in the press release.
- John Cooley
the ESNUG guy
( ESNUG 189 Item 1 ) ---------------------------------------------- [5/94]
Subject: "NEW! IMPROVED!" Synopsys 3.1a Now Fatals When Out Of Cells
From: asic@netcom.netcom.com (Henry George Berkley)
Hi John,
Synopsys 3.1a no longer generates an error message when it doesn't have
enough cells to do a mapping. It FATALs instead!
dc_shell> dont_use ss_exp/nr02d1_l
Performing set_dont_use on library cell 'ss_exp/nr02d1_l'.
1
dc_shell> compile
Information: Checking out the license 'SynLib-ALU'. (SEC-104)
Loading target library 'ss_exp'
Fatal: Internal system error, cannot recover.
Release = 'v3.1a' Architecture = 'sparc' Program = 'dc_shell'
'9904692 9904980 10195316 18950040 6911352 6128096 6100836 7072824
7040280 6949388 6949992 6950720 6924888 6423004 2174188 2090284 430060
8702040 8691504 23272 23128 22872 8948 8300'
- Henry George Berkley
Electronic Consulting
( ESNUG 189 Item 2 ) ---------------------------------------------- [5/94]
Subject: (ESNUG 188 #4) Unhappy With Two Verilog/Synopsys Gotchas
>We've had a flurry of problems crop up lately with Verilog HDL code which
>simulates fine however the post-Synopsys output is not what we expected...
>
> output [3:0] buf0;
> :
> reg [7:0] buf0;
>
> // buf0 feeds another stage buf1 however only 4 bits of buf0
> // leave the module - Synopsys removed all references and gates
> // to buf0[7:4]!!
>
>Verilog doesn't catch this; Verilint doesn't catch this; Synopsys doesn't
>catch this.
---- ---- ---- ----
From: "prz@play.rose.hp.com" (Paul Zimmer)
This isn't a bug, it's a feature! A "reg" statement just declares a
variable. Synopsys is NOT required to retain all variables in gate form.
I use this FEATURE all the time. I create intermediate variables in my
code to make it more understandable ("enable = (control == 3'b010)"),
and I sure don't want Synospys to make sub-optimal logic just to ensure
that my intermediate variable exists in gates.
The above assumes that buf0 is combinatorial. If buf0 gets assigned-to
in a "always @ (posedge clock)" block, Synopsys will infer a flip-flop.
These are not so readily optimized out of existence, but they can be.
This brings me to a true bug, or a least a much-needed enhancement.
We found it by having a counter (infered flops) and checking the counter's
value against a constant that was bigger than the counter could hold.
It's an easy mistake to make. You declare the counter when you write the
module, then go back and up the comparison value later without thinking
about the declaration.
Neither Verilog (Cadence's anyway) nor Synopsys warn you that you did this.
Verilog just never takes the branch (since the counter never obtains this
value), and Synopsys implements something that does the same thing:
NO LOGIC (no flops, no decode, nothin').
[Side note: It's actually a little more complicated than this. If the
counter is big enough (>3 bits? 4bits?), design_compiler will use
synthetic components. It you don't flatten these out of existence,
the logic stays. If you do, or if your counter is small enough to
not require synthetic components, you get the "NO LOGIC" solution. ]
Even those this is "correct", in that it does what the simulator does,
Synopsys agrees that some sort of warning is in order. There is
a star on this to make Synopsys warn you when you did this
(look for a value that is bigger than the variable can hold).
I also convinced them to file another star for the more general case.
Design_compiler should warn you WHENEVER it optimizes out infered flops.
You almost never want this.
- Paul Zimmer
Hewlet Packard
---- ---- ---- ----
From: zalzala@mpd.tandem.com (Linda Zalzala)
I have seen a similar problem to the one described in ESNUG 188 #4. This
relates to Synopsys optimizing out flip flops that are used as staging
registers. I am not sure if this is the same problem that the previous
person had.
Doesn't work - buf0 gets optimized out, leaving buf1 = in.
wire [7:0] in;
reg [7:0] buf0;
reg [7:0] buf1;
always @ (posedge clock)
begin
buf0 = #1 in;
buf1 = #1 buf0;
end
Does work - use non blocking assignments.
always @ (posedge clock)
begin
buf0 <= #1 in;
buf1 <= #1 buf0;
end
Does work - separate register stages into different always blocks.
always @ (posedge clock)
begin
buf0 = #1 in;
end
always @ (posedge clock)
begin
buf1 = #1 buf0;
end
Hope this helps,
- Linda Zalzala
Tandem Computers
---- ---- ---- ----
From: uunet!fmicos!splinter!flieder (Jeff Flieder)
> Any other "gotchas" roaming about? (in reference to legal Verilog code
> that Synopsys eats without warnings and then messes up)
Here's another good one. Given the following code segment:
parameter [4:0] state2_0 = 2'b00, state2_1 = 2'b01,
state2_2 = 2'b11, state2_3 = 2'b10;
always @( state or b or c or d)
begin
casex({c,state})
{1'b1,state2_0} :
if ((d == 1'b1) & (b == 1'b0))
next_state = state2_1;
{1'b1,state2_1} :
if (b == 1'b1)
next_state = state2_2;
{1'b1,state2_2} :
if (b == 1'b0)
next_state = state2_0;
{1'bx,state2_3} :
next_state = state2_0;
endcase
end
Verilog reads and executes this code fine, Synopsys reads it with no
problems, but if you do a check_design, Synopsys will tell you the ports "d"
and "b" are not connected to any nets. The problem is the width mismatch
between the defined state parameters (5 bits) and the state variable
(2 bits). If you change the parameter to 2 bits, everything is OK again.
Seems to me this should at least be a warning in Synopsys, or they should
be able to handle these things more gracefully, like Verilog does.
- Jeff Flieder
Ford Microelectronics
---- ---- ---- ----
From: black@mpd.tandem.com (David C. Black)
>(In fairness to Verilint their next release is supposed to catch both
>of these problems.)
Which version of Verilint?
- David C. Black
Tandem Computers
( ESNUG 189 Item 3 ) ---------------------------------------------- [5/94]
From: Magnus.Jacobsson@era-t.ericsson.se (Magnus Jacobsson T/RG)
Subject: Aliases To Piss Off Your Synopsys Salesman (More Licence Wars)
Hi John!
We use the following aliases for read and compile commands which makes
Synopsys give up Design-Compiler and VHDL-Compiler licenses when not
needed. They are very primitive and don't work under all circumstances,
but saved us from bying even more licenses. If required, it is probably
easy to modify them to give up other kind of licenses too.
They are based on the fact that Synopsys executes a create_schematic command
after successful completion of the read and compile commands. What they do
is create another alias for the create_schematic command that, when executed,
gives up the licenses. I redefine "read" and "compile" commands to let go
of their licenses when completed through aliasing like:
alias read "alias create_schematic \"view_disable_error_windows=true;
remove_license VHDL-Compiler; remove_license Design-Compiler;
view_disable_error_windows=false; unalias create_schematic;
\\\create_schematic \"; read";
alias compile "alias create_schematic \"view_disable_error_windows=true;
remove_license Design-Compiler;
view_disable_error_windows=false;
unalias create_schematic; \\\create_schematic \"; compile";
The reason for using view_disable_error_windows=false is to avoid getting
pop-up error messages when trying to get rid of licenses you don't have.
This happens for instance when reading other files than VHDL files and in
modern versions of Synopsys that doesn't grap a Design-Compiler license
during VHDL read.
One case when they don't work is when the read command itself fails, because
then no create_schematic command is executed. If anyone has any better ideas
on how to do this or can make these alias better I would be glad to hear
about it on ESNUG.
- Magnus Jacobsson
Ericsson Radio Systems
( ESNUG 189 Item 4 ) ---------------------------------------------- [5/94]
From: "Dennis Strouphauer" <dstroup@VNET.IBM.COM>
Subject: Synopsys & Bidirectional I/O
John,
I'm having some trouble with bidirectional I/O's. Synopsys tells me that I
can set all the following commands at once on any bidirectional I/O pin:
set_load, set_drive, set_input_delay, set_output_delay. When I do this and
generate a timing report for the pin when used as an input, I see this
rather large delay at the pin. I assume this is because I've set a load
because the problem goes away if I remove the load constraint. I was
just wondering how the rest of the Synopsys community is handling
bidirectional I/O pins. Setting all the above commands at once sure seems
contradictory to me. Or is it possible that my library is not modeling
bidi's correctly? Anyway, keep up the good work--I really enjoy reading
ESNUG. Looks like Professor Anderson taught you well at UVM!
- Dennis Strouphauer
IBM Corporation
( ESNUG 189 Networking Section ) ---------------------------------- [5/94]
Digital Design Engineers w/Verilog & Synopsys experience wanted for ASIC
design in Houston, TX. "hecht@twisto.compaq.com" Fax: Stu @ 713-378-1396
|
|
