On Wed, 28 Aug 2013 00:48:18 -0700, Don Y <this@isnotme.com> wrote:
>Hi Robert,
>
>On 8/27/2013 11:07 PM, Robert Wessel wrote:
>> On Tue, 27 Aug 2013 19:46:59 -0700, Don Y <this@isnotme.com> wrote:
>
>[attributions elided]
>
>>>>> The post's subject puts a huge constraint on approaches like that:
>>>>> It has to happen today.
>>>>
>>>> Ok then. I'll change my answer. It's not possible to fit any amount of
>>>> RAM on an ASIC today. ASIC design cycles take more than one day.
>>>
>>> Um.... no. Technically, an FPGA qualifies as an ASIC. So, you
>>> could design and produce a functioning "ASIC" in a single 24 hr
>>> period (assuming you had the tools and components in place before
>>> you started).
>>
>> Eh? By definition, an FPGA is *not* an ASIC. An FPGA is general
>> purpose (FSVO "general purpose") part, and not "Application
>> Specific...".
>
>If I gave you a piece of plastic that performed a specific function
>when you twiddled certain pins in a certain way would you agree
>it was an ASIC? It's obviously an IC. It performs a specific
>function defined by its intended application.
>
>If you deencapsulated it and found a full custom mask with my
>initials in the lower left corner, would you be satisfied?
>
>If, instead, you found a generic SoC with a *masked* ROM would
>your opinion change?
>
>What if it was a generic SoC with a FLASH store? Or, EPROM?
>
>What if it was BBSRAM?
>
>As far as you are concerned, the functionality is rigidly
>defined when I put the device into your hands.
>
>What if the SoC was, instead, a sea of gates and the "programming"
>was masked? What about, *electrically* configured?
>
>Ages ago, we used MPU's (not MCU's!) with external *masked* ROM.
>Long lead times. High setup charges. Big minimum quantities.
>Dirt cheap once you got over all that up-front stuff! But,
>*really* hard to change!! (there were chips produced whose
>sole purpose was to "patch ROMs" -- piggy back it onto your circuit
>so it would jam *it's* data onto the bus in place of the masked
>ROM's... at particular addresses!)
>
>Then, EPROM! Program it on your premises. No long lead times.
>No minimum quantities. No setup charges. Terribly expensive
>($25/KB). Not well suited to large volumes. But, if you wanted
>to change your mind often (e.g., development), perfect choice!
>
>Hmmm... folks really like this convenience! And, higher volumes,
>competition, fab improvements are bringing the cost *way* down!
>Unfortunately, the ceramic package is a huge cost penalty.
>
>"Hey, many folks are using these in PRODUCTION, now! They don't
>need to erase/reprogram them. Why have a window at all?" Hence
>came the OTP parts. And, if you were really clever, you could
>actually *reprogram* these!
>
>[Early in the OTP adoption, we were getting "masked" parts that
>were actually OTP's that the manufacturer was programming for
>us -- cheaper than running a new batch of a particular mask set]
>
>Repeat with FLASH, etc.
>
>[We used to make *instantly* reprogrammable "ROMs" -- no need to
>erase and reprogram as that took a lot of development time -- out
>of static RAMs with batteries glued to their backsides along with
>some glue logic]
>
>I.e., these are all just cost/manufacturing tradeoffs made by the
>customer -- OR BY THE VENDOR.
>
>PLAs have taken the same sort of approach. Moving from fusible links
>(PALs), to EPROM cells, masked metalization layers (sea-of-gates
>and STL), etc. The fixed AND-OR arrays of early devices moving to
>more complex macrocells, then generic sea-of-gates and, now, back
>towards more "predefined subsystems" interconnected on chip. (i.e.,
>very few designs nowadays are more than SSI+MSI+LSI on the same
>die -- but with configurable interconnects)
>
>But, how the interconnects are made is really just a manufacturing
>economy. Do you trade off general purpose routing capability for
>functional gate real estate, etc.? Wanna bet the cost point keeps
>shifting as geometries shrink and yields improve -- and customers
>shift to "OTP-ish" implementations instead of full custom?
>
>Once <whatever> is programmed, it's functionality is defined.
>Specific. If the OP's "RAM requirements" were more modest, he
>could give those to someone and receive his ASIC a few hours
>later -- guaranteed to perform the application specific functionality
>desired AND NOTHING MORE (though the "ASIC" would strongly resemble
>an FPGA! :> )
>
>Do you only consider "full customs" as ASICs? And, of those, do
>designs built from standard cells rate a different/lesser designation?
>
>YMMV, of course. Until the day you crack open a "full custom"
>and find some *programmable* part hiding inside :>
That's really odd. I've *never* heard anyone define the term ASIC
from the perspective of the containing device's consumer. Really.
*Never.* Doesn't that make *any* chip inside a box you sell to a
consumer an ASIC?
It's an ASIC because you, as the device manufacturer, pay a fab to
make masks, and fab chips. PLDs of all flavors, microprocessors,
etc., are *not* ASICs by any definition I've ever heard.
Mask programmable devices do occupy something of grey area in the
middle, but OTP programmable device do not (and are clearly not
ASICs). Gate array devices fall into the mask programmable area
somewhere. But in general, I'd consider mask programmed devices to be
ASICs or near-ASICs.
Now some other possibilities in the gray area exist. For example, you
could call Xilinx and ask them to make a FPGA with some extra embedded
doodad just for you.
And so long as we're talking Xilinx, where should we put their
EasyPath stuff? At least some of those are just their normal FPGAs
with the programmed for you at the factory, and with their programming
fuses blown? (IOW, these are intended to be the equivalent of
mask-programmed versions of an otherwise field-programmable device).
Certainly full custom devices are usually ASICs, but also standard
cell designs.