Hardware > Hardware (Classic 16-/32-Bit)

68K30L, Falcon und Suska-III-T2

<< < (138/149) > >>

MiST:

--- Zitat von: 1ST1 am Fr 25.04.2014, 14:02:28 ---Ist evtl. geplant, neben der A500-Emulation auch einen A1200/4000-Modus zu machen?

--- Ende Zitat ---

Ich habe den Thread hier nur "gekapert", weil der OP auf das MiST eingegangen ist. Ich denke das hier sollte ein Suska-Thread bleiben. Weitere Diskussionen daher bitte in:
http://forum.atari-home.de/index.php?topic=10668.0

wfoerster:
Hi zusammen,
ich bin wieder da. Kurz zur Info: ich hatte viel um die Ohren und war mit der Modellierung des 68K30 ausgelastet. Wen es interessiert: das war auf dem VCFe 15.0

https://speakerdeck.com/wfoerster/entwurf-einer-68030-compatiblen-cpu

Im Sommer und Herbst möchte ich wieder verstärkt an Suska arbeiten. Da das Projekt mittlerweile schon 10 Jahre alt ist und die Suska Boards nun bald 5. Geburtstag feiern, werde ich mir bis dahin was ausdenken :-)

Weitere Infos demnächst.

Grüße

Wolfgang

wfoerster:
Einen schönen guten Morgen zusammen,
ich poste in dieses Forum immer als erstes News, wenn ich welche habe; gerne könnt ihr das weiter streuen. Also: ich habe die Arbeiten an dem 68K30 Core soweit abgeschlossen. Das Projekt hat sich über fünf Jahre hinweggezogen - sorry dafür. Wenn dieser Prozessor fehlerfrei läuft, dann steht dem Falcon-kompatiblen IP-Core wohl bald nichts mehr im Weg. Den COMBEL habe ich bereits, der VIDEL ist so gut wie abgeschlossen und am Falcon DMA mit DDR-Interface muss noch Arbeit investiert werden.
Der 68K30 Core ist so komplex, dass es wohl erfahrene 'Nerds' geben muss, um diesen IP-Core zu debuggen. Ich alleine schaffe das definitiv nicht, zumal die Mannschaften, die ihn designen und debuggen unterschiedlich besetzt sein sollten.
Für den Falcon-DMA bräuchte ich noch jegliche Infos, die irgendwer von euch da draußen hat. Das hilft bei der Implementierung.
Also wer Lust, Muße, Zeit, Durchhaltevermögen, den erforderlichen Biss hat, der kann helfen, das alles voran zu bringen.

Herzliche Grüße

Wolfgang

Arthur:
Hallo Wolfgang, da hast Du ja eine frühen Beitrag gepostet. :)

wie bist Du bei der Entwicklung des 68k30 Cores vorgegangen? Konntest Du den 68K Core weiter entwickeln oder mußtest Du eine anderen Ansatz wählen? Könnte man den 68k30 auch aufbohren im Core? Also z.B. größere Caches oder wär das zu komplex bzw. bringt das bei DDR Speicher nicht so viel? Ich hoffe das sich genügend Debugger einfinden damit die Entwicklung schnell voran geht..

Bei der Entwicklung hast Du bei dem ST damals IC für IC im ST durch Piggy-Back Adapter ersetzt... machst Du das im Falcon genauso?
Auf jeden Fall eine klasse Leistung von Dir. 

wfoerster:
Hallo Arthur,
der 68K30 Core ist eine komplette Neuentwicklung, weil er strukturell ganz anders aufgebaut ist. Er nutzt Pipelining, so dass er deutlich schneller ist als der 68K00. Momentan liegt die maximale Taktfrequenz je nach Baustein für Cyclone FPGAs zwischen 32MHz und 35MHz. Der 68K30 hat momentan 4096 Byte Caches implementiert. Das bringt im Vergleich zu originalen Chips, die 512 Byte haben,  einen Geschwindigkeitsvorteil. Ich habe auf der VCFe in München im Frühjahr darüber einen Vortrag gehalten. Den findest Du hier:
https://speakerdeck.com/wfoerster/entwurf-einer-68030-compatiblen-cpu
Der Entwurf des Falcon geht anders als beim ST. Im Prinzip ist der Falcon eine Weiterentwicklung des Mega STE. Das sieht man ganz gut an dem 16 Bit Datenbus und den Signalnamen. Die Baugruppen sind anders auf ICs aufgeteilt und 'nicht so gute' Hardware wurde optimiert. Das kannst Du als Entwickler regelrecht vor Deinem geistigen Auge sehen. So war es nicht sonderlich schwierig, aus dem Suska Projekt den Combel zu bauen. Auch der Videl und die DMA sind nicht sehr kompliziert. Eine Schwierigkeit besteht nun aber dennoch in der Implementierung des Speicherinterface. Ich denke, dass es keinen Sinn macht, auf irgendetwas anderes als DDR zu gehen. Und das muss dann superschnell sein. Dazu gibt es zwei Ansätze: 1. Hard-IPs verwenden, das bedeutet fertige DDR Schnittstellen in FPGAs benutzen, womit man auf den Baustein festgelegt ist oder eine sehr performante VHDL-Modellierung zu schreiben, so dass auch das Speicherinterface quelloffen liegt und damit keine Abhängigkeit auf bestimmte Bausteine besteht. Ich verfolge momentan den zweiten Ansatz.
Ich hatte angekündigt, dass ich zu 10 Jahre Suska etwas bringen möchte und werde daher einige Teile für die kommende 2K14B Configware Version freigeben, so dass interessierte Personen über den Quellcode schauen oder sogar daran weiterbasteln können.

Grüße

Wolfgang

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete