ModelSim e alee?

[legacy]

@fiz

non e' questione di sbagliato o giusto, potrebbe anche funzionare
diciamo che dal mio punto di vista salti uno step, io l'avrei messo
e poi eventualmente l'avrei rilassato

ma te lo deve dire il motore di sintesi, e per dirtelo devi chiederglielo
e per chiederglielo devi mettere delle constraints e vedere che ti dice

e' l'approccio su cui hanno insistito fino alla nausea in erasmus
davvero non so quante 1K di volte ce l'hanno detto e ridetto =P

[flz47655]

Per verificare seriamente il progetto ho messo da parte le CPLD e ho tirato fuori la FPGA seria che mi riservo per le grandi occasioni (DE0-Nano con Cyclone IV)
Sulla dev-board ho collegato il registro REG ai led così da poter vedere con soddisfazione il registro cambiare ho collegato il RST al pulsante con debouncing

Con SignalTap (analizzatore di stati logici via JTag) ecco cosa ho ottenuto:

Sembra tutto funzionare perfettamente, il problema di alcune istruzioni più veloci altre più lente individuato da JTagProbe probabilmente era dovuto evidentemente a qualche suo limite di velocità.
Ma ad un certo punto.. dopo l'ennesimo reset tutto è "impazzito", sono riuscito per fortuna a catturare cosa succedeva con SignalTap:

O il reset al momento sbagliato ha interferito con SignalTap ed è impazzito tutto o esiste purtroppo una qualche condizione critica..

Ciao

EDIT: Ho notato che WE sembra non cambiare nel caso pazzo..

[flz47655]

@legacy: non ho nessuna constraints, la fmax è limitata solo dal toggle rate dei pin, quindi è al massimo 250 MHz
Forse inizio a capire.. ModelSim si arrabbia perché è cambiato sia WE (Write Enable) sia Data e questo può comportare una sorta di corsa critica.. mmh.. dovrò rifletterci..

[legacy]

appunto, lavorare senza constraints nel progetto non va bene, devi averle
il requisito di progetto minimo e' garantire i tempi di propagazione
cioe' essere sicuri che i dati e i controlli si siano propagati in modo corretto
e per esserne sicuri vanno messe constraints che tengano conto anche e sopratutto
del giro che il motore di sintesi dovra' fare e quindi dei ritardi veri che introduce

quindi dei tempi di propagazione + grossi e cicci di quanto si pensi
e di quanto si legga sulle blande specifiche del datasheet della logica di sintesi

devi avere constraints, ing parlando si dice con fatto eng K, cioe' gonfiati per essere sicuri
in ogni caso hai dei numeri davanti che solo cosi' puoi usare come paletti per procedere per passi sicuri
in modo deterministico, tutto funziona sempre e sempre allo stesso modo (concetto dei QA)
senza che ci siano condizioni esoteriche per cui si verificano hardware hazard

in questo caso mi sa che la seconda logica programmabile ha tempi di propagazione
nettamente inferiori ai tempi della prima logica che hai usato
e altra cosa, + rilevante, il motore di sintesi potra' sfruttare meglio le celle per evitare problemi di concorrenza
ci riesce, e per pura fortuna tutto va bene
se avessi avuto constraints nel progetto ti saresti bloccato a meditare
se mettere o meno un altro step, e alla fine, provando a rilassarle
secondo me avresti deciso di lasciarlo, quindi l'avresti messo

io infatti l'avrei messo subito, ma perche' so che non e' la prima volta che
vedo un circuito apparentemente funzionare
poi lo lasci a macinare 100G di operazioni di scrittura e lettura in ram
e per la legge dei grandi numeri si verifica che 1 operazione su 100G operazioni
non va a buon fine e la ram porta un dato corrotto, e il motivo ?
il wait_cycle era troppo breve, per 100G volte -1 e' andato bene
alla 100Gth volta la legge dei grandi numeri ha colpito duro

puoi avere anche problemi di concorrenza
e si puo' progettare in questo modo e vivere con la paura di p(%) di disastro ?
cosa succede se quel dato e' proprio il PC di ritorno da function ?
(se chiami la funzione pippo(), metti sullo stack il PC attuale in modo che lei sappia dove saltare al ritorno)
succede che leggi dallo stack in ram quell'indirizzo e quell'indirizzo non lo leggi giusto
salti chissa' dove, perdi il controllo del target, tutto impazzisce e non sai da che parte girarti

i geniacci delle architetture sanno farne a meno
vari progetti softCore vedono il genio di gente che sa prevederli ed aggirarli, ma la gente comune no
ed ecco perche' nei corsi in erasmus si proponeva approccio fortemente conservativo
con le indicazioni di cui sopra =P

