Editor's Note: The other day I came across some old college photos and
was surprised to see a picture of four bags of garbage. I thought for a
minute until I remembered my job for two summers at Argonne National
Laboratory designing electronics for High Energy Physics research. It was
a great place to work, but it meant you had to live in a college dorm that
had few single rooms, many double rooms and some 4 person rooms. I was a
bit unlucky. I got one of those rooms that should have been a single
(because it was so small) but the Housing Office decided to make it a
double. It was nerve wracking because I had this room to myself at first,
but I was always under the threat that I could get a roommate at any time
because people were constantly rotating in & out of the lab on different
international research programs. To stop this, I had a plan.
Every day before I left for work, I carefully emptied four full bags
of garbage *into* my room. This wasn't ordinary garbage, though -- it
was beer cans, orange juice containers, donut and pizza boxes, McDonald's
wrappers, etc. -- all *carefully* cleaned to be completely free of any
food remnants so as to not attract bugs. I also spread my clean clothes
all about the room. Whenever I had a prospective new roommate enter my
room for the first time (which was usually a daytime event because he just
arrived) he would see an absolute pig sty and go back to the Housing Office
*demanding* a different room. When I got back home at night, I'd put all
the garbage and clothes away to have a nice room for the evening. I know
this probably caused some of the college students and the Housing Office
staff to gossip about my lack of housekeeping skills -- but, hey, I
didn't care -- I was the only one who had a *private* room all summer
for both summers! :^)
- John Cooley
the ESNUG guy
( ESNUG 258 Item 1 ) -------------------------------------------- [2/7/96]
Subject: ( ESNUG 257 #6 ) Bad DC! -- Getting DC To Clean Up After Itself
> I use parameterized templates extensively in my Verilog designs. When
> Synopsys reads in these templates, it creates a few temporary files with
> names like "*.mra", and "*verilog.syn". Problem is, messy Synopsys
> doesn't clean up these files upon exit. My directories are really
> starting to get cluttered! Do any of your readers have any tricks to get
> Synopsys to not create these files, or redirect them to a junk directory?
From: pbarrett@su102s.ess.harris.com (Phil Barrett)
John,
Regarding the problem with synopsys writing cache files to your synopsys
directory and cluttering it up, I may not fully understand your problem,
but there may be a simple solution. Create a work directory in your
synopsys directory. Add the following to your .synopsys_dc.setup file:
define_design_lib work -path ./work
cache_read = cache_read + {./work}
cache_write = "./work"
This should write all of your *.mra, *.sym, etc. files to the work directory
you created. I am not familiar with the use of parameterized templates,
or for that matter Verilog design, but any synthesis related files should
write to the work directory with these additions.
- Phil Barrett
Harris Corp., Palm Bay, FL
---- ---- ---- ---- ---- ----
From: ajoy@rendition.com (Ajoy Aswadhati)
Hi John, To reduce the clutter in your synthesis directory....
UNIX>mkdir WORK
at the beginning of your synthesis script:
dc_shell>define_design_lib work -path ./WORK
- Ajoy Aswadhati
Rendition Inc, Mountain View, CA
---- ---- ---- ---- ---- ----
John,
Assuming these are being created in your "WORK" library (the default for
the analyze command) then use this dc_shell command:
define_design_lib WORK -path the/directory/you/want
Now the "WORK" design library is mapped into whatever directory you want.
I typically use "../work" or "~/work". Make sure the directory exists
before you use it.
- Steve Golson
Trilobyte Systems
---- ---- ---- ---- ---- ----
From: Paul Zimmer <prz@hplb.hpl.hp.com>
Hi, John.
My complaints about this to Synopsys have fallen on deaf ears. It's
worse than messy, it's destructive.
The REST of DC, and other synopsys tools (except perhaps BC), behave like
good little editors. You read something in, do whatever bizarre, deviant
things you want to them, and, as long as you don't do a write, you can
exit without having done a bit of damage.
Not so with parameterized designs. You do a simple *read*, and the thing
defecates all over the file system! VERY irritating! Why doesn't it
just create the .mra, etc stuff as objects in dc, and write them out if
and when you say so?
I agree - Bad DC! Bad DC!.
- Paul Zimmer
HP, Bristol, UK
( ESNUG 258 Item 2 ) -------------------------------------------- [2/7/96]
Subject: ( ESNUG 257 #4 ) Model Tech V4.5c vs. Synopsys VSS 3.4b and 3.3b
> which TB_ICP_BTA sim Relative sim times
> --------------------- -------------- ------------------
> VSS V3.3B Interpreted 240 minutes 100%
> VSS V3.3B Compiled 94 40%
> VSS V3.4B Interpreted 191 80%
> VSS V3.4B Compiled 48 20%
> Model tech V4.5c 47 20%
From: blogs@telxon.com (Brian Logsdon)
John,
I'm kinda amazed at those sim time results, I've never EVER benchmarked
Synopsys VSS where it came close to ModelTech's V-system. I'll have to run
them again.
I would like to see a comparison at the gate level w/ back-annotated delays.
I'm willing to bet your farm that the comparison isn't even close.
> The Model Tech waveform tool is less capable than Synopsys's, but the
> host of other methods of viewing your data more than makes up for it.
> Model Tech waveform is much faster at viewing lots of data (full view).
> ModelTech crashed once in the waveform tool. Synopsys never crashed.
This I gotta flame! Synopsys WAVE beats ModelTech? Not a chance. Synopsys
WAVE is the klunkiest, slowest piece of junk in their suite! Try doing
timing measurements with the cursors. Can you say "autosnap"? Also try
displaying ALL of your signals in a design. ModelTech will do it. Last
time I tried it, Synopsys had a 256 signal limit. I've displayed 20,000
signals in ModelTech before, when looking for a test failure and it did a
great job!
The ModelTech waveform crash was probably due to a bug that has existed
forever in their software. You'll run out of temp buffer space unless you
shut off the scrolling in the main ModelTech window.
- Brian Logsdon
Telxon
---- ---- ---- ---- ---- ----
From: bz@musun4.micro.lucent.com (Denis Bzowy)
John,
Could you ask "Chicken Man" ( the guy who did this benchmark ) if he used
VITAL libraries? His benchmark is excellent; now to further incur the
wrath of the EDA vendor gods, has anyone looked at:
TimingChecksOn: boolean := false;
XGenerationOn: boolean := false;
vsim -noglitch ?
These can nearly double simulation speed.
(Glitch warnings are less useful after the first 1000000; every simulator
should have "when NWarnings > 1000 ...")
Also, has anyone looked at the speeds of VHDL+Vital vs. Verilog in a
single-kernel simulator ? With the same kernel, this would measure
the VITAL primitives vs. Verilog's built-in gates and tables.
- Denis Bzowy
Lucent Technologies Microelectronics Group, Munich
---- ---- ---- ---- ---- ----
> Synopsys is more forgiving of VHDL semantic content, has a fuller featured
> wave viewer, and might be more robust on the bigger circuits.
From: "John Swan-ACIC00" <John_Swan-ACIC00@email.mot.com>
John,
This statement makes it sound like a "more forgiving" simulator is a good
thing. But our experience with multiple VHDL simulators has taught us that
a "forgiving" simulator is *not* such a good thing. It leaves problems to
be discovered later in the design process, instead of helping to resolve
them earlier.
Our use of the relatively "unforgiving" Model Tech simulator (in Mentor's
quicksim) lead us to resolve problems earlier in the design cycle. Our
other simulator (not Synopsys' simulator) did not. Actually, Quicksim often
gave us warnings to help us discover build problems, but the tool generally
kept compiling.
Our main chip simulation guy who reminded me that Model Tech was used on a
very large design of ours recently: "My experience with ModelTech has been
that it works quite well on the <XYZ_chip> and I can't imagine many circuit
designs larger than the <XYZ_chip>."
So then, Why does "Chicken Man" say that Synopsys "might be more robust on
the bigger circuits" ???????
- John Swan
Motorola Corporate Research
( ESNUG 258 Item 3 ) -------------------------------------------- [2/7/96]
From: "Erich C. Whitney" <erich@datacube.com>
Subject: Pipelined Designs, Latches, Test Compiler and Flip-Flopping
Dear John,
I've been dealing with the question: "How do you avoid using latches in a
design when they're so darned convenient for holding control bits?" a lot
lately.
First you may ask, "Why would you want to avoid them?" And my answer is
simple, "Test Compiler!" I've read every bloody tech note on latches
with Test Compiler and the issues of testability, but nowhere does anyone
have the guts to come out and say that, "One, TC hates them, and two, they
cause more problems than they're worth in the context of an otherwise
beautifully synchronous design."
A latch presents a problem for ATPG because the LATCH ENABLE input prevents
the flow of data from D to Q. So, it has to either figure out how to
properly open and close the latch during scan test such that all of the
faults are testable. (Yes, I know that TC v3.5 can handle this in the
general case and I've been told that TC+ is even better at it but in the
context of a real design, latches are a big pain in the butt! For those of
us without a big wad of cash for TC+, this means that for every D-Latch in
a design, you can't cover the LE input or ANY of the gates that drive it.)
An Example:
I have a synchronous pipeline design consisting of about 3000 flip-flops.
Just the sort of thing that makes Synopsys shine. BUT I need about 4000
bits worth of control registers to run that pipeline! That's 4000 of those
stinking D Latches! Now, I can't justify the price of TC+ to get fault
coverage on 4000 Latches and when you take into account the loss of coverage
of the decode logic, we're talking about a 20% deficit in coverage.
Unacceptable.
Here's the original circuit:
The latches are typically grouped together into words of up to 16 bits, so
there's more than one latch per comparator as the diagram might otherwise
imply. There's probably about 1/10 as many comparators as are latches.
D-LATCH
+-----+
Data_Bus []-|>-------------------|D Q|------>Off to the pipeline...
| |
| LE |
ADDRESS +-----+
COMPARE |
+------+ |
Address_Bus []-|>--| A=B? |-+ |
+------+ | |
| +-----+ |
+-----+ +-| | |
Chip_Select []-|>--O| | | AND |--+
| AND |---| |
Write_Enable []-|>--O| | +-----+
+-----+
A CPU Write Cycle looks like this:
Chip_Select --------\_____/-------------
Write_Enable ----\_____________/---------
Address_Bus ====X=============X=========
Data_Bus ZZZZX=============XZZZZZZZZZ
A CPU Read Cycle looks like this:
Chip_Select --------\_____/-------------
Write_Enable ----------------------------
Address_Bus ====X=============X=========
Data_Bus ZZZZZZZZZZX=====XZZZZZZZZZZZ
The Solution:
It has been suggested that I make the CPU interface to this design
synchronous which would imply registering all of the input signals
shown above. That would gain some fault coverage, but I neither
need nor want a synchronous interface.
I scratched my head for a while until the answer came to me in the shower
one morning. First of all, I know that D latches are about half as big as D
flip-flops, but I'm using a 0.5 micron gate array and there's more gates than
I can shake a stick at. So I said to myself, "To hell with all of that 70's
logic minimization crap, be a guy of the 90's and eat gates! Test Compiler
wants to see DFFs, then I'll stuff so many DFFs down its shirt it'll beg for
mercy!" (Sorry, I guess I really shouldn't drink so much coffee at work.)
I want to use a D flip-flop but I don't want to clock it off of the pipeline
clock because that'll burn power AND make the interface synchronous. Yech.
So I'll make my own clock. Here's what I came up with:
+------------------------+
| 2-1MUX |
| +----+ DFF |
+---|B | +-----+ |
Data_Bus []-|>-------------|A Y|------|D Q|--+->Off to pipeline...
+-|SEL | | |
| +----+ +--|> |
ADDRESS | | +-----+
COMPARE | |
+------+ | |
Address_Bus []-|>--| A=B? |-+ |
+------+ |
|
+-----+ |
Chip_Select []-|>---| | |
| AND |------------+---->
Write_Enable []-|>--O| | (global gated chip select)
+-----+
Here, the D Latch is replaced by a DFF and a 2-1 MUX. All of the flip-flops
are clocked off of the gated chip select. New data is only written into the
control register IF it's a write cycle AND the address matches. Furthermore,
the control registers are ONLY clocked during CPU write cycles. And the
really cool thing is that this structure is handled by Test Compiler with no
complaints! You have to mark the gated chip select as a global clock, but
you can use that to your advantage because now you can easily constrain
Design Compiler to give you reasonable CPU access times to the chip!
Caveats:
There is one real-world point that I haven't made here (yet). Typically,
chips that have a CPU port such as the one I described here allow for
read-back of some kind. This opens up yet another can of worms with Test
Compiler and fault coverage. The problem is that a bidirectional data bus
implemented with BIDIR IO cells causes un-testable faults, namely in one
side or the other of the tri-state gate in the BIDIR port. Although this
has absolutely nothing to do with the problem with latches, it does create
headaches in the design because we're trying to design a practical CPU
interface.
A typical CPU interface read back using BIDIR cells:
BIDIR PAD BIDIR CELL
+-+ |\
Data_Bus |X|----+----| +------X-> to control registers as shown above
+-+ | |/ /|
+--------+ |----< from read back MUX
\| (see posting 257 #2!)
|
+-----< from output enable logic
Yet another problem:
Test Compiler recommends that you force the BIDIR into output mode which
means that you lose the testability of the data bus inputs we fought so hard
to get by using flip flops in the first place! You have to break the
combinational feedback loop introduced by the BIDIR at the point marked
by an 'X' in the diagram above (by using the set_test_isolate command).
Yet another solution:
My solution to this is to put another set of flip-flops in. "When you're a
hammer, everything looks like a nail." This provides Test Compiler with a
way to scan data into the input side of those 2-1 MUXs shown above. The 2-1
MUX shown below is there to allow scan data to get to the control registers
during normal operation. The Test Hold input is asserted (with 1) during
scan test which engages the DFF and allows scan data to pass through to the
control registers. You only have to build this structure once for each data
bus bit. And you will likely have many more control registers so the loss of
coverage introduced by the 2-1 MUX/Test Hold combination is dwarfed by the
gain in coverage you get by being able to scan into ALL of the control
register flip-flop D inputs. You end up with 2 scan clocks, one is the
global system clock, and the other is the global chip select clock we
made above. The good news is that Test Compiler handles this with no
problem.
2-1MUX
+----------+ +---+
BIDIR PAD BIDIR_CELL | DFF +-|A |
+-+ |\ | +---+ | Y|-> to control registers
Data_Bus |X|-----+--| +---X---+---|D Q|----|B |
+-+ | |/ +-|> | | S |
| | +---+ +---+
global chip-----------------------+ |
select clock | |
from example above | |
| |
Test_Hold -------------------------------------+
| /|
+-------+ |----< from read back MUX
\| (see ESNUG 257 #2)
|
+-----< from output enable logic
Test Compiler Script snippet:
/*
* make the gated chip select into a legal gated clock
* (you need to fill in the timing details for your design)
*/
create_clock -name "Chip_Select" -period 25 -waveform {"0" "12.5"} \
find(port, "Chip_Select")
set_dont_touch_network find(clock, "Chip_Select")
set_fix_hold find(clock, "Chip_Select")
/*
* declare the pins that are statically held during scan test
* (Write_Enable is necessary to make the gated clock scheme work)
*/
set_test_hold 1 find(port,"Test_Hold")
set_test_hold 0 find(port, "Write_Enable")
/*
* disable the feedback loop through the BIDIR cells
* (use need to edit BIDIR and X to fit your design and library)
*/
foreach (cell_found, find(cell, "BIDIR*") {
set_test_isolate cell_found + "/X"
}
NOTE: Depending on your ASIC vendor's technology library, you may want to
consider putting a clock tree in to drive the gated chip select signal.
Conclusion: I know this is a long and winding road just to make a CPU
interface, but it does work and it makes life easier in the long run.
Happy Flip Flopping!
- Erich C. Whitney
Datacube, Danvers, MA
( ESNUG 258 Item 4 ) -------------------------------------------- [2/7/96]
From: Paul Laberge - PC Tech <plaberge@micron.com>
Subject: Crazy Synopsys Buffering & Time Critical Paths In Synthesis
Hi John,
I've got a time critical vhdl design in which I'm ANDing several values,
but only one is time critical. No matter how I code I just can't get
Synopsys to treat the time critical signal as high priority and
AND it at the last possible place in the tree. I've tried group_path,
using parenthesis, and turning structuring off.
A <= B and C and D and E and TIME_CRIT;
My Synopsys rep says VHDL Compiler ignores parenthesis, so I tried:
TEMP <= B and C and D and E;
A <= TEMP and TIME_CRIT;
But doesn't help at all! Any Ideas?
Also, I have a time critical path that feeds externally from my design,
and several internal loads that are less time critical. Therefore I just
want Synopsys to put a big buffer on the internal copy and drive the
external copy unbuffered. No matter what I do Synopsys seems to want to
drive the output port with the buffered copy, or put no buffer on at all.
Both solutions slow down the output port. Help!
- Paul LaBerge
Micron Electronics
( ESNUG 258 Item 5 ) -------------------------------------------- [2/7/96]
From: Dyson.Wilkes@swi055.ericsson.se (Dyson Wilkes)
Subject: I Want Verilog `ifdef Supported By Synopsys!
John, here is one to get some chat going!
WHY, OH WHY, does HDL Compiler for Verilog not support `ifdef's etc.???
- Dyson Wilkes
Ericsson
( ESNUG 258 Networking Section ) -------------------------------- [2/7/96]
Atlanta, GA -- Scientific-Atlanta seeks Verilog/Synopsys ASIC Designer.
Principals only. No third party referrals, please. "jim.avant@sciatl.com"
Wilsonville, OR -- Tektronix seeks EDA Support Engineer for Unix, Cadence,
Synopsys, Solaris, Verilog. No agencies. "karenhar@bangate1.tek.com"
|
|
