Rethinking Memory - Plato AiStream V2.1

Publisert av Platon

Følgere: 0

Eksperter ved bordet: Semiconductor Engineering satte seg ned for å snakke om veien videre for minne i stadig mer heterogene systemer, med Frank Ferro, konserndirektør, produktledelse ved Cadence; Steven Woo, stipendiat og fremtredende oppfinner ved Rambus; Jongsin Yun, minneteknolog ved Siemens EDA; Randy White, programleder for minneløsninger hos Nøkkelsikt; og Frank Schirrmeister, visepresident for løsninger og forretningsutvikling ved Arteris. Det som følger er utdrag av den samtalen. Del én av denne diskusjonen kan bli funnet her..

[L-R]: Frank Ferro, Cadence; Steven Woo, Rambus; Jongsin Yun, Siemens EDA; Randy White, Keysight; og Frank Schirrmeister, Arteris.

[L-R]: Frank Ferro, Cadence; Steven Woo, Rambus; Jongsin Yun, Siemens EDA; Randy White, Keysight; og Frank Schirrmeister, Arteris

SE: Når vi sliter med AI/ML og kraftkrav, hvilke konfigurasjoner må tenkes nytt? Vil vi se et skifte bort fra Von Neumann-arkitekturen?

Woo: Når det gjelder systemarkitekturer, er det en bifurkasjon på gang i bransjen. De tradisjonelle applikasjonene som er de dominerende arbeidshestene, som vi kjører i skyen på x86-baserte servere, forsvinner ikke. Det er flere tiår med programvare som har blitt bygget opp og utviklet, og som vil stole på at arkitekturen fungerer godt. Derimot er AI/ML en ny klasse. Folk har revurdert arkitekturene og bygget veldig domenespesifikke prosessorer. Vi ser at omtrent to tredjedeler av energien brukes på å flytte dataene mellom en prosessor og en HBM-enhet, mens bare omtrent en tredjedel brukes på å faktisk få tilgang til bitene i DRAM-kjernene. Databevegelsen er nå mye mer utfordrende og kostbar. Vi kommer ikke til å bli kvitt minnet. Vi trenger det fordi datasettene blir større. Så spørsmålet er: ‘Hva er den riktige veien videre?’ Det har vært mye diskusjon om stabling. Hvis vi skulle ta det minnet og legge det direkte på toppen av prosessoren, gjør det to ting for deg. For det første er båndbredden i dag begrenset av kysten eller omkretsen av brikken. Det er der I/O-ene går. Men hvis du skulle stable den direkte på toppen av prosessoren, kan du nå bruke hele området av brikken til distribuerte sammenkoblinger, og du kan få mer av båndbredden i selve minnet, og den kan mate direkte ned i prosessoren. Lenker blir mye kortere, og strømeffektiviteten går sannsynligvis opp i størrelsesorden 5X til 6X. For det andre øker mengden båndbredde du kan få på grunn av at mer areal array-forbindelse til minnet, også med flere heltallsfaktorer. Å gjøre disse to tingene sammen kan gi mer båndbredde og gjøre det mer strømeffektivt. Industrien utvikler seg til hva behovene er, og det er definitivt en måte vi vil se minnesystemer begynne å utvikle seg i fremtiden for å bli mer strømeffektive og gi mer båndbredde.

