Nuovo hw Amiga

[legacy]

In Natami gia' si parla di 68070 :-)
http://www.natami.net/68070.htm

OK, pero'

This is a prelimenary design draft for the 68070 CPU project.
The 68070 is not available yet.
This is not an announcement.

quindi non c'e' de facto nulla, solo una bozza che suona come un proof of concept. Personalmente ti direi: non farti troppe illusioni, quel coso e' tanto complicato che e' mooooooooolto poco probabile che veda la luce per tempo.

[sabbate]

Speriamo per il d68000 allora e che scendano di prezzo.

[cdimauro]

mi sembra che di tentativi di questo genere, ce ne siano stati almeno 4 o 5 di cui solo uno andato pienamente in porto. Questo conferma quanto sicuramente non siano semplici, ma penso che il problema più grosso sia che, per un motivo o per l'altro ogni progetto è ripartito da zero reinventando la ruota. Ora dico, visto che c'è il minimig funzionante, non sarebbe meglio estendere quel progetto? Si potrebbe utilizzare lo steso cip del minimig per i soli cip custom, in modo da recuperare il s/w già esistente ed avere al contempo maggior potenzialità di sviluppo pe nuove features.

E' quel che penso pure io, infatti. Il rischio, altrimenti, è quello che il progetto vada a far compagnia a quelli abortiti o finiti nel limbo.

