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.
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.
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.
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.
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
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
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.
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:
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.
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.
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
"Andy" schrieb im Newsbeitrag news: snipped-for-privacy@a14g2000cwb.googlegroups.com...
Thanks John, that's useful to know! Syms.
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:
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.
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
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.