Compromessi tra progettazione on-premise e on-cloud

Compromessi tra progettazione on-premise e on-cloud

Timestamp: 16 agosto 2023 3:01
Nodo di origine: 2825730

Gli esperti al tavolo: l'ingegneria dei semiconduttori si è seduta a discutere di come e perché le aziende stanno dividendo il lavoro on-premise e nel cloud e a cosa fare attenzione, con Philip Steinke, collega, infrastruttura CAD e progettazione fisica presso AMD; Mahesh Turaga, vicepresidente dello sviluppo aziendale per il cloud presso Design Systems Cadence; Richard Ho, vicepresidente dell'ingegneria hardware di Lightmatter; Craig Johnson, vicepresidente soluzioni cloud presso Siemens Digital Industries Software; e Rob Aitken, collega di Synopsys. Quelli che seguono sono estratti di quella conversazione, che si è tenuta di fronte a un pubblico dal vivo alla Design Automation Conference. La prima parte di questa discussione è qui.

SE: Con così tanto in gioco oggi nella progettazione dei chip, come si ottiene il miglior ROI con le risorse cloud?

Steinke: Quando abbiamo selezionato i flussi di lavoro per l'abilitazione al cloud, abbiamo iniziato osservando i dati. Quali hanno un set di dati gestibile che può essere incapsulato, spostato in un data center ospitato nel cloud per eseguire una sorta di calcolo e quindi avere una quantità ragionevole di risultati che ritornano? Una delle aree su cui ci siamo concentrati è stata la verifica front-end. Il mio flusso preferito consiste nel mantenere le nostre build on-premise, raggruppare il modello stesso insieme allo stimolo del test e inviarlo per eseguire l'effettiva attività di simulazione sul cloud computing. L'altra classe di carichi di lavoro per i quali abbiamo eseguito l'abilitazione al cloud sono i carichi di lavoro di verifica dell'intero chip, le esecuzioni di approvazione dell'intero chip per la sincronizzazione statica, la verifica fisica e l'alimentazione, principalmente perché in un ambiente di tipo luogo e percorso, si entra in una cadenza regolare di ECO giornalieri o ECO regolari che si verificano e apportano modifiche, e c'è già una configurazione di gestione dei dati, con rilasci in corso del progetto. Quindi siamo in grado di inserire hook in quel meccanismo di rilascio, non solo per inserirlo in una sorta di volume di rilascio locale nel nostro data center, ma per poi inviare quei dati a un data center cloud che è stato selezionato per eseguirli lavori. Una delle preoccupazioni su un carico di lavoro così grande è che se hai già il tuo Oasis unito, o se hai raccolto tutte le specifiche per il tuo progetto su cui vuoi eseguire il timing statico, è una parte significativa dei dati da spostare tutto in una volta. Ma aggiornando la metodologia di rilascio a livello di blocco, entrano in gioco man mano che ogni blocco viene rilasciato durante il giorno. In questo modo puoi avviare il lavoro di analisi full-chip ospitato nel cloud con una latenza inferiore. La sfida principale che ho visto è l'accesso a buone macchine virtuali cloud con memoria sufficiente per eseguire quei grandi lavori. Questo è un altro spazio che continuiamo a spingere i nostri partner cloud a offrire: soluzioni con molta RAM da utilizzare per le aziende di progettazione di chip.

SE: Che consigli puoi dare su come distinguere quando un carico di lavoro dovrebbe essere eseguito in locale rispetto al cloud?

Aitken: C'è una dinamica interessante che vediamo solo nei rappresentanti di questo panel, perché il modo in cui Richard potrebbe affrontarla e il modo in cui Phil potrebbe affrontarla sarà diverso. Uno è molto concentrato su un design che si muove tra picchi e valli in termini di esigenze. In AMD, presumibilmente, ci sono molti progetti in corso tutto il tempo, quindi c'è uno sforzo iniziale in termini di ciò che stanno cercando di fare. Quale infrastruttura ha senso se stai cercando di entrare in un mondo in cui eseguirai tutto il tuo progetto sul cloud e preferiresti semplicemente non avere un data center on-premise? Il modo in cui ti avvicini sarà diverso rispetto a quando utilizzi il cloud come funzionalità di backup ed espansione per un'enorme infrastruttura che già possiedi.

SE: In pratica, come decidi?