@cdmauro
secondo me ci sono pocchissime persone al mondo in grado concretamente di fare una cosa del genere, o disposte a farlo, sopratutto per hobby (cioe' non competenze non retribuite). Non a caso D68000 costa 60.000 USD per i sorgenti, e gli ing di freescale sono letteralmente stati pagati a peso d'oro per il refactoring del 68060 e della linea coldfire e 683xxx (AKA 68K/CPU32)

Non lo metto in dubbio. Se possono permettersi di chiedere tutti quei soldi, vuol dire che hanno sputato sangue per realizzarlo, e trovo sia anche giusto che si facciano pagare lo sforzo e l'IP.

Secondo me il tizio del fantomatico super 68K aka "68050" in Natami se capisce come gira il mercato il suo core lo ritratta in termini di Copyright, proponendolo sotto forma di IP a scatola chiusa, o a diversi zeri per avere anche i sorgenti: e lo penso perche' se ho compreso la natura umana, beh ... con se quel coso davvero esiste e funziona il tizio puo' farci davvero un bel po' di soldi.

E' un tizio che lavora all'IBM, credo proprio su quelle cose, per cui penso che ne conosca anche il valore. Infatti non ho mai sentito parlare di eventuali rilasci dei sorgenti.

Da poco circola questa voce, ma non so se si parla del suo lavoro o di quello realizzato dagli altri, dopo che ha lasciato il gruppo.

In quanto ai salti no, questo no, non penso, i salti sul mio MIPS32-rev2 sono catastrofici e da Mips inc ho visto che sono stati seguiti diversi approcci, sia per CPU asic che per proposte di softcore Mips

I MIPS non fanno testo: sono i poveri dei core. Hanno tolto tanta di quella roba dal core, spostandola al compilatore / programmatore, che mi vengono i brividi soltanto a pensare di lavorarci sopra.

Dal piu' pregiato al + bovino, posso tentare di riassumerli cosi':
[...]
Ma hai abbastanza risorse per mettere in piedi questa cosa ? Sui chip asic il branch prediction e' l'aggeggio che occupa + transistor, sui PIC e sugli AVR8 tagliano molto corto e usano soluzioni bovine proprio perche' hanno maschere a pochi transistor (e il chip deve anche costare $2/$5) per cui ... dubito che sulle fpga piccole si possano fare cose tanto elaborate.

So come funziona, e so che l'unità di branch prediction è molto costosa da implementare, e soprattutto sempre attiva (succhia corrente che è una bellezza).

Comunque ce ne sono diverse versioni, dal semplice al molto complicato, a seconda degli obiettivi che si vogliono raggiungere.

Al momento assumiamo che non ci sia quest'unità, anche per semplificare di molto la progettazione del softcore.

Poi ci sono casini bestia come tradurre le complicatissme EA (effective address) del 68020 in load/store del nucleo RISC, anzi spesso una istruzione che fa EA complessa e' tradotta in un gruppo di micro istruzioni RISC, il che significa che per portare a termine l'istruzione 68k servono diversi e diversi cicli, vero che c'e' pipelining, ma la profondita' e' 4 o 5, oltre bisogna assolutamente stallare con nop per non incorrere in hazard condition fra il dato/registro manipolato da quella istruzione e le istruzioni che seguono che spesso e volentieri vorrebbero consumare quella informazione e devono aspettare che sia pronta e stabile.

Purtroppo le modalità con doppia indirezione del 68020 sono micidiali. Finché non si fa uso della doppia indirezione siamo ai livelli dell'EA dell'80386+, che è abbastanza comune e semplice da implementare (basta un sommatore con 3 operandi), e le prestazioni possono essere molto elevate.

A mio avviso soltanto nei casi di doppia indirezione si potrebbe stallare la pipeline per un altro ciclo di clock (o anche più, nelle prime versioni del core) in modo da leggere dalla memoria il puntatore necessario, e poi proseguire normalmente.

Comunque sono idee. Non sono esperto di progettazione di architetture (intendo a livello di implementazione hardware), come ben sai.

Mips Inc per le sue CPU questa rogna la delega al compilatore, con un 68K super scalare dove hai istruzioni 68k tradotte in micro istruzioni RISC, o stalli come ho fatto notare prima e perdi prestazioni, oppure per ottimizzare sarebbe necessaria logica ed intelligenze eseguzione fuori ordine delle micro istruzioni RISC al fine di prevenire le loro hazard -> altro complicatume infinito da fare e validare

Lo posso ben immaginare. Comunque al momento di core RISC per il 68K non se ne parla: è una finezza che va riservata a dopo, quando il progetto sarà già nato con un softcore più semplice, ma che almeno funzioni.

Dopo aver letto tutte le vostre considerazioni che apprezzo, rimango fortemente convito che la strada sia quella del softcore. Solo per il fatto che puo' essere successivamente sostituito con una versione migliore per me merita.

La penso allo stesso modo, ma c'è parecchio lavoro da fare.

Con questo ci sono 2 strade che cercheremo di seguire:
1. individuare un fpga che in termini di prestazioni sia importante ma non troppo costoso in modo da colmare in parte la 'deficenza' dei softcore open

Un FPGA che lavora a 400Mhz, come quello che hai riportato prima (quando hai elencato quei 3), a mio avviso sarebbe un ottimo punto di partenza.

Nel frattempo la tecnologia va avanti, migliorano i processi produttivi, e magari nel giro di qualche anno gli FPGA faranno il salto al Ghz, pur mantenendo gli stessi prezzi (e con un bel po' di LE in più, si spera).

2. trattare per la license del D68000 che e' vero chiedono 60kUSD MA considerate che e' UN PREZZO ESTREMAMENTE DI LISTINO, soggetto a trattative e sicuramente ridimensionato non di poco. Una volta chiusa la partita io non potro' ovviamente comunicare il costo pero' fare un ragionamento del tipo 'al raggiungimento di n dispositivi venduti potremo tutti godere del softcore D68000... temporaneamente utilizziamo tutti questo open che fa pena (ma forse inizialmente poi nemmeno cosi' tanto)'
Il punto 2 e' importante perche' fin dal principio ho espresso la volonta' di portare le velocita' di elaborazione della cpu notevolmente in avanti rispetto alla piattaforma originale (e non intendo 20MIPS).

Concordo. Il softcore 68020 dell'FPGArcade / Minimig v2 non è malvagio (a parte l'essere ancora incompleto, perché manca qualche istruzione), perché gira già a 28Mhz, integra anche una cache dati da 256 byte (quindi come il 68030), e presenta prestazioni comparabili al 68030. Inoltre mi pare che ci stavano lavorando per portarlo a 56Mhz.

Quindi sarebbe una buona base di partenza.

Il salto di qualità, però, lo si potrà fare soltanto quando si farà uso di un'unità RISC interna, come il 68060, che consentirà di arrivare almeno a un'istruzione eseguita per ciclo di clock. A 400Mhz macinare 400MIPS per un 68K è un valore impressionante.

