RAMB16 primitive write/read collision differences betweem virtex2 and virtex4

Hello,

I have a design in a Virtex2 that uses RAMB16 primitives. In this design I access to this memory to write and read the same address at the same time. This gives a collision but over the board it has the expected result, it means, it write the data and put in the output the new data. Porting this design to a Virtex4 I found that the behaviour of the RAMB16 is different and the design doesnt work. I go around this problem adding some logic to avoid collisions in the memory. But my question is, is there any difference between RAMB16 primitive in Virtex2 and Virtex4?

Regards

Javier

Reply to
Javier Castillo
Loading thread data ...

Look at the Library Guide entry for RAMB16.

There are three WRITE_MODE parameter values that may underscore the difference between the two designs. I believe the Virtex2 RAMB16 primitive behaves like the "WRITE_FIRST" mode while the Virtex4 has the additional settings of "READ_FIRST" or "NO_CHANGE" for same-port read/write. Your synthesizer might change the default setting from "WRITE_FIRST" to something else, altering your expected behavior.

Reply to
John_H

Hello,

Yes, I know it. In simulation I tried NO_CHANGE parameter and all works fine. In both designs when sinthesizing I used the "WRITE_FIRST" parameter but in Virtex2 it works and in Virtex4 not.

Regards

Javier

Reply to
Javier Castillo

I found the problem.

I was using Synplify 8.1 to implement the design and it seems that it has some problem using RAMB16 primitives. Using XST the design works fine. The same design using Synplify and Virtex2 also works. So I suposse there are a problem with my design and the Virtex4 mapper.

Regards

Javier

Reply to
Javier Castillo

I haven't used Synplify for a while, but it used to add a 'collision wrapper' around dual port block rams unless you turned off an option, something like syn_ramstyle="no_rw_check" ( or there may be a "don't mess with instantiated primitives" option somewhere )

Brian

Javier Castillo wrote:

Reply to
Brian Davis

very likely simplify doesn't propagate the bram attribute further (but xst does) , what I would try is to run netgen to generate a back annotated netlist after ngdbuild (translate) and try to see if the atteibute is attached to the bram correctly. I realy don't see this coming from mapper (assuming mapper is xilinx MAP app) but I can investigate for you is you give me some files. I think the default value for this attribute has change from V2 to V4 and this will explain difference in behaviour when this is not set by the synthesizer.

Cheers, Aurash

--
 __
/ /\/\ Aurelian Lazarut
 Click to see the full signature
Reply to
Aurelian Lazarut

I have discover that disabling the sequential optimizations in Synplify corrects the problem. So I am still supossing that the problem is due to the use of Synplify with Virtex4.

Regards

Javier

Reply to
Javier Castillo

Hello,

I used the new version of Synplify (8.2.1) and the problem has dissapeared. It seems that there was a bug retiming option for Virtex4. Now with the new version it has been corrected and all works fine.

Regards

Javier Castillo

Reply to
Javier Castillo

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.