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

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

Ok, the code is changed and ready for import into the misc project tree.
I have a question though. What is the best way to preserve the information
(entries, log)
about the file.
I think we should have Miha copy the tpram verilog file from the Open Risc
tree
into a file named "generic_tpram.v" in the  /misc tree.  I have done this
before and it
is pretty safe.
I can "update" to get the new file in the misc tree, merge the changes in
and commit it back
with the next version and comments.

This would preserve all of the data and keep the entries going.

Take a look at the code as well, my verification philisophy is generate x's
and z's for
any case that should not explicitly have valid data. This way there will
never be a case
of invalid data being mistakenly used which would fail in the real world
chip.

Regards,
  Sam

----- Original Message -----
From: "Damjan Lampret" <lampret@opencores.org>
To: <cores@opencores.org>
Sent: Tuesday, November 06, 2001 2:08 PM
Subject: Re: [oc] Memory model consolidation (Behavioral?)


>
> ----- Original Message -----
> From: "Sam Gladstone" <samg@t-and-t.com>
> To: <cores@opencores.org>
> Sent: Tuesday, November 06, 2001 11:00 PM
> Subject: Re: [oc] Memory model consolidation (Behavioral?)
>
>
> > Ok, I looked the the tpram.
> > I am assuming that you want the behavioral checks to go
> > in the that last section. I think I can work to add them into both
>
> Last section, exactly.
>
> > the tpram and dpram.
> >
> > We can also create a register file memory model as well.
> > (I use a model that stitches two dprams together to build a reg file
> > in the SXP.  It also has the option of using a FF based reg file as
well.)
>
> I think the important is to have models for vendor rams. If certain uses
of
> RAMs are required in several designs, then we can also put register and
> other common uses together in common. But I think it will be hard enough
to
> maintain vendor models so I would put register file for now.
>
> >
> > I guess my next question is, should these models be moved into
>
> Idea is in the reuse. So yes, but we need to work also on infrastructure
> that will allow sharing of common blocks...
>
> > the common section? I don't think the tpram is there.
>
> Feel free to put it there.
>
> > I will update the SXP to use these models if we can keep them up to
date.
> > Here is an idea, can Miha do some type of link to the main common area
> > memories?
> > That way all repository checkouts will download the same version from
the
> > same
> > place.  tar file downloads would also pull a copy of the link. I think
you
> > can
> > do a link that make a whole copy when it copied to another source.
>
> Exactly and this is already on Miha's TODO list. Basically you will be
able
> to set up symbolic links in the CVS repository. This way if you update
> "your" local version or in common directory, the same file will be
updated.
>
> >
> > Anyway, I will look into making changes to the tpram to do the extra
> > checks and we can put it in the "common" misc section. I can then try
> > and make the SXP use that memory model.
>
> Great!
>
> regards,
> Damjan
>
>
> --
> 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