Subject: RE: [vhdl-200x] Re: TBV2: Associative arrays proposal submitted
From: Jim Goeke (james.goeke@kodak.com)
Date: Mon Apr 28 2003 - 08:43:30 PDT
Steve
See my comments below.
Regards,
James Goeke
>
> The address bus is typically modeled as a bit vector and not as an integer
> value. The conversion must be performed. What is the value of requiring
> the user to write to_integer()? It doesn't take care of the X in the
> address vector problem. That problem still exists.
>
> We should provide support for vectors as the index because this is how
> people model. It makes it easier and quicker to write the models. We
It may be how people have historically written models but should we continue to
bank on that? In the past there were many tool constraints that prevented using
anything but vectors, that is no longer the case. We have written complete
(synthesizable) designs using integer based types for for everything except the
usual cast of control bits where it doesn't make much sense. With properly
ranged integer subtypes the tools now do the "right" thing.
What we usually do is convert to/from vectors at the top level. This allows us
to have the same I/F pre and post systhesis but still run all our RTL with
integer operations (the TB is also integer, we just do conversions on both sides
of the I/F). MTI even has performance app notes that talk about converting
vectors to integer types even for single operations. They claim the conversion
overhead is so much lower than vector operations that the user can do the
conversion, the operation, the re-conversion and still come out ahead.
I agree that there is still a X problem but I think we should try to make any
new features as efficient as possible. Integer based simulation has always been
a hands down winner in any tests we have done.
I'd like to hear what others think.
> should have an identified behavior for the X situation this is logical and
> reasonable (from a modeling/hardware behavior perspective).
>
> -Steve Bailey
>
> > Why address in bit/std_logic? To address in integer
> > all that is required is a call to to_integer?
> > So the to_integer would be built into the call.
> > What happens when address = "X" for write and
> > for read? Write invalidate all entries?
> > Read, readback an "X"?
> >
> > Jim
> >
> > Stephen Bailey wrote:
> > >>Is an associative array the same as the sparse array (TBV12)?
> > >>I think a sparse array was intended for creating space
> > >>on demand for modeling something like a RAM. Sounds
> > >>like associative array is the same thing.
> > >
> > >
> > > Associative arrays could be used to model sparse arrays.
> > However, sparse arrays are more specific. They are used
> > specifically for
> > > modeling large memories efficiently when only a small
> > percentage of the memory addresses are used in any given simulation.
> > >
> > > To easily model sparse memories, associative arrays would
> > need to support:
> > >
> > > 1. A bit (std_logic) vector as an index expression.
> > (The memory address.)
> > > 2. Support constraining the index according to the memory size.
> > >
> > > I had requested that the proposal ensure that both of these
> > be covered (permitted).
> > >
> > > There may also be efficiency of implementation
> > considerations that might determine that sparse arrays should
> > either have their own
> > > syntax or that a standard "generic" associative array
> > subtype be defined to be used for sparse array/memory
> > modeling. Either of
> > > these would then be what implementations key on to kick in
> > any relevant optimizations.
> > >
> > > BTW, it would also be good to define load and dump
> > operations for associative/sparse arrays.
> > >
> > > -Steve Bailey
> > >
> > >
> > >
> >
> >
This archive was generated by hypermail 2b28 : Mon Apr 28 2003 - 09:00:02 PDT