Editor's Note: I just got back from a week in Japan at JSNUG: the Japanese
Synopsys Users Group meetings in Osaka & Tokyo. I must say after this
trip, I now have the utmost respect for Japanese engineers. This has
nothing to do with their technical skill (which varies as much as in the
U.S. & Europe) nor their culture (which was completely alien!) -- it has to
do with the fact that over the years I've seen Japanese engineers turn up
at DAC's, IVC's, VIUF's, SNUG's, etc. in the U.S. -- and they were awake,
alert & thinking. Flying from Boston to Japan (East to West) was easy.
Just stay up 11 more hours (sort of like college finals week) and you're on
local time. But, going from Japan to Boston ( BACK 11 hours ) has been
totally devastating on my internal clock! It's been 5 days since I got
back and I'm still wide awake when everyone's asleep & vice-versa! I
don't know how the Japanese do it!
- John Cooley
the ESNUG guy
( ESNUG 230 Item 1 ) ---------------------------------------------- [11/95]
Subject: Pro & Con Altera HDL (was "ESNUG 229 #1 Is Syn DW PCI Worthwhile?")
Chuck Gollnick <chuckg@arnet.com> writes:
>Altera suffers one major problem that caused me to simple pan Altera's PCI
>product: Altera HDL. I've used it in the past and I want it to die. Sorry,
>but the last thing we need is yet another hardware description language.
>Why can't you use Verilog or VHDL like everyone else? Quite frankly, when
>I saw those 4 little letters (AHDL), my response was "Run Away, Run Away."
>Sorry, but that's the truth. Friends don't let friends learn Altera HDL...
From: jacko@altera.com (Jack Ogawa)
John,
Got Chuck's e-mail on PCI; looks like he's been spending some time looking
at many of the solutions that are on the market.
AHDL: Ok, I hear his opinion. But, as you might imagine, there is a
real reason why we didn't do a VHDL version. Let's look at the problem
in terms of functionality, and then optimization.
As a designer, I would imagine that you would focus on the functionality
of your system first. In fact, your first task in an ideal approach to
designing with an HDL is to complete a functional, synthesizable
description, which would be put against a test bench. Subsequently,
then, the task of optimization for the target silicon would begin.
As far as re-usability of a functional description, any well-written piece
of VHDL or Verilog should be functionally compatible with various silicon
targets (including ASICs). The question here is the optimization.
So, what's the problem with VHDL? The problem here is that while VHDL
(or Verilog) is great for describing the functionality of a design, it
is poor for describing specifc logic structures which have been optimized
for a given piece of silicon. So, what's the answer? Well, it would seem
to me that you could instantiate a PCI interface into your overall HDL
design, and then plug in topologies which have been optimized for your
target silicon. In this case, the topology is described in Altera HDL.
In fact, this is the model that LSI Logic has been pushing for several years.
Buy a core from them, instantiate it in your system level description,
and let them provide you with an optimal topology.
Now, there is really one hole which we are trying to address: behavioral
descriptions of the interface so that you can functionally simulate. Oh, I
guess you would argue there are 2 holes -- the additional one being that if
you wanted to change the functionality of the interface, you would have to
modify the Altera HDL.
So, our motivation was to provide functionality described in a language which
allowed us the power to optimize FPGA's. I believe that once we get some
behavioral code in place, that Altera HDL will be a complete solution.
By the way, our implementation easily meets the 33 MHz PCI spec, as well
as the 7ns set-ups and the 11ns clock-to-outputs.
- Jack Ogawa
Altera
---- ---- ---- ---- ---- ---- ----
From: [ No, I'm Not A PCI Consultant ]
John, please don't include my name in this article if you decide to print it.
You wouldn't believe the hassels I have to go through to get permission to
put my name on any printed article in my company.
We recently completed a PCI design using an Altera PLD, and ran into a number
of problems. I first wrote the entire code in Verilog and compiled it using
Synopsys, and the resultant netlist only ran at about 10 MHz. It took
extensive hand tweeking and writing many parts of it in Altera HDL before we
finally got the final design to run about 33 MHz, which was our target. The
Altera part (series 8000) certainly can run that fast, but the software can
not take advantage of its speed without manually forcing the place and router
to use the internal cascade paths. Altera and Synopsys could fix this with
a major software revision, but that would take time and money, so don't hold
your breath.
By the way, we inserted the part in a P.C. board and plugged it into a PCI
slot, and after 4 weeks of debugging, the board actually worked! For anyone
who casually thinks they can read the literature about the PCI bus and whip
up a design and debug it in a month or two, they are going to be sadly
mistaken. Plan on at least 4-6 months for your first design cycle. The
learning curve for this bus is very long ("PCI, Hardware and Software" by
Solari & Willse is over 600 pages, and even that doesn't tell you everything
you need to know to design such a board). Hiring a consultant who has
successfully done at least one PCI design would be a very smart idea.
- [ No, I'm Not A PCI Consultant ]
( ESNUG 230 Item 2 ) ---------------------------------------------- [11/95]
Subject: (ESNUG 228 #10 229 #2) "Is Syn Floorplan Manager Worth The Price?"
>I would be very interested in hearing from people that have real-life
>hands-on experience with the Synopsys Floorplan Manager. For example, does
>it really do something that I can't do myself by tweaking the constraints &
>process by which I use the dc_shell? If so, under what circumstances would
>this extra something be worth the extra something Synopsys is asking for it?
From: jeffb@asic.mtv.nec.com (Jeff Buckles)
John,
I'd like to share an experience that I just completed with Links-To-Layout
(aka Floorplan-Manager).
// Synopsys Floorplan-Manger exists mode OFF
In January we processed a design from a customer using one of our 0.5um gate
array technologies. At that time we did not have Synopsys floorplan manager,
and getting the design to meet timing was a nightmare.
The design was completely hand floorplanned (about 15 floorplan regions for
80k gates). The customer used our statistical wire-load models with "-mode
enclosed", so the wire load estimates were very aggressive for lower-level
hierarchical blocks, but (so we thought) a little conservative for
higher-level blocks. However, after place & route, there were some rude
surprises:
- The statistical wire-load model grossly underestimated the wire
load between floorplan groups. Given the following hierarchy:
(Logical) (Physical)
TOP - TOP -
|__ A _ |_ A + A1 + A2
| |_ A1 |
| |_ A2 |_ B + B1
| |
|__ B _ |_ B2
|_ B1
|_ B2
Suppose that module "A" is one floorplan Group, B+B1 is a group,
and B2 is a group by itself. The statistical model (with -mode
enclosed) will estimate nets between B1<-->B2 based only on the
number of gates in all of B. However, in our case, B+B1 and B2
were rather far apart on the hand floorplan, causing the statistical
models to break. (No, we can't ask the customer to change their
logical hierarchy to match the physical; I tried that....once)
But, the real surprise was that it had under-estimated the load
between blocks such as A and B!
- Wire-loads for nets buried deep in the hierarchy were also
underestimated. Consider the same hierarchy again: nets
completely enclosed within A1 will get statistical wire loads based
on the gate count in A1. But the real physical implementation
will allow those gates to spread out over an area that is large
enough to contain all of A+A1+A2. On the other hand, there may
still be some sense of "locality" among the gates in A1.
So setting wire load -mode "top" may yield too *conservative*
wire loads for A1 (as alluded to in ESNUG 229).
- Wire loads for I/O nets were significantly overestimated. This
occurred because the statistical model for top-level nets assumes
that a net is connecting between two floorplan groups. A majority
of top-level nets do this. But since blocks that connect to I/O
are commonly placed near the I/O pads, the I/O nets tend to be much
shorter than inter-block nets.
In cases where the prelayout wireload had been significantly underestimated,
it was obvious that many of the fixes should have been achievable with IPO
("compile -in_place") -- fixes such as additional buffering, replacing
gates with higher-drive versions, etc. But, for whatever reason, IPO was
unable to accomplish the fixes. We played with the compile variables to no
avail. My own (unsubstantiated) speculation is that certain nets were
falling-back to the statistical model during IPO, thus "fooling" Synopsys
into believing that the path was "fixed".
METRICS: It took about five iterations of netlist hand-edits, four quarts of
StarBucks coffee, and a three all-nighters to coerce the layout to meet
timing. Just tweaking constraints didn't help because the nets that "broke"
were just too far "out" to be fixed by adding the small amount of margin that
could be achieved with constraint tweaks. And neither I nor the customer was
willing to risk breaking something else by completely re-synthesizing.
It would be easy to blame the vendor for having lousy wire-load models, to
blame the layout tools for doing a lousy placement, or Synopsys for not being
able to fix the problems. But I'm starting to agree that as long as you're
using statistical wire load models for submicron design there's not much else
that can be done -- it's just The Way Things Are. Many of our customers have
beaten us up on this, but it really is an industry-wide problem (wasn't there
an "ASIC & EDA" (oops, That's "Integrated System Design") article about this
a few months back?)
// Synopsys Floorplan-Manger exists mode ON
This Fall we had an opportunity to re-spin the design. We used virtually the
same design, the same technology library, and the same wire-load models. But
this time I wanted to see if Floorplan Manager Links-To-Layout (LTL) really
worked. The customer agreed to try it. So, we took a preliminary, trial
placement and created a set of custom wire-load models for it. (I had wanted
to make these based on the floorplan clusters, but screwed-up and gave them
the models based on logical hierarchy. I guess it worked anyway!)
Timing analysis on the design with these custom (hierarchical) models showed
that it *almost* met timing at 33 MHz. So I took it into our floorplanner,
created custom cluster-based wire load models, and re-analyzed the timing
using the physical hierarchy and annotated net capacitance. It blew up!! I
had 12ns violations in a 33MHz design!
Since we were only at the floorplan stage, I tried a couple of things.
"reoptimize_design -in_place" and "compile -in_place" didn't do nearly
enough, as I rather expected, even using wire_load models created from the
current floorplan. On the other hand, this did quite well:
reoptimize_design -post_layout_opto \
-tolerance_to_change high \
-map_effort high
The worst violator was now about 1.2 ns, but all the violations were
contained in modules that were deeply nested in the hierarchy. These modules
were fairly self contained (low port/gate ratio) and were embedded in much,
much larger modules. So I was confident that the Placement tool would tend
to tightly cluster the cells in these paths even though they were members of
a much larger floorplan area. We could have broken these modules out into
small floorplan groups, but I was *that* confident that placement would fix
it. (And me, not a gambling man! If it hadn't worked, I'm sure the customer
would have shot me by now....)
This design went throught layout and came back with more violations. In this
case, all of the violations could be attributed to under-estimation of net
capacitance by the floorplanner itself. So:
reoptimize_design -in_place
on the fully Placed & Routed design actually took care of almost all of the
violations.
After that I had to hand-edit exactly two gates to change them from low-power
to high-power, and move a buffer to a higher level of hierarchy so that the
unbuffered signal was available one level up (the signal was used both
locally and remotely -- the local path did not need the buffering and could
not tolerate the intrinsic delay of the buffer.)
I don't yet know if "reoptimize_design -in_place" introduced these three
problems, or why it was unable to fix them. But I plan to find out.
METRICS: One iteration. Two cups of Starbucks. No all-nighters.
- Jeff Buckles
NEC Electronics Inc.
( ESNUG 230 Item 3 ) ---------------------------------------------- [11/95]
Subject: (ESNUG 228 #9 229 #1) Syn DW PCI Sucks; But LMC's PCI Is Fantastic!
>My company has had considerable experience with Synopsys's DesignWare PCI
>product, most of it quite bad. Their basic problem was using a group of
>software developers to essentially design hardware while learning hardware
>design on the fly. They clearly had no experience with logic design at this
>level of complexity and this shows in the quality of their current product,
>as it is far from functionally correct. .... (But) We used the product
>from Logic Modeling (now owned by Synopsys) and can recommend it to be quite
>competent. The LMC group which developed the bus functional model is
>entirely separate from the group which developed the DesignWare PCI
>controller and should not suffer from association.
From: bouchier@news.eng.convex.com (Paul Bouchier)
John,
We've used the Synopsys/Logic Modelling PCI master/slave and compliance test
suite. Apart from a small amount of difficulty getting it to work in a "not
quite zero delay" environment, it worked great. The Verilog part of it is
quite difficult to understand, because it seems to be a machine generated
translation of something originally written in LMC's native modeling
language. However, phone support quality was good.
One issue you have to deal with is arranging for something on the inboard
side of your PCI interface to generate transactions as required by the
master suite, and to accept transactions as required by the slave suite.
It seemed that the compliance suite does a fairly good job of testing all the
types of PCI transactions with lots of corner cases in hundreds of different
ways. It can also check compliance to PCI timing specs. It found a bug in
our chip, so it paid for itself. Be aware that the compliance suite as it
ships out of the box only checks the last data item during a block transfer.
The master & slave are also handy for using as general purpose models to
validate operation of the system as a whole. Generally you'll do more than
just run the compliance tests. So you'll need a PCI master/slave to interact
with your system. The biggest issue here is getting things sync'ed up so
the models do the right thing when the other side of your design expects it.
- Paul Bouchier
Convex Computers
( ESNUG 230 Item 4 ) ---------------------------------------------- [11/95]
Subject: ( ESNUG 229 #3 ) Dc_shell Does Verilog/VHDL Yet Fails To Output EDIF
> I've been trying to generate an EDIF netlist from the Synopsys' design
> compiler. But there seems to be something missing, as a result of which I'm
> getting a "write failed" when I try to generate edif netlist. Verilog or
> VHDL netlists come out fine for the same design. A sample session:
>
> dc_shell> write -format vhdl -output syn_out
> Information: Writing synthetic library implementations for design
> 'process1'. Use "write -no_implicit" to get just the design. (UID-172)
> 1
>
> dc_shell> write -format edif -output syn_out
> Information: Writing synthetic library implementations for design
> 'process1'. Use "write -no_implicit" to get just the design. (UID-172)
> Warning: Some designs have no schematic. (EDFO-1)
> Designs without schematics: process1_DW01_add_32_1 process1_DW01_add_32_0
> process1
>
> Nothing done.
> Error: Write command failed. (UID-25)
> 0
From: rray@msai.com (Russell Ray)
Hi, John.
Synopsys when writing out EDIF needs to have schematics generated unless
you set the edifout_netlist_only variable to true. Otherwise, it wants to
create an EDIF that is a schematic. So if you are not interested in having
EDIF schematics, set edifout_netlist_only to true and re-try writting out
the EDIF. Otherwise, you need to create_schematic -hierarchy before you do
the EDIF write.
- Russell Ray
Mitsubishi Semiconductor
---- ---- ---- ---- ---- ---- ----
From: rmehler@netcom.com (R. Mehler)
I think the problem here is lack of "netlist only" in the the script.
Just add "edifout_netlist_only = true" That might fix it.
- Ron Mehler
---- ---- ---- ---- ---- ---- ----
From: johne@vcd.hp.com (John Eaton)
Select your top level module and do: "create_schematic -hierarchy"
or you can manully click open each and every submodule in your design.
- John Eaton
Hewlet-Packard
( ESNUG 230 Item 5 ) ---------------------------------------------- [11/95]
From: John_Swan-ACIC00@email.mot.com (John Swan)
Subject: Is Synopsys Trying To Kill The Useful Schematics In Design Analyzer?
John,
I would like to ask Synopsys users on ESNUG to speak out if anyone has used,
or desired to use, the schematic cross probing feature of Design Analyzer.
Or maybe would have used it if it was less buggy. Anyone out there???
I ask this because Synopsys is/has been removing support for schematic cross
probing, and apparently schematic support in general from Design Analyzer.
I have been told that this is because no one uses schematics in Design
Analyzer. I was hoping to make use of it for gate level debugging. Now we
are required to generate schematic plots. Does anyone care that we pay
maintenance to have a company *remove* useful features?
- John Swan
Motorola
( ESNUG 230 Item 6 ) ---------------------------------------------- [11/95]
From: Andy.Frazer@idt.com (Andrew Frazer)
Subject: What's The Skinny On interHDL's "Verilint" ? Good Stuff Or Trash?
John,
We are evaluating "Verilint" which is supposed to flag pre-synthesis warnings
in Verilog source code. We are told this tool is supposed to guide the user
to writing better synthesizable code. We are really interested in hearing
any feedback from people who have used this tool. We are not interested in
the workings of the tool itself, but we would like to know if it actually
helps you improve the quality of your code. For example, please don't just
say "we've been using for N years and we like it". Please tell ESNUG what
you like/dislike about it.
- Andy Frazer
Integrated Device Technology
[ Ed. Note: In replying, if you need anonymity, just ask & you got it! -John ]
( ESNUG 230 Networking Section ) ---------------------------------- [11/95]
Stockholm, Sweden - Frontec Telecom AB seeks ASIC designers w/experience in
synthesis/HDL methodology for HW design positions. "chce@sth.frontec.se"
Silicon Valley, CA - verification/software consult., ASIC, test, 15 yrs exp.,
Verilog, C, various assembly languages. Screw Agencies! "dchapman@nbn.com"
El Segundo, CA - Peerless Systems, Corp. seeks ASIC engineers with 5-10
yrs of Synopsys/Verilog experience. No agencies. "k-schmidt@peerless.com"
San Jose, CA - Stock options/401K for Verilog/VHDL Apps Engineer at Design
Acceleration for Signalscan. No Headhunters. mark.leonard@designacc.com
|
|
