delucagiovanni forum

Ciao!
Ho un dubbio sull'utilizzo di variabili e segnali. Ho capito che le variabili vanno utilizzate solamente all'interno di un processo e il loro valore viene aggiornato immediatamente. Alla fine del processo però il valore finale viene conservato? E per quanto riguarda un segnale invece? In particolare vorrei creare una FSM che carica un valore da un registro, somma una certa quantità a questo valore e poi riscrive il tutto nel registro. Questo ciclo vorrei che continuasse fino ad una certa soglia, ripartendo dal primo stato ricaricando il valore (aggiornato della quantità sommata fino ad ora). La lettura/scrittura del registro pensavo di pilotarla con due segnali provenienti dalla FSM.

Ho pensato di usare una variabile per assegnare il valore letto, incrementare quindi la variabile e infine assegnarla al segnale in uscita verso il registro. E' corretto?

Grazie della pazienza,
un saluto!

Salve Giacomo,

Ho capito che le variabili vanno utilizzate solamente all'interno di un processo e il loro valore viene aggiornato immediatamente. Alla fine del processo però il valore finale viene conservato? E per quanto riguarda un segnale invece?

Alla fine del processo il valore delle variabili viene conservato ma non è visibile fuori dal processo ove dichiarate.
Nei segnali il valore viene conservato ed è visibile anche ad altri processi.

E' possibile utilizzare le variabili e assegnare il valore ad un segnale per renderlo disponibile all'infuori del processo.

NB: Esistono anche le cosiddette variabili condivise o shared variable ma sono un argomento un pochino più complicato.

In particolare vorrei creare una FSM che carica un valore da un registro, somma una certa quantità a questo valore e poi riscrive il tutto nel registro. Questo ciclo vorrei che continuasse fino ad una certa soglia, ripartendo dal primo stato ricaricando il valore (aggiornato della quantità sommata fino ad ora). La lettura/scrittura del registro pensavo di pilotarla con due segnali provenienti dalla FSM.
Ho pensato di usare una variabile per assegnare il valore letto, incrementare quindi la variabile e infine assegnarla al segnale in uscita verso il registro. E' corretto?

Si, puoi realizzarlo in quel modo o con soli segnali.

Ciao

Ho capito, grazie Leonardo! Mi rimane però un dubbio: se i segnali mantengono il loro valore, devo implementare io i registri che lo tengono memorizzato o faccio a meno?

Non c'è bisogno. Al limite bisogna stare attenti a non creare latch involontari coi segnali, sopratutto nei processi con if..then

Leonardo wrote:Non c'è bisogno. Al limite bisogna stare attenti a non creare latch involontari coi segnali, sopratutto nei processi con if..then

Perfetto. Se per caso dovessero essercene dovrei vederlo dalla vista RTL giusto?

Si, ma più semplicemente il tool che utilizzi (ad es. Quartus) dovrebbe darti dei warning.

Ho risolto il problema, ti ringrazio! Ps. Per caso sei a conoscenza di un software che fornisca una codifica con distanza di Hamming 1 per stati adiacenti in una FSM? Mi ritrovo con dei glitch sugli stati e una FSM dalle dimensioni proibitive per farlo a mano..

Intendi opzioni come: http://quartushelp.altera.com/12.1/mergedProjects/logicops/logicops/def_smp_process_type.htm ?
Le tempistiche del progetto (visionabili con TimeQuest) sono a posto?

Si, qualcosa del genere. Però, anche selezionando la codifica di Gray, Quartus non tiene conto delle "transizioni di ritorno" secondarie. Mi spiego: se ho una catena di stati in cui l'ultimo torna al primo (o ad uno intermedio) la codifica proposta non è sicura per la transizione dall'ultimo al primo che, svolgendosi in un solo ciclo di clock, porterà ad uno stato non voluto tra i due..

hai provato con one-hot?

Il problema si verifica solamente a run-time o è visibile anche nella simulazione gate-level?
Se non sei riuscito a risolvere cosa ne diresti di postare un piccolo esempio in grado di riprodurre il problema?

