Hallo. Mag nicht länger alleine vor mich hin werkeln. Schaut Euch mal meine Website an. Würde mich interessieren, was Ihr von der Sache haltet. Vielleicht findet sich auch jemand, der in das Projekt mit einsteigt. http://www.bomerenzprojekt.de
Coole Webseite!Schickes Design! Mit was hast Du die gemacht? Mit Notepad?
Schon interessant, welche CPU soll simmuliert werden,oder ist es eine Neuentwicklung deinerseits?
Frage von lalilu : welche CPU Es ist eine Neuentwicklung, und sie soll nicht simuliert werden, sondern sie ist fertig und getestet.
Tip: Lad' das Ding bei opencores hoch, und schau, was passiert. Nicht viel labern, lohnt nicht. Noch ein paar Anmerkungen: - "Getestet" ist eine extrem breitbandige Bezeichnung. Für mich ist es erst 'getestet', wenn ein GCC-Regresstest komplett durchgelaufen ist, für einen Airforce-Techniker damit noch lange nicht. - Etwa 80% der Entwickler/Anwender raffen nicht was gut ist, 40% machen gerne alles, was sie nicht kennen, schlecht, 90% sind bequem und machen nur das was sie gelernt haben. Deswegen: mach einfach dein Ding, wenn sich's von andern abhebt, und sich ein paar wenige daran beteiligen, freu dich. Wenn nicht, hast Du immerhin was gelernt. Andere Leute bauen Computer aus TTL-Logik oder gar Röhren nach.. - Was hier die Profis aufhorchen lässt ist: * Geringer Platzbedarf (FFs/Gates) * Hohe Taktfrequenz * Pipeline (wieviele Zyklen pro Befehl) * Tools (optimierender Compiler, Debugging) * Referenzapplikationen (meist spezielle Nischenanwendungen) * Gute Dokumentation - Merke: es gibt schon sehr viele gereifte Lösungen (von ZPU über Plasma bis OrSoc/Leon). Damit's keine "me2"-Entwicklung wird, sollte man ein Alleinstellungsmerkmal aufweisen. Und nu hab ich genug gelabert :-) Gruss, - Strubi
Ich pflichte meinem Vorredner bei. Noch einen
Weichkernzentralkleinrechner braucht die Welt nicht.
Eher schon etwas intelligente Peripherie! So eine Art Phy-Array :-)
>Aufsteckplatinen
Welcher Art sollen die denn sein und was sollte da drauf?
Hallo, ich habe mir das Projekt schon mal angeschaut, es ist erstaunlich was Josef G. innerhalb eines Jahres erreicht hat: Von ca 50 Seiten reiner Theorie (siehe Format der Website) zu einer neuen CPU (Alle Logikverschaltungen im Kopf durchdacht und auf Blätter geschrieben) über ein von ihm anschließend entworfenes Programm in der Linux-Bash welches diese Blätter in Software umsetzten. Anschließend übertragen in die Hardware mithilfe von VHDL. Und als die CPU dann lief mache er noch schnell eine Grafikkarte mit rein. Allerdings muss ich sagen, dass dieses Projekt so komplex ist, dass man erst zwei Tage dauerunterricht bräuchte um es zu überreißen. Ob es jetzt den i7 schlagen wird bezweifle ich mal aber die neuen Denkansätzte sind durchaus interessant. Vielen Dank an Herrn G. für die durchaus interessante Vorführung. Schönen Gruß Thomas
Dann sollte man es auf OC hochladen, wäre doch schade, wenn die Arbeit verkommt und das wird sie, wenn nicht 3-5 Leute beigreifen, das stabiliseren und weiterziehen und vor allem 30-50 Personen es runterladen und benutzen! Ohne eine Community lebt keine Software. Grüsse von jemandem, der vor 12 Jahren mal 33% einen skalierbaren 16-Bit RISC-Prozessor in Verilog mitentwickelt hat.
Habe mir jetzt erstmals kurz opencores.org angeschaut. Bin leider nicht so fit mit Internet, siehe meine Website. Habe auch meine ganze Dokumentation bisher nur auf Papier, nicht im Rechner. Ich möchte erst einmal weiter versuchen, meine Unterlagen per Post an eine größere Zahl von Leuten zu versenden. Also, bitte anfordern, Kopieren und Porto zahle ich.
Dann solltest du ernsthaft versuchen dich etwas mehr mit den neuen Medien anzufreunden, sonst wird die Resonanz ausbleiben. Die Hemmschwelle jemanden anzufragen ist schon so dermaßen hoch, dass ich mir nicht vorstellen kann dass da jemand drauf eingeht.
Bin noch eine Antwort schuldig auf die Frage von FPGA-Berater vom 24.10. (Welche Steckkarten?). Musste etwas länger darüber nachdenken. Um kurzfristig ein marktfähiges Produkt zustandezubringen, bräuchte man eine Karte mit SPI-Flash und Treiber-ROM eine reine Software-Karte (64 KByte ROM) einige herausgeführte Ein/Ausgangs-Bits eine RS232-Schnittstelle mit Treiber-ROM Man hätte dann fürs erste schon einmal ein von einem PC unabhängiges Gerät für Hobbyisten. Ich denke da an logisch-arithmetische Spielereien (siehe hexadezimaler Ziffernsatz), Assembler-Programmierung (siehe einfache CPU), und Steuerung von externer Selbstbau-Elektronik (siehe exakt berechenbare Programmlaufzeiten). Wenn man weitere Peripherie braucht (Drucker, Netz), kommuniziert man über RS232 mit einem PC. Für den Anfang ist ein Einsatz im Hobby-Bereich naheliegend, wo ein System auch mal abstürzen darf.
Josef G. schrieb: > Um kurzfristig ein marktfähiges Produkt zustandezubringen, bräuchte man > > eine Karte mit SPI-Flash und Treiber-ROM > eine reine Software-Karte (64 KByte ROM) > einige herausgeführte Ein/Ausgangs-Bits > eine RS232-Schnittstelle mit Treiber-ROM Hm, wenn ich meinen Senf dazu geben darf, ich glaube "ein marktfaehiges Produkt" wird nie daraus. Waere glaub ich auch der falsche Ansatz. Die Kosten fuer obige Karten mit Ihren nahezu trivialsten Funktionen (jedenfalls im Jahr 2011) sprechen gegen eine Ausbreitung. Eine ARM mit >100kByte RAM, > 128k Flash, x USARTS, SPI (SDIO) ggfl. auch LCD Treiber kommen fuer deutlich kleiner 10EUR daher. Um von Produkten sprechen zu koennen, muessten dann auch Themen wie ElektroG, EMV etc. geklaert sein. ...Was aber nicht heissen soll, dass das Projekt uninteressant waere. Gerade ein minimalistisches Projekt (im Hinsicht auf Resourcen und Hardwarekomplexitaet) hat Chancen eingesetzt zu werden. Die Chancen bestehen aber eher im Bereich der Nutzung, Verifikation und Weiterentwicklung der IP, denn in einer eigenen Hardwareplattform. Zumindest meiner festen Ueberzeugung nach. Gruss
Ich hab auch noch Senf: - Steckkarten/Modulsystem: Gibt's doch alles schon. Siehe Papilio Wings: http://papilio.cc/index.php?n=Papilio.Wings. Wenn die CPU auf einen Papilio passt, hat sie Popularitätschancen. - Die Community will mit Sicherheit Dokumentation und Anwendungsbeispiele im Netz sehen - Sich in die OpenCores-Dienste einzuarbeiten ist bestimmt weniger aufwendig als VHDL zu schreiben :-) Und lohnt sich wirklich.
Habe jetzt die CPU (Definition und VHDL-Code) auf meine Website hochgeladen. Habe auch am Erscheinungsbild der Seite ein wenig gebastelt. Hier ist nochmal der Link: http://www.bomerenzprojekt.de
Hi Josef, habe mir mal eben deinen Source und die Doku angesehen. Dabei sticht ein grosses Problem ins Auge: Du wirst vermutlich der einzige sein und bleiben, der den Code warten und erweitern kann. Ich bin da völlig aufgeschmissen, da irgendwas zu verstehen, da er offensichtlich die direkte Übersetzung der von Dir designten Logik ist, und zwar auf Gatter-Level. Habe nun schon viele OpenCore-Projekte evaluiert, und mein Eindruck ist, dass die meisten Projekte daran scheitern, dass die gute 'gemeinsame Sprache' fehlt, d.h. eine Code-Strategie besitzen, die teamkompatibel ist. So wie Dein Code aussieht, passt das Design mögl.weise optimal in LUTs, aber ist für den Laien absolut nicht zu debuggen. Wichtig ist auch der Aspekt der Wiederverwertbarkeit, also eine bestmögliche Modularisierung des VHDL-Projektes in gut getestete Einzelbausteine. Ich hoffe, das klingt nicht vernichtend, aber SO kannst Du Dein Projekt sehr schlecht 'verkaufen', auch wenn es ev. eine geniale Neuentwicklung sein mag. Grüsse, - Strubi
Josef G. schrieb: > Habe jetzt die CPU (Definition und VHDL-Code) auf meine > Website hochgeladen. Hallo Josef, der Kritik von Strubi schließe ich mich an. Weitere Kritik: - Zwei Takte cl0 und cl1 - Verknüpfung von Takten: fallen <= '0' when cl0 = '0' else cl1; - und dann das: aktiviere : process (cl0, fallen) So etwas schreit nach Wettläufen und Glitches. Inwieweit ist dein Design getestet, mit welchen Frequenzen, verschiedene FPGA usw. Steht in den Reports etwas von "bad design practice"? Weiterhin sehe ich es auch so, dass keiner mehr einen modularen Kleincomputer auf Basis von Steckkarten braucht. So etwas packt man alles in einen FPGA. Das meiste lässt sich direkt auf Logik abbilden, z.B. ADC-Ansteuerung, Signalvararbeitung, Ausgabe. Für manches hätte man gern eine CPU, weil keine Rechenleistung erforderlich ist aber die Ansteuerung einiger maßen komplex ist, wie z.B. ein Protokoll über die serielle Schnittstelle fahren, alphanumrisches Display, Netzwerk. Xilinx hat den Picoblaze und den Microblaze. Der Microblaze braucht schon ganz schön Ressourcen und ist Overkill für die serielle Schnittstelle und das Display, den Picoblaze muss man in Assembler programmieren, soweit ich mich erinnern kann. Eine CPU dazwischen programmierbar in C hätte eine Chance. Unter folgenden Randbedingungen: - nur ein Takt - weiter Taktbereich - kein externer RAM/ROM notwendig - keine bidirektionalen Signale, keine Tristates - anerkannter Bus, Wishbone - für kommerzielle Nutzer, verlässlicher Support durch eine Firma - eine aktive Community, damit du Feedback erhälst - Beispiel-Applikationen Auch wenn du jetzt hier heftige Kritik einsteckst, war es der richtige Weg an die Öffentlichkeit zu gehen. Tom
Ich denke, der umgekehrte Weg ist der Praktikablere: Ein System zur Verfügung zur Stellen, mit dem man seine 8Bit Controller Apps leicht auf einen FPGA portieren kann.
Zur Kritik von abaxor an der Konstruktion fallen <= '0' when cl0 = '0' else cl1 in Verbindung mit aktiviere : process (cl0, fallen) : Das Problem hatte ich übersehen. Ich habe die Stelle geändert und die neue, bereits geteste, Version hochgeladen. Zur Problematik mit den zwei Takten: Die CPU war ursprünglich für einen Aufbau mit Latches konzipiert. Flipflops habe ich nur verwendet, weil sie im FPGA angeboten werden, und man tausend Warnungen erhält, wenn man Latches verwendet. Über weiteres muß ich noch nachdenken.
Elektrohans schrieb: > Ich denke, der umgekehrte Weg ist der Praktikablere: Ein System zur > Verfügung zur Stellen, mit dem man seine 8Bit Controller Apps leicht auf > einen FPGA portieren kann. Verstehe ich nicht, was ist jetzt hier zu was umgekehrt? Tom
Weiteres zum Beitrag von abaxor vom 30.10.: In meiner Test-Konfiguration für das Spartan-3A-Starterkit dauert ein Vollzyklus, bestehend aus den Halbzyklen tA und tB, 960ns. Ich würde die Hälfte dieser Zeit für einen letztlich anzustrebenden Wert halten. Der kleinste Abstand von zwei Flanken beider Takte betrüge dann 30ns. Das bei Verwendung von zwei Takten auftretende Problem, über den Chip verteilt die relative Phasenlage beider Takte stabil zu halten, dürfte bei so niedrigen Frequenzen beherrschbar sein. Zwei Takte zu verwenden, hat den Vorteil, dass man sich die Option offen hält, die CPU mit Latches aufzubauen. Tristate-Busse stehen derzeit innerhalb des FPGA nicht zur Verfügung und werden von der Synthese-Software durch Logik ersetzt. Ich spekuliere aber darauf, dass es irgend- wann einmal die blanke CPU in einem eigenen Gehäuse zu kaufen gibt. Und dann wären Tristate-Anschlüsse optimal. Schon am 27.10. wurde von Vanilla das Wirtschaftlichkeits- Argument gegen Steckkarten vorgebracht. Dazu habe ich mir überlegt: Hardware-Module ("Steckkarten") könnten auch Teil der Hauptplatine oder sogar des zentralen FPGA sein, wenn die Einbindung so erfolgt, dass die Module für die Software wie Steckkarten aussehen. Auch in meiner Prototyp-Konfigu- ration ist die Testkarte nicht wirklich eine Steckkarte.
Josef G. schrieb: > Tristate-Busse stehen derzeit innerhalb des FPGA nicht zur Verfügung Sie standen mal zur Verfügung (früher, in der FPGA-Steinzeit). Damals gab es die Dinger sogar bis an die FPGA-Pins, sodass ein FPGA bis hinunter auf einzelne Subkomponenten in einen "normalen" Bus eingebaut werden konnte. Tristate-Busse wurden aber wegen ihrer geringen Geschwindigkeit und der Anfälligkeit für Buskollisionen aus dem Programm genommen. > und werden von der Synthese-Software durch Logik ersetzt. Kurz: Multiplexer.
Josef G. schrieb: > Schon am 27.10. wurde von Vanilla das Wirtschaftlichkeits- > Argument gegen Steckkarten vorgebracht. Dazu habe ich mir Ich habe noch Probleme mit deiner Zielgruppe, die du ansprechen willst. Die muss dir erst einmal klar werden. Danach kann man eine Wirtschaftlichkeit überhaupt erst abschätzen. Variante A: Lehrmaterial für Hardware- und Systemarchitekten Leider ist der Code sehr kompakt und nicht selbsterklären. Daher nicht pädagoisch anwendbar. Passt nicht wirklich Variante B: Softwareleute Die bekommen für wenig Geld schon 32bit uC´s für einen Apfel und Ei auch schlecht Variante C: Fans aus der 80er Jahren, doch dann musst du schon den Chip den sie so lieben nachbilden. Damit sie die alten Spiel Arcade und Co. wieder haben. Ein neuer Processor ist hier auch nicht gefragt. Variante D: Schließen der Lücke zwische Picoblaze und Microblaze. Da du bis 64k Adressieren kannst, wäre das unter Umständen was. Doch dann passt deine Kartenbauweise nicht dazu Die Resonanz im Forum hat dir auch gezeigt, dass keiner so richtig begeistet war, obwohl sich hier verschiedene Vertreter tummeln. Vielleicht habe ich noch eine Variante E vergessen!
Lothar Miller schrieb: > Josef G. schrieb: >> Tristate-Busse stehen derzeit innerhalb des FPGA nicht zur Verfügung > Sie standen mal zur Verfügung (früher, in der FPGA-Steinzeit). Damals > gab es die Dinger sogar bis an die FPGA-Pins, sodass ein FPGA bis Wie wird es aber mit INOUT signalen an einem gemacht? Da ist doch ein Ausgang und eine Eingang an einem Pin zusammengeschaltet. Wenn es ein Eingang ist, ist der Ausgang hochohmig. Eben bei bidirektionalen Daten Datenleitungen z.B. Die gibt es ja noch soncht könnte man keinen externen Speicher IC mehr anschließen.
Vorschau mit Absenden verwechselt. nochmal Lothar Miller schrieb: > Josef G. schrieb: >> Tristate-Busse stehen derzeit innerhalb des FPGA nicht zur Verfügung > Sie standen mal zur Verfügung (früher, in der FPGA-Steinzeit). Damals > gab es die Dinger sogar bis an die FPGA-Pins, sodass ein FPGA bis Wie wird es aber mit INOUT signalen an einem Pin gemacht? Da ist doch ein Ausgang und eine Eingang an einem Pin zusammengeschaltet. Wenn es ein Eingang ist, ist der Ausgang hochohmig. Eben bei bidirektionalen Daten Datenleitungen z.B.. Die gibt es ja noch. Sonst könnte man keinen externen Speicher IC mehr anschließen.
Hugo schrieb: > Coole Webseite!Schickes Design! > > Mit was hast Du die gemacht? Mit Notepad? Geil! Ich lach mich grad kaputt :D :D :D
René D. schrieb: > Eben bei bidirektionalen Daten Datenleitungen z.B. Die gibt es ja noch Richtig, aber nur an den IO-Pins, nicht im FPGA. Dort hat jede Leitung einen Treiber (Ausgang) und einen oder mehrere Empfänger (Eingang).
Thomas Reinemann schrieb: > Eine CPU dazwischen programmierbar in C hätte eine > Chance. Da muß ich mal etwas Werbung für die ZPU [1][2] machen ;-) Duke [1] http://opensource.zylin.com/zpu.htm [2] http://www.mikrocontroller.net/articles/ZPU:_Softcore_Implementierung_auf_Spartan-3_FPGA
Blubberblah schrieb: > Hugo schrieb: >> Coole Webseite!Schickes Design! >> >> Mit was hast Du die gemacht? Mit Notepad? > > Geil! Ich lach mich grad kaputt :D :D :D Sorry, Hugo, dass ich durch die Neugestaltung meiner Seite deine Pointe zerstört hab.
Josef G. schrieb: > Sorry, Hugo, dass ich durch die Neugestaltung > meiner Seite deine Pointe zerstört hab. Nicht ärgern lassen ;-) Josef G. schrieb: > Habe jetzt die CPU (Definition und VHDL-Code) auf meine > Website hochgeladen. Bin ich blind? Irgendwie hab ich den Code nicht gefunden. Hast Du auch einen Direktlink dazu? Duke
Duke Scarring schrieb: > Hast Du auch einen Direktlink dazu? http://www.bomerenzprojekt.de/Website/CPU-vhdl.html
Josef G. schrieb: > http://www.bomerenzprojekt.de/Website/CPU-vhdl.html Danke. Zum Code wurde ja schon einiges gesagt. Ich finde Ihn auf den ersten Blick auch nicht slebsterklärend, aber immerhin schön formatiert (sowas ist selten und wird m.E. unterschätzt). Hast Du eine Testbench dazu? Dann könnte ich das ganze mal durch den Simulator schicken... Duke
Duke Scarring schrieb: > Hast Du eine Testbench dazu? Eine Testbench habe ich leider nicht, aber immerhin eine funktionierende Applikation. Bitte schau Dir dazu nochmals meine Startseite an. Das Spartan-3A-Starterkit gibt es für etwa 200€. Die Unterlagen, wie auf der Seite beschrieben, würde ich Dir sehr gerne zusenden.
Hall Jesef G(bome), nach einem Blick auf den bisherigen Thread und den Code hier ein paar Anmerkungen: 2 Clocks sind ein NOGO schlechthin. Du machst das Leben dem Synthesetool (und Dir) nur unnötig schwer. Falls Du nicht alles in einem Clock erledigen kannst, dann arbeite mit Clockenables (welche Du aus einem Hauptclock ableitest, [mit einem Zähler, oder einem rückgeckopelten Schieberegister]) an FlipFlops. Dann kannst Du dem Synthesetool Multiclockconstraints mitgeben und alle freuen sich. Selbst auf einem Spartan3 solltest Du in der Lage sein eine Targetfrequenz von >40Mhz hinbekommen ( mit etwas Hintergrundwissen dürften auch 100Mhz ohne Pipelining hinzubekommen sein). Falls irgendmöglich nur unidirektionale Busse innerhalb des FPGAs definieren und benutzen. wie schon geschrieben gabs früher mal Tristatebusse in FPGAs, aber die Zeit ist vorbei. Die Synthesetools lösen das heute auf, aber es macht die Verifikation einfacher keine bidirektionalen Busse zu benutzen. Solls aus dem FPGA rausgehen, dann einen zusätzlichen Wrapper als Topinstanz hinzufüen. Simulation. Was nicht getestet ist funktioniert auch nicht. Auch wenn die Ergebnisse "augenscheinlich" stimmen. Insofern sind Testbenches zentraler Bestandteil eines solchen Projekts. Dein Code ist insgesammt so schön unterteilt, dass der sicherlich innerhalb von kurzer Zeit und mit wenig Simulationscode (die Clocks mal auf die Reihe gebracht) zu 100% getestet werden können. Eine gute Voraussetzung das der Code sich weiterverbreiten kann... Noch ein Wort zum Thema externer Bus. Um nicht das Rad neu zu erfinden, flansche einen Wishbonebus an die CPU. Dann stehen aus dem Stehgreif eine Grosszahl an Funktionen zur Verfügung. Gruß Andreas Die Benutzung von Variablen im Code macht die Sache aber nur oberflächlicher schöner. Kannst Du Dir eigentlich sparen.
Noch ein paar Punkte zu deinem Source: Asynchroner Reset = BAD Design Praktice Die Synthesetools sind nicht darauf ausgerichtet das Inputdelay beim asynchronen Reset korrekt zu verarbeiten. Damit ist nicht gewährleistet dass deine CPU im selben Clockzyklus aus dem Reset herauskommt! Zweiter Punkt, positive Logik lässt sich besser lesen als negative (Beispiel Reset statt nrs)... Gruß Andreas
B.L. hat mir gemailt. auf meiner Seite sei die Verlinkung zu CPU-doku und CPU-vhdl nur bei aktiviertem Javascript zu sehen. Ich habe mangels tieferer Kenntnisse einen black-box-Webseitengenerator verwendet und kann es nicht ändern. Stattdessen hier nochmals alle Direktlinks: http://www.bomerenzprojekt.de/Website/home.html http://www.bomerenzprojekt.de/Website/CPU-vhdl.html http://www.bomerenzprojekt.de/Website/CPU-doku.html
Wieso scannst du die Dokumentation die du da geschrieben hast nicht einfach ein und lädst die Bilder hoch? Dann könnte sich jeder mal das Design anschauen.
Habe nachgedacht über das Problem der zwei Takte, angeregt durch den Beitrag von bergy vom 5.11. Das Problem scheint nicht zu sein, dass zwei Takte real nicht funktionieren würden, sondern dass sie bei der Simulation Schwierigkeiten machen, weil man eine einzige Zeitbasis braucht, und nicht zwei. Tatsächlich werden aber ohnehin in der realen Anwendung die Takte von einem gemein- samen Master abgeleitet. Man muß also für die Simulation nur den Master hinzunehmen. Er liefert die Zeitbasis. Konkret: Ein als Ring betriebenes Schieberegister erhält den Startwert 00000011 und wird mit dem Master getaktet. cl0 und cl1 erhält man als zwei benachbarte Bits des Schieberegisters, wobei cl1 vorauseilt. Man braucht also keine zusätzlichen Clock-Enables, und muß auch sonst am Code der CPU nichts ändern. Noch zum Reset: Er ist nicht asynchron, sondern endet gemäß Spezifikation im Bereich der gemeinsamen langen Pause von cl0 und cl1, und das Ende kann an eine Flanke des Masters gekoppelt werden.
Andreas Bergmann schrieb: > Falls irgendmöglich nur unidirektionale Busse innerhalb des FPGAs > definieren und benutzen. ... es macht die Verifikation einfacher > keine bidirektionalen Busse zu benutzen. Nach meiner Kenntnis machen Tristates bei der Simulation keine Probleme. Gerade dafür gibt es ja den Datentyp std_logic. > Dein Code ist insgesammt so schön unterteilt, dass der sicherlich > innerhalb von kurzer Zeit und mit wenig Simulationscode (die Clocks mal > auf die Reihe gebracht) zu 100% getestet werden können. Eine gute > Voraussetzung das der Code sich weiterverbreiten kann... Schön, mal was positives zu lesen.
Josef G. schrieb: > Das Problem scheint nicht zu sein, dass zwei Takte > real nicht funktionieren würden, sondern dass sie bei der > Simulation Schwierigkeiten machen, weil man eine einzige > Zeitbasis braucht, und nicht zwei. Tatsächlich werden aber > ohnehin in der realen Anwendung die Takte von einem gemein- > samen Master abgeleitet. Man muß also für die Simulation > nur den Master hinzunehmen. Er liefert die Zeitbasis. Die Simulation hat nicht mit den zwei Zeitbasen Schwierigkeiten, typischer Weise wird mittlerweile eh auf ps Basis simuliert wenn man mit mehreren Zeitbasen und/oder DCMs / PLLs arbeitet. Problematisch ist da eher dass man im Normalfall mit simpleren Modellen simuliert und nicht auf Gatterebene... > > Konkret: Ein als Ring betriebenes Schieberegister erhält > den Startwert 00000011 und wird mit dem Master getaktet. > cl0 und cl1 erhält man als zwei benachbarte Bits des > Schieberegisters, wobei cl1 vorauseilt. > > Man braucht also keine zusätzlichen Clock-Enables, > und muß auch sonst am Code der CPU nichts ändern. BAD DESIGN PRACTICE! Es würde zwar grundsätzlich funktionieren, aber diverse Effekte die sich aus dieser Konstruktion werden im Falle einer normalen Logigsimulation nicht berücksichtigt: Das Delay vom Ausgang des jeweiligen Flipflops über die Globalclockbuffer (welches das Design in weiser Voraussicht hoffentlich automatisch einfügt) bis der Takt endlich auf dem Clocknetz ist. Wenn sowas nicht notwendig ist, dann macht man das auch nicht! Eine Möglichkeit besteht darin, wie schon beschrieben zusätzliche Clockenables zu benutzen ( und ggfl. Multiclockconstraints) oder aber technologie abhängige Komponenten wie DCMs und PLLs, welche es erlauben mehrere clocks aus einem Eingang abzuleiten ( z.B. mit 45,90,180,270 Grad Phasenverschiebung). Die Delays aus diesen Komponenten in die Clocknetze ist vom Design bereits auf solche Anwendungen optimiert und von den Synthesetools berücksichtigt. > > Noch zum Reset: Er ist nicht asynchron, sondern endet > gemäß Spezifikation im Bereich der gemeinsamen langen > Pause von cl0 und cl1, und das Ende kann an eine > Flanke des Masters gekoppelt werden. Das die Quelle deines Resets per Design synchron definiert hat ist hier nicht entscheidend. Das Problem besteht darin, dass Du im Design einen asynchronen Reset modelierst. Aktuelle FPGAs enthalten kein Resetnetzwerk mehr sondern routen dieses ganz normal in der Fabrik. Die Designtools sind nicht auf die Verwendung deines Szenarios optimiert, Du musst nun entsprechende Constraints an dein Design anlegen, damit garantiert ist, dass der Reset vom Timing her korrekt geroutet wird. Bei deinem Takt aus dem obigen Post (ms) ist das noch kein Problem, wenn wir aber mal realistischere CPU Geschwindigkeiten (mit einer Clockperiode von sagen wir mal 10ns anlegen) sieht die Sache (zumahl in einem Spartan3) schon wieder anders aus. Die Kunst einen "guten" VHDL Code zu schreiben, ist seine Codierung entlang der Leitlinien der FPGA Hersteller zu gestalten. Für heutige Verhälltnisse kostet das auch nix. Im Falle deiner CPU bedeutet dies: Innerhalb des Designs synchrone Resets zu nutzen (und auch nur da wo Resets tatsächlich notwendig sind), sowie (für das Gesamtdesign auf einem PCB) den von aussen kommenden Reset von digital zu filtern (um versehendliche Resets von aussen zu unterbinden, heutige FPGAs sind an Ihren Eingängen dammich schnell (und damit empfindlich) eine Transiente von einigen 100ps wirst Du ggfls. nur durch "unerklärliche" Resets, oder Hänger der CPU sehen). Wenn Du diverse Dokumentationen von CPUs durchsuchst (vor allem von richtigen CPUs in Silikon) wirst Du eine Mindestresetdauer finden, das schreiben Die nicht weil die Böse sind, oder deren Chips so schlecht oder langsam wären (eher das Gegenteil). Die Erfahrung (aus dem Produktsupport) zeigt eher, dass es notwendig war die Resetleitung intern gegen eben jene kurzen Störungen abzusichern...
Josef G. schrieb: > Andreas Bergmann schrieb: >> Falls irgendmöglich nur unidirektionale Busse innerhalb des FPGAs >> definieren und benutzen. ... es macht die Verifikation einfacher >> keine bidirektionalen Busse zu benutzen. > Nach meiner Kenntnis machen Tristates bei der Simulation keine > Probleme. Gerade dafür gibt es ja den Datentyp std_logic. Der Simulator und auch die Synthesetools lösen das schon auf (und machen damit was ganz anderes aus deinem Code als das was Du beschreibst (auch nicht schön). Entscheidender ist aber was passiert, wenns mal nicht so läuft wie der Entwickler sich das so vorgestellt hat... Je nach verwendetem Simulator und Art der Simulation (offline, online) wird es schon schwieriger die multiplen aktiven Treiber zu erroieren. Hinzu kommen auch immer wieder hübsche Softwarebugs in Synthese- und Simulatoren, welche dann auf die falsche Codezeile oder das falsche Bit in einem Signalvektor verweisen. Dann wird die Suche dann schon sportlicher ;) Mein Fazit: Ich vermeids einfach, aber ich will da keinem den Spass nehmen, wenn er unbedingt will...
Moin, der Herr Bergmann hat dazu schon so gut wie alles gesagt, das kann ich nur bestätigen. Da gibt's dann die lustigen Effekte, dass das Design auf 25 MHz läuft, auf 100 MHz nicht mehr, weil irgendwelche "Race conditions" (siehe Glitches) auftreten. Mit asynchronen Signalen und unterschiedlichen Clocks (siehe auch Warnungen zum Thema Clock aus kombinatorischer Logik) bin ich schon so oft auf gut Deutsch die Fresse gefallen (und das viel später als in der Simulation). Also: Gewisse Warnungen der Tools NIEMALS ignorieren. Irgendwie fehlt mir bei der Diskussion der eigentliche Clue an dieser CPU, mal ganz abgesehen vom VHDL-Design. Wie sieht's denn von den Resourcen aus? Die ZPU wurde hier ja schon erwähnt, das Studium des Code der Zealot-Variante kann ich betreffend Code-Design nur empfehlen. Viele mögen zwar die Stack-basierte Arch nicht, aber das Ding tut hier seinen Job prima und läuft nahezu am Taktlimit. Vor allem hat es: - GCC-Toolchain - Funktionierenden (JTAG-)Debugger - Wishbone - Unterstützung für so einige Plattformen Schön sind auch die "Design-Rules", die man so in der LEON-Architektur findet. Aber das ist wieder ein anderes Karat / ganz andere Anforderungen. Gruss, - Strubi
Ich möchte zurückkommen auf den Titel dieses Forum- Beitrags und auf die Startseite meiner Website. Das Projekt besteht aus einer CPU, sowie einer Gesamt- Hardware und einer ROM-Software, welche ausgelegt sind für die Einbindung von Erweiterungen (Hardware mit ROM- Software) und für exakt berechenbare Programmlaufzeiten. Dazu kommt ein, wie ich meine, interessanter Zeichensatz. Die CPU sehe ich als Weiterentwicklung von nicht mehr erhältlichen Prozessoren wie 6502 oder 8085, mit erweitertem Adressraum, leicht berechenbaren Code-Ausfürungszeiten, und einem, wie ich meine, Programmierer-freundlichen Befehlssatz. Alle Speicherzugriffe sollten gleich lang dauern, um ohne zusätzliche Maßnahmen das Konzept der exakt berechenbaren Programmlaufzeiten durchhalten zu können. Aus dem Ziel, viele Speichertypen (zB. Parallel-Flash) ohne Repeat-Zyklen ansteuern zu können, ergibt sich eine anzustrebende Dauer für einen Vollzyklus tA+tB von nicht unter 500ns. Am liebsten hätte ich die blanke CPU als speziell gefertigten Chip in einem eigenen Gehäuse. Ersatzweise habe ich erst einmal einen FPGA-Prototyp für die CPU und einen Teil der Peripherie realisiert, der sich vielleicht für eine Kleinserie weiterentwickeln lässt. Damit soll auch der Code für die CPU getestet werden, um mit ihm vielleicht einmal einen endgültigen CPU-Chip zu realisieren. Aus dieser Sicht ist es uninteressant, ob das Design auch bei höheren Frequenzen funktionieren würde, und es wäre widersinnig, das CPU-Konzept zu verbiegen, um es an Eigenheiten der FPGA-Architektur oder der Synthese- Software oder der Simulations-Software anzupassen. Die CPU ist von mir nicht gedacht als Konkurrenz zu Softcores, welche speziell für FPGAs optimiert sind, und schon gar nicht zu 32-Bitern. Wenn jemand die CPU für FPGAs optimieren will, mag er das tun, dies ist nicht mein Ziel. Ich hoffe weiter, Leute zu finden, die bei dem Projekt mit- machen. Die Resonanz bisher ist mäßig, aber größer als Null. Josef G.
Josef G. schrieb: > Aus dieser Sicht ist es uninteressant, ob das Design auch > bei höheren Frequenzen funktionieren würde, und es wäre > widersinnig, das CPU-Konzept zu verbiegen, um es an > Eigenheiten der FPGA-Architektur oder der Synthese- > Software oder der Simulations-Software anzupassen. Bei ASICs gelten mal noch ganz andere Designregeln. Willst Du wirklich einen 50'000 € teuren Tapeout als Totgeburt auf dem Tisch liegen haben? Aus eigener Erfahrung kann ich dir sagen, dass man da eine Menge Hausaufgaben erledigen muss (inkl. sich mit den Eigenheiten der Tools/Architektur zu beschäftigen), bis man zum eigenen Silizium kommt. Abgesehen davon man sich überlegen sollte, was das besondere Merkmal des Chips ist, damit ihn jemand kauft. Sorry, aber ich hab den Witz an deiner CPU nicht verstanden, Du machst keinerlei Angaben über Maximal-Takt, Tools (Assembler) und Resourcenverbrauch (FF/Gates), bisher sind also die "Verkaufsargumente", vorneweg der unlesbare VHDL-Code, sehr schwach. Kann mir nicht vorstellen, dass sich so Mitstreiter finden. Die Jungs hier haben Dir schon ne Menge Tips gegeben. Mein Tip: Befolge sie, schreib das Ding nochmal nach den gängigen Designregeln neu und stell's bei opencores.org rein. Übrigens: Ohne vernünftige Testbench sag jeder Chipdesigner erst mal: Njet. Ciao, Boeserfisch
Zum Beitrag von BöserFisch Es müsste nicht gleich ein ASIC sein. Ein Antifuse-FPGA von Actel täte es auch. Der Witz an der CPU ist der Befehlssatz. Aber den schaut sich ja keiner an.
Die Zeiten der Assembler-Hacker sind seit einer ganzen Weile vorbei, vor allem im kommerziellen Bereich, auf den du offenbar abziehlst. Das kann sich heutzutage niemand mehr finanziell leisten. Es interessiert ehrlich gesagt nur den Programmierer des C-Compilers, wie gut der Befehlssatz einer CPU ist.
... schrieb: > Die Zeiten der Assembler-Hacker sind seit einer ganzen Weile vorbei, vor > allem im kommerziellen Bereich, auf den du offenbar abziehlst. Das kann > sich heutzutage niemand mehr finanziell leisten. Es interessiert ehrlich > gesagt nur den Programmierer des C-Compilers, wie gut der Befehlssatz > einer CPU ist. Na das Argument das im kommerziellen Bereich überhaupt kein Assembler mehr vorkommt ist nicht ganz wahr. für kleine Kontrollaufgaben (in denen z.B. der Picoblaze) hergenommen wird, ist C-Programmierung auch Overkill... Auch im Securitybereich wird oft noch auf Microcontrollern in Assembler programmiert. Mit einer MCU welche dann noch gleiche Ausführungszeiten für jeden Befehl hat, werden diverse Angriffsmöglichkeiten ausgeschlossen. Aber hier ist die Ausführungsgeschwindigkeit und die Portierbarkeit sehr wichtig... Auf der anderen Seite sehe ich den Zielkreis des Gesamtsystems gegen Null gehen. Auch heute noch gibt es 8051, 6502 und 8085 sowie Z80 in Embeddeden Systemen. Nur ein paar handvoll Leute behereschen bei diesen noch die Assemblerprogrammierung. Eine weitere CPU muss wie schon geschrieben "Handfeste" Alleinstellungsmöglichkeiten haben und möglichst Universal einzusetzten sein. wenn Josef G. hier schreibt, dass (Zitat) >Aus dieser Sicht ist es uninteressant, ob das Design auch >bei höheren Frequenzen funktionieren würde, und es wäre >widersinnig, das CPU-Konzept zu verbiegen, um es an >Eigenheiten der FPGA-Architektur oder der Synthese- >Software oder der Simulations-Software anzupassen. dann mag das aus seiner Sicht stimmen. Aber kauft sich jemand eine neue Plattform, dessen praktischer Nutzen, die Programmierung einer neuen CPU mit einem schönen Befehlssatz und einem interessanten Zeichensatz ist, wenn er das Ergebnis seines Lernprozess wiederum nicht in anspruchsvolleren Projekten (sprich höhere Taktfrequenzen, weniger Clockresourcen, vollständiger Codecoverage und Simulationsbenches) übernehmen kann? Ich habe da mehr als nur Zweifel... Die gemachten Aussagen hier im Forum sind mit ganz wenigen Ausnahmen sehr fundiert und wollen dem TO nun wirklich nichts böses, sondern zum Nachdenken anregen.
> Der Witz an der CPU ist der Befehlssatz. > Aber den schaut sich ja keiner an. Der Befehlssatz ist schön und gut. Jede noch so kleine CPU hat einen verfügbaren C-Compiler. Damit mit zu 90% programmiert. Wichtig ist, dass der C-Compiler optimal den Befehlsatz ausschöpft und dafür ist ein sinnvoller Befehlsumfang notwendig. Gegen eine bestehende CPU keine Chance. 8bit ist nun mal Historie. Im FPGA als Softcore um wenig Resourcen zu verbrauchen, da wäre noch Bedarf. Der Core muss nicht mal optimiert sein. Eine herstellerunabhäniger Code wäre schon ausreichend.
Du hast Register Schleifenzähler und Schleifenrücksprungaddresse. Viel wichtiger ist ein Stackregister und das sehe ich nicht?
Ein spezielles Stackregister muss ja nicht unbedingt vorhanden sein, so lange man einen Stack mit den vorhandenen Befehlen realisieren kann.
Hallo Habe meine Website überarbeitet. Es muß mich nun niemand mehr kontaktieren, um Unterlagen zu meinem Projekt zu erhalten. Alles ist auf der Webseite verfügbar. Vielleicht hat jemand Interesse, das Emulationsprogramm auszuprobieren. Oder es hat jemand ein Spartan-3A/3AN- Starterkit und ist bereit, die Konfiguration zu testen. Über Rückmeldungen würde ich mich freuen. Josef G. http://www.bomerenzprojekt.de
Siehe in diesem Forum auch unter der Rubrik Codesammlung: Beitrag "Ein 8bit-Rechner auf dem Spartan-3A-Starterkit"
Leider sind in der Rubrik Codesammlung anscheinend kaum FPGA/VHDL-Leute unterwegs. Da ich jetzt eine konkrete Fragestellung habe, möchte ich mir erlauben, hier bei FPGA, VHDL & Co die Diskussion nochmal fortzuführen. Thema: DDR2-RAM. Ich betreibe auf meinem Spartan-3A-Starterkit das DDR2-RAM mittels eines vereinfachten Verfahrens, ohne das von Xilinx bereitgestellte Werkzeug MIG. Dabei werden die 4 Datenworte eines Bursts als ein ein- ziges Datenwort behandelt. Es wird also nur ein Viertel der Speicher- kapazität genutzt, und nur ein Viertel der möglichen Geschwindigkeit. Der Grund für diese Vorgehensweise ist, dass mir die Verwendung des Werkzeugs MIG zu kompliziert ist, und dass ich für meine Anwendung keine Burst-Zugriffe gebrauchen kann, sondern das RAM als Ersatz für ein auf dem Board nicht vorhandenes SRAM oder einfaches DRAM verwenden möchte, als Peripherie für eine CPU, welche mit starrem Timing laufen soll. Noch ist nicht sicher, ob das Verfahren stabil auf allen Exemplaren des Boards funktioniert, wegen eines vielleicht bestehenden Glitch-Problems. Näheres siehe meine erste Antwort im Beitrag in der Rubrik Codesammlung. Vielleicht gibt es noch andere Leute, die an einer vereinfachten Nutzung des DDR2-RAMs interessiert sind, und die bereit sind, das Verfahren zu testen. Ich wäre daran interessiert zu erfahren, ob Fehler auftreten. Der Code ist zu finden auf meiner Website (Seite Downloads). Wer kein Interesse an der Gesamt-Konfiguration hat, findet den DDR2-RAM-Treiber als Teil der Datei flhtest.vhdl. Josef G.
Zu dem möglichen Glitch-Problem beim Lesen des DDR2-RAM: Habe mich informiert über den inneren Aufbau von DDR2-RAM. Es scheint so zu sein, dass die vier Datenbits eines Bursts parallel in ein Schieberegister geladen werden und dann nacheinander in das am Ausgang liegende Bit des Schiebe- registers gelangen. Es können also gar keine Glitche auf- treten, da ein Flipflop, welches mit dem alten Wert geladen wird, keinen Glitch produziert.
Vermutlich schauen nicht alle FPGA/VHDL-Leute auch in das Forum Codesammlung. Ich will deshalb hier nochmal auf meinen dortigen Beitrag aufmerksam machen. Die Konfiguration für das Spartan- 3A/3AN-Starterkit ist inzwischen durch Anbindung einer SD-Karte soweit ausgebaut, dass sie nicht mehr nur als Ersatz für eine noch zu bauende Hardware anzusehen ist, sondern für Hobbyisten auch als eigenständiges Gerät interessant werden könnte. Beitrag "Ein 8bit-Rechner auf dem Spartan-3A-Starterkit"
Naja, das Spartan ist zwar ein nettes Board, aber was bitte will man da reinbringen? Für eine 8Bit App reicht ein AVR. Ich denke, mal sollte auf eine etwas leistungsfähigere Plattform einschwenken. Es muss auch genügend Platz für FPGA Apps vorhanden sein, wenn man etwas mit dem System anfangen können soll, denke ich.
J. S. schrieb: > ... sollte auf eine etwas leistungsfähigere Plattform einschwenken. Mit Ausnahme des Block-RAM lastet die aktuelle Konfiguration das FPGA nur zu etwa 20% aus.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.