Implement ARM cores on a FPGA chip?

On Oct 2, 8:36=A0pm, LucienZ <lucien.zh...@gmail.com> wrote:
> On Oct 1, 8:53=A0pm, Jon <j...@beniston.com> wrote:
>
> > > But I've seen
> > > one design article (carried out at NXP, the Netherlands) that claims
> > > they have implemented two ARM926EJ-S processors on a Xilinx Virtex 4
> > > FPGA chip. I am wondering what technologies enable this
> > > implementation.
>
> > The same technologies that enable any other CPU to be put on an FPGA.
> > The ARM926EJ-S is no different, except that it will be a lot bigger
> > and a lot slower, than other FPGA specific CPUs.
>
> > > 1. How to implement one or more such ARM926EJ-S cores on a FPGA chip
>
> > Talk to ARM, but you probably can't afford it.
>
> > Jon
>
> Thank you Jon. In my understanding, 'hard' processor cores on an FPGA
> are not using the FPGA fabric. They are made on the same die with FPGA
> fabrics by FPGA vendors e.g. PowerPC cores on Virtex products. Here
> the FPGA fabric is working as glue logics for interconnections or
> customized peripherals. Here I guess the PowerPC core on Virtex is not
> the same concept like Microblaze cores on Virtex. Am I right?
>
> So far I did not see a FPGA chip on market that contains a hardened
> ARM core on the same chip, and that is why I am asking this question.
>
> In your answer, what do you mean by 'FPGA specific CPUs'? And can you
> tell me more words on your mentioned 'technologies'?

Hard processor cores in an FPGA are essentially similar to the same
processor core in an ASIC and probably have similar performance.
They also increase the price of an FPGA by more than you would
typically
spend for the standard processor in a chip by itself.

FPGA-specific processors like NIOS and MicroBlaze were designed
for implementation in an FPGA and theerfore typically perform
better in that FPGA than a market-standard device like ARM.  The
measure of performance usually includes the percentage of the
FPGA fabric used, so in other words you'd have a much easier
time placing 4 MicroBlazes in a Virtex 5 than 4 ARM cores.

