Editor's Note: It's amazing how your life can change in an instant. For
the past 6 years, I've always put together the ESNUG newsletters on a
cheesy 386 CPU, 33 Mhz, 8 Meg RAM, Windows 3.1 PC clone. Hey, I didn't
need it for more than wordprocessing and as a dumb terminal to connect to
the Internet! Works nicely. Or should I say "worked nicely." Two days
ago, while deep into concentration putting together this ESNUG post, I
suddenly heard a very weird whine, followed by some cracking/poping noises,
and then suddenly the monitor went black! To add to my surprize, as the
poping continued, a small cloud of black smoke came out of the *side* of
my monitor! Power down. Power up. More poping. Damn. This is the
first time I've ever seen/had a monitor die on me.
To make a long story short, I finished putting together this ESNUG with
a friend's old monitor. (Kind of odd: everything's slighly green now and
all the characters on the screen are scrunched to the left.) So now I'm
suddenly thrust, against my will, into the PC clone market. Oh, joy.
- John Cooley
the ESNUG guy
P.S. Read item 3 (below) for my second big surprise of the week. Whoa!
( ESNUG 278 Item 1 ) ----------------------------------------------- [1/98]
From: Chuck Shinn <cshinn@hpbs4107.boi.hp.com>
Subject: DC 97.08 QOR Aren't What The Synopsys Marketeers Say They Are
Hi John,
I have discovered that 1997.08-49682 (the latest patch) doesn't live up to
it's claims of improved QOR (Quality Of Results) which is Synopsys speak for
how well the synthesis can meet your timing constraints...
I've been working on a BIST controller for a RAM and with v3.4b the
synthesis meets the timing constraints. With 1997.01 and it's patches the
synthesis crashes. With 1997.08 or 1997.08-49682, it fails to meet the
timing. Guess which version we're sticking with?
I'm beginning to feel that Synopsys needs to upgrade their QA test suite
before doing formal releases...
- Chuck Shinn
Hewlett-Packard, Boise, Idaho
( ESNUG 278 Item 2 ) ----------------------------------------------- [1/98]
From: Rich Katz <rich.katz@gsfc.nasa.gov>
Subject: Coding State Machines By Hand Or With Graphical Entry Tools
> Does anyone have any experience with statecad? In general, is it
> worthwhile going to a visual state machine entry as opposed to coding in
> vhdl [no vhdl-verilog wars, we're using vhdl] or <gasp> designing with
> gates, flip-flops, and macros?
>
> - Rich Katz
> NASA
From: "Frederick K. Best" <fbest@slr.orl.lmco.com>
I used to code in text-only VHDL and Verilog. I found using a graphical
entry tool such as Summit's Visual or Mentor Graphics' Renoir increased
productivity quite a bit.
Visual HDL from Summit ( www.summit-design.com ) is a VHDL front-end tool
using graphical design methods such as block diagrams, state machines, flow
charts and truth tables to generate synthesizable HDL code that is optimized
for specific synthesis tools (Synopsys, etc.)
- Frederick K. Best
Lockheed Martin
( ESNUG 278 Item 3 ) ----------------------------------------------- [1/98]
From: [ Wally_Rhines, CEO of Mentor ]
Subject: Thanks For The "System Architect" Wake-Up Call 2 Years Ago
John,
I just wanted to express my thanks for the jump-start your ESDA design shoot
out of two years ago had on Mentor. Renoir, our high-level design capture
tool, has now passed the 25% market share point and is rapidly displacing
Summit. It wouldn't have happened without the wake-up call your contest
gave to our "System Architect" product. It is now a multimillion dollar per
year high profit generator for Mentor.
My thanks.
- Wally Rhines, CEO
Mentor Graphics
( ESNUG 278 Item 4 ) ----------------------------------------------- [1/98]
Subject: ( ESNUG 270 #9 271 #7) DesignWare Foundation Licensing Tricks
>> We have less DW Foundation licenses than DC licenses. Currently we have
>> the designers not point to any of the advanced DW architectures unless
>> their design is not meeting timing. Does anyone know of a way to only
>> check out the DW Foundation license when you want to write out the design
>> and maybe run everything else in eval mode?
>>
>> - Russ Ray
>> Mitsubishi
>
> From: [ The Man In The Iron Mask ]
>
> John, please keep me anon. To disable the DW foundation licenses use:
>
> synlib_dont_get_license = {DesignWare_Foundation}
>
> Then use:
>
> synlib_disable_limited_license = FALSE
>
> To trick Synopsys into thinking its using it in Evaluation mode. When
> you're done, at the last minute, you can switch back to non-Evaluation
> mode to then write out your working design by using:
>
> synlib_disable_limited_license = TRUE
>
> along with a get_license for DW license.
>
> - [ The Man In The Iron Mask ]
From: [ Someone Who Does DesignWare At Synopsys ]
John,
The method described to circumvent the licenses will cause your design to
use only the Standard library parts. Evaluation mode will not work if a
site has a DesignWare Foundation license whether you disable the license or
not. If you were to do a 'report_resources', you will find that standard
library architectures were used instead. The fact that evaluation mode
doesn't work when a Foundation license is available can be even better
illustrated when a design contains an instantiated Foundation part.
So, if you are currently using this method, and find that the performance
is not as good as you expect, you might want to try using the library
without disabling it as the method prescribes.
- [ Someone Who Does DesignWare At Synopsys ]
( ESNUG 278 Item 5 ) ----------------------------------------------- [1/98]
Subject: JTAG, Board Testing, And Increased Costs Of Silicon
> I just started to evaluate boundary scan (JTAG) for debug and for
> manufacturing test reasons. Quite often you can read how great it is and
> what it can do, but I am wondering if this methodology is already adopted
> by the whole industry. Here some points:
>
> 1) Has anybody an opinion on the availability and reliability of
> BSDL files?
>
> 2) Has anybody good or bad experience with "JTAG-tools" especially
> for PCB-debugging? (Do they pay back?)
>
> 3) As I started to evaluate my system to get an idea what fault
> coverage I can get on interconnection faults. I was surprised how
> low it was (20-30% -- pls note, it was not a DFT design ). Anybody
> out there who has used boundary scan for board level testing and
> could achieve significant advantages?
>
> - Joerg Grosse
> Tait Electronics Ltd., Christ Church, New Zealand
From: daveb@iinet.net.au (David R Brooks)
In my experience, availability and reliability of BSDL files is very
disappointing. A recent project included a CPLD device, which is in-system
programmed via the JTAG chain. The CPLD software requires a BSDL file for
each device in the chain, so it can bypass the other devices. Having just
one device unsupported in this way (as was the case) means the chain cannot
run. I worked around by adding a jumper to bridge out the offending device
while programming, but it shouldn't be necessary.
I agreed on the low coverage (the 20-30 % coverage you mentioned.) Many
programmable devices now come with JTAG, and a few (a very few) CPUs. Bus
drivers are available, but costly. The big sticker is memory: the market is
so competitive they won't spring for the extra silicon to implement JTAG.
The only use I have found for JTAG (and it's a very valuable one) is to
in-system program flash ROMs (and CPLDs). The ROM-programming technique
works by re-programming a FPGA to take over the system and control the ROM.
It's documented on my website <http://www.iinet.net.au/~daveb>. Follow
the "Free Stuff" pointer.
- Dave Brooks
iiNet Technologies
---- ---- ---- ---- ---- ---- ----
From: Todd <tdh@io.com>
FWIW, in one of last year's issues of Electronic Engineering Times, there
was an article on how pitiful JTAG implementations are across the industry.
It was written either by, or sourced from someone at HP.
Wow... EE Times has a nice web site. I was able to find the article
fairly easily:
Title: IC makers blasted for failure to back boundary scan
Author: Stan Runyon
Date: December 01, 1997, Issue: 983
Search their archives here to get the complete article text:
http://techweb.cmp.com/eet/news/search/print.html
- Todd
io
---- ---- ---- ---- ---- ---- ----
From: "Ross Swanson" <swan000@erols.com>
It depends on the system that JTAG is in, the military has produced some
system's where all the ASIC's use JTAG and so board level inner-connect
testing is a snap. However JTAG isn't going to pay for itself if the system
around the chip doesn't support this methodology. I believe some large
chip's are setup to use the JTAG port as a debugging tool for S/W, providing
single step, readback and download.
- Ross Swanson
---- ---- ---- ---- ---- ---- ----
From: "Alvin E. Toda" <aet@lava.net>
Joerg Grosse wrote:
> 3) As I started to evaluate my system to get an idea what fault coverage I
> can get on interconnection faults I was surprised how low it was (20-30%
> -- pls note, it was not a DFT design ).
This is not surprising if as you say it is "not a DFT design". Question
on your analysis, though. As you able to model all components on the
board which have NO boundary scan? If not, then a great number of the
inconnections on the board would be untestable nets. I believe a number
of software programs report the fault coverage on the number of nets
that are TESTABLE.
I believe you need to bring the state on untestable nets -- such as outputs
of non-modeled components -- to KNOWN states by exercising the board. If
all untestable nets can be brought to know states such as through a bed of
nails technique if not through exercise of the circuit, then I'm sure that
the fault coverage of the testable nets by the scan logic would be MUCH
greater.
Generally, fault coverage fails on components such as unscanned flip flops
and asynchronous sequential logic. Even here, it would seem that if you
were by some means to define these outputs than the coverage would be higher.
It seems a lot of a test engineer's time is spent in getting a stimulus to
a certain node. With partial scan, there is still this necessity. I don't
think you can develop a scantest ONLY using the scan logic if you insist
("no DFT") on using partial scan.
- Alvin E. Toda
2-Sigma Pearl City, Hawaii, USA
---- ---- ---- ---- ---- ---- ----
From: "Gerhart Hlawatsch" <ghl@uni-muenster.de>
The boundary scan story is still not settled in industry. Initially
intended to be implemented in complex circuits for manufacturing tests and
enhanced subsequently to allow PCB fault detection several drawbacks arose.
The intest (internal function test) needs a large test vector file for
the mega-gate chips and take too long for an economic production. Instead,
special test functions like a signature verification are preferred.
The extest (external signal path test) is a beautiful feature to detect
PCB faults (open circuits or shorts). Up to date, however I do not know
of any chip manufacturers which have I/O-pads with boundary scan function
integrated in the pad logic. Therefore you have to increase the core of
the chip which can - with core limited designs - lead to a larger silicon
area and thus to higher cost.
A few years ago the FPGA and CPLD inustry detected the JTAG boundary scan
interface for in-system programming of the eeprom switch matrix of the
device. Surely a good draw. Texas Instruments has bus drivers and other MSI
chips with JTAG. Using these raises the total system cost by 10 or 20 %.
A detailed description of JTAG boundary scan applications will be found
in http://www.goepel.com/
Have fun!
- Gerhart Hlawatsch
Westfaelische Wilhelms-Universitaet Muenster, Germany
---- ---- ---- ---- ---- ---- ----
From: Frank Bouwman <Frank.Bouwman@sv.sc.philips.com>
Gerhart Hlawatsch wrote:
> The extest (external signal path test) is a beautiful feature to detect
> PCB faults (open circuits or shorts). Up to date, however I do not know
> of any chip manufacturers which have I/O-pads with boundary scan
> function integrated in the pad logic. Therefore you have to increase the
> core of the chip which can - with core limited designs - lead to a larger
> silicon area and thus to higher cost.
I always hear the phrase: larger silicon THUS higher cost.
I hear it for full scan, boundary scan, ...
Extra silicon may be a cost for producing it, but it is going to pay back
BIG if you run into problems with a new design and need for example debug
or fault localization capabilities. Do you know what it costs to delay
market introductions ?
- Frank Bouwman
Philips Semiconductors
( ESNUG 278 Item 6 ) ----------------------------------------------- [1/98]
Subject: (ESNUG 276 #8) Views On Off-The-Shelf Standard ASIC Libraries
> I'm fishing for information, horror stories, and user insights concerning
> off-the-shelf standard cell ASIC libraries. (In particular, but not
> limited to, how they work with Synopsys synthesis.)
From: monks@quebabi.sps.mot.com <Morgan Monks>
John,
I would strongly recommend that when you evaluate these "off-the-shelf"
ASIC libraries that you look at timing convergence to a final routed design.
In my ASIC experience many vendor's libraries don't have the insight that
make the place and route make a small timing correct chip.
Each library that I have worked with has had design input based upon the
place and route tool. We use Cell3.
- Morgan Monks
Motorola Semi-custom Chandler, Arizona
---- ---- ---- ---- ---- ---- ----
From: "David Brantley" <dmb@dalsemi.com>
John,
We have been evaluating cell libraries and memory compilers from various
vendors since last September. By most accounts, Aspec is considered to have
the largest share of this market. We are looking for Chartered libraries
only, not multiple foundry based libraries. Also, we are concentrating on
0.5um (for 5V parts) and on .35um (for our 3V parts).
The foundry and the process you are targetting are very large factors in
trying to decide what vendor can support you. It has also been our
experience that the salesperson will "sell" you anything, doesn't matter
whether the vendor actually has the product or not. Some vendors structure
their business model such that they expect to be able to re-act quickly
enough to a customer's request that you should not have to concern yourself
whether or not they actually have the product you wish to buy or not. They
believe they can make it in time for delivery to you.
I would highly recommend that you demand to put your hands on at least a
small sample of what you are purchasing, including all views, before you
place an order. Further, I would encourage you to run DRC's, off-grid
checks, and route one or more blocks after using synthesis using the
library. This comes from our recent experiences.
Another key point is to get a clear definition from your foundry of all
documents which describe the process you are targetting and their current
revision code. Then make sure your cell library vendor complies with this
rev of these documents.
As for details of particular vendors, we have dealt with Aspec and found
their libraries to be wanting from an engineering perspective. They have
a P/N ratio of 1 in their libraries, off-grid points, the cells are not
compliant with the latest rev of the foundry's DRC documents, an inverter
is made up of 4 Xtrans (2 of which are obviously not connected but causes
the cell to be much larger than needed therfore impacting density), some
cells require routing outside of the cell boundary to make internal
connections, metal2 and metal3 are used in the cell, etc.
We are a 3+ year customer of Cascade for our internal Fab. We have had
battles with them over the past year with these libraries as they have
"changed their business model". They have put in place new management
which have taken a company which worked well with its customers and "broken"
it. We are finding DRC problems, off-grid problems, verilog model versus
actual silicon functionality problems, etc. Also, Cascade does not have
any of the processes we have requested for Chartered "off the shelf".
They believe they can "quickly turn" whatever the customer requests.
We have talked to Artisan only about memory compilers. They too have
apparently changed their business model. According to John Roar at Artisan,
they now only sell memory compilers to Foundries with a "right to
distribute" license. Artisan does not sell memory compilers directly to
end-users.
Compass (now Avant!) are trying to decide if/how they will be in the cell
library business. Avant! has a new division for design services called
Galaxy. They really want to sell you design services not just libraries
or compilers. Furthermore, they are not sure it is in their best interest
to sell you any product if you are going to use a Cadence router. If you
want to buy an Avant! router, then they will consider selling you libraries
or compilers.
We are currently evaluating cell libraries from Leda Systems. So far, we
have been very impressed with their technical ability and their products do
not appear to have the flaws we have found in the other vendors. Again, we
are early in our evaluation process, but so far we are pleased. Leda does
not have any memory compilers to offer, so we are still searching for that
solution.
As you can see from our horror stories, it is not just "plug-and-play". I
suggest you spend some time developing an evaluation strategy and then
expect to spend some "quality" time with your proposed vendors.
- David Brantley
Dallas Semiconductor Dallas, TX
( ESNUG 278 Item 7 ) ----------------------------------------------- [1/98]
From: Eric Ryherd <"vauto@tiac.net">
Subject: Avoiding Synchronous Resets Being Combined With Other Random Logic
> What is the "proper" format for a clock-enabled DFF with a synchronous
> reset. The trick is to insure that the synthesizer (Synopsys) doesn't
> combine the synchronous reset with other logic that results in the
> classic "I can't get out of reset, my circuit is all Xes" problem.
>
> - Eric Ryherd
> VAutomation Inc. Nashua, NH
From: Darrell Stewart <dstewart@nortel.ca>
Along with your synopsys sync_set_reset compiler directive, make sure that
you compile using the option: compile_preserve_sync_resets = "true"
- Darrell Stewart
Nortel
---- ---- ---- ---- ---- ---- ----
From: Bob Flatt <bobf@fishes.com>
Seems you'd have to code with clock enable dominant, and reset as a
boolean lump. To prevent that boolean lump getting merged with its fanin
(and your reset problem) you'd have to mark the D input to the reset
lump as critical or don't touch or whatever your specific synthesizer
uses to say keep a combinational net.
I'd probably use async reset, but maybe that isnt available to you.
- Bob Flatt
---- ---- ---- ---- ---- ---- ----
From: Richard Schwarz <APS@associatedpro.com>
I guess I am not quite sure what the problem is you are describing. The
code below describes a synchronous priority encoded process which should
reset if a clock comes along when a reset is set to one. This presupposes
that the reset pulse is longer than the clock period however, or that it was
generated with the clock. An asych signal shorter than the clock period
could easily be missed or ignored.
data_register:PROCESS(clk) -- Create the register
BEGIN
if (clk'event and clk='1') then
if (ce='0') then -- clock enable
q <= q;
elsif (reset='1') then -- synch reset
q <= '0';
else
if (a='1' AND b='1' AND c='1' AND q='1') then
q <= d; -- ugly logic w/ feedback
elsif (a='0' OR b='1' OR d='1' OR q='0') then
q <= c;
elsif ((a='1' AND c='1') OR (d='0' AND q='1')) then
q <= b;
else
q <= a XOR q;
end if;
end if;
end if;
END PROCESS;
What is your indication that anything is wrong? You mentioned synthesis
above and also X's, which to me means simulation. Are you having
problems simulating?
You could have also added the reset to your sensitivity list and then
done this:
if (reset'event and reset='1') then ...
This would essentially be an async reset though. Or your could use a wait
statement in combination with some combinatorial reset logic, and eliminate
the sensitivity list.
- Richard Schwarz, President
Associated Professional Systems (APS) Abingdon, Maryland
---- ---- ---- ---- ---- ---- ----
From: Eric Ryherd <"vauto@tiac.net">
Actually, the best answer is to put the sync reset first followed by the
clock enable. Synopsys recognizes the reset and most ASIC libraries have
DFFs with reset overriding the clock enable.
Turns out that Exemplar Galileo will use the clock enable of Xilinx XC4000
families with the reset as the first IF by gating RESET and clock enable
together and connecting that to the CE pin of the DFF in the FPGA.
This is exactly the result I am looking for, Synopsys is certain to produce
sync resets so we don't get stuck in Xes forever (because synopsys is
notorious for feeding Q and Q_BAR back into the "ugly" logic unless it
recognizes the sync reset attribute) and Exemplar uses the CE on FPGAs which
saves many many LUTs which are often in short supply.
Thanks to all who responded...
- Eric Ryherd
VAutomation Inc. Nashua, NH
( ESNUG 278 Item 8 ) ----------------------------------------------- [1/98]
From: Nestor Caouras <nestor@ece.concordia.ca>
Subject: Division & Multiplication Using Alta PSW, Synopsys, & Xilinx
> In my efforts to build an efficient divider (unsigned for the time
> being), I have used a method which separates the "y/x" quotient into a
> product of "1/x" and "y". The "1/x" part is implemented in a ROM (in and
> FPGA). So the input "x" addresses the ROM and the "1/x" value is
> outputed and then multiplied with the "y" factor. Neither "x" nor "y"
> are constants which makes implemtation a little more difficult (and less
> efficient).
>
> My synthesis procedure of the method I used is the following and yields
> less than acceptable results:
>
> 1. Block diagram design in SPW (Alta Group's (Cadence) Signal
> Processing Worksystem)
> 2. VHDL code generation from SPW
> 3. Synthesis using Synopsys 3.4b
> 4. Place & route using Xilinx Alliance M1.3 and a -1 speed grade part.
>
> Any kind of input about this method or another better method for
> implemeting division (or its sub-operations) would be greatly appreciated.
> VHDL algorithms for signed or unsigned division can also be useful to my
> project. Also, any info on where to obtain a good multiplication
> algorithm would be very time saving.
>
> - Nestor Caouras
> Concordia University Montreal, Quebec, Canada
From: NgOsSmPiAtMh@passport.ca (Gregory Smith)
I assume your application can't tolerate the time required for 'bit-by-bit'
long division? Can you put several of these in skew-parallel to reduce
the effective time? It makes a huge difference what kinds of errors you
can tolerate. Your 1/x table, unless x is always close to some center
value, will become very inaccurate for large x. Have you considered a 'log'
approach? Use tables to approximate log2(x) and log2(y), and then another
table for 2^(y-x). The choice of 2 is important. For instance, 2^z can be
done by looking-up the fractional part of z and then barrel shifting by the
integer part. With this method the errors are uniform relative to the
magnitude of x and y.
For log x: rewrite x=2^k*(1+d), where k is an integer such that
(sqrt(0.5)-1) < d < (sqrt(2)-1) about -0.293 .. 0.414
'k' can be found by a 'normalize' function which finds the MSB; then
compare the normalized result to sqrt(2) and shift again if larger. Now d
is in the range above, and 'k' is the integer part of your log. The
fractional part (which may be negative) is log2(1+d); Since 1+d is close
to 1, this can be approximated efficiently by
log2(1+d) = (l/ln(2)) d + lookup[d]
where the lookup table doesn't have to be very big (i.e. only use the first
few MSB's of d). You may not have to go to such lengths, but this will
reduce the table size at the expense of additional logic. The result above
(log2(1+d)) will always fall in the range [-0.5,0.5].
Of course you can just normalize so 'd' is in [0..0.999] and lookup the
fractional log from there. log2(1+d) will also be in [0..0.9999].
Concerning a good multiplication algorithm, many VLSI texts cover this.
Look for 'Booth Coding' or 'Booth Multiplier'; that will at least bring you
to the right place.
- Gregory Smith
---- ---- ---- ---- ---- ---- ----
From: "Prof. Vitit Kantabutra" <vkantabu@computer.org>
I have some new algorithms for high-radix division that don't use
complicated table look-up. The most recent paper is available at
http://math.isu.edu/~vkantabu/radix8.pdf, and can be viewed with Adobe
Acrobat Reader 3.0 or later.
- Prof. Vitit Kantabutra
Idaho State University
( ESNUG 278 Item 9 ) ----------------------------------------------- [1/98]
From: Shashi Aluru <saluru@fore.com>
Subject: Synch Problems Across 2 Clock Domains When Freqs Are Close
John,
May be some of your experienced readers can help us out.
In one of our designs we are synchronizing a fifo across 2 clock domains.
The write to the fifo is through one clock & read is through another clock.
We use gray coding scheme and 3 stages of flip-flop to synchronise the write
and read pointers to the fifo. The problem we are seeing in the lab is when
the 2 oscillators have the same frequency some data is getting lost. When
the 2 clocks are different frequencies we don't see any problem.
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
|
|
