Subject: [sv-bc] $readmem proposal discussion
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Sep 11 2003 - 23:28:53 PDT
Hi SV-BC,
Haven't heard from anyone in a while on our $readmem
enhancement proposal. This is proposal 67 on the SV-BC
site, due for discussion at Monday's meeting:
http://www.eda.org/sv-bc/display_issue.cgi?issue_num=67
I am resending the current (informal) proposal to prepare us
for discussion on Monday. Note that it doesn't have anything
on $fread, but that is a good idea proposed by Shalom and
one other person, so we can add something to that effect
as well. Anyone know of any other related system tasks
in need of adjustment?
If the group likes our proposal well enough, we can
type it up in the Frame LRM templates provided by
David Smith. We will most likely recommed that
the changes be made in Section 22 of the LRM.
One issue has come up since we originally created
our proposal. Namely, 1364-2001 says that for
data files that don't contain addresses, the memory
is loaded in the order of its declaration range.
So memory dimensions declared [high:low] should have
the first words in the file go into the highest addresses,
and on down to the lower addresses as the file words go up.
Opposite for [low:high].
However, to my knowledge, not a single Verilog simulator
actually works this way. They all load the first words
in the file into the lowest memory addresses, and continue
upwards. This occurs regardless of the low:high/high:low
range given in the dimension's declaration. Should we change
the LRM to conform with this de facto behavior? This would
be a good opportunity to do so, although it might be argued
that we should leave this to the IEEE. Well, maybe we could
just do it here, or make a note of it in our LRM, and leave
it to them to sort out later.
Thanks and regards,
Doug
Original proposal follows.
Steve, others,
Thanks for the good feedback on $readmem.
Our feeling is that extending $readmem to handle multi-D memories
and int/enum memories would be a valuable convenience to users.
We also think that adding equivalent $writemem would have value.
Here is the outline of a proposal. If everyone likes it enough,
I can write it up in LRM format and submit it to SV-BC.
1. Handle 2-state types (int/enum/etc.) as suggested by Peter,
using reg[31:0] for int and appropriate size reg for enum.
As described in LRM section 3.10, all enum types are of
integer_type that decompose into old-fashioned reg vectors.
2. Disallow class, struct, handle, dynamic array, non_integer types.
(I guess this could be achieved by simply allowing integer_type,
as is done for enums in section 3.10).
3. For the $readmem systask itself, keep the same signature:
$readmemb("file_name", memory_name[, start_addr[, finish_addr]]);
$readmemh("file_name", memory_name[, start_addr[, finish_addr]]);
The following caveats would apply:
3.1 memory_name can be a slice of a multi-D memory that resolves
in some lesser-D memory, down to 2-D. The slice dimensions
must be specified with an index, rather than complete or
partial dimension range. This is the same as the restrictions
when assigning an array element described in 1364-2001, 3.10.
Consider the following 4-D memory declaration:
reg [0:31] mem [15:0][99:0][0:1023]
Thus the following are legal inputs to $readmem:
mem[0][99]
mem[1]
mem
The following are illegal:
mem[3:2]
mem[5][99:8]
mem[15:0][3]
3.2 The file contents are organized in row-major order,
with each dimension's entries moving from low to high.
That means that lesser dimensions spin more quickly
than greater dimensions. This yields a hierarchical
sense to the file data. The outer-most dimension
contains "chunks" of inner-dimension data, sorted in
row-major order. Each successive inward dimension
is part of an outer dimension's "chunk".
[ A diagram could be drawn for the LRM-format submission ]
As per address entries in the file, the address field
would be limited to addressing the outermost dimension's
entries. Thus, for complex memories, there could be long
sets of data words associated with each address. We could
select one of several techniques for dealing with this in
the file format:
a) Allow repeated addresses in the address column
b) Allow the data lines to wrap around onto the next
lines, with no continuation character (e.g. \)
c) Allow data line wrap with \ continuation
3.3 The start_addr and finish_addr arguments apply to the
addresses of the memory slice selected by memory_name.
This slice represents the outer-most dimension of
data in the memory_file.
The direction of the outermost dimensions file entries
is given by the relative magnitudes of start_addr and
finish_addr, as is the case in 1364-2001.
4. Create a $writemem system task, similar to $readmem.
$writememb("file_name", memory_name[, start_addr[, finish_addr]]);
$writememh("file_name", memory_name[, start_addr[, finish_addr]]);
This would generate a LRM-compliant file that any $readmem could read.
Address column would be optional, up to the simulator vendor.
Best regards,
Doug
This archive was generated by hypermail 2b28 : Thu Sep 11 2003 - 23:32:33 PDT