[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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