Common problems migrating from XEM6001 to XEM6010


#1

I have been using an XEM6001 in my application and recently changed to an XEM6010. The application runs in two modes. In the first mode, single commands are sent to the FPGA by USB which then sends commands on to secondary devices. In the second mode, a list of commands are stored on the FPGA and then a state machine reads the list and executes the command.

I have recompiled the bit file after regenerating the memory and clock cores, updating the FPGA type, and rerouting the output signals. The single command mode works perfectly. The list of commands mode does not work. The state machine apparently halts. I was curious if anyone had similar problems migrating from XEM6001 to XEM6010 and what common bugs are known.


#2

Common bugs with what? Typically, if a design works on the smaller Spartan-6 devices and timing closure is done properly, then migrating to a larger Spartan-6 device is pretty straightforward. The Xilinx primitives are all the same and you don’t even need to regenerate the memory and clock cores since the resources are (typically) monotonically increasing with larger device size.

So if your design still meets timing with the larger device (problems can occur here if you’re pushing the edges of clock speed because the device is larger and routing is slower), you should be in good shape.

Sometimes Xilinx does introduce new bugs with ISE and the core generation from one version to another. But Spartan-6 data is very stable now and has been for some time. If you generated your XEM6001 design on an earlier version of ISE, you might want to try generating on the latest version first… then do the XEM6010 migration.

The obvious next steps are simulation and ChipScope. It would be interesting to know why the state machine is halting.

One other note regarding state machines – without seeing your code, it’s impossible to know if you’ve fallen prey to the many common pitfalls of state machine design on FPGAs. One such being properly synchronizing inputs to the state machine’s clock domain. If you’re not doing this, all bets are off and your state machine is doomed to fail sooner or later. The migration to a different device size was just a red herring – you won the lottery with the small device and your luck ran dry with the larger one.