Editor's Note: Most California to Boston flights go late night, so when I
get home I don't turn on the lights so as to not wake my housemates. The
moment I step in my dark house, I hear a "thump-thump-thump". Once I get
my luggage in the door, it becomes a louder THUMP THUMP THUMP. Then,
still in the dark, the thumping stops and it's replaced by my feet and my
luggage being sniffed. It's not a weird ghost haunting my farmhouse; it's
Sophie, a 12 year old cocker spaniel who's usually happy to welcome me
home even though everyone else has gone to bed. Sophie's a goofy old dog
who just wants attention and love no matter who you are. And that was
usually. When I got home from SNUG'03 on Thursday night, the house was
quiet. I thought nothing of it when I got home at 1:00 AM, but the next
morning I heard the news. Sophie had died while I was away. She was
buried in the back yard where she loved to wander. No more late night
welcome homes. No more goofy looks for attention from Sophie. No more.
- John Cooley
the ESNUG guy
( ESNUG 409 Subjects ) ------------------------------------------ [03/25/03]
Item 1: ( ESNUG 395 #8 ) Coping With IBM's 12% On-Chip Timing Variations
Item 2: ( ESNUG 395 #14 ) C/Vera/Verilog Memory Leaks & Rational's Purify
Item 3: ( ESNUG 395 #4 ) DC's Renaming Of Nets & Verilog Gate Simulations
Item 4: ( ESNUG 381 #1 ) What's hdlout_internal_busses Been Replaced By?
Item 5: Can't Get My Cadence SKILL Code To Traverse My Chip Automatically
Item 6: ( ESNUG 393 #8 ) Didn't Buy Debussy; But We Liked Denali PureView
Item 7: ( ESNUG 407 #10 ) Screw Denali; DesignWare Has Beaucoup Memory IP
Item 8: Am I One Of The Many Using "Useful" Clock Skew To Close Timing?
Item 9: What? DC Only Buffers Flip-flop Outputs But NOT Latch Outputs??!
Item 10: ( ESNUG 347 #1 ) Cliff Adds #1 Delays To His Non-Blocking Paper
Item 11: ( ESNUG 396 #1 ) A Boatload Of Letters On Sync vs. Async Resets
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 409 Item 1 ) -------------------------------------------- [03/25/03]
Subject: ( ESNUG 395 #8 ) Coping With IBM's 12% On-Chip Timing Variations
> Our current ASIC vendor, IBM, is having us do timing analysis with an
> on-chip variation of 12%, applied to both cell delays and
> interconnect delays.
>
> This makes certain kinds of timing very difficult to pass. For example,
> using a PLL to zero out a 5 ns insertion delay requires a 5ns feedback
> path. But 12% variation between the two is 600 ps, which is a big chunk
> of time these days. Source-synchronous interfaces have similar problems.
>
> How realistic is this sort of thing? Has anyone done a paper on this?
>
> - Paul Zimmer
> Cisco Systems
From: Howard Landman <domain=riverrock.org user=howard>
Hi, John,
Srinivas Kakumanu wrote in his ESNUG 395 #8 reply to Paul's question that
4-corner analysis "is an alternative to the on-chip-variance in PrimeTime".
I must disagree. Consider two distinct paths, perhaps in a manually-laid-
out clock tree, which have exactly equivalent layouts. Any corner analysis
will say that they are the same since the computation is given exactly the
same transistor sizes and parasitics; therefore it will show no difference.
But the On-Chip Variance (OCV) could be as much as half a nanosecond!
Paul Zimmer asks: "If your path goes through 20 or so elements, and the
variation is sort-of random, isn't all-min vs all-max a little extreme?"
Yes it is. The mathematics of it would be that if you had N stages which
all had equal delay, and you model OCV as independent random variables,
then the variance goes up linearly with N and the standard deviation goes
up as the square root of N. So you'd expect 16 equal stages to be about
four times as bad as one stage.
However any deviation from the above assumptions could make it worse. For
example, some of the variation can be systematic rather than independent.
Or not all the stages could be equal in delay. And some of these sources
of variation are linear, not square-root. So a simplified but moderately
realistic model of OCV might look something like:
On-Chip Variance (OCV) = a*D + (b*D)/sqrt(N)
where D is the total path delay from the point at which the two paths
diverged. It seems that most tool (and silicon) vendors simplify this
further to just a linear model. This isn't quite right, but it's not
too unreasonable.
Matt Weber writes "IBM is the only ASIC vendor I know of that requires
this analysis". I know of at least one other, but I'm under NDA. :-) His
discussion of common path pessimism removal was excellent, and this issue
is critical in OCV analysis; so I'd recommend everyone read it through
carefully and make sure they understand it. The only thing I'd change is
that I'd put more emphasis on hold checks - in my experience they are often
the biggest problem from OCV because of the added clock skew and the large
number of delay elements needed to fix a big hold violation.
The moral of the story: Keep your clock tree insertion delay as low as
possible, or use clock distribution methods which are not subject to
as much OCV as a tree. For example, in the Emotion Engine of the Sony
PlayStation 2, the last stage of the clock network is a mesh with all
outputs shorted together. This smooths out OCV-induced skews, although
you need to analyze possible EM problems caused by not all the drivers
switching at the same time.
- Howard A. Landman
Riverrock Consulting Fort Collins, CO
( ESNUG 409 Item 2 ) -------------------------------------------- [03/25/03]
Subject: ( ESNUG 395 #14 ) C/Vera/Verilog Memory Leaks & Rational's Purify
> We're trying to find a memory leak in a large co-simulation, i.e. we're
> comparing a C-model with a Verilog model together with Vera as the test
> bench. The leak is probably in the C model and it shows up only when we
> run in co-simulation, not standalone. I tried to run Rational's Purify
> tool on the entire co-simulation, but to date, have had no success
> purifying VCS. I am wondering if anybody on ESNUG have had any luck
> doing this.
>
> - Steve Tjiang
> Tensilica, Inc.
From: Praveen Sathyadevan <group=wipro lot bon person=praveen.sathyadevan>
Hi, John,
We had come across such a situation once and Rational's Purify helped in
cleaning the code fully. But I was trying it in Verilog-XL.
Some things that I remember are:
- all the C files were compiled with -g option for debug
- the linking for the new Veriog executable has to be done with Purify
and the -g option.
- for these two modify the script [cr_vlog] given by vconfig.
- here give purify -best-effort to avoid abortion of instrumentation
- run Purify newVerilog with the pop-up display enabled for Purify
Once the Purify runs on -g compiled C code, it will be able to find out the
leaks, if there are any.
- Praveen Sathyadevan
Wipro India
---- ---- ---- ---- ---- ---- ----
From: Ajoy Aswadhati <castle=force10networks clot gone king=ajoy>
Hi, John,
Steve could have a problem in the Vera domain, too. Even though Vera is
supposed to do automatic garbage collection, you could run into issues
where you keep creating new objects without reusing them.
Vera versions 5.0(?) and beyond have a built-in profiler which can help in
tracking down these issues. It is fairly easy to setup and use. The most
recent version of Vera that I've heard of is 5.1.1
- Ajoy Aswadhati
Force10 Networks Milpitas, CA
( ESNUG 409 Item 3 ) -------------------------------------------- [03/25/03]
Subject: ( ESNUG 395 #4 ) DC's Renaming Of Nets & Verilog Gate Simulations
> We are running into problems with respect to gate level sims. The Verilog
> netlist produced by Design Compiler optimizes the net names and they
> become "n1234" or something like that. Our testbenches probe the internal
> nets & therefore it becomes increasingly difficult to map the RTL signal
> names to gate level signal names. I was wondering if there is a Synopsys
> variable that controls the outcome of the signal names? In other words,
> how can preserve the RTL signal names in DC netlists?
>
> - Himanshu Bhatnagar
> Conexant Systems, Inc.
From: Jonah Probell <kitchen=lexra fiat yon chef=jonah>
Hi, John,
I am no expert, but my company's testbench also supports gate level sim. It
is best to design your testbench so that it does not make hierarchical
references into synthesized modules. If you need to check or change
something about the internal state of the device and you can not do so
directly through external pins of the chip, design an internal software
accessible register.
If you must use a hierarchical reference into the synthesized RTL code, do
not flatten any hierarchy in the reference path. It is best to reference
only ports of submodules within the chip since Synopsys does not change
module instance names or port names throughout unflattened hierarchy. If
you must reference a register within a submodule within the chip, you should
be able to do so. By default Design Compiler names all registers by their
RTL signal name with "_reg" appended. You can use the define_name_rules in
conjunction with the change_names commands to remove the "_reg" from the
ends of all register names in your script between the compile and the write
netlist commands.
define_name_rules my_rule -map {{"_reg$", ""}}
change_names -rules my_rule -verbose
In order to optimize combinational logic, Design Compiler needs to have the
freedom to create, destroy, and rename signals in combinational paths. I do
not believe that there is a way to preserve such signal names, so your
testbench should not reference signals in combinational paths.
- Jonah Probell
Lexra, Inc. Massachusetts
---- ---- ---- ---- ---- ---- ----
From: Tom Tessier <france=hdl-design caught qualm paris=tomt>
Hi, John,
I don't know of a way directly to do this but I have found that Synopsys
will preserve the names of registers thus you can attach to the output
pins of registers consistently. I have been working on a couple of
designs that both force (bad practice IMHO) and observe register values
with an ASIC. This is used to facilitate automated testbench checking.
The designs have imbedded processors in them and this was a way for the
team to communicate what the processor was doing to the testbench. The
interesting thing is most of these registers don't go anywhere so we
have to "dont_touch" them to keep them in the gate level netlist.
Personally I would prefer to see a debug port added to the design that
would involve a couple of pins at most. This port would then be
available for both testbench and lab checkout.
If you find a way to make DC preserve RTL names please let us all know.
- Tom Tessier
t2design, Inc. Louisville, CO
---- ---- ---- ---- ---- ---- ----
From: Scott Evans <iraq=sonicsinc blot gone bagdad=scott>
Hi, John,
I think the only net names that you can preserve would be that of nets
connected to ports (i.e. the main I/O of the block you are synthesizing or
levels of hierarchy you are preserving within that block) and the outputs
of registers as those are the only "static" parts of your design.
Everything else is fair game for DC to optimize away. If these are not
the places you need to probe your RTL then I think your only option is to
bring these signals out as ports (which has problems of its own).
- Scott Evans
Sonics, Inc. Mountain View, CA
( ESNUG 409 Item 4 ) -------------------------------------------- [03/25/03]
Subject: ( ESNUG 381 #1 ) What's hdlout_internal_busses Been Replaced By?
> We wound up adding these variables in our *dc.setup file to make the
> grouping easier to swallow:
>
> set hdlout_internal_busses true;
> set change_names_dont_change_bus_members true;
> set verilogout_no_negative_index true;
>
> That last variable is odd. In DC 2000.11-SP2 and later the default value
> was set to false which resulted in Verilog arrays containing negative
> numbers (i.e. foo[1:-3]). Why anyone would want this is beyond me.
>
> - Gregg Lahti
> Corrent Corp Tempe, AZ
From: Laurent Tabaries <last=st slot pomme 1st=laurent.tabaries>
Hello John,
Is there someone who knows what is the TCL variable that replaces the
obsolete variable "hdlout_internal_busses" ?
- Laurent Tabaries
STMicroelectronics Rousset, France
( ESNUG 409 Item 5 ) -------------------------------------------- [03/25/03]
From: Chris Thomas <goatherd=sige sought mom goat=cthomas>
Subject: Can't Get My Cadence SKILL Code To Traverse My Chip Automatically
Hi, John,
I in the process of writing a Cadence SKILL code to traverse my chip's
hierarchy and plot the different cell views. The problem I am running
into is that I can't get the plots to print full page and centred. I
can plot the cell view manually and save the settings to a template
file. I can then take the settings for schPlotOptions() and use those
within my SKILL code. The problem is that when I remove all of the
specific options to that cell (bBox, scale...) to make it automated,
the plots will come out with only using 1/4 of the page or not at all.
Here is the list of schPlotOptions() when plotted manually.
schPlotOptions = '(nil
hierarchy nil
hierleveldown 0
fullarea t
multisheet nil
view "schematic"
cell "cellname"
library "libname"
bBox ((-7.0 -3.125) (9.95 11.25))
plot "cellview"
noteText "This is the plot"
grid nil
indexsheet t
notes t
header t
cv db:51811372
window window:2
mailto "user"
vsheets 1
hsheets 1
display "display"
pagecount 1
nullpage nil
paperdim (8.17 10.67)
papersize "A"
resolution 600
plottertype "postscript1"
plotter "printer"
fit t
outputfile ""
time "now"
tmpdir "/usr/tmp"
copy 1
unit "inches"
scale 0.568348
center t
mail nil
orientation "automatic"
offset (0.5182521 0.0)
plotsize (9.633496 8.17)
)
My questions is this: What options need to be set to plot a full page,
centred, automated plot? If someone has the documentation on the
schPlotOptions() and how they interact with each other I would greatly
appreciate it.
- Chris Thomas
SiGe Semiconductor, Inc.
( ESNUG 409 Item 6 ) -------------------------------------------- [03/25/03]
Subject: ( ESNUG 393 #8 ) Didn't Buy Debussy; But We Liked Denali PureView
> Undertow Suite can do exactly what Novas does and for less than 1/4 the
> cost. What a totally unnecessary and major financial burden it is to have
> to purchase tools for every engineering team member that cost $25,000+,
> just in order to trace signals back on your RTL or gate designs.
>
> - Bob Schopmeyer
> Veritools, Inc.
From: Daniel Abate <wolfpack=mc thought guam wolf=dabate>
Hello John,
We looked at Debussy, but ended up using the waveform viewer that came with
our simulators. One thing I really liked about Debussy, that I haven't
seen in other waveform viewers, is a nice integration to Denali's PureView
Memory debugging tool. We are designing a custom ASIC (a Rapid I/O based
multi-processor compute system) with +2G of DDR-SDRAM memory, and use
PureView to view the memory data/transactions during simulation. Denali's
'system memory' feature lets us organize our DDR memory models into a single
contiguous address space, and using PureView, we then have access to a
detailed memory transaction history, and a view of the system memory
contents during simulation. It's pretty valuable to be able use a backdoor
into memory for snooping reads/writes, loading large memory images, and
injecting random errors - not to mention the graphical stuff. We save a ton
of time by snooping memory data, setting assertions on memory transactions,
etc. I wish there more debug solutions using these methods; and I can see
a tight integration with Denali MMAV/PureView becoming more of a key issue
in debug/verification tool selection.
- Daniel Abate
Mercury Computer Systems, Inc. Chelmsford, MA
( ESNUG 409 Item 7 ) -------------------------------------------- [03/25/03]
Subject: ( ESNUG 407 #10 ) Screw Denali; DesignWare Has Beaucoup Memory IP
> We offer customizable memory controller IP for DDR SDRAM, FCRAM, RLDRAM, and
> SDR/DDR SDRAM applications. Each core is customized to match the exact
> application for the ASIC in order to achieve 100% bus utilization. Our
> Databahn customization process is accessed via an online interface at the
> http://www.eMemory.com site...
>
> - Mike McKeon
> Denali Palo Alto, CA
From: Mick Posner <tvshow=synopsys pot yawm host=mposner>
Hi John,
Before your readers go off and waste their time and money on the Denali IP,
I suggest they have a look at what they already own as part of the
DesignWare library. Here is a link to more information on the DesignWare
Memory Controller that supports DDR-SDRAM, SDRAM, SRAM, Micron SyncFlash,
Flash, EEPROM and other similar types of memory:
http://www.synopsys.com/products/designware/memorycentral/dwmc.html
Or just go to the Synopsys Memory Central at:
http://www.DesignWareMemorySolutions.com
The DesignWare Memory Controller is fully silicon proven. It comes with a
full verification environment so it is easy to verify your chosen
configuration. As you own the DesignWare Library, you are already licensed
to use the memory controller at no extra cost to your company. You can use
this component in as many designs as you like, royalty free.
- Mick Posner
Synopsys
( ESNUG 409 Item 8 ) -------------------------------------------- [03/25/03]
From: Simon Matthews <the_many=paxonet taut alm the_one=simon>
Subject: Am I One Of The Many Using "Useful" Clock Skew To Close Timing?
Hi, John,
I keep seeing studies in ESNUG which tout the small clock skew achieved on
designs. Yet some tools (including Magma) can introduce clock skew in order
to meet timing in localized paths.
Imagine you have a very simple case of 3 FFs, all clocked by the same clock.
Let's call the FFs A, B and C. There is a combinational path from A to B
that has a large delay. There is a combinational path between B and C that
has a small delay. Now, further imagine that the A -> B path delay is too
large to meet timing and cannot be optimized further. Intractable problem?
A B C
------- ------- -------
---|D Q|-- slow logic --|D Q|-- fast logic --|D Q|---
| | | | | |
| | | | | |
clock ----|> | --|>o-|>o----|> | ----|> |
| ------- | ------- | -------
| | |
--------------------------------------------
Solution: delay the clock input to B. In this case more time is allowed for
the A -> B path by stealing from the B -> C path. Now we have a situation
where skew is deliberately introduced in the clock and it helped us meet
timing. The example I gave is of course trivial, real examples will be much
more complex, but I am sure you will get the idea.
In my opinion, useful skew is the way to go! My question is how many people
are there today using useful skew in their design flow today? Am I one of
few using useful skew or one of the many?
- Simon Matthews
Paxonet Fremont, CA
( ESNUG 409 Item 9 ) -------------------------------------------- [03/25/03]
From: Kameswararao Suri <ocean=dalsemi knot bomb ship=ksuri>
Subject: What? DC Only Buffers Flip-flop Outputs But NOT Latch Outputs??!
Hi, John,
When synthesizing a latch who's output was on the edge of a module and would
be driving about 1 pf of load capacitance, we used a:
set_load 1.0 HT_WRMP
set_max_delay 10.0 -to find(port, "HT_WRMP")
to constrain HT_WRMP, but DC only synthesized a srlatch_nand_1x(latch)
driving HT_WRMP and it didn't complain about any violations in the report
file. We were surprized. We had expected DC to use a 12X buffer from our
fab's library. It didn't!?
Our workaround was to invert the latch expected output, then to assign the
inverted signal to the real signal HT_WRMP that we wanted. THEN, a 12x
inverter was inserted after the latch. The latch was also changed to an
srlatch_nor_6x(latch).
When I experimentally changed my RTL from a latch to a FF, DC placed a 12x
buffer on the FF's output, which was the correct result.
Is there anyway that the latch be synthesized with the initial requirement?
- Kameswararao Suri
Dallas Semiconductor
( ESNUG 409 Item 10 ) ------------------------------------------- [03/25/03]
Subject: ( ESNUG 347 #1 ) Cliff Adds #1 Delays To His Non-Blocking Paper
From: Cliff Cummings <england=sunburst-design shot gone london=cliffc>
Hi, John -
Back in ESNUG 347 #1, I sent you my first place paper from SNUG'00 on Non-
Blocking Assignments in Verilog. I've updated that paper with a detailed
examination of performance data related to adding #1 delays and removing
them. This updated paper shows how to add them if you must and it shows
why they might be needed for mixed RTL-gate level simulations. The new
paper also shows why the VHDL coding style of making blocking assignments
followed by NBA's (variable assignments followed by signal assignments) is
a bad idea, leading to confusion during debug and is unnecessary in
Verilog -- my VHDL jab for the paper. ;-)
- Cliff Cummings
Sunburst Design, Inc. Beaverton, OR
[ Editor's Note: Cliff's new paper is #40 of DeepChip Downloads - John ]
( ESNUG 409 Item 11 ) ------------------------------------------- [03/25/03]
Subject: ( ESNUG 396 #1 ) A Boatload Of Letters On Sync vs. Async Resets
> We are starting a new ASIC design and had new member coming from another
> group. When discussing methodology, our new collegue suggested using a
> synchronous reset flip-flop over asynchrous flip-flop which was a shock
> to us. Our past design guideline has been using async reset flops only
> (because all ASIC vendors we know about only have async reset flops in
> their libraries, so if you choose to code a sync reset flop Design
> Compiler will try to build some logic in front of your D pin.)
>
> Do your readers have any suggestions on this?
>
> - Jerry Yang
> Nortel Networks Nepean, Ontario, Canada
From: Pieter Hulshoff <school=lucent brought sawn fish=hulshoff>
Hello John,
Everything you always wanted to know about resets, but never dared to ask
can be found at:
http://www.xilinx.com/support/techxclusives/global-techX19.htm
We use synchronous resets only. Our ASIC vendors do not have any problems
in accommodating us in this.
- Pieter Hulshoff
Lucent Technologies Huizen, The Netherlands
---- ---- ---- ---- ---- ---- ----
From: Dave Smith <army=st lot prom soldier=dave.smith>
John,
I think that there are valid arguments to support both views on resets.
Personally, I prefer asynchronous resets because:
- The design will go into a defined state immediately on the assertion
of reset, without requiring a clock. This can be useful in multi-clock
designs.
- Designs which contain flip-flop based clock dividers are easier to
handle - if you have synchronous reset, then you cannot reset the
dividing flops and the flops which are clocked from the divided clock
at the same time, since the clock will not propagate while the divider
is held in reset. The alternative (not resetting the clock divider)
is a DFT issue, since the phase relationship of the output waveform
is undefined, and therefore the expected data could arrive in one of
many clock cycles. If reset is asynchronous, all the FFs can be reset
at the same time in complete safety.
- As mentioned, if the ASIC library does not have special sync reset
FFs, the synthesis tool will add logic in front of the D pin. This
can cause problems if you wish to use a separate tool to generate
your reset buffer tree
Off the top of my head, I can think of three reasons *for* synchronous
reset:
- A design using synchronous reset should be able to synthesise into
any cell library. Designs using asynchronous reset require
asynchronous-reset FFs.
- Any logic feeding an asynchronous reset signal needs to be
glitch-free, whereas synchronous reset can tolerate glitches.
- Care needs to be taken when using asynchronous reset, to avoid DFT
problems - in particular, if you allow FFs to generate or
resynchronise the reset signal, you must make sure that they do not
block scan chains.
It's never black or white, just shades of grey here.
- David Smith
STMicroelectronics Bristol, UK
---- ---- ---- ---- ---- ---- ----
From Brian Logsdon <his_company=philips pot hon his_name=brian.logsdon>
John,
I can see only one real reason for using a synchronous reset. If you have
a system in which the behavior must be controlled (or provide specific
responses) as it transitions into the "reset state", then you must use
synchronous resets. If the application of reset is to be indicative of
a power-on or remedy for a catastrophic failure, then there is really no
need for the additional logic that synchronous reset logic implies.
There maybe some argument for synchronous resets for software initiated
reset events. But I think it would be a weak one.
I consider it more likely that this is just a crutch for those designers
that don't want to consider system level issues.
Believe it or not, I'm seeing logic written with BOTH styles.
- Brian Logsdon
Philips Semiconductors
---- ---- ---- ---- ---- ---- ----
From: Gzim Derti <movie=agere wrought brawn actor=derti>
Hi, John,
For a while now, and at various companies, we always use asynch reset flops,
but with a caveat that we synchronize the "release" of the reset state.
In our clock/reset block usually at the top of the design, we create a
little circuit out of a flip-flop and an AND gate.
We tie the D-pin of the flop to high (Vdd, or "1") Reset feeds the RST-pin
(read also CLEAR) of the flop (clocked by the clock that is going to the
network which is being reset) Q of the flop goes to one pin of the AND
gate, and the reset signal itself goes to the other pin:
_________
| | ____
tied hi to VDD "1" -------| D Q |---------| \
| | | AND |----- Chip_Reset
Reset -------| RST | -----|____/
| |_________| |
| |
--------------------
Now when system reset goes low, the AND gate pulls the chip reset low
immediatedly. We let the vendor use clock-tree insertion to lay out the
reset lines just like clock lines. When reset goes high, the flop continues
to hold the reset low until after the next clock edge -- thus doing what we
can to eliminate the timing issues between clock and reset.
On some designs, we've even used the falling edge of clock to drive the
"reset" flop. It all depends on fixing reset setup or hold to clock.
I know that some will argue the other way, but for alot of systems, I like
to know where the flops start out, even if the clocks are off, and async
resets with the above circuit give me what I want.
- Gzim Derti
Agere Systems
---- ---- ---- ---- ---- ---- ----
From: Jerry Yang <jail=nortelnetworks shot psalm prisoner=yangj>
To: Gzim Derti <movie=agere wrought brawn actor=derti>
Gzim,
What you have described in your email is almost the same as what we have
been doing before, e.g. assert reset asynchronously but deassert reset
synchronously. However, there are two issues with the async
implementaion as described in your email:
1. how do you test the reset path?
2. reset input to the chip has to be "clean", i.e. no glitches.
But even so, I still prefer async reset just like you.
- Jerry Yang
Nortel Networks Nepean, Ontario, Canada
---- ---- ---- ---- ---- ---- ----
From: Gzim Derti <movie=agere wrought brawn actor=derti>
To: Jerry Yang <jail=nortelnetworks shot psalm prisoner=yangj>
Jerry,
When you say "test the reset path" do you mean to make sure that it
functionally works, the timing of the path, or Scan testing??
For the functional part, well, functional sims.
For timing static timing usually takes it, like I said, we treated resets
as clocks so post route is the only way.
Now for ATPG/Scan testing: there you've got me. That's one flop that I
don't think can be in the path.
And yes, I'm always assuming a clean, i.e. glitchless input. Don't know a
way around that one...
- Gzim Derti
Agere Systems
---- ---- ---- ---- ---- ---- ----
From: Eric Stine <mountainrange=ti tot con mountain=e-stine2>
Hi, John,
I have never been a big fan of asynchronous resets. Since the async reset
directly controls the flop output it is equivalent to adding a second clock
domain to your design. As such it adds all the extra complexities and
problems of a second clock.
Second, it is a problem for full scan since all clocks and async resets must
be directly controllable during scan mode and in my experience it tends to
reduce scan coverage.
Third, DC by default does not check async reset timings.
Forth, the reset better not have any glitches since that could leave the
flop in an unknown state as you might violate minimum pulse width timings.
Having said all that the biggest reason IMHO for not using async resets
is the more green your team the more likely they are to misuse async resets
and have the problems mentioned above. In almost every project I have been
involved with there is a new guy coding RTL. If I just tell him he can't
use async resets then all these possible problems go away.
- Eric Stine
Texas Instruments
---- ---- ---- ---- ---- ---- ----
From: Manish Shrivastava <bowl=ieee.org goldfish=manish>
Hi John,
Synchronous and Asynchronous reset should depend on what you are looking at.
There is a timing constraint on the rising edge of the reset ( assuming an
active low reset) which can create one cycle uncertainity in the data being
latched in by the FF. So for example if the start of a state machine depends
on when the input FF gets the data and it doenst matter if it starts one
cycle early or late, there is no problem in using Asynchronous Reset.
But if you have a high speed interface with say 6 bits of data being latched
by the FF's and reset release happens very close to the clock edge then you
have a serious problem that some Flops can get the data and some won't.
So it is really dependend on what your design does on what kind of reset you
should have. The safe methodology from my point of view is to use Asynch
resets as long as the clock starts after the reset has been released. Or to
synchronize the Reset with the clock and make sure that the reset network
delay including the CLK->Q delay of the synchronizing flop is less then the
clock period - the worst removal timing of the FF's on the network.
If you use a synchronous reset as an enable, it is a little tricky. You
can't initialize the system without the clock. On the other hand if
you synchronize the reset with clock and use it as the ASYNC Reset input
of the functional FF's, you can safely reset the synchronizing FF with the
same Reset, as what we are worried about is the rising edge of the reset
(active low) and not the falling edge in terms of race conditions.
- Manish Shrivastava
IEEE
---- ---- ---- ---- ---- ---- ----
From: [ Liberte, Egalite, Fraternite ]
Hi John, please have me anon.
I am a SoC project leader in a French company (sorry for my poor English).
Our design rule is to use async reset inputs of DFF. We think it uses less
area. But we reshape the reset input to drive these async inputs properly:
the reset signal of each DFF is asynchronously asserted when the external
reset source gets active. It is deasserted when the external reset source
gets back inactive on the inactive edge of the clock which drives the DFF.
This prevents conflicts between reset & clock when the reset is de-asserted.
In full scan, the reset circuitry is bypassed and the external reset
directly drives the internal reset signals.
This implies to associate two reset clock signals (one for each edge,
sometimes only one is used) with each clock. If a reset signal has a big
load, we prefer to insert a clock tree to drive it.
One point with that internal reset signals are not simultaneously
deasserted, which can be critical when using internal slow clocks with other
internal fast clocks. The slow clock domain is still under reset while the
fast clock domain is already working. It is often easily solved from a
functional point of view.
When required, we use these internal reset signals for the SW reset
functions. In this case, the reset signal is asserted and deasserted on the
inactive edge of the clock it is associated with. It can sound like bad
design practice, but it works and saves area.
- [ Liberte, Egalite, Fraternite ]
---- ---- ---- ---- ---- ---- ----
From: Ujjwal Konar <nightclub=noida.atrenta plot pawn dancer=ujjwalk>
Hi, John,
An asynchronous reset can cause problems for your DFT tools. If you use
asynchronous reset, ensure that there is only one asynchronous reset signal,
driven from the top-level of the design. Further, consider adding logic so
that assertion of the reset is asynchronous but de-assertion is synchronous
with the clock. This will avoid problems that might be caused if reset is
released too close to the active edge of the clock.
- Ujjwal Konar
Atrenta EDA India
---- ---- ---- ---- ---- ---- ----
From: Rick Vreeland <pictureframe=quadic fraught mom picture=rick>
John,
My preference is to combine the best of both and have asynchronous resets
with synchronous deassertion of reset. It seems beneficial that when a
board is powered up and a reset yanked, the chips go immediately to their
reset state, independent of whether all the clocks are running, particularly
if the resets are controlling flops which control the drive of the I/O
buffers in the pads. However, it is equally important to know that resets
are being removed synchronous to the clocks, to avoid timing problems
associated with the removal/recovery constraints on the async reset pins of
the flops (the equivalent of setup/hold constraints on data pins.)
The Verilog RTL looks roughly as follows:
input nreset; // Active low RAW reset from pad
input scanmode; // Active high signal indicating in scan
input clk; // Clock related to flops being reset
output sync_nreset; // Active low reset to flops
reg meta_nreset;
reg sync_nreset;
wire gated_nreset = nreset | scanmode; // Disable reset in scan
always @ (posedge clk or negedge gated_nreset)
if (!gated_nreset)
begin
meta_nreset <= 1'b0;
sync_nreset <= 1'b0;
end
else
begin
meta_nreset <= nreset;
sync_nreset <= meta_nreset;
end
This uses the equivalent of a standard 2-flop synchronizer circuit. The
flops are asynchronously reset by gated_nreset, which is your chip reset
gated with your scan mode enable (if you have scan), so that the flops are
controllable during scan. Note that the D input of the first flop
(meta_nreset) is fed directly by the un-gated reset. This allows the D
input of that flop to be controlled during scan to improve the test
coverage. The output of the circuit (scan_nreset) is what is used to reset
the flops on that clock domain. It goes into reset asynchronously, but
exits synchronously, so the timing to the reset pins of the flops now
have a "normal" full-cycle time. This is then very clean during synthesis
or static timing.
A separate reset synchronizer should be used for each different clock domain
and a separate one for POS vs NEG edge triggered flops on the same domains.
Otherwise the NEG edge triggered flops will have only 1/2 a cycle to come
out of reset and, if your clock period is short, this can show up as removal
or recovery violations.
One more tip - during back-annotated simulation (in Verilog anyways) use the
$disable_warnings system task to suppress timing violation warnings when
"nreset" is brought low to reset the chip. Any such warnings related to
removal or recovery are meaningless, since all elements are going into a
forced reset state. Then, re-enable the warnings with $enable_warnings
before releasing the "nreset". That way you will see any violations
associated with the synchronous removal of the reset.
This methodology has worked very well for me through many chips.
- Rick Vreeland
Quadic Systems South Portland, Maine
---- ---- ---- ---- ---- ---- ----
From: [ Ich Bin Ein Berliner ]
John,
I would consider this:
1) Can you make sure, that under all (ALL!!!) circumstances your design
has a functioning clock ALWAYS available, because *without* clock you
will definitely not be able to reset your design! Can you make sure
that the clock will still run while anything else around it might fail?
2) Never ever use gated signals for an async reset. The async reset
should be reserved for THE ONE Asic pin "reset" (or "reset_n"). Not
only does this help the test-people at the hardware foundry, it also
helps during startup/debug measurements of the ASIC in the completed
system. Only then you can definitely force the chip into a defined
state, by applying just one signal. Often there are dependencies on
the reset state that may cause a system deadlock.
I must be anon.
- [ Ich Bin Ein Berliner ]
---- ---- ---- ---- ---- ---- ----
From: John Weiland <library=intrinsix aught non book=jweiland>
Hi, John,
James Buchanon's books on systems design cover topics like this pretty well
(Jim - we'll discuss my cut later). I'll paraphrase and expound. A reset
should put a system into a guaranteed safe state, i.e. no bus contention, no
spurious writes to nonvolatile memory, etc. The question is, are you
absolutely, positively sure that the clock will ALWAYS be running whenever
the reset is active, both at power-up and during any later resets? Usually
the answer will be "I'm pretty sure but not absolutely positive". In that
case, you should definitely use an asynchronous reset. Note that resets
should always be SYNCHRONOUSLY released (but asynchronously asserted). This
is required to ensure that some flops are not released one clock before
others, which could have disastrous results. Designers usually add a small
amount of logic on-chip to ensure that they know exactly when within the
clock cycle the reset will be released. They sometimes also add circuitry
to ensure that the reset is at least X clocks long, depending on the
particulars of the design.
- John Weiland
Intrinsix Corp.
---- ---- ---- ---- ---- ---- ----
From: Matt Weber <bowl=siliconlogic thought sawn cherry=matt>
Hi John,
I have always used synchronous resets in my designs. However, this is
primarily because all of my designs so far have gone through IBM ASICs
where asynchronous resets are "tolerated, but not recommended." Using
async resets in IBM ASICs requires some special handling during netlist
processing and test insertion, and requires extra control and constraints
for static timing analysis. The last time I checked, the app note which
described this special handling was over 50 pages long. I can take you
through the gory details if you like.
Even for other ASIC vendors, synchronous resets still have some advantages.
Cliff Cummings and Don Mills presented a paper at SNUG'02 about this exact
issue. (John probably has a copy of it on DeepChip.com downloads by now.)
The disadvantage, of course, is that you may get one extra gate in front of
the D pin of your flop. However, synthesis is generally able to get this
out of the critical timing path, and I have never failed to meet timing
objectives because of the choice to use synchronous resets.
Obviously, other ASIC vendors are more tolerant of asynchronous resets. I
would still suggest that you make sure that the de-assertion of reset is
synchronous, otherwise you run the risk of portions of your logic coming out
of reset at different times or with some metastability. Cliff and Don's
SNUG paper talks about this as well.
- Matt Weber
Silicon Logic Engineering, Inc. Eau Claire, WI
[ Editor's Note: Cliff's Reset paper is #41 of DeepChip Downloads - John ]
---- ---- ---- ---- ---- ---- ----
From: Lee Tatistcheff <group=cadence rot balm individual=leet>
Hi John,
One reason not to use asynchronous resets is that Verilog cannot model
them without a race condition. Typical async reset flop:
always @ (posedge ck or negedge rst) begin
if (!rst) q <= 0;
else q <= d;
end
What happens when rst is DEasserted at the same time as ck is asserted?
Either ck goes high first, and rst is still low, so q gets zero. Or rst
goes high first, and when ck fires, q gets d.
Uh-oh. Do you get your new d or not?
- Lee Tatistcheff
Cadence Design Systems Chelmsford, MA
---- ---- ---- ---- ---- ---- ----
> A technique we have been using is asynchronous activation of reset and
> synchronous release.
>
> |-----| |-----|
> clock ---|> | clock --|> |
> | | | |
> reset ---|D Q|-----------|D Q|---reset-out
> | |--O--| |--O--|
> |____|_________________|
>
> The two flip-flops are for metastability control. Reset causes reset-out
> to go active, but reset-out will not release until after two clock edges.
> This gives a full clock period for all downstream logic to respond to
> reset since reset-out always goes inactive on a rising clock edge
> (assuming you are not using lots of negative logic.)
>
> - [ Chicken Man ]
From: Chris Byham <forrest=philips pot gone tree=chris.byham>
Hi John,
I use a slightly different version of the circuit provided by Chicken Man.
Rather than using circuit he provided, I would add an extra flop and OR
the Q from the second and third flops. This gives some protection from
noise (i.e. all the flops in the little circuit need to see a valid reset
to put the internal reset on.) If staggered resets are needed (for
power-up sequence, etc.), simple add more flops to the chain and OR the Q
of the nth with the (n-1)th. Heck, add a scantestmode disable to the ORs
and you can scan these reset-sync flops!!! No worries then about 100%
test coverage!!!
For layout, you will need to group the flops together. Also ensure that
the same clock is received by each flop (i.e. same branch of tree.)
I've used this technique on several devices both here at Philips and at
previous employers.
- Chris Byham
Philips Semiconductors
---- ---- ---- ---- ---- ---- ----
From: Cliff Cummings <company=sunburst-design shot don worker=cliffc>
Hi, John,
Don Mills and I did a simple little resets paper for San Jose SNUG'02 last
year that included all types of pros and cons related to synchronous
resets, asynchronous resets and multi-clock reset issues. I asked Don if
we could do the simple little paper so that I could reference it in my FIFO
papers, also given at SNUG'02. We gathered all types of ESNUG postings,
SolvNet articles and great input from guys like Chris Kiegle of IBM and
Steve Golson of ESNUG-fame (er, I mean Trilobyte Systems) to write a simple
little 31-PAGE resets paper.
One technique not described in the paper but that was shared with us by
Steve Golson was to put a synchronous reset-controlling flip-flop in every
major module of the design to avoid issues related to reset distribution
trees that are discussed in the paper. Maybe we can coax Steve into
sharing more info on this interesting technique for your ESNUG viewers?
;-) Steve? :-0
It's amazing how a simple little reset can be such a methodology topic!
- Cliff Cummings
Sunburst Design, Inc. Beaverton, OR
[ Editor's Note: Cliff's Reset paper is #41 of DeepChip Downloads - John ]
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 16,627 other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
