Led chaser” con 74HC164

[boiler]

Il tuo design mescola clock e dati all'ingresso del NAND. È una pratica da evitare, anche se nel circuito originale ci sono porcherie ben peggiori (vedo che PietroBaima mi ha preceduto, siamo in due a dirtelo, è importante! )

La soluzione piú semplice in termini di componenti utilizzati è un microcontroller.
Ma non è divertente e la complessità totale in realtà aumenta, ma è nascosta.

Quello che serve qui è un reset del 74HC174 di tipo "synchronous reset, asynchronous release" (di solito si fa il contrario).
Insomma questo, dove t_su è il setup time dello stadio su cui entriamo (qualche decina di ns, tipicamente, con questo clock non è sicuramente un problema):

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

Si può ottenere usando un solo FF di tipo D con set/reset asincroni. Per esempio questo: https://assets.nexperia.com/documents/d ... _HCT74.pdf

All'ingresso D metti l'uscita dell'ultimo LED.
La stessa uscita la colleghi anche all'ingresso di reset, che visto che viviamo nel migliore dei mondi possibili è active-low.
Il segnale clear lo otteniamo dall'uscita negata del FF.

Quando l'ultima uscita va alta, il FF riceve un livello alto in ingresso. Al successivo fianco attivo del clock, l'uscita negata del FF va a zero, triggerando il reset del 74HC174. Come conseguenza (questo è importante: passa del tempo!) le uscite vanno a zero e l'ultima triggera il reset del FF, la cui uscita negata torna a 1 e permette quindi al 74HC174 di shiftare un 1 all'ingresso al prossimo ciclo.

Boiler

[boiler]

Ah, volevo scrivere ancora qualcosa, ma poi mi sono dimenticato: se usi quelle due porte logiche per soddisfare l'hold-time, mi fa piacere che tu ci abbia pensato, ma non è necessario. Tutti i moderni FF hanno un hold time negativo! Se si vuole andare sul sicuro si può mettere una piccola resistenza in serie all'uscita che, combinata alla capacità d'ingresso dello stadio successivo, causerà un leggero ritardo nel raggiungere il threshold (soluzione amatoriale per circuiti di questo tipo, non certo per un QSFP28!)

Boiler

[djnz]

L'hold-time era uno dei dubbi, in effetti ho pensato a una simil logica master-slave per "giocare sempre a bocce ferme".

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

[djnz]

E poi chi lo dice che col micro è meno divertente? Basta fare un circuito simulato

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

Codice: Seleziona tutto

struct SIM74164
{
    uint8_t CV = 0;
    bool    CLKp = 0;
   
    void run(bool S1, bool S2, bool CLK, bool CLR)
    {
        if (!CLR)
            CV = 0;
        else if (CLK & !CLKp)
            CV = (CV << 1) | (S1 & S2);
        CLKp = CLK;
    }

    bool Q(uint8_t b)
    {
        return (bool)(CV & (1 << b));
    }
};


[boiler]

Mamma mia! No!
Scrivere circuiti digitali in C porta forzatamente ad introdurre una componente sequenziale che nel circuito non c'è! È il motivo per cui sono stati inventati VHDL e Verilog.

Il tuo codice per esempio non funzionerebbe se collegassimo l'uscita Q7 direttamente all'ingresso CL: CL cambierebbe all'interno dell'ELSE, cosa che in realtà causerebbe un reset asincrono del componente, cosa che però non succede in software perché abbiamo già passato l'IF in cui la funzione è realizzata.

Boiler

[djnz]

Ottimo spunto di riflessione. Non mi capita mai di dover gestire via software situazioni intrinsecamente asincrone, o per meglio dire, dove la propagazione di un qualcosa dovrebbe avvenire istantaneamente e asincronamente tra un ciclo di elaborazione e l'altro. Non è che l'uscita Q7 non resetta, è che lo farebbe al ciclo successivo. Se avessimo un tempo di elaborazione infinitamente piccolo... Poi ok, ci sono altre cose, come l'ordine di esecuzione delle operazioni, che in alcuni casi è comodo da sfruttare, ma se diventa un problema bisogna introdurre un aggiornamento sincrono delle variabili. Una simulazione ha i suoi limiti, basta conoscerli.

