Page 1 of 2

debug hw, SoC fuori controllo

PostPosted: 26 Jun 2014, 17:41
by legacy
@deluca
voi avete implementato un SoftCore from scratches, c'e' un mio amico che mi sta facendo una capa tanta per tutti i problemi in cui si e' infilato per una faccenda simile: ha scritto un SoC il cui Softcore e' un coso RISC con pipeline 5 stadi che … diciamo pure che NON funziona

ecco, come sai io detesto questo genere di progetti, e vedo le FPGA unicamente modi glue logic e periferiche, mai come SoftCore proprio perche' non sai mai come validarle, se sono valdiate, o se riservano sgradite sorprese (oltre al fatto che non e' mai chiaro se possano o meno essere affidabili con interfacce di debug, modi jtag, nexus, BDM ecc ecc, insomma quando c'e', rodato, testato e funzionante, nelle controparti ASIC)

sicche' mi domando e chiedo:

al pratico cosa avete usato (chipscope, LAC, boh?) e come avete condotto la attivita' di validazione, di bug fixing ecc, in HDL, sopratutto, della pipeline ?

Per l'accrocchio che mi ha mostrato … ho scritto una semplicissima calcolatrice tutta sint32_t e alla prova del 9 gia' noto che ha un comportamento diverso e va fuori controllo se si cambiano i livelli di ottimizzazione

p.e. usando gcc

-O0 (nessuna ottimizzazione) vede il codice funzionare come ci si aspetta (ed i risultati sono pure giusti :lol: )

-O1, -O2, -Os (ottimizzazioni varie) iniziano a manifestarsi comportamenti strani, del tutto non giustificabili secondo l'assembly sottostante, segno che c'e' qualche pasticcio nella pipeline, di cui sospetto hazard, e pasticci vari con i branch, e allora il punto diventa capire dove/che cosa/perche', anche perche', oltre alle CPU, potrebbero esserci delle collisioni sul cross bar matrix che collega la CPU con le periferiche e con la ram (quest'ultima e' BRAM, interna alla fpga)

Ecco, a voi e' successo durante lo sviluppo ? Se si, come ne siete venuti fuori, insomma cosa gli dico (a parte il butta via tutto, e prenditi una CPU ASIC, ma tanto, almeno su questa … non mi ascolta, ha la testa di marmo) ?

Re: debug hw, SoC fuori controllo

PostPosted: 27 Jun 2014, 00:22
by legacy
ale', il mio amico mi scrive che ha fatto una batteria di test a caso (metodo altamente scientifico) e "sembra" che siano le moltiplicazioni a mandare in stallo la pipeline, ovvero levandole tutto funziona (si fa per dire) :o

la cosa fantastica e' che in un regime altamente speculativo (dove ognuno dice la sua, fa test, prove, riprove, ecc) la MUL incriminata potrebbe anche non azzeccarci nulla, questo il bello del metodo "altamente scientifico" che gira da queste parti :lol:

Re: debug hw, SoC fuori controllo

PostPosted: 27 Jun 2014, 14:13
by deluca
@legacy,
Visto che nomini ram-BRAM Il softcore a cui tu alludi è stato sviluppato sicuramente su piattaforma Xilinx...
Proprio in questi gg abbiamo ripreso il progetto, ma il nostro SoC è stato appositamente sviluppato per fpga Altera.
Uno mio studente di ing ci sta smanettando sopra e sta sviluppando ed integrando nuove periferiche e nuove custom-instruction che ci servono per una applicazione dedicata.
Siamo passati su Cyclone IV ed abbiamo migliorato sensibilmente le prestazioni del SoC.
Ora la cpu va a 200Mhz, ma dai test effettuati mi sembra aver trovato il limite a 210/220Mhz.
Qualche problema, ma già risolto, è stato trovato nella sincronizzazione con la ram esterna.
Qualche variazione sugli indirizzi, rispetto all'avr originale, per integrare nuove periferiche, ma tutto sembra andare senza grossi intoppi.

Re: debug hw, SoC fuori controllo

PostPosted: 27 Jun 2014, 17:52
by legacy
Si, ha usato Spartan3e da 500K LE tirata a 50Mhz.

Viene impiegata la Bram sia per la instruction ram che per la data ram, con una soluzione (16+16)Kbyte che per ora sembrano essere sufficienti.

In un paio di giornate gli ho realizzato la toolchain di crosscompiling, i vari tools per caricare un elf in BRAM, più l'ealy boot (in assembly) ed una minima BSP con i driver della seriale per farlo bootstrappare e renderlo operativo.

La toolchain, la mini-bsp, e tutto il firmware e' stato testato in tutte le configurazioni possibili su un Core ASIC di pari ISA senza mai presentare difetto alcuno, nemmeno quando compilato -O1, -O2

I disastri accadono sul SoftCore quando si compila -O1, -O2, e la mia domanda : questo e' segno che c'e' qualcosa che non va nella pipeline o altrove, voi come avete condotto la validazione prima del Softcore e poi del SoC ? Come ne siete venuti fuori ? Quanto man power e' richiesto (ore/uomo) ? Che tool avete usato ? ecc