Finally there are other devices out there that start from a
fairly high performance processor but provide some form of
FPGA-like additional fabric to extend your instruction set.
Check out Stretch (http://www.stretchinc.com) for an example
of this.  Also for general purpose image processing you could
use a farm of DSP's that were designed to connect together
like sharc chips from Analog Devices.  Another approach that
woks fairly well is to use "media processors" designed for
set-top boxes, which can be very inexpensive.  An example
would be the PNX15xx series from NXP.  In the end the performance
of any multiprocessor approach will be limited by the interconnect
speed and your ability to divide up the process with the least
interconnect bandwidth requirements.

Regards,
Gabor

LucienZ wrote:

> Do you have more suggestions for doing such a verification work?

I use python to test algorithms.
It's free and easy to use.

     -- Mike Treseler

LucienZ <lucien.zhang@gmail.com> wrote:

>On Sep 30, 10:15=A0pm, Mike Treseler <mtrese...@gmail.com> wrote:
>> LucienZ wrote:
>> > Hi everyone, I am a master student and this is my first post in this
>> > group. My research group is looking for a multicore embedded platform
>> > for deploying an in-house developed computer vision algorithm. I've
>> > checked some available development boards and now still weigh the
>> > ideas in my mind.
>>
>> I might verify that the algorithm is amenable
>> to parallel processing by borrowing a rack
>> of servers before I took on building
>> the same thing on an fpga.
>>
>> =A0 =A0 =A0-- Mike Treseler
>
>Thanks for your advice Mike! There are some obvious sections in the
>algorithm that I believe can be parallelized e.g. for-loops that
>process each line (independent on other lines) of the pixel matrix. I
>also plan to do some verification work before a real implementation on
>FPGAs. But server racks may not be easily accessible for me. So I am
>thinking about some tools like Pthread or OpenMP... (not used before).
>
>Do you have more suggestions for doing such a verification work?

Why does verification takes a rack of servers? You can verify at any
speed. Just create an input dataset to test the extremes, process it
and examine the output. You can use the same dataset you created to
verify an FPGA implementation as well.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

On Oct 3, 11:10=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
> LucienZ <lucien.zh...@gmail.com> wrote:
> >On Sep 30, 10:15=3DA0pm, Mike Treseler <mtrese...@gmail.com> wrote:
> >> LucienZ wrote:
> >> > Hi everyone, I am a master student and this is my first post in this
> >> > group. My research group is looking for a multicore embedded platfor=
m
> >> > for deploying an in-house developed computer vision algorithm. I've
> >> > checked some available development boards and now still weigh the
> >> > ideas in my mind.
>
> >> I might verify that the algorithm is amenable
> >> to parallel processing by borrowing a rack
> >> of servers before I took on building
> >> the same thing on an fpga.
>
> >> =3DA0 =3DA0 =3DA0-- Mike Treseler
>
> >Thanks for your advice Mike! There are some obvious sections in the
> >algorithm that I believe can be parallelized e.g. for-loops that
> >process each line (independent on other lines) of the pixel matrix. I
> >also plan to do some verification work before a real implementation on
> >FPGAs. But server racks may not be easily accessible for me. So I am
> >thinking about some tools like Pthread or OpenMP... (not used before).
>
> >Do you have more suggestions for doing such a verification work?
>
> Why does verification takes a rack of servers? You can verify at any
> speed. Just create an input dataset to test the extremes, process it
> and examine the output. You can use the same dataset you created to
> verify an FPGA implementation as well.
>
> --
> Failure does not prove something is impossible, failure simply
> indicates you are not using the right tools...
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"If it doesn't fit, use a bigg=
er hammer!"
> --------------------------------------------------------------

Thank you very much Nico and gabor for your enlightening words.
It is not mandatory for me to implement ARM cores on a FPGA chip. Just
like gabor said, MicroBlaze and Nios could perform better than soft
ARMs. I might also start with customized hardware design using HDL,
for better performance on FPGAs. But I think the algorithms will
evolve, so this approach is not flexible nor scalable enough. Moreover
I also want to contribute something to the multicore architecture
research; all these make me think of a
processor-based design.

After my prototyping there is indeed an ASIC (or say ASSP) plan (an
ASIC designer will come in 2010). And I also hope he/she can inherit
more from my experience. So far the bridging between FPGA prototyping
and ASIC design is still not very clear to me. If I start with soft
processor cores on FPGA, then I also hope to see an ASIC equivalence
(architecture, instruction set etc.). My premature thought is that, if
I can prototype a FPGA solution with the performance of 10 frames per
second, when it goes to ASIC, we can expect a 20-fps result
(possible ???). That's why the popularity of ARM makes me think about
ARM cores on FPGA. I agree Microblaze and Nios perform better on
FPGAs, but I doubt the availability of their ASIC implementation.

Gabor says "Hard processor cores in an FPGA are essentially similar to
the same processor core in an ASIC", I agree, and I am looking for the
cores available for both FPGA and ASIC. But do they also "probably
have similar performance"? I think ASICs can run much faster than
FPGAs and I expect a nice speedup when it comes out from our foundry.

> cortex m3
> is easy obtainable a license for 1000 instances cost 2500 $
>
> this IS common knowledge i assumed you know this
>
> Antti

Is that Cortex-M3 license targeting ASIC fabrication or what?
Sorry for not sharing the common knowledge; I am really a dummy here...

On Oct 4, 7:55=A0pm, LucienZ <lucien.zh...@gmail.com> wrote:
> > cortex m3
> > is easy obtainable a license for 1000 instances cost 2500 $
>
> > this IS common knowledge i assumed you know this
>
> > Antti
>
> Is that Cortex-M3 license targeting ASIC fabrication or what?
> Sorry for not sharing the common knowledge; I am really a dummy here...

not that is for 1000 instances in Altera Cyclone III
asic licenses are different

Antti

Nico Coesel wrote:

> Why does verification take a rack of servers?

It doesn't.
That would be easy to arrange for me,
but probably not for Lucien.
Python might be more practical alternative.

My advice to Lucien is to verify that the parallel algorithm
actually works and has the expected advantages before even thinking 
about the target hardware.

    -- Mike Treseler

On Oct 4, 7:24=A0pm, "Antti.Luk...@googlemail.com"
<antti.luk...@googlemail.com> wrote:
> On Oct 4, 7:55=A0pm, LucienZ <lucien.zh...@gmail.com> wrote:
>
> > > cortex m3
> > > is easy obtainable a license for 1000 instances cost 2500 $
>
> > > this IS common knowledge i assumed you know this
>
> > > Antti
>
> > Is that Cortex-M3 license targeting ASIC fabrication or what?
> > Sorry for not sharing the common knowledge; I am really a dummy here...
>
> not that is for 1000 instances in Altera Cyclone III
> asic licenses are different
>
> Antti

Thanks Antti. What I concern is:
Suppose that I've licensed 1000 'instances', and now I want to use 4
of them for my design.
Does it mean I have to pick up 4 FPGA chips, with exactly one M3 on
each chip?
Or
I can deploy 4 instances on only one FPGA chip, using tools like
Quartus?

I see Cyclone solutions based on Cortex-M1, but I think the M3 is for
ASICs. It's just a little bit confusing...



---
To Mike, I will follow your advice and start with a verification and
evaluation step. The idea of going embedded is from my bosses...and
now I am forced to make my brain work in parallel: rewriting the
algorithm as well as looking for an embedded architecture for it :).