Jern: Da jeg først begynte å jobbe med HBM rundt 2016, spurte noen av de mer avanserte kundene om det kunne stables. De har sett på hvordan de kan stable DRAM på toppen i en stund fordi det er klare fordeler. Fra det fysiske laget blir PHY i utgangspunktet ubetydelig, noe som sparer mye strøm og effektivitet. Men nå har du en prosessor på flere 100W som har et minne på toppen av seg. Minnet tåler ikke varmen. Det er sannsynligvis det svakeste leddet i varmekjeden, noe som skaper en annen utfordring. Det er fordeler, men de må fortsatt finne ut hvordan de skal håndtere termikken. Det er mer insentiv nå for å flytte den typen arkitektur fremover, fordi det virkelig sparer deg totalt sett når det gjelder ytelse og kraft, og det vil forbedre dataeffektiviteten din. Men det er noen fysiske designutfordringer som må håndteres. Som Steve sa, vi ser alle slags arkitekturer som kommer ut. Jeg er helt enig i at GPU/CPU-arkitekturene ikke kommer noen vei, de kommer fortsatt til å være dominerende. Samtidig prøver hvert eneste selskap på planeten å komme opp med en bedre musefelle for å gjøre AI. Vi ser SRAM på brikken og kombinasjoner av minne med høy båndbredde. LPDDR har hevet hodet ganske mye i disse dager når det gjelder hvordan man kan dra nytte av LPDDR i datasenteret på grunn av kraften. Vi har til og med sett GDDR bli brukt i noen AI-inferensapplikasjoner, så vel som alle de gamle minnesystemene. De prøver nå å presse så mange DDR5-er på et fotavtrykk som mulig. Jeg har sett hver arkitektur du kan tenke deg, enten det er DDR, HBM, GDDR eller andre. Det avhenger av prosessorkjernen din når det gjelder hva din samlede verdiøkning er, og deretter hvordan du kan bryte gjennom din spesielle arkitektur. Minnesystemet som følger med, slik at du kan skulpturere CPU-en din og minnearkitekturen din, avhengig av hva som er tilgjengelig.

Og en: Et annet problem er ikke-volatiliteten. Hvis AI-en må forholde seg til strømintervallet mellom å kjøre en IoT-basert AI, for eksempel, så trenger vi mye strøm av og på, og all denne informasjonen for AI-treningen må rotere igjen og igjen. Hvis vi har en type løsninger der vi kan lagre disse vektene i brikken slik at vi ikke alltid trenger å bevege oss frem og tilbake for samme vekt, vil det være mye strømbesparelse, spesielt for IoT-basert AI. Det vil være en annen løsning for å hjelpe disse kraftbehovene.

Schirrmeister: Det jeg synes er fascinerende, fra et NoC-perspektiv, er hvor du må optimalisere disse banene fra en prosessor som går gjennom en NoC, tilgang til et minnegrensesnitt med en kontroller som potensielt går gjennom UCIe for å sende en brikke til en annen brikke, som deretter har minne i den. Det er ikke det at Von Neumann-arkitekturer er døde. Men det er så mange variasjoner nå, avhengig av arbeidsmengden du ønsker å beregne. De må vurderes i sammenheng med hukommelse, og hukommelse er bare ett aspekt. Hvor du henter dataene fra datalokaliteten, hvordan er det ordnet i denne DRAM? Vi jobber gjennom alle disse tingene, for eksempel ytelsesanalyse av minner og deretter optimalisere systemarkitekturen på den. Det ansporer til mye innovasjon for nye arkitekturer, som jeg aldri tenkte på da jeg var på universitetet og lærte om Von Neumann. I den ytterste andre enden har du ting som netting. Det er mye flere arkitekturer nå i mellom som skal vurderes, og det er drevet av minnebåndbredden, beregningsevnene og så videre, og vokser ikke i samme hastighet.

Hvit: Det er en trend som involverer disaggregert databehandling eller distribuert databehandling, noe som betyr at arkitekten må ha flere verktøy til rådighet. Minnehierarkiet har utvidet seg. Det er semantikk inkludert, samt CXL og forskjellige hybridminner, som er tilgjengelig for flash og i DRAM. En parallell applikasjon til datasenteret er bilindustrien. Automotive hadde alltid denne sensoren beregnet med ECUer (elektroniske kontrollenheter). Jeg er fascinert av hvordan det har utviklet seg til datasenteret. Spol fremover, og i dag har vi distribuert beregningsnoder, kalt domenekontrollere. Det er det samme. Den prøver å adressere at strøm kanskje ikke er så stor sak fordi omfanget av datamaskiner ikke er så stort, men latens er absolutt en stor sak med bilindustrien. ADAS trenger superhøy båndbredde, og du har forskjellige avveininger. Og så har du flere mekaniske sensorer, men lignende begrensninger i et datasenter. Du har kjølelager som ikke trenger å ha lav latens, og så har du andre applikasjoner med høy båndbredde. Det er fascinerende å se hvor mye verktøyene og alternativene for arkitekten har utviklet seg. Bransjen har gjort en veldig god jobb med å svare, og alle av oss leverer ulike løsninger som strømmer inn i markedet.

SE: Hvordan har verktøy for minnedesign utviklet seg?

