ModelSim e alee?

[flz47655]

Ciao a tutti,
Ho completato la mia prima CPU in VHDL, una soddisfazione incredibile!
L'ho simulata con successo ma non ho capito cosa vuole dire un segnale colorato di rosso in ModelSim:



Ho notato che il registro che viene segnato in rosso ha un cambio di più bit in contemporanea, è forse un'aleea o qualcosa del genere? Come è possibile nel caso eliminare il problema?

Il registro in questione è una SRAM sintetizzata con normali flip-flop, la scrittura di un dato in memoria comporta un cambio di più bit e sembra richiedere due colpi di clock per stabilizzare il segnale..

PS: Mi basterebbe anche la keyword giusta per cercare il problema su google, scrivendo "modelsim alea" non viene fuori nulla purtroppo..

[deluca]

flz,
da quello che tu descrivi, nel caso si trattasse di un effetto dovuto ad alee di tipo dinamico, dovrebbero esserci segnali in ingresso instabili o indefiniti.
da quello che noto dal grafico questo non sembra avvenire.

quindi:
hai provato realmente a sintetizzare e spedire il bit-stream su chip?

nel caso peggiore, nel caso in cui l'effetto si presentasse sul chip reale, potrebbe essere legato ad una complessità logica talmente elevata che il sint durante la minimizzazione introduce alee di tipo logico,
ma non penso sia il caso del tuo circuito.

Che ne dici di postare il codice?

ciao

[flz47655]

Grazie per la risposta,
Ho provato a sintetizzare il tutto su EPM7128SLC84-15 e mi sembra che c'è qualcosa che non va, allego il codice.

Le entità sono:
CLKDIV genera un clock di 4 KHz a partire da 33 MHz
LRAM ram sincrona contenente le istruzioni e i dati del programma
LCPU cpu minimale ad 8 bit
SYSTEM entità che collega i componenti tra loro

Il programma (fisso e contenuto nella ram) che viene eseguito è molto semplice ed utilizza tutte le 4 istruzioni della CPU minimale (probabilmente non ha neanche un insieme completo di operazioni logiche al momento):

LOAD ADDR 4
ADD 5
STORE ADDR 4
JMP ADDR 0
ADDR 4 = 170

In termini RTL

REG <= M[4]
REG <= REG + 5
M[4] <= REG
PC <= 0

All'indirizzo 4 della memoria è contenuto il valore 170.
Partendo dal valore 170 viene quindi incrementato il registro REG di 5 in continuazione.

Ho analizzato le uscite con un analizzatore di stati logico che ho costruito con la porta parallela e c'era discordanza con la simulazione, tra poco (il tempo di ricollegare tutto) allego lo screenshoot.

Ciao

UPDATE: Ho allegato la schermata dell'analizzatore logico, purtroppo non ho un vero analizzatore di stati logici e devo affidarmi al programma DigiTrace assieme ad una millefori autocostruita, a pensarci bene forse però la forma d'onda può essere corretta, avevo inizialmente scambiato le irregolarità di REG[3] con un problema ma a pensarci bene potrebbe essere anche corretta così, non è detto che sia ripetitiva su un periodo piccolo.
Ad ogni modo ModelSim segnala in rosso il segnale perché c'è un problema?

PS: Io per simulare più agevolmente commento spesso in CLKDIV il codice che divide il clock

[flz47655]

Utilizzando il programma JTagProbe per visualizzare i segnali senza collegare nulla ma tramite JTAG ho trovato i valori corretti nel registro ma non vengono aggiornati sempre con la stessa velocità, dall'immagine è possibile vedere che alcune volte il registro cambia più velocemente altre più lentamente. Anche in questo caso non saprei se attribuire il problema a JTagProbe o alla CPU.

[flz47655]

La mancanza di mezzi stimola l'ingegno.
Ho pensato di utilizzare un DAC R2R che avevo costruito (con un MCP6022 come op-amp buffer) per vedere il segnale di uscita, ecco cosa ne è saltato fuori.
Ho notato che ogni tanto sembra che c'è un "salto" troppo grosso di un valore, anche in questo caso però potrebbe essere una non linearità del DAC e quindi non si può dire con sicurezza se c'è un effettivo problema...
Nella seconda immagine all'inizio si vede il reset con il segnale che parte da 170 e sale a scatti di 5 fino a che non va in overflow e ricomincia.

