Intel in Talks to buy Altera

I had forgotten them. In fact, I can't remember any of the details other than it using an M3 and having FPGA fabric. This is a one time programmable part or a Flash part?

--

Rick

They are Flash based.

l n

Cortex-M is most useful when you have good chunk of flash on the same die. Which, unfortunately, would be incompatible with silicon tech used for mode rm FPGAs. DACs and SAR ADCs are also problem. Delta-sigma ADCs probably les s so, but I am not an expert. Anyway, for apps that I acre about SAR is mor e useful than delta-sigma. Due to all these factors small embedded solution based on Cortex-M integrat ed into FPGA is likely to and up more complex, using more chips and more ex pensive than solution based on Cortex-M (or even Cortex-R) MCU + FPGA.

The ugly part about MCU + FPGA solution is that, unlike chips from the past , small modern Cortex-M MCUs rarely have good bus to talk to FPGA (good= simple, not to slow and not too many pins). But then again, those old 32-bi t MCUs that had buses that I liked were in $25+ price range. For fair compa rison I probably have to look at old 8-bitter that I never even tried to co nnect to FPGA.

Back to another reason why I think that hard ARM Cortex-M4 core in [Altera or Xilinx] FPGA does not look as a very good proposition: The added value of M3/M4 core alone, without flash and mixed-signal periphe rals, is not that big. After all Nios2-f core (only core, without debug sup port and avalon-mm infrastructure around it) occupies only ~25% of the smal lest Cyclone4 device or ~7% of the smallest Cyclone5-E and achieves compara ble performance. As far as I am concerned, the main advantage of Cortex-M i s a code density - significantly more code can fits on-chip. But even that is less important if were are talking about Cyclone5 generation, because he re the smallest member has 140 KB of embedded memory (not counting MLABs), which is often enough.

That is a bit of nonsense unless you consider Lattice and MicroSemi to not be using "modern" FPGA processes. They include Flash in their devices for the configuration memory.

Once again you should tell that to MicroSemi... They make a mixed signal FPGA with CPU, analog and FPGA on one die. I don't use it because of the price, a bit higher than I like to see.

I think you are saying that an FPGA with internal MCU is not as useful as separate FPGA and MCU because the MCU will have lots of other stuff integrated that would be additional chips with the integrated approach. Clearly it doesn't have to be that ways since at least one company makes such parts.

That brings us back to the real differences between the MCU world and the typical FPGA world. MCUs are intended for apps where speed is limited by the software. FPGAs are intended for apps where speed is potentially much faster with the limitation potentially in the I/O. So a typical high end FPGA will have lots of I/O and some very fast I/O.

But such an integrated MCU/FPGA device would not be intended for high end apps with Mbps I/O. The FPGA would be adding special functionality that perhaps can't be done in the MCU alone. I had a design that required exactly this sort of need and ended up having to use an FPGA with an attached CODEC since there were no MCUs which could implement one interface. The FPGA was a bit jammed up in terms of capacity (only

3 kLUT). A small soft core could do most of the work and potentially free up some space. Had a combined chip been available it would have been a breeze to implement the one interface in hardware (or maybe two) and the rest of the design in software.

Yep, the low end MCU on an FPGA without any of the peripherals would not be a lot more interesting than a soft core. So when will they be doing a better job of the Vulcan mind meld and getting more analog on the FPGA die? It's not like there is anything so special about FPGA logic that can't be done in analog compatible processes. Maybe you lose some density or performance, but that isn't what we are after. At least *I* am looking for a system on chip which includes some FPGA fabric. Don't think of it as an FPGA with an MCU on chip. Think of it as an MCU with FPGA fabric on chip just like the other umpty-nine peripherals they already have along with.... gasp!... 5 volt tolerance. lol

--

Rick

's

d

ral

ch

can

f

AM

LUT

ie. Which, unfortunately, would be incompatible with silicon tech used for moderm FPGAs.

Well, you are right, I am not familiar with Lattice and MicroSemi. From the little I know about them their FPGA are modern in a sense that they a new products and, may be, modern in specific system-level features, but when it comes to size and performance of the fabric, including such important to s ome of us characteristic as dynamic power per watt (static power is probabl y o.k) they are at least 5 years behind X&A, but probably more than 5.

but I am not an expert. Anyway, for apps that I acre about SAR is more usef ul than delta-sigma.

grated into FPGA is likely to and up more complex, using more chips and mor e expensive than solution based on Cortex-M (or even Cortex-R) MCU + FPGA.

Yes, NOR flash, ADCs, DACs.

past, small modern Cortex-M MCUs rarely have good bus to talk to FPGA (goo d=simple, not to slow and not too many pins). But then again, those old 3

