Editor's Note: Synopsys just announced that it's going to sell a tool
called DesignPower that's to be used to do probabalistic power analysis on
switching CMOS type designs. (It's sort of like a "power" equivalent of
a static timing analyzer -- you throw vectors at the design in this tool
and it looks at what gates switched and what didn't from a power point of
view.) I'm very excited about this -- not the product, but what it
signifies -- Synopsys is going to start looking at power as a user
controllable constraint to synthesis! Cool!
- John Cooley
the ESNUG guy
( ESNUG 195 Item 1 ) ---------------------------------------------- [9/94]
Subject: (ESNUG 194 #3) Hold Problems On A Single FF Breaks Gate Array Size!
>When I use Design Compiler to fix hold times I run into a problem with
>feedback loops. Synopsys adds the clock skew into the path to determine
>how much hold time is needed. This is fine if the path starts and ends
>at differant devices, but wrong when the path is a feedback path in a
>statemachine, or on a MUXed flop.
>
>The effect of using clock skew in the hold requirement for a path that
>begins and ends on the same device in our case caused 6 extra un-needed
>buffers to be added into the feedback loop of every flop. This adds 20%
>to the final gate count of my design -- pushing it up to the next higher
>size gate array! Any idea how to get around this bug?
---- ---- ---- ----
From: stropparo@pasta.enet.dec.com (Peter A. Stropparo)
John, I have been enlightened! All you need to do is say the SECRET PASSWORD
and Synopsys will behave correctly. The SECRET PASSWORD is:
"tvc_uncertainty_handle_self_loops = 1"
This generates the following warning:
Warning: Defining new variable
'tvc_uncertainty_handle_self_loops'. (EQN-10)
which can be ignored. With this hidden variable set Synopsys will not fix
hold times in feedback loops.
- Peter A. Stropparo
Digital Equipment Corp.
( ESNUG 195 Item 2 ) ---------------------------------------------- [9/94]
From: mhenry@p05.dasd.honeywell.com (Matthew Henry)
Subject: DesignWare Is A Carefully Crafted Overpriced Marketing Ploy
John,
The DesignWare commentary posted in ESNUG 192 struck a chord in me. I
am licensed only for the standard "foundation" DesignWare libraries but have
evaluated several of the licensed components. My honest impression is that
DesignWare is a carefully crafted marketing ploy by Synopsys that is
undoubtedly overpriced or undervalued. The following points elucidate how I
can make so bold a claim:
1. One of the primary advertised benefits of DesignWare is that it
contains hooks into the synthesis process that allow automatic selection
among two or more alternative speed vs. area implementations based on
overall design constraints. This is fine, but that capability has
significance for arithmetic logic and little else. (Notice that the most
recent DesignWare libraries do not include area & speed implementations.)
Furthermore, it is an unusual circumstance in which the ASIC designer does
not know ahead of time which implementation is best suited to his circuit.
I have never guessed wrong about when Synopsys will choose a ripple versus
a carry-lookahead adder, for example.
2. The SynALU and SynAdvMath libraries are probably (I'm guessing) the
most popular licensed DesignWare because they promise faster arithmetic.
I've evaluated the "fast carry-lookahead" implementation of the adder
using two different ASIC libraries. In comparison to the standard
carry-lookahead implementation, I found for some cases a degradation in
speed, and in some cases a 2% to 4% speedup at the expense of 10% to 20%
in area. The Wallace tree multiplier is quite useful (and the vector
adder is a minor variant of this), but I was able to write my own
parameterized Wallace tree generator which, when coupled with a standard
Synopsys carry-lookahead adder, outperforms the DesignWare version.
3. DesignWare has at its roots the motivation of design reuse, and few
would dispute that reuse represents the single largest benefit to
productivity. But who owns the intellectual property for reused
components such as a microsequencer, EDAC unit, or programmable timer?
Synopsys does. A significant aspect of reuse is portability. DesignWare
is ASIC-library portable, but it is not simulator portable. In addition,
it contains no facility for the user to manually tweak a function for
his own needs -- naturally, there is no source code.
4. What can be the rationale for charging a customer 15% annual maintenance
for a library that does not change? If Synopsys devises a new DesignWare
component, do they add it to an existing licensed library to give the
user some reward for his maintenance? No, they create a new DesignWare
library that must be separately licensed and maintained! So maintenance
merely pays for the assurance that a DesignWare element will work with a
new release of Design/VHDL/Verilog Compiler. If DesignWare is founded on
unsupplied HDL source code, this really represents maintenance on the HDL
Compiler. On the other hand, if DesignWare is founded on pre-configured
netlists of Synopsys primitives, then re-verification of a DesignWare
library should only be necessary if the Synopsys primitive set expands
(unlikely, it seems). Either way, the customer is not getting much for
his maintenance.
5. Is there a genuine need to have multiple DesignWare licenses? Do the
tools lock up a license for an extended period of time? Can they even be
effectively shared? It seems that one license for a given DesignWare
library should be sufficient for all but the largest sites.
6. (I will happily concede that DesignWare makes tremendous sense for FPGAs,
where some functions must be very cleverly mapped into coarse-grained
architectures.)
The bottom line is that I feel most users are much more appropriately served
by initiating their own reuse strategies based on source code than on
DesignWare. Perhaps a more appropriate niche for DesignWare is in
synthesizable cores of complex standard devices such as microcontrollers,
SCSI interfaces, or the recently announced PCI interface.
- Matt Henry
Honeywell, Defense Avionics Systems
( ESNUG 195 Item 3 ) ---------------------------------------------- [9/94]
From: abdoo@adtaz.sps.mot.com (David Abdoo)
Subject: A Workaround To Force DC To Use FF Qbar Outputs
Hi John,
The library to which I am synthesizing has D Flip-Flops which have only a
'Q' output as well as DFF's with both Q and Qbar. (This is to save area if
only Q is needed.) I shall refer to them herein as 'DFF_Q' (DFF with
only a Q output) and 'DFF_Q_QB' (DFF with both Q and Qbar).
I noticed that the netlist produced by synthesis sometimes used a DFF_Q
followed by an inverter for cases where a DFF_Q_QB would have been more
efficient (both for area and timing). The problem seems to be that the
Design Compiler picked the DFF_Q before it realized that it also needed Qbar.
(Once it was mapped to a DFF_Q, it seems to have no way of figuring out
that it could swap to the use of a DFF_Q_QB.) Here's the Verilog behavioral
code I used to directly imply that it needed both Q & Qbar:
always @ (posedge CLK) Q <= D;
assign Qbar = ~Q;
// Note: Q and Qbar are used as inputs in the modules that follow!
some_other_module instance_name (Q, Qbar, ... );
As I commonly use two (or occasionally more) 'compile' commands in the
synthesis process, and the last compile is incremental, my solution to this
not-using-Qbar problem is to prevent Design Compiler from picking the DFF_Q
until the last compile:
(specify usual area and timing constraints here first)
dont_use DFF_Q
compile -map_effort medium /* maps to all DFF_Q_QB */
remove_attribute DFF_Q dont_use
compile -map_effort high -incremental
I strongly suggest that if you are going to try this, you write out your
netlist after each compile and compare the results.
If someone can explain to me (briefly) why Design Compiler did not know to
switch from DFF_Q + inverter to DFF_Q_QB, I'd like to understand - especially
if it was due to something I did wrong. Other constructive feedback and/or
questions are also welcome.
- Dave Abdoo
Motorola, Tempe, AZ
( ESNUG 195 Item 4 ) ---------------------------------------------- [9/94]
Subject: (ESNUG 193 #4) Interpreting Overlapping Verilog Casex Sectors
>Does Design Compiler define how they implement overlapping selectors in a
>Verilog "casex" statement? For example:
>
> casex(var)
> 3'b1xx: action1;
> 3'bx1x: action2;
> 3'bxx1: action3;
> 3'b000: action4;
> endcase
>
>This is the syntax one would like to use for a one-hot state machine. Does
>Synopsys ALWAYS generate the correct logic? If so, where is it documented?
---- ---- ---- ----
From: asic@netcom.netcom.com (Henry George Berkley)
In chapter 5 of HDL Compiler for Verilog Reference Manual:
"The first case-item that evaluates to 'true' determines the path.
All subsequent case-items are ignored, even if they are 'true'."
If you intend a one-hot state machine, use the '//synopsys parallel_case'
directive for optimal logic. ESNUG 193 Item 3 presents an excellent
example of a one-hot construction.
- Henry George Berkley
Electronic Consulting
P.S. Since the parallel_case directive logic behaves differently than
simulation, consider adding checking code:
//synopsys translate_off
begin : check_block
integer i, n;
n=0;
for ( i=0; i<3; i=i+1 )
if ( var[i] == 1'b1 )
n=n+1;
if ( n>1 )
$display("ERROR: var Bad one-hot state");
end
//synopsys translate_on
---- ---- ---- ----
From: martint@sei.com (Martin Taylor)
In the case syntax that the user orginally gave you would not get efficient
one-hot encoding. You would get an:
if then
else
else
else
Using the code example as supplied, the cases are evaluated in order until
one is found to be true. (To get one-hot encoding use the "// synopsys
parallel_case" directive. But be warned: If you use the parallel_case
directive then it is up to the engineer to guarantee *by*design* that only
one of the cases will evaluate true at any time.)
By the way; it's better to use casez than casex as x's in a casex are treated
as don't cares which can mask design errors.
- Martin Taylor
Silicon Engineering Inc.
---- ---- ---- ----
From: sgolson@trilobyte.com (Steve Golson)
In ESNUG 193 #4, the user wants to build a one-hot state machine, and wonders
if the following construct is guaranteed to work in Verilog:
casex(var)
3'b1xx: action1;
3'bx1x: action2;
3'bxx1: action3;
3'b000: action4;
endcase
A better idea is to use a "backwards" case statement:
case (1'b1) // synopsys parallel_case full_case
var[2]: action1 ;
var[1]: action2 ;
var[0]: action3 ;
default: action4 ;
endcase
This will do exactly what you want. (For more info see my paper "State
machine design techniques for Verilog and VHDL" in the most recent issue
of the Synopsys Journal of High-Level Design.)
- Steve Golson
Trilobyte Systems
( ESNUG 195 Item 5 ) ---------------------------------------------- [9/94]
From: gordonb@bnr.ca (Gordon G. Buchanan)
Subject: How Does One Trick Design Compiler Into Invoking Complex Cells?
Fellow Synopsys Slaves,
In order to improve routability on a particularly congested ASIC layout we
are proposing to add complex cells to the library (such as a quad scanable
FF with common enable, clock and scan pins). Note: when the FF is "disabled"
it retains the previous Q & QC values after the clock edge - we have lots
of examples of this function throughout our synchronous design.
The problem is: How do we get Design Compiler to actually use such a FF or
any other complex cell without hand instantiating it? Anyone out there
found a way to do this?
- Gordon Buchanan
BNR, Ottawa
|
|
