Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Applica a: ✔️ macchine virtuali Linux ✔️ macchine virtuali Windows ✔️ set di scalabilità flessibili ✔️ set di scalabilità uniformi
Il servizio di attestazione FPGA esegue una serie di convalide in un file di checkpoint di progettazione (denominato netlist) generato dal set di strumenti Xilinx e produce un file che contiene l'immagine convalidata (denominata "bitstream") che può essere caricata nella scheda FPGA Xilinx U250 in una macchina virtuale np series.
Il servizio Azure di attestazione FPGA della serie NP è attualmente in anteprima e viene ritirato insieme al ritiro delle macchine virtuali della serie NP. I nuovi accessi in anteprima sono stati chiusi il 1° maggio 2026 e il servizio rimane disponibile per gli utenti approvati in precedenza fino al 1° giugno 2026.
I bitstream che sono già stati attestati continueranno a funzionare nelle macchine virtuali serie NP fino alla data di ritiro della piattaforma. Per indicazioni sulla migrazione, vedere Ritiro della serie NP. Le funzionalità di anteprima sono soggette alle Condizioni per l'utilizzo dell'anteprima.
Aggiornamenti del runtime
Il servizio di attestazione corrente usa Vitis 2021.1 da Xilinx, il 26 settembre 2022, ci spostiamo a Vitis 2022.1. La modifica deve essere trasparente per la maggior parte degli utenti. Una volta che i tuoi disegni sono "attestati" con Vitis 2022.1, dovresti passare a XRT2022.1. Xilinx ha pubblicato nuove immagini del marketplace basate su XRT 2022.1.
Si noti che i progetti attuali, già confermati su Vitis 2020.2 o 2021.1, funzionano sia con le immagini di distribuzione attualmente disponibili nel marketplace sia con le nuove immagini basate su XRT 2022.1
Con l'aggiornamento alla 2021.1, Xilinx ha introdotto un nuovo DRC che può interessare alcuni progetti precedentemente funzionanti in Vitis 2020.2, in relazione all'errore dell'attestazione del componente BUFCE_LEAF. Ulteriori dettagli sono disponibili qui: Xilinx AR 75980 UltraScale/UltraScale+ BRAM: CLOCK_DOMAIN = controlli di disallineamento modalità comune.
Prerequisiti
È necessaria una sottoscrizione Azure e un account Archiviazione di Azure. La sottoscrizione consente di accedere a Azure e l'account di archiviazione viene usato per contenere i file netlist e di output del servizio di attestazione.
Vengono forniti script di PowerShell e Bash per inviare richieste di attestazione. Gli script usano interfaccia della riga di comando di Azure, che possono essere eseguiti in Windows e Linux. PowerShell può essere eseguito in Windows, Linux e macOS.
Download di interfaccia della riga di comando di Azure (obbligatorio)
PowerShell per il download di Windows, Linux e macOS (solo per gli script di PowerShell)
Compilazione della progettazione per l'attestazione
Il set di strumenti Xilinx preferito per la progettazione di edifici è Vitis 2022.1. È possibile usare i file Netlist creati con una versione precedente del set di strumenti e che sono ancora compatibili con la versione 2022.1. Assicurati di aver caricato la shell corretta con cui eseguire la compilazione. La versione attualmente supportata è xilinx_u250_gen3x16_xdma_2_1_202010_1. I file di supporto possono essere scaricati dal lounge Xilinx Alveo.
È necessario includere l'argomento seguente in Vitis (riga cmd v++) per compilare un file xclbin che contiene un netlist anziché un bitstream.
--advanced.param compiler.acceleratorBinaryContent=dcp
Accesso a Azure
Prima di eseguire qualsiasi operazione con Azure, è necessario accedere a Azure e impostare la sottoscrizione autorizzata a chiamare il servizio. Usare i comandi az login e az account set –s <Sub ID or Name> per questo scopo. Altre informazioni su questo processo sono documentate qui: Accedere con interfaccia della riga di comando di Azure. Usare l'opzione Accedi in modo interattivo o accedere con le credenziali nella riga di comando.
Creare un account di archiviazione e un contenitore Blob
Il file netlist deve essere caricato in un contenitore BLOB di archiviazione Azure per l'accesso dal servizio di attestazione.
Per altre informazioni sulla creazione dell'account, un contenitore e il caricamento di netlist come BLOB in tale contenitore, vedere Quickstart: Creare, scaricare ed elencare BLOB con interfaccia della riga di comando di Azure.
È anche possibile usare il portale di Azure.
Carica il file netlist nell'archiviazione BLOB di Azure
Esistono diversi modi per copiare il file. Dii seguito è riportato un esempio di uso del cmdlet az storage upload. I comandi az vengono eseguiti sia in Linux che in Windows. È possibile scegliere qualsiasi nome per il nome "BLOB", ma assicurarsi di mantenere l'estensione xclbin.
az storage blob upload --account-name <storage account to receive netlist> --container-name <blob container name> --name <blob filename> --file <local file with netlist>
Esecuzione degli script di attestazione
Per eseguire gli script, è necessario specificare il nome dell'account di archiviazione, il nome del contenitore BLOB in cui è archiviato il file netlist e il nome del file netlist. È anche necessario creare una firma di accesso condiviso del servizio (SAS) che conceda l'accesso in lettura/scrittura al contenitore (non alla netlist). Questo SAS è utilizzato dal servizio di attestazione per creare una copia locale del file netlist e per scrivere nuovamente i file di output risultanti del processo di convalida nel tuo contenitore.
Una panoramica delle firme di accesso condiviso è disponibile qui, mentre informazioni specifiche sul Service SAS sono disponibili qui. La pagina del servizio SAS include un'importante avvertenza sulla protezione del SAS generato. Leggere l'avvertenza per comprendere la necessità di proteggere il SAS da usi dannosi o imprevisti.
È possibile generare una firma di accesso condiviso per il contenitore usando il cmdlet az storage container generate-sas. Specificare un'ora di scadenza in formato UTC che è almeno poche ore dopo l'ora di invio; circa 6 ore dovrebbero essere più che adeguate.
Se si desidera usare le directory virtuali, è necessario includere la gerarchia di directory come parte dell'argomento contenitore. Ad esempio, se si dispone di un contenitore denominato "netlists" e si dispone di una directory virtuale denominata "image1" che contiene il BLOB netlist, è necessario specificare "netlists/image1" come nome del contenitore. Aggiungere eventuali nomi di directory aggiuntivi per specificare una gerarchia più dettagliata.
PowerShell
$sas=$(az storage container generate-sas --account-name <storage acct name> --name <blob container name> --https-only --permissions rwc --expiry <e.g., 2021-01-07T17:00Z> --output tsv)
.\Validate-FPGAImage.ps1 -StorageAccountName <storage acct name> -Container <blob container name> -BlobContainerSAS $sas -NetlistName <netlist blob filename>
Bash
sas=az storage container generate-sas --account-name <storage acct name> --name <blob container name> --https-only --permissions rwc --expiry <2021-01-07T17:00Z> --output tsv
validate-fpgaimage.sh --storage-account <storage acct name> --container <blob container name> --netlist-name <netlist blob filename> --blob-container-sas $sas
Verifica dello stato dell'invio
Il servizio di attestazione restituirà l'ID orchestrazione dell'invio. Gli script di invio avviano automaticamente il monitoraggio dell'invio eseguendo operazioni di polling per verificarne il completamento. L'ID di orchestrazione è il modo principale per noi di esaminare ciò che è successo alla tua sottomissione, quindi conservalo nel caso tu riscontri un problema. Come punti di riferimento, l'attestazione richiede circa 30 minuti per il completamento di un file netlist di piccole dimensioni (300 MB); un file da 1,6 GB ha richiesto un'ora.
È possibile chiamare lo script Monitor-Validation.ps1 in qualsiasi momento per ottenere lo stato e i risultati dell'attestazione, specificando l'ID di orchestrazione come argomento:
.\Monitor-Validation.ps1 -OrchestrationId <orchestration ID>
In alternativa, è possibile inviare una richiesta post HTTP all'endpoint del servizio di attestazione:
https://fpga-attestation.azurewebsites.net/api/ComputeFPGA_HttpGetStatus
Il corpo della richiesta deve contenere l'ID di sottoscrizione, l'ID tenant e l'ID di orchestrazione della richiesta di attestazione:
{
"OrchestrationId": "<orchestration ID>",
"ClientSubscriptionId": "<your subscription ID>",
"ClientTenantId": "<your tenant ID>"
}
Passaggi di post-convalida
Il servizio scriverà nuovamente l'output nel contenitore. Se il passaggio di convalida ha esito positivo, il contenitore avrà il file netlist originale (abc.xclbin), un file con bitstream (abc.bit.xclbin), un file che identifica il percorso privato del file bitstream archiviato (abc.azure.xclbin) e quattro file di log: uno per il processo di avvio (abc-log.txt) e uno per le tre fasi parallele che eseguono la convalida. Questi sono denominati *logPhaseX.txt dove X è un numero per la fase. Azure.xclbin viene usato sulla VM per segnalare il caricamento dell'immagine convalidata su U250.
Se la convalida non è riuscita, viene scritto un file error-*.txt che indica quale passaggio non è riuscito. Controllare anche i file di log se il log degli errori indica che l'attestazione non è riuscita. Quando ci si contatta per il supporto tecnico, assicurarsi di includere tutti questi file come parte della richiesta di supporto insieme all'ID di orchestrazione.
È possibile usare il portale di Azure per creare il contenitore e caricare il file netlist e scaricare i file di log e bitstream. L'invio di una richiesta di attestazione e il monitoraggio dello stato di avanzamento tramite il portale non sono attualmente supportati e devono essere eseguiti tramite script come descritto in precedenza.