Showing results for 
Show  only  | Search instead for 
Did you mean: 
Xilinx Employee
Xilinx Employee
Registered: ‎09-05-2007

PicoBlaze FAQ – What are typical applications?

PicoBlaze FAQ – What are typical applications?




Please note that this FAQ was written when the mainstream PicoBlaze was KCPSM3 optimised for the Spartan-3 Generation architecture. From late 2010 onwards the KCPSM6 version of PicoBlaze optimised for use with the Spartan-6, Virtex-6 and all 7-Series devices was released. Whilst the fundamental descriptions contained in this FAQ also apply to KCPSM6 it should be recoginised that KCPSM6 is even more efficient and occupies only 26 Slices of the newer devices.




Ultimately you could always use dedicated hardware to do implement the same functionally as PicoBlaze. What PicoBlaze deliverers in 96 slices and one BRAM is the ability to describe functions using assembler language and therefore to naturally include memory and time shared logic in a design which can be extremely efficient.


The art is to recognise when PicoBlaze does and does not make sense although this should also become a second nature very quickly. The fact that PicoBlaze is 100% embedded means that you can decide to include it or remove it at any stage in your design process without being concerned about how this will effect your printed circuit board. It is extremely common for users to report that they only considered using PicoBlaze once 80% of their design was complete so don’t feel that there is any urgency to make a decision; I’m confident you will find a use for it and want to use it anyway J


The PicoBlaze macro is supplied with the name KCPSM3 where ‘PSM’ stands for ‘Programmable State Machine’. In the most generic sense we can consider just about every function and application as being a finite state machine (FSM). Of course some state machines are very simple but others are so complex we don’t even like to think of them as being state machines anymore. With this range in mind, let’s look at where PicoBlaze can be used and make designs easier to implement. To do this I will consider size, performance and methodology one at a time…..





PicoBlaze is 96 slices, but you would expect to add at least some interface logic to that. Let me add a 4:1 input multiplexer (i.e. read 4 inputs of 8-bits = 32 inputs) and 4 output registers (i.e. 4 × 8-bit registers = 32 outputs) to give something representative of a complex state machine. Think about it, 32 outputs signals and 32 input signals is quite a lot of for a state machine. That would bring us up to 120 slices.


Then you really need a BRAM for the program (although I have used distributed ROM of a few occasions when the program has been small). Looking at a Spartan-3E device in FPGA Editor gives away that a BRAM is 4 CLBs high and 4 CLBs wide. So a BRAM (and the multiplier) is actually the silicon equivalent of 64 Slices. Given that a normal FSM is implemented in pure logic, then we really could say that a practical PicoBlaze design is the equivalent size to ~184 slices.


You can certainly implement a very big complex state machine for 184 slices (up to 368 flip-flops before including SRL16E’s). In fact, I think that is too big for any single state machine, so it would probably be a set of smaller state machines along with separate and counters, comparators etc.


So in terms of size, you can see that PicoBlaze will certainly starts to be an attractive proposition if it helps replaces more than 150 slices. If you have unused BRAMs then it will become even more attractive.





The great thing about hardware is that it is fast. Not only is it fast, but each piece of logic runs in parallel and can be working independently. So a key starting point in the decision process is to look at the speed of the events which the state machine has to observe, the speed at which it must react and the speed at which control outputs.


PicoBlaze executes one instruction every 2 clock cycles. It can support clock frequencies up to ~100MHz in a Spartan-4 or up to ~200MHz in a faster Virtex device. If we use the example of a Spartan-3E on a Spartan-3E Starter Kit fitted with a 50MHz clock oscillator then that means PicoBlaze can execute 25 million instructions per second.


If you have a state machine that needs to observe and control signals at 5MHz, then forget PicoBlaze. It can not do much in 5 instructions. However, if I connect a UART receiver operating at a baud rate of 9600, then PicoBlaze would only receive a character every 1.04ms. This means that PicoBlaze would have time to execute 26,041 instructions between each character and you could do a lot of processing, decision making and control with that many instructions. In contrast, dedicated hardware would probably be sitting there doing nothing whilst it waited for the next character to arrive.


So clearly PicoBlaze is ideal when you have so much time that you do not even need to think about execution time. As a general rule, most programs would execute several hundred instructions per iteration and that implies a state machine control rate in the range 125KHz to 300KHz depending on device and speed grade. Higher performance functions or more time critical operations are candidates for hardware but these may be peripherals to PicoBlaze which is left to manage anything slower. PicoBlaze has an interrupt input which can be used to respond to important things in a maximum of 5 clock cycles and this is another useful technique for handling some time critical instances.


The UART macros provided with PicoBlaze are the perfect example of using a hardware and software combination to bridge the fast and slow performance domains. PicoBlaze could implement a UART itself by executing a software description of the ‘state machine’ which is a UART. However, the asynchronous nature of the receiver means that it would become pre-occupied with the task of detecting the leading edge of the start bit which is a significant burden considering no communication is actually taking place at that time. So having a hardware UART state machine means that PicoBlaze is free to work at the character rate allowing lots of time to perform other tasks. The inclusion of a 16-byte FIFO buffer in the UART macros provides even greater isolation between the domains because now PicoBlaze does not even have to reach at the character rate.





This is really the key one. Simple state machines are quiet easy to write in HDL. You can test them and even if you get them wrong they are straightforward to fix. Once a state machine becomes complex it is hard to keep track of everything and soon it becomes the piece of code no one wants to touch in case it breaks!


Ultimately a state machine is a sequential machine. A hardware description language (VHDL or Verilog) is generally used to describe parallel structures. Therefore such languages make the description of sequential or sequenced events less natural to describe and also result in implementations which are relatively large. So in moving a state machine into PicoBlaze you also move your description to assembler code which is naturally sequential. Although it sounds strange, users often report how they consider assembler to be like a ‘high level’ language because it now fits with the task they are describing and naturally leads to the time sharing logic which exploits memory.


Consider how you would implement a real time digital clock. It would be relatively easy to implement hardware state machine in HDL which divides the system clock frequency down to seconds, minutes and hours and displayed them on a 7 segment display. But now consider how much complexity it adds to your design if you add a 2 press-button interface that is supposed to enable you to set the time; not only do you need to set the time in the state machine, but you need the display to give you helpful feedback whilst you are doing it. Again you might get that to work in a hardware design but how long will it take you? When you’ve finished that, consider how to add an alarm time; now you need to be able to set the time for the alarm whilst maintaining the existing time.


Not only would the full digital clock become rather big because of all the states, but also because of all the different ways the display can be connected to it. Most of all your HDL is going to be very hard to write and very complex in itself. At this point, assembler code looks far more natural and manageable and each of the states (seconds, minutes hours for actual time and alarm time) map nicely into PicoBlaze registers and scratch pad memory.


In the end, if it feels right, then it probably is right. Of course it would always be worth checking the size at some point and you would probably use some hardware to provide PicoBlaze with interrupts at one second intervals so that the assembler code could be independent of real time.



Typical Applications


So what applications are the appropriate mixture of size, performance and methodology that make PicoBlaze viable and desirable? Here are some examples and please do feel free to share others in this thread.


LED flasher.

PWM control and even generation (KHz PRF for motors and brightness control).

Switch monitor.

UART interface and simple command/status terminal.

LCD character module display interface and control.

SPI master (i.e. FLASH controller for Spartan-3AN).

I2C master.


Audio DSP processor (typically up to 48KHz sample rate and may utilise a hardware multiplier as a peripheral)

DTMF tone telephone dialer including sine wave generation (8KHz sample rate)

System monitoring (e.g.  temperature monitor and fan control).

Motor control.

Rotary encoder interface.

Calculator for frequency synthesizer.

Calculator for filter coefficient generation.

Emulation of a different micro controller.

PID control.

Mouse/Keyboard interface.

Keypad scanner.

Power supply monitoring and control.

Servo control.

Built-in test equipment (on-chip monitor).

Configuration management (ICAP port)

Design Authentication Processor.

Implementing peripherals for MicroBlaze or PPC.

Interrupt controller for MicroBlaze or PPC.



I hope this helps you and others decide when PicoBlaze is right for you.




Ken Chapman

Ken Chapman
Principal Engineer, Xilinx UK
0 Kudos
4 Replies
Registered: ‎09-13-2007

is USB possible by using pico....
0 Kudos
Registered: ‎03-17-2009

How do we design a DTMF RECIEVER using PicoBlaze ..?


Thanks & Regards,

viru jawoor

Best Regards,
VIru Jawoor
0 Kudos
Registered: ‎12-22-2013

how can i generate a SPIMASTER using pico blaze microcontroller?

0 Kudos
Xilinx Employee
Xilinx Employee
Registered: ‎09-05-2007

The KCPSM6 package contains an SPI reference design (Post Configuration Access To SPI Flash) and there are several reference designs provided for the Spartan-3 Starter Kits in which KCPSM3 implements SPI (i.e. See 'Features Used' column on the following site... ).

Ken Chapman
Principal Engineer, Xilinx UK
0 Kudos