On Oct 4, 10:58=A0pm, LucienZ <lucien.zh...@gmail.com> wrote:
> On Oct 4, 7:24=A0pm, "Antti.Luk...@googlemail.com"
>
>
>
> <antti.luk...@googlemail.com> wrote:
> > On Oct 4, 7:55=A0pm, LucienZ <lucien.zh...@gmail.com> wrote:
>
> > > > cortex m3
> > > > is easy obtainable a license for 1000 instances cost 2500 $
>
> > > > this IS common knowledge i assumed you know this
>
> > > > Antti
>
> > > Is that Cortex-M3 license targeting ASIC fabrication or what?
> > > Sorry for not sharing the common knowledge; I am really a dummy here.=
..
>
> > not that is for 1000 instances in Altera Cyclone III
> > asic licenses are different
>
> > Antti
>
> Thanks Antti. What I concern is:
> Suppose that I've licensed 1000 'instances', and now I want to use 4
> of them for my design.
> Does it mean I have to pick up 4 FPGA chips, with exactly one M3 on
> each chip?
> Or
> I can deploy 4 instances on only one FPGA chip, using tools like
> Quartus?
>
> I see Cyclone solutions based on Cortex-M1, but I think the M3 is for
> ASICs. It's just a little bit confusing...
>
> ---
> To Mike, I will follow your advice and start with a verification and
> evaluation step. The idea of going embedded is from my bosses...and
> now I am forced to make my brain work in parallel: rewriting the
> algorithm as well as looking for an embedded architecture for it :).

my mistake M1 of course

Antti

Algorithm development on FPGAs for maximum speed do not normally use
'cores' like you're talking about.  If your algorithm does make it to
an ASIC, it VERY likely should not be in the form of a multi-core
platform.  At least, not in the traditional processing core sense.

FPGAs are good at direct hardware implementation of algorithms.
They're pretty slow at simulating processors running embedded
software.

Everyone seems to be discussing the best soft core to put in FPGAs,
but the whole premise of using processor cores in FPGAs like you're
talking about sounds flawed to me.

The ultimate speed is going to come from coding your algorithm itself
in FPGA or ASIC gates.  Don't waste FPGA gates to simulate a
processor, which in turn runs normal embedded software code (very
slowly).  Directly implement your algorithm in hardware.

For vision algorithms, you could try Matlab-to-hardware or C-to-
hardware workflows.  However, for the best speed (and the most vendor
independence) you're likely to need to write a hardware algorithm
description in VHDL or Verilog.

You would normally code a VHDL/Verilog module that implements your
algorithm in hardware, and instanciate as many copies of that module
as will fit in an FPGA.  You might then include a single soft
processor core to manage the whole thing.  That, or you'd simply
provide an external interface to a normal processor or DSP making it
look like a memory mapped device or FIFO.

If your ASIC is just going to be a bunch of processing cores, you
could probably do it all MUCH more cheaply using some NVIDIA GT200-
based video card processing using CUDA (or ATI's stuff...  I'm not
trying to play favorites...  it's just what I know).  You're going to
get way more processing speed that way.  You're very unlikely to do
better than NVIDIA does.  (The modern video card GPUs can now do
generalized parallel processing an order of magnitude (or two!) faster
than the CPU)

You might also consider a small Linux computing cluster.  That's a lot
easier to write code for.