Editor's Note: Damn. Sorry. Please pardon my French. I didn't mean
to cuss there. I'm on one of my usual business trips to Silicon Valley
this week. Last Saturday, I got together with some old friends here. My
old lab partner from college was one of them. For the past few years he
worked for a start-up that never went public. It kind of soured him on
the whole slave-for-a-start-up-and-get-rich idea. So now he works as an
engineer at a big, stable, established company in Silicon Valley. Yet,
this month, he's doubled his personal net worth investing in IPO's!!!
Whoa. Now his catch phrase is "Why bust your hump slaving for a start-up
when you can make the same money investing in them!" Now he's even
seriously thinking of putting a second mortgage on his house for extra
money to put in the stock market. I hope we successfully talked him out
of it. Hmmm... Man... Doubling his personal net worth in less than
a month... Damn. I can see his temptation. Damn...
- John Cooley
the ESNUG guy
( ESNUG 336 Subjects ) ------------------------------------------ [11/99]
Item 1: ( ESNUG 331 #1 ) FlexRoute's Hierarchical Approach Questioned
Item 2: ( ESNUG 323 #16 ) What Are Your Thoughts About ACS In DC 99.10 ?
Item 3: Two Xilinx Engineers Defend Their Company's "New" Web Presence
Item 4: Running In 2-State; An Easy Way To Speed Up Your VCS Runs By 50%
Item 5: Ten User Letters Discussing 13 Mixed-Mode / SPICE-Oriented Tools
Item 6: ( ESNUG 329 #7 330 #5 ) Getting *Signed* Comparitors w/ DC 99.05
Item 7: ( ESNUG 331 #7 333 #7 ) IBM Has Similar Interoperability Issues
Item 8: ( ESNUG 335 #8 ) Downloadable Past SNUG Proceedings Are On Line
Item 9: ( ESNUG 335 #9 ) An RTL-C Rival Critiques Synopsys SystemC Idea
Item 10: Is There Any Other Better Way To Insert BIST That I'm Not Seeing ?
The complete, searchable ESNUG Archive Site is at <http://www.DeepChip.com>
( ESNUG 336 Item 1 ) -------------------------------------------- [11/99]
Subject: ( ESNUG 331 #1 ) FlexRoute's Hierarchical Approach Questioned
> For FlexRoute itself, our 3 Mgate ASIC with 23 top-level blocks and over
> 7,000 nets had routing runtimes of 30 minutes (for preliminary top-level
> routes during pre-tapeout timing checks) & 60 minutes (for full top-level
> routing with all preroutes and design data for tapeout-quality layout,
> including tuned clocks.) By comparision, our old Compass tools used to
> take 24 hours just to route a smaller sized design!
>
> This massive improvement allowed us to iterate many more times for optimal
> timing and area utilization than we were able to do before.
>
> We iterated on the top-level clock network approximately 50 times for
> the optimal skew characteristics. These changes were made in the
> FlexRoute database (instead of in a layout database), -- so that new
> changes to the netlist for timing and functionality did not disrupt the
> ongoing effort in clock tuning the top-level network.
>
> - Sam Appleton
> SGI Mountain View, CA
From: [ Jumpin' Jack Flash ]
To: "Sam Appleton" <sama@groovy.mti.sgi.com>
Hey Sam,
That was a *really* interesting article you posted to ESNUG 331. I enjoyed
reading your review of FlexRoute. Thanks. I'm glad that I am not the only
one who appreciates the value of ASCII database and file formats!
At my company, we were big COMPASS users (since 1983!!) and so we had a
great deal of infrastructure/knowledge which hinged on being able to "get
in there and hack". Now we have moved over to Cadence (gak!) we feel
somewhat held at arms length from our data.
We, too, have found that Cadence have little to offer in the way of top
level block routers not to mention floorplanning! We shyed away from IC
Craftsman as it was yet another P&R world with yet another database
required yet more techfiles. In the end we managed to get Avanti's
Planet-PL to talk to Cadence's Silicon Ensemble and then used Apollo to do
the top level block routing. I think we may give up on Silicon Ensemble
altogether before too long!
I like the sound of FlexRoute -- I think I had better go and give Synopsys a
call.... (The whole world seems to be turning purple!)
- [ Jumpin' Jack Flash ]
---- ---- ---- ---- ---- ---- ----
From: "Sam Appleton" <sama@groovy.mti.sgi.com>
To: [ Jumpin' Jack Flash ]
> At my company, we were big COMPASS users (since 1983!!) and so we had a
> great deal of infrastructure/knowledge which hinged on being able to "get
> in there and hack". Now we have moved over to Cadence (gak!) we feel
> somewhat held at arms length from our data.
We felt the same way since we went through the same progression. Our last
design used Compass, and I love Compose. Cadence doesn't have anything
similar, which really sucks. Cadence was a big surprise to us since the
tools' DB is binary although they do have DEF, which is a kind of limited
IC language. We did a lot of work with DEF and you can do it that way,
it's just a bit harder. The thing I like about Cadence/Avanti P&R is
fixed connectors -- Compass doesn't like fixed connectors after going
through "adjust topology", but Cadence/Avanti works with fixed floorplans,
which is better for me. We had some real Compass experts around and
we could never get fixed connector placement/adjust to work. Plus Compass'
density is not that great -- Cadence/Avanti are much better on that front.
> We, too, have found that Cadence have little to offer in the way of top
> level block routers not to mention floorplanning! We shyed away from IC
> Craftsman as it was yet another P&R world with yet another database
> required yet more techfiles. In the end we managed to get Avanti's
Exactly what we found. IC Craftsman is a kind of converted tool to make it
try and work for ICs, and it shows.
> Planet-PL to talk to Cadence's Silicon Ensemble and then used Apollo to do
> the top level block routing. I think we may give up on Silicon Ensemble
> altogether before too long!
I think SE and Avant! are probably decent solutions for block-level work,
although they can really stink (I haven't used Avant!s P&R tools yet). If
you're using hierachy though, they really don't work at the top-level at
all. Does Avanti have a top-level floorplanner/router -- they probably
just use their cell-based router at the top-level, I bet... FlexRoute does
have the advantage over cell-based routers because it is tuned for top-level
work in which nets go generally over greater distances than block-level
nets. It also has features tuned to IC work for floorplanning.
- Sam Appleton
SGI Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: [ There's A Sucker Born Every Minute ]
Dear John,
It's a big no-no to write you at my company. Please keep me an anon.
I've been doing P&R for years. Let me let you in on two foundry secrets.
The first secret is that the average design today is 200 to 300 kgates. We
tell our customers that our average design is 750 kgate to 1 million gates,
because that's what our customers want to hear and what our Marketing
department tells us to say. Reality is 200 to 300 kgates.
The second secret is Avanti easily does place and route on *FLAT* designs
of 200 K instances in 24 hours. YOU DON'T HAVE TO DO ALL THAT HIERARCHICAL
CRAP SYNOPSYS IS PUSHING!!! Sam could have intelligently partitioned his
750 K instance design into four parts by hand and Avanti could take it from
there. No brainer. Kick off Avanti on 4 workstations with lots of CPU
cycles and memory. Come back the next morning. Glue the 4 parts together.
Your final detailed placement and routing is done. FlexRoute and its
complicated hierarchical games are a waste of engineering time and money.
Aart should give a big bonus to the slick Synopsys salesman who sold
FlexRoute to SGI. They didn't need it.
- [ There's A Sucker Born Every Minute ]
---- ---- ---- ---- ---- ---- ----
From: [ Party Like It's 1999 ]
John,
Tell Sam good review. Lots of details. Please ask him whose placement
tools he used. He nixed Avanti and Cadence for routing, but said nothing
about what he used for placement. Did he use Qplace, Avanti, or Chip
Architect? Aristo? Anon. pls.
- [ Party Like It's 1999 ]
( ESNUG 336 Item 2 ) -------------------------------------------- [11/99]
Subject: ( ESNUG 323 #16 ) What Are Your Thoughts About ACS In DC 99.10 ?
Since the Synopsys marketingdroids have been yarping about Automatated Chip
Synthesis (ACS) being included in DC 99.10, I thought it would be a good
idea to post this user quote:
"Synopsys Automated Chip Synthesis (ACS) automates a "Partition and
Budget" flow. This scalable top-down approach means that synthesis
goals defined at the top level are automatically translated to lower
levels. Constraints and scripts are automatically generated to
implement a fully automated divide and conquer methodology. ACS
achieves faster run time through parallelism. It has a fully automated
interface to LSF and GNUmake queuing packages. ACS affords automated
design-data management. As an example of an ACS application Synopsys
cite a 2-Million gate graphics chip with 1.5M synthesizable gates and
5 clocks ranging from 33MHz to 100MHz which synthesizes on 7 CPUs in 8
hours. It achieves a 3% area reduction and a 15% timing improvement
over DC??"
That quote was from the responses to my DAC'99 user survey 4 months ago. My
questions to the ESNUG readers are: 1) Are you using ACS now? 2) What do
you think of it? 3) Is it useful/lame/in-between?
- John Cooley
the ESNUG guy
( ESNUG 336 Item 3 ) -------------------------------------------- [11/99]
Subject: Two Xilinx Engineers Defend Their Company's "New" Web Presence
> Switch to the quasi-EDA world of FPGAs and the web panecea hits new
> heights with "Club Xilinx" -- the ultimate in web corporate con games to
> make our over-weight welfare mom appear to look like Pamela Lee Anderson.
> Go to <http://www.xilinx.com> and ask yourself: "What has fundamentally
> changed with Xilinx FPGAs or software?" -- and you'll see it's 98 percent
> hype, renaming, repackaging, and propaganda. Yeach.
>
> - from Industry Gadfly "Heads Up! Elephants!"
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
John,
What in the world are you talking about? The "Club Xilinx" part of our web
site was only for the few weeks surrounding DAC and did provide interesting
webcasts presentations from Geoffrey Moore, John Chambers, Aart deGeus,
Scott McNealy and our CEO Wim Roelandts.
I don't believe that we've had a splash screen up for quite sometime now on
this and I'm sure that we never promoted it as a change in FPGA or Software.
It's all still there at http://www.xilinx.com/company/tradeshows/dac99.htm
I've thought that we've been doing a real good job with our web site and
even added the http://support.xilinx.com site which is purely technical.
The answers database and applications note sections grow daily and there are
a lot of resources there including the software manuals.
If you really want to see what has changed in FPGAs, then bring up
http://www.xilinx.com/products/virtex.htm
If you want to see what has changed in software, our WebFitter, then bring
up http://www.xilinx.com/products/software/software.htm
If you want to see what's new for IP Cores and reference designs, bring up
http://www.xilinx.com/ipcenter/index.htm
If you want to buy the software or a training course then bring up
http://toolbox.xilinx.com/cgi-bin/xilinx.storefront
If you want details on the webcast training course then bring up
http://www.xilinx.com/support/training/E-Learn_sched.htm
The meat is there John, I just don't see what your beef is about.
- Ed McGettigan
Xilinx
---- ---- ---- ---- ---- ---- ----
From: "Dennis Rose" <Dennis.Rose@xilinx.com>
John,
You know I look forward to the joy of reading your ESNUG emails and of
discovering what witty wisdom has been humorously embedded there. But you
missed some of the real changes happening regarding Xilinx FPGA designs,
the power of field upgradability and increasing access over the Internet.
An engineer can extend the life of a product by including the ability to
download updated bitstreams to FPGAs. An engineer can do this through
a number of mechanisms including downloading across the web. We've had
customers report multimillion dollar savings in hardware upgrades or fixes
which would have been required due to changing standards or conditions.
These savings were had because of the ability to send new bitstreams to
their Xilinx FPGAs.
Xilinx's internet based Silicon Xpresso initiative includes the Webfitter,
a free web-based CPLD design fitting software tool that allows engineers
to fit and evaluate designs in minutes over the web without having had
to download software. The CORE Generator links over the net to get latest
released COREs. See:
<http://www.xilinx.com/products/software/sxpresso.html>
<http://www.xilinx.com/sxpresso/webfitter.htm>
<http://www.xilinx.com/products/logicore/coregen/index.htm>
The Internet is sexy and productive. It's rocking our world. It's OK to
use it in the context of offering tools for product life extension
flexibility in the face of fast paced change.
- Dennis Rose
Xilinx
( ESNUG 336 Item 4 ) -------------------------------------------- [11/99]
From: [ A Synopsys VCS CAE ]
Subject: Running In 2-State; An Easy Way To Speed Up Your VCS Runs By 50%
Hi John,
I'm a CAE for VCS. I'd like to tell your readers about running VCS in
2-state mode because it can speed up their simulation runs by 50 percent
if it's the right type of Verilog.
In 4-state simulation there are four values for each signal (0,1,X,Z) with
different strengths for each logic level, thus yielding 120 different signal
values. In 2-state simulation, 0 and 1 are the only simulated values, and
the X and Z values in the simulation get mapped to 1 and 0 respectively.
(Obviously this would yield much better simulation performance, since the
simulator has to do much less work per signal.) Turning on the 2-state
option is as simple as adding a "+2state" flag to your VCS command line.
Synthesizable RTL (as opposed to gate-level designs) designs are good
candidates for 2-state simulation. (Many vendors have lots of X's and Z's
in their ASIC libs.) Also, gate-level design are more delay dominated, so
cleaning out X's and Z's probably won't help much.
At the same time some care has to be taken by the user to ensure that X's
and Z's do not affect your simulation's correctness.
VCS does some work to ensure that some strength related constructs such as
pullups, tri, bufif's, etc., maintain their 4-state values. VCS will also
resolve tri-state nets with multiple drivers using a logical "OR". In
addition, it is possible to specify signals that should retain their 4-state
values even while running VCS in 2-state mode. One way to do this is to
embed in your Verilog a directive to keep a signal 4-state no-matter-what.
reg /*4value*/ vec_reg;
(Upcoming versions of VCS will also allow you to specify which modules
should be simulated in 2-state or 4-state.)
Use the compile time switch "+warn2val" to list cases of strength constructs
which may cause simulation mismatch. Some common mismatch issues:
- a frequent sim problem occurs when using a register before it is
initialized through a reset sequence. In 2-state, uninitialized
registers are assigned value 0 (thus creating a negative edge
transition on these registers at time 0). If this negedge transition
is used elsewhere in your design, it could yield a simulation mismatch
that might have not happened using a 4-state simulation. The trick here
is you should initialize all registers using a reset sequence at the
beginning of *any* 2-state simulation run.
- If the Left Hand Side is user specified to be 4-state, the Right Hand
Side must also be 4-state for the Left Hand Side to get the 4-state
values. Example:
reg /*4value*/ vec_reg;
reg ralph;
always @(posedge clk)
vec_reg <= ralph; //RHS is still 2-state !
What I'm saying is that even though you say vec_reg is 4-value, in
a 2-state run, since "ralph" is set to run 2-value, vec_reg will
only take on 2 values. Be aware of this.
- Watch out for casex / casez in your Verilog source. In 2-state, X
is seen as a 1; Z is seen as a 0. Example (assume "selector = 0X") :
reg [1:0] selector;
casex(selector) // assume "selector = 0X"
8'b00: // gets matched in 4-state, but not in 2-state
8'b01: // gets matched in 2-state (4-state also matches,
// but in 4-state the first item is taken)
But let "selector = 0Z"
reg [1:0] selector;
casez(selector) // assume "selector = 0Z"
8'b00: // gets matched in 2-state, but not in 4-state
8'b01: // doesn't get matched in either 2-state nor 4-state
Moral: CAREFULLY watch those casex's and casez's in 2-state mode!
I recommend you make signals like "selector" 4-value to be safe.
- Watch those memory data files containing X and Z values. The values in
the memory data files read in through $readmemh, etc., which have X and
Z values would get mapped to 1 and 0 in 2-state unless the memory is
explicitly tagged as 4-value.
- Plan for 2-state simulation while writing testbenches.
- Never leave control signals at X or Z in 4-state; use a proper reset
sequence at the beginning of any simulation.
- Minimize the number of signals tagged as 4-state in your 2-state
simulation for maximum benefit.
- Use the compile time switch "+warn2val" to report potential issues with
strength resolution.
In summary, many synthesizable RTL designs that don't involve strength
modeling have the potential to simulate much faster in the 2-state mode,
with a few simple changes. You may also want to read the section titled
"Modeling For 2-State Simulation" in the VCS Users Guide.
- [ A Synopsys VCS CAE ]
( ESNUG 336 Item 5 ) -------------------------------------------- [11/99]
Subject: Ten User Letters Discussing 13 Mixed-Mode / SPICE-Oriented Tools
> I'm interested in any tool (shareware, commercial...) which can read in
> and display files in Raw SPICE format.
>
> - Martin Seifert
> Siemens / Infineon AG
From: Duncan Crowther <duncanc@euro-eda.com>
SynaptiCAD has recently added a SPICE import feature to their product
WaveFormer Pro that provides a waveform display of SPICE CSDF files.
We distribute SynaptiCAD products and you will find details at
http://www.euro-eda.com
- Duncan Crowther
EuroEDA Ltd. UK
---- ---- ---- ---- ---- ---- ----
From: Jim_Thompson <Jim_T@analog-innovations.com>
I think most commercial versions of Spice can read CSDF files. I know
that both PSpice and SmartSpice can.
- Jim Thompson
Analog Innovations, Inc. Phoenix, Arizona
---- ---- ---- ---- ---- ---- ----
From: "Eckhard Hennig" <hennig@itwm.uni-kl.de>
I'm not sure what you mean by "raw SPICE format", but in case you are
referring to CSDF files (Common Simulation Data Format, produced by some
SPICE derivatives such as HSPICE and PSpice), you may want to check out our
circuit analysis toolbox Analog Insydes for Mathematica. The toolbox has a
CDSF reader, which allows you to import SPICE output into Mathematica and
postprocess it in any way you like.
If your interested, there is a free evaluation version available on the web
at http://www.itwm.uni-kl.de/products/ai
- Eckhard Hennig
ITWM Kaiserslautern, Germany
---- ---- ---- ---- ---- ---- ----
From: han@ice.el.utwente.nl (Han Speek)
Hi Martin,
You probably know about Nutmeg already, as this comes with the Berkeley
Spice3 (which I assume you have as this produces -- and defines -- the raw
format).
If Nutmeg is too simplistic to serve your needs, you should do a Web search
for Sigview, which was written by Lisa Pickel at the Microelectronics Center
of North Carolina (MCNC). It used to be available on their website
(mcnc.org) but it no longer seems to be there. But I've seen it on various
Linux sites. It's free, can handle a number of formats (including of course
raw Spice), and best of all, it comes with source code so you can adapt or
enhance the program to your needs :-)
I just checked - you can still pick up the Sigview distribution from MCNC,
but no longer from their website, only ftp.
It's at ftp://ftp.mcnc.org/pub/VLSI/sigview.new.tar.Z
- Han Speek
Univ. of Twente Enschede, The Netherlands
---- ---- ---- ---- ---- ---- ----
From: Cecil Aswell <aswell@ix.netcom.com>
Look up hsview at
http://www.eleceng.adelaide.edu.au/Personal/moini/hsview/index.html
There are binaries for linux available.
- Cecil Aswell
---- ---- ---- ---- ---- ---- ----
From: gipson@cts.com ( Larry Gipson )
I actually purchased the Intusoft suite earlier this year and returned it.
The schematic capture was totally unusable for what I do. It looked to have
a nice simulator, but I never got that far.
I would like to have the capability of doing some more advanced post
processing on my SPICE output files. For instance, I would like to be
able to do an FFT to look for linearity, or to predict the noise
performance of a switched capacitor circuit including aliasing. These
capabilities would have to be programmed in so that they would be easy
to use.
I was thinking about switching my work environment over to Linux since
it's likely more stable than WinNT. If I ever find reasonable software to
allow me to do this, I will. I would buy the latest Sparc station, but
who can afford $100K worth of software?
So far, the following software has been mentioned:
SynaptiCAD - appears to be a simple waveform viewer suitable for
digital simulation. It does have support for Win95/98 and Unix, though
the support for Linux appears thin.
PSpice - I use an older version of Pspice since I never could stand
the schematic capture tool when it went to Windows. The problem is
my version doesn't support the latest BSIM3v3 model, which everyone
appears to be going to. The waveform viewer is called Probe, and is
very limited in post processing features. On the up side, the built
in digital/mixed mode simulation capability has been extremely useful.
SmartSpice - I thought about this. They want $7k for a copy of their
software that will support twin processors in my NT box. It has no
digital simulation capability beyond the transistor level. The post
processing capability of their viewer is not clear from the web page.
No schematic capture is bundled with the simulator (perhaps a
feature?). Appears to support Unix and WinNT, but not Linux. Is it
really that much better than the free stuff from Berkeley?
Analog Insydes for Mathematica - This is interesting. I don't own
Mathematica so I can't try it. It might, however, do the post
processing I'd like in the viewer.
Nutmeg - Unix based, simple waveform viewer from what I've read. The
good part is that it's free.
Sigview - There are two programs with this name on the net. One is a
data acquisition / FFT program and the other is source code for
something totally undefined. This might be a cheap way out if I had
the time to remember how to program in C and purchased a compiler.
Hsview - This sounds like viewer that comes with unixed based Hspice.
I hope not, because that one is just awful. Come to think of it that
was Hsplot and Gsplot as I remember (there were two programs, one
third party). Neither came close to the viewer that came with Avanti.
There was a program called Hsview that came with the DOS based Hspice
I used for a while. It looked nice, but couldn't do all the post
processing I would like to be able to do. One big problem is that
Hspice didn't supply the font it needed when they sent it to me. All
of the text on the graphs somehow became Greek symbols!
If anyone has any ideas on this, please share them!
- Larry Gipson San Diego, CA
---- ---- ---- ---- ---- ---- ----
From: Mike Seningen <mikes@evsx.com>
About all I can speak for is that Smartspice is a pretty good simulator.
I like it much better than Hspice which I used for 6+ years.
I believe they do have a Linux version.
The graphical viewer is decent and there are a lot of post processing
capability -- though I have only used a little bit of it.
- Michael Seningen
EVSX, Inc. Austin, Texas
---- ---- ---- ---- ---- ---- ----
From: "John Cain" <jjcain@goodnet.com>
I am also an independant analog/mixed mode IC designer and have the same
problem with IC tool costs. One of the best kept secrets in the IC industry
is the affordable Tanner Ledit Pro suite of tools for IC design. The Tanner
tool set covers the IC design needs from spice simulation to Layout & LVS
verification. Tanner T-Spice Pro is a high performance spice which handles
all the IC model cases including level 49. Simulation results are
equivalent to HSpice. T-Spice Pro includes Sedit schematic capture and is
nicely integrated with T-Spice Pro. Sedit is designed for IC design and is
completely integrated with the remaining Pro tools (layout, extract & LVS).
T-Spice is around $2.5-5k.
A second recommendation is Penzar TopSpice a high speed mixed mode
simulator. TopSpice uses a mixed mode spice simulation approach mixing a
spice 2G simulator with a digital simualtor resulting in a dramatic speed
up over traditional simulators with digital functions. TopSpice has an
integrated schematic editor which allows one click schematic to spice
simulation. TopSpice recently added Bsim3.3 models which allow level 8 and
level 49 simulations for IC designs. TopSpice also has a Spice3 simulator
(without digital simulator) that also works well with IC designs. TopSpice
is around $500.
I use both spices for full chip or subsystem simulations on mixed system
ICs and get excellent results.
TopSpice is a great all around simulator - especially when you are in a
hurry. T-Spice is more of a pure IC designer Spice with good integration
with Tanners Standard cells and verification tools.
I recommend both highly.
- John Cain
Power Processing, Inc. Phoenix, AZ
---- ---- ---- ---- ---- ---- ----
From: gipson@cts.com ( Larry Gipson )
Thanks John!
I am laying out a chip right now with Tanner. I like it, but IC
Editor has a much better screen presentation and vastly better screen
redraw times. These are the main reasons people give for choosing one
over the other. If you remember, Calma had a solid line around
polygons and a fill within the line. There is no solid line around
the Tanner polygons, so things are much harder to see on screen (IC
Editor has the solid line). I guess it's all what you get used to. I
have never used the Tanner schematic capture or Tspice. The complete
package is around $16k.
TopSpice looks like a great contact.
- Larry Gipson San Diego, CA
( ESNUG 336 Item 6 ) -------------------------------------------- [11/99]
Subject: ( ESNUG 329 #7 330 #5 ) Getting *Signed* Comparitors w/ DC 99.05
>> An old collegue in the Netherlands, Rob van der Valk, gave me a hint on
>> how to do the signed comparisons after he saw my letter in ESNUG. The
>> trick is to invert the MSB's of the operands and do an unsigned
>> comparison on that. So instead of:
>>
>> op_a[n:0] > op_b[n:0]
>> do:
>> {~op_a[n],op_a[n-1:0]} > {~op_b[n],op_b[n-1:0]}
>>
>> That's easier and smaller in logic than the functions I wrote.
>>
>> - Menno Spijker
>> Mitel Semiconductor Kanata, Canada
>
>
> From: Charutosh Dixit <charu@lsil.com>
>
> John,
>
> The solution given for above for signed comparators looks flawed to me.
> The correct solution is: If we have two signed numbers to be compared, we
> swap the MSBs of the two numbers and then perform the regular magnitude
> comparison. The scheme works as follows:
>
> a. When the two numbers have the same sign, MSB swapping does not have
> any effect and the regular magnitude comparison is done
>
> b. When the two numbers have opposite sign, like for example A=0011 and
> B=1001, then the positive number (A) is the bigger number. By
> swapping the MSB we get A=1011 and B=0001, and thus the positive
> number is made bigger in magnitude (1011 > 0001), for the magnitude
> comparison that follows this process.
>
> Hope this helps your ESNUG readers.
>
> - Charu Dixit
> LSI Logic Milpitas, CA
From: Gil Herbeck <gilherbeck@home.com>
John,
There is nothing flawed about the first approach. The flaw is in the tools
that would force a designer to have to use this workaround. In any case,
both approaches are arithmetically correct. This would be an interesting
test for formal verification. Can you have your EDA buddies try their
formal tools on these two RTL designs and let us know how they do? I
suspect that they will work since the vast majority of the circuits should
be the same. But still, it would be interesting to see for sure.
- Gil Herbeck
Radix20 Design Services Livermore, CA
---- ---- ---- ---- ---- ---- ----
From: Dave Knierim <davekn@pogo.WV.TEK.COM>
John,
Both solutions work fine. Charutosh's "proof" for his version works on
Menno's version as well:
a. When the two numbers have the same sign, MSB INVERSION does not have
any effect on the regular magnitude comparison. For the example of
A=0011 and B=0001, A is larger than B. Inverting the MSB's results
in A=1011 and B=1001. A is still larger than B.
b. When the two numbers have opposite sign, like for example A=0011 and
B=1001, then the positive number (A) is the bigger number. By INVERTING
the MSB's we get A=1011 and B=0001, and thus the positive number is made
bigger in magnitude (1011 > 0001), for the magnitude comparison that
follows this process.
- David Knierim
Tektronix
---- ---- ---- ---- ---- ---- ----
From: Surendra Rajupalem <srajupal@lsil.com>
Hi John,
In signed magnitude comparision, the basic trick is make the positive
numbers bigger in magnitude and negative numbers smaller in magnitude.
Assuming sign bit for positive numbers is 0 and vice versa for negative
numbers that is 1. Both the above implementations works, but the latter
will save two inverters because of the swap.
If the sign bit is 1 for positive numbers and 0 for negative numbers just
compare the numbers including sign bit like unsigned magnitude numbers
without any MSB manipulation.
- Surendra Rajupalem
LSI Logic Advanced DSP Development Dallas, TX
---- ---- ---- ---- ---- ---- ----
From: Peter Johnson <pete@sei.com>
John,
You might want to let Charu Dixit know that his swap the MSBs is the same as
Menno Spijker's solution for case b). Swapping two bits which are different
is the same as inverting the bits. Although I must admit that swapping the
MSBs does result in a solution in zero gates (rather than two inverters).
- Pete Johnson
Silicon Engineering, Inc. Scotts Valley, CA
---- ---- ---- ---- ---- ---- ----
From: Howard Landman <HowardL@SiTera.com>
John,
I'm not sure I understand what Charutosh's objection is. Rob/Menno's
solution appears to work fine. The reason:
a. When the two numbers have the same sign, inverting the MSB inverts
both MSBs and the result of the magnitude comparison is unchanged.
b. When the two numbers have opposite sign, like for example A=0011 and
B=1001, then the positive number (A) is the bigger number. By
inverting MSBs we get A=1011 and B=0001, and thus the positive
number is made bigger in magnitude (1011 > 0001).
Of course, Charutosh's variant also works fine. They're almost equivalent
in cost and performance; the only difference is Rob's solution requires
inverters on the MSB (which might slow the circuit down -- but usually MSB
delay is *not* the biggest problem), while Charutosh's involves swapping
some routing, which may or may not be a problem depending on the layout
(but probably not - the two MSBs get used together). Either one is far
better than some of the kludges discussed previously.
- Howard Landman
SiTera Longmont, Colorado
( ESNUG 336 Item 7 ) -------------------------------------------- [11/99]
Subject: ( ESNUG 331 #7 333 #7 ) IBM Has Similar Interoperability Issues
> The problem Eran is facing is what I consider today to be my biggest
> problem in setting up Timing Driven design flows, using different tool
> vendors. I've been working with some EDA companies developing timing
> driven back-end tools (floorplanners and P&R) and it seems like everyone
> is having its own constraints format. Even worse, everyone supports
> different types of constraints. Since Synopsys is the source for the
> constraints, you need to translate from Synopsys to everyone else's
> format, and try to restrict the design to use just the constraints your
> tool vendor can support.
>
> For example, in Synopsys you can define multi-cycle path with -through
> attribute. This can be translated to GCF (allthough not with the Cadence
> supplied translator), but Pearl doesn't support this so basically you
> can't use this constraint to drive Qplace. My conclusion:
>
> 1. Write your own translator(s) (I did...)
>
> 2. Restrict your designers to constraints that are translatable (I
> know it's easier for me than it is to you).
>
> 3. When you have a certain structure that requires more complicated
> constraints (I have an AGP/PCI combo block with very complicated
> constraints), take it out of the "big chunk" and use the SDF Path
> Constraints for it.
>
> Best Regards,
>
> - Nir Sever
> GigaPixel Corp. Santa Clara, CA
From: Bob Dilly <dilly@us.ibm.com>
John -
At IBM we are running into similar "translation" issues as Nir and London
cite. Our "backend processing" is based on EinsTimer, our IBM-developed
timing engine, and years of scripts that help us close timing here. As our
customers exploit the range of commands available in various timing tools,
we are finding that translation is becoming more of a challenge.
Like Nir, we are developing translators but find that its difficult because
various tools model timing differently, using concepts which sometimes
don't "map" readily between tools. To try to get out from under this
"translation" burden, we've been investing in an emerging standard for
design contraints. We participated in a demonstration at DAC this year,
using a subset of DCDL to exchange constraints between several vendor's
tools.
Although it doesn't solve Eran's issue today, we're working towards having
a good chunk of the timing portion of the standard out by early next year.
The web site is: http://www.vhdl.org/dcwg/
I think I can speak for the working group in that we'd be happy to have
others join us in hammering out a workable standard.
- Bob Dilly
IBM Microelectronics Burlington, VT
( ESNUG 336 Item 8 ) -------------------------------------------- [11/99]
Subject: ( ESNUG 335 #8 ) Downloadable Past SNUG Proceedings Are On Line
> Where can I purchase/download a hard copy of the SNUG 1999 Proceedings?
>
> - Petter Gustad
> Dolphin Norway
From: Joanne Wegener <jwegener@synopsys.com>
Hi Petter,
You can download all papers and presentations from SNUG 1999 (both San Jose
and Boston conferences) at: http://www.snug-universal.org/
You will be prompted for your Synopsys user id and password.
- Joanne Wegener, SNUG Program Coordinator
Synopsys
( ESNUG 336 Item 9 ) -------------------------------------------- [11/99]
Subject: ( ESNUG 335 #9 ) An RTL-C Rival Critiques Synopsys SystemC Idea
> I am interested to know what the design community thinks about the SystemC
> initiative launced recently by Synopsys, Coware and Frontier and a whole
> series of system design companies. For more info see www.systemc.org
From: Andy Freeman <anamax@earthlink.net>
Having actually used C to design hardware a couple of times, I'm not
impressed with SystemC.
The "design with C" tools fall into three categories:
(1) "Let's make C look/behave enough like Verilog/VHDL so that
Verilog designers can use C". SystemC and CynApps are in
this category. This category is distinguished by user-guides
which explain an execution model and explain how to express
non-blocking assignments.
(2) "Let's add something to C to make it a HW design language".
Handel-C is my favorite example - if you're one of the 10k
people who know CSP, it may be the tool for you.
(3) "Let's figure out how to translate a C subset into gates."
Currently, the big player in this area is CLevelDesign.
(I'm getting close to releasing a product which competes
with their RTL-C product.)
Category (1) tools promise faster simulation and easier integration with a
world simulated in C/C++. I don't think that the former advantage is
sustainable - the "fast" HDL simulators can use the same shortcuts. (Things
will get interesting when the C tools start exploiting multiprocessors, but
the HDL simulators can also make that leap.) If I'm correct, the open
question is whether the latter advantage is enough to entice people who are
already comfortable designing with Verilog/VHDL.
Category (2) tools don't have any potential users.
Almost all category (1) and (2) tools require (or at least allow) the
designer to express concurrency. I think that explicit concurrency is a
huge mistake because the semantics for such code is always subtle, so its
behavior is usually surprising, leading to Heisenbugs and "let's run it and
see what happens". Multiprocessor simulation may help/be required to flush
out designer misunderstandings.
Cooley's Oct 11 EE Times article (pg 137-8) quotes someone from Intel making
basically the same point. If these C/C++ dialects share the characteristics
that that make writing Verilog/VHDL "slow", their users can't be
significantly more productive. Moreover, if their users must be somewhat
competent with Verilog/VHDL....
Category (3) is analogous to synthesizable vs "full" Verilog. I've found
that "good" subsets do lead to unbelievable design productivity. (These
subsets do not have explicit concurrency - the execution model is familiar
to C programmers.) These tools won't have any problems making the leap to
multiprocessor simulation, and the results won't change when they do.
I think that the Category (1) tools will have a heyday and lead to better
synthesizers and better RTL analysis tools (because you really can't/don't
want to edit the Verilog they produce). However, I think that Category (3)
tools will eventually be used for most synthesizable design because they're
easier to use AND there are far more C programmers who can design HW with
them than there are Verilog/VHDL programmers, let alone Verilog/VHDL
programmers who want to use C.
The interesting question is how to make money with these tools. I do almost
all of my HW debugging with the C source because the Verilog (for synthesis)
generated from the C is strongly equivalent. Moreover, these compilers (C
to Verilog) are very fast. (They can compile C to Verilog about as fast as
XL can read it in.)
All of these tools do fit into typical design flows because they generate
PLI interfaces for folks who want to mix C and Verilog, Verilog for those
who don't, and VCD for people who want to use waveform viewers.
- Andy Freeman
BTW -- Since Category (3) tools don't have an event mechanism, they may have
a small (25%?) inherent simulation speed advantage over Category (1) tools.
However, that may not be significant. I've got a microcontroller core for
which the C runs over 1 million cycles/second on an obsolete PC. I haven't
bought a new PC to get 2 million cycles/second (or booted up a PC sitting in
the closet to get 2x1 million cycles/second) so I doubt that I'd care much
if it only ran 500k cycles/second.
( ESNUG 336 Item 10 ) ------------------------------------------- [11/99]
From: Najib Adalat <Najib.Adalat@infineon.com>
Subject: Is There Any Other Better Way To Insert BIST That I'm Not Seeing ?
Hi John,
I have question regarding Built-In Self Test (BIST). I understand that
Design Compiler doesn't support BIST. I have to manually get LFSR and MISR
from the DesignWare Library and then hand instantiate it my module. Is
there a better way to do BIST that I'm not seeing?
- Najib Adalat
Infineon
|
|
