From: -jg on
On May 29, 11:46 pm, Mike Harrison <m...(a)whitewing.co.uk> wrote:
>
> The XMOS parts may fill a few gaps here.

Yes, nice looking silicon - and a good direction
and concept.

We did a candidate design on these, and needed
the newest 500MHz device to meet timing.

However, their docs were quite poor, especially around assembler
which you DO have to use on tight timing stuff.
When I suggested some learning pathway improvements, their response
was dismissive, which I guess explains how their docs/files came to be
sub-standard !!

Icc is not low, but it is at 1V, so you need to add a decent sync
smps to the budget.

-jg
From: rickman on
On May 29, 3:54 am, -jg <jim.granvi...(a)gmail.com> wrote:
> On May 29, 9:12 am, rickman <gnu...(a)gmail.com> wrote:
>
>
>
> > I wonder why the MCU market is so different from the FPGA market?
> > Seems the MCUs are all trying to get smaller and smaller with more and
> > more in the package. FPGAs seem to demand high pin counts and so they
> > either are in huge packages or BGAs with very fine ball pitch. Is
> > there just no real market for medium capacity FPGAs in low pin count,
> > cost effective packaging? I would love to get up to 10,000 LUTs in a
> > 48 TQFP or even a similar QFN. At this time I would settle for even
> > 1,000 LUTs in a 32 to 48 pin TQFP or QFN.
>
> > Rick
>
> Good question - some of the tier-2 players, do have offerings in QFN,
> but the main players I think have become victims of their own success.
>
> To open new markets, leading edge FPGAs have to get ever more dense,
> and that pushes into BGA packages.
> Once they are over the BGA hurdle, it is not easy to get back. Some
> systems NEED those low L paths, and high layer counts.
>
> Those that want a TQFP48, also want a uC area price, and there is not
> enough revenue, to fund the development.
> Another indicator, is CPLDs have seen remarkably little new R&D over
> the last 5 years.
>
> The Cypress PSoC are interesting, but their published prices (peak
> over $20) really charge a premium above a CPLD+Generic uC - so they
> target a niche, not the mass market.
> -jg

I've been looking hard at the PSoC devices as well as the Actel Fusion
parts. Both are a bit pricey, the Fusion is way pricey. The PSoC
devices aren't really all that programmable from what I have seen.
Their logic blocks are "lumpy", larger grain than conventional LUTs
and not as general purpose. Their analog is rather limited too as is
the Fusion analog.

To combine with an MCU, the CPLD doesn't really need to be too
elaborate. But it needs to have some bulk. Just adding 10 or 20
macrocells doesn't do the job for me. I'd like to see 500 to 1000
four input LUTs (with half as many registers and the usual FPGA stuff
like some carry chains) along with a Cortex MCU. Heck, if you add a
reasonable size of FPGA you could leave out all the digital
peripherals since they can be added as needed. When was the last time
you needed even half the peripherals on an MCU? By keeping the pin
count to the same number MCUs would otherwise have, the testing time
is minimized and the FPGA chip area doesn't add a lot to the cost.

But the MCU makers don't have patents, tools or IP for FPGA work and
the FPGA makers are happy with their 1000 pin BGAs.

Rick
From: rickman on
I'm not that impressed with the XMOS parts. Yeah, its nice having
eight threads running at once, but each thread is only 62.5 MIPS. I
have tasks that would be marginal even if one thread is devoted to
it. My real issue is the power consumption scales with clock
frequency and is no better than other processors. I guess if you dig
enough you can find ways to minimize the power consumption, but I
don't see where it is a big improvement over other MCUs. I think XMOS
is not much of a replacement for many FPGA apps. It can be useful in
some limited set of application requirements.

Rick
From: -jg on
On Jun 2, 6:03 am, rickman <gnu...(a)gmail.com> wrote:
> To combine with an MCU, the CPLD doesn't really need to be too
> elaborate.  But it needs to have some bulk.  Just adding 10 or 20
> macrocells doesn't do the job for me.  I'd like to see 500 to 1000
> four input LUTs (with half as many registers and the usual FPGA stuff
> like some carry chains) along with a Cortex MCU.

The Cypress reports show 192 macrocells, with a fan-in of 12, so
that's up to ~600 4iLUTs
I found if I coded carefully, working just under that fan-in ceiling,
then it was predictable, and packed well.

Go too much above that, and the tools run off on their own a bit..

What Cypress forgot to do, was allow Logic fabric access of RAM
blocks. They have RAM in their blocks, but they failed to give the
flexible ram many FPGAs have.
Price is the biggest beef, as a generic 32 bit uC plus a CPLD, is
looking way cheaper.

-jg



From: rickman on
On Jun 1, 9:05 pm, -jg <jim.granvi...(a)gmail.com> wrote:
> On Jun 2, 6:03 am, rickman <gnu...(a)gmail.com> wrote:
>
> > To combine with an MCU, the CPLD doesn't really need to be too
> > elaborate.  But it needs to have some bulk.  Just adding 10 or 20
> > macrocells doesn't do the job for me.  I'd like to see 500 to 1000
> > four input LUTs (with half as many registers and the usual FPGA stuff
> > like some carry chains) along with a Cortex MCU.
>
>  The Cypress reports show 192 macrocells, with a fan-in of 12, so
> that's up to ~600 4iLUTs
>  I found if I coded carefully, working just under that fan-in ceiling,
> then it was predictable, and packed well.
>
>  Go too much above that, and the tools run off on their own a bit..
>
>  What Cypress forgot to do, was allow Logic fabric access of RAM
> blocks. They have RAM in their blocks, but they failed to give the
> flexible ram many FPGAs have.
>  Price is the biggest beef, as a generic 32 bit uC plus a CPLD, is
> looking way cheaper.
>
> -jg

What Cypress parts are you referring to? Are you talking about the
PSoC3/5 devices? I had the impression that they were specialized
logic block similar to the PSoC1 devices. It has been a while since I
looked at the PSoC5. Once I realized I couldn't do stereo, CD quality
audio they became a lot less interesting to me.

Rick