Subject: Re: Performance issues
From: Jay Lawrence (lawrence@cadence.com)
Date: Wed Apr 09 2003 - 18:40:39 PDT
Steve,
I believe there are many reasons VITAL has not been as fast as Verilog,
and as Ajay says none of them are purely in the VITAL specification.
Tool Architectures -
VHDL tools traditionally have performed "separate compilation". It is an
obvious choice because VHDL is such a strongly typed language that the
first impulse is to parse it and then immediately generate code for each
design unit. You can then share the code for each design unit and get
significant memory savings and compile time savings. All the major
vendors do this. The problem is that for gate-level optimizations the
big-bang optimizations must be done with global visibility, after
elaboration is basically complete. Only after elaboration is complete
can many of the truly powerful gate-level and timing optimizations be
performed.
Verilog however came from an interpreted heritage and is anything but
strongly typed. No significant code generation for Verilog can be done
until you resolve all the types, hierarchical references, crazy
parameter values, etc. These are all determined after elaboration, so
late code generation allows the global analysis to happen and gate-level
benefits to be reaped.
Some vendors are moving to "delayed" code generation, where possible,
and are improving gate-level performance but it is a very expensive (in
R&D investment $$) change and must be motivated by business rationale
that leads to the next categories ....
Library Availability -
VHDL (or at least VITAL) came along years after Verilog was well
established with all the ASIC vendors. It took a long time for any
reasonable libraries to be available. Until they were, customers
couldn't do VHDL asics, and until customers demanded them, vendors
weren't going to invest in a lot of optimization. This, of course, is a
vicious cycle because if vendors don't make it fast, customers won't
want it, and won't push on vendors to support it.
Competitive Pressures -
Verilog came from a gate-level foundation, RTL was an afterthought
(although it seems long ago now). All Verilog users have gate-level
content in their designs, with detailed timing. A simulation vendor can
not survive as a major Verilog player without handling these gate-level
components with very high performance and accurate timing. If they don't
they'll lose the benchmark and be thrown out on their ear.
The VHDL community started in the behavioral domain and worked down to
gates and VITAL. When there were no libraries available, they adopted
alternative solutions ...
Alternative Solutions -
Because of the library availability and performance, many VHDL users
adopted mixed-language solutions, or moved to Verilog after synthesis
entirely.
Many of the issues outlined above are now less important, but combined
have led to less of an emphasis on gate-level performance in the entire
community. To break this deadlock better library support from ASIC/FPGA
vendors is required, more demand for a VHDL specific solution from
users, and gate-level performance oriented architectural changes by tool
vendors.
None of these issues require a new gate-level library format.
Sorry to be so long-winded,
Jay
===================================
Jay Lawrence
Senior Architect
Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
This archive was generated by hypermail 2b28 : Wed Apr 09 2003 - 18:43:02 PDT