for loop with access to a ROM

Hi all,

I wrote a ROM with :
reg [7:0] ROM_values [0:255];
initial
$readmemh("rom.hex",ROM_values,0,255);

And access to it with a for loop like this :
reg [7:0] match [0:31];
always @(posedge clock)
if (reset)
for (i=0;i<=31;i=i+1)
match <= 8'h00;
else
for (i=0;i<=31;i=i+1)
match <= ~(data ^ ROM_values);

In ISE 8.1 synthesis I see that ROM_values is 32 ROM 256*8 bit instead
of ONE unique ROM 256*8 bits

How can I wrote this to have a unique ROM ?

Thanks

 

[Kevin Neilson]

fpgaasicdesigner@gmail.com wrote:

Hi all,

I wrote a ROM with :
reg [7:0] ROM_values [0:255];
initial
$readmemh("rom.hex",ROM_values,0,255);

And access to it with a for loop like this :
reg [7:0] match [0:31];
always @(posedge clock)
if (reset)
for (i=0;i<=31;i=i+1)
match <= 8'h00;
else
for (i=0;i<=31;i=i+1)
match <= ~(data ^ ROM_values);

In ISE 8.1 synthesis I see that ROM_values is 32 ROM 256*8 bit instead
of ONE unique ROM 256*8 bits

How can I wrote this to have a unique ROM ?

Thanks

Look what you are trying to do here: i indexes across silicon, not
time. You are trying to access the first 32 values of the ROM on every
clock cycle. Since you can only read one value out of a ROM at a time
(or two, if you properly infer dual-port BRAMs), the only way to realize
this hardware is with 32 separate ROMs.

If you don't need all 32 values of match[] updated on every single
cycle, you can replace the loop variable i with a synthesizable counter
which counts from 0 to 31 over 32 cycles. But if you need every value
of match[] to update on every cycle, you'll need a lot of silicon.
-Kevin

 

[glen herrmannsfeldt]

Kevin Neilson wrote:

(snip)

Look what you are trying to do here: i indexes across silicon, not
time. You are trying to access the first 32 values of the ROM on every
clock cycle. Since you can only read one value out of a ROM at a time
(or two, if you properly infer dual-port BRAMs), the only way to realize
this hardware is with 32 separate ROMs.
(snip)

But if you need every value
of match[] to update on every cycle, you'll need a lot of silicon.

The problem is, these days silicon is relatively cheap. It isn't
impossible to do 32 (small) ROMs in a medium to large FPGA.
Just as people are getting wasteful in producing bloated
software, they also produce bloated hardware.

One should think a little about the algorithm before doing the
hardware design. If those ROMs produce a useful result every
cycle then it is likely correct. (Consider systolic arrays.)
If only one is needed each cycle, then the design is wrong.

-- glen