( Post 110 Item 1 ) ----------------------------------------------------------
From: uunet!uranus!splinter!flieder (Jeff Flieder)
Subject: ESNUG Post 109, item 2
John,
I thought I should respond to post 109 item 2 so that other Synopsys
users do not get confused by it. Ken Rose thought that my code
fragment would infer a latch, but in fact it does infer a flip/flop
with asynchronous reset.
The Synopsys Verilog manual shows the following syntax for a
register:
always @(posedge clk or posedge reset_condition1 or negedge
reset_condition2) begin
if(reset_condition1) begin
/* Asynchronous inputs to f/f that are triggered
by reset_condition1 go here */
end
else if(!reset_condition2) begin
/* Asynchronous inputs to f/f that are triggered
by reset_condition2 go here */
end
else begin // no event expression in this else clause
/* Assignments to f/f D inputs go here */
end
end
and my code said:
always @(negedge ph1 or negedge iresetbx) begin
if (!iresetbx)
ppdir = 6'b0;
else if (!(enpddrx | wrbx))
ppdir = iimbus;
end
This is the same thing, with the exception that my design has only a
negative edge reset, and no positive edge reset. The segment of my
code that corresponds to "/* Assignments to f/f D inputs go here */"
is the else clause:
if (!(enpddrx | wrbx))
ppdir = iimbus;
since there is nothing in the definition that says that the
assignments to the f/f D inputs cannot be a conditional assignment,
this is valid syntax. This is the part of the code that infers a mux
on the data input, and the part that should infer a muxed D f/f.
I have been using this construct successfully for about 6 months
now, so I just wanted the ESNUG community to know that it was indeed
proper f/f (or register) inferrence.
Jeff Flieder, Senior Engineer I.C. CAD Development
Ford Microelectronics, Inc. Colorado Springs, CO 80921-3698
( Post 110 Item 2 ) ----------------------------------------------------------
From: erstad@pan.ssec.honeywell.com (David Erstad)
Subject: Re: Problems Inferring Muxed-D Flip-Flops ( Post 108 Item 3)
Jeff:
We've inferred muxed flip-flops. I believe this was at 2.2b, but
I don't have the data handy. This would have been from a VHDL RTL
description. I don't remember if we were able to do this sometimes
or always.
Depending on the library in use, a timing constraint might help. If
you're using a CMOS sea-of-gates type ASIC library, a discrete
mux plus a flip-flop may not provide area savings over the
muxed flip-flop, and could possibly have a small penalty (depending
on how the vendor has modeled the library; a common gate count
or site count measurement will not account for the additional
wiring in the former approach, and in the latter approach the fact
that the wiring is part of the cell may increase area slightly. It
also depends on how the vendor does isolation and how they count
the isolation areas). If you're using a multi-bit wide structure,
too, the muxed flip-flop may look (be?) less efficient to Synopsys
than decoding the select line once and using AND/OR gates rather
than a Mux. The performance will almost always be better with the
muxed flip-flop, though.
One issue to watch out for if you're inserting something like a scan
path is that the resulting logic may not be simulatable. This is
analgous to the synchronous reset problem which has been discussed
over the past week. The logic may be boolean-correct but may
simulate as all X's.
Dave Erstad, Sr. Principal Design Engineer, Honeywell SSEC
( Post 110 Item 2 ) ----------------------------------------------------------
From : [ The Engineers in Synopsys Research & Development ]
Subject: Post 108, item 2 Discussion about Synchronous Resets
Juno <heine@cortez.etdesg.trw.com> writes:
> The problem is solved in 3.0a with a compile variable called
>
> compile_preserve_synch_resets [sic]
>
> It is defaulted to false, change it to true, then compile - works like
> a charm! The only other solution I can think of is to use their new design
> ware products and produce a synchronous resetable flip flop for the design
> compiler to choose, then your reset logic will always be with the flip-flop.
First the bad news...
DesignWare is not a very good answer to this problem. In the current
release, non-combinational designware parts (parts containing flip-flops)
have to be instantiated. They are not inferred from HDL behavioral
statements.
I assume this solution would prove too cumbersome for most people.
And the good news...
compile_preserve_sync_resets can solve the problem. The manual
page for this variable is very comprehensive, but there are a few
important points to mention:
+ You must set the variable true for your first compile after reading
your HDL. The variable will not work once your flip-flops have
been mapped to your target technology. There is a way to unmap
flip-flops. See the manual page for details.
+ Another thing to consider is that using this variable may slow down
your circuit. Flip-flops with synchronous resets may be slower.
If your technology library does not have the correct kind of
flip-flop, an extra gate will be inserted before your flip-flop.
+ Keep in mind that only synchronous sets and resets are handled. A
set or reset causes an individual flip-flop to take on either a '1'
or a '0' value. Anything else is not considered to be a set or reset.
The following is handled:
if (reset) if reset then
State = 4'b0110; State <= "0110";
else begin else
.... ....
end end if;
But this is not:
if (reset) if reset then
State = A & B; State <= A and B;
else begin else
.... ....
end end if;
+ Hope this information is useful.
Note: The original spelling of the compile_preserve_sync_resets was incorrect.
"sync" should not have an "h".
If you have questions on the information on this post, please post it to ESNUG
first. We'll be watching for any inquiries there. Thanks!
- Synopsys R & D
|
|
