( Post 123 Item 1 ) ------------------------------------------- [01/08/03]
Subject: (Post 120 Item 4) "Seeking Altera & Synopsys Stories"
> 1. does anyone have any experience with using synopsys for ALTERA fpga's?
>
> 2. anyone who has done an fpga of ANY kind with synopsys:
>
> in retrospect, do think this was the way to go? or, more diplomatically:
> if you had to do it all over, would you do it this way again?
>
> what was the main advantage in using synopsys over the fpga vendor's
> synthesis? was it just the advantage of using verilog or vhdl instead
> of a separate language? if the vendor's synthesis system could read
> verilog or vhdl at the rt-level, would you still use synopsys?
From: [ An Anonymous Actel User ]
In response to number 2.
We (my group) has done quite a few VHDL to Actel FPGA designs. We
have a number of reasons:
-we like the tool flow;
-we sometimes get VHDL from customers that want us to finish/optimze
the design for them;
-VHDL is fast to write, and even faster to change (espeically in
comparison to hacking schematics);
-the power of the front-end VHDL simulations, we do as much simulation
as possible at the VHDL level, and other than checking timing at the
gate level we almost always have 100% functionality first pass;
-the ability to use powerfull full VHDL tools at the beginning to test
different possibilities before becoming device/vendor/architecure
specific; (note: we use Synopsys for synthesis, but not for the VHDL
work)
-as more libraries become available we like the ability to be able to
move designs to different vendors parts.
After all that is said, I have to warn you that all is not perfect.
We have had tool problems/incompatabilities, library problems,
difficulty controlling the tools to get the desired output, etc. Even
with all these problems we believe that the HDL -> generic-synthesizer
-> vendor-specific-layout is the best and most efficient in the long
run. We don't like getting trapped into limited vendor specific path
until we have to. At worst you are trapped by a "bad" decision, and
have no capability to bail out. At best it usually turns out to be
"penny-wise and pound-foolish", because invariably someone will want
you to do something that the specific tools or parts don't support, and
any time you saved in the first path with the vendor-specific tools
will be lost in tool limitations and/or moving to a different part.
Just opinions, but hope this helps.
-- An Anonymous Actel User
-- -- -- -- -- -- -- -- --
From: "Bradshaw, Lee" <LBradshaw@engineer.clemsonsc.NCR.COM>
I worked on a video board design last summer/fall that used verilog and
Altera 7032's. The fpga's and parts of the board were designed in verilog
(Silos III on a pc.)
Synopsys (Solbourne) translated the verilog code into an edif netlist. The
beta version of the altera libraries had a bug -- the output enable was in
the wrong state (different in the 5000 and 7000 series.) The work-around
was to change the state in the verilog code so that the gates would work.
Rick Schuckle read the edif into the Altera software (back to the pc).
There were problems with the global clock, reset, and output enable signals.
The synopsys edif had to be modified - esentially instantiating the global
drivers. There have been several software updates since then, and I think
some of our problems were fixed. After the modifications, the fitting
process worked correctly. (It worked before, but used too many resources
since it wasn't using the global lines.)
We went through several versions of the verilog code trying to get the
design partitioned without using the automatic partitioning available from
Altera. One of the problems with these parts is that a small change in the
equations may require pins to be reassigned, and we wanted to minimize that
possibility by manual partitioning and resource assignment. (We guessed
that the state machines were more likely to need new terms than the pure
combinatorial logic, so we tried to leave cells available for them to
expand.) Our early boards had a breakout pattern with a double set of vias
around the fpga's as a backup. Then we could cut the trace between vias and
have two holes to solder into. I have seen some brochures about a part that
has a programmable routing ring around the core. If the pinout of the core
changes, you can still have the same external pins. Recommended.
This wasn't the end of our story. Our system simulation group wanted to
verify the board and they use Mentor. This caused a few more headaches.
The edif out of the Altera software wouldn't read back into synopsys because
they used parts that weren't available in the synopsys library. The output
edif uses the smallest gate available (and10) instead of the one actually in
silicon (and12). These had to be changed and the extra inputs tied high.
Then I used a symbol library which mapped altera gate names to mentor
primitives to generate a mentor do file.
I used synopsys so I could use verilog instead of altera hdl. In the end I
would have to use synopsys anyway to transfer the design to mentor. If
synopsys could fit the part, I might use it in the future. If there are
strange requirements like verilog, edif, and mentor netlists I would
probably use synopsys. Otherwise I would use the verilog interface Altera
is working on.
I finally got around to looking at the 3.0 manuals. They have some of the
synthetic library descriptions that I was asking for previously. (Amazing
what you find when you read the manuals.) The problem is the examples in
chapter 1 are in VHDL, and the simulation files online are ALL in VHDL.
What about Synopsys support for verilog users? Is this a hint from
Synopsys?
Some of the code examples in chapter 2, which show how to instantiate the
different modules, are over twice as long in VHDL as verilog. I have seen
reasons not to switch, such as more typing and back-annotation. Are there
any reasons to switch if you are working on non-military projects?
- Lee Bradshaw, NCR Corp.
-- -- -- -- -- -- -- -- --
From: [ An Anonymous Synopsys/Exemplar User ]
Well, i didn't use synopsys for ALTERA fpga's or any other fpga, but i did
use a different synthesis tool - Exemplar Logic, (Berkeley, Calif.) to
implement a fpga based prototype and then migrate to ASIC/Gate Array using
synopsys for ASIC synthesis.
I'll describe the design flow: (Final target was ASIC implementation):
1. Design specification and partition into functional blocks.
2. Design of the functional blocks in Verilog-HDL (Including block level
simulations).
3. Translation of Verilog-HDL to VHDL by in house software tool. This step
was required since no synthesis tool was available (Jan 92) to synthesize
Verilog to target fpga technology (XILINX and ALTERA). Exemplar's tool
accepted VHDL but not Verilog.
4. Synthesize the VHDL modules into target fpga technology - using Exemplar.
5. Functional verification of Xilinx on Mentor QuickSim and Altera on MAX++
System. This was a painfull process, since we had to do gate level
simulation on different simulators other than Verilog-XL, which was used
for HDL simulation and ASIC sign off. Again, no Verilog support was
available for Xilin/Altera gate level simulation at the time. We used
in-house tools to translate Verilog test vectors to Mentor QuickSim format
for Xilinx gate level verification. Since we used 16 Xilinx FPGAs and only
one Altera device, we used manual test vector generation for Altera sgate
level simulation.
6. Place and Route of FPGAs. Required few iterations to fit the design into
target fpga.
7. Static timing analysis using Xilinx XACT and Altera's MAX++.
8. Programming of FPGAs and build prototype.
9. a. ASIC implementation using synopsys for Verilog source synthesis.
b. Prototype evaluation, changes in the source code and verification.
10. Simulation of the gate array netlist against HDL design.
11. Static timing analysis of the ASIC, sign off and fab.
12. Final product evaluation -> start of production.
So, we didn't use synopsys in this project, because at that time they didn't
have fpga compiler. They did have a mapping tool, but it was not efficient
at all, because no fpga specific optimization was done.
Synopsys FPGA compiler is pretty new (About 2-3 months). I attended their
synopsys fpga compiler seminar about month ago, in Santa Clara, and my
impression was that they are doing right things, but as i said, it's
pretty new tool and lacks some features, like clock and I/O synthesis.
About my experience using synthesis for fpgas:
Well, advantages using HDL for fpga's design, are the same as for ASIC design.
In this particular project, we successfully used Exemplar/Synopsys to design
fpgas/asic. Yes, i would do it same way, except trying to use same simulation
environement for HDL and gate level simulation. I think today you can find
Verilog libraries for many fpga families (but I'm not sure about Altera).
I think that main advantages are design time and technology independent design
source. I don't know whether synopsys would/wouldn't do better job than other
vendors like Exemplar in synthesizing the HDL into target technology.
Note: There were papers regarding this design methodology at the recent
PLD Design Conference, March 30-31,1993. Santa Clara, CA.
- An Anonymous Synopsys/Exemplar User
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 14,488 other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
