Nuovo hw Amiga

[bertocar]

Intendi se hanno della memoria? Se e' questa la domanda si e puo' essere gestita come si vuole (a bit in quanto l'unita' di misura fondamentale e' bit e non byte o oltre). Non ci sono limiti di accesso in lettura e scrittura e nemmeno per questioni di allineamento.

Volevo farti una domanda.
Quando devo scrivere un registro di un dispositivo ad esempio il colore di sfondo dell'uscita video, questo viene scritto nella memoria CHIP e il coprocessore interessato a sua volta legge a ripetizione?
Altro esempio: mi sembra di ricordare (ma e' ininfluente) che a $BFE001 ci fosse un bit con lo stato del tasto del mouse. Quando questo cambia viene scritto nella CHIP oppure in realta' quando si interroga quella locazione si va ad interrogare il CIA che risponde a quell'address?

[cdimauro]

Intendi se hanno della memoria? Se e' questa la domanda si e puo' essere gestita come si vuole (a bit in quanto l'unita' di misura fondamentale e' bit e non byte o oltre). Non ci sono limiti di accesso in lettura e scrittura e nemmeno per questioni di allineamento.

Ottimo. Ma ci sarà una suddivisione della memoria in "trance"? Ad esempio, anche se ti serve un byte, l'FPGA te ne alloca comunque 16 (128 bit) alla volta. E immagino che questi "tranci" di memoria siano fra loro completamente indipendenti.

Volevo farti una domanda.
Quando devo scrivere un registro di un dispositivo ad esempio il colore di sfondo dell'uscita video, questo viene scritto nella memoria CHIP e il coprocessore interessato a sua volta legge a ripetizione?
Altro esempio: mi sembra di ricordare (ma e' ininfluente) che a $BFE001 ci fosse un bit con lo stato del tasto del mouse. Quando questo cambia viene scritto nella CHIP oppure in realta' quando si interroga quella locazione si va ad interrogare il CIA che risponde a quell'address?

La seconda che hai detto. La chip-ram è ram, e puoi usarla per quello che vuoi dal primo all'ultimo bit.

I registri del chipset sono, invece, a se stanti. E' altra memoria, generalmente a sola lettura o a sola scrittura.

Non so come fossero implementati internamente nel chipset dell'Amiga, ma immagino che questi registri (tutti a 16 bit) fossero distribuiti all'interno del chip di competenza. Ad esempio quelli per il DMA, il Copper e il Blitter dentro Agnus (il memory controller). Quelli per sprite, colori, e schermo, dentro Denise. Quelli audio, disco, e seriale dentro Paula. E quindi l'accesso a un determinato registro era servito dal chip corrispondente.

[bertocar]

L'aggregazione avviene a bit. Posso creare un 'registro' composto da 1 fino a n bit che riservano la memoria necessaria. Non ci sono limiti e non viene mai sprecata ram. Tra le caratteristiche di un fpga c'e' anche quanta memoria ha disponibile.

Tornando al discorso dei registri, vuol dire che quelle locazioni di memoria erano riservate e basta non c'era memoria ram in quell'area. Avevo bisogno di questo chiarimento per capire come funziona minimig che sto studiando.

Altra domanda: non sono riuscito a trovare i sorgenti di minimig v2, sai se sono stati resi pubblici?

[legacy]

mah, dovrebbero saperlo sul forum http://www.minimig.net
volevo chiederlo a loro e girarti la risposta pero' ... non sono riuscito a registrarmi: attendo ancora email da admin che mi abiliti account.

[cdimauro]

L'aggregazione avviene a bit. Posso creare un 'registro' composto da 1 fino a n bit che riservano la memoria necessaria. Non ci sono limiti e non viene mai sprecata ram.

Fantastico! Questo consente una flessibilità eccezionale, che ci servirà per risolvere alcuni problemi e spingere al massimo le prestazioni.

Tra le caratteristiche di un fpga c'e' anche quanta memoria ha disponibile.

Per quel che ho in mente non ne servirà molta. Solo un po' di buffer per ogni canale DMA, in modo da eseguire prefetch dei dati opportunamente.

Comunque darò un'occhiata ai datasheet per vedere cosa mettono a disposizione.

Tornando al discorso dei registri, vuol dire che quelle locazioni di memoria erano riservate e basta non c'era memoria ram in quell'area. Avevo bisogno di questo chiarimento per capire come funziona minimig che sto studiando.

Memoria vera e propria no. Ma alla fine è pur sempre memoria, sebbene "allocata" nel chipset.

Altra domanda: non sono riuscito a trovare i sorgenti di minimig v2, sai se sono stati resi pubblici?

Purtroppo non ne so niente. Vediamo se legacy avrà più fortuna.

[bertocar]

mah, dovrebbero saperlo sul forum http://www.minimig.net
volevo chiederlo a loro e girarti la risposta pero' ... non sono riuscito a registrarmi: attendo ancora email da admin che mi abiliti account.

Ok ti ringrazio

[cdimauro]

Ci sono 608256 celle di memoria.

Ottimo anche per la CPU, perché ci sono ben 74KB a disposizione da impiegare per la cache L1 (32K per codice e 32K per dati, suppongo), e per la branch target cache (se si implementerà), oltre alla TLB se si implementerà anche l'MMU (ma non subito; un 68020 è sufficiente all'inizio).

Peccato per le sole 82 linee di I/O, che effettivamente castrano le possibilità di avere un bus a 64 bit (ce ne vorrebbero circa il doppio per avere un bus dedicato verso la memoria, e uno condiviso fra gli altri due FPGA).
Speriamo che almeno a livello di frequenza si possa arrivare a valori abbastanza elevati e che si possa impiegare per lo meno memoria DDR2, in modo da compensare alla ristrettezza del bus col maggior througput (4x rispetto alla normale SDRAM).

I dettagli dell'arbiter saranno definiti quando ci saranno i dati finali sulle caratteristiche della memoria e del bus.

[bertocar]

EP3C25Q240C8N ha 148 i/o percio' il problema maggiore che abbiamo e' per JAY visto che concentra moltissimi dispositivi.

Saremmo in mancanza grave i/o, si sta valutando di usare solo per JAY un FPGA con package BGA (con tutti i problemi che questo comporta) dato che come numero di i/o abbiamo:
SDRAM: 57
FLASH: 37
USB: 30
I2C: 2
AUDIO: 6
VGA: 29
ETH: 23
RS232: 4
PS/2: 8
SDCARD: 7
LED: 4
BUTTONS: 4
JOYSTICK: 10
EXP PORT: 36
BUS: 32 ADDR, 32 DATA, 4 CONTR, 4 ALLA CPU e 4 A GRAPH = 76
Siamo a circa 350!

Vorremmo percio' adottare per JAY EP3C16F484C7N che ha meno LE (16K) ma 346 I/O.

GRAPH:
VGA: 29
HSMC (per DVI): 82
BUS: 32 ADDR, 32 DATA, 4 CONTR, 4 A JAY = 72
=183
Anche qui' siamo in mancanza di I/O con EP3C25Q240C8N

CPU:
BUS: 32 ADDR, 32 DATA, 4 CONTR, 4 A JAY = 72
SDRAM: 57
=129
In questo caso problemi non ce ne sono con EP3C25Q240C8N

[heyvid]

.............
Altra questione annosa e' l'uscita DVI (e HDMI). Per poter avere HDMI sembrerebbe necessaria una licenza di un forum di produttori che difficilmente la concede.
Invece DVI e' libera percio' dovra' essere una scelta obbligata.
La DE2 prevede un modulo opzionale con uscita HDMI, la settimana prossima provero' a vedere se riesco a reperirla con il modulo per poter fare test (e' un vantaggio non da poco poter testare l'hw prima di produrre la scheda). Fra l'altro la scheda prima versione assomigliera' molto alla DE2 in termini di capacita' (ha 64MB SDRAM e l'uscita VGA a 24BIT, e 35KLE ad esempio), fermo restando le 3 FPGA.

ciao, sei di Padova, strano che non ti conosco, eravamo un bel gruppo che ci trovavamo spesso in zona università, ma forse sei + giovane di me.

Per quanto riguarda il discorso HDMI, non è proprio così, esiste un consorzio e per usare l'hdmi sulla tua scheda devi pagare una royalty di molte migliaia di euro, quindi il mio consiglio è appunto di usare il DVI con annessa anche la parte analogica così l'utente con un adattatore dvi-vga ha già entrambi i connettori.

p.s. se servono connettori dvi te li posso fornire ne ho una certa quantità

ciao

[cdimauro]

@bertocar: ho capito. Ti espongo la mia idea, e vediamo cosa ne pensi.

Riguardo alla suddivisione della piattaforma in 3 dispositivi / FPGA. Darei un nome a tutti e tre, in modo da identificarli: CPU, Jay = Memory controller + Arbitro DMA + Bus verso gli altri 2 dispositivi + Video + Copper + Blitter, Mitchy (il cane di Jay Miner) = tutto il resto.

Jay sarebbe, quindi, il componente più importante, perché s'interfaccia direttamente con la memoria e ne funge da "master" per l'accesso. Gli altri dispositivi s'interfacciano con lui tramite un bus (vedremo se condiviso oppure no).

Mitchy è di minore importanza perché si occupa di componenti del sistema che non richiedono un'elevata banda; tutt'altro.

Per cercare di massimizzare l'uso delle linee di I/O, ti butto un'idea, e mi dirai cosa ne pensi. Non credo serva un address bus, e quindi le linee a esso dedicate si impiegherebbero per il trasporto dei dati.
Questo perché non credo che in un ciclo di clock si possa specificare un indirizzo e leggere o scrivere un dato allo stesso tempo. Credo che dopo aver specificato un indirizzo sia necessario almeno un ciclo di clock per poter cominciare a leggere dati o inviarli.
Quindi nel primo ciclo di clock si impiegheranno le linee di I/O per specificare sia l'indirizzo che eventuali altri dati importanti di controllo per l'operazione (ad esempio quante linee di burst leggere, come multiplo del numero di burst che la memoria supporta).
A partire dal ciclo successivo si leggeranno o scriveranno i dati a blocchi di burst, come specificato prima. Un blocco di burst assume significato diverso a seconda del tipo di memoria impiegata: 1 dato a 32/64 bit per SDRAM e DDR (che possono leggere o scrivere singole celle di memoria), 4 dati a 32/64 bit per le DDR2 (che funzionano a burst di 4 dati per volta). Quindi se il dispositivo richiedesse 2 blocchi di burst, potremmo avere 2 letture o scritture per SDRAM/DDR, mentre 8 per DDR2.

In questo modo per l'accesso alla memoria potremmo avere bisogno di 64 linee di I/O per i dati (e l'indirizzo) + qualche altra linea di controllo dell'operazione.
Per connettere CPU e Mitchy si potrebbe procedere allo stesso modo, ma riservando soltanto 32 bit di I/O per i dati + qualche altra linea di controllo dell'operazione.

La CPU non richiede una banda elevatissima per lavorare, per cui potrebbe utilizzare al più metà della banda a disposizione per tutta la memoria, che è un valore accettabilissimo.
Mitchy ne richiede di gran lunga meno, quindi va benissimo così; eventualmente si potrebbe pensare di impiegare un "mini-bus" a 8 bit solo per Mitchy, in modo da avere sia la CPU che Mitchy con 2 bus dedicati e indipendenti, che quindi non richiedono logica di arbitraggio (sono esclusivi).

Non so se sia fattibile un'idea del genere. La suddivisione l'ho pensata per cercare di scaricare su Mitchy la maggior parte delle linee di I/O per le periferiche di minore importanza di cui si dovrà occupare. In questo modo Jay potrà utilizzare le sue linee di I/O quasi esclusivamente per fungere da memory controller e arbiter, a cui si aggiungono le poche linee richieste per la VGA e il DVI.

Spero di non aver sparato troppe boiate.

EDIT. Dimenticavo: per Jay non serve un numero esagerato di LE. Quindi 16K LE vanno benissimo. Per Mitchy credo ne serviranno anche meno; forse 5K LE potrebbero bastare.

[cdimauro]

Ho "giocato" un po' coi dati, cercando di tirare fuori delle configurazioni compatibili col numero di pin di I/O per l'EP3C25Q240C8N.

Jay

Codice: Seleziona tutto

Memory bus: 64 + 4   68
CPU + Mitchy bus: 32 + 4 Controllo + 4 CPU + 4 Mitchy   44
VGA   29
HSMC (per DVI)   82
   223
   
Memory bus: 64 + 4   68
CPU + Mitchy bus: 32 + 4 Controllo + 4 CPU + 4 Mitchy   44
VGA   29
   141

Mitchy

Codice: Seleziona tutto

BUS: 32 Dati + 4 Mitchy + 4 Jay   40
FLASH   37
USB   30
I2C   2
AUDIO   6
ETHERNET   23
RS232   4
PS/2   8
SDCARD   7
LED   4
BUTTONS   4
JOYSTICK   10
EXP PORT   36
   211
   
BUS: 32 Dati + 4 Mitchy + 4 Jay   40
FLASH   37
USB   30
I2C   2
AUDIO   6
ETHERNET   23
RS232   4
PS/2   8
SDCARD   7
LED   4
BUTTONS   4
JOYSTICK   10
   175
   
BUS: 32 Dati + 4 Mitchy + 4 Jay   40
USB   30
I2C   2
AUDIO   6
ETHERNET   23
RS232   4
PS/2   8
SDCARD   7
LED   4
BUTTONS   4
JOYSTICK   10
   138

CPU

Codice: Seleziona tutto

Bus: 32 Dati + 4 CPU + 4 Jay   40
SDRAM   57
   97
   
Bus: 32 Dati + 4 CPU + 4 Jay   40
SDRAM   57
FLASH   37
   134

Con le ultime configurazioni i conti tornano, ma Jay rimane senza uscita DVI (82 pin mi sembrano, comunque, un'enormità, come pure i 29 per la VGA), mentre Mitchy sacrifica la porta di espansione.

Non so se siano fattibili, in particolare senza un parere riguardo all'implementazione del bus che ho esposto (senza linee di address dedicate).

[cdimauro]

Ho scaricato l'handbook dei Cyclone III, ma purtroppo non se ne esce fuori. Se si renderà necessario l'uso del BGA (quindi il EP3C16F484C8N), allora tanto vale usare 2 soli FPGA: l' EP3C25Q240C8N per la CPU e l'EP3C16F484C8N per il chipset completo (16K LE dovrebbero bastare).

In questo caso il chipset integrerà:

Codice: Seleziona tutto

Memory bus: 64 + 4   68
CPU + bus: 32 + 4 Controllo + 4 CPU   40
VGA   29
HSMC (per DVI)   82
USB   30
I2C   2
AUDIO   6
ETHERNET   23
RS232   4
PS/2   8
SDCARD   7
LED   4
BUTTONS   4
JOYSTICK   10
   317

Lasciando fuori la porta di espansione (la Flash rimarrebbe, invece, a carico dell'FPGA usato per la CPU), ma guadagnando l'uscita DVI. Sempre supponendo che i bus siano implementati senza far uso delle linee di address.

In questo modo scenderebbe pure il costo del dispositivo.

[bertocar]

Potrebbe essere ma non dimentichiamo che dovrà essere potenziato e poi che la sintesi più complessa è più rogne comporta. Inoltre il costo/le non è proporzionale. Appena rientro stasera butto giu un diagramma con visio così iniziamo ad avere una rappresentazione visuale. Poi è da considerare che abbiamo a che fare con fpga perciò se dedichiamo x linee di bus se decidiamo di cambiarne l'uso o lo scopo non ci sono problemi.

[cdimauro]

Potrebbe essere ma non dimentichiamo che dovrà essere potenziato

Per quello non c'è problema, perché c'è il fratello maggiore, l'EP3C40F484C8N: 40K LE, molta più memoria, ma qualche linea di I/O in meno (331 in tutto).

e poi che la sintesi più complessa è più rogne comporta.

Hum. Anche nel caso in cui hai molte più LE a disposizione (da 16K a 40K c'è quasi il triplo di elementi)?

Inoltre il costo/le non è proporzionale.

Sì; dipende anche dal modello. Il EP3C16F484C8N con 16K LE costa €36,50, mentre il fratello maggiore, il EP3C40F484C8N con 40K LE costa €86,42; non è il triplo del costo, ma non pensavo costasse così tanto...

Appena rientro stasera butto giu un diagramma con visio così iniziamo ad avere una rappresentazione visuale. Poi è da considerare che abbiamo a che fare con fpga perciò se dedichiamo x linee di bus se decidiamo di cambiarne l'uso o lo scopo non ci sono problemi.

Ottimo. Comunque si deve sciogliere il nodo gordiano del tipo di FPGA da impiegare. Se prevedi che sia necessario il EP3C16F484C8N perché servono tanti pin di I/O e vuoi mantenere lo stesso la configurazione con 3 FPGA, possiamo trovare delle configurazioni più adeguate.

Allo scopo, si potrebbero anche scegliere FPGA che calzano a pennello. Ho visto che oltre ai package P/Q240 e F484 ci sono anche gli E144 e M164, che potrebbero essere papabili per Mitchy, che richiederà poche LE e non tante linee di I/O.
Se si usa l'EP3C16F484C8N, al grosso delle funzionalità (e dei pin) ci penserà lui, e Mitchy verrebbe usato per quelle meno importanti. Ad esempio:

Codice: Seleziona tutto

BUS: 32 Dati + 4 Mitchy + 4 Jay   40
I2C   2
RS232   4
PS/2   8
SDCARD   7
LED   4
BUTTONS   4
JOYSTICK   10
   79

Quindi con Ethernet, USB e Audio convogliati su Jay, tutto il resto lo gestirebbe Mitchy, usando un FPGA molto economico (se si possono usare E144 o M164 come package; non so nemmeno quali dei due sarebbe più semplice e/o più economico).

Ecco qui due candidati:

EP3C5E144C8N 5K LE, 94 I/O, €22,22
EP3C5M164C8N 5K LE, 106 I/O, €13,46

[bertocar]

Sto preparando lo schema con Visio.
I package 'difficili' sono i bga (quelli con i pin da saldare internamente al corpo del chip) e anche EP3C5M164C8N rientra tra quelli purtroppo.

Una volta finito lo schema (penso sia questione di pochi minuti) si decide cosa spostare e come per far rientrare i pin.

Tornando alla questione scegliamo FPGA con quantita' di LE maggiore e mettiamone 2, sul campo poi ci si scontra con la certezza che vengano rispettati i timing in tutti i moduli e questa diminuisce man mano che aumenta il numero di LE impegnati.

L'idea di usare 3 FPGA complica la scheda ma semplifica la vita a noi sviluppatori poi, oltre a mantenere lo sviluppo separato per 3 diversi progetti = sintesi piu' snella = sviluppo piu' rapido.

Per la scelta degli FPGA mi sembra di aver letto che un 68050 impegna 25KLE quindi se non vogliamo chiuderci troppo le porte per il futuro io 20E in piu' li spenderei