Happy Halloween, ESNUG readers! In the never ending quest to occassionally
see a little of the fun in what we do as designers, I'm putting together
a "Scary Verilog / Terrifying VHDL" Contest. The idea will be to send in
100 line samples of actual Verilog / VHDL syntaxes you've seen tried in
the design world that was intended for simulation or synthesis. (I'm not
talking about random keystrokes that won't work in any compiler whether it's
HDL or not -- I'm talking about the stuff that either confused the hell out
of you trying to figure it out or the stuff that gave rather surprizing
results in simulation or synthesis.)
But, before I "officially" annouce this contest, though, I'll have to smooze
some EDA vendors into donating some prizes for this contest. (I've already
had one EDA vendor donate a free copy of their simulator.) Also I want
formulate some rules to insure blind, unbiased judging of the code sent in.
- John Cooley
the ESNUG guy
( ESNUG 159 Item 1 ) ---------------------------------------------- [10/93]
From: maurizio.paolini@cselt.stet.it
Subject: Test Compiler Left Ports Unrouted Out Of Subdesigns
Hello, John. Here comes a brand new bug of the Synopsys Test Compiler
(We're using version 3.0b-12954, on Sun Sparc 10).
We are trying to create a scan path in a circuit. One of the circuit modules
already contains a scan chain set, while the others don't. We processed the
circuit as follows:
dont_touch <module_with_scan>
create_test_clock -period 2000 -waveform {1000,2000} { <test_clock> }
set_test_methodology full_scan
set_scan_style multiplexed_flip_flop
set_test_hold 1 { <list_of_signals_1> }
set_test_hold 0 { <list_of_signals_0> }
insert_test -no_disable -no_route
(at this point, scan FFs have been inserted into all of the blocks but
<module_with_scan>, as desired)
remove_attribute <module_with_scan> dont_touch
current_design = <module#1>_test_1
set_scan_chain 1 { <instance_list> }
set_scan_chain 2 { <instance_list> }
...
current_design = <module#n>_test_1
set_scan_chain 26 { <instance_list> }
current_design = <module_with_scan>
set_signal_type test_scan_in -index 27 <in1>
set_signal_type test_scan_in -index 28 <in2>
set_signal_type test_scan_in -index 29 <in3>
set_signal_type test_scan_out -index 27 <out1>
set_signal_type test_scan_out -index 28 <out2>
set_signal_type test_scan_out -index 29 <out3>
set_signal_type test_scan_enable scan_en
current_design = <submodule#1_with_scan>
set_signal_type test_scan_in -index 27 <in1>
set_signal_type test_scan_in -index 28 <in2>
set_signal_type test_scan_in -index 29 <in3>
set_signal_type test_scan_out -index 27 <out1>
set_signal_type test_scan_out -index 28 <out2>
set_signal_type test_scan_out -index 29 <out3>
set_signal_type test_scan_enable scan_en
set_scan TRUE { <list_of_leaf_cells> }
set_scan_chain 27 { <sublist_of_leaf_cells_1> }
set_scan_chain 28 { <sublist_of_leaf_cells_2> }
set_scan_chain 29 { <sublist_of_leaf_cells_3> }
...
set_test_methodology full_scan -existing_scan
insert_test -no_insert -no_disable -scan_chains 29
-max_scan_chain_length 33
It must be pointed out now that the scan chains in <module_with_scan> were
routed by hand - i.e. the read netlist of <module_with_scan> already
contains the scan path routing.
After the second insert_test command, the scan chains are exactly as desired,
but several submodules in <module_with_scan> contain some fake scan routing.
Usually, the new submodule instance has some extra test_si<n> and test_so<n>
ports, where n > 29. The submodule itself does not contain any scan FF, and
so test_si<n> is directly wired to test_so<n>.
NOTE: The corresponding ports are NOT routed outside the submodule, and are
left hanging by the test compiler!
Is this a known behavior of the Test Compiler ?
Does anybody know how to overcome this bug ? (I am currently trying setting
the dont_touch attribute for all the non-scan modules, but this method is
quite cumbersome...)
- Maurizio Paolini
CSELT - Centro Studi E Laboratori Telecomunicazioni
( ESNUG 159 Item 2 ) ---------------------------------------------- [10/93]
Subject: ( ESNUG 158 # 4) 'Switch To Disable The DesignWare "Feature"'
> We don't use DesignWare at all, but Synopsys 3.0X has the hooks built into
> DesignWare that automatically grabs a HDL license when it thinks it needs
> to build parts. We have 4 options:
>
> 1.) decrease the number of Design Compiler licenses
> 2.) increase the number of HDL compiler licenses
> 3.) return to Synopsys 2.2b
> 4.) waste time finding a workaround
>
> I think Synopsys should allow a switch to let users decide if they want
> to use DesignWare or not. We'd immediately disable the DesignWare "feature"
> and synthesize like we always have!
From: [ Anonymous, Too ]
John - make me Anonymous, Too
After seeing a couple of postings on this issue, I thought I would share my
experience regarding the need for HDL compiler licenses in DesignWare. We are
one of the Synopsys' customers that have more Design Compiler licenses than
HDL Compilers for the simple fact that we only needed them to read in Verilog.
We ran into the problem in 3.0b where HDL Compiler licenses were grabbed
during compilation (DesignWare), but they were not released. We contacted
Synopsys about the issue. At first, they treated it as a bug, giving us
temporary HDL Compiler licenses while they worked on the problem. They tried
a couple of commands, but they didn't seem to work. Magically, it became a
sales/marketing issue. Synopsys claims that, despite never publicizing or
marketing it this way before, that the high level optimization performed
during a compile always required an HDL or VHDL license (either one), but it
was never "checked out". Now, in DesignWare, if you infer a structure in
your Verilog or VHDL code, the HDL Compiler license is checked out and not
released until the compile is complete.
What is the resolution? Synopsys wants me to buy enough HDL Compiler
licenses to match 1-to-1 with Design Compilers. There has not been much
give on their part in pricing or terms. They claim we are one of only a
few companies which do not have parity in licenses (is this true? anyone
else out there have the same problem?). In the meantime, we have filled
the DesignWare cache (another new feature, but this one is helpful) with
every possible size and structure of DesignWare components. If the component
is in the cache, it does not have to be built and the HDL license is not
needed. This is a temporary workaround, but whenever software versions
change or our semiconductor vendor's library changes, we have to recreate
the cache.
- Anonymous, Too
P.S. We have suggested to Synopsys technical solutions such as "wait" for
a license, turn off DesignWare, etc., but have been rebuffed so far.
( ESNUG 159 Item 3 ) ---------------------------------------------- [10/93]
From: tychan@video.sc.ti.com (T Y Chan)
Subject: EDIF bus numbering
John, I am new to this group, I have a problem that can be worked around, but,
would like find a better way to do it.
Is there a way to to enable bus numbering in little endian mode when generating
EDIF netlists from dc_shell? I am trying to convert a VHDL structural netlist
to EDIF. In VHDL, I am using constructs like:
address : std_logic_vector(31 DOWNTO 0)
and the EDIF output becomes
address_31_0_
When accessing individual bits, address_31_0_ 31 turns out to be the Least
Significant Bit while in VHDL, address(0) is the Least Significant Bit.
I am trying avoid using std_logic_vector(0 TO 31) as the design is basically
a little endian design.
- T. Y. Chan
Texas Instruments
( ESNUG 159 Item 4 ) ---------------------------------------------- [10/93]
From: Steven Redant <redant@imec.be>
Subject: A Strange 'Invalid Non-combinational Cell' FSM Bug & Workaround
John,
My goal is to design a gray counter. For this I want to use the FSM encoding
possibilities of Design_analyzer because the VHDL this way appears easier and
the synthesis should be quicker with a lower memory use.
I used the following VHDL code:
LIBRARY ieee;
LIBRARY work;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_signed.all;
ENTITY gray_counter IS
PORT (clk : IN std_logic;
enable : IN std_logic;
reset : IN std_logic;
up_down : IN std_logic;
state : BUFFER std_logic_vector(7 DOWNTO 0) );
END gray_counter;
ARCHITECTURE behaviour OF gray_counter IS
BEGIN
gr_c: PROCESS(clk, reset)
BEGIN
IF reset = '0' THEN
state <= "00000000";
ELSIF clk='1' AND clk'EVENT
THEN IF NOT (conv_integer(state)=127 OR conv_integer(state)=-128)
THEN IF up_down = '0'
THEN state <= state - "1";
ELSE state <= state + "1";
END IF;
END IF;
END IF;
END PROCESS gr_c;
END behaviour;
The following works OK:
1) read
2) compile
3) ungroup
4) fsm->allow all possible states => OK
But this gives ERRORs:
1) read
2) fsm->define legal states (gray) => ERROR (There seems to be illegal
(bogus) non-combinational cells in the design.) I get the following
error message:
"Error: Invalid non-combinational cell <one_of_them> (FSM_EX-60)"
3) Optimize
4) fsm->define legal states (gray) => ERROR
5) Ungroup
6) fsm->allow all possible states => ERROR
Here's how I did the workaround: I wrote this into an EDIF file. Then I
deleted everything I had and read in the EDIF file. I am now rid of the
bogus non-combinational cells and can proceed with changing the counter
states from binary to Gray.
This also gave ERRORs but is OK in the end:
1) read
2) fsm->allow all possible states => ERROR
3) Optimize
4) fsm->allow all possible states => ERROR
5) Ungroup
6) fsm->allow all possible states => OK
Somewhere along the way the fsm generator looses the undefined Combination
Cells. If all else were logical, it's illogical that step 4 of this last
example fails - but it does. Why? Whether or not the design is grouped it
should not matter. It seems that the ungroup option should (always?)
be used in conjunction with Synsopsys FSM synthesis.
- Steven Redant
IMEC
|
|
