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

[Richard Herveille <richard@asics.ws>]

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