[legacy]

istruzioni più veloci altre più lente individuato da JTagProbe probabilmente era dovuto evidentemente a qualche suo limite di velocità.

il jtag e' sincrono con il core per definizione, c'e' un frame datain buttato dentro nella jtag TAP machine
che colpo di clock dopo colpo attraversa tutta la TAP machine di tutta la macchina sotto esame uscendo poi con un frame dataout
il tutto e' scandito non a casaccio ma proprio dal clock
ergo se vedi cose bizzarre non e' colpa del jtag

oppure il sw che lo controlla funziona davvero malissimo
perche' per seguire il target (e qui si vede la differenza fra un jtag veloce, con buffer e banda e un jtag giocattolo)
pilota la tap machine scartando di proposito a casaccio frames in uscita perche' non saprebbe come farli arrivare sull'host
dato che non ha banda ne buffer adeguato per farlo

[flz47655]

Ok, ma io non ero a fare prove estreme di overclock TimeQuest mi dice che nel caso peggiore la frequenza massima a cui può girare il tutto con SignalTap II instrumentato è (fmax) 121.48 MHz, io sulla scheda ho un clock da 50 MHz.. il primo blocco è un divisore che porta il clock a 100 Hz in modo che posso vedere i led lampeggiare (ogni istruzione necessita di diversi clock quindi i led lampeggiano più lentamente) quindi non penso proprio in problemi di questo tipo.

Per quanto riguarda il JTAG quando usavo con la CPLD JTagProbe avevo un clone giocattolo che evidentemente non aveva troppa banda.. con SignalTap uso il JTAG a bordo della dev-board (una CPLD invece del Cypress del clone)

Ciao

[legacy]

mi piacerebbe sapere cosa ne pensa DeLuca

[deluca]

@FLZ, ecco cosa penso,
la soluzione è molto semplice..................
mai in queste situazioni integrare in un unico processo le funzioni di FSM e l'output-logico.

Crea 2 processi individuali di questo tipo:

next_state_logic: PROCESS(Reset, Clock) --per il salto degli stati e un

output_logic: PROCESS(state) --per il setting degli IO.

Maiiiiii !!!, soprattutto quando si ha a che fare con un control-unit di un micro.
Non so su che testo hai per le mani ma per esperienza personale, dopo aver realizzato decine e decine di control-unit con FSM, mi sono reso conto che la strada giusta è quella di suddividere il codice.
Una cosa è l'FSM degli stati, una cosa è il processo con il sensitive-list (state) di output_logic....
Prova a suddividere i due processi e vedrai che troverai la strada per risolvere i tuoi problemi.

ciao

[legacy]

il consiglio che ti avevo dato io passa dallo spezzare su piu' steps
il consiglio che ti ha dato Deluca e' di spezzare su due processi individuali
il consiglio di Deluca e' migliore, e lo puoi vedere come uno step intermedio gestito in modo esplicito dal motore di sintesi
entambi mirano a far si che il progetto non sia vulnerabile a problematiche di tempi di propagazione e hazard races


p.s. grazie Deluca

[flz47655]

Ho eliminato il "warning" segnalato da ModelSim con una semplice modifica:

Code: Select all

case state is
   -- ...
   when sexec =>            
      -- Read data
      case data(7 downto 6) is
         -- ...
         -- Store
         when "01" =>
            we    <= '1';               
            addr    <= data(5 downto 0);                     
            state <= sstore;
         -- ...
      end case;                  
   when sstore =>
      -- write to memory, data is ready next clock                        
      data    <= reg;
      state <= sfetch;
   when others => null;
end case;


Ho semplicemente spostato:

Code: Select all

data <= reg;

Nello stato sstore in quanto in sexec si accedeva già a data per leggere l'address

Ora che ci penso avevo già avuto dei dubbi a proposito http://www.delucagiovanni.com/public/phpbb3/viewtopic.php?f=10&t=334 è passato un pò di tempo e me ne ero scordato

La modifica è stata semplice (e spero sia quella giusta) ma credetemi trovarla è stato faticoso, ho stampato le forme d'onda di ModelSim e ho analizzato tutto quanto a mano, ho fatto con carta e penna il grafo degli stati (ok lo fa anche Quartus ma l'ho fatto personalizzato) e vedendo il codice VHDL ho controllato cosa potesse essere andato storto.

Ad ogni modo ho riscritto il tutto con due processi distinti come consigliato, il risultato è sicuramente più gestibile e.. il codice degli stati non viene eseguito allo stato successivo (è un pò difficile da spiegare a parole)

Mi sono messo poi avanti per evitare che la CPU impazzisca se raggiunge uno stato imprevisto:

Code: Select all

when others =>
    state <= sreset;   -- Reset crazy CPU :)


Ecco il nuovo codice:

http://www.atomwave.com/FPGA/LCPU2.zip

e la simulazione ModelSim:

Per evitare problemi ho impostato WE (Write Enable) a 'Z' (Alta impedenza) per evitare di leggere la memoria quando non necessario (un pò un disable), spero non sia una pratica scorretta.

Non sto seguendo nessun testo in particolare, vado a memoria dalle reminiscenze del corso di calcolatori elettronici che però non trattava VHDL ma solamente qualcosa di Assembly x86. Ho letto per conto mio qualcosa di VHDL ma sopratutto sulla sintassi.
Diciamo che ho ripreso l'idea di scrivere una CPU "educativa" per non scordare quel poco di sintassi che avevo imparato. L'idea era nata dopo aver analizzato il progetto MCPU http://opencores.org/project,mcpu che però non avevo trovato molto immediato perché mancava la RAM e quindi non era possibile farlo girare e poi se non si scrive qualcosa da soli from scratch non si impara veramente.

Ciao e grazie a tutti

[flz47655]

Ricapitolando il problema mi sa che non era tanto che si accedeva già a data per leggere l'address ma che dopo aver impostato WE ad 1 bisognava aspettare 1 clock prima di applicare i dati.

Ecco perché alcune RAM hanno una porta IN ed una OUT.. si evita inoltre di usare 'Z' che mi sembra che non è consigliato..

PS: Queste conclusioni non sono del tutto farina del mio sacco.. ma ci ero andato quasi vicino ed avevo comunque risolto .. spero

[peter90]

Ciao a tutti,
sto cercando di trovare il tempo di imparare il vhdl.
di tanto in tanto vi ho fatto qualche visitina, ma spero tra non molto di essere più presente e magari rompervi le scatole.
Ho visto che il forum si è espanso e gli argomenti sulle fpga e sul vhdl sono aumentati.

La cosa che mi incuriosisce è il progetto di flz, cioè realizzare un micro generico in vhdl.
vedi mio topic: viewtopic.php?f=10&t=249

flz, lo so che forse chiedo troppo,
SEI IN GAMBISSIMA e ti invidio un pò,
ma saresti così gentile da postare il progetto e spiegare passo passo come importare questo tuo progetto in modelsim per visualizzare la simulazione
come hai mostrato sul forum?


Io ho installato quartus II versione 12 free e Modelsim-altera ma sto facendo fatica a simulare il tuo progetto.
Vorrei capire come si arriva alla tua simulazione... ma proprio passo passo.

Ti ringrazio tanto se vorrai mettere a disposizione della comunità queste informazioni.

ciao a tutti

[flz47655]

Ciao peter90,

Competenze sulle logiche programmabili (non io ma il nostro caro admin Giovanni e qualche utente sono veramente esperti) sono quello che sicuramente differenzia questo forum da tutti gli altri (e recentemente ha riscosso successo anche bascom-avr).

ModelSim è una brutta bestia da domare, sopratutto all'inizio. Dopo aver incontrato tante difficoltà avevo scritto un tutorial in italiano con tante immagini che può essere un inizio per prendere dimestichezza con ModelSim: http://www.delucagiovanni.com/public/phpbb3/viewtopic.php?f=10&t=239

Per fare prima a simulare inserisco questi comandi (con un unico copia/incolla) nel Transcript di ModelSim dopo aver premuto RTL Simulation in Quartus (prova a seguire il tutorial prima però per prendere familiarità col programma):

Code: Select all

