Re: [oc] Memory model consolidation (Behavioral?)

["Sam Gladstone" <samg@t-and-t.com>]

Ok, I looked the the tpram.
I am assuming that you want the behavioral checks to go
in the that last section. I think I can work to add them into both
the tpram and dpram.

We can also create a register file memory model as well.
(I use a model that stitches two dprams together to build a reg file
in the SXP.  It also has the option of using a FF based reg file as well.)

I guess my next question is, should these models be moved into
the common section? I don't think the tpram is there.
I will update the SXP to use these models if we can keep them up to date.
Here is an idea, can Miha do some type of link to the main common area
memories?
That way all repository checkouts will download the same version from the
same
place.  tar file downloads would also pull a copy of the link. I think you
can
do a link that make a whole copy when it copied to another source.

Anyway, I will look into making changes to the tpram to do the extra
checks and we can put it in the "common" misc section. I can then try
and make the SXP use that memory model.

Regards,
 Sam


----- Original Message -----
From: "Damjan Lampret" <lampret@opencores.org>
To: <cores@opencores.org>
Sent: Tuesday, November 06, 2001 8:45 AM
Subject: Re: [oc] Memory model consolidation (Behavioral?)


> Hi Sam,
>
> I think there should be _at least_ three generic memories. Single port
sync
> RAM, dual-port (under dual port I underatand one R and one W port - same
as
> Artisan, while Virtual Silicon means 2x R/W) and two-port (two separate
R/W
> ports). This is what I use in OR1200:
>
> single-port:
>
http://www.opencores.org/cgi-bin/cvsget.cgi/or1k/or1200/rtl/generic_spram_51
> 2x20.v
> dual-port:
>
http://www.opencores.org/cgi-bin/cvsget.cgi/or1k/or1200/rtl/generic_dpram_32
> x32.v
> two-port:
>
http://www.opencores.org/cgi-bin/cvsget.cgi/or1k/or1200/rtl/generic_tpram_32
> x32.v
>
> My initial idea was to have completely parametrizable models (w/o _32x32)
> but I found out that most vendors although put parameters in their verilog
> models, are in fact not parametrizable (you need to generate new model for
> every configuration and not just change parameters in the verilog model -
> although one vendor had such model). I'd like to see that our models are
> compatible with Artisan, Virtual Silicon, Avant!, Virage and also with
FPGA
> memories. I have access to all mentioned ASIC memories and I can verify
that
> our model would be compliant.
>
> regards,
> Damjan
>
> ----- Original Message -----
> From: "Sam Gladstone" <samg@t-and-t.com>
> To: <cores@opencores.org>
> Sent: Tuesday, November 06, 2001 5:31 PM
> Subject: Re: [oc] Memory model consolidation (Behavioral?)
>
>
> > I think this might need another file, I explain why below.
> > Another issue is definition of some of the pins.
> >
> > It is common in the latest Virage memories to read and write to both
port
> A
> > and B with
> > minor restrictions.  I noticed in the dpram.v that the code assumes one
> port
> > for read and
> > one for write.
> > I also noticed that the Virage memory instantiation is adjusted to make
> one
> > port read and
> > one port write.  (Although it is not restricted to this operation.)
> > This happens for Xilinx, Artisan and Virage memories but not with
Altera.
> >
> > How do we deal with this discrepancy for the interface to a generic
> memory?
> >
> > The Xilinx, Virage and Artisan memories could use a full dual port
> > behavioral model
> > but it would have to be a separate file because of the read/write
> > functionality on both
> > ports.
> >
> > Ok, any comments?
> >
> > Regards,
> >   Sam Gladstone
> >
> >
> > ----- Original Message -----
> > From: "Richard Herveille" <richard@asics.ws>
> > To: <cores@opencores.org>
> > Sent: Monday, November 05, 2001 7:56 PM
> > Subject: Re: [oc] Memory model consolidation (Behavioral?)
> >
> >
> > > I agree, but we should agree on certain points before a developer
starts
> > > changing somebody else's code. I think there are a number of solid
> points
> > > listed below which improve the generic-behavioral model. But I think
you
> > > should contact the initial developer first and make your wishes known.
> > >
> > > Richard
> > >
> > >
> > > >Hi Folks,
> > > >
> > > >I'd just like to make general comment. Things in CVS module common
> > (another
> > > >alias is misc) are contributed by different developers and it is
> desired
> > > >that if you have an idea how to improve them, just go and do it. So
if
> > you
> > > >need something that doesn't reduce and change current functionality,
go
> > and
> > > >what you need.
> > > >
> > > >regards,
> > > >Damjan
> > > >
> > > >----- Original Message -----
> > > >From: "Sam Gladstone" <samg@t-and-t.com>
> > > >To: <cores@opencores.org>
> > > >Sent: Sunday, November 04, 2001 8:02 PM
> > > >Subject: [oc] Memory model consolidation (Behavioral?)
> > > >
> > > >
> > > > > Hey, I just downloaded the common cores stuff that was mentioned
in
> > the
> > > >new
> > > > > stuff.
> > > > >
> > > > > I looked at the dual port memory and have some questions.
> > > > >
> > > > > Where is the Verilog behavioral model for dual port memories?
> > > > > I noticed that some of the memories just do a Verilog memory
command
> > > > > without any checks.  Take a look at the DPMEM in SXP for checks
that
> I
> > do
> > > > > from working with dual port memories. (I am used to Virage
> memories.)
> > > > > I have a couple of rules put into place like:
> > > > > 1. You cannot read from the same address that you are writing to.
> > > > >   This is a big one that I think this trap is most common. (I know
I
> > have
> > > > > accidentally fallen into it.) A lot of behavioral memory models
> check
> > this
> > > > > and
> > > > > generally return an "x" if you violate it. I generally use a
> waveform
> > > > > generator and
> > > > > look for "x"s related to the memory and see if this is the cause.
> You
> > can
> > > > > also
> > > > > generate an event or do a display in addition so that the
simulation
> > warns
> > > > > the user
> > > > > of the problem.
> > > > >
> > > > > 2. Exceeded the full size of the memory. A lot of memories are not
> the
> > > >total
> > > > > length defined
> > > > > by their address bit width. I have seen plenty of times a 12 bit
> > memory
> > > >with
> > > > > 3/4 that size
> > > > > generated in the memory. It is important that the true intended
size
> > of
> > > >the
> > > > > memory is checked and "X" returned if violated.
> > > > >
> > > > > 3. Generate "Z" on tristated modes. (Output enable low and chip
> enable
> > > >low)
> > > > >
> > > > > 4. Generate "X" on unwritten memory. (Helps with the debug)
> > > > >
> > > > > I also generate a 3ns on a 5ns clock delay on the output in order
to
> > give
> > > >a
> > > > > good approximation for the memory output delay.
> > > > >
> > > > > I think a really tight behavioral memory model is one of the best
> > > >debugging
> > > > > tools for memory inteface that one can have. It sure helps knock
out
> > hours
> > > > > of problems later when the part is created.
> > > > > I know that you cannot model everything like minute timing because
> > that
> > > > > would make your
> > > > > synthesizable verilog turn into a behavioral model itself but
> logical
> > > >errors
> > > > > can be removed.
> > > > >
> > > > > I am looking to replace the memory models in the SXP with common
> ones
> > but
> > > >I
> > > > > need to make
> > > > > sure that the common behavioral models checks for correct
operation
> as
> > > >well.
> > > > >
> > > > > Regards,
> > > > >   Sam
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe from cores mailing list please visit
> > > >http://www.opencores.org/mailinglists.shtml
> > > > >
> > > >
> > > >--
> > > >To unsubscribe from cores mailing list please visit
> > > >http://www.opencores.org/mailinglists.shtml
> > >
> > > --
> > > To unsubscribe from cores mailing list please visit
> > http://www.opencores.org/mailinglists.shtml
> > >
> > >
> >
> >
> > --
> > To unsubscribe from cores mailing list please visit
> http://www.opencores.org/mailinglists.shtml
> >
>
> --
> To unsubscribe from cores mailing list please visit
http://www.opencores.org/mailinglists.shtml
>
>


--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml