Whoa! George Orwell's "Big Brother" is alive & well in the U.S. credit
card companies! Last week, while I was at the Mentor User's Group in
Portland, Oregon, I told my travel agent 3000 miles away in Eastern
Massachusetts to buy airplane tickets to Japan with my credit card. (I'm
going to speak at the Japanese Synopsys User's Group next week and they
wanted me to buy the tickets which they'd re-imburse because it's cheaper
than buying them in Japan.) Within 4 hours I had a message on my home
answering machine from my bank's fraud division asking me to call them as
soon as possible because my last credit card purchase had me 3000 miles
away in the Portland Marriott -- yet my card was used near Boston for a
large purchase a few hours ago! I phoned and explained the situation. A
few days later I got kind of spooked realizing how closely we're being
"altruistically" watched by large institutions. Talk about 1984! Whoa!
- John "Hi, VISA!" Cooley
the ESNUG guy
( ESNUG 229 Item 1 ) ---------------------------------------------- [11/3/95]
Subject: (ESNUG 228 #9) AMCC's PCI Is Junk; Is Synopsys's DW PCI Worthwhile?
> In your travels, have you chanced to meet anyone using the new Synopsys
> DesignWare Components PCI Macro Set yet? My understanding is that this is
> a collection of parameterized, synthesizable Verilog or VHDL models of
> various building blocks from which one can assemble PCI controllers. By
> configuring the blocks and adjusting the parameters, one can tailor-build
> an "application-specific" PCI controller. This sounds like a great concept.
From: [ Keep Me Anonymous! ]
John,
Please keep my name and company anonymous. I tried to be honest in my
appraisal of Synopsys PCI product. I'm sorry if I come across as rather
negative, but then it really was a rather bad experience. I actually had
to leave out the worst details so my identity wouldn't be obvious to
Synopsys.
A DW PCI part does indeed sound like a great concept. A functionally correct
PCI controller which can be parameterized for any application and then easily
synthesized into gates which meet PCI's stringent timing requirements? Given
the current market opportunities for PCI products and the design complexity
of this interface, this would be a golden product. Unfortunately, Synopsys
has the concept but lacks the expertise and experience to pull it off.
My company has had considerable experience with Synopsys's 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.
Their verification methodology is woefully inadequate to achieve the
correctness needed for commiting to ASIC design. This problem is certainly
very difficult given the paramaterized nature of the product, since there
are endless configuration possibilities. However, the bugs which we
routinely uncovered were so basic and easy to find that they indicated a very
cavalier approach to verification. The same can be said of their regression
testing. Bug fix releases were commonly accompanied with new undetected
bugs. They really seem to be relying on their customers to verify the design
for them. They acted like they were solving an academic problem and were
puzzled by our concerns for correctness.
As far as synthesis and timing, parts of their design cannot be made to
meet timing without restructuring the source code. Synthesis constraints
alone will not do the job. They have difficulty understanding this and
have not written the HDL to specifically meet timing. They seem to
believe that synthesis alone will solve any timing problem, regardless
of the coding style. Their synthesis scripts use set_multicycle_path to
disable many input paths from timing consideration. When running
simulations with actual timing, we found that many of these paths were
not multicycle but were actually very critical paths. This indicated
that they really did not understand the design and that they had not not
done any dynamic timing analysis to verify the correctness of their
false path analysis.
In summary, at the time when we gave up on using Synopsys's PCI product,
it was clearly not suitable for production use. We felt that the
additional development time required for Synopsys to get the logic and
timing correct were not worth the considerable schedule hit and that the
likelihood of successful silicon would still be very uncertain. We
pursued another alternative and have no regrets.
Of course, some months have passed since then and perhaps they are
making some progress toward maturity. Any ASIC based approach to PCI is
a very expensive and risky commitment. My advice is to think very very
hard prior to committing to any PCI vendor who cannot provide you with a
reference from a satisfied customer with actual silicon. Synopsys will
be unable to provide you with such a reference.
For alternatives, a good source of information on PCI issues in general
and simulation/conformance models in particular is to subscribe to the
PCI SIG internet mailing list. This is a mail reflector. To subscribe,
send mail to "pci-sig-request@znyx.com" with a subject of "subscribe". The
content is low noise and generally well informed.
There are several other vendors listed below who offer synthesizable PCI
controller models. I don't know enough about each of them to compare.
But, I would say that RaviCad's product is most mature and has certainly
generated usable silicon. Some of these are customer-configurable
through a descriptor file, like Synopsys. Others will perform the
customization for you by supplying some amount of engineering time with
the purchase price. Some offer source code, unlike Synopsys which supplies
encrypted source files. Check out:
RaviCad: 408-720-6120 | SICAN GmbH, Germany: mun@sican.de
Chrysalis: kevinm@chrysal.com | Logic Modeling: contact Synopsys
Sand Microelectronics: 408-441-7138 | IBM: yaron@vnet.ibm.com
Eureka Systems: Milpitas, CA ??
There are also a number of ASIC vendors who will customize a hard macro of
their own design for your application, such as IBM, LSI, NEC. Others will
offer a synthesizeable model as a service, typically based on RaviCad.
You will also need a bus functional model with a conformance test suite
in order to verify your design. The test suites are usually based on the
PCI SIG conformance check list and are a valuble starting point for
verification. Of course, they are not exhaustive and still must be
supplemented with specific tests of your own which can be written in the
language of the bus functional model. 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 PCI controller and
should not suffer from association.
- [ Keep Me Anonymous! ]
---- ---- ---- ---- ---- ---- ----
From: chuckg@arnet.com (Chuck Gollnick)
John,
I have looked at RaviCad, but their license agreement is so restrictive that
our legal department refused to sign off on it and cautioned me that it would
be very bad for me professionally, too. Basically, if I am ever in the same
room as the RaviCad source code, or in any room served by the same
ventilation system as a room containing RaviCad code, I am prohibited from
developing any PCI code of my own for three years. That's just not a license
paradigm that I'm willing to promote.
- Chuck Gollnick
Digi International
---- ---- ---- ---- ---- ---- ----
From: gord@vdc.smos.com (Gord Wait)
John,
We haven't used this product from Synopsys, but I just wanted to comment:
My gut feeling is that you could create your own PCI subsystem for about the
same price/effort, and your company now has PCI technology of its own.
We have our own in house PCI design, and wrote our own behavioral models to
test it out. We were then required to test it against a commercial PCI test
rig, as an additional check. While it was worth comparing to an outside PCI
test rig, we found that our internal test rig to be far more stringent and
a "HECK" of a lot easier to use than the expensive commercial rig.
Having said that, it may well be that the Designware stuff is hot, and
unbeatable. If you could try before you buy, that would help. You'll still
have to learn PCI so you can prove it works, though...
- Gord Wait
S-MOS Systems Vancouver Design Centre
---- ---- ---- ---- ---- ---- ----
jacko@altera.com (Jack Ogawa) offered:
> Chuck, Have you considered using programmable logic devices? I know that
> there may be some reasons that you may not want to use PLDs (cost perhaps
> being one of them), but, if you are looking at a $150K solution via
> Synopsys, then you might want to look at a <$10K solution from Altera.
>
> We have a PCI design kit available, which has design examples of a
> target, master, and combined master/target interface. Also, on our BBS,
> we have these examples with burst mode implemented.
>
> - Jack Ogawa
> Altera Corp.
Chuck Gollnick (chuckg@arnet.com) replied:
Hey Jack, Sure, you and I have talked Altera PCI in the past. Of course we
looked at just about every FPGA vendor's PCI stuff. They range from "some
college student did this as his term project and now we're distributing it"
to "after $250,000 in development expenses, we are glad to present you with
50,000 lines of fully-commented Verilog and a six-volume handsomely-bound
documentation set..."
The chief concern I have about an FPGA-based approach is that we would then
have to come up-to-speed on the vendor's tool set.
AT+T's really excellent looking FPGA macro is written entirely in VHDL and
synths with Synopsys. AT+T feels that it is highly retargetable. So, they
make you swear by everything holy that you'll never even think about
considering synth-ing it for anything except an AT+T ORCA FPGA or an AT+T
ASIC. The problem here is that ORCA arrays are expensive little buggers and
AT+T is one of the most pricey ASIC vendors out there & really doesn't want
to open the door of their precious fab unless you want a million parts.
Don't get me wrong, I love ORCA FPGAs and strongly recommend them. But, for
production use in a competitive market, they're best used as a stepping stone
toward an ASIC.
Xilinx has, IMHO, has the best PCI FPGA macros. They're on their third
generation product and have really put effort and expense into this new
product. However, it's currently in "beta" testing and they're unwilling to
give me any names of anyone who's using them. I did shake one person out of
the bush on usenet and he sang high praises for the new Xilinx PCI macros.
Unfortunately, the crew Xilinx hired to do the job did not feel that they
could adequately control the synth tool to get them the timing they wanted.
The Xilinx macros are very high performance (many FPGA-based PCI macros
are real dogs on the PCI bus), and, if you run the numbers, Xilinx needs
every nanosecond possible to get the performance they wanted from their
FPGA. In fact, they even had to die-rev the FPGA to get one fast enough
for the application. Let's face it, 33 MHz is really pushing a Xilinx part
a lot faster than she's ever gonna go without extensive handcrafting and
layout control. So, they really need tight control of exactly how the
design turns into an FPGA. As a result, the design is a crazy mix of
VHDL and ViewLogic Schematics. We don't have View-ilLogics and I'm not
excited about getting it.
Altera suffers one major problem that caused me to simple pan your PCI
product: AHDL. 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 VHLD like everyone else? Quite frankly, when
I saw those four little letters, my response was "Run Away, Run Away."
Sorry, but that's the truth. Friends don't let friends learn AHDL...
Also poking their head in PCI is Quicklogic. The tech support guy "thinks
they've got some sort of PCI thing." Well, they do, but it's very limited.
I've learned, in my long search, that all PCI controllers are not created
equal. It's like walking up the rental car desk and asking for "a car".
You could get anything from a beat-up Chevy Sprint to a brand new Lincoln
Towncar. Wow, there's quite a range of what is defined and sold as a
"PCI controller."
Atmel has PCI-compliant parts, but no macro. Roll your own.
Lattice is about the same as Quicklogic.
Actel has a sort of middle-of-the-road approach. But, again, their's is
schematics for either ORCAD (gag me with one of those really big wooden
spoons that people hang on the wall next to the really big fork), or
View-ilLogic.
Now, Synopsys looked around and found that someone in Germany had targeted
their Designware product for a Xilinx FPGA successfully. I also know of
one American company that has done so for AT+T ORCA arrays.
So, that's the rundown on the PCI for FPGA market as I see it.
- Chuck Gollnick
Digi International
(Formerly Arnet Corporation)
( ESNUG 229 Item 2 ) ---------------------------------------------- [11/3/95]
Subject: (ESNUG 228 #10) "Is The Synopsys Floorplan Manager Worth Its 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: Zia Khan @ Intel
Hi John, I thought I'd put in my $0.02 worth.
First, Floorplan Manager (FM) is an incorrectly named product. It does not
floor plan as one might expect. It is an interface between Synopsys and a
REAL floor planner or P&R engine. Now, about it uses.
1. Most ASIC vendor's libraries provide a set of wire load models that are
grossly inaccurate (or have huge margins built in). If you design to
these targets you will be very hard pressed to meet your timing goals for
high frequency designs.
We use the FM for generating custom wire load models after a trial layout
to get a good wire load model. This helps us fine tune the synthesis
results for a better pre- and post- layout (actual layout for sign off)
correlation.
Our experience has been that (for various reasons) the models in vendor
libraries are up to 200+% inaccurate. With FM generated models you can
come within 25% of actuals. Using custom models helps reduce post-layout
surprises and design iterations.
2. The PDEF interface is a useful feature that allows you to have different
physical and logical hierarchies. So far have not have a need to use it.
I would like to point out that, in my opinion, the wire load calculation
algorithm used by FM has one flaw. When computing wire load models for
higher level design units (major blocks of the chip) the tool incorrectly
includes all net that exist at lower levels of hierarchy thus giving a much
more optimistic estimate (lower than actual) than the real capacitances. I
have found it to be over 200% off for nets that exist at top level of a chip
(nets interconnecting large blocks). BTW, we have communicated this issue to
Synopsys who do not this is a flaw & therefore are not motivated to fix it.
- Zia Khan
Intel Corp.
( ESNUG 229 Item 3 ) ---------------------------------------------- [11/3/95]
From: puneet@qcktrn.com (Puneet Jethalia)
Subject: Dc_shell Does Verilog & VHDL Yet Fails To Output EDIF
Hi, John,
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
What's going on here and what is it's workaround?
- Puneet Jethalia
Quickturn
( ESNUG 229 Networking Section ) ---------------------------------- [11/3/95]
Pasadena & Fremont, CA - Silerity, Inc. seeks EDA developers w/ VLSI exper.
for R&D on new synthesis paradigm. Principles only. "rdoherty@viewlogic.com"
San Jose, CA - Altera seeks engineers w/Synopsys/Verilog/VHDL experience for
R&D, support & customer training work. No headhunters. "jacko@altera.com"
RTP, North Carolina & Rockville, MD - Mentor seeks apps. engineers w/ ASIC/
Verilog/VHDL/Synopsys experience. No Agencies! "mike_walsh@mentorg.com"
|
|
