( ESNUG 382 Item 3 ) -------------------------------------------- [11/15/01]
Subject: ( ESNUG 381 #10 ) Some Gotchas When You Tranlate VHDL To Verilog
> We need to do a design involving mixed VHDL & Verilog. Our 1st preference
> would be to translate the VHDL parts to Verilog (our standard language)
> for maintainability. I would like to question your readers regarding
> their experience with translation tools.
>
> - Daniel Szoke
> National Semiconductor Israel
From: "Alessandro Fasan" <alfa@synopsys.com>
Hi, John,
I answered this question when it came up in ESNUG 341 #10. I sent you a
paper that you posted at http://www.deepchip.com/downloadpage.fhtml, as #26.
In that paper I described that at my prior job, I worked on converting from
VHDL to Verilog a big portion of a MPEG2 decoder. I evaluated available
mixed HDL solutions and 3 VHDL-to-Verilog translators. Since our design
environment was based on VCS and our VHDL portion was big but very stable, I
ended up converting the VHDL to Verilog using the vhdl2verilog translator
from Alternative System Concepts, Inc.
My project was successful because I had access to my company's best R&D
resources (A. Fedeli, co-author of the paper, and U. Rossi) and to
Formality. Without equivalence checking you never know if your translator
did the right things!
That experience taught me that there are enough differences between VHDL and
Verilog that in most cases translation can not be done automatically while
maintaining the same quality of results or simulation performance. Only in
highly constrained design coding styles could you expect to get a good
automatic conversion. In most cases you would still need to do manual
translation of portions after doing equivalence checking (to guarantee
correctness) and simulation profiling (to preserve performance).
If engineering resources and time are critical factors for your project, and
if your VHDL code is not synthesizable or changes often, then I recommend
you look into simulating in a mixed HDL environment rather than performing a
language translation.
Here is some background on what kind of performance issues you should expect.
Today, all major simulators offer support for Mixed HDL environments. But
since these two different languages use separate simulation algorithms, there
will usually be some performance penalty when simulating two languages.
How much penalty depends on the simulation technology and how much the two
languages interact.
In the high end simulators, advanced compiler optimizations are applied
globally (i.e. across Verilog modules or VHDL processes) to increase sim
performance. But individual language semantics (VHDL delta cycle vs. Verilog
no delta) tend to restrict the scope of most optimizations to a specific
language. Basically this means that the more you mix & match the languages,
the less optimizations you can use.
If you do simulate using mixed VHDL/Verilog source, to maximize performance
remember to keep the interaction and boundaries between the two languages to
a minimum. Be cautious about where and why you plug in a different language.
Use it for large design blocks that cannot easily be rewritten. Mix the
languages closer to the top of the design (allowing more compiler-based
optimizations to be applied.) Mixed languages is still quite efficient if
used only for a few large IP blocks, or for plugging in some VHDL Vital
modules into a Verilog gate netlist.
And of course use a high performance compiler technologies, like those
found in VCS, NC-Verilog, Scirocco, and NC-VHDL.
- Alessandro Fasan
Synopsys, Inc. Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: Alan MacKenzie <Alan.MacKenzie@nsc.com>
John,
I have been doing some work on this to convert the a design we have got from
a Danish company into Verilog. Up until now, we have just simulated with
ModelSim, but the majority of our simulations are done in Verilog, so we have
to maintain two environments which is a bit awkward.
I managed to find and evaluate two tools:
- xhdl from X-TEK, Inc.
- vhdl2verilog from Alternative System Concepts, Inc.
for the design I had. Both tools converted most of the code, but ASC's
vhdl2verilog was definitely the better of the two tools. Both tools made
mistakes, but the vhdl2verilog tool made fewer mistakes. The xhdl tool is
cheaper as a result.
In both cases the original VHDL was modified to make the tools job easier.
The resulting Verilog output had to be modified to remove the bugs the tools
each had added. If the VHDL design is going to be updated regularly and
then converted to Verilog each time, it is beneficial to change your VHDL
source code to absolutely minimise the amount of manual work required on the
Verilog. The design I used was 60 K gates, so it was pretty large and it
only required one major change to remove VHDL aliases plus about a dozen
other minor changes to the VHDL and then about half a dozen minor changes to
the resulting Verilog output -- so I don't want to give the impression that
it required a large ammount of effort or that it radically changed the
original VHDL design but this will inevitably depend on how you have coded
your design. Here is what ASC's vhdl2verilog couldn't handle:
- complicated reset logic had to be removed from a process statement.
Only a simple reset signal could be handled.
- Verilog has no equivalent to the generate statement. Both tools can
roll out generate statements but I tried converting a codec design
which had parameterised generate statements but this is not possible.
Not the tools' fault.
- couldn't handle multi-dimensional arrays of data. This can be handled
in Verilog with a single dimensional array but the conversion is not
simple and can't be done by the tools automatically.
- doesn't handle VHDL aliases. Claim to handle them but they don't.
- can't handle power operator because Verilog doesn't have one.
Supposed to be an update to vhdl2verilog so it can handle powers of 2
but I never used it.
One of the annoying things about the tool was that it wouldn't warn you of
VHDL constructs it couldn't handle. It just produced rubbish code!
Critical to using this tool reliably was we used Avanti Chrysalis formal
verification to compare the Verilog with the VHDL. This was a relatively
easy process and it picked out several issues that the simulations missed.
To answer Dan's specific questions:
> 1. What VHDL constructs are/were translated
All constructs except the ones I have listed above were handled, but the
design I had probably did not use the full language. ASC won't handle
testbenchs either.
> 2. Quality (readability) of the translated Verilog
ASC's output seemed to be OK. Maintained the comments. I didn't do any
work with the design after this so it is difficult to critize.
> 3. Compare synthesis of: VHDL -> gates VS. VHDL -> Verilog -> gates
Ran synthesis to check it compiled, but I didn't do a comparision. Assumed
that it would be the same or very similar because the designs were
functionally identical, but synthesis is a non-deterministic process, so I
guess this may be naive.
> 4. Compare sim of: mixed VHDL-Verilog VS. translated Verilog-Verilog
Not sure what Dan wants to know. Mixed signal simulation has some issues,
but the ModelSim tool works well. The main problem as mentioned above is
that two simulation environments had to be maintained and there is always
the problem of timing hazards that cause a problem with one version of
Verilog but not with another plus being forced to use a tool you aren't
familiar with.
For ASC vhdl2verilog we have had several different prices which tend to get
lower as the end of quarter gets closer. The last quote was $10K for a node
locked license but that offer ran out at the end of september. Typically
they price around $20K to $32K, with $4K to $5K yearly maintenance.
The xhdl tool was about $13K for floating and $11.5K for node locked.
- Alan Mackenzie
National Semiconductor Greenock, Scotland
---- ---- ---- ---- ---- ---- ----
From: Daniel Szoke <Daniel.Szoke@nsc.com>
Hi, John,
I know you like follow-ups from the people who post questions on ESNUG.
Here's my follow-up to my VHDL-to-Verilog translator tool question:
1) I started out this journey (before the ESNUG email) with a web link:
http://www.vhdl.org/comp.lang.vhdl/FAQ3.html#verilog2vhdl
We tried their "vhd2vl" tool on a block of VHDL and it failed on
many types of VHDL language constructs.
2) An EDA vendor suggested mixed Verilog-VHDL simulation. We do not like
this direction because:
a) We want to learn, modify and maintain the IP. To do so in VHDL
would mean too big an investment in a two language environment.
b) I heard at the Verisity Users meeting that there are a lot of
problems with the mixed Verilog-Vhdl simulations.
3) InterHDL (now in Avanti) have an internal effort to write a VHDL to
Verilog translation tool.
My past experience (in automatic Pascal to C translation) makes me a skeptic.
After all, why would there be Verilog/VHDL wars if translation was so easy?
Still, finding ways to minimize the pain of conversion is important.
- Daniel Szoke
National Semiconductor Israel
|
|