@sgranfius,
Siamo in attesa del codice......

Scusate sono da mobile e non riesco a postare il codice fino a stasera...

Code: Select all

entity Input_Manager is
   port (
      clk25 :                     in std_logic;
      reset :                     in std_logic;

      frameoff :                          in std_logic;
      sync_pad :                          out std_logic;
   
      up :                         in std_logic;
      down :                      in std_logic;

      y_PadIN :                          in std_logic_vector (8 downto 0);
      y_PadOUT :                          out std_logic_vector (8 downto 0);
      
      state_test :                       out std_logic_vector (3 downto 0)
   );
end Input_Manager;
   
architecture IM of Input_Manager is
   --attribute enum_encoding : string;
   type stato is (w, a, b, c, d, e, f, g, h);
   --attribute enum_encoding of stato : type is ("1100 1000 0000 0010 0011 0110 0001 0100 1010");
   
   signal presentState :                      stato;
   signal nextState :             stato;
   


   constant DEFAULT_Y_PAD :                     std_logic_vector (8 downto 0) := "011101111";         
   constant edgeWidth :                        integer := 20;
   constant monitorHeight :                      integer := 480;
   constant padRadius :                        integer := 40;   
   
   begin
--   
   seq : process (clk25, reset, presentState)
      begin
      
      if (reset = '1') then
         presentState <= w;
         else if (clk25'event and clk25 = '1') then
            presentState <= nextState;
         end if;
      end if;
   end process;
   
   fut : process (presentState, frameoff, up, down)
      begin
      
      case presentState is
         when w =>
            if (frameoff = '0') then
               nextState <= w;
            else
               nextState <= a;
            end if;
            
         when a =>
            nextState <= b;
            
         when b =>
            nextState <= c;
         
         when c =>
            if (frameoff = '0') then
               nextState <= c;
            else
               if (up = '1') then            
                  if (down = '1') then
                     nextState <= h;
                  else
                     if (y_PadIN  + padRadius < monitorHeight -edgeWidth -4) then            --up
                        nextState <= d;
                     else
                        nextState <= h;
                     end if;
                  end if;
               else
                  if (down = '1') then
                     if (y_PadIN - padRadius > edgeWidth +3) then               --down
                        nextState <= e;
                     else
                        nextState <= h;
                     end if;
                  else
                     nextState <= h;
                  end if;
               end if;
            end if;
            
         when d =>
            nextState <= f;
            
         when e =>
            nextState <= g;
            
         when f =>
            if (frameoff = '0') then
               nextState <= f;
            else
               nextState <= b;
            end if;
            
         when g =>
            if (frameoff = '0') then
               nextState <= g;
            else
               nextState <= b;
            end if;
            
         when h =>
            if (frameoff = '0') then
               nextState <= h;
            else
               nextState <= b;
            end if;
            
      end case;
   end process;
   
   uscite : process (presentState)
      variable temp :                  std_logic_vector (8 downto 0);

      begin
      sync_pad <= '0';
      
      
      case presentState is
         when w =>
            y_PadOUT <= DEFAULT_Y_PAD;
            state_test <= "1100";
         
         when a =>
            state_test <= "1000";
            
         when b =>
            sync_pad <= '1';
            temp := y_PadIN;
            state_test <= "0000";
            
         when c =>
            state_test <= "0010";
            
         when d =>
            y_PadOUT <= temp + 4;
            state_test <= "0011";
         
         when e =>
            y_PadOUT <= temp - 4;
            state_test <= "0110";
            
         when f =>
            state_test <= "0001";
            
         when g =>
            state_test <= "0100";
            
         when h =>
            state_test <= "1010";
            
      end case;
   end process;
end IM;


Ragazzi questo è il codice. Gestisce il movimento di un pad nel gioco pong, i cui comandi sono collegati a due bottoni sulla FPGA. La posizione del pad (y_Pad) viene aggiornata ogni volta che in input a questa entità viene fornito un segnale "frameoff". Il segnale "sync_pad" indica quando la nuova posizione del pad è stata calcolata e "state_test" mi è servito per verificare se la FSM funzionasse come doveva con la mia codifica). Allego le simulazioni functional (funzionante) e run-timing (non funzionante con codifiche Quartus, funzionante (anche se con un glitch ogni due cambi di valore di y_Pad, come da simulazione allegata) con codifica da me realizzata e commentata nel codice sopra). Il problema è risolto usando la mia codifica ma, dovendo realizzare una FSM molto più grande per gestire il moviemnto e i rimbalzi della pallina, mi trovo in difficoltà.
Ps. Nelle simulazioni è stato testato il codice completo, per cui il segnale "frameoff" si chiama "aa", la posizione del pad si chiama "pp1/2" e "state1/2" corrisponde a "state_test"...

