PicoBlaze

[sergemoutou]

MicroBlaze is not so easy to use as picoBlaze. We use picoBlaze only with the ISE webpack : every student can make homework with a ISE webpack.

MicroBalze is harder to use : the XPS and SDK are not part of ISE webpack (I am not sure for the SDK under Linux)

Here is an other gap.

Place and number of LUTs are effectively important but I think that microBlaze was conceived in the spirit of speed and extendable with professional PLB bus. It is its place even if we have used it for a low speed video game where it spends most of the time to wait : not a good place for such a processor !

Because of this gap I use picoBlaze and a free AVR core : only webpack is necessary. Compiling is done with AVRSudio... Every student can install all the software for free.

Please don't think I want all for free. I can understand Xilinx policy with microBlaze. I just say we need both policies  free and no-free and the free one has to evolve.

[goran]

Hi,

Did you read the datasheet that I linked?

It's a prepackage MicroBlaze with tiny peripherals and a IO bus delivered through CoreGen. It's part of WebPack.

It's free and you don't need XPS or SDK. 

Göran

[galere1]

I really think the prepackaged Tiny Microblaze is a great thing, and will become a excellent replacement of Picoblaze as it is a 32bits processor and as the low cost FPGAs come with more and more FFs .

But Xilinx should do an effort regarding documention and the 'get started' with Microblaze (How to compile and to load my first Microblaze led blink C program).
The good point for the Picoblaze is we can find a lot of concret examples.

Laurent

 http://www.amontec.com

 Amontec JTAGkey-2 High-Speed USB JTAG Interface Dongle

[vanmierlo]

---

Including an offset to a pointer in your architecture is a nice feature but it also implies the inclusion of logic in the  path to the memory address inputs. Whilst an adder is physically quite small, the corresponding increase in propagation delay would result in a lower clock frequency performance.

---

There already was a long discussion about this in this previous thread including my modification to the original KCPSM6 code for it:
http://forums.xilinx.com/t5/PicoBlaze/KCPSM6-is-Here-Download-it-now/td-p/100430/page/2

My conclusion was that it costs no performance, but only some resources.

With this extension of accessing scratchpad memory with a small index it becomes possible to calculate the address of a variable first using the ALU and then access it to perfom the requested operation. It is also usefull for small stack offsets and struct offsets. With this extension I do not see the need for ADDN anymore.

Maarten Brock

[vanmierlo]

---

Why do we employ KCPSM3 instead of KCPSM6?

3) as we perform all our development effort in Linux OS, we needed a linux-enabled assembler. Until our compiler tool-chain was completed, we used the open-source picoasm. I think there was no assembler for KCPSM6 that can be used in Linux.

---

Well, http://code.google.com/p/pblazasm/wiki/PicoblazeSix is around for quite some time now. It can be compiled for windows and linux AFAIK.

---

What is missing in PicoBlaze to enable better compilers?

The COMPARECY instruction in KCPSM6 is a fine step, but what I've run into when implementing the compiler is an efficient support for software stack spilling. Right now, you have to use 3 instructions (LOAD, ADD, STORE) to push/pop a single value from a software stack. Moreover, this 3-instruction 'stack spilling code' is not inert: it modifies FLAGS due to the ADD instruction. This turned out to to be a great problem for the LLVM compiler framework, because the optimizing compiler sometimes wants to insert the spilling code in the middle of an ADD->ADDCY chain (or SUB->SUBCY), hence potentially corrupting processor state.... All this is explained in detail in the documentation: http://sp.utia.cz/smecy/pblaze-cc-v2/Users_Guide/index.html#chap-Users_Guide-PB3A 

---

For small cores with no (efficient) data stack it can be very effective to let go of one C requirement that is often not needed: reentrancy. This is what SDCC (http://sdcc.sourceforge.net) does by default for many of its targets. It allocates all local variables to fixed memory places making them something like static variables. Overlaying tries to reclaim some of the wasted memory. If the user really needs reentrancy it can be added with the function modifier __reentrant or a global option. Is the pblaze-cc doing something similar or are all function reentrant and thus all parameters and local variables placed on the stack?

Maarten Brock

SDCC Developer

[necago]

I think the ADDN instruction is needed even when the reg+offs addressing mode is available as we have to cater for the case when a large offset cannot be folded into an instruction (in our case when the offset is negative or bigger than 15).

I did not know about the pblazasm project (or can't remember now). Funny that google did not point us there, and it is located in their site...

In pblaze-cc functions are re-entrant as usual in C. Function parameters are first passed in registers (s0-s3) and then on stack, hence stack usage is not a big issue (in terms of both data and instruction memory resources). Similarly local variables are allocated first in registers (s4-sC) and spilled to stack on demand.

Jaroslav

[sergemoutou]

Sorry goran_bilski

I missed your datasheet, and it sounds very interesting : the kind of processor I was looking for. I will have a look as soon as possible.

[mediatronix]

Hi Maarten:

This one is based on SDCC:

Link Removed see the link in the next post

It should be more a suitable Picoblaze cc; haven't tried it yet.

groet,

Henk van Kampen

[mediatronix]

sorry, try this:

http://www.fit.vutbr.cz/~meduna/work/doku.php?id=projects:vlam:pbcc:pbcc