[flz47655]

Se può aiutare posto la lista dei Warning alla compilazione:

Warning (13046): Tri-state node(s) do not directly drive top-level pin(s)
Warning (13047): Converted the fan-out from the tri-state buffer "LRAM:b2v_inst1|data[0]" to the node "LCPU:b2v_inst|Selector5" into an OR gate
Warning (13047): Converted the fan-out from the tri-state buffer "LRAM:b2v_inst1|data[6]" to the node "LCPU:b2v_inst|Mux23" into an OR gate
Warning (13047): Converted the fan-out from the tri-state buffer "LRAM:b2v_inst1|data[7]" to the node "LCPU:b2v_inst|Selector3" into an OR gate
Warning (13047): Converted the fan-out from the tri-state buffer "LRAM:b2v_inst1|data[1]" to the node "LCPU:b2v_inst|Selector4" into an OR gate
Warning (13047): Converted the fan-out from the tri-state buffer "LRAM:b2v_inst1|data[2]" to the node "LCPU:b2v_inst|Selector3" into an OR gate
Warning (13047): Converted the fan-out from the tri-state buffer "LRAM:b2v_inst1|data[3]" to the node "LCPU:b2v_inst|Selector23" into an OR gate
Warning (13047): Converted the fan-out from the tri-state buffer "LRAM:b2v_inst1|data[4]" to the node "LCPU:b2v_inst|Selector22" into an OR gate
Warning (13047): Converted the fan-out from the tri-state buffer "LRAM:b2v_inst1|data[5]" to the node "LCPU:b2v_inst|Selector21" into an OR gate
Warning (163076): Macrocell buffer inserted after node "LCPU:b2v_inst|reg[1]"
Warning (163076): Macrocell buffer inserted after node "LCPU:b2v_inst|reg[2]"
Warning (335095): TimeQuest Timing Analyzer does not support the analysis of latches as synchronous elements for the currently selected device family.

[legacy]

io non ho mai realizzato CPU in sintesi per la ragione che non ho mai avuto la necessita'
unito al fatto che preferisco CPU in silicio e package

pero' ho sviluppato parecchie FSM per realizzare periferiche su bus, anche bus strani e poco simpatici
quello che posso dire e' che per cercare di semplificarmi la vita ho sempre fatto tesoro degli esami di architetture
dove se volevi passare l'esame ti conveniva spezzare il problema per isole e ragionare per multiciclo grossolano

non prendevi un bel voto, spesso non era la soluzione ottima, spesso il docente storceva il naso per la "discutibile" soluzione subottimo
tanto che spesso all'orale circa le architetture finivo poi a discutere
di come si poteva eventualmente risolvere passando dalla microprogrammazione (IJVM CPU, o peggio ancora 68020 CPU)
piuttosto che soluzioni raffinatissime per il single cycle (MIPS moderni)


io puntavo sul mio cavallo sicuro: multi ciclo, per step grossolani, abusando spesso delle fasi di assestamento dei segnali
abusando spesso delle sincronizzazioni ma con la garanzia che cosi' facendo almeno non mi sarei imbattuto in problemi strani
tra cui le alee

nel multi ciclo l'eseguzione e' spalmabile su piu' passi, fasi o step, io abbondo di step o di infra step per favorire la stabilizzazione dei segnali
ma anche per poter sfruttare un approccio metodologico in cui inserisco le contraints nel progetto di sintesi
e vedo quanto posso restringerle man man che il simulatore mi da il via libera con la sua validazione


per la lettura e per la scrittura di una static ram esterna o interna sono solito spezzare le operazioni in almeno 2 o 3 fasi
specialmente se la cpu deve leggere la ram incrementando il PC, o caricando un nuovo PC, tipica operazione di fetch
con o senza conditional o unconditional branch

quindi per me, una lettura in ram e' consumata almeno in 3 colpi di clock
al primo propago il da farsi, al secondo propago l'addr, al terzo stabilizzo i dati in lettura

