Subject: Re: [vhdl-200x], vital issues
From: Jim Lewis (Jim@synthworks.com)
Date: Thu Mar 06 2003 - 19:47:02 PST
If we were to develop a new library solution, someone
would have to spend money to develop sign-off quality
vendor libraries. In the current economy, do they have
money to support two different netlist formats for
sign-off quality libraries?
The current VHDL gate level libraries are slow.
According to a presentation at DVCon, Verilog
gate-level libraries are 4X faster than VHDL libraries.
If we can read and execute Verilog gate-level libraries, I
get the speed I want, without having to pay for two licenses
to run one simulation. Vendors (EDA and silicon) get the
advantage of only having to support one library format.
I suppose if you could give me a library format that would
simulate faster than Verilog gates, I might be interested.
Cheers,
Jim
> Actually the VHDL netlist is not as much as a problem as the
> VHDL gate models. It would be nice to have precompiled libraries,
> whether they came from Verilog or whatever is not of "vital"
> importance. I'd be glad to see less of vital models, they do
> not show VHDL in a good light.
>
> The netlist itself does not lead to inefficiencies, it contains
> no models, just connectivity. I don't see savings to be gained
> by reading in a Verilog netlist over a VHDL netlist.
>
> There are still of course problems reading netlists, mostly
> environmental, library related since the netlist is multi-use.
> Not clear things are better in Verilog.
>
> The SDF is the same regardless, excepting of course that VHDL
> "out" ports cannot be read so one has to artificially inflate
> the design before the VHDL and Verilog netlist signals can have the
> same names. (this issue is on our list) This would be a real
> headache if you tried to read a Verilog netlist into VHDL.
>
> It is worth noting the trend is away from having setup-hold, skew,
> etc. checked in the models. These things are checked in the STA,
> where there is more information than the SDF has. For simulation,
> there is more interest in fast models. So we could have simpler
> VHDL gate models for simulation, if there was any incentive for
> the simulation people to supply them (did you ever see software
> get smaller?)
>
> --Rob
>
> Jim Lewis wrote:
>
>> Francoise,
>> I see there being two aspects to this.
>>
>> 1) Read Verilog Gate-level Netlists
>> Vital is not enjoying the wide support we wished for.
>> Vital is also slow compared to Verilog gate-level netlists.
>> If Vital died, silicon vendors would only need to support
>> one gate-level library format. EDA vendors would no longer
>> need to support Vital. Hence, this would be good for both.
>>
>> However, the current situation is not good for VHDL designers,
>> because to use a VHDL testbench with a Verilog gate-level
>> netlist will cost me two licenses, one for VHDL and one
>> for Verilog. Note for a Verilog designer it would only
>> cost one license.
>>
>> To benefit both users and vendors, it would be best if
>> Verilog gate-level netlists were included as part of the
>> langauge.
>>
>> 2) Standardized Verilog Interface
>> Standardize how to connect a Verilog design to VHDL.
>> This would take us away from a Vendor specific
>> implementation (which at the current time may or may not
>> be identical, but it would be nice if it were documented
>> somewhere in the standard).
>>
>> This of course should and will likely cost two licenses.
>>
>> Cheers,
>> Jim
>>
>> Francoise Martinolle wrote:
>>
>>> I noticed in the priority spreadsheet that a few people (Jim Lewis,
>>> Williams and Bishop)
>>> have voted for read and simulate Verilog netlists.
>>> I was wondering of one of them could provide a short description of
>>> this request.
>>>
>>> thanks
>>> Francoise
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Thu Mar 06 2003 - 19:52:37 PST