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

["Damjan Lampret" <lampret@opencores.org>]

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