vsim work.system
add wave sim:/system/*
force -freeze sim:/system/clk_synth 1 0, 0 {50 ps} -r 100
force -freeze sim:/system/rst 0 0
add wave  \
sim:/system/b2v_inst/reg \
sim:/system/b2v_inst/pc \
sim:/system/b2v_inst/state
run
force -freeze sim:/system/rst 1 0
run


In pratica le righe dicono di utilizzare la libreria work e aggiungere alla finestra Wave tutti i segnali interessanti, impostare un clock al segnale clk_synth e impostare prima a 0 e far girare la simulazione e poi ad 1 il segnale rst in modo da concentrarsi direttamente sulla CPU già inizializzata

Ho in programma anche di scrivere un tutorial super passo-passo sulla creazione e simulazione di una piccola cpu didattica, però dovrai aspettare un pochino..

Trovi i file VHDL da aggiungere ad un progetto Quartus qui: http://www.atomwave.com/FPGA/LCPU2.zip

Ciao

[peter90]

@flz grazie, funziona perfettamente !

ho sintetizzato per cyclone ep1c6 e tutto passed
aprendo la simulazione RTL mi porta su Modelsim e dopo aver fatto copia e incolla del tuo script è partito un ciclo di simulazione.
però devo dare tanti run per vedere in sequenza sul wav il cambiare degli stati.
Come avvio una lunga simulazione con Run -all giusto?

grazie ancora, e spero, se ne sarò in grado, quanto prima di ricambiare l'aiuto.
ciao

[flz47655]

Ciao, tutto quello che fa lo script puoi farlo coi pulsanti ma così fai prima
Io in genere aumento il tempo per dover fare meno run, ad esempio da 100pS a 1000pS, comunque in base a cosa voglio verificare. Con Run -all simula finche non lo si ferma.
Imposto anche dei breakpoint sui process per fermarmi ai punti desiderati ma questo forse è un po' più avanzato se hai appena cominciato, te lo racconto magari un'altra volta

Ciao

[legacy]

Ricapitolando

eri in hazard race

Ecco perché alcune RAM hanno una porta IN ed una OUT

Non ram, ma registri, registri CPU
li puoi vedere come una piccola ram, un array uint32_t cpu_reg[reg_N]
e in quel caso si puo' fare qualcosa per risparmiare cicli, quindi performance design oriented
tanto sei dentro la cpu e puoi gestirti il data path come vuoi

negli altri casi e', secondo me, ... sconsigliato.

mmmm, ora che mi viene in mente
c'e' anche un altro caso secondo me che ha senso considerare
se hai un design di CPU a microcodice (solitamente una cpu CISC)
quello schema va bene anche per descrivere la microROM del microcodice
altri casi non mi vengono in mente ...

[flz47655]

appunto, lavorare senza constraints nel progetto non va bene, devi averle
il requisito di progetto minimo e' garantire i tempi di propagazione
cioe' essere sicuri che i dati e i controlli si siano propagati in modo corretto
e per esserne sicuri vanno messe constraints che tengano conto anche e sopratutto
del giro che il motore di sintesi dovra' fare e quindi dei ritardi veri che introduce

Avevo provato tempo fa a usare TimeQuest ma mi ricordo che non era così semplice.. ad ogni modo io avevo capito che durante la compilazione nel report veniva calcolato un valore fmax corrispondente alla frequenza massima con cui far girare il tutto senza avere problemi anche senza mettere nessuna constraints custom ma lasciando le impostazioni di default (che mi sembrano impostano il clock ad 1 GHz come constraints).

PS: Se continui a modificare a posteriori i post precedenti perdo gli aggiornamenti, sopratutto quando iniziano ad esserci tanti post in un topic..

[legacy]

se trovo degli appunti del corso te li giro
come usare le constrains in un progetto
e' un discorso lungo e contorto
sopratutto se applicato a Quartus

[legacy]

valore fmax corrispondente alla frequenza massima con cui far girare il tutto senza avere problemi anche senza mettere nessuna constraints custom

come avrai ormai intuito non centra la fmax con il problema delle hazard race

prima ti ho parlato dei tempi di propagazione ma non intendevo quello che intendi tu
semplicemente il fatto che a te e' andata bene, hai avuto un segnale che si diramava
impiegando tempi diversi (per via delle celle da attraversare) per arrivare a destinzione

e il risultato e' che avevi un enable che arrivava per pura fortuna nel modo giusto per gestire i dati
e questo grazie ai tempi di propagazione e a routing fatto

gia' di questo fatto il motore di sintesi ti fa notifica,

e cosi' sai che mettendo uno step in piu' puoi sincerarti della giusta sequenza temporale
dal punto di vista della fsm e' uno stato in piu'

tu avevi un macrostato in cui facevi due cose in concorrenza
eri percio' in corsa critica, per analogia lo stesso problema che si ha con i sistemi operativi
quando tocca gestire la concorrenza di n oggetti che si contendono una risorsa

[flz47655]

In realtà non so ancora se è andata bene, ho fatto una simulazione RTL, ora provo a farne una Gate Level e provo a rigiocare con TimeQuest per vedere se riesco a combinare qualcosa..

Ti posso chiedere se conosci qualche libro che puoi consigliarmi su VHDL? Tutti quelli che ho visto partono dalle basi ma non arrivano molto avanti, parlano delle solite cose, multiplexer, decoder, FSM, etc.. ma non trattano problemi di timing in modo approfondito ne spiegano i tools

UPDATE: La simulazione Gate Level è un massacro, ci sono tantissimi segnali generati dal sintetizzatore.... mi ci vuole calma e devo analizzare la rete generata, spero di saltarci fuori..