Forums

What's the maximum RAM size that can be embedded in an ASIC today?

Started by Unknown August 23, 2013
On 8/26/2013 2:23 PM, Stef wrote:
> In comp.arch.embedded, > Grant Edwards <invalid@invalid.invalid> wrote: >> On 2013-08-26, John Speth <johnspeth@yahoo.com> wrote: >> >>>> In general, what would be the maximum I could fit, if cost is not a >>>> limitation? Why? >>> >>> I love answering these no-cost-limitation questions. :) >>> >>> There is no limit to how much RAM you can fit onto an ASIC if cost is >>> not a constraint. >> >> Indeed. If current fabs and wafer-processing tools are a limit, then >> with unlimited funds you can build your own fab, make your own tools, >> and develop your own fancy new 4D transistor geometries, >> electron-spin-cells, or sub-atomc-size black holes to be used as >> memory elements. > > 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. The point is, and others have made it in their replies, schedule and cost are ALWAYS driving factors in any design, not just ASICs. To minimize the role of schedule and cost is not productive in a discussion. JJS
Hi John,

On 8/27/2013 4:51 PM, John Speth wrote:
> On 8/26/2013 2:23 PM, Stef wrote: >> In comp.arch.embedded, >> Grant Edwards <invalid@invalid.invalid> wrote: >>> On 2013-08-26, John Speth <johnspeth@yahoo.com> wrote: >>> >>>>> In general, what would be the maximum I could fit, if cost is not a >>>>> limitation? Why? >>>> >>>> I love answering these no-cost-limitation questions. :) >>>> >>>> There is no limit to how much RAM you can fit onto an ASIC if cost is >>>> not a constraint. >>> >>> Indeed. If current fabs and wafer-processing tools are a limit, then >>> with unlimited funds you can build your own fab, make your own tools, >>> and develop your own fancy new 4D transistor geometries, >>> electron-spin-cells, or sub-atomc-size black holes to be used as >>> memory elements. >> >> 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).
> The point is, and others have made it in their replies, schedule and > cost are ALWAYS driving factors in any design, not just ASICs. To > minimize the role of schedule and cost is not productive in a discussion.
Exactly. With infinite money and infinite time you can do "anything". Unfortunately, most of us mere mortals have *neither* -- so have to *engineer* solutions that try to find some "sweet spot"...
On Tue, 27 Aug 2013 19:46:59 -0700, Don Y <this@isnotme.com> wrote:

>Hi John, > >On 8/27/2013 4:51 PM, John Speth wrote: >> On 8/26/2013 2:23 PM, Stef wrote: >>> In comp.arch.embedded, >>> Grant Edwards <invalid@invalid.invalid> wrote: >>>> On 2013-08-26, John Speth <johnspeth@yahoo.com> wrote: >>>> >>>>>> In general, what would be the maximum I could fit, if cost is not a >>>>>> limitation? Why? >>>>> >>>>> I love answering these no-cost-limitation questions. :) >>>>> >>>>> There is no limit to how much RAM you can fit onto an ASIC if cost is >>>>> not a constraint. >>>> >>>> Indeed. If current fabs and wafer-processing tools are a limit, then >>>> with unlimited funds you can build your own fab, make your own tools, >>>> and develop your own fancy new 4D transistor geometries, >>>> electron-spin-cells, or sub-atomc-size black holes to be used as >>>> memory elements. >>> >>> 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...".
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 :>
Robert Wessel <robertwessel2@yahoo.com> writes:

> On Tue, 27 Aug 2013 19:46:59 -0700, Don Y <this@isnotme.com> wrote: > >>Hi John, >> >>On 8/27/2013 4:51 PM, John Speth wrote: >>> On 8/26/2013 2:23 PM, Stef wrote: >>>> In comp.arch.embedded, >>>> Grant Edwards <invalid@invalid.invalid> wrote: >>>>> On 2013-08-26, John Speth <johnspeth@yahoo.com> wrote: >>>>> >>>>>>> In general, what would be the maximum I could fit, if cost is not a >>>>>>> limitation? Why? >>>>>> >>>>>> I love answering these no-cost-limitation questions. :) >>>>>> >>>>>> There is no limit to how much RAM you can fit onto an ASIC if cost is >>>>>> not a constraint. >>>>> >>>>> Indeed. If current fabs and wafer-processing tools are a limit, then >>>>> with unlimited funds you can build your own fab, make your own tools, >>>>> and develop your own fancy new 4D transistor geometries, >>>>> electron-spin-cells, or sub-atomc-size black holes to be used as >>>>> memory elements. >>>> >>>> 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...".
Agreed. There are also very significant differences at the silicon level. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
On 2013-08-28, Don Y <this@isnotme.com> wrote:

> Um.... no. Technically, an FPGA qualifies as an ASIC.
I've been working with both for a long time, and I've never met anybody who refers to an FPGA as an "ASIC". -- Grant Edwards grant.b.edwards Yow! Half a mind is a at terrible thing to waste! gmail.com
In article <kvl0ev$hcq$1@reader1.panix.com>, invalid@invalid.invalid 
says...
> > On 2013-08-28, Don Y <this@isnotme.com> wrote: > > > Um.... no. Technically, an FPGA qualifies as an ASIC. > > I've been working with both for a long time, and I've never met > anybody who refers to an FPGA as an "ASIC".
Likewise, even my customers who make ASICs would not consider PLD or FPGA or PLA being an ASIC, or for that matter any MCU with configurable I/O. Then again they tend to do a lot of mixed/signal work and a lot with mixed/signal Cell ASICs. A custom Mask ROM is easier to do than even a metallisation layer custom ASIC. Mind you these days there are some interesting barriers to making ASICs these days in less than 500k unit runs, especially small or older packages (like QFP or SOIC) for small pin count devices. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/pi/> Raspberry Pi Add-ons <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny <http://www.badweb.org.uk/> For those web sites you hate
On Thu, 29 Aug 2013 09:18:03 +0100, Paul
<paul@pcserviceselectronics.co.uk> wrote:

> >Mind you these days there are some interesting barriers to making >ASICs these days in less than 500k unit runs, especially small or older > packages (like QFP or SOIC) for small pin count devices.
Packaging MOQ? Is that part of the reason why so many ASICs are blob-on-PCB?
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.
In article <21mu19d3v7tl10h7v2i1n7vhm9cpb0ti2n@4ax.com>, 
speffSNIP@interlogDOTyou.knowwhat says...
> > On Thu, 29 Aug 2013 09:18:03 +0100, Paul > <paul@pcserviceselectronics.co.uk> wrote: > > > > >Mind you these days there are some interesting barriers to making > >ASICs these days in less than 500k unit runs, especially small or older > > packages (like QFP or SOIC) for small pin count devices. > > Packaging MOQ? Is that part of the reason why so many ASICs are > blob-on-PCB?
Yes no matter how much you are willing to pay, most packaging lines will not setup up for less than 250k to 500k units. Partly because lots are preferring QFN or BGA as their default packaage types. Mainly because if you want 20k parts in SOIC or QFP requires line changes and setups, typically - half a day setup line less than day for the run half a day to reset line to normal use COB (Chip On Board) or COG (Chip On Glass is getting more common to avoid packaging issues in smaller runs and partly hiding IC manufacture. Finding those willing to package ASIC small runs gets more difficult as time goes on. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/pi/> Raspberry Pi Add-ons <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny <http://www.badweb.org.uk/> For those web sites you hate