Magari facendo uso proprio del D68000, che promette faville, se si riesce a spuntarla sul prezzo.

Quando mi sono riferito a FPGA molto costosi, intendo dispositivi che arrivano al GHz (non conosco specificamente quali perche' ho ignorato l'info, ma uno dei miei ingegnieri me ne ha parlato ieri) ma siamo completamente fuori dal target.

Infatti lasciamoli perdere per ora. Il tempo aggiusterà le cose.

Pero' mi domando anche perché dover fare tutto da zero, quando invece potreste provare... e dico almeno provare a unire le forze con il Team di Natami e continuare lo sviluppo di questo sistema.

Ci sono tante persone sparse per il globo che non vedono l'ora di trovarsi tra le mani un sistema Natami bello e funzionante, ma cio' non avviene mai.

Allora se avete la forza finanziaria e le qualita' giuste per sviluppare una tale idea, perché non provare la strada di chi ha gia' iniziato da tanto e sviluppato tanto ?

In Natami gia' si parla di 68070 :-)
http://www.natami.net/68070.htm

No, per favore, che non se ne esce più col team di Natami. Sono troppo fissati con le loro idee, che già per la prima versione vogliono tirare fuori il SuperAmiga galattico con scapellamento a destra.

Meglio volare bassi all'inizio, FAR USCIRE SUBITO QUALCOSA DI FUNZIONANTE (lo sottolineo, perché con tutti i progetti è sempre così), e col tempo affinare il progetto migliorandolo.

Nel frattempo il prodotto si può già vendere, gli appassionati sono contenti (anche perché se arriva sui 200€ al massimo, sarà sicuramente appetibile), e gli sviluppatori possono provare nuovamente interesse e magari dare una mano per i driver. Si forma, insomma, un circolo virtuoso.

[bertocar]

Concordo pienamente.

Fra l'altro un progetto come natami che dopo tutto questo tempo non ha partorito ancora una prima versione per me e' fallimentare, vogliono solo strafare a mio modesto parere.

Comunque lunedi' ci consegnano le terasic de1, e iniziamo a fare test.
Spero per venerdi' di avere qualche risultato positivo, ho gia' visto alcune patch per quella scheda per abilitare le sdram con il core minimig modificato.
Se la gestione della sdram funziona bene ci permetterebbe di passare da sram a dram il che abbassa notevolmente i costi a parita' di MB.
Poi dovremo progettare la prima beta della scheda che inglobera' i 3 fpga (ricordiamoci che il 3o si dovra' occupare non solo dell'audio ma degli hdd, floppy e tutte le periferiche che serviranno). Arrivata la scheda (tempo 10gg) l'obbiettivo numero 1 e' prendere il core per la de1 e farlo 'funzionare al minimo dell'indispensabile' per verificare che a livello HW ci siamo.
Poi si decidera' il da farsi.

[cdimauro]

Ditto.

La butto lì, visto che ci siamo: invece del terzo FPGA non sarebbe meglio un microcontroller ARM, come sul Minimig v1 e sull'FPGArcade, che si occupa di caricare il firmware dell'FPGA (due, in questo caso), avviarlo, e di gestire floppy e hard disk emulati (caricando i dati dalle immagini presenti nella scheda SD)?

Quindi 1 FPGA per la CPU, 1 FPGA per video + audio + Blitter + Copper, 1 microcontroller per il boot del sistema e per gestire l'emulazione di floppy e hd (ed eventualmente anche dell'I/O: tastiera, mouse, joystick, seriale).

Dovrebbe facilitare lo sviluppo, i test, e gli aggiornamenti dei firmware, specialmente per tanta gente che non è molto affine con la tecnologia, e vuole procedure "a prova di idiota" per utilizzare oggettini come questi.

Dimenticavo: le DRAM vanno venissimo se consentono di ridurre i costi. D'altra parte anche l'Amiga originale aveva la circuiteria di refresh della memoria, con tanto di "slot DMA" dedicati nella raster line.

