HLL VHDL & VCD

[Mayan Moudgill]

As a language, VHDL has some interesting, high-level language
properties. However, you can't really use them. Specifically:
- there are tools that need VCDs (e.g. some power estimation tools)
- VCDs weren't specified with HLL features in mind
- so simulators can't/don't generate VCDs while simulating VHDL with
high-level features.

Two examples that come to mind are RECORDs and BLOCKs. Since the VCD
spec does specify how to name a field in a record, most VCD generators
just don't generate any values for record typed SIGNALs

BLOCKs are a slightly different story. I don't quite understand why
SIGNALs declared inside a BLOCK can't have a VCD generated for them, but
they don't. In particular, the work-around for it:
foo: IF true GENERATE
SIGNAL x : type;
BEGIN
...
END GENERATE foo;
produces VCDs generate signal fine.

Is there a new rev of the VCD standard planned? Or even a de-facto
standard from Cadence/Synopsys/MTI that deals with these issues?

 

[Dwayne Dilbeck]

Niether the VCD or newer eVCD standard address these issues. Cadence's SST2
format will handle the records and bocks data correctly, but for power
analysis Cadence will direct you to use thier own dynamic power analysis
tools which can take VCD, eVCD, and SST2. From the Cadence's side I can't
see any reason to push for further VCD extensions, they already have a
solution.

"Mayan Moudgill" <mayan@bestweb.net> wrote in message
news:13mkuoicg35eec8@corp.supernews.com...

As a language, VHDL has some interesting, high-level language properties.
However, you can't really use them. Specifically:
- there are tools that need VCDs (e.g. some power estimation tools)
- VCDs weren't specified with HLL features in mind
- so simulators can't/don't generate VCDs while simulating VHDL with
high-level features.

Two examples that come to mind are RECORDs and BLOCKs. Since the VCD spec
does specify how to name a field in a record, most VCD generators just
don't generate any values for record typed SIGNALs

BLOCKs are a slightly different story. I don't quite understand why
SIGNALs declared inside a BLOCK can't have a VCD generated for them, but
they don't. In particular, the work-around for it:
foo: IF true GENERATE
SIGNAL x : type;
BEGIN
...
END GENERATE foo;
produces VCDs generate signal fine.

Is there a new rev of the VCD standard planned? Or even a de-facto
standard from Cadence/Synopsys/MTI that deals with these issues?

 

[Mayan Moudgill]

Dwayne Dilbeck wrote:

Niether the VCD or newer eVCD standard address these issues. Cadence's SST2
format will handle the records and bocks data correctly, but for power
analysis Cadence will direct you to use thier own dynamic power analysis
tools which can take VCD, eVCD, and SST2. From the Cadence's side I can't
see any reason to push for further VCD extensions, they already have a
solution.

The following seem to be true:
1. VHDL may (or may not) be a better language than Verilog
2. its inadequately supported by tools
* for any "interesting" feature of the language, you will find a
tool that fails to parse it. Examples I've bumped into:
+ untyped ALIAS
+ types in GENERATEs
+ binding a slice of std_logic_vector as an argument to an
entity input of type std_logic_vector
* The tools don't play nice together; at least one synthesis tool
generates very long names for ENTITYs with multiple GENERIC arguments,
long enough that other tools barf on the name
* The VCD issue.

My suspicion is that unless some of the second set of issues are fixed,
its irrelevant how much better VHLD is than Verilog; its going to get
marginalized.

 

[Dwayne Dilbeck]

The following seem to be true:
1. VHDL may (or may not) be a better language than Verilog
The more extensions that are added to verilog the closer the two draw

together on feature sets. Since I am comfortable with both languages, I go
with the one that takes least amount of typing to do something.

2. its inadequately supported by tools
* for any "interesting" feature of the language, you will find a tool
that fails to parse it. Examples I've bumped into:
+ untyped ALIAS
+ types in GENERATEs
+ binding a slice of std_logic_vector as an argument to an entity
input of type std_logic_vector
* The tools don't play nice together; at least one synthesis tool
generates very long names for ENTITYs with multiple GENERIC arguments,
long enough that other tools barf on the name
* The VCD issue.

Hehehe, I have seen in my testing the name barf issues for generics. At the
time our tool had the same problem for both vhdl generics and verilog
parameters. The synthesis engine would append the generic value to the end
of the name. Eventually the name would break the linux file name length
limit. We had to redesign how the synthesis engine created names to solve
this issue. At the time I couldn't believe the problem had never been
thought about til it was tried.

 

[Colin Paul Gloster]

On Thu, 20 Dec 2007, Dwayne Dilbeck wrote:

|-----------------------------------------------------------------------------|
|"[..] |
|> * The tools don't play nice together; at least one synthesis tool |
|> generates very long names for ENTITYs with multiple GENERIC arguments, |
|> long enough that other tools barf on the name |
|[..] |
| |
|Hehehe, I have seen in my testing the name barf issues for generics. At the |
|time our tool had the same problem for both vhdl generics and verilog |
|parameters. The synthesis engine would append the generic value to the end |
|of the name. Eventually the name would break the linux file name length |
|limit. [..]" |
|-----------------------------------------------------------------------------|

I am not content with the short paths forced by filesystems which
supposedly support long filenames. However, I am impressed with this
story of filesystem failure (not that dissatisfaction with a Linux
filesystem policy is unique).