Intel in Talks to buy Altera

[Richard Damon]

On 4/1/15 7:27 PM, Rob Gaddi wrote:

On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:

On 4/1/2015 1:27 PM, John Speth wrote:

I've used both example products with great success. As you said, it's
real convenient to roll your own peripherals with impunity. It saved
me hours of coding effort when you can smartly implement the peripheral
of your dreams with a little HW design.

The part that gets me about the newer versions of this theme is that
they are large, pricey FPGAs and incorporate fairly high end CPUs which
are typically programmed under Linux... a very far cry from the
efficient solution I would like to see. There are few engineers who can
even design the entire system on that chip spanning logic design and
system programming.

Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of
which have big monster Cortex A9s meant to run Linux with a mess of DRAM
and etc. Which, I mean we can make work. But if I could get a 10-20KLUT
FPGA with a dual or quad Cortex M4 instead? Nice and light with every
intention of running bare metal with 10-20K of code? I'd take it in a
heartbeat.

Have you looked at the MicroSemi "SmartFusion2" FPGAs? Its just a single
M3, but that can often be enough.

 

[rickman]

On 4/1/2015 10:59 PM, Richard Damon wrote:

On 4/1/15 7:27 PM, Rob Gaddi wrote:
On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:

On 4/1/2015 1:27 PM, John Speth wrote:

I've used both example products with great success. As you said, it's
real convenient to roll your own peripherals with impunity. It saved
me hours of coding effort when you can smartly implement the peripheral
of your dreams with a little HW design.

The part that gets me about the newer versions of this theme is that
they are large, pricey FPGAs and incorporate fairly high end CPUs which
are typically programmed under Linux... a very far cry from the
efficient solution I would like to see. There are few engineers who can
even design the entire system on that chip spanning logic design and
system programming.

Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of
which have big monster Cortex A9s meant to run Linux with a mess of DRAM
and etc. Which, I mean we can make work. But if I could get a 10-20KLUT
FPGA with a dual or quad Cortex M4 instead? Nice and light with every
intention of running bare metal with 10-20K of code? I'd take it in a
heartbeat.


Have you looked at the MicroSemi "SmartFusion2" FPGAs? Its just a single
M3, but that can often be enough.

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

 

[Richard Damon]

On 4/2/15 2:06 AM, rickman wrote:

On 4/1/2015 10:59 PM, Richard Damon wrote:
On 4/1/15 7:27 PM, Rob Gaddi wrote:
On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:

On 4/1/2015 1:27 PM, John Speth wrote:

I've used both example products with great success. As you said, it's
real convenient to roll your own peripherals with impunity. It saved
me hours of coding effort when you can smartly implement the
peripheral
of your dreams with a little HW design.

The part that gets me about the newer versions of this theme is that
they are large, pricey FPGAs and incorporate fairly high end CPUs which
are typically programmed under Linux... a very far cry from the
efficient solution I would like to see. There are few engineers who
can
even design the entire system on that chip spanning logic design and
system programming.

Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of
which have big monster Cortex A9s meant to run Linux with a mess of DRAM
and etc. Which, I mean we can make work. But if I could get a
10-20KLUT
FPGA with a dual or quad Cortex M4 instead? Nice and light with every
intention of running bare metal with 10-20K of code? I'd take it in a
heartbeat.


Have you looked at the MicroSemi "SmartFusion2" FPGAs? Its just a single
M3, but that can often be enough.

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?

They are Flash based.

 

On Thursday, April 2, 2015 at 2:28:33 AM UTC+3, Rob Gaddi wrote:

On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:

On 4/1/2015 1:27 PM, John Speth wrote:

I've used both example products with great success. As you said, it's
real convenient to roll your own peripherals with impunity. It saved
me hours of coding effort when you can smartly implement the peripheral
of your dreams with a little HW design.

