Avvägningar mellan on-premise och on-cloud design

Återutgiven av Platon

anhängare: 0

Experter vid bordet: Semiconductor Engineering satte sig ner och diskuterade hur och varför företag delar upp arbetet på plats och i molnet, och vad man ska se upp med, med Philip Steinke, kollega, CAD-infrastruktur och fysisk design på AMD; Mahesh Turaga, vice vd för affärsutveckling för moln på Cadence Design Systems; Richard Ho, vice president hårdvaruteknik på Lightmatter; Craig Johnson, vice president molnlösningar på Siemens Digital Industries-programvara; och Rob Aitken, stipendiat vid Synopsys. Det som följer är utdrag från det samtalet, som hölls inför en livepublik på Design Automation Conference. Del ett av denna diskussion är här..

SE: Med så mycket som står på spel i chipdesign idag, hur uppnår du bästa ROI med molnresurser?

Steinke: När vi valde arbetsflöden för molnaktivering började vi med att titta på data. Vilka har en hanterbar uppsättning data som kan kapslas in, flyttas till ett molnbaserat datacenter för att göra någon form av beräkning och sedan få en rimlig mängd resultat som kommer tillbaka? Ett av områdena vi fokuserade på var front-end-verifiering. Mitt föredragna flöde där innebär att vi håller våra byggen på plats, buntar ihop själva modellen tillsammans med teststimulansen och skickar ut den för att göra den faktiska simuleringsaktiviteten på molnet. Den andra klassen av arbetsbelastningar som vi har gjort molnaktivering för är full-chip-verifieringsarbetsbelastningar, full-chip signoff-körningar för statisk timing, fysisk verifiering och ström – främst för att du i en miljö av plats-och-rutt-typ kommer in i en regelbunden takt av dagliga ECOs eller vanliga ECOs som händer och gör ändringar, och det finns redan en datahanteringsinställning, med releaser av designen. Så vi kan sätta krokar i den frigivningsmekanismen, inte bara för att placera den i någon sorts lokal utgivningsvolym i vårt eget datacenter, utan för att sedan skicka dessa data till ett molndatacenter som har valts ut för att utföra dessa jobb. En av farhågorna med den stora arbetsbelastningen är att om du redan har din sammanslagna Oasis, eller om du har samlat in alla specifikationer för din design som du vill köra statisk timing på, är det en betydande del av data att flytta allt på en gång. Men genom att uppdatera metoden för release på blocknivå, då sipprar de in när varje block släpps under dagen. På så sätt kan du starta det molnbaserade analysjobbet med full chip med lägre latens. Den största utmaningen jag har sett där är tillgång till bra moln-VM:er med tillräckligt med minne för att köra de stora jobben. Det är ytterligare ett utrymme som vi fortsätter att pressa våra molnpartners att erbjuda – lösningar med mycket RAM för chipdesignföretag att använda.

SE: Vilka råd kan du ge om att urskilja när en arbetsbelastning bör göras på prem kontra på molnet?

Aitken: Det finns en intressant dynamik vi ser just i representanterna i den här panelen, eftersom det sätt som Richard kan närma sig det och hur Phil kan närma sig det kommer att vara annorlunda. Man är mycket fokuserad på en design som rör sig genom topparna och dalarna när det gäller behov. Hos AMD finns det förmodligen massor av designs på gång hela tiden, så det finns en första ansträngning när det gäller precis vad det är de försöker göra. Vilken infrastruktur är vettig om du försöker komma till en värld där du ska göra all din design på molnet, och du bara inte vill ha ett lokalt datacenter alls? Sättet du närmar dig det kommer att vara annorlunda än om du använder molnet som backup och expansionskapacitet för en enorm infrastruktur du redan har.

SE: Rent praktiskt, hur bestämmer du dig?