Una tosse: Tu guardi i dati. Quanti dati hai? Quanti dati genererai? E cosa ti serve indietro? La cosa fondamentale per avere successo è che le informazioni che desideri vengano restituite dal cloud. On-prem deve essere minimo, quindi verranno visualizzati solo i report e i risultati delle tue regressioni. La nostra build è in realtà sul nostro piccolo locale. Lo spediamo ed eseguiamo le nostre simulazioni là fuori, e facciamo la nostra analisi della copertura. Quindi rispediamo i risultati, ed è molto piccolo, ed è buono. Il back-end è diverso. Nella parte del design fisico, spedisci il design là fuori, vuoi che rimanga sul cloud il più a lungo possibile perché quei database sono enormi e non vuoi davvero che torni indietro. A quel punto, è l'infrastruttura come servizio. Devi solo fare in modo che i tuoi dipendenti accedano al cloud e facciano tutto il design fisico lassù fino a quando non ottieni il GDS. Ecco, sono le cose all'interno della macchina: quanta memoria puoi ottenere? Questo è uno dei limitatori. In realtà è molto costoso avere macchine virtuali molto grandi nel cloud. Molto spesso è più economico acquistarne uno tuo. Non abbiamo parlato di costi. Il costo del cloud non è quello che pensa la gente. È piuttosto alto. È più che in sede abbastanza spesso, quindi devi bilanciarlo per ottenere il vantaggio di essere flessibile e accedere alle grandi risorse di memoria. E il modo in cui appare sarà molto individuale per ogni cliente.

Johnson: Questa domanda si riferisce davvero al ROI di farlo. Dipende da cosa stai cercando di ottenere come utente dell'ambiente, e questo fa parte della sfida. Ogni azienda esegue i propri calcoli in base alla propria strategia per capire cosa vuole fare nel cloud e quanto è disposta a spendere in modo aggressivo per ottenere tale vantaggio. L'altro elemento è che il rendimento misurato è diverso dal costo di proprietà. Tendiamo ad essere più bravi nell'effettuare analisi del costo totale di proprietà rispetto alla parte "R" del ROI, che deve quindi mettere in gioco fattori più intangibili attraverso il tempo e il vantaggio del time-to-market.

Aitken: Anche con qualcosa di semplice come la latenza, quando esegui uno strumento e il tempo di risposta è "Ho spostato il mouse e poco dopo succede qualcosa", può essere molto frustrante.

Turaga: Storicamente, se guardiamo al ROI per il cloud, ci sono tre classi di strumenti che possono sfruttare il cloud in modo molto efficace. Il primo è l'organizzazione del progetto, le iterazioni del progetto, le regressioni con verifica. Il secondo è dove ci sono simulazioni di lunga durata con carichi di calcolo pesanti e possono scalare molto bene per sfruttare gli algoritmi di calcolo in varie istanze. Il terzo è il tipo interattivo, come gli strumenti che richiedono latenza e richiedono anche molta crescita della collaborazione. Queste sono le tre categorie di strumenti che ottengono il miglior ROI dal cloud. E ancora, a seconda della situazione di ogni cliente, dipende da quale strumento vogliono avviare nel cloud. Alcuni dei nostri clienti hanno iniziato con la verifica, ma dipende dalla situazione specifica del cliente.

SE: Per gli utenti del cloud, come siete arrivati ​​alle decisioni per il vostro modello di utilizzo del cloud?

Steinke: Siamo in giro da un po'. Avevamo già un data center piuttosto grande, quindi all'inizio non avevamo bisogno di andare all-in. Stavamo cercando di aumentare ciò che abbiamo con ciò che il cloud ha da offrire. Il nostro data center on-prem continua a fornire un'enorme quantità della nostra capacità di elaborazione. I progetti vanno e vengono e accadono cose inaspettate; essere in grado di integrare quella flessibilità e disporre di più fonti di calcolo da cui attingere è un vantaggio su cui volevamo saltare. Questa è stata una parte importante della nostra motivazione per il cloud e il motivo per cui siamo andati in quella direzione. Avevamo già quell'investimento anticipato, quindi era qualcosa che stavamo cercando di aumentare e costruire.

Una tosse: Posso rispondere da due punti di vista. La prima prospettiva è che prima di entrare in Lightmatter, ero in Google a lavorare su TPU e nel team dell'infrastruttura, e anche lì abbiamo utilizzato il cloud. La risposta è diversa dalla risposta di Lightmatter. Una delle domande che devi porti è se vuoi che il tuo repository (repository) sia on-prem o nel cloud. In un'azienda come Google, e presumibilmente AMD, vogliono il loro repository on-prem. Si sentono più sicuri, sentono che è più sotto il loro controllo. In un'azienda più piccola come Lightmatter, non mi interessa necessariamente. Ero a mio agio con la sicurezza del cloud, quindi posso avere un repository nel cloud. E in quel contesto più piccolo, avere un repository nel cloud significa che stiamo usando il cloud quasi come un'infrastruttura completa. È lo stesso del mio on-prem. Questa è la prima preoccupazione. La seconda preoccupazione è l'eredità. Alcune aziende hanno legacy e quando provi a passare da una soluzione legacy a una basata su cloud, devi davvero capire cosa stai guadagnando, il che parla dell'obiettivo di questo panel. Stiamo cercando di sottolineare dove ottieni un vantaggio in termini di flessibilità, in termini di possibilità di avere macchine più nuove, ecc. Dove conta davvero è su alcuni di quei carichi di lavoro, dove hai molte corse parallele in corso. Vuoi gestire un ampio set di server e lavori in esecuzione, ed è qui che dovresti andare sul cloud. Puoi fare in modo che il tuo carico di lavoro ne tragga vantaggio. Quindi, tornando al flusso di dati, dove hai un vincolo, devi prendere una decisione. Abbiamo preso la decisione di avere un repository per la progettazione fisica nel cloud, ma altre aziende no. So che le aziende ne hanno di più. Hanno fatto molta progettazione fisica ancora in sede perché hanno bisogno di molto spazio di archiviazione e non hanno bisogno di così tante macchine. Quindi devi esaminare ciascuno di questi casi e prendere una decisione in base a quale sia la tua situazione.