estendo a 3+n colpi di clock in caso la ram esterna o il giro che fa il sintetizzatore nel sintetizzare la sram sia descrivibile in termini di "ram lenta"
lenta a propagare i dati, nel caso di ram esterna la cosa e' palese, specialmente per le vecchie ram e per le vecchie *prom
e si chiama wait cycle, in pratica quanti colpi di clock e' opportuno attendere per avere dati stabili

con queste semplici regole ho sempre passato gli esami, con voti non eccellenti (non prendi + di 28 con questo approccio conservativo)
e mi sono sempre dipandato da pasticci vari al lavoro

[flz47655]

Non devo farlo per un progetto universitario, faccio informatica non elettronica. L'argomento però mi incuriosisce a provo a fare qualcosina da solo.

Al momento ho previsto le seguenti fasi: sfetch, sread, sexec, sload, swriteback, sstore
Dici che sarebbe più saggio inserirne altre? Pensavo che con un colpo di clock si stabilizzava il tutto nella RAM (che poi sono FF dentro la CPLD). Non vorrei aggiungere fasi a casaccio che per forza di cosa rallentano l'esecuzione di un'istruzione senza prima capire bene a cosa servono.

Riporto il succo per semplicità qua sotto (trovi tutti i sorgenti nel primo post) se vuoi curiosare:

Code: Select all

case state is
   when sfetch =>               
      addr   <= pc;                              
      we <= '0';
      pc   <= pc + 1;
      state <= sread;
      data <= "ZZZZZZZZ";   -- optional
   when sread =>
      -- read from memory, data is ready next clock
      state <= sexec;
   when sexec =>            
      -- Read data
      case data(7 downto 6) is
         -- Load
         when "00" =>
            we    <= '0';
            addr    <= data(5 downto 0);
            state <= sload;
         -- Store
         when "01" =>
            we    <= '1';               
            addr    <= data(5 downto 0);
            data    <= reg;
            state <= sstore;
         -- Add
         when "10" =>                      
            reg <= std_logic_vector(unsigned(reg) + unsigned(data(5 downto 0)));
            state <= sfetch;
         -- Jump
         when "11" =>                     
            pc    <= data(5 downto 0);
            state <= sfetch;
         when others => null;
      end case;               
   when sload =>
      -- read from memory, data is ready next clock               
      state <= swriteback;            
   when swriteback =>
      reg    <= data;      -- Load write back
      state <= sfetch;   -- Fetch Next Instruction            
   when sstore =>
      -- write to memory, data is ready next clock               
      state <= sfetch;
   when others => null;
end case;               


Ciao e grazie

[filosofo]

flznnnn,
ma che linguaggio è quello che sto leggendo sopra, mi sembra una specie di bascom ma non è esattamente uguale.
puoi dirmi cosa fa questo codice?
ciao e grazie

[flz47655]

Ciao, non è un linguaggio di programmazione ma è un linguaggio di descrizione dell'hardware che serve per sintetizzare circuiti digitali con parte logiche, in pratica il testo viene tradotto in un circuito che "materializzo" su una CPLD/FPGA ma che si potrebbe anche realizzare sotto forma di circuito integrato (ASIC)
Ho costruito un semplice microprocessore, lo stralcio di codice è proprio il "succo" della CPU

Ciao

[filosofo]

non capisco
come fai a "costruire un microprocessore", non ti capisco.
io il microprocessore lo compro e in qualche modo cerco di programmarlo

non penso che un microprocessore si possa costruire in casa

o sei la atmel impersonificata

[flz47655]

Provo a semplificarti il tutto (non è completamente corretto ma è solo per farti capire): in pratica esistono dei chip che hanno tante porte logiche che si possono collegare tra loro in base alla memoria del chip, scrivendo questa memoria si possono realizzare le funzioni logiche volute.
Se vuoi approfondire cerca CPLD ed FPGA su Wikipedia e tra le slide del sito di Giovanni

Magari apri un topic dedicato all'approfondimento di cosa sono le logiche programmabili e spostiamoci li, altrimenti questo diventa un macello e non mi rispondono più..
Ciao

[filosofo]

scusa flz ma come faccio a trovare le "slide di giovanni", ma chi è costui.

(come avrete capito, stavo scherzando)

flz

[flz47655]

Dai dai fai ancora in tempo a modificare il messaggio prima che qualcun'altro legge

[filosofo]

che figura di M...da

