Reply by -jg June 2, 20102010-06-02
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