On Jun 3, 2:19=A0pm, rickman <gnu...@gmail.com> wrote:
> On Jun 2, 7:24 pm, -jg <jim.granvi...@gmail.com> wrote:
>
> > On Jun 3, 10:20 am, rickman <gnu...@gmail.com> wrote:
>
> > > > Yes, the PSoC3.
> > > > Their Logic is very CPLD like, with a product term macrocell, with =
a
> > > > fan-in of 12 (compared with 40 for Atmel CPLDs and 36-40 for others=
)
>
> > > When you say fan in of 12, you don't mean product terms do you? =A0Th=
at
> > > would be a very adequate number of product terms. =A0I don't recall
> > > seeing any CPLDs with up to 40 product terms. =A0If it is just 12
> > > inputs, then it all depends on how they are connected.
>
> > FanIn is effectively the width of the wide AND gate,
> > so is the number of signals that can be Boolean ANDed.
> > When you include some Enables & clocks, it means around 8-9-10 bit
> > counters are the best fit.
>
> Typically the utility of macrocells are not limited by the number
> inputs to the and gates. =A0They are normally as wide as the number of
> signals in a bank so that all inputs can feed all product terms and
> there is no signal routing problems within a given block. =A0
Depends on the design.
It happens that on the last 2 I've done, the
FanIn was the ceiling I banged into.
(and this on Fanin 40 devices)
In the Cypress devices, the fanin of 12 I'd call
unusually low, and so it will be more of an issue.
Certainly I had to modify my design to better
match the resource.
-jg
Reply by rickman●June 2, 20102010-06-02
On Jun 2, 7:24 pm, -jg <jim.granvi...@gmail.com> wrote:
> On Jun 3, 10:20 am, rickman <gnu...@gmail.com> wrote:
>
> > > Yes, the PSoC3.
> > > Their Logic is very CPLD like, with a product term macrocell, with a
> > > fan-in of 12 (compared with 40 for Atmel CPLDs and 36-40 for others)
>
> > When you say fan in of 12, you don't mean product terms do you? That
> > would be a very adequate number of product terms. I don't recall
> > seeing any CPLDs with up to 40 product terms. If it is just 12
> > inputs, then it all depends on how they are connected.
>
> FanIn is effectively the width of the wide AND gate,
> so is the number of signals that can be Boolean ANDed.
> When you include some Enables & clocks, it means around 8-9-10 bit
> counters are the best fit.
Typically the utility of macrocells are not limited by the number
inputs to the and gates. They are normally as wide as the number of
signals in a bank so that all inputs can feed all product terms and
there is no signal routing problems within a given block. The
macrocell capability is limited by the number of product terms that go
into each or gate. In most CPLDs this is fixed for a given macrocell,
but can vary across the macrocells so that the few functions that need
more logic can have it, but the smaller logic functions can fit in the
rest of the macrocells. A few logic families can share product terms
across macrocells or at least allow some product terms to be
partitioned to different macrocells, but that is the exception I
believe.
> Looking at the report file, I see that FanIn goes up to 12, (I rewrote
> things to keep at <=12)
> and the number of product terms I see used is up to 8,
> (averages ~3) so they don't seem to have the annoying hard limit of
> 5PT that other CPLDs have on each Macrocell.
>
> I think they can share PT too - report says 384 Max Unique PT, for
> 192MC, and I was chewing PT faster than MC, with my average of ~3.
Ok, that is a lot more clear. I guess I don't need to know exactly
how they block out their logic, the tools will or at least should
optimize that for me.
> So that makes it more similar to CoolRunner, than 16V8/Max/Atmel PLDs
I've never been a fan of CPLDs myself, primarily because of the cost
per logic element. The Lattice Flash FPGAs seem to do a lot better in
that regard. There is some irony here. Cypress used to have an
interesting line of CPLD/FPGA devices, flash based, IIRC.
> I found their tools annoyingly slow, and have shelved the R&D work,
> until the real price is revealed.
> Indications right now are, it is too expensive.
I thought the PSoC3 parts were available and had pricing, no? I am
waiting for the PSOC5 parts myself. But then I have been waiting for
over two and a half years now! I'm not holding my breath. Imagine
how many design wins they could have achieved if they had come out
with the devices a year and a half ago like they planned! They have
been saying Q2 of 2010 for months now. They have less than 30 days
left to meet their deadline.
Rick
Reply by -jg●June 2, 20102010-06-02
On Jun 3, 10:20=A0am, rickman <gnu...@gmail.com> wrote:
> > Yes, the PSoC3.
> > Their Logic is very CPLD like, with a product term macrocell, with a
> > fan-in of 12 (compared with 40 for Atmel CPLDs and 36-40 for others)
>
> When you say fan in of 12, you don't mean product terms do you? =A0That
> would be a very adequate number of product terms. =A0I don't recall
> seeing any CPLDs with up to 40 product terms. =A0If it is just 12
> inputs, then it all depends on how they are connected.
FanIn is effectively the width of the wide AND gate,
so is the number of signals that can be Boolean ANDed.
When you include some Enables & clocks, it means around 8-9-10 bit
counters are the best fit.
Looking at the report file, I see that FanIn goes up to 12, (I rewrote
things to keep at <=3D12)
and the number of product terms I see used is up to 8,
(averages ~3) so they don't seem to have the annoying hard limit of
5PT that other CPLDs have on each Macrocell.
I think they can share PT too - report says 384 Max Unique PT, for
192MC, and I was chewing PT faster than MC, with my average of ~3.
So that makes it more similar to CoolRunner, than 16V8/Max/Atmel PLDs
I found their tools annoyingly slow, and have shelved the R&D work,
until the real price is revealed.
Indications right now are, it is too expensive.
-jg
=A0
Reply by rickman●June 2, 20102010-06-02
On Jun 2, 5:07=A0pm, -jg <jim.granvi...@gmail.com> wrote:
> On Jun 3, 4:03=A0am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Jun 1, 9:05=A0pm, -jg <jim.granvi...@gmail.com> wrote:
>
> > > On Jun 2, 6:03=A0am, rickman <gnu...@gmail.com> wrote:
>
> > > > To combine with an MCU, the CPLD doesn't really need to be too
> > > > elaborate. =A0But it needs to have some bulk. =A0Just adding 10 or =
20
> > > > macrocells doesn't do the job for me. =A0I'd like to see 500 to 100=
0
> > > > four input LUTs (with half as many registers and the usual FPGA stu=
ff
> > > > like some carry chains) along with a Cortex MCU.
>
> > > =A0The Cypress reports show 192 macrocells, with a fan-in of 12, so
> > > that's up to ~600 4iLUTs
> > > =A0I found if I coded carefully, working just under that fan-in ceili=
ng,
> > > then it was predictable, and packed well.
>
> > > =A0Go too much above that, and the tools run off on their own a bit..
>
> > > =A0What 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.
> > > =A0Price 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? =A0Are you talking about the
> > PSoC3/5 devices? =A0I had the impression that they were specialized
> > logic block similar to the PSoC1 devices. =A0It has been a while since =
I
> > looked at the PSoC5. =A0Once I realized I couldn't do stereo, CD qualit=
y
> > audio they became a lot less interesting to me.
>
> Yes, the PSoC3.
> Their Logic is very CPLD like, with a product term macrocell, with a
> fan-in of 12 (compared with 40 for Atmel CPLDs and 36-40 for others)
When you say fan in of 12, you don't mean product terms do you? That
would be a very adequate number of product terms. I don't recall
seeing any CPLDs with up to 40 product terms. If it is just 12
inputs, then it all depends on how they are connected. I will have to
look at the new PSoC devices a bit more, but I seem to recall they are
hard to learn since the focus is on using their magic GUI and less on
just letting you at the native hardware.
> I think that is quite different from the earlier PSoC1 devices, which
> were more basic menu-choice based blocks.
> That put me off them, as well as the orphan core.
>
> The reports base on 192 of these D/T macrocells, and you can access
> all this from Verilog - so the logic is quite accessible.
>
> In the tests I did, I found that as long as I kept the fanin =A0below
> that 12 ceiling, then the logic compiles behaved as expected.
> ( of course, Cypress mention none of this )
Too bad I am a VHDL guy! Maybe I'll download their tool and try it
out. That seems to be the way they want you to learn the parts.
There is still the issue of price. Their parts are more expensive
then the FPGAs I am currently using.
Rick
Reply by -jg●June 2, 20102010-06-02
On Jun 3, 4:03=A0am, rickman <gnu...@gmail.com> wrote:
> On Jun 1, 9:05=A0pm, -jg <jim.granvi...@gmail.com> wrote:
>
>
>
> > On Jun 2, 6:03=A0am, rickman <gnu...@gmail.com> wrote:
>
> > > To combine with an MCU, the CPLD doesn't really need to be too
> > > elaborate. =A0But it needs to have some bulk. =A0Just adding 10 or 20
> > > macrocells doesn't do the job for me. =A0I'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.
>
> > =A0The Cypress reports show 192 macrocells, with a fan-in of 12, so
> > that's up to ~600 4iLUTs
> > =A0I found if I coded carefully, working just under that fan-in ceiling=
,
> > then it was predictable, and packed well.
>
> > =A0Go too much above that, and the tools run off on their own a bit..
>
> > =A0What 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.
> > =A0Price 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? =A0Are you talking about the
> PSoC3/5 devices? =A0I had the impression that they were specialized
> logic block similar to the PSoC1 devices. =A0It has been a while since I
> looked at the PSoC5. =A0Once I realized I couldn't do stereo, CD quality
> audio they became a lot less interesting to me.
Yes, the PSoC3.
Their Logic is very CPLD like, with a product term macrocell, with a
fan-in of 12 (compared with 40 for Atmel CPLDs and 36-40 for others)
I think that is quite different from the earlier PSoC1 devices, which
were more basic menu-choice based blocks.
That put me off them, as well as the orphan core.
The reports base on 192 of these D/T macrocells, and you can access
all this from Verilog - so the logic is quite accessible.
In the tests I did, I found that as long as I kept the fanin below
that 12 ceiling, then the logic compiles behaved as expected.
( of course, Cypress mention none of this )
-jg
Reply by rickman●June 2, 20102010-06-02
On Jun 1, 9:05=A0pm, -jg <jim.granvi...@gmail.com> wrote:
> On Jun 2, 6:03=A0am, rickman <gnu...@gmail.com> wrote:
>
> > To combine with an MCU, the CPLD doesn't really need to be too
> > elaborate. =A0But it needs to have some bulk. =A0Just adding 10 or 20
> > macrocells doesn't do the job for me. =A0I'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.
>
> =A0The Cypress reports show 192 macrocells, with a fan-in of 12, so
> that's up to ~600 4iLUTs
> =A0I found if I coded carefully, working just under that fan-in ceiling,
> then it was predictable, and packed well.
>
> =A0Go too much above that, and the tools run off on their own a bit..
>
> =A0What 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.
> =A0Price 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
Reply by -jg●June 1, 20102010-06-01
On Jun 2, 6:03=A0am, rickman <gnu...@gmail.com> wrote:
> To combine with an MCU, the CPLD doesn't really need to be too
> elaborate. =A0But it needs to have some bulk. =A0Just adding 10 or 20
> macrocells doesn't do the job for me. =A0I'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
Reply by rickman●June 1, 20102010-06-01
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
Reply by rickman●June 1, 20102010-06-01
On May 29, 3:54 am, -jg <jim.granvi...@gmail.com> wrote:
> On May 29, 9:12 am, rickman <gnu...@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
Reply by -jg●May 29, 20102010-05-29
On May 29, 11:46=A0pm, Mike Harrison <m...@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