Io non so da che parte iniziare a guardarlo quell'affare, non l'ho scritto io, non ho idea di cosa sia buggato ma di sicuro c'e' qualcosa che non va da qualche parte o nella pipeline, o nella crossbar matrix, o in entrambe, e a rigore mi verrebbe voglia di smontarlo modulo per modulo e simulare tutto con una massiccia dose di vettori di test che coprano quante + casistiche possibili, pero' mi sembra che sia un lavoro immenso in termini di risorse richieste.

Mi chiedevo, e se invece di simulare tutto a tappedo si usasse un chipscope ? Altre idee, trucchi, suggerimenti ?

Per il chipscope, certo, non fa parte delle licenze ISE/WebPack, quindi e' un goloso tool per chi ha le licenze per poterlo usare, ma forse ho qualcuno che mi presta una licenza per un paio di settimane, sempre che basti il tempo, e sarebbe a tempo perso.

Re: debug hw, SoC fuori controllo

PostPosted: 27 Jun 2014, 17:58
by legacy
deluca wrote:nuove custom-instruction


Questa faccenda come la gestite al lato toolchain ?
Patch a tappeto di gcc ? Modifica del machine gen ?

Re: debug hw, SoC fuori controllo

PostPosted: 27 Jun 2014, 18:07
by legacy
A pro po, una faccenda che NON va assolutamente bene: mi sono accorto solo ora che il mio amico non ha assolutamente considerato le illegal instruction, ovvero se il SoftCore dovesse fare fetch di qualcosa che non e' in grado di decodificare (istruzione non implementata, o fuori specifica), nulla si può dire sulle conseguenze!

Male, malissimo, sfugge di mano, non e' deterministico, e almeno sapere che e' successo un pasticcio del genere, almeno si alzasse una exception, anche solo per accendere un led ad indicazione del nefasto evento!

bah, non ce la possiamo fare :lol:

Re: debug hw, SoC fuori controllo

PostPosted: 01 Jul 2014, 13:23
by legacy
ma insomma, con uno topicone cosi', nessuno mi dice nulla ?

Re: debug hw, SoC fuori controllo

PostPosted: 01 Jul 2014, 16:55
by Altero
legacy cosa dobbiamo dirti,

siamo poveri neofiti e qua tu, deluca e qualcun'altro parlate di cose troppo complesse, almeno per me.

mi sono avvicinato al vhdl saltuariamente e solo da poco sto iniziando a vedere cose un pò più complesse.

a proprosito, hai un qualche testo sul vhdl da consigliarmi? tu su quale hai o stai studiando?

ti ringrazio.

Re: debug hw, SoC fuori controllo

PostPosted: 01 Jul 2014, 20:36
by legacy
sulla questione toolchain mi piacerebbe sapere se c'e' una scorciatoia o se per validare

Re: debug hw, SoC fuori controllo

PostPosted: 06 Jul 2014, 11:58
by Leonardo
legacy wrote:Per il chipscope, certo, non fa parte delle licenze ISE/WebPack, quindi e' un goloso tool per chi ha le licenze per poterlo usare


In alcune dev-board (es. LX9) dovrebbe essere inclusa una licenza ChipScope SDK device-locked.

Io personalmente in SignalTap II (equivalente Altera di ChipScope) ho trovato un prezioso alleato che mi ha salvato in molte occasioni dove i tempi erano stretti.

Re: debug hw, SoC fuori controllo

PostPosted: 06 Jul 2014, 13:09
by legacy
Cos'e' sta storia della licenza "ChipScope SDK device-locked" ? Mai sentita, umm, LX9 -> Spartan6 ? Che significa cambiare target, fattibile, e' solo un ulteriore esborso di grana -> da valutare, ma in ogni caso che boards sarebbero in lista per il ChipScope ?



E con oggi abbiamo scoperto altri 2 bachi, il + divertente e' che non puoi nemmeno mettere una loadbyte dopo una divi (oltre che dietro una mulu) senno ti si inchioda la pipeline, ale', praticamente la ALU non sa fare ne moltiplicazioni ne divisioni senza scassare tutto, e siamo ad 9 bachi (2 fixed, gli altri 7 ancora latitanti), st'affare e' un colabrodo, tutta la parte writeback e' sospetta (anzi, per me li dentro si annidano altri bagarospi) e testarlo sto softcore e' praticamente impossibile (a meno di una potente batteria di test incrociati) :lol:

Re: debug hw, SoC fuori controllo

PostPosted: 06 Jul 2014, 13:31
by Leonardo
Ho la scatola ( con la board dentro :) ) della LX9 sulla scriviania, ti riporto quanto dice il foglietto (Welcome Letter) all'interno:

Your development kit includes:
- Spartan-6 FPGA LX9 MicroBoard ..
- Xilinx ISE Design Suite (IDS) 14.5 DVD
- WebPACK Edition
- ChipScope Pro (device-locked to XC6SLX9)
- SDK (device-locked to XC6SLX9)
- Documentation ..
- Online Documentation ..


