Following my previous column in which we pondered The Zen of Writing Code, we will now look at some of the more important aspects of using the PicoBlaze 8-bit soft core microcontroller. Thus far, we have considered only basic programming of the "Hello World" ilk, but now we need to really get to grips with the tools available. So this column is all about programming one's PicoBlaze and using the JTAG loader tool.
FPGA hardware design engineers are used to the somewhat tedious process of turning an HDL (hardware description language) source code file into a corresponding configuration (*.bit) file, which can subsequently be used to configure the target device. If you've done this yourself, you will also know that you can usually wander off and make a cup of tea while the configuration file is being generated; by comparison, the final "zapping" of the file into the target takes only a few seconds.
As a software engineer, I know that this FPGA scenario is very different to the way in which things work in the embedded world of microcontrollers. When using microcontrollers, the hardware is already defined, compliers are fast, and programming takes only seconds. Software engineers do not want to sit around!
The issue we have with the PicoBlaze is that our assembler code first has to be turned into a VHDL (*.vhd) file, which is included in the FPGA build. This means even the simplest of "tweaks" can take ages to get from the screen into the target device. That's not good, because it leaves your engineer with far too much time on his or her hands to look for a new job. But "wait," I say! That clever chap Ken Chapman (the creator of the PicoBlaze) has already considered this problem and has supplied us with a JTAG loader that allows us to load a program into the PicoBlaze's memory (that's on-chip memory in the FPGA) without having to go through the FPGA build process.
Of course, you still have to go through the build process one time to load your design -- including the PicoBlaze core -- into the FPGA. After this load, however, you can upload the machine code program for the PicoBlaze into the FPGA's on-chip memory using the JTAG loader -- a process that takes only a few seconds.
So, armed with this newfound knowledge, let's walk through the ABCs of programming our PicoBlaze core (or cores) using the JTAG loader. Our first step is to return to our original FPGA design and set a flag to say that we wish to allow the JTAG Loader to program the PicoBlaze. This is in the port mapping that defines our program ROM; set "C_JTAG_LOADER_ENABLE" equal to "1" as illustrated on line 138 in the code below:
Note that this process is described in excruciating detail in the PicoBlaze User Guide! One we've done this, we simply follow the normal route of regenerating the configuration (*.bit) file and loading it into the target device.
So now the real fun begins. Having used the "kcpsm6.exe" PicoBlaze compiler -- as described in my earlier blogs -- I already had a *.hex file containing the executable version of my code. But I wanted to prove this new approach by modifying the flash-rate of my Blinky LED. So I slowed down the loop by increasing the count, then I re-ran the compiler to generate a new *.hex file. I now run the command line tool called JTAG_Loader in the same folder as my *.hex file. (Note that you may have to go check the "readme files" on setting up system path variables so that the system can find the DLL files.) When the Loader runs, it locates the target and determines that you're ready to program the PicoBlaze. So I then simply repeated the command, but this time with the filename I wish to be programmed. Less than a second later, the JTAG Loader tool had accessed deep inside the FPGA and into the PicoBlaze’s memory area and reprogrammed the device. The LED then began to blink much slower. This is just what a software engineer wants -- a tool that can reprogram the target in seconds!
Moving forward, this means I can now tweak my code and quickly test the result without having to go through that tiresomely long rebuild process. My next challenge will be to debug the PicoBlaze. There are lots of options available to us here, such as using the in-built simulator or employing the ChipScope virtual logic analyzer. I'll be discussing my approach in my next column, but I’d also be interested to hear how you would set about debug the PicoBlaze -- what would you do?
Related posts:
Tweet This
