Led chaser” con 74HC164

[boiler]

Esprimere (formalmente/matematicamente) e far funzionare potrebbero essere cose diverse.

Ed è proprio questo il punto!

Se fosse stato possibile esprimere in modo sensato circuiti digitali in un linguaggio di programmazione procedurale, allora non sarebbe stato necessario inventare gli Hardware Description Languages.

Boiler

[gekofive]

@Boiler
Nel tuo ragionamento c'è un errore.
I linguaggi come VHDL servono per descrivere come realizzare un hardware, non per eseguire la funzione che quell'hardware realizza.
Tutte le funzioni hardware possono essere descritte con un linguaggio procedurale.
Un esempio sono gli schemi Functional Block dei PLC che sono convertiti in una serie di istruzioni che realizzano la funzione rappresentata dal circuito hardware.
Anche i simulatori digitali fanno la stessa cosa.
Per descrivere in modo procedurale un circuito hardware senza retroazione si parte dall'uscita e si procede a ritroso elencando tutte le operazioni con le loro dipendenze. Poi le operazioni si eseguono in ordine inverso di quell'elenco.
Se il circuito ha retroazione, ogni anello va aperto e generata un'uscita aggiuntiva che sarà poi utilizzata nel ciclo successivo.

[boiler]

I linguaggi come VHDL servono per descrivere come realizzare un hardware, non per eseguire la funzione che quell'hardware realizza.

Vero, ma non vale lo stesso per C, che deve passare attraverso un compiler per produrre qualcosa di "realizzabile"?

Per descrivere in modo procedurale un circuito hardware senza retroazione si parte dall'uscita e si procede a ritroso elencando tutte le operazioni con le loro dipendenze. Poi le operazioni si eseguono in ordine inverso di quell'elenco.

D'accordo, ma lo fai tu o lo fa il compiler?
Perché fino ad ora abbiamo parlato di circuiti con una manciata di porte logiche.
Cosa fai quando diventano centinaia o migliaia?

Boiler

[gekofive]

Vero, ma non vale lo stesso per C, che deve passare attraverso un compiler per produrre qualcosa di "realizzabile"?

Vale per qualsiasi linguaggio di programmazione, interpretato o compilato. E' un processo logico indipendente dalla realizzazione pratica.

D'accordo, ma lo fai tu o lo fa il compiler?

Il metodo descritto è un processo logico che può essere applicato manualmente oppure in modo totalmente automatico partendo da una descrizione qualsiasi del circuito, ad esempio la netlist di uno schema elettrico come potrebbe essere il file di testo di uno schema Fidocad.

Perché fino ad ora abbiamo parlato di circuiti con una manciata di porte logiche.
Cosa fai quando diventano centinaia o migliaia?

Non cambia nulla. Applicando il corretto metodo di analisi non c'è limite alla complessità del circuito, al numero di retroazioni o al loro annidamento. Qualsiasi circuito viene convertito in una serie di istruzioni sequenziali che realizzano esattamente la funzione della logica hardware.

Se questo sistema non funzionasse, non si potrebbero simulare i complessi circuiti descritti in HDL. Il simulatore, che gira su un calcolatore, prima converte la descrizione HDL in una serie di istruzioni sequenziali che poi esegue ciclicamente per assegnare a ogni nodo il corretto valore binario.

[boiler]

Credo che stiamo parlando di cose diverse.

Che sia fattibile mi è chiaro, anni fa ho lavorato con ModelSim su netlists da 250 kGE.
Il golden model dell'algoritmo era scritto in C, la netlist era generata dal compiler VHDL e sputavano lo stesso identico risultato.

Però il programma in C è su un altro piano rispetto al codice VHDL.
Faccio fatica a spiegarmi a parole... ci provo con il diagramma di Gajski&Kuhn:

Il codice VHDL è piú o meno sul braccio "structural domain" e nei gironi ( ) RTL o "Gate level".
Il codice in C è sul braccio "behavioral domain", sul girone "Algorithmic level".

Queste posizioni sono quelle classiche e "facili" da realizzare.

Posso simulare il circuito risultante del codice VHDL in C, ma il codice C che mi serve per farlo non va a finire in behavioral/algorithmic. Perché non è equivalente! Probabilmente per disegnarlo su questo diagramma bisognerebbe aggiungere un'altra dimensione, nella quale l'algoritmo originale diventa un sottoinsieme del design completo. Vanno aggiunte funzioni che controllano le iterazioni sulla logica RTL, che in origine non c'erano.