The part that gets me about the newer versions of this theme is that
they are large, pricey FPGAs and incorporate fairly high end CPUs which
are typically programmed under Linux... a very far cry from the
efficient solution I would like to see. There are few engineers who can
even design the entire system on that chip spanning logic design and
system programming.

Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of
which have big monster Cortex A9s meant to run Linux with a mess of DRAM
and etc. Which, I mean we can make work. But if I could get a 10-20KLUT
FPGA with a dual or quad Cortex M4 instead? Nice and light with every
intention of running bare metal with 10-20K of code? I'd take it in a
heartbeat.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

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 moderm FPGAs. DACs and SAR ADCs are also problem. Delta-sigma ADCs probably less so, but I am not an expert. Anyway, for apps that I acre about SAR is more useful than delta-sigma.
Due to all these factors small embedded solution based on Cortex-M integrated into FPGA is likely to and up more complex, using more chips and more expensive 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-bit MCUs that had buses that I liked were in $25+ price range. For fair comparison I probably have to look at old 8-bitter that I never even tried to connect 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 peripherals, 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 comparable 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 that is less important if were are talking about Cyclone5 generation, because here the smallest member has 140 KB of embedded memory (not counting MLABs), which is often enough.

 

On Friday, April 3, 2015 at 1:03:23 AM UTC+3, rickman wrote:

On 4/2/2015 5:30 PM, already5chosen@yahoo.com wrote:
On Thursday, April 2, 2015 at 2:28:33 AM UTC+3, Rob Gaddi wrote:
On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:

On 4/1/2015 1:27 PM, John Speth wrote:

I've used both example products with great success. As you said, it's
real convenient to roll your own peripherals with impunity. It saved
me hours of coding effort when you can smartly implement the peripheral
of your dreams with a little HW design.

The part that gets me about the newer versions of this theme is that
they are large, pricey FPGAs and incorporate fairly high end CPUs which
are typically programmed under Linux... a very far cry from the
efficient solution I would like to see. There are few engineers who can
even design the entire system on that chip spanning logic design and
system programming.

Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of
which have big monster Cortex A9s meant to run Linux with a mess of DRAM
and etc. Which, I mean we can make work. But if I could get a 10-20KLUT
FPGA with a dual or quad Cortex M4 instead? Nice and light with every
intention of running bare metal with 10-20K of code? I'd take it in a
heartbeat.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

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 moderm FPGAs.

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.

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 some of us characteristic as dynamic power per watt (static power is probably o.k) they are at least 5 years behind X&A, but probably more than 5.

DACs and SAR ADCs are also problem. Delta-sigma ADCs probably less so, but I am not an expert. Anyway, for apps that I acre about SAR is more useful than delta-sigma.

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.


Due to all these factors small embedded solution based on Cortex-M integrated into FPGA is likely to and up more complex, using more chips and more expensive than solution based on Cortex-M (or even Cortex-R) MCU + FPGA.

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.

Yes, NOR flash, ADCs, DACs.

Clearly it doesn't have to be that ways since at least one company
makes such parts.


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-bit MCUs that had buses that I liked were in $25+ price range. For fair comparison I probably have to look at old 8-bitter that I never even tried to connect to FPGA.

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.

That about right, except that I am not talking about high-end FPGAs, but about 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 MCU<->FPGA interface I will be mostly satisfied in much more moderate speed. Say, something logically similar to venerable LPC bus, but without 24-bit address space limit (28 bits probably acceptable) and with physical layer of RGMII.

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.


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 peripherals, 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 comparable 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 that is less important if were are talking about Cyclone5 generation, because here the smallest member has 140 KB of embedded memory (not counting MLABs), which is often enough.

Yep, the low end MCU on an FPGA without any of the peripherals would not
be a lot more interesting than a soft core.

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

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.

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.

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

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

--

Rick

 

[rickman]

On 4/2/2015 5:30 PM, already5chosen@yahoo.com wrote:

On Thursday, April 2, 2015 at 2:28:33 AM UTC+3, Rob Gaddi wrote:
On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:

On 4/1/2015 1:27 PM, John Speth wrote:

I've used both example products with great success. As you said, it's
real convenient to roll your own peripherals with impunity. It saved
me hours of coding effort when you can smartly implement the peripheral
of your dreams with a little HW design.

The part that gets me about the newer versions of this theme is that
they are large, pricey FPGAs and incorporate fairly high end CPUs which
are typically programmed under Linux... a very far cry from the
efficient solution I would like to see. There are few engineers who can
even design the entire system on that chip spanning logic design and
system programming.

Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of
which have big monster Cortex A9s meant to run Linux with a mess of DRAM
and etc. Which, I mean we can make work. But if I could get a 10-20KLUT
FPGA with a dual or quad Cortex M4 instead? Nice and light with every
intention of running bare metal with 10-20K of code? I'd take it in a
heartbeat.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

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 moderm FPGAs.

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.


> DACs and SAR ADCs are also problem. Delta-sigma ADCs probably less so, but I am not an expert. Anyway, for apps that I acre about SAR is more useful than delta-sigma.

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.


