Subject: [sv-bc] Re: [sv-ec] $readmem proposal discussion
From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Tue Jan 06 2004 - 00:59:45 PST
Doug,
See http://www.boyd.com/1364_btf/report/full_pr/87.html
Shalom
"Warmke, Doug" wrote:
> 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
-- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
This archive was generated by hypermail 2b28 : Tue Jan 06 2004 - 01:09:17 PST