Editor's Note: That's it. My cynicism meter has maxed out. I have no
faith left in humanity. You know that recent Steven Spielburg movie
"Amistad"? It was a movie about the trial that followed when a slave ship
from Africa had a revolt on it. The revolt was led by an African named
"Cinque" and the trial was whether or not the slaves had the right to be
free to return back home to Africa or not. Big drama. Lots of scenes
showing the horrors of slavery and Politically Incorrect Evil White Men
being overtly and covertly evil. The drama even involved historical U.S.
bigwigs like Adams & Van Buren. In the end, the Supreme Court decides
that the slaves can return home. Typical Hollywood. Good triumphs over
evil. Nothing new here. What got me pissed was the rest of the story.
When I went to the library to check out how much of this movie was truth
& how much of it was Hollywood, it turns out that, when "Cinque" returned
to Africa, and after all that, he set himself up as a slave trader!
I have no faith left in humanity. My cynicism meter has maxed out.
- John Cooley
the ESNUG guy
P.S. For those not wanting to be left proceedings-less, I recommend you
get your SNUG'98 registration in by this Friday (tomorrow) because I
heard they already have 517 pre-registrants and made only 700 copies of
the SNUG'98 proceedings. Those pre-registered get first dibbs on the
proceedings. Those left proceeding-less might be just as cynical as I.
( ESNUG 283 Item 1 ) ------------------------------------------------ [3/5/98]
Subject: ( ESNUG 282 #10 ) Formality's Independence From Design Compiler
> I need your insights on Formality, Synopsys's new equivalence checker.
> Questions have been raised by Synopsys competitor Chrysalis about the
> independence or lack thereof of Formality from Synopsys's Design Compiler
> synthesis tool. How much of an issue is Formality's reliance on DC? Is
> Formality going to allow the same faults to slip through that DC allows?
>
> - Chad Fasca
> Associate Editor
> Electronic News
From: [ Someone Who Knows A Little Something About FV Tools ]
John,
Please keep my name in confidence - in a former life, I worked on [ All
Sorts Of Great Yet Identifying Creditials Deleted ].
With respect to Formality's dependence or independence from DC: if you want
to compare RTL to gate-level designs, you must synthesize the RTL to gates,
then check those gates to the user's gates. (Got that? -- you start with
RTL and gate1 -- you synthesize RTL *to* gate2, *then* compare your gate2 to
the user's gate1. There may be other ways to do the comparison in theory,
but they all break down pretty quickly.)
Given the above scheme, you have a couple of problems:
1) Language synthesis, while not rocket science, isn't trivial. To
develop one from scratch isn't much fun. Would you write a
completely new one, if you had the industry-standard version already
available to you? (This is the basis of the Chrysalis complaint.
Formality may use the same (or similar) code to do language
synthesis as did DC, thus, errors introduced in the DC synthesis
step will be replicated in the Formality synthesis step, and thus
won't be caught. I don't know whether Synopsys used the same code
or not.)
2) If you do choose the "let's write one" language synthesis route, you
have a bunch of new problems. Amongst them:
- language interpretation: some corners of the language are
ambiguous (or, at least DC takes an "interesting" interpretation).
Do you match DC, or the simulator? Folks will complain, either
way. (Let me know, if you want specific examples.)
- worse, interpretation can depend on compiler directives (pragmas),
which can (and do) affect the systhesized result. ("synopsys
full_case" and "parallel_case" are the most obvious examples).
Now, not only do you have to match [relatively standard]
languages/language subsets, but also completely non-standard
(and potentially copyrighted) compiler directives -- not all of
which are well documented.
- More interpretation: FSMs - what do you do when/if DC re-encodes
the FSMs? (...and, for an implicit FSM, where there is no explicit
encoding.) How do you find the state variable flops, if the
synthesis tool doesn't tell you where it put them, in the gate1
netlist?
3) Equivalence checking algorithms: Sadly (or happily, depending on your
perspective), the time/memory/whatever required for equivalence
checking is proportional to the SIMILARITY between the designs - not
on their size or the function they implement. For example, it is not
hard to compare multipliers, if you know that they are multipliers
(not buried in logic), and expecially if you know the algorithm they
use. Similarity comes up in spades, if you try to compare FSMs which
use a different state encoding (or, equivalently, in pipelined logic,
if the synthesis tool has done extensive retiming & re-optimization).
Again, there is no problem if you happen to pick the same encoding as
DC (but how do you do that, if you are a separate vendor, and don't
have hooks into DC?), or know how DC did the encoding.
Hmm... this is getting long. Lets change gears for a minute:
Last issue is really a marketing one: why do customers purchase Formal
Verification tools? If it is just to check whether Synopsys did the right
thing, how many do you think you can sell? If you find Synopsys bugs,
great -- then Synopsys fixes the bug (maybe)....eventually, you turn into
a Synopsys QA tool -- and only Synopsys really needs to buy one. (i.e.,
your value tends to decrease over time).
Next issue: given that your sales as Chrysalis may be limited, how many
resources do you really want to pour into development? As described above,
keeping up to DC may or may not be so straightforward. Synopsys has a much
larger market, and thus can afford to but a lot more people into developing
DC than you can afford to put into yours to keep up. And if you don't keep
up, your tool is going to give more "can't solve" messages - thus becoming
less valuable, over time. So you need to customers to have another set of
reasons (aside from Synopsys QA) to buy. And those reasons would be... ?
Do I think that there are viable FV product opportunities? Yes. But I'm
not sure how many equivalence checking products can actually make money.
And I have real doubts about the viability of (real) RTL->gate Equivalence
Checking and even more doubts about RTL->RTL comparison (both of which
are probably more valuable than gate->gate. Unfortunately, less feasible
technically). On that front, I'd be curious to hear, if you find a customer
who used anybody's RTL->gate or an RTL->RTL EC tool, and was happy with it.
(I'm not really interested if the user had to hack the code to get EC to eat
it, or if there were severe limits on block size, design methodology, etc.)
Again, you didn't hear any of this from me.
- [ Someone Who Knows A Little Something About FV Tools ]
---- ---- ---- ---- ---- ---- ----
From: rajen@jaxom.eng.pko.dec.com ( Rajen Ramchandani )
Hi John,
As someone who has used Formality on a 2 million gate ASIC to check the RTL
to gates, I feel that I should comment.
Our design flow used DC 97.08 for compiling the designs and one of the
significant changes in this release was a new hdl reader and like all new
code this had significant bugs. There were cases in which this reader would
incorrectly read our verilog code and produce bad gates. These were being
detected by gate-level simulation.
In one instance a whole else branch of if statement was ignored. We couldn't
migrate back to 1997.01 since there were instances in which this release was
producing incorrect logic for us & these bugs had been fixed in the 1997.08
release. Also we were getting much better quality of results with 1997.08
while using the large design compile strategy as detailed in the white paper.
We asked Synopsys for a pre-release version of Formality to check the RTL to
gates, since the simulations would not be able to check all cases of errors.
After a lot of arm-twisting on our part (which I couldn't understand, since
we were going through hell out here trying to synthesize this design), we
were given a temporary liscence to use Formality and used this tool to
check the RTL to gates for equivalence. We used this to check the RTL to
gates for most blocks on the design. A couple of blocks had to be sent off
to the Formality R&D folks for further investigation of miscomparisons.
Formality did detect errors in Design Compiler when comparing the RTL to the
gates and in most cases the solution to the problem was to say:
hdlin_turbo_sequential = false
(i.e just use the old hdl reader, one more hidden swich to be added to the
list out there :-).
I feel that Synopsys has taken the trouble to address the issue of
independence of Formality and Design Compiler. I must add that in the past
I have detected the problems with the BK adders for certain bit-widths
( see ESNUG 261 #1 ) using compare_design which is within Design Compiler
itself. I think the issue is not whether both tools come from the same
company but whether they were developed by the same team. If different
teams implement the tools independently then the likelyhood of making the
same assumptions and the same mistakes are minimized.
I hope Synopsys makes this independence formal and glass walls the two
divisions to prevent common mode mistakes from entering the system. I don't
know the extent of shared code in the two tools but my experience has shown
that Formality can be used to check the results of Design Compiler. We have
taped out the design and are waiting for prototypes back from IBM. Lets see
what the lab results have to show when we get the prototypes back and power
up the system.
- Rajen Ramchandani
Digital Equipment Corporation
---- ---- ---- ---- ---- ---- ----
From: Dyson.Wilkes@swi055.ericsson.se (Dyson Wilkes)
John
Chad Fasca asked about the indepenedence of Formality from DC. A good
question that was raised at seminar I attended. The answer was that
Formality contains a number of equivalence engines of which, I think, only
one is the same as that used in DC.
The issue I have is with the RTL front-end. The interpretation of RTL into
the logical equivalent is one most frought with danger. (Maybe it is not so
bad now assuming a higher level of education in how to code good RTL.) Even
so I would would like to have any RTL checked by two independent front-ends
if I was to rely on formal tools to do away with gate level simulation.
I got the feeling that Synopsys was playing down the use of Formality in the
early stages and advocating that users start with gate-gate comparisons and
only then work back to RTL-gate comparisons as they gained experience in the
these new tools.
The big downside so far with any tool of this kind (equivalence checkers) is
that they get more tricky to use as the topology (or logic) of the compared
codes become more different. I advise Chad to take a close look at the
debugging capabilities in the tools under consideration: watch out for that
old "Not proven" problem!
I am also interesed in some figures for the scaling of performance of these
tools with circuit size. Unless the algorithms are cleaver the runtime goes
through the roof as the size increases. A good tool would be nearer linear
if at all possible.
What would be most useful is a tool that can tell me that circuit A is the
same as circuit B except that it has XYZ additional functionality! That
would be such a useful tool in this age of design re-use. Oh, yes, and it
has to cope with all sorts of nasty asych. features in the circuits, too!
- Dyson Wilkes
Ericsson
( ESNUG 283 Item 2 ) ------------------------------------------------ [3/5/98]
Subject: Help! How To Decrypt Encrypted Cadence SKILL Code?
> Does anyone know if is there exists any program to decrypt encrypted
> Cadence SKILL code? How about a Context?
>
> - Ng Tsz Kin
> Hong Kong University of Science and Technology
From: Carry Megens <Carry.Megens@nym.sc.philips.com>
When you have the debug features in cadence (try lbCeckOut("debug"))
you can pretty print (pp) any SKILL routine...
- Carry Megens
Philips Semiconductors Consumer IC, Nijmegen, the Netherlands
---- ---- ---- ---- ---- ---- ----
From: Hans van Walderveen <vanwal@natlab.research.philips.com>
To decrypt encripted skill you can use the following piece of skill:
procedure( NlDecrypt( inputFile @optional outputFile "tt")
prog( (inp out line)
if( inputFile then
unless( outputFile
outputFile = sprintf(nil "%s.dec" inputFile)
)
when( isFile( outputFile )
print( "You must specify a file that doesn't exist!!!\n" )
hiGetAttention( )
return()
)
unless( inp = infile(inputFile)
printf("Unable to open input file: %s\n" inputFile)
return()
)
unless( out = outfile(outputFile "w")
printf("Unable to open output file: %s\n" outputFile)
return()
)
while( line = lineread(inp)
when( line != t
pprint(line out)
)
)
close(inp)
close(out)
else
printf("You must at least specify an input file!\n")
return()
) ; ** if inputFile **
return(t)
) ; ** let **
) ; ** procedure **
This should work in both cadence 4.3.X as well as 4.4 and above.
To list stuff from protected context files, you need the debug (as mentioned
by Carry Megens), but that's something you may not get from Cadence.
- Hans van Walderveen
Philips ED&T/Services Eindhoven, The Netherlands
( ESNUG 283 Item 3 ) ------------------------------------------------ [3/5/98]
Subject: A Tool That Translates ANSI-C To Verilog
> I am looking for web sites which show a comparison of C and verilog.
>
> - Aravinda Gollapudi
> AT&T WorldNet Services
From: "Steven K. Knapp" <sknapp@optimagic.com>
I don't know if this is exactly what you are looking for but you might find
the following links on CompiLogic's web site interesting:
http://www.compilogic.com/c2v.htm
http://www.compilogic.com/pubs.htm
CompiLogic makes a product that converts from ANSI-C into Verilog.
- Steven K. Knapp
OptiMagic, Inc.
( ESNUG 283 Item 4 ) ------------------------------------------------ [3/5/98]
Subject: ( ESNUG 275 #1 279 #3 280 #5) Even More "I Like Module Compiler!"
> To twist an infamous quote from a former EDA CEO -- if Synopsys put
> "DogFood Compiler" on the market, would users be sending ESNUG
> testimonials about how tasty the gravy bits are?
>
> - [ A "CAD" At LSI Logic ]
From: Chris Rowen <rowen@tensilica.com>
Hi John,
Tensilica is funded venture working on high-performance IP for rapidly
growing volume markets. Our key systems customers care intensely about
five critical charateristics of design environment they may use:
* application performance - a combination of circuit-level performance and
architectural performance, measured by data throughput, power etc.
* portability - the opportunity to have the system-on-a-chip silicon built
in the most appropriate fabrication technology, as measured by cost,
performance and business terms
* adaptability to the task at hand - the opportunity to get all the
features they and no more in order to ensure optimal price
and performance.
* ease of integration - the opportunity to easily add value in hardware and
software along side the independently produced IP, and to validate the
whole system using the tools and methods with which the system design
teams are already familiar
* quality - confidence that the silicon and system produced will work as
expected on the tightest possible schedule.
We have evaluated Module Compiler as a possible key tool for use our
development. There are some key characteristics that make it attractive
for datapath-intensive IP:
* Standard Libraries: The fact that we get results, good results, from
off-the-shelf cell libraries is enormously important. Our customers get
the foundation for portability they demand, without a significant
sacrifice of performance. We resynthesize and tune each design against
a number of libraries in order to make sure we have robust micro-
architectures that will work well in a variety of different
configurations and processes.
* Turn-around time: We can take even a fairly large block (many tens of
thousands of gates) through the Module Compiler in less than 15 minutes.
This gives us unprecedented opportunity to tune the design in non-trivial
ways, making major architectural restructurings a thing of hours, not
weeks. In fact, the performance we get from improved architecture
probably far outweighs the possible circuit-level suboptimality of using
standard libraries.
* Uniform approach: We mix datapath and control arbitrarily, as needed by
the problem at hand. Module Compiler's excellent optimizations for
datapath structrues, especially adders, shifters and multipliers, means
that we get good circuits fast. More important yet, we find it pretty
easy to describe control functions in the same way, using
application-specific macros and pre-processing.Since all the interesting
critical paths run through both datapath and control logic we have a far
easier time finding and improving our logic when we synthesize as as
single unit. Any approach that requires a manual or even automatic cut
between datapath and control is likely to take too long, leave too many
optimization opportunities on the table, and lead to poor portability,
configurability and integratability.
* Conciseness: Module Compiler HDL lends itself to extremely concise,
readable, configurable, structurally-oriented logic descriptions. The
comparative clarity of representation means that one person can actually
understand a large unit, and that the number of logic bugs, even on
configurable designs, is reduced. We have done a couple of fairly large
prototype designs -- what would have been complete ICs only a few years
ago -- in less than 1000 lines of source code each. The comparative to
ease of writing and tuning this more concise code probably has saved us a
couple of months of development time versus conventional RTL coding and
implementation styles.
* Quality of Results - Module Compiler's sophsiticated datapath
optimizations are essential for the high-performance functions we're
implementing. We have had good success using Design Compiler as a
post-processor on Module Compiler output. While DC is too slow to
use in that rapid architectural exploration phase, it is so adept as a
peephole optimizer on MC output that it can still find a few
percent of critical path delay even on good circuits. The combination
turns out to be measurably and consistently better than either DC or MC
could do by itself on large complex mixed datapath/control units.
Module Compiler is not perfect, but to borrow Winston Churchill's comment
on democracy, it is can be said that Module Compiler is the worst form of
HDL tool except all the others that have been tried. ;-) Improved support
for floorplanning would clearly reduce uncertainty from statistical
wireload models. We would also like some better hooks for control logic
description, better UI and better reporting (especially for multiple
critical paths and false paths). MC has some very interesting hooks for
memory array integration -- these also need to be fleshed out and driven as
standards for RAM generators in order for Module Compiler to help full
realize the dream of portable/optimized IP.
- Chris Rowen
Tensilica, Inc.
---- ---- ---- ---- ---- ---- ----
From: "Kenneth Wagner" <kwagner@s3.com>
Dear John,
Just a short note as a first response to the great "Module Compiler" debate
you launched in the recent ESNUGs. The gentleman from LSI has written a
thought-provoking note. Unfortunately, I, too, have to weight in saying it
is quite unbalanced. He was highlighting perceived deficiencies while
making no attempt to recognize MC's advantages. Module Compiler, like ALL
tools, comes with caveats. They can be circumvented. The architects and
design engineers here at S3 used MC creatively and successfully for several
different purposes. Just my 2 cents.
- Ken Wagner
S3, Inc. Santa Clara, CA
( ESNUG 283 Item 5 ) ------------------------------------------------ [3/5/98]
Subject: (ESNUG 278 #9 281 #6) Synch Probs W/ 2 Clock Domains W/ Close Freqs
> We are suspecting that it is because of meta-stability caused by using 2
> clocks of similar frequencies. The problem cannot be reproduced in
> simulations. The synchronizing circuit looks something like this.
>
> _______ ______ _______
> in1 --->|D Q|---------->|D Q|---------->|D Q |---> out1
> | | | | | | (synchronized)
> wr_clk --|>______| rd_clk --|>_____| rd_clk --|>______|
>
>
> We have similar synchronizing circuits in our earlier ASICs. Any ideas
> as what exactly is happening?
>
> - Shashi Aluru
> FORE Systems, Inc
From: robert_c@gennum.com (Robert Cram)
John,
When wr_clk and rd_clk are the same frequency, which clock has the higher
fanout? I suspect that the rd_clk is more heavily loaded and therefore
even though wr_clk and rd_clk are the same frequency there will be some
skew between the clocks which will result in wr_clk being slightly faster
than rd_clk. This could result in the in1 data corrupting or overwriting
the data at the D input of the first rd_clk flop.
I have seen this problem in scan chains that contain more than one clock
domain but are driven by one scan clock during scan. The solution I have
used is illustarated below:
latch
_______ _____ ______ _______
in1 --->|D Q|--->|D Q|--------->|D Q|--------->|D Q |---> out1
| | -o|>____| | | | | (synced)
wr_clk --|>______| | rd_clk --|>_____| rd_clk --|>______|
|
wr_clk -------
The negative-level gated latch prevents the wr_clk data from overwriting
or corrupting the rd_clk data. I hope this helps.
- Robert Cram
Gennum
( ESNUG 283 Item 6 ) ------------------------------------------------ [3/5/98]
Subject: (ESNUG 282 #9) DesignTime - Generating SDF W/ Timing Driven Layout
> I am trying to generate the SDF for timing driven layout. For this
> we use the "write_constraints -cover_design" command. The design
> contains gated clocks, so we use the -propagate option in dt_shell.
>
> Here is a simple example:
> ____
> ------------ / \____ -----------
> | FF1 | / \__ | FF2 |
> | Q |------->| logic |------->| D |
> | | \______________/ | |
> clk --|> | clk --|> |
> ------------ ------------
>
> Both FF1 & FF2 are driven by the same clock, with delay of ~2ns. (skew
> in this case is close to zero). The setup to FF2 is 1ns. Cycle 10ns.
>
> The report_timing reports a path that starts from:
> FF1/Q at time 2ns (clock delay) + 0.8ns (delay clk to Q in FF1)
>
> and ends at
> FF2/D at time 10ns (cycle) - 1ns (setup) + 2ns (clock delay to Ff2)
>
> Which is what you'd expect. However, in the SDF generated, the path will
> start at time 0.83 (delay of the FF1 to Q) and will not include the
> delay of clk to FF1, but will take into account the effect of the delay
> to the clock to FF2, therefore generating a path which is longer in 2ns
> (exactly the delay on clock to FF1).
>
> Has anyone ran into this problem? Is there a way to bypass that? Any
> flags or other report methods?
>
> - Erez Naory
> National Semiconductor Hertzlia, Israel
From: Jonathan Liu <jonathan@ikos.com>
Hi John,
I think you might be able to workaround this problem by using the "-ideal"
option to set_clock_skew when you define your clocks. (I believe this
is the default if you don't use the "-propagated" option.) This way
the delay from the clock to FF1 and to FF2 would both be considered 0.
That's my normal methodology and I haven't run into this behavior
when generating constraints.
Of course if you use "-ideal" for clocks, you'll have to run special reports
to verify that the actual clock skew in the netlist is within the amount
defined in set_clock_skew. I usually do this by running report_timing
with both -min_rise and -max_rise options on the list of all pins driving
FF clocks (i.e. the last stage of the clock tree).
- Jonathan Liu
Ikos Systems, Inc.
( ESNUG 283 Item 7 ) ------------------------------------------------ [3/5/98]
Subject: (ESNUG 281 #5 282 #5) The Future Of FPGA Synthesis W/ Synopsys
> Synthesis is also an issue. Design Compiler for FPGA's from Synopsys
> generally is beaten out for last place by ViewLogic for quality of
> synthesis and .... should be mothballed.
From: Pavel Zivny <pavelz@mdhost.cse.tek.com>
John,
That seems to be what Synopsys is doing, if I understand it right
they plan to end up with two flavors of the FPGA Express - one will be a
pushbutton and the other will have some understading of DC scripts.
Internally both will be the 'Express', _not_ the 'Compiler'.
Not bad, but there is a downside to this: IMHO there is a value in
having one and the same tool for both the prototyping FPGA and the ASIC
you end up in eventually; and DC was the one way to do it.
Indeed there is enough value in it to justify the lower "QoR" (just
love that Quality of Result :-) for many prototyping situations - e.g. so
what if you needed to up the FPGA size, it's for the prototype only. You
could keep your scripts (mostly), and there was less of a danger that some
HDL construct would be understood differently by your asic synthesis and
differently by the fpga synthesis.
- Pavel Zivny
Tektronix
( ESNUG 283 Item 8 ) ------------------------------------------------ [3/5/98]
Subject: (ESNUG 281 #11 282 #1) Cleaning Up Dangling Gates In An IP Core
> In my design, I have a bunch of gates whose outputs are not being used.
> (A purchased core that has functionality, and thus outputs, that I don't
> need is a common way that I get dangling gates.) Are there switches in
> DC to tell it only to remove extra gates & not further optimize? I tried
> "-incremental". I tried "-incremental -only_design_rule". But DC always
> insists on further "optimizing" other logic. I added
>
> "compile_no_new_cells_at_top_level = true"
>
> (for flat designs), which was successful on some modules, but
> optimized-out needed buffering on other modules. Any ideas, anyone??
>
> - Rick Weiss
> NABLE Technologies Cupertino, CA
From: [ Nowhere Man ]
John,
While browsing through the Synopsys Synthesis Quick Reference Guide the
other day, I noticed the following command:
dc_shell> set_compile_directives -help
Usage: set_compile_directives
<object_list> (list of objects)
-delete_unloaded_gate <flag> (true or false)
-constant_propagation <flag> (true or false)
-local_optimization <flag> (true or false)
-critical_path_resynthesis <flag> (true or false)
I remembered your post in ESNUG 281, and thought this might help you out.
Perhaps something like a "set_compile_directives <design> -delete true
-constant true -local false -critical false" followed by an incremental
only-design-rule compile would do the trick?
BTW, John, I wish to remain anonymous.
- [ Nowhere Man ]
( ESNUG 283 Item 9 ) ------------------------------------------------ [3/5/98]
Subject: (ESNUG 282 #3) Anyone Using Summit/Mentor's Text->Graphics Tools?
> ... If these examples of mixed blocks of VHDL and Verilog continue to turn
> up, don't you think designers will begin solving the problem this way?
> Or, alternatively, use a product like Renoir to convert the unfamiliar
> language IP block to graphical form and then recompile in their language
> of choice?
>
> - Wally Rhines, CEO
> Mentor Graphics
From: "Reams, Byron" <byron@xgate.columbiasc.ncr.com>
John,
I'm curious... Is anyone out there really doing that? By that I mean
are the tools mature enough that they can actually capture the design
(ie. state machines, flow charts, truth tables, etc.) correctly without
alot of hand-holding (or even with alot of hand-holding for that matter).
I know Mentor was promising that the next release of Renoir would attempt
this but the current version only builds block diagrams from the structural
elements of the code. I know that Summit claims to be able to do it.
What I want to know is this: Is anybody out there using the Summit
tool, or any other tool, for real text to graphics conversion. Not just
to capture the hierarchy of the design with a bunch of block diagrams, I
mean real text to graphics, creating bubble diagrams from state machine
code.
- Byron Reams
NCR Columbia, South Carolina
( ESNUG 283 Item 10 ) ----------------------------------------------- [3/5/98]
From: Tomoo Taguchi <tomoo@sdd.hp.com>
Subject: Anyone Have A Grocery List Of Low Power Design Issues?
John:
I was wondering if you could give me a quick pointer. I'm looking for a
reference for doing low-power designs. Does anyone have a grocery list
of low-power design guidelines? I'm looking for something along the lines
of design guidelines for testability (i.e., don't gate clocks, avoid
latches, etc.) To not be too demanding, I'm just looking for a list, not
an extensive tutorial. I'm just trying to jog my memory.
- Tomoo Taguchi
Hewlett-Packard
|
|
