Coming soon to an ESNUG near you!
Some ESNUG readers were "volunteered" to write a C script that will
send back issues of ESNUG posts to readers who request them. (This
should be of special interest to new readers.)
More info to follow in a few days. - John Cooley
ESNUG Moderator
( Post 109 Item 1 ) ---------------------------------------------------------
From: Bambang Gunadi <sbang@sdc3.ssi1.com>
Subject: Synchronous Reset Issues (Posts 107 Item 3 & Post 108 Item 2)
It looks like a lot of us has been hit by this, including myself.
I actually went one step further and analysed the circuit generated
by Synopsys. My conclusion agrees with the rest, the circuit should
work in silicon but the simulator has problem in putting the flip-
flops in the reset state. In my case, it was actually due to the
limitation of the modelling. For example, in one case:
There was a MUX in front of a D flip-flop and the select line of the
MUX came from the output of the D flip-flop. The simulator assigned
an 'X' to the Q output of the flip-flop during startup. Because of that
the output of the MUX got an 'X' since its select line is at 'X'.
Probing further, I found that when I activated the synchronous reset
input, both data inputs of the MUX were fed with '0'. If the model for
the MUX was more intelligent, it should output a '0' in this case
rather than an 'X' although its select line is at 'X'.
In the end, I resorted to asynchronous reset or ended up tweaking the
synthesized circuits to satisfy the simulator.
Bambang Gunadi, Senior IC Design Engineer
Silicon Systems, Inc., Singapore Design Center
( Post 109 Item 2 ) ---------------------------------------------------------
From: kenr@storage.tandem.com (Ken Rose)
Subject: Re: Problems Inferring Muxed-D Flip-Flops ( Post 108 Item 3)
Jeff Flieder writes:
> Subject: Problems Inferring Muxed-D Flip-Flops
>
> John,
> I am currently using Motorola's MDA08 synthesis library and I am
> having trouble getting Synopsys to infer a muxed-D flip/flop. The
> following is an exerpt of code from one of my models:
>
> always @(negedge ph1 or negedge iresetbx)
> begin
> if (!iresetbx)
> ppdir = 6'b0;
> else if (!(enpddrx | wrbx))
> ppdir = iimbus;
> end
>
> This synthesizes to two components per bit, a MUX2H and a DFFRP. These
> components are a 2-input mux and a D flip/flop with asynchronous
> reset.
I can see at least one problem here. Assuming this code fragment is
copied correctly, the code doesn't tell synopsys what to do if neither
if condition is satisfied. Normally, in this type of statement synopsys
should be inferring a latch.
Additionally, if you want a f/f with asynchronous clear, this is not the
recommended syntax. You might want to peruse the section on register
inference in the "HDL compiler for Verilog Reference Manual".
Ken Rose, Tandem
- - - - - - - - - - - - - - - - - - - - - - - -
From: rm@hoy.nsc.com (Robert Marshall)
Subject: Re: Problems Inferring Muxed-D Flip-Flops ( Post 108 Item 3)
IN ESNUG 108, Jeff Flieder writes:
>Has anyone had luck in inferring muxed-D flip/flops ? If so I would
>appreciate any help. Thanx in advance, and happy synthesizing.
I can't give you a definitive answer on this one, but we did look at it a year
or so back as we were interested in seeing how synopsys would cope with
internal scan-path logic.
We (with some help from Synopsys) couldn't find a way to get synopsys to use
muxed-D f/fs, other than by instanciating them.
One avenue you could explore is the synopsys Test Compiler product, which WILL
synthesise muxed-D f/fs, but I do not think that it is able to do so under the
direction of the initial HDL code.
Robert Marshall, Telecom Products Group,
National Semiconductor, Scotland
- - - - - - - - - - - - - - - - - - - - - - - -
From: brucel@zulu.sps.mot.com (Bruce A. Loyer H2-451)
Subject: Re: Problems Inferring Muxed-D Flip-Flops ( Post 108 Item 3)
Dear Jeff;
I am also using the MDA08 library and I have seen it use the muxed flops.
Are you setting any contraints? Until you do, synopsys has no reason to
change the original circuitry which has a flip-flop and a mux.
Bruce A. Loyer, Motorola
( Post 109 Item 3 ) ---------------------------------------------------------
From: lewis@protocol.zycad.com (Jim Lewis)
Subject: Response to posting 107 #3 and 108 #3
John,
The problems described in posting 107 Item 3 and posting 108 Item 3
"Problems Inferring Muxed-D Flip-Flops" and "problems generating synchronous
resets w/ SYN 2.2b" seem to have a lot in common. The synthesis tool does
not see the desired structure since there is other combinational logic clouding
the issue.
The solution to this problem is to separate the functions being coded. The
following is a procedure for accomplishing this:
* Identify the desired function.
* Code it separately in the HDL
* In VHDL enclose the function within a VHDL Block Statement.
* When compiling the design, separate the VHDL Block into a
hierarchical block using group -hdl_block
Following this procedure I recoded the VHDL with the following:
library synopsys ;
use synopsys.types.all;
use synopsys.arithmetic.all;
entity ramcnt_fix is
port(
reset : in mvl7; -- sync reset
ck455 : in mvl7; -- master clock
inc_ram : in mvl7; -- increment enable
ld_ram : in mvl7; -- load enable;
ld_addr : in mvl7_vector(14 downto 0); -- initial address
addr : out mvl7_vector(14 downto 0) -- ram address
);
end ramcnt_fix;
architecture behaviour of ramcnt_fix is
constant ACTIVE : mvl7 := '1';
constant DISABLE : mvl7 := '0';
constant ZERO_14 : mvl7_vector(14 downto 0) := "000000000000000" ;
constant ONE_14 : unsigned(14 downto 0) := "000000000000001" ;
signal count : mvl7_vector(14 downto 0);
signal cnt_mux : mvl7_vector(14 downto 0);
begin
MUX : process ( ld_ram, inc_ram, ld_addr, count)
begin
if ld_ram=ACTIVE then
cnt_mux <= ld_addr;
elsif inc_ram=ACTIVE then
cnt_mux <= mvl7_vector (unsigned (count) + ONE_14) ;
else
cnt_mux <= count ;
end if;
end process ;
CNT_BLK : block
begin
cnt: process
begin
wait until ck455='1' and ck455'event;
if reset='0' then
count <= ZERO_14;
else
count <= cnt_mux ;
end if;
end process;
end block ; -- CNT_BLK
addr <= count; -- inout's conflict with other tools
end behaviour;
Then I compiled the design with the following:
read -f vhdl sync_rst_fix.vhd
group -hdl_block CNT_BLK
compile
Now the synchronous reset goes directly to an and gate that is before the
register. This may increase the critical path though. It is possible to
use the "group -hdl_block" with processes, but there are cases where it did
not work with previous versions of the tool (I don't know if I tried it with
2.2b or not).
The following applies to posting 108 Item 3. I don't know verilog (yet),
but the concepts are the same. What I would try is to replace the
expression (!(enpddrx | wrbx)) with a new signal/variable that is outside of
this process/module. Then use the group -hdl_block with this process/module
to isolate it from the variable.
These techniques were very successful in managing critical paths when
we synthesized some chips using the ACTEL FPGA library.
Hope this helps,
Jim Lewis, Protocol, - the Design Services Division of Zycad
( Post 109 Item 4 ) ---------------------------------------------------------
From: dtran@vertex.com (David Tran)
Subject: Generating constraint files with 3.0a
I seem to have problems characterizing and generating the correct constraints
using dc_shell 3.0a. After doing:
current_design = top
characterize -constraint U1
current_design = design_U1
write_script > outfile
The outfile file has good information on the inputs but no "set_output_delay"
and no "max_delay" for any of the outputs.
Anybody has any idea what's going wrong?
David Tran, Vertex
- - - - - - - - -
Reply from jcooley@world.std.com (John Cooley)
In Post 91, there's a detailed description of exactly what switches effect
which constraints when one characterized a module using Synopsys 2.2b
- whether this analysis is still valid for Synopsys 3.0a, I know not.
If it is, Post 91 will tell you all you need to know. - John
( Post 109 Item 5 ) ---------------------------------------------------------
From: [ Someone who wishes to remain anonymous ]
Subject: 3.0 bugs?
John:
It is best that I now remain anonymous, but I thought some of the things that
are showning up in 3.0a might be of interest to others.
1. In VHDL the construct
library foo_lib;
use foo_lib.foo.all;
worked in the 3.0 beta release, but the same code that compiled under
3.0beta now produces errors under 3.0a.
If you use the report_design_lib -package, you will see the library and
the file, but you cannot use the library contents.
2. In VHDL Synopsys creates an error message called "library aliasing error"
when it becomes confused about the paths used to describe a library
(i.e. if you call the library work and foo_lib in the same e/a while
working in foo_lib). This is fine (although one of their simulator
competetors works with this setup), but when a file compiles in 3.0beta and
not in 3.0a, then I think that is a problem.
Basically for VHDL the 3.0 product is improved, but still has some strange
anomalies. Please remember don't use my name it's a political issue!
|
|