Il codice non è compilabile senza modifiche, puoi caricare un file zip contenente il progetto Quartus con un testbench per eseguire la simulazione?
Hai dato un'occhiata ai warning che restituisce Quartus? Si parlava di latch involontari e.. quelli presenti nel progetto sono voluti? Ad ogni modo attenzione alle liste di sensitività dei processi, manca qualcosa ed anche se non critico durante il funzionamento reale può creare qualche grattacapo durante la simulazione.
Infine, non ho controllato ma i glitch creano errori logici reali sul funzionamento del progetto?

@sgranfius
ti posso chiedere se la gestione dei pad fatta con FSM ti è stata imposta o è stata una tua scelta?
Sei partito da un progetto già sviluppato?

No ho scelto io di realizzare i pads tramite FSM perché mi sembrava più semplice. Essendo però alle prime armi con questo linguaggio, accetto volentieri ogni critica e consiglio...

ciao sgranfius,
Le altre parti del game le hai già realizzate?
hai già realizzato i moduli per la generazione video e la generazione delle racchette e della pallina?

PS. io inizierei dalla interfaccia video da cui preleverei le info delle righe e colonne nello standard VGA

ciao

Si ho già realizzato la gestione vga, la gestione pads e un modulo crashmanager a cui delego l'emissione di segnali che indichino alla FSM della gestione della pallina se ci sono stati scontri. Mi manca soltanto la gestione della pallina su cui sono bloccato per il discorso della codifica della FSM. Ho provato a semplificarla togliendo le riflessioni e facendola semplicemente muovere con incrementi di default: il compilatore mi segnala dei combinational loops e degli inferring latches, le simulazioni non producono il risultato voluto ma il codice caricato su fpga funziona. Non riesco proprio a spiegarmi questa cosa. Più tardi se riesco vi carico il codice completo.

Ps. Ho realizzato quasi tutti i moduli tramite fsm ma l'osservazione di deluca mi ha fatto pensare che forse alcuni moduli avrebbe avuto più senso pensarli combinatori. Tuttavia l'aggiornamento della posizione dei pads dipende dalla posizione precedente (lo stato) e da un eventuale input dell'utente... per cui mi è venuto abbastanza spontaneo pensare ad un'implementazione mediante FSM. Come ho già detto sono ben accetti critiche, consigli o commenti.

Ciao sgranfius,

I latch indesiderati in genere sono dovuti a segnali modificati dentro condizioni if..then senza specificare il valore per ogni "diramazione".

La simulazione può divergere dalla realtà sopratutto a causa della lista di sensitività incompleta, aggiungendo i parametri mancanti otterrai probabilmente una simulazione logicamente corretta. Il warning dovrebbe suggerirti proprio il parametro mancante.

I glitch in qualche modo sono quasi inevitabili, bisogna però verificare che non creino problemi logici, se lo stato cambia temporaneamente ad un valore intermedio dopo un fronte di salita di un clock potrebbe non produrre errori logici in quanto possono essere presenti flip-flop che valutano lo stato solamente al fronte di salita. Non so se sono riuscito a spiegarmi.

Ciao