XEM7310 RAMTester

#1

I’m trying to build the FPGA code for RAMTester on the XEM7310 under Vivado 2019.1.
I created a project and brought in the source files and constraints. I added the MIG IP and customized based on:
https://docs.opalkelly.com/display/XEM7310MT/DDR3+Memory
I had some initial errors as the fifo IPs were locked and out of date. I upgraded them but now when I try to build it I get:

[Vivado 12-4810] IP ‘fifo_w256_128_r32_1024’ is locked and cannot be converted:

  • IP definition ‘FIFO Generator (13.1)’ for IP ‘fifo_w256_128_r32_1024’ (customized with software release 2016.3) has a newer minor version in the IP Catalog. * IP definition ‘FIFO Generator (13.1)’ for IP ‘fifo_w256_128_r32_1024’ (customized with software release 2016.3) has a different revision in the IP Catalog. * Current project part ‘xc7a75tfgg484-1’ and the part ‘xc7a200tfbg484-1’ used to customize the IP ‘fifo_w256_128_r32_1024’ do not match.

I checked and they are updated. I don’t see why the project part is wrong nor where to fix that.

Any ideas?

#2

Have you tried rebuilding the project with the upgraded IP cores?

#3

Yes - see screen capture.

image
image.png632×532 19.8 KB

#4

While this was simmering, I took care of other build errors and now it builds fine. Maybe the old error just didn’t clear. I closed and reopened the project and built it again and it builds ok.

For others trying this out, here are the things I ran across:

  1. Copy the sources and constraints to a new location. Be sure to add the OK*.v sources.
  2. You will probably be using a newer version of Vivado, so upgrade the fifo IP. (IP Sources tab, right click on each IP and select Upgrade)
  3. Go to IP catalog and add in Memory Interface Generator under Memories and Storage Units.
  4. Set up the MIG using the information in:
    https://docs.opalkelly.com/display/XEM7310MT/DDR3+Memory
  • complain about the random listing of pin names in the Xilinx interface…
  1. Add the MIG constraint files to the project.
  2. Change the name of the MIG instantiation in the top level Verilog file to match the name in the instantiation template (mig_7series_0.veo).

That seemed to work for me.

#5

As I look at this more closely, I’m checking the many (848) warnings produced, and many look important, although the code did seem to function. Here are the synthesis errors:

image
image.png834×580 50.9 KB

Things like the number of address lines seem odd. I used the code example for the XEM7310 and generated the RAM interface based on the instructions - seems like they should match.

#6

Generally speaking most of these warnings can be safely ignored.

In particular, the warning about the app_addr length will not negatively affect this sample, as the highest address bit will simply be ignored by the MIG core (because the MIG core address range is shorter than the other modules). Reducing the app_addr length in the other modules may reduce some utilization inside the device, but it is unlikely that it will impact anything significantly. If things were reversed and the MIG had a wider address range there would be an issue (as we would be unable to address the full memory), but that is not the case here.

Many of our endpoints generate a lot of unconnected signal warnings on okHE/okEH due to the fact that not all endpoints use every signal on those busses. These warnings are safe to ignore and difficult to remove.

Warnings from inside the okCore module can be safely ignored.

Generally speaking, FPGA design differs from software in that warnings cannot always be avoided. Oftentimes the shorthand used to make an FPGA design more readable/workable result in warnings as well (like those related to the okHE and okEH signals).

#7

Thanks for the insights. It’s the ‘generally speaking’ that is worrisome. I suppose through testing I’ll see if any warnings are important. Your guidelines do help in ferreting out which ones I should be looking closely at, so that is very helpful, thanks!