Subject: [sv-bc] Re: [sv-ec] $readmem proposal discussion
From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Tue Jan 06 2004 - 01:01:46 PST
Sorry, I got mixed up and accidentally responded to an old mail.
Please ignore.
Shalom
Shalom Bresticker wrote:
> 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
-- 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:03:46 PST