BMOW title
Floppy Emu banner

Small Progress

Finally, some small progress on the memory interface. After banging my head every which way against the Xilinx tools, and reading everything I could find on the subject, I came across Leo Silvestri’s page on modifying the Xilinx MIG memory controller design for a Spartan 3E board. It’s for a different kit and an older version of the software, but with his help I was finally able to build the reference design and testbench for the Spartan 3A board, program it to the FPGA, and see the LED that indicates success. It’s not very exciting, but it’s progress.I still can’t believe all the steps I went through, and the whole process has made me quite bitter about Xilinx’s software tools. I’m sure it would be easier if I had better general knowledge of this field, but the last few weeks of this project have been like being lost at sea, and totally disoriented. It still feels more like a series of disconnected guesses than a genuine understanding, but here’s what I’ve managed to piece together on the topic of using the DDR2 SDRAM that’s on the Spartan 3A kit board.

  1. The Xilinx MIG can’t be used to generate a new memory controller design for the Spartan 3A board. This is because the way the SDRAM on the board is connected to the FPGA pins violates some of the MIG design rules. The only solution is to use the pre-built Spartan 3A board reference controller design, which then locks you into a specific burst length and CAS latency, or to hand-modify the code generated by the MIG, which is way beyond the skills of a noob like me.
  2. Using the newest version of the Xilinx ISE and MIG, attempting to add the Spartan 3A reference design to your project will cause a crash. No answer from Xilinx support on this.
  3. You can also get the Spartan 3A reference design as a zip file. But if you unzip it, add all the files to a new ISE project, and try to build it, you’ll get lots of errors about non-existant nets that I couldn’t resolve.
  4. There’s also a batch file in the zip file that will create a new ISE project for you. But try to build it, and you’ll be told that the design requires a ChipScopePro license, which is Xilinx’s software logic analyzer. I found a discussion of this on the Xilinx forums, but no resolution other than to create a new controller design that omits ChipScopePro support, which is impossible for this board due to issue number 1 above.
  5. What finally worked was to hand-edit the reference design, deleting parts of it semi-randomly until the ChipScopePro error disappeared. It turned out that required removing three modules called icon, ila, and vio, none of which seemed obviously related to debugging to me.

So there you have it. The next step will be to begin to actually use this interface for something more interesting than lighting up an LED. I’m just now realizing that the interface created by the MIG is just the first, small step towards what the 3DGT memory controller must eventually become. It’s not enough to simply have an interface that permits reading and writing. To achieve half-way decent performance, much care will be required to manage and coordinate those reads and writes, minimizing waiting and wasted time, and maximizing throughput. And to top it off, it’s going to need a bus master to arbitrate memory access between the display circuit, pixel processors, vertex processors, and any other consumers of memory. All this is a substantial project in itself, that will need to be at least partially completed before any real progress can begin on the 3D part of 3DGT. Looks like a long, slow climb, but I’m moving ahead.

Read 4 comments and join the conversation 

4 Comments so far

  1. Gregg Levine July 6th, 2009 5:07 pm

    Do you, Steve, remember what Obi-Wan said to Luke regarding his (Luke’s) efforts to use the lightsaber to tag that target-globe, while wearing that helmet?

    He said “Luke, you’ve taken the first step into a larger universe.”.

    That’s what’s happened here. Granted others will argue it already happened with BWOW, I believe since you’re working with those FPGA devices, and that crappy software that the firm produces, this something different, and my comment applies.

    Incidentally blinking a single LED connected to a GPIO (set to be an output of course) is par for the course with these things especially since cores are available for working as different processors. This however is decidedly different and good.

  2. Steve July 6th, 2009 7:30 pm

    Thanks Obi-Wan. Comprehension is dawning, ever so slowly. Today I discovered that if you right-click one of the actions in the ISE’s Processes panel, you can open a properties dialog with dozens of different options for that action! This answers one of the questions that had troubled me the most: why did the script-created project file work (after removing the ChipScope references), but a newly-created project file containing the same RTL and UCF files didn’t? What secret magic pixie dust did it contain?

    The answer was that the script-created project file also specified some non-default options for the Synthesize step. In particular, -keep_hierarchy was set to “soft” instead of “no”. This was apparently the cause of the non-existent net errors I was getting earlier: the UCF file refers to the nets by their hierarchical names, which presumably were lost during the synthesize step without that option. After I changed it, I was successfully able to implement the memory controller and program the FPGA using my newly-created project file.

  3. kipman725 August 19th, 2009 6:42 am

    FPGA’s can be very fustrating and the software is also buggy on the altera side. When I last messed around with an FPGA board I just made everything from scratch in VHDL upwards from basic logic gates. Asin well I need a random number genrator so lets make some flipflops and then include them and then lets make the random number genrator then lets include that in the actual game logic.

  4. Phenominom July 28th, 2011 11:52 am

    Hey Steve –

    I realize that this is an old post (~2 yrs), but I have the same FPGA dev board, and also am struggling to create an HDL interface to the onboard DDR2. This is quite a common stumbling block with this board, judging by a small multitude of posts on various related forums.

    Would you be at all willing to make the source available publicly? If so, it would very much be appreciated 🙂


Leave a reply. Comments may not be monitored regularly. For product support questions, visit the Contact page.