debug hw, SoC fuori controllo

[legacy]

bah, io pensavo ad una modifica alla machine layer (llvm/g.cc code_gen + controparte g/as), in modo che sia lo stesso compilatore C a potersene avvalere quando e' opportuno, non ad opcode inseriti tramite troian horses

[deluca]

@legacy,
quell' oggettino di qualche decina di tonnelli, fa paura a tutti.
pensa che fino a qualche gg fa occorreva salirci sopra per manovrarlo e cambiare angoli di incidenza fascio andando ad azionare i comandi posti in locale sugli inverter. Ovviamente si poteva fare il tutto in assenza fascio.
Con il nuovo sistema dovremmo muoverlo in sicurezza anche in presenza fascio..... "almeno si spera".

[legacy]

@deluca
sui vostri SoftCore avete implementato una jtag tap machine o altro sistema, p.e. BDM, nexus, etc ?
Sto meditando se sia il caso o meno di sfruttarla per la validazione, intendo per monitorare il CPU context prima e dopo ogni istruzione in modo da stanare quali combinazioni soffrono ancora di hazard critiche (finendo per sporcare i registri, compreso lo stesso cpu.reg.PC)

Ho beccato altri bachi di questo tipo e temo ce ne siano molti altri: se fornisco una lista dettagliata al mio amico "forse" c'e' la possibilità di un bug fix di massa.

[deluca]

@legacy
scusa la mia curiosità,
ma visto i numerosi bugs che stai incontrando.... quale sarebbe la provenienza del codice vhdl del soc?.
Per quali scopi è stato descritto: educativo, commerciale, tesi, altro? il rilascio è free o è black-box?
Cioè, è stato il tuo amico a descrivere l'hardware o è di 3rd dubbia provenienza.

Noi eseguiamo debugging con strumenti tradizionali usando LA e trace jtag, come si fa di norma con i uC/uP classici. Certo, forse il nuovo MSO9104 della agilent che abbiamo acquistato l'anno scorso non è da ritenersi proprio tradizionale, visto il costo, ma di norma perlustriamo in questo modo.

[legacy]

@legacy
ma visto i numerosi bugs che stai incontrando

lui ha sempre impilato le classiche istruzioni assembly-cavia attorno alle quali tutto stava in piedi, i disastri che ho trovato io sono dovuti a ricombinazione del codice propria del contesto reale, ovvero codice che esce dalla catena di compilazione, e possibilmente ottimizzato, ovvero rimescolato, quindi tale da mettere in luce molte delle casistiche per le quali p.e. (un classico da quanto ho visto fino ad ora, ce ne sono altre di casistiche) ci possono essere delle hazards nella pipeline con conseguente corruzione del contesto da cui, macroscopicamente, si ha l'unexpected behavior.

@legacy
quale sarebbe la provenienza del codice vhdl del soc?

e' un lavoro iniziato con me in erasmus, lui e' tedesco, io italiano, eravamo allo stesso corso in UK, io mi sono fermato all'elaborato, ovvero ho scritto una robina minimale per passare l'esame e fine dei giochi, lui e' andato avanti fino ad arrivare alla implementazione pipeline, sicche' eravamo in gruppo assieme, gruppi di 2 persone ad elaborato, ma del mio codice (che era single cycle, non di certo pipelined, non per un elaborato), in pratica, non resta quasi nulla, anzi volendo quantificare: di mio codice resta solo la seriale, e nemmeno con FIFO, tutto il resto l'ha riscritto, cambiato, eliminato, ecc.

@legacy
Per quali scopi è stato descritto: educativo, commerciale, tesi, altro?

educational, non ha senso alcuno parlare di SoC a scopo commerciale: salvo pochi contesti di super nicchia direi che si fa molto prima ad infilare una FPGA accanto ad una CPU ASIC che a mettere le mani in lavori di questo tipo, sopratutto in termini di ore uomo/risorse/etc.

@legacy
il rilascio è free o è black-box?

non credo che si parli di rilascio, cmq la decisione e' sua, a me interessano le 12 casse di birra (e parliamo di birra tetesca) che mi ha promesso.

@legacy
Noi eseguiamo debugging con strumenti tradizionali usando LA e trace jtag

per il jtag avete quindi implementato in FPGA anche la jtag TAP machine, come vi regolate al lato host ? e sopratutto cosa usate ?

@legacy
come si fa di norma con i uC/uP classici. Certo, forse il nuovo MSO9104 della agilent che abbiamo acquistato l'anno scorso non è da ritenersi proprio tradizionale, visto il costo, ma di norma perlustriamo in questo modo

non ne ho idea alcuna, io sfrutto jtag e BDM quasi solo per attività debugging firmware, non ho mai avuto a che fare con validazioni rtl della CPU.


ma per esempio, per essere sicuri che la pipeline sia correttamente stallata -quando/come/dove- serve, come vi regolate ? Fate/avete fatto pesante attività di simulazione con testbench per ogni modulo ? Poi a seguire una sessione di integrazione ?

Qui stiamo giocano modi cow boy, ovvero "priviamo direttamente" sull'hw, il che e' sbagliato per metodologia, io ne sono consapevole, lui un po' meno, tuttavia per entrambi compatibile con i ritagli di tempo e con il know/how attuale.

[legacy]

bene bene, molto bene, ci siamo inventati un metodo basato totalmente sul simulatore RTL per estrarre il regsdump (dump di registri CPU) ad ogni ciclo, questo (compatibilmente con i casini della pipeline) e' + o - utile per capire se c'e' o meno una corruzione del cpu context: messi a posto altri 3 bachi che riguardavano, ancora una volta, proprio pasticci di questo tipo.

Forse quest'affare vedra' la luce fuori dal tunnel (forse )

[legacy]

ma quindi, nessuna indicazione ?

[Leonardo]

Visto che si è parlato di verifica dell'hw segnalo l'articolo "Intel Nehalem Processor Core Made FPGA Synthesizable" che ha un paragrafo "Verification Methodology" che può insegnare qualcosina.

Esiste anche un precedente articolo "Intel Atom Processor Core Made FPGA-Synthesizable"

Leonardo

[legacy]

dopo 1 anno circa, adesso + o - le cose funzionano come ci si aspetta, ed e' un buon risultato considerando che non abbiamo impiegato risorse uomo ed attrezzatura che non possiamo, ne avremmo potuto, permetterci.

ci ha dato una mano un protocollo di debug, tap e relativi tools (compreso codeflow) che avevo disegnato ai tempi della uni (tesi L2), pero' e' fondamentale anche il simulatore RTL: il debugger ti da informazioni macroscopiche sul contesto (e sullo stato del bus e ram), tutte le informazioni sui segnali sono a lui nascoste, ma non al simulatore, che pero' senza il mirino del debugger non saprebbe dove rivolgere le sue attenzioni e quindi noi avremmo in mano troppi dati. Decisamente troppi per le nostre scarse risorse.

Si fa quel che si puo', in lista siamo a 119 bachi, risolti 117, 2 ancora latitanti (riguardano la cache ed e' difficile riprodurli).

intanto, mi porto gia' a casa una cassa di birra