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

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

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