Editor's Note: Dr. Vince Bello, the father of averaged SMPF SPICE models,
recently forwarded me the e-mail write-up of how to join a really cool
undertaking -- the SETI@home project. Essentially, SETI is the Search
for Extra-Terrestial Life and the people doing it have a massive amount
of raw radiotelescope data to process. Their solution? Distribute PC and
workstation screensavers that process chunks of data when your computer
is idle. Novel idea! And currently over 500,000 computers are partaking
in this project. So, instead of letting your unused CPU cycles go to
waste, I urge you to go to http://setiathome.ssl.berkeley.edu and let that
unused processing power go towards a really cool project! Nanoo! Nanoo!
- John Cooley
the ESNUG guy
( ESNUG 321 Subjects ) -------------------------------------------- [6/8/99]
Item 1: ( ESNUG 317 #7 ) WARNING! Synopsys Tcl Messes w/ DC_shell Scripts
Item 2: How Do You Handle Embedded Asynchronous Memory Timing In DC ?
Item 3: ( ESNUG 319 #8 ) User Disgust At Avant! Charging $47K For VeriLint
Item 4: ( ESNUG 320 #3 ) Actually, We Found Equivalency Checking Useful
Item 5: ( ESNUG 317 #4 ) Tricking DC Into Buffering Every Output Port
Item 6: ( ESNUG 319 #2 ) Odd Question Marks In My Synthesis Log Files?
Item 7: Help! DC's Wrecking My Scan Chains In Incremenatial Compiles!
Item 8: ( ESNUG 316 #3 320 #10 ) Transmission Gates Ruin Fault Coverage
Item 9: ( ESNUG 318 #10 319 #12 ) Want To Remove Tied-off/Dead Flip-flops
Item 10: ( ESNUG 319 #3 ) Accessing Intermediate Bits In Module Compiler
( ESNUG 321 Item 1 ) ---------------------------------------------- [6/8/99]
Subject: ( ESNUG 317 #7 ) WARNING! Synopsys Tcl Messes w/ DC_shell Scripts
> Q: If I only want to use DC_shell, do I have to re-write my scripts?
>
> A: No. dc_shell will function the same it did before. You only have to
> worry about converting scripts if you want to use Tcl.
>
> - [ Erich of Synopsys ]
From: Robert Wiegand <rwiegand@mailsrv.ensoniq.com>
John,
There is one subtle exception. The .synopsys_dc.setup file in the
$SYNOPSYS/admin/setup directory MUST be in tcl-s format, as well as any
scripts included from here. I add the following line to the end of the
setup file in the $SYNOPSYS/admin/setup directory:
include synopsys_root + "/admin/setup/.synopsys_dc.setup.global"
I use the global setup file to set up a shared Synopsys cache for all
users, grab information from Unix variables to set library and project root
directory variables for assembling search path strings, set global aliases
and settings across all users and projects, and apply any version specific
bug fix hidden variable workarounds.
I found out about the tcl-s requirement the hard way when I was in the beta
program for this version. It normally takes me about 5 minutes to get an
existing project up and running a new version, but this nasty suprise took
me about 4 hours to get past. Since I had no tcl documentation (is there a
"TCL for Dummies" out there somewhere?), and the conversion utility didn't
support a most of constructs I use (including COMMENTS!), I was left to
hack at it using examples from the PrimeTime documentation as a guide.
Unfortunately, I was not able to continue beta testing since I was in the
middle of several critical mass projects at the time. I hope the script
conversion utility has improved since then.
- Bob Wiegand
Ensoniq, Corp. Malvern, PA
( ESNUG 321 Item 2 ) ---------------------------------------------- [6/8/99]
From: navin@dalsemi.com (Venkata Navin)
Subject: How Do You Handle Embedded Asynchronous Memory Timing In DC ?
John,
I have the following circuit in my design:
---------
| |--------
|Flop | |
Clk | | ------------ ------------
------- | | | | |
| --------- ---------------- WE | Async. |
| | Combinational|--------| RAM |
------------------------------| Logic | | |
---------------- ------------
WE is the write enable pulse.
As far as I know, DesignTime is going to look at all paths between 2
flip-flops. Now, the RAM library file has all the setup and hold timings
of the address and data of the asynchronous RAM with respect to the write
enable pulse. How does DC try to meet these? Since WE is not defined as
a clock, I think DC would treat the RAM as a combinational element and not
a sequential element. So, would it ignore all the setup and hold
requirements with respect to WE?
Also, the combinational logic generating the WE pulse is don't touched
and instantiated because WE is generated with both edges of the clock.
--------- ---------
| | | |
Clk --------- --------- --------
WE ----------- ------------- ----------
| | | |
----- -----
Is the only way to check this using dynamic simulation? Or would I need to
define WE as a clock? If so, it's not periodic, so how do I go about it?
I guess my question is more general. How do you handle embedded
asynchronous memory timing if the WE is generated by both edges in general?
- Venkata Navin
Dallas Semiconductor
( ESNUG 321 Item 3 ) ---------------------------------------------- [6/8/99]
Subject: ( ESNUG 319 #8 ) User Disgust At Avant! Charging $47K For VeriLint
> Now Avant! has purchased InterHDL and sent a fax to all Verilint customers
> offering to "upgrade" the license to flexlm and remove the 27 minute timer
> -- all for only $10K and $7K in annual maintenance. This for a tool that
> originaly cost less than $10K. That's screw number 2. If you want to buy
> the tool new from Avant! the list is $47K!!! Screw 3. Sheesh, that's
> more than a verilog license. Who are they kidding? This thing is a
> SYNTAX checker.
>
> By the way: if you decide not to upgrade, they'll give you a permanent key
> for the old tool - forever locked to the machine you specify -- they'll
> never allow a future rehost! Screw 4.
>
> What a way to run a business.
>
> - [ I Am Sparticus ]
From: Tom Loftus <tloftus@hns.com>
John,
Although perhaps not quite as strongly as Sparticus, I also object to the
way Avant! is handling the InterHDL/Verilint "upgrade". We have three of
the hold time licenses and have found them useful in our design flow.
I have tried to explain to Avant! that the tool is not a $45K tool, but
they seem unmoved. I wonder how many of their customers are really going
to take them up on their offer to upgrade, and how many are going to go
with a permanent key, drop maintenance, and not give them another dime?
It is particularly annoying that they want to charge maintenance based on
the $45K price of the tool. This means our yearly maintenance would be
almost $7,000 --- what we paid for each license originally.
It looks to me like their strategy is to move their Verilint customer base
to their Nova-Explore-RTL product. This product requires you to run
interactively in a multi-window GUI type environment. Just like every
other EDA vendor, they want to have the Holy Grail of EDA Software. That
is, a tool that a designer is going to sit in all day long while doing code
development and debug. I don't think Nova-Explore-RTL is it.
- Tom Loftus
Hughes Network Systems
---- ---- ---- ---- ---- ---- ----
From: Andrew Frazer <Andy.Frazer@idt.com>
John,
Sparticus discussed two options to working with Avant! to handle our
existing Verilint licenses: get a permanent license or upgrade to a
non-timed FlexLM configuration.
While I would jump on the upgrade option ($10k to get rid of the 27-minute
timer and the Elan license manager), you should also consider the third
option: upgrading to their Nova-Explore-RTL. Nova-Explore-RTL is everything
that Verilint wasn't. It does more complete syntax and error checking,
has a 10X better user interface, and is scheduled to have some important
enhancements that I may not be able to discuss openly (so I'll keep my
mouth shut).
- Andy Frazer
IDT Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: [ The Cat In The Hat ]
John - please sign me anon.
Funny how no one bought more than one copy of Verilint despite that 27
minute limitation -- you'd think they found a way to get around it or
something.....
Anyway - being a proponent of capitalism, I feel no more 'screwed' by
the outrageous prices charged by Avant! for Verilint than I do for the
prices Synopsys charges for <fill in the blank>. (Remember the good old
days when you could buy an entire suite from COMPASS and get change back
from your $100K?) Anyway, I think this will play out one of three
ways: Maybe Verilint is really worth the money, or maybe someone will
develop a competitor and sell it for less, or (more likely?) the Verilog
linting function will end up as LINUX-like freeware. Seems like
someone could write a basic linting tool that accepts "violations to
test for" specified in a user-friendly way, then we could all add tests
to it as desired. Perhaps some UNIX utility does something like this
already? I suspect that no one was motivated to do any of the above
when you could buy Verilint from nice people for only $7K, but now, we
shall see....
- [ The Cat In The Hat ]
---- ---- ---- ---- ---- ---- ----
From: [ The Cheshire Cat ]
John, Please keep me anonymous.
You can get around the 27-minute timeout for Verilint by establishing an
account "lintuser", giving everyone the password, and requiring everyone
to log in as "lintuser" to use Verilint.
- [ The Cheshire Cat ]
[ Editor's Note: This price gouging of charging $47K for interHDL's/
Avant!'s VeriLint may spur a real search for alternatives. The tool
that comes to mind for me is 'HDL LINT' from Veritools. 'HDL LINT'
sells for $3K a copy (and gets cheaper if you buy more copies) and is
said to run 700-800 lint checks. It has *no* cheesy usage timers
involved. Plus it has a Perl interface so users can customize it and
do style checking. (See http://www.veritools-web.com ) My question
is "has anyone used 'HDL LINT'? Is it a viable alternative?" - John ]
( ESNUG 321 Item 4 ) ---------------------------------------------- [6/8/99]
Subject: ( ESNUG 320 #3 ) Actually, We Found Equivalency Checking Useful
> Here's where we were coming from when we were looking at Chrysalis. We
> were designing a 1 million gate design that had multiple clock zones
> ranging from 75 MHz to 180 Mhz with about a third of the design being
> RAM. This meant we had roughly 700,000 gates of custom logic to test.
> Like everyone else doing these big, massive ASICs, we were looking for
> alternatives to the SLOW task of running gate level functional vectors.
> We were looking to group a couple approaches to accomplish this task
> such as static timing analysis with "equivalency checking". As I
> recall, to do the equivalency checking between RTL and gates, Chrysalis
> forces you to have to break up your design in 5K to 10K gate blocks.
> Equivalency checkers do a sort of voodoo synthesis on RTL (to convert it
> to equations) and on gates (to convert that to equations) and then it
> compares both sets of equations. Go beyond 10K gates, and the tool
> chokes. So, doing the math, using Chrysalis meant we'd have to do
> comparisons of roughly 100 'blocks'. Seemed like a lot of work for very
> little return. Additionally, the indications were, that equivalency
> checking between RTL and GATEs runs very slow.
>
> The place where I can see equivalence checkers helping is with testing
> gates-to-gates technology translations of design -- like porting a 0.35
> um design to 0.18 um, or from vendor A to vendor B-- but we weren't
> doing that, so Chrysalis was pretty much useless for us.
>
> - Don Mills
> LCDM Engineering South Jordan, UT
From: "Anders Nordstrom" <andersn@nortelnetworks.com>
Dear John,
Having done an 850k gate design with very little gatelevel simulation I have
do disagree with Don that Formal Verification is not useful. RTL-to-gate
verification is certainly the most tedious task and you do have to do it in
pieces but the alternative, gatelevel simulation, isn't very pretty either.
We did equivalence checking on the same modules we did synthesis on and
they ranged in size from 5k to 30k gates in Chrysalis.
I agree with Don that at this point it is most useful at gate-to-gate
comparisons. This is not a small benefit though. You have to verify
insertion of test logic, clock trees, buffer trees and in-place
optimizations. At this point in the design cycle you can verify the
enire gatelevel netlist at once in a reasonable time whereas gatelevel
simulations with the full chip take days.
- Anders Nordstrom
Nortel Networks Ottawa, Ontario, Canada
---- ---- ---- ---- ---- ---- ----
From: [ Snoopy, Charlie Brown's Dog ]
Hi John,
Can you please keep me anonymous as we are currently evaluating some
formal verification tools.
It must be a while since Don used Chrysalis.
We've recently done an evaluation of Chrysalis Design verifier and it had
no problems doing an RTL-to-Gate equivalence check on a 500K design which
was broken up into 100K gate blocks. For Gate-to-Gate, the tool was able
to handle the entire design at once, without breaking it up into smaller
blocks. On a Sparc Ultra-2:
The RTL-to-Gate equivalence check took approx 3.5 hours.
The Gate-to-Gate equivalence check took approx 2 hours.
These are pretty impressive figures on their own. Even more so when you
take into account the users's inexperience with the tool and the fact that
the machine we used for the benchmark was not particularly powerful.
- [ Snoopy, Charlie Brown's Dog ]
---- ---- ---- ---- ---- ---- ----
From: Mike Bartley <bartley@bristol.st.com>
John,
Maybe it is time for Don Mills to look at equivalence checking again.
I am a verification manager at STMicroelectronics and also responsible for
equivalence checking for a large part of STMicroelectronics. (I am also
on the Boston SNUG Tech Committee, which is how I got your email, and I
couldn't resist the challenge offered by Don's posting).
At ST (and quite a few other companies now) equivalence checking is just
like air. Don is right that gate-gate proofs are easier and that technology
porting is an obvious application. But there are a number of other
applications. Specifically, what does RTL-Gate buy you?
- faster checking of gates than simulation does
- more complete checking of gates than simulation does
- earlier checking (i.e. you can check just a block rather than wait
for a simulation environment to run it in -- yes, this is just a flow
issue, but we find equivalence checkers provide an enhanced flow that
allows more checking at lower levels, finding problems earlier.)
We have automated most things here at ST -- so designers can just type a
single, short command to run their proof.
On the flip-side -- there are capacity problems -- but not as bad as you
suggest. Equivalence checkers work hierarchically, so large designs aren't
a problem if they have matching hierarchy. The main problems are:
- RTL to gates if there is not matching hierarchy. But flow can solve
this. Use an RTL to hierarchical-gates proof, then a hierarchical to
flat gates proof,
- RAM's remain hard. We still use simulation to do this, but we will
probably start to use symbolic simulation pretty soon.
- large arithmetic blocks are also hard. Most equivalence checkers run out
of steam on RTL-gates at around 17 or 18 bits.
- re-timed designs and duplicated logic (e.g. duplicating state for
physical considerations) can cause problems.
and of course there may be others that I don't see.
In conclusion, equivalence checkers are pretty mature now and are being
used by a lot of companies on a lot of designs. Currently ST has about 10
on-going designs that use Formality as part of their flow with only a few
problems.
- Mike Bartley
STMicroelectronics Bristol, UK
( ESNUG 321 Item 5 ) ---------------------------------------------- [6/8/99]
Subject: ( ESNUG 317 #4 ) Tricking DC Into Buffering Every Output Port
> I would like to force design compiler to put a buffer on all output
> ports, and to not use the buffered output internal to the module. The
> obvious way to do this would be to do a
>
> set_max_fanout 1 all_outputs()
>
> but of course set_max_fanout can only be used on input ports (why???).
> I can usually get what I want with the right combination of loads and
> output delays on the output port, but there are cases where this
> doesn't always work. Ideas?
>
> - Will Leavitt
> Giganet, Inc.
From: Robert Wiegand <rwiegand@mailsrv.ensoniq.com>
John,
This has worked for me in the past: Start out by setting a max_fanout
on the design,
set_max_fanout max_fanout_number current_design
/* let max_fanout_number = 20 for example */
Then, set a fanout number on the output port equal to the max fanout of
the design:
set_load max_fanout_number -fanout_number output_port(s)
or
set_fanout_load max_fanout_number output_port(s)
It is now a design rule violation to hang any additional internal loads
on the net driving the output.
- Bob Wiegand
Ensoniq, Corp. Malvern, PA
( ESNUG 321 Item 6 ) ---------------------------------------------- [6/8/99]
Subject: ( ESNUG 319 #2 ) Odd Question Marks In My Synthesis Log Files?
> Could somebody help me to understand why I get sometime the question marks
> for a certain register in my synthesis log file. A part of the log file
> looks like this:
>
> ======================================================================
> Register Name | Type | Width | Bus | MB | AR | AS | SR | SS | ST
> ======================================================================
> cnt_reg | Flip-flop | 8 | Y | N | N | N | N | N | N
> dac_buf_reg | Flip-flop | 1 | - | - | N | N | N | N | N
> data_buf_reg | Flip-flop | 8 | Y | N | N | N | N | N | N
> mod2cnt_reg | Flip-flop | 1 | - | - | N | N | N | N | N
> sum_reg | Flip-flop | 8 | N | N | ? | ? | ? | ? | ?
> ======================================================================
>
> The register bank sum_reg got the question mark for all parameters:
>
> AR, AS, SR, SS, ST
>
> Thanks for any help.
>
> - T.P Nguyen
> Philips Semi/ASG-Microtel Eindhoven, The Netherlands
From: Oren Rubinstein <oren@gigapixel.com>
The question marks mean some of the bits get set and other get cleared.
For instance, if the reset value for an 8 bit register is 01010101.
- Oren Rubinstein
GigaPixel Corp. Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: Oleg Milter <omilter@iil.intel.com>
Hi, John,
The reason of this behavior could be, that you use part of bits in sum
vectors as asynchronous set/reset and part of bits as synchronous set/reset.
If you set hdlin_report_inferred_modules = verbose
the tool will report detailed information for each bit in vector.
- Oleg Milter
Intel Israel Ltd. Haifa, Israel
---- ---- ---- ---- ---- ---- ----
From: George Lambidakis <lambo@sei.com>
John,
The question marks are there because the register in question, "sum_reg" was
not reset to a consistent value. Some of the bits are 1 and some are 0
rather than 8'hff or 8'h00. This is annoying but has been this way for
some time.
- George Lambidakis
Silicon Engineering Inc.
---- ---- ---- ---- ---- ---- ----
From: [ A Synopsys Staff AC ]
John,
The answer to T.P. Nguyen's question is that all of the bits of "sum_reg"
are not initialized the same way. For example, the following code would
cause the elaboration report T. P. is seeing
IF (reset = '0'0 THEN
sum <= "00000001";
ELSIF (clk'event and clk = '1') THEN
sum <= foo;
END IF;
Notice that the elaboration report has an "N" in the BUS column. DC only
considers a register a "BUS" if all the bits are set/reset to the same
value under all conditions. To get more detailed information about each
individual bit set
hdlin_report_inferred_modules = verbose
This will give the set/reset information for each individual bit of each
register.
- [ A Synopsys Staff AC ]
---- ---- ---- ---- ---- ---- ----
From: "T.P. Nguyen" <nguyen@natlab.research.philips.com>
Hi John,
After some deep investigation, the reason I got these question marks is that
the sum_reg was assigned with signals of different sizes. Synopsys reported
question marks for those signals during the elaboration.
- T.P Nguyen
Philips Semi/ASG-Microtel Eindhoven, The Netherlands
( ESNUG 321 Item 7 ) ---------------------------------------------- [6/8/99]
From: Laurent Claudel <laurent.claudel@massana.com>
Subject: Help! DC's Wrecking My Scan Chains In Incremenatial Compiles!
Hi John,
I have a netlist with a scan chain inserted. Now I want to do an
incremental compile on that netlist without the Test Compiler. I've tried
to put a set_dont_touch on every register and every scan chain net (the one
which are connected to the DB input of my scannable register).
Unfortunately, this doesn't stop Design Compiler from messing around with my
scan chain since the set_dont_touch on a net applies only on combinatorial
cells connected to that net.
What happens basically is that Design Compiler is re-routing my scan chain
thru inverters to try to reduce the fanout on other critical paths. So
instead of going from Q to DB, it goes from QN to DB thru an inverter. Not
really what I want for a scan chain !!!
This scan chain wasn't generated by the Test Compiler at the first place.
If anyone has a suggestion, that would be great.
- Laurent Claudel
Massana Ltd Dublin, Ireland
( ESNUG 321 Item 8 ) ---------------------------------------------- [6/8/99]
Subject: ( ESNUG 316 #3 320 #10 ) Transmission Gates Ruin Fault Coverage
> As a former Sunrise/Synopsys Test CAE/Consultant, this issue is fairly
> common on custom designs that use fully-decoded N-input muxes. Modeling
> these with bufif1 primitives is fine for TestCompiler or TestGen. This
> is more fundamental to the stuck-at fault model & this type of circuit...
>
> ... If the decoder and mux combination can be re-modeled as a single,
> encoded mux cell, a complete set of patterns will be generated and a full
> coverage will be reported.
>
> - [ A Former Sunrise/Synopsys Test CAE/Consultant ]
From: Subhasish Mitra <smitra@CRC.Stanford.EDU>
Hi John,
It's not clear whether it is suggested that the designer replaces the
decoder and the decoded multiplexer (selector) by an encoded mux IN THE
DESIGN. If the decoder and the selector combination is modeled as a fully
encoded mux just for the purpose of testing (i.e. for the ATPG tool),
then the set of patterns generated will only test for stuck-at faults at the
pins of this decoder-selector combination -- thus, the actual stuck-at
faults at the selector select signals will not be considered -- So in that
case, the fault coverage reported will NOT be the actual fault coverage.
(Note that the actual stuck-at fault model is defined as stuck-at faults at
inputs and outputs of basic gates. Basic gates are AND, OR, AND, NOR and
inverter. Even for 2-input XOR gates a THOROUGH test requires 4 patterns
instead of 3).
Testing for select inputs of decdoed mux-es represents one aspect of the
problem. How about ensuring one-hot values on one-hot signals? This problem
may be handled if a good ATPG is used and some logic is added to ensure
one-hot values during scan-in and scan-out. BUT WHAT HAPPENS DURING A
PSEUDO-RANDOM BIST or RANDOM PATTERN TEST? Any suggestions?
- Subhasish Mitra
Stanford University
---- ---- ---- ---- ---- ---- ----
> I recommend replacing the entire mux model with a model of the cell that
> only uses ands, ors and inv's. Completely ignoring the internal structure.
> And suppress faults inside the cell. The "stuck-at" model is still valid
> at the pins of the cell.
>
> - Gary Porter
> Harris Semiconductor
From: Howard Landman <HowardL@SiTera.com>
John,
One advantage of this style of mux model (as opposed to a behavioral "if" or
"?:" model) is that it will propagate X values. (The Verilog language spec
requires an if statement to treat an X as if it were a 0.) However, there's
a subtlety that many people miss. You want it to be the case that, if your
select is X, but both data values are the same, then the output is the data,
not X. (You can trust me on this, or learn from painful experience. :-)
Therefore, your mux models need to include a "redundant" term. Here's an
example (the "a & b" term is redundant for 0-1 values):
module mux2 (z, a, b, s);
output z;
input a, b, s;
reg z;
always @(a or b or s)
begin
// redundant term to get correct behavior when s is X .
q = (~s & a) | (s & b) | (a & b);
end
endmodule
I *STRONGLY* recommend all behavioral mux models be written in this manner.
- Howard A. Landman
SiTera, Inc. Longmount, CO
( ESNUG 321 Item 9 ) ---------------------------------------------- [6/8/99]
Subject: ( ESNUG 318 #10 319 #12 ) Want To Remove Tied-off/Dead Flip-flops
> I've noticed the problem John Patty described for several years now, and
> it's only a subset of the real problem, which is Design Compiler never
> removes storage elements. I've tried connecting set, reset, clock, or
> data to force FFs or latches to constant values, and DC always kept them
> in the design.
>
> - William Liao
> MMC Networks
From: "Paul.Zimmer" <paul.zimmer@cerent.com>
John,
This is not so. In fact, this has been one of my gripes about dc over the
years. The one guaranteed way to get a sequential element optimized out
is to not use the output. Here is some code that seems to instantiate two
4-bit counters and 2 flops, using both sync and async resets. After compile
(indeed, after the verilog read), the result is no gates whatsoever!
Here's the code:
module no_flops ( clk, datain, sync_ctr_eq_16, async_ctr_eq_16, reset );
input clk;
input datain;
output sync_ctr_eq_16;
output async_ctr_eq_16;
input reset;
reg [3:0] sync_counter; // Note: not big enough!
always @(posedge clk)
begin
if (reset)
sync_counter <= 0;
else
sync_counter <= sync_counter + 1;
end
assign sync_ctr_eq_16 = (sync_counter == 16);
reg [3:0] async_counter; // Note: not big enough!
always @(posedge clk or posedge reset)
begin
if (reset)
async_counter <= 0;
else
async_counter <= async_counter + 1;
end
assign async_ctr_eq_16 = (async_counter == 16);
reg sync_dummy; // Note: doesn't go anywhere!
always @(posedge clk)
begin
if (reset)
sync_dummy <= 0;
else
sync_dummy <= datain;
end
reg async_dummy; // Note: doesn't go anywhere!
always @(posedge clk or posedge reset)
begin
if (reset)
async_dummy <= 0;
else
async_dummy <= datain;
end
endmodule
The counter comes from a real-life example where a designer inadvertently
upped the value he was checking for without remember to increase the
counter size. Easy to do. Synopsys SILENTLY removed all the flops!
Even the dummy flops are from real-life. Anybody ever mis-type a signal
name on a flop and get an unconnected output and no flop?
I think Synopsys should issue a very specific warning whenever it removes
a sequential element. This is almost never what the designer intended.
True, you can tell the flops didn't get created because the "Inferred
memory devices in process:" block doesn't appear during the verilog read,
but I'm synthesizing a million gates here. I can't go look at this
report on every module every time I rebuild the chip. If there were a
specific warning, I could grep for it.
- Paul Zimmer
Cerent Corporation
---- ---- ---- ---- ---- ---- ----
From: Thorsten Lutscher <thlu@force.de>
John,
I am not sure if this is the answer, but we encountered the same problem
while trying to make the insertion of a FF dependent on a parameter.
Solution was to add a wire between the output of the FF and the output
of the module (in Verilog):
output ff_q;
wire ff_q;
reg loc_ff_q;
// first the flip flop
always @(posedge clk or negedge reset)
if(~reset)
loc_ff_q <= 0;
else begin
loc_ff_q <= whatever;
end
// then the wire (INSERT_THE_FF is the parameter)
always @(loc_ff_q)
ff_q = INSERT_THE_FF ? loc_ff_q : 0;
If the parameter is 0, Synopsys will not instantiate a Flip-Flop.
- Thorsten Lutscher
FORCE Computers GmbH Germany
---- ---- ---- ---- ---- ---- ----
From: William Liao <wliao@mmcnet.com>
Hi John,
To figure this all out, I created some test cases myself.
What I did is to create three HDL flip-flops: DFF (D with no Reset), DFFR
(D with Reset), and DFFS (D with Set). Then I instantiated them 6 times:
1) DFF with clk
2) DFFR with Reset and clk
3) DFFS with Set and clk
4) DFF with data
5) DFFR with Reset
6) DFFS with Set
Then I instantiated them again, exactly the same input connections,
but the output pins do not drive anything.
module dff (clk, d, q);
input clk;
input d;
output q;
reg q;
always @(posedge clk) q <= d;
endmodule
module dffs (clk, d, q, s);
input clk;
input d;
input s;
output q;
reg q;
// synopsys async_set_reset_local dffs_block "s"
always @(posedge clk or posedge s)
begin : dffs_block
if (s)
q <= 1'b1;
else
q <= d;
end
endmodule
module dffr (clk, d, q, r);
input clk;
input d;
input r;
output q;
reg q;
// synopsys async_set_reset_local dffr_block "r"
always @(posedge clk or posedge r)
begin : dffr_block
if (r)
q <= 1'b0;
else
q <= d;
end
endmodule
module test (clk, s, d, q, t);
input clk;
input s;
input d;
output [5:0] q;
output t;
reg t;
dff no_clk(.clk(1'b1), .d(d), .q(q[0]));
dffs no_clk_ws(.clk(1'b1), .d(d), .s(1'b1), .q(q[1]));
dffr no_clk_wr(.clk(1'b1), .d(d), .r(1'b1), .q(q[2]));
dff no_d(.clk(clk), .d(1'b0), .q(q[3]));
dffs no_s(.clk(clk), .d(d), .s(1'b1), .q(q[4]));
dffr no_r(.clk(clk), .d(d), .r(1'b1), .q(q[5]));
dff nf_no_clk(.clk(1'b1), .d(d));
dffs nf_no_clk_ws(.clk(1'b1), .d(d), .s(1'b1));
dffr nf_no_clk_wr(.clk(1'b1), .d(d), .r(1'b1));
dff nf_no_d(.clk(clk), .d(1'b0));
dffs nf_no_s(.clk(clk), .d(d), .s(1'b1));
dffr nf_no_r(.clk(clk), .d(d), .r(1'b1));
endmodule
The result can be summarized like this: If a cell is not sequential (no
clk), DC will try to remove it. If a cell does not drive anything, DC
will try to remove it. But if a cell is sequential (has clk), or it
drives something, DC is stuck with it, no matter how input pins are
connected.
If you have time, try the example, then have fun with other combinations.
- William Liao
MMC Networks
( ESNUG 321 Item 10 ) --------------------------------------------- [6/8/99]
Subject: ( ESNUG 319 #3 ) Accessing Intermediate Bits In Module Compiler
> I have been given the task of evaluating Module Compiler. After cruising
> along the learning curve quite well, I came to a roadblock. The ALU
> datapath I was implementing as a test case had the use of intermediate
> carry bits from the 32-bit adder. I have yet to find in the documentation
> how one gets access to these bits or if it is even possible. Any help
> from ESNUG would be appreciated.
>
> - Barry Williams
> Rockwell Avionics
From: [ A Synopsys Module Compiler AE ]
Hi John,
Here are some examples that try to illustrate how to access carry signals.
Barry's problem (we spoke on the phone) is to get access to the carry signal
after each successive 8 bits in the sum. Really, this is just breaking down
a big 32-bit adder into 4 8-bit adders and connecting the carry-out from a
lower 8-bit adder into the carry-in of the next higher 8-bit adder. This
can be easily accomplished with the following code example done both for
unsigned and signed. Note that this will be slower than the full 32-add
because we can only do fast-carry-look-ahead for 8 bits at a time instead
of all 32 bits.
This is the UNSIGNED reference design:
module add_slice_ref(a,b,y);
directive(delay=10000);
input [31:0] a,b;
output [32:0] y;
directive(fatype="csa"); // I chose "carry select adder"
// architecture for the adder type.
y = a + b;
endmodule
This is the UNSIGNED carry access design:
module add_slice(a,b,y);
directive(delay=10000);
input [31:0] a,b;
output [32:0] y; // output needs to be 33 bits for no overflow.
// bit 32 is the carry-out.
wire [8:0] y3,y2,y1,y0;
directive(fatype="csa");
y0 = a[7:0] + b[7:0];
wire [1] c8 = y0[8];
y1 = a[15:8] + b[15:8] + c8; // y0[8] is the carry out
// from the first 8 bits
wire [1] c16 = y1[8];
y2 = a[23:16] + b[23:16] + c16; // y1[8] is the carry out
// from the second 8 bits
wire [1] c24 = y2[8];
y3 = a[31:24] + b[31:24] + c24; // y2[8] is the carry out
// from the third 8 bits
y = cat(y3,y2[7:0],y1[7:0],y0[7:0]); // y3[8] = y[32] is the
// carry out from the
// last 8 bits
wire [1] c32 = y3[8];
// Now you can use the carry for your particular use
endmodule
This is the SIGNED reference design:
module add_slice_signed_ref(a,b,y);
directive(delay=10000);
input signed [31:0] a,b;
output signed [32:0] y;
directive(fatype="csa");
y = a + b;
endmodule
This is the SIGNED carry access design:
module add_slice_signed(a,b,y);
directive(delay=10000);
input signed [31:0] a,b;
output signed [32:0] y; // output needs to be 33 bits for no overflow
wire signed [8:0] y3;
wire unsigned [8:0] y2,y1,y0; // only y3 contains the signbit.
directive(fatype="csa");
y0 = a[7:0] + b[7:0];
wire [1] c8 = y0[8];
y1 = a[15:8] + b[15:8] + c8; // y0[8] is the carry out
// from the first 8 bits
wire [1] c16 = y1[8];
y2 = a[23:16] + b[23:16] + c16; // y1[8] is the carry out
// from the second 8 bits
wire [1] c24 = y2[8];
y3 = a[31:24] + b[31:24] + c24; // y2[8] is the carry out
// from the third 8 bits
y = cat(y3,y2[7:0],y1[7:0],y0[7:0]); // y3[8] = y[32] is the
// carry out from the
// last 8 bits
wire signed [1] c32 = y3[8]; // Note that this is also
// the sign bit
endmodule
Also note that I wanted to verify my coding, so when I also created a simple
32 bit adder of each flavor (signed and unsigned), I used Formality to
quickly check the output of Module Compiler that the versions with carry
bit access are 100% functionally equivalent.
- [ A Synopsys Module Compiler AE ]
( ESNUG 321 Networking Section ) ---------------------------------- [6/8/99]
Santa Clara, CA -- GigaPixel seeks the impossible; good designers looking
for a job. Verilog, Synopsys, & related exp. a plus. "oren@gigapixel.com"
|
|
