|
Message
From: Damjan Lampret<lampret@o...>
Date: Wed May 5 17:22:20 CEST 2004
Subject: [openrisc] QMEM Generic single-port synchronous RAM model
Mikeyou 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@opencores.org > [mailto:openrisc-bounces@opencores.org]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@jennic.com> > To: <openrisc@opencores.org> > 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
>
|
 |