1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

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

Discussion in 'Embedded' started by juangui.jg, Aug 23, 2013.

  1. juangui.jg

    juangui.jg Guest

    Hi all,

    Is it possible to embed 10 or 100 or 1,000 GBytes of RAM inside an ASIC design today?

    In general, what would be the maximum I could fit, if cost is not a limitation? Why?

    Our need would be for a large number, but could be split into many independent banks if that makes things easier. For example, 1,000 independent banks of 100 MBytes each.

    Or another possible partition (again, if it makes things easier) could be a single huge memory with "normal-size" address bus, say of 20 bits, with a huge data bus of 800,000 bits.

    ....Or a mixture of the idea above with the idea of the independent banks.

    Thanks so much for your help.

    - Juan
     
    juangui.jg, Aug 23, 2013
    #1
    1. Advertisements

  2. juangui.jg

    Don Y Guest

    Hi Juan,

    Not with your *likely* budget! :> I suspect any fab even thinking
    about considering your request would push heavily for a hybrid.
    Cost is *always* a limitation.

    And, cost is *always* a limitation.

    Furthermore, cost is *always* a limitation.

    You might try researching the available cores on the market
    currently. And, pricing an equivalent amount of COTS memory
    (with "whatever" other specifications you haven't mentioned).

    Then, ask yourself if you plan on buying in the same sorts of
    quantities that this COTS memory is currently produced/sold.

    If *not*, consider how willing a fab will be to tie up
    their resources for the quantities *you* want -- as an
    "exclusive" customer.
    Is there some OVERWHELMING REASON why you couldn't locate the
    store *outside* the ASIC and take advantage of *commodity*
    memory to give you that capacity? E.g., even if it means
    you have to think a bit harder on your problem and implement
    some caching internal/external to the ASIC? ("Think smarter")
     
    Don Y, Aug 24, 2013
    #2
    1. Advertisements

  3. juangui.jg

    rickman Guest

    An interesting question. Bu the way you put it, if cost is not the
    limiting factor, what is? Does it have to be currently available? Does
    it have to fit on a chip of a given size?

    If you place no constraints on the problem, you end up with an
    unconstrained answer.
     
    rickman, Aug 24, 2013
    #3

  4. You can get roughly 4Gb of DRAM on a 40mm**2 die these days. The
    biggest logic/memory die, reticle limited, you can make, is about
    600mm**2 (that can be pushed a bit). So call it somewhere in the 60Gb
    range (7.5GB) , give or take. At that size you'd better leave a chunk
    for redundancy though (further reducing capacity), since you defect
    density will otherwise kill you.

    Several option including stacking dies in a package, wafer scale
    integration, or some other sort of MCM technology (whether that counts
    depends on your definition of ASIC).

    Alternatively, you could pay (if cost is really no object) to develop
    new steppers and whatnot with bigger reticle limits. Just be sure to
    bring your eleven figure bank balance.
     
    Robert Wessel, Aug 24, 2013
    #4
  5. juangui.jg

    Paul Guest

    So you want to put a Hard Drive on a single ASIC, or bank of ASICs?
    That much data which has time limits to fill or read the whole lot, in
    RAM as data that is volatile. Means if that really is the case you dont
    care if power fails and loss of data; even if the whole system has
    has all sorts of multiple power sources, there are always situations
    where power is removed from maintenance to fire in building.

    Suggests a tiny market, suggests tiny volumes, so unless you
    have a govt agency funding design you would never afford it or
    get it built.
    Wonders if you want a disk drive size data why you dont use disk drive
    methods or methods in parallel and/or caching to solve the issue.

    Or simply use hard drive(s) anyway.


    --
    Paul Carpenter |
    <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
     
    Paul, Aug 24, 2013
    #5
  6. juangui.jg

    upsidedown Guest


    Assuming 64 Gib with current technology mentioned in an other message,
    using a rectangular organization would be 256 Krows x 256 Kcolumns,
    thus an 18 bit row address would be needed and 256 K column sense
    amplifiers/latches effectively creating a 32 KiB cache line, thus
    eliminating much of the bottleneck caused by having a narrow (64-128
    bit) multiplexed external data bus
    That is a real issue how to handle cache collisions. While the memory
    array could be a single plane, after the column amplifiers, there must
    be multiple cache lines, at least one for code and an other for data,
    in practice much more.

    Since code is more or less sequential, it would benefit from long
    cache lines, also using very long instruction words would be
    attractive, each bit could control directly some data path switching.

    It is more problematic with data, how do you shuffle in and out huge
    amount of data. Using 9 KB Ethernet Jumbo frames, it would take more
    than three frames to fill the cache line. At 10 Gbit/s Ethernet a
    Jumbo frame takes 7 us or 140 Kframes/s.

    So in order to utilize th full capacity of such memory architecture,
    you would need a lot of external I/O connections. So something like a
    32 port 10 Gbit/s ethernet switch might be a possible application.
     
    upsidedown, Aug 24, 2013
    #6
  7. juangui.jg

    John Speth Guest

    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. It's your money and you can spend as much of it as
    you want.


    JJS
     
    John Speth, Aug 26, 2013
    #7
  8. 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.
     
    Grant Edwards, Aug 26, 2013
    #8
  9. juangui.jg

    Stef Guest

    In comp.arch.embedded,
    The post's subject puts a huge constraint on approaches like that:
    It has to happen today.

    Don't know where the OP lives, but over here there's under 40 minutes
    left to do it. So the correct answer will be a lot closer to zero that
    the numbers I've seen so far. :)


    --
    Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

    "Why must you tell me all your secrets when it's hard enough to love
    you knowing nothing?"
    -- Lloyd Cole and the Commotions
     
    Stef, Aug 26, 2013
    #9
  10. Ah, I completely missed that.
    I've survived about a half-dozen ASIC efforts, and you're right: you
    can't do anything today. Nor can you do anything this month or this
    quarter. In my experience it's pretty much always to late to do do
    anything this year.

    Next year may or may not be possible...
     
    Grant Edwards, Aug 26, 2013
    #10
  11. juangui.jg

    John Speth Guest

    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
     
    John Speth, Aug 28, 2013
    #11
  12. juangui.jg

    Don Y Guest

    Hi John,

    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).
    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"...
     
    Don Y, Aug 28, 2013
    #12

  13. Eh? By definition, an FPGA is *not* an ASIC. An FPGA is general
    purpose (FSVO "general purpose") part, and not "Application
    Specific...".
     
    Robert Wessel, Aug 28, 2013
    #13
  14. juangui.jg

    Don Y Guest

    Hi Robert,

    [attributions elided]
    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 :>
     
    Don Y, Aug 28, 2013
    #14
  15. juangui.jg

    Randy Yates Guest

    Agreed. There are also very significant differences at the silicon
    level.
     
    Randy Yates, Aug 28, 2013
    #15
  16. 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, Aug 28, 2013
    #16
  17. juangui.jg

    Paul Guest

    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 |
    <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
     
    Paul, Aug 29, 2013
    #17
  18. Packaging MOQ? Is that part of the reason why so many ASICs are
    blob-on-PCB?
     
    Spehro Pefhany, Aug 29, 2013
    #18

  19. 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.
     
    Robert Wessel, Aug 29, 2013
    #19
  20. juangui.jg

    Paul Guest

    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 |
    <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
     
    Paul, Aug 29, 2013
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.