Schirrmeister: Da jeg begynte med mine første par brikker på 90-tallet, var det mest brukte systemverktøyet Excel. Siden den gang har jeg alltid håpet at det kan gå i stykker på et tidspunkt for tingene vi gjør på systemnivå, minne, båndbreddeanalyse og så videre. Dette påvirket lagene mine ganske mye. På den tiden var det veldig avanserte greier. Men til Randys poeng, nå må visse komplekse ting simuleres på et nivå av troskap som tidligere ikke var mulig uten beregningen. For å gi et eksempel, kan det å anta en viss ventetid for en DRAM-tilgang føre til dårlige arkitekturbeslutninger og potensielt feil utforming av datatransportarkitekturer på brikke. Baksiden er også sann. Hvis du alltid antar det verste tilfellet, vil du overdesigne arkitekturen. Å la verktøy utføre DRAM og ytelsesanalyse, og å ha de riktige modellene tilgjengelig for kontrollerene gjør at en arkitekt kan simulere alt, det er et fascinerende miljø å være i. Mitt håp fra 90-tallet om at Excel på et tidspunkt kan bryte som en Verktøy på systemnivå kan faktisk gå i oppfyllelse, fordi visse av de dynamiske påvirkningene du ikke kan gjøre i Excel lenger fordi du trenger å simulere dem ut - spesielt når du legger inn et die-to-die-grensesnitt med PHY-egenskaper, og deretter kobler lag egenskaper som å sjekke om alt var riktig og potensielt sende data på nytt. Å ikke ha disse simuleringene vil resultere i suboptimal arkitektur.

Jern: Det første trinnet i de fleste evalueringer vi gjør er å gi dem minnetestbenken for å begynne å se på DRAM-effektiviteten. Det er et stort skritt, til og med å gjøre ting så enkelt som å kjøre lokale verktøy for å gjøre DRAM-simulering, men så gå inn i fullverdige simuleringer. Vi ser at flere kunder spør etter den typen simulering. Å sørge for at DRAM-effektiviteten er oppe på 90-tallet er et veldig viktig første skritt i enhver evaluering.

Woo: En del av grunnen til at du ser fremveksten av fullsystemsimuleringsverktøy er at DRAM-er har blitt mye mer kompliserte. Det er veldig vanskelig nå å være jevn i baren for noen av disse komplekse arbeidsbelastningene ved å bruke enkle verktøy som Excel. Hvis du ser på dataarket for DRAM på 90-tallet, var disse databladene som 40 sider. Nå er de hundrevis av sider. Det snakker bare om kompleksiteten til enheten for å få ut de høye båndbreddene. Du kobler det sammen med det faktum at minne er en slik driver i systemkostnader, samt båndbredde og latens relatert til ytelsen til prosessoren. Det er også en stor driver i kraft, slik at du trenger å simulere på et mye mer detaljert nivå nå. Når det gjelder verktøyflyt, forstår systemarkitekter at minne er en stor driver. Så verktøyene må være mer sofistikerte, og de må kobles til andre verktøy veldig godt slik at systemarkitekten får den beste globale oversikten over hva som skjer - spesielt med hvordan minnet påvirker systemet.

Og en: Når vi går over til AI-æraen, brukes mange flerkjernesystemer, men vi vet ikke hvilke data som går hvor. Det går også mer parallelt med brikken. Størrelsen på minnet er mye større. Hvis vi bruker ChatGPT-typen AI, krever datahåndteringen for modellene omtrent 350 MB data, som er en enorm mengde data bare for en vekt, og den faktiske input/output er mye større. Den økningen i mengden data som kreves betyr at det er mange sannsynlige effekter vi ikke har sett før. Det er en ekstremt utfordrende test å se alle feilene knyttet til denne store mengden minne. Og ECC brukes overalt, selv i SRAM, som ikke tradisjonelt brukte ECC, men nå er det veldig vanlig for de største systemene. Testing for alt dette er svært utfordrende og må støttes av EDA-løsninger for å teste alle de forskjellige forholdene.

SE: Hvilke utfordringer møter ingeniørteam på en daglig basis?