Questo è un lavoro complesso per il quale, se non mi sbaglio, in C non c'è un automatismo diretto che se ne occupi.
E quindi, se è un lavoro che devo fare con carta e matita prima di scrivere il codice in C, la differenza tra 6 porte logiche e qualche migliaio di porte logiche diventa significativa.

Insomma, possibile non vuol dire fattibile.

Sto cercando di trovare un paragone concreto, forse si può dire così:
Voglio portare un oggetto da Reggio Calabria a Messina.
Posso darlo ad un nuotatore (VHDL) o ad un piccione viaggiatore (C).
Il risultato è lo stesso, il mio oggetto arriverà a Messina.
Se però voglio che il nuotatore lo porti in volo (circuito simulato in C), devo aggiungerci un elicottero ed un pilota (codice aggiuntivo, lavoro di conversione, o ModelSim).

Spero si capisca

Boiler

[gekofive]

Io credo che sia il tuo ultimo post a portare tutto fuori dal piano di discussione.

Io ho risposto alla tua affermazione

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.

Questa affermazione è sbagliata: i circuiti logici, senza limitazioni di dimensioni e complessità, possono essere scritti con linguaggio procedurale.

Metterci dentro Gajski&Kuhn oppure Simon&Garfunkel non cambia questo fatto.

[boiler]

Non credo che la mia affermazione sia sbagliata. Un linguaggio procedurale aggiunge una componente sequenziale. La si può poi "nascondere" in altro modo, per esempio reiterando le operazioni, ma c'è e bisogna tenerne conto.

Metterci dentro Gajski&Kuhn oppure Simon&Garfunkel non cambia questo fatto.

Se il livello di discussione a cui sei interessato è questo, possiamo chiudere qui.

Boiler

[gekofive]

Interrompere la discussione con una scusa per non ammettere di aver fatto un'affermazione sbagliata è ciò che ho visto mille volte succedere a scuola. Non so se anche tu sei o sei stato insegnante, ma ti comporti come tale.

Sono parecchi post che continui a ripetere che un compilatore non può generare automaticamente un programma sequenziale in grado di funzionare come un circuito hardware complesso. Questo è falso, è sbagliato.
Puoi ammetterlo e fare bella figura, oppure nasconderti dietro qualche strano nome o un atteggiamento risentito per nascondere l'evidenza.

[boiler]

Sono parecchi post che continui a ripetere che un compilatore non può generare automaticamente un programma sequenziale in grado di funzionare come un circuito hardware complesso.

Vero, perché ne sono convinto (se stiamo parlando di circuiti con retroazione).

Questo è falso, è sbagliato.

Può darsi, ma non ne ho ancora visto la dimostrazione.

Quale compiler è in grado di prendere il codice di cui sopra e trasformarlo in qualcosa che abbia la stessa funzione della netlist dalla quale è stato derivato? Per comodità riporto il codice qui:

Codice: Seleziona tutto

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

Attenzione, parliamo di questo esatto codice, non di

Codice: Seleziona tutto

while (!steadyStateDetected)
{
   N = B ^ !N;
   X = N | !(A & B);
}

Puoi ammetterlo e fare bella figura, oppure nasconderti dietro qualche strano nome o un atteggiamento risentito per nascondere l'evidenza.

Stai veramente sfociando nella polemica. Restiamo sul tecnico: rispondi alla domanda qui sopra, così mi fai fare una brutta figura e sei contento.

Boiler

[djnz]

Per me la discussione è stata molto interessante. Il primo punto è che VHDL descrive un circuito, che funzionerà in hardware, ma non lo esegue. L'esecuzione/simulazione non in hardware richiede sempre una serializzazione. E qui c'è il secondo punto, la serializzazione porta a due conseguenze: il tempo di propagazione delle retroazioni diventa pari al tempo di ciclo (e per ogni retroazione serve una variabile aggiuntiva), e l'ordine di valutazione delle operazioni intermedie (tra cose che dipendono da) diventa rilevante/pericoloso, come ben sa chi scrive in ladder. Anche il codice che ho scritto per l'esempio di Boiler soffre di questo: visto che X dipende da N, se calcolassi prima X di N otterrei un risultato diverso. Alla luce di questo il circuito andrebbe ridisegnato in modo "invariante" dall'ordine di valutazione delle sottofunzioni, fermo restando l'aggiornamento finale che virtualmente rappresenta la propagazione all'indietro:

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

Qui calcoliamo prima X di N, ma il risultato è corretto:

Codice: Seleziona tutto

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