Puoi quindi utilizzare la licenza ChipScope Pro solamente coi dispositivi XC6SLX9, visto il prezzo e la presenza di una Spartan 6 da 9k LEs potresti probabilmente consigliare l'acquisto al tuo amico.

Inoltre la presenza di memoria LPDDR da 64 MB con il controllore di memoria integrato nella Spartan-6 potrebbe ampliare le applicazioni del SoC in futuro.

Re: debug hw, SoC fuori controllo

PostPosted: 06 Jul 2014, 13:49
by legacy
See come no, gia' quel coso esplode nel fare moltiplicazioni, divisioni, ma pure semplici Load/Store, anzi, in certe condizioni sono buggati pure i branch ('namo bene, proprio bene, eh?), figuriamoci cosa succede ad aggiungerci una DDR :lol:

Ma, conformandomi al suo metodo scientifico posso pure provare a propinargliela, "giusto per vedere che succede e come va a finire", perche' c'e' una scienza puramente empirica da queste parti :lol:

OK, ma che board sarebbe ? Roba Digilent ? Pazzesca pero' la trovata commerciale di questa licenza.

Re: debug hw, SoC fuori controllo

PostPosted: 06 Jul 2014, 13:59
by Leonardo
Se ha problemi col il Load/Store il futuro per la DDR sarà magari molto remoto :D

La board è prodotta da AVNET, membra ( di livello Member :) ) del programma Xilinx Alliance Program http://www.xilinx.com/alliance/

Qui trovi ulteriori informazioni previa registrazione al sito:
http://www.em.avnet.com/en-us/design/drc/Pages/Xilinx-Spartan-6-FPGA-LX9-MicroBoard.aspx

Re: debug hw, SoC fuori controllo

PostPosted: 08 Jul 2014, 20:25
by legacy
@Leonardo
board suggerita, ci sta pensando e ci fara' sapere

@deluca
ma come avete condotto la validazione ? e per le istruzioni nuove, aggiunte alla ISA Avr8, come vi siete regolati ?

con oggi siamo a quota 17 bugs hw, 3 in fixing, 2 fixed: scovarli grazie al fw e' dura, metterli a posto in HDL e' molto piu' dura, serve qualche suggerimento.

Re: debug hw, SoC fuori controllo

PostPosted: 10 Jul 2014, 13:15
by deluca
@legacy,
a che punto sei con il debug del soft-core?

noi siamo ripartiti con lo sviluppo di un nuovo ip-core.....ma dedicato al motion-control di un x-ray scanner.

Re: debug hw, SoC fuori controllo

PostPosted: 10 Jul 2014, 14:03
by legacy
bah, si procede a tentoni, ci sono 17 bugs hw noti e altri probabili, i 3 + gravi sono fixed, gli altri ancora da risolvere, praticamente adesso si riesce quasi a sfruttare una compilata -O2 che impiega la pipeline a regime senza dover stallarla a mano forzando nop ovunque, resta qualche pasticcetto ma direi che serve un approccio decisamente diverso per venirne fuori, io pero' ho aperto questo thread perche' vorrei capire come procedete voi per sviluppo e validazione, e pure la questione della toolchain per l'aggiunta di istruzioni alla ISA di partenza.

Re: debug hw, SoC fuori controllo

PostPosted: 10 Jul 2014, 14:29
by deluca
@legacy,
la toolchain usata è la classica gnu di atmel, sotto avrstudio, se non ricordo male è la 3.4 e qualcosa.
ora visto che dovremmo usare il core per gestire la movimentazione di un grosso spettrometro di massa(in ambiente
un pò attenzionato !!), abbiamo incaricato uno studente di ing di stressare il soft-core e vedere di trovare bugs hw durante la presenza fascio. Io schedino fpga riceve molti dati dal campo, interlock vari, encoder, sensori di
prossimità e si interfaccia con due inverter di potenza che pilotano 2 grooooossssssssi motori trifase che fanno muovere l'apparato. ti mostro una foto.
magnex.jpg
magnex.jpg (77.11 KiB) Viewed 11641 times

Re: debug hw, SoC fuori controllo

PostPosted: 10 Jul 2014, 15:21
by legacy
brrrrr quel coso fa pura :o

ma non dicevi che avete aggiunto delle istruzioni alla ISA Avr8 ? Se si, come fate a gestiverla questa faccenda da gcc-avr8 visto che il suo machine code-gen non le prevede, e questo visto che la ISA di riferimento e' quella Atmel Avr8 appunto ?

Re: debug hw, SoC fuori controllo

PostPosted: 10 Jul 2014, 19:09
by Leonardo
@legacy: ti lascio un esempio in Assembly per inserire del bytecode custom

Code: Select all
; esempio "legacy" :)
LDI r16, 0x3
MOV r17, r16      
LDI r16, 0x5
; ora r17 = 0x3
; specifico bytecode prossima istruzione: 0x2F10
; NB: corrisponde all'istruzione MOV r17, r16
const: .DW 0x2F10   ; r17 = 0x5