Porting MinSoc to the Nexys2, part 2

So in my last post I expressed some frustration in porting the MinSoc to my board. Here I will resolve the issues I mentioned.


It turns out that the other 3E board project has similar problems, so I decided to solve it in a similar way. When you run the spartan_3e_starter_kit configuration script it will blow away the configuration files inside the OR1K cpu with new ones without asking. How rude!

I've created a new or1200_defines.v and disabled a huge laundry list of features. The biggest impact of this is that linux can't run on this (No MMU). I also wrote a an extension to the configure script that tells you this, asks your permission to modify the OR1K cpu, and makes backups of the files it is changing.

• Features removed:
• OR1200_NO_DC
• No data cache
• OR1200_NO_IC
• No instruction cache
• OR1200_NO_DMMU
• No data MMU
• OR1200_NO_IMMU
• No instruction MMU
• OR1200_MULT_IMPLEMENTED
• No hardware multiply
• OR1200_MAC_IMPLEMENTED
• No hardware Multiply and accumulate 

By doing this, I was able to achieve a 3% reduction in space. Yikes, still not a whole lot of room to work with. This will hopefully be enough room for me to play around and decide if I like the MinSoc platform. If I like it, I may consider buying a larger FPGA.

   Number of BSCANs                          1 out of 1     100%

   Number of BUFGMUXs                        3 out of 24     12%

   Number of DCMs                            1 out of 4      25%

   Number of RAMB16s                        18 out of 20     90%

   Number of Slices                       4533 out of 4656   97%

   Number of SLICEMs                        24 out of 2328    1%

Here is the new MinSoc board support package for the Nexus2-500. Place it in your "Backend" directory and run ./configure like any other backend board. Once I can confirm this support package is fully functional I will submit it to the MinSoC project for inclusion in the distribution.

So my next step is to get some software loaded onto it. I own a BusBlaster JTAG module based off the really popular FTDI2232, which the adv_debug_bridge software claims to support. Expectations are different than reality, and this is no exception. I cannot get adv_debug_bridge to detect my 'cable' and there is zero documentation. I'm pretty sure it has something to do with the usblib-win32 software and windows drivers.

I may end up writing a patch to for the adv_debug_bridge that enables use of the Digilent JTAG interface that appears on most of Digilent's boards. The only thing stopping me from doing this right now is the uncertainty of using a windows DLL within Cygwin.