L'importante è poter aver un buon quantitativo (2GB sarebbe l'ideale: coprirebbe l'intero spazio d'indirizzamento di AmigaOS) e, soprattutto, TANTA banda a disposizione per pensare di poter rilanciare alla grande la piattaforma Amiga (non basta poter visualizzare schermi FullHD, ma... serve anche gestirli, garantendo al "SuperBlitter" sufficiente banda per muovere tanta roba).

[bertocar]

sarebbe sicuramente piu' semplice ma ho paura (sopratutto per la gestione hdd) che non ci possa garantire ottime prestazioni. Noi gli ARM li utilizziamo in applicazioni di automazione ad alta velocita' e spesso ci siamo scontrati con i loro limiti. Ne parlero' con i colleghi sicuramente.
Se riuscissimo ad adottare le DRAM (spero proprio di si) la banda puo' tranquillamente arrivare a 10 volte quella che avevamo ipotizzato.

[cdimauro]

sarebbe sicuramente piu' semplice ma ho paura (sopratutto per la gestione hdd) che non ci possa garantire ottime prestazioni. Noi gli ARM li utilizziamo in applicazioni di automazione ad alta velocita' e spesso ci siamo scontrati con i loro limiti. Ne parlero' con i colleghi sicuramente.

Come non detto allora. Era soltanto per semplificare un po' il progetto, sia per voi che dovete svilupparlo, che per gli utenti finali.

Ma se bisogna scendere troppo a compromessi, allora è meglio lasciar prdere.

Se riuscissimo ad adottare le DRAM (spero proprio di si) la banda puo' tranquillamente arrivare a 10 volte quella che avevamo ipotizzato.

Io avevo ipotizzato 4GB/s (250Mhz * 128 bit), che sono già impressionanti per un SuperAmiga, ma a quanto si potrebbe arrivare a questo punto? 40GB/s? Mi pare troppo.

[ilbarbax]

No, per favore, che non se ne esce più col team di Natami. Sono troppo fissati con le loro idee, che già per la prima versione vogliono tirare fuori il SuperAmiga galattico con scapellamento a destra.

tipico approccio teutonico, che quando è completo è insuperabile...vediamo l'approccio italiano a cosa porta!

[bertocar]

Io avevo ipotizzato 4GB/s (250Mhz * 128 bit), che sono già impressionanti per un SuperAmiga, ma a quanto si potrebbe arrivare a questo punto? 40GB/s? Mi pare troppo.

si tratta di valori teorici e poi considera che la sdram deve essere sottoposta a refresh e questo occupa tempo al memory controller... bisognera' valutarne i costi/benefici.

Volevo sapere perche' secondo te ha senso un bus a 128bit.

[cdimauro]

Il bus a 128 bit lo vedo soltanto in termini di banda. Per me potrebbe anche essere a 64 bit DDR, o 32 bit DDR-2, o ancora 16 bit DDR-3; non è importante l'ampiezza, ma quanti byte possono leggere o scrivere per ciclo di clock.

Siccome hai parlato di SRAM prima, che può accedere a un solo dato per ciclo di clock, avevo ipotizzato un bus a 128 bit per potere leggere o scrivere 16 byte per ciclo di clock, in modo da arrivare ai 4GB/s che secondo me sarebbero ottimi per poter rilanciare la piattaforma Amiga.

Lo so che sono teorici, perché passando alle DRAM c'è il refresh che se ne mangia una percentuale (comunque piccola, se non ricordo male). Non è un problema anche perché avevi parlato di una banda maggiore di 10 volte rispetto alle SRAM, per cui è un prezzo che si può sicuramente pagare pur di ottenere valori di un ordine di grandezza più elevati.

Su questo punto potresti fornire qualche informazione in più? Che tipo di bus prevedi? A che frequenza potrebbero operare le DRAM? Quale sarebbe la sua ampiezza? In modo da poter valutare il picco teorico di banda a disposizione.

Ovviamente rimango sempre dell'idea di avere un bus unico, in modo da poter sfruttare l'intera banda per determinate periferiche (la circuiteria video; e il Blitter in particolare) a discapito di altre (la CPU, che potrebbe fungere semplicemente da controllore, come capitava spesso nei giochi Amiga), se l'applicazione / gioco lo richiede.

