Subject: [sv-bc] More on SV $readmem
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Mon Aug 25 2003 - 12:09:43 PDT
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
> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Thursday, August 21, 2003 3:52 PM
> To: sv-ec@eda.org; sv-bc@eda.org
> Subject: RE: [sv-ec] RE: [sv-bc] Question on memory pattern
> file formats in SV
>
>
> The existing $readmem provides a lot of flexibility. The
> user can provide
> a start and end address to control where the file contents go
> into memory
> and in which of the two possible orders. Or the user can
> leave either of
> these out and get a default. How would you propose providing
> a similar
> level of flexibility for multi-dimensional arrays?
>
> For example, with existing memories, allowing upward and
> downward order
> is enough to cover the possible file orders. With multi-dimensional
> arrays, the file could be in row-major or column-major order, and each
> dimension could be ordered upward or downward. And if start
> and end is
> specified for each dimension, does that specify bounds that each index
> should stay within, or a starting and ending point for the combination
> of indices, with each index incrementing over its full range
> from there?
>
> Note that with a Verilog loop version, any of these variations can be
> written with minor changes to the code. Should $readmem provide the
> same level of flexibility, or give up and only provide a
> limited subset
> of the possibilities for multi-dimensional arrays?
>
> Steven Sharp
> sharp@cadence.com
>
This archive was generated by hypermail 2b28 : Mon Aug 25 2003 - 12:48:58 PDT