ISE 11.1

Quick review.... Licensing is the major change, and it was actually quite painless. Xilinx allows you to create licenses from the Entitlement page. My license was created immediately which in turn allowed me to start working immediately. Installation was done from the 5.3 GB tar file download also from Xilinx's Entitlement page. The download was fast, about 2 1/2 hours. Installation includes Chipscope, EDK and the standard ISE Foundation. The last step in the installation takes you to the licensing page and uploads your computer's ID so that the license can be created.

They have made some nice GUI improvements. The IDE looks smoother. They have also changed the text on many of the compilation messages. I'm guessing there was some overhauling done on all stages. Synthesis and par (Place and Route) are supposedly much faster. So far I haven't run into any major problems with the new tools. A nice change is the new xise project files. Finally a text based (XML) file that can easily be stored compared and modified.

There is a new MIG (Memory Interface Generator), version 3.0. The only difference I can see is that the previous requirements for column locations, and master / slave DQ bit information is no longer required. This is very nice as it means you can change IO constraints without having to run "Update Design," or manually change those values. Apparently this update is due to an update in the par which can intelligently place components without the previously required information. The other change in the MIG is that they are using PLLs now instead of DCMs. This might have to do with DCMs being removed from the Virtex 6, and to keep MIG compatible with the new chips.

Enjoy the new tools.

mig 2.3 - what's this all about

So I had to implement an SDRAM controller on a Xilinx chip. That's the MIG (Memory Interface Generator). First off - this is no simple wizard click click task, you must understand how the MIG works to get going. The MIG in the end just creates source files for you, there is no NGO files involved. It creates a completely open-source implementation. This has certain implications:

1. The source is compiled within your project, so any XST (Synthesis) settings you have will affect the synthesis of the MIG. For example, if you want your design to be optimized for area and the MIG needs to be optimized for speed then you better figure out how to create a black box.

2. It is not extremely friendly as the assumption is that you will open the source and edit what you need to. If you choose to have the MIG implement the clocking then you will have to provide GC (Global Clock) input pins for both the interface speed (266 MHz for example) and the 200 MHz IDELAY clock otherwise the code won't compile and you'll need to modify the source (most changes will be in the infrastructure file). If you choose to implement the clocks yourself than you'll have to provide the 4 clocks correctly phase aligned (phase alignment isn't required for the 200 MHz IDELAY clock) and sent through BUFGs (Global Buffers) into the top MIG module.

3. All EVM examples I've seen provide a different pinout than the defaults given by the MIG, and under most circumstances so will any new board. This is a pain in the ass, but not as bad as you might think. There are a number of tedious requirements for the MIG, ie "What is the column location of all DQS pins?", "What type of pin is each DQ - Master or Slave?", and "How many regions have DQS pins in them?". This is all annoying and can manually be updated by following the instructions in the MIG user manual (appendix about required UCF modifications), but the easiest method of updating this information is to create a MIG implementation. Make sure to mark all banks available for all functions (one of the last pages with a list of banks and checkboxes for address, control, and data). Take the created UCF file and remove all constraints except the pin locations. Update all pin locations manually to the pinout of your board. Open the MIG design again and choose the option "Update Design". Give it the modified UCF and let it create the full design again. It will update all constraints and source files, and spit out a new UCF with the correct pinout and all the required modifications.

4. The MIG provides 2 example trees, "user_design", and "example_design". To compile the designs you can use the ise_flow.bat found in the designated par folder. The example design allows you to provide just the SDRAM signals, the clocks, and the reset. The user design would require you to add your own user code.