spero che deluca non mi mandi a quel paese.

penso che dalle 22 in poi, ma direi anche prima, devo far riposare le meningi.

ciao e scusatemi

[deluca]

filosofo, perdonato, non preoccuparti.
nel forum mi conoscete tutti come "deluca"

@flz per ritornare in topic,
ho visto il tuo avanzamento lavori, e devo dire che sei sulla buona strada.
Tuttavia le istruzione basilari (stati che non possono mancare in una unità di controllo) per realizzare una cpu minimale devono essere queste che
ti elenco sotto:

-STORE (ST)
-LOAD (LD)
-aritmetiche standard (ARITM)
-salto incondizionato con un link (JAL)
-salto condizionato (JE/JS)
-salto incondizionato (JMP)
-salto ad una locazione indicizzata attraverso l'uso di registro (JR/RFI)
-di non operazione (NOP).... che non fa mai male e ti serve in quei timing che ogni tanto fanno impazzire specie nella sincronizzazione e wait-state di ram esterne più lente.

Non sono molte ma possono bastare per realizzare una unità di calcolo abbastanza complessa.

ciao

[legacy]

il consiglio di cui sopra
si vede molto bene con l'approccio a microprogrammazione
che ha valenza pratica vera
se la ISA del softcore sotto sintesi e' semplice con poche istruzioni poco ortognali, e' un approccio molto buono
usa un approccio conservativo, abbonda di step di sincronismo
e piace particolarmente al prof Andrew Stuart Tanenbaum

[legacy]

per dissipare dubbi sulla eventuali non linearita' del dac
fai una cosa, fai un module counter (a=a+n) su cold
e dai in pasto il tutto al dac, vedi subito come si comporta

[flz47655]

Grazie Giovanni per l'incoraggiamento e per i consigli, una volta capito come fare aggiungere istruzioni ho visto che diventa semplice Proverò ad implementarle ma prima volevo capire se ModelSim segnalava un problema oppure era tutto normale. La guida di ModelSim (versione gratuita di Altera) non è fatta malissimo ma mi sembra che non spende parole su questo aspetto.

@legacy: prima dicevi che tu in una lettura in ram al primo passo propaghi il da farsi, al secondo propaghi l'addr, al terzo stabilizzi i dati in lettura.
Io sostanzialmente svolgo il tutto in due passi: nel primo propago addr, write enable e data e nel secondo leggo i dati, dici che è sbagliato?

Ciao e grazie a tutti

[legacy]

-di non operazione (NOP)....
che non fa mai male e ti serve in quei timing
che ogni tanto fanno impazzire specie nella sincronizzazione
e wait-state di ram esterne più lente.

assolutamente si =D

anche se dal mio punto di vista cio' vale + per i MIPS (superscalari) che non per altre cpu
i MIPS hanno internamente cop0 con n slot di ritardo, impiego fino a 5 colpi di clock
per chiedere al cop0 quale e' il motivo di una exception, solo il cop0 me lo puo' dire
e sono costretto a mettere 5 nop altrimenti lui, che ha i suoi tempi, mi risponde cose a caso

pero' il cop0 e' dentro la cpu, quando ho rogne fuori la cpu
e' tanto meglio cercare di rifilare il problema al BUS
implementando BUS rognosi si, ma che prevedono meccanismi di ack
e cosi' la cpu sta buona e ferma fino a che la ram lenta non gli dice che ha finito
in questo modo regoli il problema in hw e non in sw

prendi le vecchie EEPROM, hanno tempi giurassici per stabilizzare un address, indirizzare le celle giuste
e stabilizzare il dato in risposta, tempi ancora + giurassici per alzare il campo elettrico interno da 5V a 12V
indirizzare le celle, stabilizzare i floating gate dei transistor di cella, e finire di scrivere il dato

qui quante nop dovrei mettere ? tempo fa mettevo dei for (i=0; i<WAIT_CYCLE; i++) { i++; asm("nop"); }
definendo volatile i; perche' altrimenti il compilatore mi ottimizzava il tutto srotolando il ciclo con una sola nop

poi siccome mi ero rotto di questi problemi software, e ogni persona che mettava mano al mio codice sceglieva WAIT_CYCLE come voleva
ho iniziato a spostare la soluzione verso l'hw =P