OPENCORES.ORG

Hi,

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