The example design is best used to test that the MIG implementation works. The example design compiles into a self-contained testbench of the SDRAM. The easiest way I found to use the example design was to insert a chipscope core into it which shows the main application signals. The chipscope core is fairly easy to implement. Do Not Use the Debug Option in the MIG. Haven't really figured out what it's for, but I believe it shows you the calibration sequence which is not what you want to see. To get chipscope working you have to build a normal MIG design, update pinouts (as explained above), modify clocks, run through the XST stage in the ise_flow.bat and then start up chipscope inserter. After creating the core and exiting chipscope inserter call inserter.exe on the command line to insert the .cdc project and create a new ngc file (which contains the basic design and the inserted chipscope core). Finish the rest of the steps from ise_flow.bat with the new ngc (output from inserter.exe) It should finish the compilation and you will now have a design which will show you the signals from within the testbench when using chipscope analyzer. If you're lucky you'll see phy_init_done rise, and the accesses begin to take place.

Happy migging!

Can Xilinx ISE be any worse? #!@&^ PCF files

Working with Xilinx's ISE 10.1 has proven to be quite a challenge. The latest failure of their tools has to do with PCF (Physical Constraints File) files. Here's an error that took a while to figure out:

Resolving constraint associations...
Checking Constraint Associations...
ERROR:ConstraintSystem:59 - Constraint "pcie_inst/pcie/BU2/U0/pcie_ep0/pcie_blk/clocking_i/clkout0" TNM_NET =
pcie_inst_pcie_BU2_U0_pcie_ep0_pcie_blk_clocking_i_clkout0>: NET
"pcie_inst/pcie/BU2/U0/pcie_ep0/pcie_blk/clocking_i/clkout0" not found.
Please verify that:
1. The specified design element actually exists in the original design.
2. The specified object is spelled correctly in the constraint source file.

This error is due to the fact that I have constraints that refer to objects that no longer exist in the code. This makes sense since I commented out all pcie code. This doesn't make sense since I also commented out (from the project's UCF file) all constraints (including the above one) that refer to pcie code. So why is it complaining about a constraint that doesn't exist? After attempting my "Rerun All" commands, and after many changes and frustrations I discovered that ISE copies constraints from the project's UCF file into a PCF file during the compilation process. Since I previously had these constraints and compiled with them, the old PCF file wasn't updated. ISE doesn't bother deleting or recreating this file when manually editing the UCF file which causes it to give errors on constraints that no longer exist.

Delete this file, it might help.

Continuation - Xilinx I/O pin's location

I recently discovered the easiest way of figuring out whether an I/O is left, center, or right. The I/O name's X value is 0 for left, 1 for center, and 2 for right. This means that IOB_X1Y318 is center b/c of the X1 value, IOB_X0Y179 is left b/c of the X0, and IOB_X2Y198 is right b/c of X2. This is very easy once you are aware of this naming convention, and I hope this information is helpful for others.

Xilinx I/O pin's location - left, right, or center?

So while working with the MIG (Memory Interface Generator) I was required to find out whether each DQS (Data Strobe) pin was located "Left", "Center", or "Right". I figured this should be easy, just open the documentation. It's not in the documentation. You can only find which bank a pin is in, but you can't find whether a bank (and all it's pins) are left, right or center. I finally discovered with the help of the FAE (Field Applications Engineer - support contact) that I can find whether a bank is left, right, or center by using the Floorplan view in the Floorpan Editor inside of ISE. When floating the mouse over I/Os you know which bank an I/O is in, and by the I/O's location you know whether that I/O and the others in the same bank are located left, right, or center. Another way to figure this out is by using the Package view in the Floorplan Editor and kinda seeing the groups of I/Os and where they are located on the package. Make sure to look at the top view so that the left I/Os are actually on the left instead of right, and vice versa.

Xilinx ISE vs batch mode (command line / makefile)

I don't know. I truly loathe the ISE and since most Xilinx tools produce output that seems (at first glance) more suited towards command line I feel that command line should be better. It can't be worse. Of course this means I have to figure out how to work in the command line. I've now installed cygwin to use the *nix (Linux, Unix) tools and makefile system. Since I never remember how to write makefiles (it's been a few years), I'm busy experimenting and getting frustrated all over again. Tabs (as in the \t or 4 or so spaces thingy) makes a difference in makefiles. And GViM doesn't identify or tabify makefiles properly. This is all very frustrating. My nerves were twitching quite a bit by the end of the day. I think I will try to work within the ISE tomorrow and perhaps during compilations see what I can figure out about command line or batch mode compilation.