Turaga: Molte delle nostre piccole e medie startup di clienti non vogliono il repository on-prem. Non hanno problemi con i data center legacy, quindi stanno davvero abbracciando completamente il cloud. Alcune delle aziende più grandi che dispongono già di un'enorme infrastruttura in sede stanno già passando a un modello di tipo ibrido.

SE: Con il numero quasi sconcertante di tipi di istanza disponibili nel cloud da diversi fornitori, oltre ai costi di licenza che non sono ancora ottimizzati per il cloud, come possono gli utenti migliorare il modo in cui scelgono il giusto tipo di istanza per eseguire i loro lavori?

Johnson: Questa è una delle cose fondamentali che stiamo cercando di affrontare. La nostra idea era per aziende come AMD che vogliono in gran parte gestire la propria infrastruttura e ottimizzarla in un modo particolare, ciò su cui vorrebbero aiuto da parte nostra sono decisioni specifiche dell'applicazione su quali tipi di istanze con quale quantità di memoria funzionano meglio, e forse la configurazione del carico di lavoro stesso. Come possono gestire le esecuzioni dei lavori per ottenere prestazioni ottimali? Cerchiamo di impacchettare tutto in qualcosa che chiamiamo piano di volo. Abbiamo questi piani di volo disponibili per varie parti del nostro flusso con suggerimenti di base. Se un cliente vuole usarlo, bene. Se vogliono riff su quello e migliorare da quello, va bene anche per noi.

Aitken:  La vista Synopsys è la stessa, ma c'è anche una dipendenza dal design specifico che stai facendo. Alcuni progetti richiedono solo istanze più grandi o più alte di altri. E a seconda di quale sia il tuo particolare flusso di lavoro, alcune istanze avranno più o meno senso di altre. Inoltre, non sono solo i costi di licenza. È anche il costo della macchina nel cloud che devi scendere a compromessi. Le macchine più grandi sono più costose, ma forse puoi eseguire il tuo carico di lavoro su un'istanza minore più a lungo e pagare di più in canoni di licenza ma meno dei costi di calcolo.

Una tosse: Il nostro obiettivo è stato quello di guardarlo in termini di quale sia la corsa effettiva. E' una corsa prima del check-in? Con un pre-check-in, vuoi un'esecuzione più veloce con bassa latenza, quindi ottieni un'istanza ad alte prestazioni per questo. È una regressione notturna? In tal caso, non mi interessa necessariamente quanto velocemente finisce. Deve solo finire dall'oggi al domani, quindi ciò significa che posso pagare istanze più economiche per le mie regressioni notturne. Collaboriamo con il nostro fornitore di servizi cloud per capire qual è l'istanza migliore per eseguire questo tipo di lavoro. Poi si tratta di ottimizzare i costi. Vuoi mantenere i tuoi costi il ​​più bassi possibile perché, come ho detto, si somma abbastanza velocemente. Esaminiamo ogni particolare carico di lavoro e diciamo: "Qual è il tipo di istanza necessario per questo?" Allo stesso tempo, diventa difficile perché devi gestire i pool di istanze per ogni lavoro e quindi assicurarti di avere abbastanza di quel pool di istanze disponibili in modo che quando quel lavoro si avvia effettivamente, venga eseguito in un ragionevole lasso di tempo. Quando arrivi alla distribuzione, devi rispondere a queste domande.

Turaga: Nel corso degli anni abbiamo sviluppato alcune best practice. Inizialmente, quando non sei sicuro del tipo di istanza da utilizzare, scegli qualcosa con un equilibrio tra calcolo e memoria o quel tipo di istanza generale. Ma poi, mentre guardi diversi tipi di carichi di lavoro e verifica, hai bisogno di un po' più di memoria. È lo stesso caso con i tempi. Hai bisogno di ancora più memoria. Per l'analisi CFD, potresti aver bisogno di GPU. Queste fanno parte delle best practice che abbiamo sviluppato e che condividiamo con i clienti.

Timestamp:

Di più da Semiingegneria