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

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

Ok, well then if there are no current substitutes for a dual port Verilog
behavioral memory
model then I propose the dpmem.v from the sxp.
The path is "/sxp/dpmem/src/dpmem.v"
This model is intended for use while developing verilog that interacts with
a dual port
memories.  It is not subcycle timing accurate but you don't want this when
developing
verilog for it. The subcycle timing model can be used for gate level
simulation after synthesis.
I will adjust a few things and submit it to the common/misc section very
soon if there are
no objections or further issues from the core group.

Regards,
  Sam Gladstone

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


> 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