SDRAM AL (Additive Latency)

So I've got to implement a SODIMM interface with Xilinx's MIG (Memory Interface Generator). One thing I've learned today is the very interesting use of the AL (Additive Latency) for SDRAM chips. Additive latency allows for commands to be issued to the SDRAM chip and have the SDRAM chip buffer the commands for AL (1,2,3,4, or 5) clocks depending on configuration. This is useful when the time between Activate (SDRAM command) and Read (SDRAM command) (tRCD) will cause a collision between the next Activate and the optimal clock for the Read to be issued on. See http://download.micron.com/pdf/technotes/ddr2/TN4710.pdf for a very good explanation of AL.

The Design and Debugging Stages

Designs have the natural beauty of logic. This means for every design there is always a "perfect" way to implement it. Believe it - it's true.

Every bug has a reason; In other words a basis in logic. Whether the bug is due to bad hardware / peripherals, or if it's because of a bad compiler there is always a reason. Every step of the programming process from the designing to the running can be explained. Bugs are usually the product of an error in the design or implementation, and rarely a problem with the tools or hardware - although nothing should be discounted when attempting to solve a bug.

I'm an amazing debugger. I use very few tools, and I do most of my debugging manually - but I almost always get to the bottom of things. The only reason why I can do this is because of my strict belief in logic, and perhaps the massive amount of experience that I have in debugging.

Be very suspicious of other people's code, and be very suspicious of APIs. This has served me extremely well over the years. This advice must be taken with care. For example it is obvious that most Win32 API calls are gonna work the way they should since they are used in countless systems since whenever Win32 API came out - a while ago. But if you are using the API from a very customized chip maker and the chip / API is new - then be suspicious. Any time you want to suspect an API you must be able to explain at least in theory how that API is only causing you a problem although it's working for other companies / users of the same API.

Other people's code is always a source of friction. Most people take pride in their code and don't like when you look at it suspicously. I'll say this "If the system isn't working then the first step is to look at the code as if it's 100% the problem." Don't listen when people say "The bug isn't in my code." Everyone believes that and someone's wrong. Take this advice with care. We all know that some people are more prone to bugs then others. And that should affect which code you are more suspicious of to begin with.

my history

During my tenure at Mango DSP Ltd (1/2001 - 7/2008), I began as a C++ developer working on basic GUI software. I moved onto developing C code for Analog Devices DSPs with interfaces to Altera FPGAs. As time went on I rewrote all the Windows drivers bringing support to Windows 2000/XP with WDM. I was promoted to Manager of Infrastructures taking on the responsibility for low-level DSP and host libraries. In 2004 I began to venture into FPGA design. I rewrote Mango's complete low-level FPGA infrastructure code bringing down compile times to a fraction of what they previously were, while at the same time significantly lowering resource usage. I was given the additional title as Senior FPGA Engineer at Mango DSP Ltd. I rewrote complete Altera Stratix FPGA designs for image processing systems in a very short time with successful results. I wrote Lattice FPGAs both for Mango DSP Ltd., and for my next employer VisionMap Ltd (8/2008 - 9/2009). My final project at VisionMap Ltd. was a high-bandwidth high-speed Xilinx Virtex 5 design. I built a complete scatter gather DMA engine core for usage with Xilinx's Endpoint Block Plus for PCI Express. I converted an algorithm written in C to a pipelined implementation in the FPGA. My design uses over 400 DSP48E blocks (instantiated manually), and over 250 BRAMs (also instantiated manually). I wrote the accompanying WDM scatter gather driver for testing and final operation.



I have decided to return to the US after 9 years in Israel and I am looking for new challenges and learning experiences there.