> Due to all these factors small embedded solution based on Cortex-M integrated into FPGA is likely to and up more complex, using more chips and more expensive than solution based on Cortex-M (or even Cortex-R) MCU + FPGA.

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.


> 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-bit MCUs that had buses that I liked were in $25+ price range. For fair comparison I probably have to look at old 8-bitter that I never even tried to connect to FPGA.

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.

FPGA does not look as a very good proposition:
The added value of M3/M4 core alone, without flash and mixed-signal peripherals, 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 comparable 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 that is less important if were are talking about Cyclone5 generation, because here the smallest member has 140 KB of embedded memory (not counting MLABs), which is often enough.

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

 

[rickman]

On 4/2/2015 6:52 PM, already5chosen@yahoo.com wrote:

On Friday, April 3, 2015 at 1:03:23 AM UTC+3, rickman wrote:
On 4/2/2015 5:30 PM, already5chosen@yahoo.com wrote:
On Thursday, April 2, 2015 at 2:28:33 AM UTC+3, Rob Gaddi wrote:
On Wed, 01 Apr 2015 19:10:55 -0400, rickman wrote:

On 4/1/2015 1:27 PM, John Speth wrote:

I've used both example products with great success. As you said, it's
real convenient to roll your own peripherals with impunity. It saved
me hours of coding effort when you can smartly implement the peripheral
of your dreams with a little HW design.

The part that gets me about the newer versions of this theme is that
they are large, pricey FPGAs and incorporate fairly high end CPUs which
are typically programmed under Linux... a very far cry from the
efficient solution I would like to see. There are few engineers who can
even design the entire system on that chip spanning logic design and
system programming.

Agreed. We're looking hard at both Zynq and the Cyclone V SOC, both of
which have big monster Cortex A9s meant to run Linux with a mess of DRAM
and etc. Which, I mean we can make work. But if I could get a 10-20KLUT
FPGA with a dual or quad Cortex M4 instead? Nice and light with every
intention of running bare metal with 10-20K of code? I'd take it in a
heartbeat.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

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 moderm FPGAs.

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.


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 some of us characteristic as dynamic power per watt (static power is probably o.k) they are at least 5 years behind X&A, but probably more than 5.

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.

DACs and SAR ADCs are also problem. Delta-sigma ADCs probably less so, but I am not an expert. Anyway, for apps that I acre about SAR is more useful than delta-sigma.

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.


Due to all these factors small embedded solution based on Cortex-M integrated into FPGA is likely to and up more complex, using more chips and more expensive than solution based on Cortex-M (or even Cortex-R) MCU + FPGA.

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.

Yes, NOR flash, ADCs, DACs.

Clearly it doesn't have to be that ways since at least one company
makes such parts.


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-bit MCUs that had buses that I liked were in $25+ price range. For fair comparison I probably have to look at old 8-bitter that I never even tried to connect to FPGA.

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.


That about right, except that I am not talking about high-end FPGAs, but about 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 MCU<->FPGA interface I will be mostly satisfied in much more moderate speed. Say, something logically similar to venerable LPC bus, but without 24-bit address space limit (28 bits probably acceptable) and with physical layer of RGMII.

"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.

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.


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 peripherals, 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 comparable 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 that is less important if were are talking about Cyclone5 generation, because here the smallest member has 140 KB of embedded memory (not counting MLABs), which is often enough.

Yep, the low end MCU on an FPGA without any of the peripherals would not
be a lot more interesting than a soft core.

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

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

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.

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.

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).

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


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

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

 

[HT-Lab]

On 27/03/2015 19:50, 1@FPGARelated wrote:

http://www.wsj.com/articles/intel-in-talks-to-buy-altera-1427485172
---------------------------------------
Posted through http://www.FPGARelated.com

For those that haven't seen it:

http://www.deepchip.com/items/0548-02.html

good article,

Hans
www.ht-lab.com

 

On Saturday, April 4, 2015 at 10:34:43 AM UTC+3, HT-Lab wrote:

On 27/03/2015 19:50, 1@FPGARelated wrote:
http://www.wsj.com/articles/intel-in-talks-to-buy-altera-1427485172
---------------------------------------
Posted through http://www.FPGARelated.com


For those that haven't seen it:

http://www.deepchip.com/items/0548-02.html

good article,

Hans
www.ht-lab.com

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 FPGA'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 become 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.