[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA-dev: Re: Icarus verilog question
Just to be thorough on this topic, many commercial waveform viewers that
read standard VCD formatted files allow the capability of creating your own
expressions from the dumped values and give them names that can be added to
the waveform. Its the equivalent of putting these assignments in your HDL
but without cluttering up the HDL itself. I don't think that any open
source waveform viewers currently provide this functionality, however.
Also as a point of reference, I believe that newer versions of VCS can dump
entire memories, but only of a limited size. They get displayed in their
waveform viewer as a vector (i.e., reg [3:0] foobar[2:0] gets output as
foobar[11:0]). I'm not sure what the upper limit is, however.
I agree that Icarus Verilog could implement a special non-standard feature
to accommodate this need. Just don't expect other tools to understand that
the dumped memory elements all come from the same memory.
Regards,
Trevor Williams
----- Original Message -----
From: "John Sheahan" <jrsheahan@optushome.com.au>
To: "gEDA developer mailing list" <geda-dev@moria.seul.org>
Sent: Friday, January 19, 2007 5:23 PM
Subject: Re: gEDA-dev: Re: Icarus verilog question
> Stephen Williams wrote:
>> Andrew Lentvorski wrote:
>>> Steven Wilson wrote:
>>>> I've never seen a dump list with memories included.
>>> Okay. Well, I'd at least like to have the option. So, I'll file that
>>> as an enhancement request.
>>>
>
> my standard says (18.2.1)
> 1) The VCD format does not support a mechanism to dump part of a vector.
> For example, bits 8 to 15 (8:15) of a 16-bit
> vector cannot be dumped in VCD file; instead, the entire vector (0:15) has
> to be dumped. In addition, expressions, such
> as a + b, cannot be dumped in the VCD file.
>
> and 18,2,2
> Variables can be either scalars or vectors. Each type is dumped in its own
> format. Dumps of value changes
> to scalar variables shall not have any white space between the value and
> the identifier code.
>
> implementing this in a way compatible with existing vcd parsers could be
> tricky.
>
>
>>>> The format is really only designed to dump "vectors."
>>> But, rf[0] *is* a vector. I can understand not dumping it by default,
>>> but if I explicitly list it, I really want it.
>>
>> That's beyond the scope of the standard, but it is a reasonable
>> request and probably not very hard to implement. Do file it as an
>> enhancement request.
>>
>>> In addition, why won't rf[0] show up when I put it in a $monitor
>>> statement?
>>
>> That would be a bug. File a bug report. Bug reports that have
>> clear and simple (and complete!) sample programs get fixed
>> fastest.
>>
>>> Finally, how do I grab a slice of rf[0] aka rf[0][15:12] ? Do I have to
>>> wire *that* out and then slice the wire? I'm probably going to have to
>>> build a parameterized register file module if I want
>>> rf[someWire[2:0]][15:12]? This is nuts.
>>
>> That should work. You can take bit/part selects of array words.
>>
>>> Why do register arrays not behave like an array of registers? Is this
>>> in the standard somewhere or is everybody just following bugs in
>>> Verilog-XL?
>
> 3.10.3.1.3 Memory differences
> A memory of n 1-bit regs is different from an n-bit vector reg
>
> - because the standard says so. :(
>
>>
>> In 1995 there were no arrays. "Memories" are special things that
>> were not quite the same as arrays. V2001 tries to generalize the
>> memory into arrays, allowing for a more orthogonal treatment of
>> the concepts. But some limits still remain.
>>
>>
>
>
>
> _______________________________________________
> geda-dev mailing list
> geda-dev@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev