10-06-2014 03:54 AM
Is Picoblaze possible from within a XC95288XL ? These are similar to the CoolRunnerII family and some aspects of Picoblaze are possible from within these devices - hence my question. Thanks.
10-06-2014 08:35 AM
I wasn't involved in PicoBlaze for CoolRunner and I have not become familiar with it since it was created. It depends how it is defined, but theoretically, it could be used in a 9500 device as well.
However, I think it should be appreciated that CPLD devices do not contain Block Memory or distributed RAM. These are the two principle features that make PicoBlaze so small and efficient in the FPGA devices. Without them, a PicoBlaze in a CPLD can become rather large and impractical. There are still some CPLD applications that benefit from a microcontroller approach but they should be seen more as special cases than the norm. So before you pursue this route much further, have a read of the PicoBlaze for Cool Runner documentation and consider just how much of your XC95288 device would be used to implement a program ROM as well as the processor itself. You may suddenly see the appeal of a small FPGA.
10-07-2014 12:25 AM
Thanks for the reply Ken. Perhaps I should give a little more explaination. I perform test development of product and am currently looking at possible BIST for some of our older product. I was wondering if I can implement picoblaze in an XC95288 I would then be able to add the uart block so that I can then access spi flash and create an interactive test routine. I've already performed this on another product using the Spartan 3A devices. Since it is for test purposes only I am not concerned about filling the CPLD - however if it cannot have RAM blocks I don't see how picoblaze would work ? I shall look at the Coolrunner info again.
I have created processor test applications on standalone micros before but this idea of soft-processor is new to me and I am still learning about it. I also have a background in boundary scan development and can see the potential of merging the two techinques to produce efficient and powerful test / manufacturing procedures.....
10-07-2014 03:30 AM
I’ve always been a big fan of exploiting reprogrammable devices for test purposes so I totally agree with your motives. In fact, that is where ‘PicoBlaze’ started in the early 90’s. Back then, the FPGAs weren’t very big, lacked Block Memory and were really too expensive for my first ‘PSM’ macro to be practical. However, the whole device was free to be reused for test purposes and then a processor macro was a quicker way to implement experiments.
Ideally a program is stored in a ROM. A Block Memory (BRAM) can be configured to act as a ROM providing storage for 1K instructions in a Spartan-3 device. In a CPLD a ROM can be looked at as just being a truth table that is implemented by the ‘product terms’ architecture. It’s a pretty inefficient way of doing it but that’s all that there to do it. The number of products, and hence macro-cells, required will depend on both the size of the program and the actual pattern of instructions! Let’s face it, you’ll need to be writing some fairly small programs (Note fig.2 in XAPP387 shows an 8-bit address indicating a maximum program size of 256 instructions).
KCPSM3 has 16 general purpose 8-bit registers. These are implemented by just 8 Slices of distributed RAM in a Spartan-3 device. In contrast, such a register file requires 128 flip-flops and some serious multiplexers to implement in a CPLD and that’s a lot of macro-cells. For this reason XAPP387 indicates that there are only 8 registers in the CPLD macro. Likewise, the call and return stack of the KCPSM3 macro in a Spartan-3 device has 31 levels but this is limited to just 4 levels in the CPLD version but that is probably adequate for small programs.