[boiler]

Il problema non è tanto l'asincronia o il tempo di propagazione. Il problema principale è la differenza tra operazioni che avvengono in sequenza e operazioni che avvengono in concomitanza.

ESEMPIO 1:

Codice: Seleziona tutto

a = x;
a = y;

Questa, in C, è un'operazione valida.

Codice: Seleziona tutto

a <= x;
a <= y;

Questo, in VHDL, è un conflitto.

ESEMPIO 2:

Codice: Seleziona tutto

a = x;
b = y;

Codice: Seleziona tutto

b = y;
a = x;

Questi, in C, sono due pezzi di codice che fanno cose diverse.

Codice: Seleziona tutto

a <= x;
b <= y;

Codice: Seleziona tutto

b <= y;
a <= x;

Questi, in VHDL, fanno la stessa identica cosa.

Boiler

[djnz]

Questa, in C, è un'operazione valida.
[..]
Questo, in VHDL, è un conflitto.

In C è un'operazione valida, ma è comunque un bug di logica

Questi, in C, sono due pezzi di codice che fanno cose diverse.
[..]
Questi, in VHDL, fanno la stessa identica cosa.

La contemporaneità, quando non è possibile realizzarla fisicamente, si può comunque ottenere logicamente, serializzando le operazioni ma tenendo da parte i risultati che possono influire sulle altre valutazioni, e aggiornando alla fine in un colpo solo. In questo modo l'ordine di valutazione diventa irrilevante, per tornare all'esempio C che in effetti non è molto significativo, sarebbe come scrivere:

Codice: Seleziona tutto

// operazioni concorrenti serializzate in qualsiasi ordine
an = x;
bn = y;

// aggiornamento finale
a = an;
b = bn;

// da qui è come se tutto fosse avvenuto
// realmente in parallelo, a parte il tempo impiegato


A meno che non sbaglio qualcosa, non mi sembra così terribile simulare qualcosa in C ( o altro).

EDIT: questo potrebbe essere l'aggiornamento interno dei flip-flop del 74164, volutamente alla rinfusa:

Codice: Seleziona tutto

onCLK = CLK & !CLKp //edge detect
CLKp = CLK;
//valutazione in parallelo dei flip-flop
//qualsiasi ordine va bene
Q1n = CLR & (!onCLK ? Q1 : Q0);
Q4n = CLR & (!onCLK ? Q4 : Q3);
Q0n = CLR & (!onCLK ? Q0 : S1 & S2);
Q5n = CLR & (!onCLK ? Q5 : Q4);
Q7n = CLR & (!onCLK ? Q7 : Q6);
Q3n = CLR & (!onCLK ? Q3 : Q2);
Q6n = CLR & (!onCLK ? Q6 : Q5);
Q2n = CLR & (!onCLK ? Q2 : Q1);
//aggiornamento finale sincrono uscite
Q0 = Q0n;
Q1 = Q1n;
Q2 = Q2n;
Q3 = Q3n;
Q4 = Q4n;
Q5 = Q5n;
Q6 = Q6n;
Q7 = Q7n;


[boiler]

In C è un'operazione valida, ma è comunque un bug di logica

Sicuro?

Codice: Seleziona tutto

StatusEnum a = idle;
a = InitializeStack();
a = ScanForDevices();
a = ConnectToDevice();

Da qualche parte nel sistema c'è un interrupt che vuole sapere qual è lo stato dello stack.

La contemporaneità, quando non è possibile realizzarla fisicamente, si può comunque ottenere logicamente,

Come esprimeresti questo in C? Quando hai scritto la funzione, valutala per A=B=0

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

Boiler

[djnz]

Come esprimeresti questo in C?

Esprimere (formalmente/matematicamente) e far funzionare potrebbero essere cose diverse. Naturalmente scriverei nel seguente modo:

Codice: Seleziona tutto

N = B ^ !N;
X = N | !(A & B);

Con una variabile intermedia per ogni feedback all'indietro, tempo di propagazione un ciclo di elaborazione. Con B==0 N oscilla con periodo due tempi di propagazione.

Codice: Seleziona tutto

B  A    X     N
----------------
0  0    1     ~
0  1    1     ~
1  0    1    n-1
1  1    n-1  n-1