2-bit MCUs that had buses that I liked were in $25+ price range. For fair c omparison I probably have to look at old 8-bitter that I never even tried t o connect to FPGA.

That about right, except that I am not talking about high-end FPGAs, but ab out modern "low-cost" lines of A&X. So, fast I/O optional and very fast I/O is rarely even an option (fast=1-3.125 Gbit/s, very fast= >3.125). But for MCUFPGA interface I will be mostly satisfied in much more modera te speed. Say, something logically similar to venerable LPC bus, but withou t 24-bit address space limit (28 bits probably acceptable) and with physica l layer of RGMII.

era or Xilinx] FPGA does not look as a very good proposition:

ipherals, is not that big. After all Nios2-f core (only core, without debug support and avalon-mm infrastructure around it) occupies only ~25% of the smallest Cyclone4 device or ~7% of the smallest Cyclone5-E and achieves com parable performance. As far as I am concerned, the main advantage of Cortex

-M is a code density - significantly more code can fits on-chip. But even t hat is less important if were are talking about Cyclone5 generation, becaus e here the smallest member has 140 KB of embedded memory (not counting MLAB s), which is often enough.

Just a nitpick - by definition there is no such thing as "MCU without any o f the peripherals". Let's call them "MCU-style hard cores" or just "ARM Cor tex-M4" because this particular core looks like the most logical (or least illogical) candidate.

Yes, could be nice. But to be real useful FPGA part should not be too small . I wouldn't bother for 1K 4-input LUTs. 5K looks like reasonable minimum, at least for gray haired devs like you and me. Younger guys a spoiled, they 'd want more than that.

Is 5-V tolerance really that useful [in new designs] without ability to act ually drive 5V outputs? I suppose, even you don't expect the later in 2015 :-)

Sometimes I get really tired of of Thunderbird. When I reply to a post the quoted text is just as likely as not to extend beyond the margin and off the screen... a bloody nuisance I tell you.

Anyway, I think you are not familiar at all with the Lattice products. They have lines of FPGAs that are RAM based like the X and A parts and are likely a generation behind in many terms... but you shouldn't focus on the things that are intangible to you. Do you really care what geometry a part is made in? No, you care whether your design will fit, if it will run fast enough and how much the part costs. I think unless you need the largest parts in the X or A line the L parts will do the job competitively.

I would also mention that you can thank L for the availability of SERDES in lower cost FPGAs. Lattice was the first to offer that and X and A only followed begrudgingly I think.

The other parts, like the XOx and XPx lines can't be compared to anything X or A makes (unless they've come out with something in the last 6 months) because X and A have shied away from the Flash based market. They are adequately fast and have brought the price down to a point where they are competitive against MCUs in some apps.

So saying L is 5 years behind is probably no accurate and not very useful.

"High" speed is relative. Integrated MCUs would have direct bus mapped access to FPGA connections which clearly would run at full speed depending on your FPGA design. Multi-die solutions would need to be bit banged I/O from the MCU or use some peripheral like SPI or Ethernet. As you say, there ain't no buses on many MCUs anymore.

Not sure what that means, but whatever. Potatoes, Patahtoes.

My current product is shipping in a 3 kLUT device. I could have shoved a lot more functionality in if I had used a soft core (of my own design, the canned ones are too large).

There are any number of MCUs that still have 5 volt I/Os. A Cypress line that I was looking at can run with Vcc of 1.8-5 V. Clearly there is a need for such parts or they wouldn't keep designing them. The FPGA vendors ignore this segment because they have never wanted to go down the low price, high volume road in earnest. They would love to get some automotive products designed in and 5 volt I/Os are popular there I believe. I remember when the Xilinx folks were saying the next generation after Spartan 3 would not support 3.3 volt I/Os! But then they also told me that if I connected the FPGA to the load with a 1 inch trace I could blow up the Spartan I/Os if I didn't simulate it. Really? They tend to see the world through FPGA glasses as if they drove the market rather than the market driving their designs.

--

Rick

For those that haven't seen it:

good article,

Hans

I am even more pessimistic than John Cooley. He lists "FPGA users" twice, both on the negative list (Instability in the overall FPGA market (like when two biggest players are in chaos) means R&D on the advanced FPGAs is cut; and the prices for current FPGAs go up. (It's economics.)) and on the positive list ("No more Xilinx-Altera duopoly in F PGA's!"). I personally don't see in which aspects lame duopoly can be better for me, FPGA user, than functional duopoly. Yes, potentially some parts could becom e slightly cheaper, but that's nothing relatively to impact of instability on development process. Besides, it seems, Cooley underestimates ability of Intel to destroy good, solid companies that they are acquiring.