Message

Reply | Reply all

Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

From: Damjan Lampret<lampret@o...>
Date: Wed May 5 18:55:42 CEST 2004
Subject: [openrisc] QMEM Generic single-port synchronous RAM model
Mike

if you go to http://www.opencores.org/login.cgi/login and if you can log in,
then you have a username. If you can't login, then you either need to get
your password (type your email address and if you have username it will send
the details to your email), or apply for a new opencores account (click Get
account).

regards,
Damjan

----- Original Message -----
From: "Michael Scott" <mike.scott@jennic.com>
To: "'List about OpenRISC project'" <openrisc@opencores.org>
Sent: Wednesday, May 05, 2004 6:06 PM
Subject: RE: [openrisc] QMEM Generic single-port synchronous RAM model


> Hi,
> I thought it was the same as my e-mail
> -obviously not ;o)
>
> I don't seem to have any records relating to a username
> would it have been produced when I first subscribed to OpenRisc
> (approx 18 month ago)
>
> Mike
>
>
> -----Original Message-----
> From: openrisc-bounces@opencores.org
> [mailto:openrisc-bounces@opencores.org]On Behalf Of Damjan Lampret
> Sent: 05 May 2004 17:04
> To: List about OpenRISC project
> Subject: Re: [openrisc] QMEM Generic single-port synchronous RAM model
>
>
> Mike
>
> what is your opencores username?
>
> regards,
> Damjan
>
> ----- Original Message -----
> From: "Michael Scott" <mike.scott@jennic.com>
> To: "'List about OpenRISC project'" <openrisc@opencores.org>
> Sent: Wednesday, May 05, 2004 5:53 PM
> Subject: RE: [openrisc] QMEM Generic single-port synchronous RAM model
>
>
> > Hi Damjan,
> > Just tried a checkout with opts as suggested
> > (ie :pserver:mike.scott@cvs.opencores.org:/cvsroot/mike.scott)
> > but to no avail -has the maintainers list been updated ?
> >
> > Regards,
> >
> > Mike
> >
> > -----Original Message-----
> > From: openrisc-bounces@opencores.org
> > [mailto:openrisc-bounces@opencores.org]On Behalf Of Damjan Lampret
> > Sent: 05 May 2004 16:22
> > To: List about OpenRISC project
> > Subject: Re: [openrisc] QMEM Generic single-port synchronous RAM model
> >
> >
> > Mike
> >
> > you you have to check out your sources with CVSROOT
> >
> > :pserver:<username>@cvs.opencores.org:/cvsroot/<username>
> >
> > Then you can modify the source and automatically commit back to the cvs.
> >
> > The #1 are because of simulator problems.
> >
> > regards,
> > Damjan
> >
> > ----- Original Message -----
> > From: "Michael Scott" <mike.scott@jennic.com>
> > To: "'List about OpenRISC project'" <openrisc@opencores.org>
> > Sent: Wednesday, May 05, 2004 4:11 PM
> > Subject: RE: [openrisc] QMEM Generic single-port synchronous RAM model
> >
> >
> > > Hi Damjan,
> > > I'm a bit unsure on how to do the update
> > > I used the CVSget to grab rel_27 but so I assume I checked out
> > > as :pserver:anonymous@cvs.opencores.org:/cvsroot/anonymous
> > > do I need to checkout as
mike.scott@cvs.opencores.org:/cvsroot/anonymous
> > > update the code and commit
> > >
> > > Is a password required ?
> > >
> > > Would you prefer the new code to retain the #1's after the
non-blocking
> > > assigments. I've noticed these in other code such as xilinx
> > > simprims; are they to get round some simulator problems (race
> conditions) > > ? > > > > > > It is my understanding that provided the simulator is > > > compliant with the LRM and blocking assignment used for combinatorial & > > > non-blocking for sequential then #1's shouldn't be needed in > synthesisable > > > RTL > > > Out of interest, is there a specific reason for the #1's ? > > > > > > I will be using the Xilinx memories eventually. The problem only arose > > > while playing around with the generic qmem variant in modelsim > > > > > > Regards > > > > > > Mike > > > > > > > > > > > > > > > -----Original Message----- > > > From: openrisc-bounces@o... > > > [mailto:openrisc-bounces@o...]On Behalf Of Damjan Lampret > > > Sent: 05 May 2004 12:28 > > > To: List about OpenRISC project > > > Subject: Re: [openrisc] QMEM Generic single-port synchronous RAM model > > > > > > > > > Mike > > > > > > yes you are correct. > > > > > > The good thing is that generic memories for DC/IC are only used for > > > simulation, not for implementation (or your implementation would have > > > thousands of flops instead of actual RAM macros as it is the right way). > I > > > have built-in generic memories for those folks that want to have a quick > > > start and don't have the libraries set-up yet... > > > > > > Mike can you go and commit the change directly to the cvs? (you need to > be > > > designated as or1k maintaner and if you are not laready I will add your > > > username to the maintaners group) > > > > > > regards, > > > Damjan > > > > > > ----- Original Message ----- > > > From: "Michael Scott" <mike.scott@j...> > > > To: <openrisc@o...> > > > Sent: Wednesday, May 05, 2004 12:40 PM > > > Subject: [openrisc] QMEM Generic single-port synchronous RAM model > > > > > > > > > > Hi, > > > > Is there a bug in the Generic single-port synchronous RAM model for > > qmem > > > > (file : or1200_spram_2048x32_bw.v) ? > > > > > > > > Looking at code below, I can't see how the cpu can write more than 1 > > byte > > > at > > > > a time > > > > 32/16 bit writes only update mem_0 due to the inferred priority > encoder > > > > > > > > > > > > always @(posedge clk) > > > > if (ce && !we) begin > > > > do_reg[7:0] <= #1 mem_0[addr]; > > > > do_reg[15:8] <= #1 mem_1[addr]; > > > > do_reg[23:16] <= #1 mem_2[addr]; > > > > do_reg[31:24] <= #1 mem_3[addr]; > > > > end > > > > else if (ce && we[0]) > > > > mem_0[addr] <= #1 di[7:0]; > > > > else if (ce && we[1]) > > > > mem_1[addr] <= #1 di[15:8]; > > > > else if (ce && we[2]) > > > > mem_2[addr] <= #1 di[23:16]; > > > > else if (ce && we[3]) > > > > mem_3[addr] <= #1 di[31:24]; > > > > > > > > should the code be structured as: > > > > > > > > always @(posedge clk) > > > > if (ce && ~|we) begin > > > > do_reg[7:0] <= mem_0[addr]; > > > > do_reg[15:8] <= mem_1[addr]; > > > > do_reg[23:16] <= mem_2[addr]; > > > > do_reg[31:24] <= mem_3[addr]; > > > > end > > > > else > > > > begin > > > > if (ce && we[0]) mem_0[addr] <= di[7:0]; > > > > if (ce && we[1]) mem_1[addr] <= di[15:8]; > > > > if (ce && we[2]) mem_2[addr] <= di[23:16]; > > > > if (ce && we[3]) mem_3[addr] <= di[31:24]; > > > > end > > > > > > > > Regards, > > > > > > > > Mike Scott > > > > > > > > ___________________________________________________ > > > > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK > > > > www.jennic.com Tel: +44 (0) 114 2812655 Confidential > > > > ___________________________________________________ > > > > > > > > > > > > _______________________________________________ > > > > http://www.opencores.org/mailman/listinfo/openrisc > > > > > > > > > > > > > _______________________________________________ > > > http://www.opencores.org/mailman/listinfo/openrisc > > > > > > _______________________________________________ > > > http://www.opencores.org/mailman/listinfo/openrisc > > > > > > > > > _______________________________________________ > > http://www.opencores.org/mailman/listinfo/openrisc > > > > _______________________________________________ > > http://www.opencores.org/mailman/listinfo/openrisc > > > > > _______________________________________________ > http://www.opencores.org/mailman/listinfo/openrisc > > _______________________________________________ > http://www.opencores.org/mailman/listinfo/openrisc