En hostning: Du tittar på datan. Hur mycket data har du? Hur mycket data ska du generera? Och vad behöver du tillbaka? Det viktigaste för att göra det framgångsrikt är att informationen du vill ha tillbaka från molnet. On-prem måste vara minimal, så det är bara rapporterna och resultaten av dina regressioner som kommer att dyka upp. Vår konstruktion är faktiskt på vår lilla on-prem. Vi skickar upp det och kör våra simuleringar där ute, och vi gör vår egen täckningsanalys. Sedan skickar vi tillbaka resultatet, och det är väldigt litet, och det är bra. Back-end är annorlunda. På den fysiska designdelen skickar du designen där ute, du vill att den ska stanna i molnet så länge du kan eftersom de databaserna är enorma, och du vill verkligen inte att den ska komma tillbaka alls. På den punkten är det infrastruktur som en tjänst. Du behöver bara dina medarbetare logga in i molnet och göra all fysisk design där uppe tills du får GDS. Där är det grejerna inuti maskinen — hur mycket minne kan du få? Det är en av begränsarna. Det är faktiskt väldigt dyrt att ha väldigt stora virtuella maskiner i molnet. Ganska ofta är det billigare att köpa en egen. Vi har inte pratat om kostnad. Kostnaden för moln är inte vad folk tror. Det är ganska högt. Det är mer än on-prem ganska ofta, så du måste balansera det för att få fördelen av att vara flexibel och få tillgång till de stora minnesresurserna. Och hur det ser ut kommer att vara väldigt individuellt för varje kund.

Johnson: Den här frågan relaterar verkligen till ROI för att göra det. Det beror på vad du försöker uppnå som användare av miljön, och det är en del av utmaningen. Varje företag gör sin egen beräkning baserat på sin strategi för att ta reda på vad de vill göra i molnet och hur aggressivt de är villiga att spendera för att skörda den fördelen. Det andra elementet är avkastningen som du mäter är annorlunda än ägandekostnaden. Vi tenderar att vara bättre på att göra totalkostnadsanalys än "R"-delen av ROI, som då måste ta in fler immateriella faktorer genomströmningstid och time-to-market-fördelar.

Aitken: Även med något så enkelt som latens, när du kör ett verktyg och svarstiden är "Jag flyttade musen och sedan en stund senare händer något", kan det vara väldigt frustrerande.

Turaga: Historiskt sett, om vi tittar på ROI för moln, finns det tre klasser av verktyg som kan utnyttja molnet mycket effektivt. Först är designorganisationen, designiterationer, regressioner med verifiering. Det andra är där det finns långa simuleringar med tunga beräkningsbelastningar, och de kan skalas mycket bra för att dra fördel av beräkningsalgoritmerna i olika fall. För det tredje är den interaktiva typen, som verktygen som kräver latens och som också kräver mycket samarbete. Det är de tre kategorierna av verktyg som får den bästa ROI från molnet. Och igen, beroende på varje kundsituation, beror det på vilket verktyg de vill starta i molnet. Några av våra kunder började med verifiering, men det beror på din specifika kundsituation.

SE: För molnanvändarna, hur kom du fram till besluten för din molnanvändningsmodell?

Steinke: Vi har funnits ett tag. Vi hade redan ett ganska stort datacenter, så vi behövde inte gå all-in i början. Vi ville utöka det vi har med vad molnet har att erbjuda. Vårt lokala datacenter fortsätter att leverera en stor del av vår beräkningskapacitet. Projekt kommer och går, och oväntade saker händer; att kunna lägga in den flexibiliteten och ha flera beräkningskällor som vi kan dra från är en fördel som vi ville hoppa på. Det har varit en stor del av vår motivation för moln, och varför vi gick den vägen. Vi hade redan den förskottsinvesteringen så det var något som vi ville utöka och bygga vidare på.

En hostning: Jag kan svara på detta ur två perspektiv. Det första perspektivet är att innan jag var på Lightmatter var jag på Google och arbetade med TPU och på infrastrukturteamet, och vi använde även moln där. Svaret där skiljer sig från svaret hos Lightmatter. En av frågorna du måste ställa dig är om du vill ha ditt arkiv (repository) on-prem eller i molnet. På ett företag som Google, och förmodligen AMD, vill de ha sin repo on-prem. De känner sig säkrare, de känner att det är mer i deras kontroll. På ett mindre företag som Lightmatter bryr jag mig inte nödvändigtvis. Jag var bekväm med säkerheten i molnet, så jag kan ha en repo i molnet. Och i det mindre sammanhanget innebär att ha repo i molnet att vi använder molnet nästan som en komplett infrastruktur. Det är samma som min on-prem. Det är det första bekymret. Det andra problemet är arvet. Vissa företag har legacy, och när du försöker gå från legacy till en molnbaserad lösning måste du verkligen förstå vad du vinner, vilket talar för målet med den här panelen. Vi försöker peka ut var du får en fördel när det gäller flexibilitet, när det gäller att kunna ha nyare maskiner etc. Det som verkligen räknas är på en del av de arbetsbelastningarna, där du har många parallella körningar på gång. Du vill hantera en stor uppsättning servrar och jobb som körs, och det är dit du ska gå på molnet. Du kan få din arbetsbörda att dra nytta av det. När du sedan kommer tillbaka till dataflödet, där du har en begränsning, måste du fatta ett beslut. Vi tog beslutet att ha repo för den fysiska designen i molnet, men andra företag har inte gjort det. Jag vet att företag har fler. De har gjort mycket fysisk design fortfarande på plats eftersom de behöver mycket lagring och inte behöver så många maskiner. Så du måste titta på vart och ett av dessa fall och fatta ett beslut baserat på din situation.

