( ESNUG 136 #1 ) -------------------------------------------------- [7/93]
From: jcooley@world.std.com (John Cooley)
Subject: Follow Up on White Space / Comments Bug
It's important to note that the white space & comments bug has NOT been
observed changing the functionality of the designs output by Design
Compiler -- only the gate count! That is, you might get a different gate
count on a design from the way you've put white space or comments in your
source HDL but the funtionality of your designs remains unaffected.
-- -- -- -- --
John Cooley wrote:
> This bug was presented to Synopsys and they confirmed it. In addition,
> they found:
>
> Synopsys 3.0a Has the White Space / Comments Bug
> Synopsys 3.0a-9746 Unknown Status
> Synopsys 3.0a-100052 Has the White Space / Comments Bug
> Synopsys 3.0a-100063 Does NOT have the White Space / Comments Bug
Lots o' people wrote back:
>John, Are these versions correct? I believe we have 3.0a-10052. Looks like
>there may be an extra zero in the one above but I want to confirm this.
John Cooley now writes:
"Soorry foolks, but I accidentally slipped in doouble "0" for the Synoopsys
revisioon numbers! -Joohn"
The corrected info follows:
> This bug was presented to Synopsys and they confirmed it. In addition,
> they found:
>
> Synopsys 3.0a Has the White Space / Comments Bug
> Synopsys 3.0a-9746 Unknown Status
> Synopsys 3.0a-10052 Has the White Space / Comments Bug
> Synopsys 3.0a-10063 Does NOT have the White Space / Comments Bug
-- -- -- -- --
Concerning the white space / comments bug and Synopsys 2.2b, I asked Synopsys
about this and they report that this bug doesn't effect Synopsys 2.2b or
Synopsys 2.2b-8468. Not to nag, but the Synopsys technical gurus recommend
that all users migrate to Synopsys 3.0a-10063 until Synopsys 3.0b comes out.
- John Cooley
EDA & ASIC Design Consultant
(and the ESNUG guy, too!)
( ESNUG 136 #2 ) -------------------------------------------------- [7/93]
From: danw@pobox.wellfleet.com (Dan Westerberg)
Subject: Odd 3.0a-10052 Behavior
John,
That's a very interesting bug in 10052, white-space changing gate counts,
yikes. While we're on the subject of bugs under v3.0a-10052, has anyone
else come across a scenario where a characterize does not generate:
"set_output_delay -max"
for any outputs on a module? "-min" delays are generated for the module,
but no maximums. It's funny, because the modules that these outputs go to
have "set_input_delay -max" constraints generated for them! Again, I've
submitted a test case to Synopsys and the engineers in CA have it, but I
haven't yet heard anything back.
The only way I ended up getting around this was to throw away all of my
.db's and write_script constraints, and start fresh with Verilog and
dc_shell scripts. I then started to get max output delays again. Weird.
- Dan Westerberg
Wellfleet Communications
( ESNUG 136 #3 ) -------------------------------------------------- [7/93]
From: uunet!uranus!splinter!flieder (Jeff Flieder)
Subject: (ESNUG 134 # 5) "Modelling Muxes"
> John, I've been building the stdcell library at Cyrix and I'm having
> trouble trying to specify the function for a decode-mux cell. The cell
> has 4 inputs & 4 select lines, with one select line on at a time,
> selecting an input. The function is:
>
> a & ( sa & !sb & !sc & !sd) | b & (!sa & sa & !sc & !sd) |
> c & (!sa & !sa & sc & !sd) | d & (!sa & !sa & !sc & sd)
>
> The above function is correct with one select enabled, but if I use this
> specification, Synopsys could use the cell to generate 0 by having more
> than one select high. I need to convey the illegal states of 0 selects
> high and more than 1 select high.
>
> I found a 3 paragraph description on the tri_state attribute which looks
> promising. I could enumerate the illegal states and have them as the
> function for the tri_state statement. This would probably be okay,
> though Synopsys may elect not to use a tristate cell in combinational
> logic. Does anyone have any ideas?
I have spent a significant part of my life recently creating synthesis
libraries here at Ford Microelectronics, and I am pretty sure that Mark
doesn't have to worry about this. I assume his concern is that Synopsys
will use this cell to generate a logic 0 by setting more that one input
high. The tools are smart enough to only use this cell as a mux. It is
much easier to just connect a net to Logic 0 that to use such a complex
cell.
As a matter of fact, I have never seen Synopsys actually use a mux with
individual selects, it usually selects AOI's instead (which is really the
same thing anyway). My assumtion is that the functional descriptions for
these cells is so complicated that it is hard for Synopsys to map to them.
I believe that the minimum coverage algorithms that are used by Design
Compiler are better suited to simpler logic functions. Our library also
has these cells, but more for compatibility with older designs than for
synthesis purposes.
So, I think that your specification of the block is fine, and I can't see
any way to use the tri-state model on this block since it is not a tri-state
device. Hope this helps.
- Jeff Flieder
Ford Microelectronics, Inc.
( ESNUG 136 #4 ) -------------------------------------------------- [7/93]
From: "McCabe Patrick" <McCabe_Patrick@smtpmm.space.honeywell.com>
Subject: (ESNUG 132 #1) "Working with MUXes using Verilog and VHDL"
> Where did my mux go? Why can't the tool infer my 32 to 1 mux structure?
> The tool is broken!!! How many times have your found yourself in this
> situation when you have been using Design Compiler / VHDL Compiler?
>
> Many users write HDL code with the intent of inferring or synthesizing to
> multiplexers only to find combinational logic in the resulting circuit.
The approach we have taken in speed-critical applications (what isn't?) where
you would like the Design Compiler to use a "complex" macro, such as the mux
you describe, is to create a VHDL entity with the same pinout as the cell
you would like Synopsys to use (matches the cell symbol in your schematic
library), have the architecture model the cell functionality as closely as
possible, then do a simple compile on the entity with a "prefer <lib>/<cell>"
to try to force Synopsys to use that cell (mux, or whatever). This usually
works pretty good. This has especially come in handy in FPGA designs, where
if you don't use the existing mux macros, you don't get decent timing.
Pat McCabe
Honeywell Inc.
Clearwater, FL
( ESNUG 136 #5 ) -------------------------------------------------- [7/93]
From: paolini@tor01.CSELT.STET.IT (Maurizio Paolini)
Subject: VHDL Compiler problems
John,
Recently I found a VHDL compiler problem I was not able to overcome. A
circuit module included a "big" data table. I tried to represent it in VHDL
using the two following architectures:
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_misc.all;
use IEEE.std_logic_arith.all;
use work.DECL_PKG.all;
entity CROM_LOGIC is
Port ( ADDR : In STD_ULOGIC_VECTOR (10 downto 0);
DOUT : Out STD_ULOGIC_VECTOR (23 downto 0));
end CROM_LOGIC;
architecture FIRST of CROM_LOGIC is
type BIT_MATRIX is array (0 to 2047) of BIT_VECTOR(23 downto 0);
constant CROM : BIT_MATRIX := ( X"5a8279", ... , X"5ed77c");
begin
process (ADDR)
variable IADDR : INTEGER range 0 to 2047;
begin
IADDR := CONV_INTEGER(UNSIGNED(ADDR));
DOUT <= To_StdUlogicVector(CROM(IADDR));
end process;
end FIRST;
architecture SECOND of CROM_LOGIC is
constant CROM0 : BIT_VECTOR(23 downto 0) := X"5a8279";
...
constant CROM2047 : BIT_VECTOR(23 downto 0) := X"5ed77c";
begin
process (ADDR)
variable IADDR : INTEGER range 0 to 2047;
begin
IADDR := CONV_INTEGER(UNSIGNED(ADDR));
case IADDR is
when 0 => DOUT <= To_StdUlogicVector(CROM0);
...
when 2047 => DOUT <= To_StdUlogicVector(CROM2047);
end case;
end process;
end SECOND;
Well, the FIRST architecture just blew VHDL Compiler out of memory in some
ten seconds or so (and it runs on a 48MB Sparc 10 with 300MB swap!) while the
second was properly elaborated, but run for 36 hours with no result. When I
finally put the design in PLA format, I found out that it was compiled and
mapped in 20 - 30 minutes. So, the problem is obviously in the VHDL compiler.
I would like to know whether this type of problem was found by anyone else
and, if so, whether and how it is possible to solve them (different data types
/data structures ?)
- Maurizio Paolini
CSELT - Centro Studi E Laboratori Telecomunicazioni
|
|
