Can I use all 18bits of a BlockRAM?

When I use FPGAs of Xilinx, the BlockRAM is 1K * 18bit, but the data width I can actually use is only 16bit. The other 2 bits is for read/write check. Then can I use all 18bits of a BlockRAM as the data width(no read/write check)?

Thank you, all.

Reply to
StanleyLee
Loading thread data ...

Hi Stanley, As you say there are two extra bits, nominally refered to as 'parity check bits' or somesuch, but you have to implement any parity check yourself. So, you can use these bits in the BRAM as regular data bits, no problem, as long as you're in 1k * 18 or even 2k * 9 modes. Cheers, Syms.

Reply to
Symon

Symon =E5=86=99=E9=81=93=EF=BC=9A

o,

ong

Thank you, Symon. Then when I use the blockRAM as 1k * 16 mode, the parity is checked automatically, is it right? And will it spend FPGA resource to do that?

Thank you once again.

Reply to
Stanley Lee

No. When you use 1k *16 mode, all you have is 1K*2 bits unused. To have parity checking, you must wite the parity checker and generator

Best regards,

Zara

Reply to
Zara

eck

So,

long

The last time I used *9 / *18 / *36 mode block rams, I instantiated them as such and they exposed themselves as those *8 + the parity bit. Look for the instantiation template and you'll see what I mean.

Just assign your ninth bit (for each block ram) to the parity bit.

Cheers

PeteS

Reply to
PeterSmith1954

The primitives have the bits separated off as parity bits, but other than the addressing considerations if you have different depths on the dual ports, they are no different than the data bits. It may be easier to deal with if you make a wrapper for the Xilinx primitives that bring in/out an 18 bit bus.

Reply to
Ray Andraka

Or just infer the block ram from an 9/18/36 bit wide array...

Then you can store anything you like in the ram (std_logic, std_logic_vector, unsigned, integer, boolean, enumerated types (states!), records, etc.

Check your synthesis manual for templates for inferring block ram from arrays.

Andy

Ray Andraka wrote:

Reply to
Andy

Hi Andy, Back when I was young and idealistic, (well actually about 4 years ago!) I used to try and infer these things in my code. Trouble was, the Synplify tool wouldn't infer 18KiB RAMs. Has that changed now? Thanks, Syms.

Reply to
Symon

I've had no problem with Synplify inference for the last few years. The memories easily imply up to 9 bits, up to 18 bits, or up to 36 bits in a single BlockRAM.

I still instantiate memories often in order to apply parameters such as READ_FIRST at the source level or to control more subtle aspects of dual-port memories.

Reply to
John_H

The last time I tried, XST (ISE 7.1) did only infer *8/*16/*32-bit RAMs and did not use the "parity" bits. Xilinx answered that this is a known bug/limitation, don't know if it is fixed now. So I ended up in writting a wrapper for BRAM-instantion...

Thomas

formatting link

"Andy" schrieb im Newsbeitrag news: snipped-for-privacy@a14g2000cwb.googlegroups.com...

Reply to
Thomas Entner

Thanks John, that's useful to know! Syms.

Reply to
Symon

Thomas and all,

Actually, XST did introduce inference capabilities for parity bits in version 7.1i, but it was only for Virtex-4. In version 8.1i, that support was extended to all applicable families. This is documented in Answer Record 20829 (albeit in the future tense; I'll have that updated).

thanks, david.

Thomas Entner wrote:

Reply to
David Dye

I belive the parity bits is physically located as the MSB's. In a 18 bit RAM-config, the "left-hand-bit" is the parity bit for the left-hand byte, and the second bit on the left is the parity bit for the right-hand byte. But you can use all bits as ordinary data-bits if you wish, as others have mentioned before.

Reply to
Jan Hansen

Reply to
Peter Alfke

For network applications, they are fantastic as end-of-packet markers.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.