Can somebody explain thse XST warnings/info

[hallovipin]

Hi,

I created an SRAM of 8K*12 bits inside FPGA. When I am reading it following two info appear while synthesis.

1. Xst:3040 - The RAM <MRAM_int_ram> will be implemented as a BLOCK RAM, absorbing following register(s):

2. Xst: 3031 - HDL ADVISOR - The RAM <MRAM_int_ram_ren> will be implemented on LUTs either because you have described an asynchrous read or because of currently unsupported block RAM features.

Problem: Due to the second message my whole lookup tables have got exhausted as
ISE is trying to build RAM out of it.

I have taken all precautions to have a synchrous read : have a look on the part of my code



always @(posedge clk_adc) begin ///////////// Write RAM with ADC clock if(write_enable)
if(address_w==12'b111111111111)
begin
address_w<=12'b000000000000;
end
else begin
int_ram[address_w]<=adc_data_in;
address_w<=address_w+12'b000000000001;
end
end


always @(posedge clk) begin /////// Read RAM with main FPGA clock
if(address_r==12'b111111111110)begin
address_r<=12'b000000000000;
end
else begin
if(temp_sum>15'b00000010000000) ////////////////////////////// peak temp_sum<=15'b000000000000000;

if(int_ram[address_next]>int_ram[address_r])
neg_check=int_ram[address_next]-int_ram[address_r];
else
neg_check=0;

temp_sum<=temp_sum+neg_check;
address_r<=address_r+12'b000000000001;
address_next<=address_r+12'b000000000010;

end
end

Please ignore the completeness of the code as I have selectively found out that only this portion of the code is creating problem.

 

[permute]

are you sure you don't just want to use a fifo?

It looks like XST won't infer the RAM you want at this time. its in the XST manual -- the async read won't be inferred. You can always use coregen, or use the RAMB primitives.

 

[hallovipin]

@ Permute

Thanx

but I need to have access to different addresses at a time. in fifo only sequential access to the data is possible

Consider
address_next<=address_r+12'b000000000010;

it increments the address by 2 not 1.

and in statement
I gotta use

neg_check=int_ram[address_next]-int[address_r];

so FIFO cant be use as per me. Any suggestion.

 

[lucbra]

Hi,

Do you want to use the block ram inside of the FPGA or do you want to consume your logic?

the first warning tells you that XST tries to implement the 8kx12 RAM in a block RAM. the second warning tells you that you didn't follow the rules of the hardware block ram (async Rd or unsupported feature). If you want to use the block ram, you will need to search for the asyn read error (I can't help with this as I only know VHDL very well).

In the latter case of consuming your logic (which I don't recommend) to implement this memory block, you can ignore the warning.

Regards,

 

[falloutmx]

neg_check=int_ram[address_next]-int_ram[address_r]

i think he want to read two data in one clock,fifo or dpram can't do this.

 

[hallovipin]

@ lucbra

thanx.

yes I want to use block ram, but I am not able to locate the asynchronous read error.
I am using registers only for address updating and updating them evry clock cycle, which makes it a synchronous read. Some part of the program has already been converted to block ram by ISE but some part is still being implemented on logic. Is there any way by which you can know in ISE that which section of ur code is causing a particular info.

any reply will be appreciated.



@Falloutmx

yes I want to read not only 2 but more than 2 data in a single clock. ISE is implementing dpram only but not for total code. why??

 

[permute]

@fallout:
you can still create something to give N reads with 1 write. It just means using N block rams with the same write, and each with a different read. Perhaps ISE is using this implementation.

@hallo:
Unless you've grossly simplified the code, just use a fifo. it looks like on each cycle you are reading elements k, and k+1. eg, [0,1] [1,2] [2,3] [3,4]. In which case you could most likely rewrite this to read one element per cycle, and register that value for use in the next cycle.

It seems that the alternatives are to instantiate a few BRAMs manually, or to synchronize the ADC data to the correct clock domain first.