Turaga: Många av våra små till medelstora kundstartuper vill inte ha repot på plats. De har inga äldre datacenterproblem, så de omfamnar verkligen molnet fullt ut. Några av de större företagen som har enorm lokal infrastruktur går redan över till en hybridmodell.

SE: Med det nästan förbryllande antalet instanstyper som finns tillgängliga i molnet från olika leverantörer, utöver licenskostnader som ännu inte är optimerade för moln, hur kan användare förbättra sättet att välja rätt typ av instans för att sköta sina jobb?

Johnson: Detta är en av de grundläggande sakerna vi försöker ta itu med. Vår idé var för företag som AMD som till stor del vill hantera sin egen infrastruktur, och optimera den på sitt speciella sätt, det de skulle vilja ha hjälp av oss med är applikationsspecifika beslut kring vilka typer av instanser med vilken mängd minne som fungerar bäst, och kanske konfigurationen av själva arbetsbelastningen. Hur kan de hantera jobbkörningarna för optimal prestanda? Vi försöker paketera det hela till något vi kallar en färdplan. Vi har dessa färdplaner tillgängliga för olika delar av vårt flöde med baslinjeförslag. Om en kund vill använda det, bra. Om de vill riffa på det och förbättra sig från det är det bra för oss också.

Aitken: Synopsys-vyn är densamma, men det finns också ett beroende av den specifika design du gör. Vissa mönster kommer bara att kräva större eller högre instanser än andra. Och beroende på vad ditt specifika arbetsflöde är, kommer vissa instanser att vara mer eller mindre vettiga än andra. Dessutom är det inte bara licenskostnaderna. Det är också maskinkostnaderna i molnet som du måste byta av. Större maskiner är dyrare, men kanske kan du köra din arbetsbörda på en mindre instans längre och betala mer i licensavgifter men mindre än beräkningsavgifter.

En hostning: Vårt fokus har varit att titta på det i termer av vad själva löpningen är. Är det en förincheckning? Med en förincheckning vill du ha en snabbare körning med låg latens, så du får en riktigt högpresterande instans för det. Är det en regression över natten? I så fall bryr jag mig inte nödvändigtvis om hur snabbt det slutar. Det behöver bara avslutas över natten, så det betyder att jag kan betala för billigare instanser för mina övernattningsregressioner. Vi samarbetar med vår molnleverantör för att ta reda på vad som är den bästa instansen för en körning av den här typen av jobb. Sedan handlar det om att optimera kostnaderna. Du vill hålla dina kostnader så låga du kan för som sagt, det lägger sig ganska snabbt. Vi tittar på varje enskild arbetsbelastning och säger, "Vad är det för instanstyp som behövs för det?" Samtidigt blir det svårt eftersom du då måste hantera poolerna av instanser för varje jobb, och sedan se till att du har tillräckligt med den poolen av instanser tillgängliga så att när det jobbet faktiskt startar körs det i en rimlig tidsram. När du kommer till implementeringen måste du ta itu med dessa frågor.

Turaga: Under åren har vi utvecklat några bästa praxis. Till en början, när du inte är säker på vilken instanstyp du ska använda, väljer du något med en balans mellan dator och minne eller den allmänna instanstypen. Men när du tittar på olika typer av arbetsbelastningar och verifiering behöver du lite mer minne. Det är samma sak med timing. Du behöver ännu mer minne. För CFD-analys kan du behöva GPU:er. Dessa är en del av de bästa praxis vi utvecklat som vi delar med kunderna.