P.S. Tra l'altro ho qualche idea per poter patchare le routine di allocazione della memoria di AmigaOS, in modo da poter arrivare a sfruttare fino a 4GB, nell'eventualità che si possa integrare un simile quantitativo (la DRAM è molto economica).

[bertocar]

Capisco.

Proprio ora sto cercando un memory controller dram per capirne le caratteristiche e determinarne la banda disponibile.
Si potrebbe implementare direttamente nel fpga che funge da cpu ma non vorrei caricarlo troppo.

[cdimauro]

Meglio metterlo nell'FPGA che fungerà da chipset / northbridge. Vecchia maniera, insomma: la CPU, se ha richieste verso la memoria, le fa al chipset, che s'interfaccia direttamente con la memoria.

Questo perché credo che i 25K LE a disposizione per il chipset siano parecchi (servirà spremere le meningi per sfruttarli tutti), mentre per la CPU è un oggetto particolarmente complesso e credo sia meglio utilizzare tutti i LE soltanto per la sua sintesi.

Anche per questo credo che 2 soli FPGA da 25K LE potrebbero essere sufficienti per il progetto. Il terzo soltanto per l'audio e il controller floppy / hd mi sembra uno spreco.
Secondo me bisognerebbe lavorare intanto con 2 soli FPGA, poi se veramente il chipset diventerà così complicato da richiedere più di 25K LE (o comunque troppo complicato da essere gestito singolarmente), si potrà suddividerlo in due.

[bertocar]

Beh non era mia intenzione mettere 3 fpga uguali.
Forse la cpu e il processore video si, ma quello audio etc direi proprio di metterlo mooolto meno performante (e costoso), intorno a 5kle penso sia sufficiente.
Dato che trovo una gran quantita' di core fpga che integrano controller di dram, potrebbe essere una configurazione del tipo:
CPU(1) connesso al CHIPSET e a della memoria SRAM propria (opzionale, comunque priva di refresh)
VIDEO(2) connesso al CHIPSET
CHIPSET(3) svolge le funzioni audio, dispositivi e da tramite alla dram (percio' anche memory controller)
A questo punto potremmo trovarci che il chip VIDEO soffre delle latenze del CHIPSET.
Caso che immagino: il CHIPSET sta trasferendo blocchi filesystem all'HDD e contemporaneamente deve servire VIDEO che fa operazioni importanti.
In questo progetto quello che mi ha sempre creato una certa preoccupazione e' la mole di dati che dovra' gestire il chip VIDEO. Io non ho mai programmato blitter e copper, percio' non conosco bene i meccanismi che si possono innescare. Pero' immagino che se fossimo a 1920x1080 25p e ci fosse anche qualche operazione blitter il chip VIDEO abbia necessita' di accedere alla memoria con una certa importanza.
A te non spaventa questo? Nel senso non potremmo trovarci il resto del sistema quasi bloccato?

[cdimauro]

Non mi spaventa, perché ci sono già passato proprio con l'Amiga, che doveva gestire parecchie periferiche diverse che si contendevano l'accesso alla memoria. Per eliminare alla radice o ridurre i problemi di cui hai parlato, e che giustamente ti preoccupano, il chipset prevedeva degli slot riservati per le periferiche più importanti (refresh dram, disco, audio, primo sprite), cosicché questi avessero sempre degli accessi a esclusiva disposizione; mentre per altri dispositivi c'era un sistema di priorità che metteva il display al primo posto, a seguire gli altri sprite, poi il Copper, dopo il Blitter, e infine la CPU. Poiché per simulare l'Amiga questi meccanismi dovranno essere riprodotti, li utilizzeremo anche per le nuove caratteristiche.

[bertocar]

Avrei pensato a questa soluzione allora:
come la CPU ha una propria SRAM "privata" opzionale connessa direttamente (una sorta di FAST), potremmo fare la stessa cosa per il CHIP VIDEO. Questo ci darebbe piu' garanzie in caso di necessita'. Ovviamente sarebbe memoria non accessibile da altri dispositivi.
Che dici?