Migrating from Xilinx ISE to Xilinx Vivado FPGA software

Until now, we have been using the old (and deprecated) Xilinx ISE software to compile the VHDL for the MEGA65 project. This is all a bit of an accident of history, because when the project first began in 2014, ISE was only just at end of life, and deficiencies in my VHDL programming style meant that I couldn't get it to work in Vivado.  Also, Vivado was less mature at the time.

Now, all that has changed: ISE is well and truly end of life, and approaching the zombie stage.  Vivado is now much more mature. But perhaps most importantly, Kenneth, one of our volunteers has put in a LOT of work silently in the background helping to move the project over to Vivado. 

The work involved, and the value to the project of doing this cannot be understated.

First, synthesis time under Vivado is fully 10x faster than under ISE.  This means we can do a synthesis run in ~10-15 minutes, instead of ~2-10 hours.  The benefit of this cannot be overstated.

Second, by fixing the semantics of memory access of the internal memories in the FPGA, a whole raft of instabilities have been fixed. These instabilities were causing differences in behaviour on different FPGA chips of the same model, and generally causing many lost hours due to chasing my tail on the symptoms of the problem, rather than the cause.

Third, Vivado achieves better timing closure.  This means that it is easier to get the design to run at the correct clock speed.  It also opens the door to increasing the clock speed in the future.

Finally, we are now somewhat future-proofed for ongoing development for the foreseeable future.

While most of the changes have been in the background, there are a few practical differences.  One of those is that various fixes along the way have improved our Bouldermark score somewhat to 38,980 (up from about 31,000).  This means we have a Bouldermark score 124x that of a stock C64. However, as previously explained, Bouldermark is a bit non-linear, in that the first few hundred points are quite a lot harder to get than the majority. This is consistent with the results of the Chameleon 64, which gets a Bouldermark score of 44.62x, but only 10.79x on Synthmark (our current Synthmark score is, for reference, 51x).

Kenneth gets an extra gold star for having found and fixed a problem with self-modifying code that was previously causing Bouldermark (and presumably other things) to not run stably.  This was all part of the same memory access semantics problems: In this case, it was possible for the CPU to begin fetching the next instruction before the RAM had time to update internally to present the updated value.  While this sounds absurd, when the clock cycles are only 20ns, propagation time inside components becomes a real consideration.