@Nadamuni: Being the programmable Gate arrays this may be named as GASoC - Gate Array SoCs
This might have worked when FPGAs were predominantly arrays of programmable elements, but these days they contain so much more "stuff" that the term "gate array" just doesn't reflect what they are and do.
@BisDevGuy: Wow Max, cudoes for writing a short article that get's so much attention and debate.
Thank you so much for your kind words. I've found that this is the sort of topic that really trips a lot of folks up -- those of us who are deep in the thick of it know what other people mean when they use these terms, but a lot of people get really confused. I usually include a brief overview of this when I do an FPGA talk, and there's almnost invariably a couple of people who say "So that's what xxx means!"
Wow Max, cudoes for writing a short article that get's so much attention and debate. To your original question, I recall Altera being the first to use the term System on Programmable Chip (SOPC) back about 15 years ago when they had the Excalibur product line. I always thought this term was sufficient for similar devices including those from Xilinx. However, since these devices were not that popular back then, the need for an industry term focused on a new breed of programmable silicon devices wasn't so necessary.
As George pointed out in an earlier post, today, the lines are becoming much more blurred in terms of what Altera and Xilinx offer versus full custom devices. Today, traditional ASIC/ASSP development teams are including FPGA capability in their devices. Some of this integration is occuring within one monolithic device and some are integrating with 2.5/3D techniques. With that in mind, I think we should revert back to naming the device based simply on how it will be applied in the overall system and call it either an ASIC, ASSP. Almost all of these will contain some sort of processor and incude some memory....so it might be time to retire the term SoC too.
"This is very interesting -- something to think about -- the capitalization of FP and ASSP remonds me of the a/D (little 'a' big 'D'), A/D, and A/d (big 'a' little 'D') to talk about mixed-signal chips and indicate the relative amount of the analog and digital functionality."
I too have often used the terms "Big A/Little D" and "Big D/Little A" for mixed-signal ICs -- by the way, isn't everything a mixed-signal IC? -- but those terms relate just as much to design methodology as they do to the relative amount of analog vs digital content. Big A/Little D can be thought of as "schematic on top" and Big D/Little A can be thought of as "netlist on top." The former refers to traditional analog design methodology and the latter refers to traditional digital design methodology.
Choosing the optimum methodology for a particular mixed-signal design can make a big difference in die size, performance and schedule.
Important thing about FPASSP is everyone is trying to expand their markets. FPGA is trying expand their reach by adding ASSP content which is small enough in dies size not to radicaly increase their high device costs. The ASSP vendors are willing to add a FPGA or programmable die area to offset their high NRE costs by making their devices suitable in adjacent applications.
But all this is a problem, and an opportunity. FPGA customers now have to use IP for which they must write drivers and do software. Work they are not used to. ASSP users now have to understand how to deal with non-fixed resources and tools that program them. Both sides need new support from EDA, IP, and software. Simply a manner ot economics and how architectures map onto devices.
@George Janac: The capitalization of FP and ASSP reflects the dominant partition in the device.
This is very interesting -- something to think about -- the capitalization of FP and ASSP remonds me of the a/D (little 'a' big 'D'), A/D, and A/d (big 'a' little 'D') to talk about mixed-signal chips and indicate the relative amount of the analog and digital functionality.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...