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
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
