UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Adventurer
Adventurer
3,045 Views
Registered: ‎04-04-2010

BLOCK RAM configuration issue SPARTAN 3E

Hello,

 

I am using a SPARTAN 3E, 1200k gate device (XC351200E-FG320).  My application, a softcore processor, requires the use of BLOCK RAM in either of two alternative configurations

 

(a) true dual ported, 8 bit data width, 16 SRAM blocks for 32K total

 

(b) true dual ported, 32 bit data width, 16 SRAM blocks for 32K total

 

With option (a) my design meets timing with (b) it fails by a considerable margin.  The reason is explained in the timing detail section of the synthesis report for (b):

 

     RAMB16_S18_S18:CLKA->DOA7    1   2.800   0.595  U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[15].ram.r/s3_init.ram/dpram.dp18x18.ram (U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/ram_douta14<7>)
     LUT4:I0->O            1   0.704   0.000  U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/has_mux_a.A/Mmux_dout_mux_514 (U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/has_mux_a.A/Mmux_dout_mux_514)
     MUXF5:I0->O           1   0.321   0.000  U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/has_mux_a.A/Mmux_dout_mux_3_f5_6 (U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/has_mux_a.A/Mmux_dout_mux_3_f57)
     MUXF6:I1->O           1   0.521   0.420  U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/has_mux_a.A/Mmux_dout_mux_2_f6_6 (U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/douta_i<21>1)
     INV:I->O              7   0.704   0.712  U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/valid.cstr/douta_i<21>_inv1_INV_0 (douta<21>)
     end scope: 'inst_SYS_RAM'

 You can see that inserted after the RAMB_16 is a considerable amount of logic (LUT, MUX5, MUX6, INV) with consequent gate and net delays.  This does not appear to be the case with option (a).   As a test I tried option (b) with only 8 SRAM BLOCKS (16K) and in this case the extra logic does not seem to be present, and my design meets timing (in fact a different path is the critical path, so the SRAM BLOCKS do not appear in the synthesis report)

 

So it seems that to use all of 16 SRAM BLOCKS with 32 bit data width as opposed to 8 bit data width requires this extra glue logic.  Is there anything I can do to resolve this issue or is it just a limitation of this particular device and I should choose a different device if I really need the 32 bit data with configuration?

 

Any help much appreciated!

0 Kudos
2 Replies
Historian
Historian
3,032 Views
Registered: ‎02-25-2008

Re: BLOCK RAM configuration issue SPARTAN 3E


@anding wrote:

Hello,

 

I am using a SPARTAN 3E, 1200k gate device (XC351200E-FG320).  My application, a softcore processor, requires the use of BLOCK RAM in either of two alternative configurations

 

(a) true dual ported, 8 bit data width, 16 SRAM blocks for 32K total

 

(b) true dual ported, 32 bit data width, 16 SRAM blocks for 32K total

 

So it seems that to use all of 16 SRAM BLOCKS with 32 bit data width as opposed to 8 bit data width requires this extra glue logic.  Is there anything I can do to resolve this issue or is it just a limitation of this particular device and I should choose a different device if I really need the 32 bit data with configuration?


You don't tell us what tool generates this processor or the memory. You also say "32K total," so I assume that this means you want 32k BYTES. There's a difference between 32k BYTES and 32k WORDS when the words are 32-bits wide!

 

Remember in S3E, the BRAMs are 16k bits (actually 18k bits if you include the parity, but ignore that for now). They can be accessed with a variety of word widths, from 1 bit to 512 bits. Of course the narrower the word the deeper the memory, so the 1-bit wide memory is 16k bits deep and the 512-bit wide memory is 32 bits deep.

 

So the above has an impact on how you build memories. In your example a) with the 8-bit interface, my guess is that the tools built the memory out of 16 one-bit-wide memories. Remember that you can put the memories in parallel with basically no impact on anything, so if you put 8 one-bit wide memories in parallel you get an 8-bit-wide 16k deep memory. (Each BRAM then is one of the 8 bits.) But you want 32k depth, so for each bit you mux two 1-bit wide 16k deep memories and a simple selector (driven by the address MS bit) chooses which RAM gets written and which RAM gets read. You then put eight of these two-BRAM-plus-selector parts in parallel to get an 8-bit wide 32k-deep memory.

 

Now to b). You say that you want 32k bytes accessed 32 bits at a time. That's a memory that's only 1k words deep but it also requires 32 BRAMs. So right away something isn't adding up.  So assume then that it's actually trying to build a memory that's 32k words deep where each word is 32 bits wide.  Figure 16k words deep * 32 wide is 32 BRAMs, make it 32k words deep and it's now 64 BRAMs.

 

So what's not right about how you specify your memory?

----------------------------Yes, I do this for a living.
Adventurer
Adventurer
3,021 Views
Registered: ‎04-04-2010

Re: BLOCK RAM configuration issue SPARTAN 3E

bassman59,

 

Thank you for taking a look at this.  Your reply has clarified my thinking at lot and I need to take a second look at it.

 

Much appreciated,

 

Anding!

0 Kudos