cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
tillnorbert
Visitor
Visitor
8,802 Views
Registered: ‎09-16-2011

BRAM utilization using byte-wide write enable in Spartan3e

Jump to solution

Hi,

I'm going to implement a memory with byte-wide write enable. I'm targeting the Spartan 3e FPGA and depending on the utilization of BRAMs.
The xst user guide [1] provides a coding example on page 162. But for Spartan3/3e a distributed memory is implemented. If I try to synthesize it for Spartan6 it works, so the BRAM is utilized. I've tested both options: the Single Write Statement as well as the Multiple Write Statement. The code is written in VHDL and I've tried version 13.3 and 14.4.
I know that my design can be implemented on this particular FPGA, because I wrote a structural design by instantiating the ArmRAMB16_2kx8_Wrapper out of the UNISIM.VComponents library.
Is xst utilizing any techniques that are not available in Spartan3/3e? Or did I miss something? Or is there perhaps a way to get this working?

Thanks for help in advance!

 

[1]:XST User Guide for Virtex-4, Virtex-5, Spartan-3, and Newer CPLD Devices; UG627 (v 14.5) March 20, 2013

0 Kudos
1 Solution

Accepted Solutions
yashp
Moderator
Moderator
11,347 Views
Registered: ‎01-16-2013

Try with using new parser as recommende by Bassman59:

 

Go to ISE --> Synthesis properties --> other command line tool option

TYPE:  -use_new_parser yes (This is default for spartan 6)

*Note: After using this option you will recive one warning you can safly ignore that.

 

Thanks,

Yash

View solution in original post

0 Kudos
9 Replies
bassman59
Historian
Historian
8,793 Views
Registered: ‎02-25-2008

@tillnorbert wrote:

Hi,

I'm going to implement a memory with byte-wide write enable. I'm targeting the Spartan 3e FPGA and depending on the utilization of BRAMs.
The xst user guide [1] provides a coding example on page 162. But for Spartan3/3e a distributed memory is implemented.


How big is this memory?

----------------------------Yes, I do this for a living.
0 Kudos
tillnorbert
Visitor
Visitor
8,783 Views
Registered: ‎09-16-2011

Hi bassman59,

Sorry, I forgot to mention this. My design requires a size of 4096x32. But I've already tried different sizes, like 1024x32,512x32 or 512x16. But for all of them a got the same behavior.

0 Kudos
markcurry
Scholar
Scholar
8,773 Views
Registered: ‎09-16-2009

We've always struggled with infering byte-write memories.  It's easy for the tools to get lost.

 

For us, it was just easier to infer each byte lane as a seperate memory, and control the write-enable for that specific instance.  For your target (4Kx32), you're already looking at (8) 18Kbit Brams, so there's no loss in doing it this way.  Probably end up what XST would build anyway.

 

If you're using verilog, use an array of instances:

 

inferred_ram

#(

  .depth( 4096 ), 

  .width( 8 )

) ram_byte_lanes[ 3 : 0 ]

(

  blah, blah

 .single_bit_write_enable( write_enable[ 3 : 0 ] ),

blah, blah

);

 

0 Kudos
tillnorbert
Visitor
Visitor
8,757 Views
Registered: ‎09-16-2011

Hi markcurry,

Of course there are possibilities to overcome this. I've already a structural working implementation. As I mentioned above; I created this version by instantiating eight times the RAMB16_S9_S9 out of the Xilinx unisim library.

Anyway the behavior of xst in this case is strange to me. So I want to know if there is a possibility to convince xst to detect the memory correctly, or if I made a mistake. As far as I know the xst user guide is targeting Spartan 6 as well as Spartan 3. So why xst can detect a behavioral description of a RAM with bide-wide enable for Spartan 6 but not for Spartan 3? I don't see any relevant differences between these two FPGAs (for this particular case).

0 Kudos
bassman59
Historian
Historian
8,748 Views
Registered: ‎02-25-2008

@tillnorbert wrote:


Anyway the behavior of xst in this case is strange to me. So I want to know if there is a possibility to convince xst to detect the memory correctly, or if I made a mistake. As far as I know the xst user guide is targeting Spartan 6 as well as Spartan 3. So why xst can detect a behavioral description of a RAM with bide-wide enable for Spartan 6 but not for Spartan 3? I don't see any relevant differences between these two FPGAs (for this particular case).


it may be one of the features of the so-called "new parser" which (I believe) is the default for the S6 parts.

There's a switch you can set in the XST options which enables that parser for your S3 devices. When you run the synthesizer, you'll get dire warnings about how things might not work as they used to.

----------------------------Yes, I do this for a living.
0 Kudos
yashp
Moderator
Moderator
11,348 Views
Registered: ‎01-16-2013

Try with using new parser as recommende by Bassman59:

 

Go to ISE --> Synthesis properties --> other command line tool option

TYPE:  -use_new_parser yes (This is default for spartan 6)

*Note: After using this option you will recive one warning you can safly ignore that.

 

Thanks,

Yash

View solution in original post

0 Kudos
tillnorbert
Visitor
Visitor
8,710 Views
Registered: ‎09-16-2011

Thanks to Yash and bassman59

With the new parser it works definitely better (mainly regarding to the synthesis time). But the reason for this is in my opinion, that the old parser cannot detect the memory.  With the new parser xst detects a memory, but it will be implemented as distributed RAM. And xst causes that with the statement:


"The RAM <Mram_RAM> will be implemented on LUTs either because you have described an asynchronous read or because of currently unsupported block RAM features."

My implementation contains only a synchronous read-port. As mentioned before for the Spartan6 the BRAM is correctly detected. And this is still confusing to me.

0 Kudos
bassman59
Historian
Historian
8,705 Views
Registered: ‎02-25-2008

@tillnorbert wrote:

Thanks to Yash and bassman59

With the new parser it works definitely better (mainly regarding to the synthesis time). But the reason for this is in my opinion, that the old parser cannot detect the memory.  With the new parser xst detects a memory, but it will be implemented as distributed RAM. And xst causes that with the statement:


"The RAM <Mram_RAM> will be implemented on LUTs either because you have described an asynchronous read or because of currently unsupported block RAM features."

My implementation contains only a synchronous read-port. As mentioned before for the Spartan6 the BRAM is correctly detected. And this is still confusing to me.


Show the code.

The report doesn't show a clock on Port B (the read port).

 

----------------------------Yes, I do this for a living.
0 Kudos
tillnorbert
Visitor
Visitor
8,685 Views
Registered: ‎09-16-2011

Thanks to bassman59 again,

This hint solves the problem. I've described a synchronous register for the read-addr of port B, as it was proposed by xst. For Spartan6 this register is absorbed. For Spartan3 this is not working (why ever). But now I described everything in a synchronous way and it works. So now the code works for Spartan6 as well as for Spartan3(with xst option -use_new_parser yes).

Thanks to all repliers again.


0 Kudos