FPGA Central

Hi all,

I'm doing few tests in these days with the PicoBlaze and it seems to
work just fine. Now, in my project, where a Spartan3 has to deal with a
DSP through a serial spi-like communication to reply on different
request that may arrive, do you think could be woth using with a
PicoBlaze as a supervisor? I mean, the FPGA could reveive a request to
read from its inputs, or to write on its output, or to read a
temperature from an spi-sensor and the send it to the DPS, or to read
the values from quadraure decoder...
Picoblaze or vhdl from scratch in your experienced opinion?
I'm making some considerations by myself now, but I'd like to hear
comments from you too.

Thanks,
Marco

Marco schrieb:
> Hi all,
>
> I'm doing few tests in these days with the PicoBlaze and it seems to
> work just fine. Now, in my project, where a Spartan3 has to deal with a
> DSP through a serial spi-like communication to reply on different
> request that may arrive, do you think could be woth using with a
> PicoBlaze as a supervisor? I mean, the FPGA could reveive a request to
> read from its inputs, or to write on its output, or to read a
> temperature from an spi-sensor and the send it to the DPS, or to read
> the values from quadraure decoder...
> Picoblaze or vhdl from scratch in your experienced opinion?
> I'm making some considerations by myself now, but I'd like to hear
> comments from you too.

Picoblaze offers a lot of bang for the buck. Especially in S3, where you
have 1k program space. Since it sounds like you have to handle a lot of
task which are not too time critical, I would go for the Picoblaze.
Also, odification in the control algorithm are done much easier in the
picoblaze than in a FSM.

Regards
Falk

Marco wrote:
> Hi all,
>
> I'm doing few tests in these days with the PicoBlaze and it seems to
> work just fine. Now, in my project, where a Spartan3 has to deal with a
> DSP through a serial spi-like communication to reply on different
> request that may arrive, do you think could be woth using with a
> PicoBlaze as a supervisor? I mean, the FPGA could reveive a request to
> read from its inputs, or to write on its output, or to read a
> temperature from an spi-sensor and the send it to the DPS, or to read
> the values from quadraure decoder...
> Picoblaze or vhdl from scratch in your experienced opinion?
> I'm making some considerations by myself now, but I'd like to hear
> comments from you too.
>
> Thanks,
> Marco

The PicoBlaze is absolute gem and easy to use. At one block ram and
under a hundred slices in size it is not that big, but can do quite a
lot of work. One of the things that I like about it is that I can
change its program without having to resynthesize and place and route
again.

They are very well suited for large state machines that need to deal
with events at microsecond or slower rates. We have used them on a
V4FX with the TEMAC to offload a custom IP/UDP protocol at GIGE rates,
on a Spartan3e to read the file system on a MiniSD card, and on a V2 to
run the adapation algorithm of some adaptive filters. In all of these
applications, I think that it was simpler to write the assembly code
than it would have been to write a VHDL/Verilog state machine, and
probably used less resources as well.

On the Xilinx web site, there is a fourm dedicated to the PicoBlaze
with some links to PicoBlaze programs for IIC, serial ports etc that
may be of interest to you as examples.

Regards,

John McCaskill

>I'm doing few tests in these days with the PicoBlaze and it seems to
>work just fine. Now, in my project, where a Spartan3 has to deal with a
>DSP through a serial spi-like communication to reply on different
>request that may arrive, do you think could be woth using with a
>PicoBlaze as a supervisor? I mean, the FPGA could reveive a request to
>read from its inputs, or to write on its output, or to read a
>temperature from an spi-sensor and the send it to the DPS, or to read
>the values from quadraure decoder...
>Picoblaze or vhdl from scratch in your experienced opinion?
>I'm making some considerations by myself now, but I'd like to hear
>comments from you too.

In general, if you can easily turn a hardware problem into software,
that's probably the right thing to do.

How many states will your system have? Will a circles and arrows
drawing of your state machine fit on a page? For anything bigger
than a page, I try hard to turn it into software. I find it much
easier to deal with a complicated problem when thinking of it
as software.

Do you have lots of multi way branches? Do you have enough time
to turn them into a chain of two way branches? ...

The main disadvantage of using software is that you have to
setup and maintain a software development environment in addition
to your FPGA environment. That's usually a lot easier after you
have done it the first time.

Another answer is to do (or try) both and see which one you like better.



--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.