Hvit: På en gitt dag vil du finne meg i laboratoriet. Jeg bretter opp ermene og har skitne hendene mine, stukket ledninger, loddet og sånt. Jeg tenker mye på post-silisiumvalidering. Vi snakket om tidlig simulering og on-die-verktøy – BiST og slike ting. På slutten av dagen, før vi sender, ønsker vi å gjøre en form for systemvalidering eller tester på enhetsnivå. Vi snakket om hvordan vi kan overvinne minneveggen. Vi samlokaliserer minne, HBM, slike ting. Hvis vi ser på utviklingen av emballasjeteknologi, startet vi med blyholdige pakker. De var ikke veldig gode for signalintegritet. Tiår senere gikk vi over til optimalisert signalintegritet, som ball grid arrays (BGAs). Vi fikk ikke tilgang til det, noe som betydde at du ikke kunne teste det. Så vi kom opp med dette konseptet kalt en enhetsinterposer – en BGA-interposer – og som tillot oss å legge inn en spesiell armatur som dirigerte signaler ut. Så kunne vi koble den til testutstyret. Spol frem til i dag, og nå har vi HBM og chiplets. Hvordan legger jeg armaturet mitt i mellom på silisiuminnlegget? Vi kan ikke, og det er kampen. Det er en utfordring som holder meg våken om natten. Hvordan utfører vi feilanalyse i felten med en OEM- eller systemkunde, der de ikke får 90 % effektivitet. Det er flere feil i lenken, de kan ikke initialiseres riktig, og opplæringen fungerer ikke. Er det et systemintegritetsproblem?

Schirrmeister: Vil du ikke heller gjøre dette hjemmefra med et virtuelt grensesnitt enn å gå til laboratoriet? Er ikke svaret mer analyse du bygger inn i brikken? Med chiplets integrerer vi alt enda lenger. Å få inn loddebolten din er egentlig ikke et alternativ, så det må være en måte for analyse på brikken. Vi har det samme problemet for NoC. Folk ser på NoC, og du sender dataene og så er de borte. Vi trenger analysene for å sette inn der slik at folk kan gjøre feilsøking, og det strekker seg til produksjonsnivået, slik at du endelig kan jobbe hjemmefra og gjøre alt basert på chipanalyse.

Jern: Spesielt med minne med høy båndbredde kan du ikke fysisk komme inn der. Når vi lisensierer PHY, har vi også et produkt som passer til det, slik at du kan se på hver eneste av disse 1,024 bitene. Du kan begynne å lese og skrive DRAM fra verktøyet slik at du ikke trenger å komme inn der fysisk. Jeg liker interposer-ideen. Vi tar noen pinner ut av interposeren under testing, noe du ikke kan gjøre i systemet. Det er virkelig en utfordring å komme inn i disse 3D-systemene. Selv fra et designverktøyflytsynspunkt ser det ut til at de fleste selskaper gjør sin egen individuelle flyt på mange av disse 2.5D-verktøyene. Vi begynner å sette sammen en mer standardisert måte å bygge et 2.5D-system på, fra signalintegritet, kraft, hele flyten.

Hvit: Etter hvert som ting fortsetter å dø, håper jeg vi fortsatt kan opprettholde samme nivå av nøyaktighet. Jeg er med i UCIe-formfaktoroverholdelsesgruppen. Jeg ser på hvordan man karakteriserer en kjent god terning, en gyllen terning. Til slutt vil dette ta mye mer tid, men vi kommer til å finne et lykkelig medium mellom ytelsen og nøyaktigheten til testingen vi trenger, og fleksibiliteten som er innebygd.

Schirrmeister: Hvis jeg ser nærmere på chiplets og deres bruk i et mer åpent produksjonsmiljø, er testing en av de største utfordringene for å få det til å fungere riktig. Hvis jeg er et stort selskap og jeg kontrollerer alle sider av det, kan jeg begrense ting på riktig måte slik at testing og så videre blir gjennomførbart. Hvis jeg vil gå til UCIe-slagordet om at UCI bare er én bokstav unna PCI, og jeg ser for meg en fremtid der UCIe-montering blir, fra et produksjonsperspektiv, som PCI-spor i en PC i dag, så er testaspektene for det virkelig utfordrende. Vi må finne en løsning. Det er mye arbeid å gjøre.

Relaterte artikler
Minnets fremtid (Del 1 av over avrundbar)
Fra forsøk på å løse termiske og strømproblemer til rollene til CXL og UCIe, har fremtiden en rekke muligheter for hukommelse.