In my previous two blogs on the PicoBlaze 8-bit soft processor core, I considered things from a relatively high-level point of view. (See: Introducing This 8-Bit Soft Processor Core and Building the Core.) I'll be continuing along that path in some of my future columns.
Having said this, I've come to something of a fork in the road, because some of the other content on All Programmable Planet has really got me thinking. In particular, I'm talking about Adam Taylor's columns on using FPGAs to drive VGA displays and Chris Taylor's recent column on the increasing use of FPGAs in the DIY (do-it-yourself) arena. Of especial interest in Chris's blog was the part where he described how Mike Field (also known as Hamster) has Conway's Game of Life running in full high-definition (HD) with a 60Hz update on a Spartan 6 FPGA.
Editor's Note:The Game of Life (also known as Life or GOL) is a cellular automaton devised by the British mathematician John Horton Conway in 1970. This is not a game in the classical sense; mathematically and/or computationally speaking, the GOL is a zero-player game, which means its evolution is determined by its initial state, requiring no further input. One interacts with the Game of Life by creating an initial configuration and observing how it evolves.
The combination of these two sets of blogs started me pondering about using one or more PicoBlaze cores running in an FPGA to implement my own version of the Game of Life and present the results on a VGA display. It seems I was not alone in my thoughts, because the next thing I knew I had Editor in Chief Max on the phone saying "What do you think about creating a PicoBlaze-based version of the Game of Life?"
Now, if you aren’t familiar with Conway's Game of Life, may I suggest that you check out the Wikipedia entry and also this Life Patterns Website. The basic idea is that you have a large grid of cells, each of which may be alive (colored) or dead (empty). The rules, which we will look at in more detail later, say that whether or not a cell lives or dies -- and when new cells come into existence in empty locations -- all depends on what is happening in surrounding cells.
Ever since its publication, Conway's Game of Life has attracted a lot of interest. One of the reasons people find this to be so fascinating is the way in which some combinations of rules and initial conditions end up in cell patterns oscillate, while others manage to "crawl" across the display. More complex cell scenarios like Gosper's Glider Gun end up casting off sub-cell-assemblies as illustrated below:
Gosper's Glider Gun.
As we see, the interactions between the two larger cell structures in the upper left result in the creation of smaller oscillating structures that subsequently work their way across the grid.
@Ken: thanks for the elaborate answer! As you probably surmised I'm not a Xilinx user :) And being able to use LUT as memory is definitely something I would welcome.
In the Spartan-3 Generation devices a 'Slice' does indeed contain 2 LUTs (each with 4 inputs) so you are more or less correct to say that KCPSM3 occupies (2x96) 192 LUTs. Of course a 'Slice' also contains flip-flops, carry Logic and dedicated multiplexers and they all play a part too in those same 96-Slices. However, it is the use of the LUTs as memory that really boosts the efficiency of PicoBlaze. The 16 general purpose registers, 64-bytes of scratch pad memory and the 32-deep call/return stack means that there are a total of 960 bits of storage implemented in the LUTs of just 34 of those 96 Slices.
PicoBlaze programs are normally stored in a single Block Memory (BRAM), so yes, you do need one of those too. The scratch pad memory in built-in (i.e. come of those Slices) so you only need to add additional RAM if the application needs it. In practice, if you connect memory to PicoBlaze then it is really a case of PicoBlaze acting as a controller/manager of that memory as part of your application.
If we move on to the more recent devices (e.g. Spartan-6 and 7-Series) then the newer KCPSM6 variant of PicoBlaze will be used. This is somewhat more capable that KCPSM3 but only occupies 26 Slices. How can that be? Part of the answer is that a Slice now contains 4 LUTs but that means KCPSM6 still only uses 104 LUTs. Another part of the answer is that the newer devices have LUTs with 6 inputs rather than 4. Having more inputs gives the potential for more logic to be implemented in each LUT and clearly KCPSM6 exploits this whenever possible. But once again it is the use of LUTs as memory that yields the greatest efficiency. Each LUT now provides 64-bits of storage; four times greater density that the 16-bits per LUT in Spartan-3.
@Ken: The Xilinx doc specifies 96 Spartan-3 slices (which in my language is about 192 LUT's, I assume). You still have to add the ROM and possibly also some RAM?
Paul Clarke 7/27/2012 2:40:21 AM User Rank Blogger
Re: Why PicoBlaze?
Hi Rodney,
I guess most people will have mixed results with the PicoBlaze as they will with any device. Just want to pick up on some of your point however:
As the tool chain is Windows based I'm going to guess that getting it to run under any other Os is going to have issues. Also posible that, and you did not say, that you have used with like myself on the Spartian-3. The tools on the newer chips are better.
I did not understand your commant about the ports beign designed in two differant languages? My next blog that uses a port is along with the picoblaze all in VHDL, or you could have gone all Verilog. The PicoBlaze does not come with ports, just a guide on how to design them. So I'd like to know more.
Your correct there are lots of other cores out and about and I always incorrage people to consider what thay are using. For me the PicoBlaze is free, well documented and has a great support site. Sometimes other cores are 'just' dumpped on OpenCores with little back up. To me the support is a big factor.
There are other ways to get more memory and code space in the picoblaze, I've not ratteled off into this as yet as i want people to grow and understand PicoBlaze and other Soft Cores.
These blogs are about understanding why you use a PicoBlaze / soft core in place of a FSM. As the blogs go on we will find the good and the bad.
I've used a PicoBlaze before and had mixed results. It did what was needed -- receiving control messages from an external SPI master and queuing and relaying control messages to several attached devices and I2C peripherals.
There were however problems:
1. The tool chain was really bad -- I had to go through some contortions to get the DOS assembler to run under Linux as part of a make file.
2. As the design grew and the number of I/O ports grew the PicoBlaze became the bottleneck on PAR. I eventually had to re-architect the system to run the PicoBlaze at a significantly lower clock rate. This complicated the clock domain structure of the system.
PicoBlaze designs also suffer in that the ports have to be defined in two languages in separate files. Simulation in Verilator also required copying and modifying library files to make them synthesizable.
On a recent Xilinx project I again needed a PicoBlaze-like processor. However, because of my previous experience I decided to look for an alternative. There are lots of processors on OpenCores, but they are either huge in comparison to PicoBlaze or, if they are comparable in size, they are incomplete, abandoned, or not fully open source.
My solution was to roll my own. The 9-bit opcode, 8-bit data, stack based processor is available on github as SSBCC (small stack-based computer compiler) and has the following features:
1. It is slightly larger than PicoBlaze, runs significantly faster than PicoBlaze, allows up to 8K instructions and up to four RAM/ROM, each of which can be up to 256 bytes. The tool chain is written in Python 2.7.
2. The assembly language is Forth-like, which helps make the assembly language programs more readable.
3. I/Os are declared in an architecture file which eliminates the mundane task of coding muxes and latches and eliminates the nuisance of defining the ports in two languages in two files. The I/O structure includes strobes so that FIFOs can be connected directly to the processor with no additional logic. Open drain I/Os, UARTs, PWMs, simulation diagnostics, and custom peripherals are provided by Python scripts.
4. Simulations have been straightforward with ISIM, Verilator, and Icarus Verilog.
The core and assembler are complete. I'm still working on the documentation but will help you if you decide to abandon PicoBlaze and use this processor instead.
It might be useful to use color in a scalable display. While brightness could be used to represent population within a 2x2 block represented in a single pixel, color could provide a more visually distinct presentation. (One could imagine panning across a habitat larger than the display area as well as zooming in and out.)
Rather than using a linear scale to represent population, one might associate colors with layout patterns. 16 different colors would support a 2x2 block.
A 3D game of life might use color to represent the state of different layers. One could assign one color channel to each of three slices. (One could descend and ascend through the 3D habitat.)
@Ken: We agree, the wording is in the way. I meant that once a chip is chosen -- there is only one chip -- and I assumed(badly) that the design was clean before the chip was chosen. Then is when there is a distribution of path lengths and some will have a lot more positive slack than others and nothing to be done about it UNLESS the tools and technology can use lower speed/power for those paths.
Ken_Chapman 7/17/2012 10:06:27 AM User Rank Expert
Re: Why PicoBlaze?
@Karl
I totally agree with your last paragraph but I have to disagree when you say "There is one and only one chip" because FPGA's come in different sizes. Not surprisingly you pay more for a bigger device so it is desirable to implement things smaller. In some cases it may only require a fraction of the design to be implemented more efficiently in order to squeeze it into the next smallest device and save a significant amount of cash. However, I prefer to live the expression; "look after the pennies and the pounds will look after themselves" (substitute cents, dollars and Euros as appropriate). All too often I've seen designs in which it is the accumulation of innocent little bits of logic operating 'slowly' that have consumed so much of the resources. A quick tidy up may allow it to squeeze into the next smallest device but often a full design review can more than half the size of an implementation. Of course, your statement is correct once you are in the smallest device.
@Ken: Good comments. Here is one that to me is a bit trivial --
"Combine that with any occasion in which you clock or enable that state machine at a rate slower than the device is capable of supporting and it represents an inefficient use of the silicon." There is one and only one chip and the speed may be just the technology, or may be needed for some other function.
Any design has critical paths which are a minority so everything does not need run at top speed. Therefore the efficient use of silicon based on speed is not key.
The state machine enphasis is very important. When you consider that a program can be "single stepped" that can lead to a program is a state machine and each statement/compound statement is a state determined by decision statements that either do the next sequential statement or the next non-sequential statement. The compound statement can be a block of statements delimited by curly braces, begin/end pairs, or whatever.
Given this, source code can be parsed and a state machine implementation used to execute the source code far more efficiently than any CPU ISA.
PicoBlaze is tiny and its speed is related to the chip speed, so when it does the job, great. When it does not, then the only recourse is not just a custom design.
Max Maxfield 7/16/2012 9:46:37 AM User Rank Blogger
Re: Why PicoBlaze?
@Ken: Great input -- thanks for this -- certainly something to mull over.
What I'm thinking is after Paul creates his PicoBlaze version of the Game of Life, maybe we look at a mini-state machine per cell approach, just for the heck of it...
The PicoBlaze does not come with the ability to single step, set breakpoints, and monitor registers and memory, so we need a way to get around these limitations.
As opposed to rebuilding the entire design every time we "tweak" the code we wish to run on the PicoBlaze soft microcontroller core, we can simply use a JTAG tool to load our executable code directly into the FPGA's on-chip memory.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
