( 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)
|
|
