Editor's Note: We had a weird Friday night last Friday. An ex-roomate,
Pam, came by the Poor Farm (the name of the sheep farm near Boston where
I live) to show her boyfriend the 'interesting' place where she used to
live. It was fun talking to Pam, catching up on old times, telling old
stories. Pam, her boyfriend, and I were talking on the second floor when
we all noticed a police cruiser with flashing lights in the driveway.
We all walked downstairs to the kitchen. Then the cops came to the door
asking if we had seen any strange women running around. (?) (And, no,
they weren't looking for Pam.) Odd. The police left. We resumed talking
about old times for another 20 minutes. Then, out of the back bathroom,
a strange woman walked right past us and out the kitchen door! I asked
"WHO THE HELL ARE YOU?!?" as she walked by us and she said "I'm the woman
the police are looking for." And she then disappeared into the night!
We were all awestruck.
After about 5 minutes of hard laughing, we noticed that the police
cruiser hadn't actually left, but had turned off their flashing lights.
They had a tow truck towing some car away. When I told them we saw the
strange woman, they did another quick search in the back pasture for
her (they didn't find anyone but sheep). It turns out that the police
were chasing this woman because she was speeding. She pulled into our
driveway and ran from her car. She then must have found my kitchen door
open and (not knowing the house nor anyone in it) she rushed in, found
the bathroom and hid in there! Talk about balls! Whoa! The cops never
found her that night. They didn't seem to care too much. They had
her car and knew she'd eventually have to turn up for it.
What a weird Friday night.
- John Cooley
the ESNUG guy
( ESNUG 320 Subjects ) -------------------------------------------- [6/2/99]
Item 1: WARNING! Don't Switch To DC 99.05 Tcl Just Yet! Inconsistancy Bug!
Item 2: ( ESNUG 319 #16 ) Which Of These Power Books Are Useful?
Item 3: Formal Verification Equivalency Checking Didn't Buy Us Anything
Item 4: ( ESNUG 315 #1 318 #4 ) How Engineers React To Reusing Designs
Item 5: Synplicity's Latest Version Of Synplify Is Now Much Pickier!
Item 6: Modelsim 5.2a Checkpoint/Restore Function Doesn't Appear To Work
Item 7: The Backdoor Economy Of Market Analysts Live In & Their Models
Item 8: ( ESNUG 316 #11 ) Verilog-XL Back-annotation Slow Compared To VCS
Item 9: ( ESNUG 313 #10 316 #10 ) Analog Phase-Locked Loops In Verilog
Item 10: ( ESNUG 316 #3 ) Transmission Gates In Libs Ruin Fault Coverage !!
Item 11: Useful Web Sites If You're Designing High Speed FPGA Multipliers
Item 12: ( ESNUG 319 #6 ) Modelsim/Verilog-XL SDF Lib Conflicts W/ DC 99.05
Item 13: Test Compiler / DC-XP Uses Excessive Memory With Tri-State Logic
Item 14: Synplicity Users Group Registration Deadline On Friday, June 4th
Item 15: How Do You Model 2 Gbytes Design Mem w/ A 0.5 Gbyte Workstation?
Item 16: Where Can I get An Introduction To Memomry Compilers For My Chip?
( ESNUG 320 Item 1 ) ---------------------------------------------- [6/2/99]
From: Jeff Freeman <Jeff_Freeman-rwwf40@email.sps.mot.com>
Subject: WARNING! Don't Switch To DC 99.05 Tcl Just Yet! Inconsistancy Bug!
John,
I thought I would pass this on the the rest of the ESNUG community to
proactively warn anyone doing dc_shell to Tcl conversions. I ported my
dc_shell synthesis environment to the Synopsys 99.05 just to begining
learning Tcl. I ran the dc_shell environment as well as the Tcl
environment on the same design and compared the results. Guess what? I
got different results!
Synopsys has confirmed that there is a problem, so users might want to
wait before porting their environment to Tcl.
- Jeff Freeman
Motorola
( ESNUG 320 Item 2 ) ---------------------------------------------- [6/2/99]
Subject: ( ESNUG 319 #16 ) Which Of These Power Books Are Useful?
> Has anyone found a low power design reference worth reading? I've
> found a number of books on Computer Literacy's web site but haven't
> had a chance to leaf thru them yet:
From: Jerry Frenkil <jfrenkil@senteinc.com>
Hi John,
I am familiar with most of these books and perhaps can shed some light
on comparisons. IMHO, the one that is "best" will primarily depend
on what type of information is needed.
> Low-Power Digital VLSI Design : Circuits and Systems
> By Bellaouar, A. / Elmasry, Mohamed I. / Bellaouar, Abdellatif
>
> Advanced Low-Power Digital Circuit Techniques
> By Elrabaa, Muhammad S. / Abu-Khater, Issam S. / Elmasry, Mohamed
These two books are very similar in orientation in that both address
transitor level design. The first book "Low-Power Digital VLSI Design:
Cicuits and Systems" takes a relatively broad view in its coverage of
such topics as low voltage device modeling, logic styles and circuit
families for low power, and low power memory circuits. The latter book,
"Advanced Low-Power Digital Circuit Techniques", has a more limited scope
but instead focusses in detail on techniques for a few specific structures,
such as adders, multipliers, memories, and transcievers.
> Low Power Digital CMOS Design
> By Chandrakasan, Anantha P . / Brodersen, Robert W .
This is a very good overview of Low Power Design and covers a wide variety
of topics including voltage scaling, power supply design, adiabatic logic,
and optimization at various levels of abstraction. Targetted at hardware
development, much of this book is based on the InfoPad project, a portable
multimedia terminal developed at UC Berkeley.
> Logic Synthesis for Low Power VLSI Designs
> By Iman, Sasan / Pedram, Massoud
As its title suggests, this book focusses on logic synthesis, primarily
from the tool development perspective. It is based on the development
of a power optimizing synthesizer, POSE, developed by the authors at USC.
I believe that this book is most useful for those interested in the
optimization routines and transformations that occur within a synthesizer.
> Low Power Design in Deep Submicron Electronics
> By Nebel, Wolfgang (Edt) / Mermet, Jean (Edt)
This book covers the widest range of all those listed here, addressing
such topics as low power circuit and logic level design, libraries,
estimation techniques, and case studies. It should appeal to both
chip designers as well as tool developers. However, given that the
various chapters were written by different contributing authors, the
coverage of the different topics tends to vary.
> Low Power VLSI Design and Technology
> By Yeap, G. K. (Edt) / Najm, F. N. (Edt) / Najm, Farid N. (Edt)
I am not familiar with this book.
Lastly, you may wish to check out our web site for additional information
on Low Power Design. We maintain a page of pointers to a variety of
industrial and research oriented web-sites all related to low power issues.
If you are interested see http://www.senteinc.com/icpower1.htm
- Jerry Frenkil
VP, Low Power Design
Sente, Inc. Acton, MA
( ESNUG 320 Item 3 ) ---------------------------------------------- [6/2/99]
From: Don Mills <mills@lcdm-eng.com>
Subject: Formal Verification Equivalency Checking Didn't Buy Us Anything
Dear John,
I just saw in EE Times that Avant! just bought Chrysalis. I see that as
just trying to keep up with the "Jones" or in this case Synopsys's. In
my prior job, we looked at Chrysalis 3 or 4 times over the years and just
didn't think using any equivalence checker would buy us much. (I guess
then, my following comments could apply to Formality, too. Oh, well.)
Here's where we were coming from when we were looking at Chrysalis. We
were designing a 1 million gate design that had multiple clock zones
ranging from 75 MHz to 180 Mhz with about a third of the design being
RAM. This meant we had roughly 700,000 gates of custom logic to test.
Like everyone else doing these big, massive ASICs, we were looking for
alternatives to the SLOW task of running gate level functional vectors.
We were looking to group a couple approaches to accomplish this task
such as static timing analysis with "equivalency checking". As I
recall, to do the equivalency checking between RTL and gates, Chrysalis
forces you to have to break up your design in 5K to 10K gate blocks.
Equivalency checkers do a sort of voodoo synthesis on RTL (to convert it
to equations) and on gates (to convert that to equations) and then it
compares both sets of equations. Go beyond 10K gates, and the tool
chokes. So, doing the math, using Chrysalis meant we'd have to do
comparisons of roughly 100 'blocks'. Seemed like a lot of work for very
little return. Additionally, the indications were, that equivalency
checking between RTL and GATEs runs very slow.
The place where I can see equivalence checkers helping is with testing
gates-to-gates technology translations of design -- like porting a 0.35
um design to 0.18 um, or from vendor A to vendor B-- but we weren't
doing that, so Chrysalis was pretty much useless for us.
- Don Mills
LCDM Engineering South Jordan, UT
( ESNUG 320 Item 4 ) ---------------------------------------------- [6/2/99]
Subject: ( ESNUG 315 #1 318 #4 ) How Engineers React To Reusing Designs
> Having talked about reuse with hundreds of engineers over the last two
> years, I can assure everyone that reuse is not a myth. It's a practical
> reality and just common sense. I agree with Mr. Cummings that engineers
> don't want to reuse someone else's design if the alternative is to design
> something interesting if it's easier to do this than to reuse an existing
> solution. What I don't understand is why anyone would want to create a new
> CPU if an existing one would do, or why they'd want to sit down with 600
> pages of standards documentation and design the world's ten-thousandth PCI
> core, USB, MPEG, vector-multiplier or 8051.
>
> - [ John Chilton, VP/GM Design Reuse at Synopsys ]
From: [ Cousin 'It' from the Addams Family ]
John, please keep me anon.......
While design reuse has a very positive impact on product cycle times, there
are many negatives to the concept as well.
Having worked in the ASIC industry for 15 years, I can say from my own
experiences, that while design reuse is a necessary reality that is here to
stay, it truly demoralizes the engineering staff more than salary freezes
and layoffs. Not one of us went to engineering school saying, "When I get
out, I want to reuse somebody else's stuff for the next 30 years."
I have extensive experience with design reuse. Over my career, I would
estimate that 90% of my activity has been with IP that was being reused.
There are basic difficulties with design reuse, one is specification
maintenance. Timers, interrupt controllers and similiar "low impact" IP
blocks generally require little or no maintenance or upkeep. PCI
interfaces, Firewire, USB, networking and other "high impact" IP blocks
require maintenance to keep them up to the current level of their specs.
To perform this maintenance, you must have a staff with expert-level
knowledge of the block and the specification.
Then there is the issue of product differentiation. If every company in a
product sector uses the same set of blocks from the same supplier, there
is a practical limit to how much product differentiation can be realized.
At that point, every product in the sector becomes a commodity, and it is
difficult to turn a real profit on a commodity. So to achieve product
differentiation you must be able to enhance the technology that you are
dealing with this is difficult enough, but when you did not author a block,
it becomes a hair pulling experience.
It is naive to think that design reuse will go away. Schedules, business
pressures, the EDA industry and the IP industry won't let that happen. It
is equally naive to think that you can take a seasoned ASIC engineering
staff, give them a diet of 90% design reuse, and expect them to stay
motivated, innovative and content. There has to be a balance.
- [ Cousin 'It' from the Addams Family ]
( ESNUG 320 Item 5 ) ---------------------------------------------- [6/2/99]
Subject: Synplicity's Latest Version Of Synplify Is Now Much Pickier!
> I recently upgraded to version 5.1.2 of Synplify and was horrified to find
> the number of warnings issued for my designs have exploded!
>
> I regularly put into the process sensitivity list only the signals that
> are used in decisions, such as "if" or "case" statements. The previous
> version of Synplify was quite happy with that. Now it wants every signal,
> even those only used to assign a value, in the sensitivity list. For
> example, in x <= y, y is now needed in the sensitivity list, otherwise
> I get a warning.
>
> Was I out to lunch in my previous assumption that only decision-making
> signals should be in the sensitivity list?
>
> - Jamie Sanderson
> Nortel Networks Canada
From: Jan Decaluwe <jand@easics.be>
If your process describes combinatorial logic, yes. Suppose that at a given
time, *only* signal y changes value. You still expect to see the effect of
this change on the outputs, right? Therefore, y should be in the
sensitivity list. If you don't put it there, the RTL will have more "state"
and thus a different behavior than the synthesized logic. Therefore, the
warnings are certainly appropriate. Note: however that if you use the
clocked process paradigm, only clock and reset need to be in the sensitivity
list.
- Jan Decaluwe
Easics Leuven, BELGIUM
---- ---- ---- ---- ---- ---- ----
From: Renaud Pacalet <pacalet@enst.fr>
Think hardware and hardware only. A process is either a 1) synchronous
one (synthetizes with DFFs) and must be sensitive to clock only (and reset
signal if it is an asynchronous one) or 2) a combinational one and must
be sensitive to all signals that are entries of the corresponding
*hardware* glue logic. Examples:
process(CK)
begin
if (CK = '1') then
S <= A + B;
end if;
end process;
is a synchronous process without reset. It synthesizes a DFF register for
S and an adder.
process(CK, RST)
begin
if (RST = '0') then
S <= (others => '0');
elsif (CK = '1') and (CK'event) then
S <= A + B;
end if;
end process;
is the same but with an active low asynchronous reset on the register.
process(I0, I1, I2, STATE)
begin
case STATE is
when S0 => NEXT_STATE <= S1;
Z <= I0 and I1;
when S1 => if (I0 = '1') then
NEXT_STATE <= S2;
elsif (I1 = '1') then
NEXT_STATE <= S3;
else
NEXT_STATE <= S1;
end if;
Z <= I2 xor I0;
when S2 => if (I1 = '0') then
NEXT_STATE <= S0;
else
NEXT_STATE <= S2;
end if;
Z <= '0';
when S3 => NEXT_STATE <= S2;
Z <= '1';
end case;
end process;
is a combinational process. It must be sensitive to all entries of the
equivalent glue logic part. STATE is used for decisions only, I0 and I1
are used for decisions and assignments, I2 is used for assignments only.
All are absolutely needed in the sensitivity list. Another constraint is
that all outputs must receive a value in every situation. If you don't
respect this constraints you'll synthesize something that has a different
behavior than your simulations. In fact, if you don't respect this
constraints you are using VHDL to describe something that is not hardware
at all. A good synthesizer complains, a bad one does anything.
- Renaud Pacalet
ENST / COMELEC Paris, France
( ESNUG 320 Item 6 ) ---------------------------------------------- [6/2/99]
From: Jerome Chaix <jerome_chaix@mentorg.com>
Subject: Modelsim 5.2a Checkpoint/Restore Function Doesn't Appear To Work
I'm simulating under Modelsim 5.2a under NT and I want to restore the state
of my component at a specific time. It works well if I use the 'restore'
function without quitting the processus where I did the 'checkpoint'
function. But if I quit the simulation and reload my design with 'vsim
-restore <file name> <design name>', nothing happen, the signals stay
undetermined!?!
Do you have you another solution to restart a Modelsim simulation from a
certain state?
- Jerome Chaix
Mentor Graphics France
( ESNUG 320 Item 7 ) ---------------------------------------------- [6/2/99]
From: "Charles H Small" <charles.small@worldnet.att.net>
Subject: The Backdoor Economy Of Market Analysts Live In & Their Models
John,
One needs an iron butt to do my job. I spend a good bit of my time listening
to marketing presentations. They are almost all exactly alike: a marketing
guy drones through a series of PowerPoint slides. Now I tested out at
reading over 600 wpm when I was in the seventh grade, so I can read and
understand the slides a lot faster than they can read them to me.
Invariably, they quote market predictions by "analysts." As nearly as I
can tell, what these analysts to is poll all their customers (i.e.,
marketing guys), get some data, massage it, and sell the data back to
the marketing guys for a couple of thousand dollars a pop.
Collett says he has always disclosed how he formulates his "models." This
demands immediate and thorough investigation! If what he says is true, you
ought to be able to get lots of descriptions of his models. Your audience
is math literate. They could easily follow a critque Collett's models, in
particular, and Dataquest's, et. al., in general.
Cool project.
- Chuck Small
Senior Tech Editor
"Electronic Systems" magazine
( ESNUG 320 Item 8 ) ---------------------------------------------- [6/2/99]
Subject: ( ESNUG 316 #11 ) Verilog-XL Back-annotation Slow Compared To VCS
> Has anyone found that for a given testbench, back-annotation an sdf file
> for a gate-level simulation in Verilog-XL takes MUCH longer than it does
> with VCS? (3-4 hours vs. 4 minutes respectively for one of my test
> benches). What's the reason for this? How does each tool perform back-
> annotation?
>
> At first, I thought that VCS wasn't performing back-annotation, but after
> throwing some deliberate "errors" in the netlist at VCS, it detected them.
>
> I changed the module type from a low-drive gate to a high-drive gate. I
> changed the instance name to something non-existent in the sdf file. Both
> changes were flagged by VCS. Can anyone offer any explanations?
>
> I'm using VCS v5.0 and Verilog v2.6.
>
> - Alfred Cheung
> Nortel Networks Ottawa, Ontario
From: soconnor@pico.apple.com (Stephen O'Connor)
This matches my experience -- the times you note sound right -- annotation
in VCS is very very fast. Coming from XL sims, the question for a long time
was "Why is XL annotation so slow!" It's a big delay at a point when the
schedule is usually at its most pressing.
However, we have occasionally seen differences with gate sims under both,
so keeping both options open, as it seems you can, might be wise.
- Stephen O'Connor
Apple Computer
> You may be using the compiled SDF feature of VCS, which may be default
> now. In that case, the SDF file is read at compile time rather than at
> run time.
>
> - Ashutosh Varma
> Axis Systems Sunnyvale, CA
From: srini@natlab.research.philips.com (Srini Venkataramanan)
John,
If Asuthosh is correct, then NC-Verilog handles the SDF back-annotation in
a similar (compiled) manner. May be Alfred can try that as an option.
- Srini Venkataramanan, M.Tech (srini)
Philips Research Laboratories Eindhoven, The Netherlands
( ESNUG 320 Item 9 ) ---------------------------------------------- [6/2/99]
Subject: ( ESNUG 313 #10 316 #10 ) Analog Phase-Locked Loops In Verilog
> I have worked with people trying to model an analog PLL in Verilog and
> the results were not very good. Two problems come up besides the inherent
> problems of doing analog in a digital situation.
>
> One is that a true analog PLL will take quite a while (milliseconds) to
> stabilize. You should see this if your doing an accurate simulation. No
> one wants to wait a millisecond before beginning the rest of the system
> simulating.
>
> Second was that we had to make the timescale very small (much less than
> one picosecond) to get good results. This slowed the entire system
> simulation down to a crawl. We did not expect that with an event
> simulator but it did happen.
>
> This leads one to simulating the PLL separately and then feeding the
> results (jitter, frequency wander, etc.) into the Verilog model. If you
> are going to do this, you might as well simulate the PLL in spice and get
> more accurate results. Good luck.
>
> - Bruce Loyer
> AMD
From: Dave Knierim <davekn@pogo.WV.TEK.COM>
John,
Simulating VCO's can be done without small timescale by keeping the
fractional time step phase of the VCO in a variable. In the short example
below, the lower 24 bits of variable tm track the fractional time step
portion of the VCO phase. Variable vr is the VCO input voltage. In this
example, zero input generates a vco_out period of 2*99 time steps. Larger
inputs reduce the period by 2 time steps for every 1<<24 increase in vr.
I am sure there are more elegant ways to keep fractional time step phase
in a variable as well.
always begin
tm=(tm&((1<<24)-1))+(99<<24)-vr;
#(tm>>24) vco_out = ~vco_out;
end
For the other problem of long settling time relative to VCO frequency, I do
not have any magic solutions. We just simulated the VCO portion by itself
until it looked good, then ran a few long (day or two) simulations of the
entire chip to watch the VCO settle.
- David Knierim
Tektronix
( ESNUG 320 Item 10 ) --------------------------------------------- [6/2/99]
Subject: ( ESNUG 316 #3 ) Transmission Gates In Libs Ruin Fault Coverage !!!
> We're facing a Design-For-Test problem.
>
> In our library we have some MUXes made of transmission gates. We manually
> instantiate these cells in our datapath for fast timing. For example, we
> have a cell DSEL4, which has 4 i/ps, 4 selects and 1 output. We always
> have a decoder in front of such MUXes for the select lines. (Actually in
> our design, the selects for the MUXes are not decoded. So using a
> decoder, we generate fully decoded selects which drive the pass gate
> selects.)
>
> So we assure that, ONE & ONLY ONE of the selects is ON at any given time.
>
> Now my problem is the stuck-at faults at the select pins of these pass
> gates are untestable. So, can I do something to make them testable???
> I would also like to know the best way to model them in Synopsys. Right
> now they're modelled as bufif.
>
> We have many such cells in the design and the fault coverage reduction is
> required is huge. So, we can't neglect them.
>
> Please, help!!!
>
> - Nukala Ravikanth
> Meridian semiconductor
From: Hannes Froehlich <hannes@elaborate-designs.com>
John,
This designer could add an XOR-tree (testpoints) and a register (add to
scan chain) to observe the select lines (given you can live with some
additional gates).
- Hannes Froehlich
Elaborate Designs
PS: John, this should count as one point (against tri-states) in the long
lasting battle on whether to use tri-states or logic gates for muxing.
> Now my problem is the stuck-at faults at the select pins of these pass
> gates are untestable. So, can I do something to make them testable???
> I would also like to know the best way to model them in Synopsys. Right
> now they're modelled as bufif.
From: gsp@enigma.mlb.semi.harris.com (Gary Porter)
I recommend replacing the entire mux model with a model of the cell that
only uses ands, ors and inv's. Completely ignoring the internal structure.
And suppress faults inside the cell. The "stuck-at" model is still
valid at the pins of the cell.
- Gary Porter
Harris Semiconductor
---- ---- ---- ---- ---- ---- ----
From: Nukala Ravikanth <ravikanth@msemi.com>
Hi John,
I think that Gary's solution won't work with pass gates.
Right now I have a solution but dont know whether it is the best or not.
The solution is 2 fold, one for Stuckat1 faults and another for SA0
faults. I added a pullup cell(to test SA0 faults) at the o/p of each such
passgate mux. The pullup is an active one which i will switch off during
normal operation as I don't want my fall times to be affected. Also, I
had to add some control points (NOR gates) to the selects of the muxes,
to enable the ATPG tool to force all zeroes at the selects of the
passgate mux. The main problem is, as selects are driven by decoders, we
cant have all zero combination at the selects. This combination (all
zeroes means all pass gates are off) is needed to test the SA1 faults at
the select pins.
This solution gives 100% coverage but in case select lines are timing
critical, we can't add control points to the selects. So for those select
paths which are timing critical, we need to have a compromise over
the fault coverage.
- Nukala Ravikanth
Meridian Semiconductor
---- ---- ---- ---- ---- ---- ----
From: [ A Former Sunrise/Synopsys Test CAE/Consultant ]
As a former Sunrise/Synopsys Test CAE/Consultant, this issue is fairly
common on custom designs that use fully-decoded N-input muxes. Modeling
these with bufif1 primitives is fine for TestCompiler or TestGen. The issue
is more fundamental to the stuck-at fault model and this type of circuit.
First, consider a single pattern test to detect a S-A-0 fault on a bufif1
enable (mux select pin.) This test will have to sensitize this pin to a
1, which implies that all the other mux select pins are a 0. If this pin
has a S-A-0 fault, the faulty machine bufif1 will produce a Z and the mux
will output an X. At best this can only lead to a potential detect. Now
TestCompiler will give credit to half the potential detects in the final
fault coverage. And TestGen provides an option to re-classify a potential
detect as a hard detect once a specified detection count for that fault is
reached. So some creative accounting can make the fault coverage look a
bit higher.
If the mux were to contain a bus holder or charge storage, TestGen
sequential ATPG would create a two pattern test to detect the S-A-0 fault
on the bufif1 enable. The first pattern selects data through another mux
input and stores this value in the mux. Then the second pattern selects
the opposite data through the target input. In the presence of a S-A-0
fault, the previous data will be retained rather than overwritten.
S-A-1 faults on the bufif1 enable can never be hard detected because any
test will have to sensitize this pin to a 0, which implies that one of the
other mux select pins is 1. If this pin has a S-A-1 fault, opposite data
on the selected input will create a tristate contention which produces an
X on the mux output. Like the S-A-0 faults, giving credit to potential
detects may help
If the decoder and mux combination can be re-modeled as a single, encoded
mux cell, a complete set of patterns will be generated and a full coverage
will be reported.
- [ A Former Sunrise/Synopsys Test CAE/Consultant ]
( ESNUG 320 Item 11 ) --------------------------------------------- [6/2/99]
Subject: Useful Web Sites If You're Designing High Speed FPGA Multipliers
> I was wondering if anyone can refer me to some information about designing
> an 8-bit by 4-bit unsigned multiplier and an 8-bit by 4-bit signed
> multiplier that will perform at high clock speeds and have efficient usage
> of CLBs on the Xilinx Virtex FPGA.
>
> - Allen Tung
> Visicom Labs San Diego, CA
From: brian@esperan.com ( Brian Dickinson )
For some info on different FPGA multiplier architectures, take a look at:
http://users.ids.net/~randraka/multipli.htm
- Brian Dickinson
Esperan
---- ---- ---- ---- ---- ---- ----
From: "James E. Stine, Jr." <jes6@eecs.lehigh.edu>
There are a variety of different tools and programs for VHDL generation of
computer arithmetic at http://www.eecs.lehigh.edu/~caar/toolspg.html. These
tools can be obtained free of charge by way of written request. They
include Perl generation of structural Dadda (optimized Wallace) multipliers
and Array multipliers which can easily be transformed into signed
multiplication using techniques such as the ones described by Baugh and
Wooley. Take care.
- James Stine
LeHigh University
---- ---- ---- ---- ---- ---- ----
From: mcgett@xilinx.com (Ed Mcgettigan)
The Xilinx IP Center has a number of multipliers available for Virtex.
http://www.xilinx.com/ipcenter/reference_designs/index.htm#Math
- Ed Mcgettigan
Xilinx
( ESNUG 320 Item 12 ) --------------------------------------------- [6/2/99]
Subject: ( ESNUG 319 #6 ) Modelsim/Verilog-XL SDF Lib Conflicts W/ DC 99.05
> I'm trying to do a post-synthesis simulation with Modelsim EE 5.2, using
> the VITAL lib of my ASIC vendor. ... I don't know if I produce wrongly the
> SDF/VHDL files from Synopsys DC 99.05 (I use the SDF v2.1 format). Is
> there any chance that the vendor ASIC VITAL models are not 100% VITAL
> compatible, as said in the Modelsim user manual?
From: Todd Kline <todd@wgate.com>
The only SDF based problem I have had with Modelsim was with Verilog models.
Verilog-XL has extended features which are not supported in Modelsim. I
have never had a problem with VHDL models.
Since you are not sure about you SDF file generation, are you using the -c
VHDL and -f sdf-v2.1 switches?
- Todd Kline
Wgate
( ESNUG 320 Item 13 ) --------------------------------------------- [6/2/99]
From: [ A Test Products CAE ]
Subject: Test Compiler / DC-XP Uses Excessive Memory With Tri-State Logic
John
Hi! One of our customers hit a nasty, defect with DC-XP / Test Compiler
that causes excessive memory usage by the insert_scan command while
inserting three-state enabling/disabling logic. The defect has actually
been there for two and a half years, and has only just been discovered,
so we don't think that too many customers will hit it. However we'd like
to spread the word rather than run the risk. I'm pleased to say that:
a) The defect is fixed in the 1999.05-3 Cluster Release
b) There is a workaround for those using other releases
The defect is in how DC-XP's insert_scan command handles library cells with
a large number of input or inout pins. You are most likely to encounter
this problem with a memory cell, but could encounter it with other cells.
You will see this limitation only under the following conditions:
1. There is a library model of a cell with an output bus that has the
three_state attribute defined in the library
2. There are multiple drivers on the output bus
3. The number of pins on the library cell that are defined as inputs,
or as inouts, is greater than 16.
4. Your library cell is not a black-box.
If you hit this defect you will see insert_scan run very slowly indeed
during the insertion of enabling/disabling logic and, in the extreme case,
you will get an "out of memory" error. If you do not wish to install the
1999.05-3 Release then the workaround to overcome this limitation is to
create an alternative model to use during scan insertion. Create a
"bit-blasted" structural model of the memory cells that uses single
three-state buffers to model the 3-state functionality of the memory cell,
and relink your design to use this structural model rather than the
original library cell. Then, once you have completed scan insertion you
can relink to your original model.
SOLVIT Test-242.html gives full details of the workaround.
- [ A Test Products CAE ]
( ESNUG 320 Item 14 ) --------------------------------------------- [6/2/99]
From: Andrew Dauman <andrew@synplicity.com>
Subject: Synplicity Users Group Registration Deadline On Friday, June 4th
John,
If any of your readers want to be at our 3rd Annual Synplicity User Group
meeting at DAC'99, go to:
http://www.synplicity.com/support/usr_group/usersmain.html
Where:
Wyndham Riverfront Hotel, New Orleans, Louisiana
When:
Sunday, June 20, 1999
9:00am to 4:00pm (complimentary lunch)
Check-in 8:30am - 9:00am (continental breakfast)
Registration ends this week.
- Andrew Dauman
Synplicity
( ESNUG 320 Item 15 ) --------------------------------------------- [6/2/99]
Subject: How Do You Model 2 Gbytes Design Mem w/ A 0.5 Gbyte Workstation?
> Does anyone know how to model large amount of memory in Verilog without
> using too much simulation memory space? For instance, if there is
> 1 GBytes of memory in a design how much memory will the memory model
> take during the simulation?
>
> How can the simulation memory requirement be reduced as much as possible
> without degrading simulation performance?
>
> Young K. Choi
From: Edward Arthur <eda@ultranet.com>
Use a sparse memory model.
You can write one via the PLI, use the one supplied with Verilog-XL
or buy them from Denali (http://www.denalisoft.com/) or Synopsys
(http://www.synopsys.com/products/memory/memory.html)
- Edward Arthur
---- ---- ---- ---- ---- ---- ----
From: dave rich <@cadence.com>
Perhaps this should be added to the comp.lang.verilog FAQ.
The Verilog-XL release directory comes with a PLI example called "damem".
I believe other vendors also provide it as a PLI example. It was never
copyrighted. Here are some excerpts from the appnote. System tasks:
$damem_declare
$damem_read
$damem_write
$damem_initb
$damem_inith
The $damem_declare System Task
=============================
The $damem_declare system task declares a memory in your design. It is an
alternative to the use of the reg keyword to declare an array of regs. When
you use the $damem_declare system task to declare a memory in a design,
Verilog-XL does not allocate memory space in your workstation for that
memory in your design until you enter another system task for dynamically
allocated memories ($damem_write, $damem_initb, or $damem_inith) that writes
data to that memory in your design. When Verilog-XL allocates this memory
space, it only allocates enough memory space to hold the data written to
that memory in your design.
$damem_declare(name_of_memory,bit_from,bit_to, addr_from, addr_to);
$damem_write (name_of_memory,addr,value);
$damem_read(name_of_memory,addr,register);
( ESNUG 320 Item 16 ) --------------------------------------------- [6/2/99]
Subject: Where Can I get An Introduction To Memomry Compilers For My Chip?
> Where can I get an introduction to memory compilers? What I am looking
> for is the capability of these tools and quality of the design. Any
> references will be useful.
>
> - Tariq Afzal
From: Thomas Dejanovic <thomasd@cisco.com>
Talk to your local ASIC vendor like LSI or IBM as a start. Memory compilers
are typicaly a vendor supplied tool unless you are doing COT or Full Custom
design in which case your vendor will probably suggest which memory
compiler(s) to use and where to get them.
- Tom Dejanovic
Cisco Systems
---- ---- ---- ---- ---- ---- ----
From: jcooley@world.std.com (John Cooley)
Tariq, I'd like to add that a lot of times you won't be seeing a memory
compiler. Instead your foundry will ask you exactly what type(s) of
memories do you want for your chip and then they'll provide you a Verilog
(or VHDL) behavioral of them for simulation purposes and you're to treat
them as black boxes in synthesis. That is, you may be gearing up to learn
about memory compilers when your foundry won't expect you to use one in
the first place.
- John Cooley
the ESNUG guy
|
|
