Well, it's been a few weeks now since my previous blog in which I described how I finally managed to get video output onto my VGA screen.
This was a great step for me as I can now see results of what is happening inside my FPGA-based version of the Game of Life (GOL). However, the story is not over as I now have to connect an 8-bit PicoBlaze soft processor IP core to the memory grid in order for it to generate the images that will appear on the screen. This small task prompted me to think about how I write code and my psychology when it comes to writing it.
I'm reminded of two key statements from my background as a software engineer: "Software takes only a few hours to write, but weeks to debug" and "Simple tasks often take the longest to achieve." I originally started this column by saying something along the lines of "All I need to do now is to just connect a PicoBlaze to the memory," and now regret that. My idea of having information presented to the PicoBlaze in such a way that it's easy for it to be processed turned out to not be as simple as I first guessed it would be. If you can't remember what I was originally setting out to do then go have a quick look back at my column on the way in which I'm implementing the memory array for my GOL.
I started this part of the project the way I usually do, which is by creating a VHDL framework and then adding comments describing what I intend to do -- things like "Store top line when we start a new loop of memory." I find comments like these are really helpful when it comes to setting the goals I want to achieve. (Click here to see a larger, more detailed version of this image):
The idea is to break the big task down into smaller tasks. This also means that I can easily view all the comments with no code written to ensure that I have captured everything and covered all the bases. When doing this in a language like C, it means that I can see the flow of the code down the page. In the case of VHDL, it means that I can see the structure of the blocks interacting with each other. This then allows me to see what signals and interfaces I will need.
The next part is to get one's hands dirty and actually write some code. I like to warm my brain up by starting with small tasks that are quick and easy to achieve, and that give me a "warm and fuzzy feeling" of actually making progress. For example, I like to update my entities with all of their "ins" and "outs." In the case of a big entity, I add comments to remind me what all of the "ins" and "outs" are for.
Around this time I'll also start with the more simple VHDL code. For example, one of the first tasks is to take the cell references (I'm using an X/Y coordinate system) that are passed as "std_logic_vectors" and change them into integers.
Once I'm "warmed up," I will work on bigger portions of the code. I do, however, try to keep a flow in mind. I know that logic inside the FPGA works in parallel, but it helps me to write my code while thinking about what is affecting -- to start with the first part and slowing move through the system. This prevents me from jumping backwards and forwards around the code and getting confused.
To Page 2 >
Tweet This
