cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mandonov
Visitor
Visitor
11,197 Views
Registered: ‎11-10-2011

Spartan 6, XC6slx150-3fgg676

Question1.  How do I guarantee WRITE FIRST " mode in BRAMs?   I am having trouble making sure my BRAM is using " WRITE FIRST " mode.  I included the file as an attachment.   I copied the example in the XST User Guide, UG627 (v 11.3) September 16, 2009 page 151 titled "Dual Port RAM With Enable on Each Port Verilog Coding Example".  While it makes a WRITE FIRST mode correctly if I synthesize this verilog module by itself, when I actually use it as a submodule, the higher level verilog module changes it and converts it back to READ FIRST.  I remember in another area of my design, that I had to use a wrapper around the lower level module and TWO clocks, to make sure it made a WRITE FIRST  DPRAM, which did not make sense to me since I copied the ONE CLOCK example right from the  XST User Guide, UG627 (v 11.3).   

 

Question 2.  I am aware and want to avoid having the problems that are mentioned in the 4 erratas on BRAMs for this Spartan 6 part.  I read somewhat thoroughly the AR#: 34533, 39997, 34541, 39999, and 40000.  I am using ISE 13.2 which supposedly fixed some of the problems, except it needs a patch.  I think I am using the software patch in  the link below, but I am not sure if it actually took effect, since I don't see any mention of it in the console window during synthesis/implementation/Generate Programming File.  As was mentioned in the "readme" file, I changed the environment variable to point to C:\Xilinx and placed the zip file and the unzipped files in that directory.

  Patch for ISE 13.2: http://www.xilinx.com/txpatches/pub/swhelp/ise13_updates/ar44192_ar44193_cr620145_cr620373_spartan6_spartan6l_spd_13_2_o61xd_all_preliminary.zip

 

  I also entered this in the Synthesis and Implemation settings respectively:

Map Properties     “Other Map Command Line Options”  -convert_bram8

XST Properties   “Other XST Command Line Options”  -infer_ramb8 No

Generate Programming File " “Other BitGen Command Line Options” -g INIT_9K:Yes"

 

Question 3. How do you know what the FIFO Core Generator is making.  I can't find in any report if it is making WRITE FIRST or READ FIRST.

 

Any help on any of these issues is appreciated,

Michael

0 Kudos
5 Replies
austin
Scholar
Scholar
11,195 Views
Registered: ‎02-27-2008

m,

 

1.    I do not know the answer to this question, but you can always use FPGA_editor to examine the design to verify what it is set for.

 

2.  If you convert all BRAM8 to the larger primitive, the software should be working (takes the smaller primitive and re-maps it to the larger one).  You can see if this is happening by examining the usage report.

 

3.  Again, one can use FPGA_editor to check to see what it is doing.

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
mandonov
Visitor
Visitor
11,194 Views
Registered: ‎11-10-2011

I just tried hooking up the port A data bus and it made it a WRITE FIRST mode.  So if i leave this port unused, which in reality is my case,  it makes it READ FIRST.  I am trying to do a Simple DPRAM, not a True Dual Port RAM.  I wonder if I should add in my ucf file these lines:

INST WRITE_MODE _A = WRITE_FIRST

INST WRITE_MODE _B= WRITE_FIRST

0 Kudos
mandonov
Visitor
Visitor
11,145 Views
Registered: ‎11-10-2011

I figured out that it is best to use example 1 and NOT example 2 to guarantee "Write First" mode.  There are two examples in the XST user's guide, UG627 (v 11.3) September 16, 2009 page 151.  I guess Xilinx version 13.2 does not recognize example 2 as a guaranteed way of doing "Write First".  Maybe Xilinx version 11.3, matching the User's Guide version did recognize both techniques of doing it.

 

I am using now Xilinx version 13.4.  Be aware that is you use Smart Explorer to pick a new and better Mapping options, it will blast away the Map setting mentioned in the first post above to avoid the 9K Block RAMS:  -convert_bram8.  What a pain.  They came back and I needed to put the setting back in after seeing the warning telling me to avoid 9K Block RAMS.

 

I really wonder if there should be another errata (already 4 on record) about these Spartan 6 block RAMS.  In my design, I have had to hand code many CoreGen block RAMS to verilog versions to get my design to work.

 

I succeeded and did use PlanAhead, as mentioned above by Austin, to see what CoreGen generated for Block RAMS in order to know whether they were "Write First" or "Read First".  These are the steps.  I opened Planahead.  Then out of the 5 options, I chose to import a Syntesized netlist, which then has you search for an .ngc file.  Then after that, it said import the .ucf file.  Then I got an error message saying it couldn’t find the Block RAM black boxes, so I imported the .ngc files for the Block RAMS that it needed.  Then from the top menu I did Edit ..... Find .  I chose Block RAM.  Then you can click on any of the Block RAMS found at the bottom in the Find Results tab.  Then in the window Instance Properties, you can click on the Attributes tab and scroll to the bottom and see if you have Write First mode or Read First mode.

0 Kudos
mandonov
Visitor
Visitor
11,048 Views
Registered: ‎11-10-2011

Another question for Xilinx FAE's:

 

1)  Please explain what does this errata mean

 the core does not combine two adjacent 9K BRAMs into one 18K BRAM.

in AR42712 "Block Memory Generator v6.2 - Release Notes and Known Issues for ISE Design Suite 13.2"   referenced in  “IP Release Notes Guide, XTP025 (v3.5) July 31, 2012” .

 

Known Issues in v6.2

- When the IP core is generated for Spartan-6 devices, the core does not combine two adjacent 9K BRAMs into one 18K BRAM.

 

It seems like the CoreGenerator can't convert 9K RAMS to 18K, yet the other errata mentioned above wants you to add these settings to the XST tools to convert 9K RAMs to 18K.  Is there a conflict?  If I read this correctly, this conflicts with one of the workarounds which says force all 9K block RAMs to be 18K, by using a switch settings in the synthesis tool to avoid using 9K block RAMS.  My take on it is that later on in the process, the settings can do what CoreGenerator could not do?  Please explain anyone?

 

Again it seems like it is safer to never use the CoreGenerator with the Spartan 6, when using Block RAMS, and design your own block RAMS from scratch.

  

These are the settings to add to convert 9K BRAM to 18K BRAM in the Synthesis and Implementation settings:

Map Properties     “Other Map Command Line Options”  -convert_bram8

XST Properties   “Other XST Command Line Options”  -infer_ramb8 No

Generate Programming File " “Other BitGen Command Line Options” -g INIT_9K:Yes"

 

   

0 Kudos
mandonov
Visitor
Visitor
10,998 Views
Registered: ‎11-10-2011

Here are some tips I wrote to avoid Block RAM issues and errratas with Spartan 6.  I hope it helps the Xilinx community out there.

0 Kudos