microCore enstand während der letzten 20 Jahre bei der Realisierung eingebetteter Systeme mit FPGAs als mein persönliches Werkzeug, um effizienter arbeiten zu können. Nun ist es "fertig" und ich habe es auf Github veröffentlicht: https://github.com/microCore-VHDL Die Dokumentation ist hier: https://github.com/microCore-VHDL/microCore/tree/master/documents Am besten erstmal "uCore_overview.pdf" lesen. microCore ist aus drei Gründen ungewöhnlich: 1. Zuerst war der Assembler, nämlich die Programmiersprache Forth, und dann erst kam die Hardware. 2. Die Datenwortbreite kann vor der Synthese beliebig eingestellt werden zwischen 12..32 Bits. "12 Bits", weil man mindestens 4096 Instruktionen adressieren können will. "32 Bits", weil der Crosscompiler (noch) auf einem 32-bit System aufsetzt. Ansonsten ist die Wortbreite nur durch die vorhandenen FPGA-Ressourcen begrenzt. 3. Der "Pause" Mechanismus, ein janusköpfiger Bruder des Interrupts: Interrupt: Ein Ereignis hat stattgefunden, das die Software NICHT erwartet hat. Pause: Ein Ereignis hat NICHT stattgefunden, das die Software erwartet hat. Die UART in microCore löst z.B. dann eine Pause aus, wenn versucht wird, die UART auszulesen - aber (noch) gar kein Zeichen empfangen wurde. Normalerweise wird dann im Pause-Trap der Multitasker aufgerufen und eine andere Task aktiviert. Oder im Trap wird sofort ein EXIT ausgeführt, so dass der Prozessor solange auf der Stelle tritt, bis die UART ein Zeichen empfangen hat.
schon mal sehr schön, dass der Core auf git ist zum Einsehen und Nutzen. Die Dokumentation ist auch nicht mager. Erster Tipp: in fpga.vhd:156 (und nicht nur dort)
1 | sema_proc : PROCESS (clk, reset) |
2 | BEGIN
|
3 | IF reset = '1' AND async_reset THEN |
4 | flags(f_sema) <= '0'; |
5 | ...
|
1. Du verwendest zwei asynchrone Resets. Dann sollten auch beide in der sensitivity Liste auftauchen. 2. Wenn das zeitkritische Signale betrifft (d.h. eigentlich alles was nicht auf ein GPIO rausläuft), dann sollte der Reset auf die Taktdomäne einsynchronisiert werden. Das ist wichtig für das Place&Route. Zur Nutzbarkeit mit forth kann ich nichts sagen. Sicherlich nicht für jedermann. Das können andere aber besser beurteilen.
"1. Du verwendest zwei asynchrone Resets. Dann sollten auch beide in der sensitivity Liste auftauchen." async_reset ist eine boolsche Konstante. Der gesamte Core kann mit synchronem oder asynchronem Reset synthetisiert werden, das hängt von async_reset ab, das am Anfang von functions.fs definiert ist. Das ist "conditional compilation für Arme" in VHDL ;) "2. Wenn das zeitkritische Signale betrifft (d.h. eigentlich alles was nicht auf ein GPIO rausläuft), dann sollte der Reset auf die Taktdomäne einsynchronisiert werden. Das ist wichtig für das Place&Route." Das reset in der Sensitivity List wurde in fpga.fs einsynchronisiert vom externen reset_n. Das ist nicht nur fürs P&R wichtig, sondern auch gegen Metastabilität gut, weil sonst ein Resetende kurz vor einer aktiven Clockflanke das ganze System aus dem Gleis werfen kann.
> > Zur Nutzbarkeit mit forth kann ich nichts sagen. Sicherlich nicht für > jedermann. Das können andere aber besser beurteilen. Es gibt eine recht grosse Forth-Community, insbesondere rund um die J1-CPU. In der Industrie gibt es zum entsprechenden Nischenmarkt allerdings auseinanderdriftende Meinungen... Ich persoenlich finde Stack-Maschinen wegen ihrer guten Verifizierbarkeit und recht elegant umsetzbarer Fehler-Intoleranz sehr interessant, muehsam ist nur, gute C-Compiler dafuer zu bauen. Leider ist mit dem Untergang der Transputer auch sehr viel Know-How dazu versackt, so ist das Ganze hierzulande recht unpopulaer und die 'Fachwelt' entsprechend ignorant. In den Staaten sieht's anders aus (da ist auch die RTX-Serie von Harris noch nicht vergessen...)
Mathearsch schrieb: > Was ist ein Echtzeitprozessor? Ein Prozessor, der deterministische Ausführungszeiten seiner Instruktionen hat und deshalb Programme in ausrechenbarer=beweisbarer Geschwindigkeit erledigt. Nicht-Echtzeitprozessoren haben z.B. einen Programmcache. In Abhängigkeit davon, ob der Cache mit dem gerade auszuführenden Code bereits geladen ist, oder nicht, ergeben sich deshalb sehr unterschiedliche Ausführungszeiten.
Martin S. schrieb: > .. muehsam ist nur, gute C-Compiler dafuer zu bauen. Ein C-Compiler Prototyp für eine ältere microCore-Version wurde an der FH Nordwestschweiz in Windisch (CH) erstellt auf der Basis von LCC. Da musste nicht nur das uCore-Backend gebaut werden, sondern das Frontend auch für Stackallokation umgeschrieben werden. Das Ergebnis war ausgesprochen ermutigend, ca. 90% der lokalen Variablen konnten auf dem Datenstack gehalten werden mit entsprechenden Stackoperationen. Beim letzten größeren Einsatz von uCore für den MERLIN Satelliten waren wir zu dem Schluss gekommen, dass die uCore-Programme in eingebetteten Systemen im allgemeinen so klein sind, dass sich der ganze C-Kram nicht lohnt. Zumal in solchen Anwendungen im allgemeinen der Sprachumfang, den man dafür in Forth braucht, sehr übersichtlich ist. Bei MERLIN waren es aber immerhin schon 10k Instruktionen Objektcode.
Klaus S. schrieb: > Ein C-Compiler Prototyp für eine ältere microCore-Version wurde an der > FH Nordwestschweiz in Windisch (CH) erstellt auf der Basis von LCC Tja, der LCC...ansich koennte man mit dem intermediaeren Bytecode schon was machen (da gibt es auch die X32 CPU). Leider ist der LCC nicht C99-komplett und hat sich fuers taegliche Engineering nicht wirklich behaupten koennen. Ein GCC/LLVM sollte es schon sein. Die einzig mir bekannte Stack-Hybride die damit vernuenftig nutzbar ist, ist die ZPU-Architektur. Das Problem ist halt bei fast allen Optimierern, dass sie auf Basis von Registern arbeiten und man damit den Hybriden (Register-Fenster im Stack) eben braucht, sonst geht sehr viel Performance floeten.
Martin S. schrieb: > > Ein GCC/LLVM sollte es schon sein. > Die einzig mir bekannte Stack-Hybride die damit vernuenftig nutzbar ist, > ist die ZPU-Architektur. Was bitte ist die ZPU-Architektur? > Das Problem ist halt bei fast allen > Optimierern, dass sie auf Basis von Registern arbeiten und man damit den > Hybriden (Register-Fenster im Stack) eben braucht, sonst geht sehr viel > Performance floeten. microCore war gut als LC-C Prozessor. Der LCC hatte Forthcode erzeugt, der dann im Crosscompiler weiter optimiert wurde. Das Frontend war die 3. Iteration in der Kunst der Stackallokation. Die Literatur dazu ist - verglichen mit Registerallokation - SEHR übersichtlich und leider ist von den Arbeiten an der FHNW nichts veröffentlicht worden. Den Returnstack von uCore hatte ich mit Absicht in den Datenspeicher gelegt, so dass da Stackframes gebaut und sowohl relativ zum Returnstack als auch mit absoluten Adressen zugegriffen werden kann. Von sich aus kennt uCore keine Bytes - und hier beißt es sich mit C, während das Forth egal ist. Macht aber nichts, wenn auf Unions verzichtet wird. Als der LCC uCore lernte, hatte ich eine Bytedressierung parallel zur nativen Zelladressierung eingebaut. Das ist aber aus zwei Gründen Mist: 1. Es beschränkt die Datenwortbreite auf Vielfache von 8. 2. Diese Mischform Celladressen UND Byteadressen - das will man wirklich gar nicht. Überhaupt Bytes: Wer die Bytes zum Hardwarestandard für Speicherbreite erhoben hat, gehört noch nachträglich geteert und gefedert. Ja, mit den Bytes konnte man ein paar Speicherzellen einsparen, als Speicher noch teuer war. Funktional bringen die Bytes aber gar nichts, machen aber das Memoryinterface zum Multiplexergrab. Und eine zusätzliche Stolperstelle für die Software sind sie auch noch. "Alignment". uCore ist Zelladressiert und eine Zelle ist data_word_width breit und wenn die Zelle breiter als 8 Bits ist, dann kann man damit tatsächlich auch 8-bit Werte verarbeiten.
Klaus S. schrieb: > https://github.com/microCore-VHDL Das sieht, beim kurzen Blick in den Doc Folder, wirklich sehr gut aus. Du hast da ein sehr schönes Projekt gebaut. Glückwunsch :) Aber wenn ich die Lizenz richtig verstehe, dann darf man microCore nicht in komerzielle Projekte einbinden? Klaus S. schrieb: > Was bitte ist die ZPU-Architektur? Vermutlich das: https://opencores.org/projects/zpu /regards
Klaus S. schrieb: > Als der LCC uCore lernte, hatte ich eine > Bytedressierung parallel zur nativen Zelladressierung eingebaut. Das ist > aber aus zwei Gründen Mist: > 1. Es beschränkt die Datenwortbreite auf Vielfache von 8. > 2. Diese Mischform Celladressen UND Byteadressen - das will man wirklich > gar nicht. Ich kenne da weitverbreitete Architekturen (Ich glaube ARM und ganz sicher TI C2000 DSP), die das bis heute nicht eingebaut haben. Byte access kann man machen, wird aber vom Compiler als Lesen und danach Schieben Instruktionen umgesetzt. Muss der Programmierer halt wissen und seine Arrays, Records etc. auf Celladressen alignen. (Ist natürlich in C einfacher wenn das vielfache von 8 sind). Klaus S. schrieb: > Was bitte ist die ZPU-Architektur? Ein langjähriges Projekt hier aus dem Mikrocontroller.net Universum: https://www.mikrocontroller.net/articles/ZPU:_Softcore_Implementierung_auf_Spartan-3_FPGA
Klaus S. schrieb: > 3. Der "Pause" Mechanismus, ein janusköpfiger Bruder des Interrupts: > Interrupt: Ein Ereignis hat stattgefunden, das die Software NICHT > erwartet hat. > Pause: Ein Ereignis hat NICHT stattgefunden, das die Software erwartet > hat. Gefällt mir, das mal in einer Architektur umzusetzen. Mir kommt dabei gleich Exception Handling in den Sinn, das ja die allermeisten Embedded Programmierer eben genau nicht nutzen dürfen, weil es so viel zusätzlichen Bytecode produziert und das deterministische Timing kaputt macht auf klassischen CPU Architekturen.
Klaus S. schrieb: > Überhaupt Bytes: Wer die Bytes zum Hardwarestandard für Speicherbreite > erhoben hat, gehört noch nachträglich geteert und gefedert. Ja, mit den > Bytes konnte man ein paar Speicherzellen einsparen, als Speicher noch > teuer war. Funktional bringen die Bytes aber gar nichts, machen aber das > Memoryinterface zum Multiplexergrab. Das 'Multiplexergrab' ist Industriestandard in jedem modernen uC.. Die Frage waere dann, welcher 'groesste gemeinsame Teiler' dann als minimal addressierbare Speichereinheit in der Praxis geeignet waere...:-) Ja, und irgendwie muessen die Bytes vom UART/Interface in den Speicher, dann hat man halt die MUXer in der DMA-Peripherie, wenn man die CPU nicht mit Bitschiebereien belasten will.
Andreas H. schrieb: > Aber wenn ich die Lizenz richtig verstehe, dann darf man microCore nicht > in komerzielle Projekte einbinden? Jein. Entwickeln für ein kommerzielles Projekt kann man schon jetzt, fürs Produkte verkaufen wird es eine kommerzielle Lizenz geben. In der wird geregelt sein, dass Lizenzzahlungen fällig werden, wenn mehr als 100 Produkte produziert werden. An der Lizenz wird noch gearbeitet. Wer sich jetzt davon abgeschreckt fühlt, sollte mir eine Mail schreiben und dann klären wir das rechtsverbindlich.
Klaus S. schrieb: > 3. Der "Pause" Mechanismus Könntest du das etwas ausführlicher erläutern? Hat die CPU Interrupts?
Christoph Z. schrieb: > Mir kommt dabei > gleich Exception Handling in den Sinn, das ja die allermeisten Embedded > Programmierer eben genau nicht nutzen dürfen, weil es so viel > zusätzlichen Bytecode produziert und das deterministische Timing kaputt > macht auf klassischen CPU Architekturen. So ungefähr vor 15 Jahren habe ich den Pausemechanismus eingebaut und dann wußte ich natürlich erstmal nicht, was ich damit anfangen kann - außer zu warten, solange ein Device nicht bereit ist. Heute weiß ich, dass man dank Pause die gesamte Resourcenverwaltung an die Hardware delegieren kann. Inklusive MUTEX (MUTual EXclusion). Nehmen wir mal den ADC128S102, ein ADC mit SPI-Interface und vorgelagertem 8-Kanal MUX. Den kann man in einem Multitaskingsystem in uForth so ansprechen:
1 | <kanalnummer> ADC ! ADC @ Sample ! |
2 | |
3 | das wäre in C: |
4 | |
5 | ADC = <kanalnummer>; Sample = ADC; |
Fertig. Das ! (store) der Kanalnummer kann man erst machen, wenn kein anderer Prozess den ADC beschäftigt, und das @ (fetch) kann man erst machen, wenn der ADC fertig ist. Ansonsten ist Pause. Und die Pause Trap ruft den Scheduler auf, der nicht - wie noch beim Transputer - in einem ROM liegt, sonder frei programmierbar ist. Damit kommt eine fehlerträchtige Aufgabe der Software, nämlich die Resourcenverwaltung, gar nicht erst vor. Aber Deadlocks kann es leider immer noch geben.
Martin S. schrieb: > Ja, und irgendwie muessen die Bytes vom UART/Interface in den Speicher, > dann hat man halt die MUXer in der DMA-Peripherie, wenn man die CPU > nicht mit Bitschiebereien belasten will. Gar nicht nötig. Solange die data_word_width > 8 ist (was sie immer sein wird, weil man sonst nur 128 Programmadressen hätte), kann man in jeder Zelle natürlich nur jeweils ein Byte speichern. Und wenn es aus irgendwelchen Gründen sein muss, kann man mit den Bibliotheksfunktionen pack/unpack komprimieren. Wenn ein Hardwaremultiplier im FPGA ist, kostet ein Barrelshift 2 Zyklen. Und DMA braucht man eigentlich auch nicht, weil in einer Stackarchitektur im Interrupt sofort losgearbeitet werden kann - ist sowieso schon alles auf Stacks. Und der Multitasker hat keine Sequenzen, in denen Interrupts ausgeschaltet sind, so dass die Interrupt Trap nach spätestens 3 Zyklen angesprungen wird. Als Performancebeispiel: Mein letztes Projekt war die Frequency-Reference-Unit für den Merlin Satelliten. (Konditionierung von drei Halbleiter-Infrarotlasern auf 5 MHz genau). Das gesamte System ist im Prinzip eine SPS mit 5 Regelschleifen, die alle 50 msec abgearbeitet werden. Nur die Peripherieinterfaces und das Wavemeter sind in VHDL, der Rest ist Software mit 5 Tasks. Trotzdem hatte das Gesamtsystem nur einen Jitter < 1 msec.
Josef schrieb: > Könntest du das etwas ausführlicher erläutern? > Hat die CPU Interrupts? Ja, natürlich. Und zusätzlich Pause. In https://github.com/microCore-VHDL/microCore/tree/master/documents/uCore_overview.pdf Kapitel 6 ist das erläutert.
Klaus S. schrieb: > An der Lizenz wird noch gearbeitet. Dann lass es uns mal wissen wenn Du soweit bist. Bei uns wollen die BLs ja immer wissen wenn sie verklagen können wenn was schiefgeht ;) /regards
Andreas H. schrieb: >> An der Lizenz wird noch gearbeitet. > > Dann lass es uns mal wissen wenn Du soweit bist. Es ist nicht einfach. Deshalb werde ich meine Gedanken dazu darlegen und hoffe, dass eure Antworten mir mehr Klarheit bringen. Vorweg: Ich habe mich von dem Gedanken verabschiedet, das Produkte lizenzpflichtig sein sollen. microCore wird freie Firmware sein, so wie Linux oder GCC freie Software sind. 1. Jeder Ingenieur will alles Mögliche machen, aber eines nicht: Den Assembler NOCH eines weiteren Prozessors lernen müssen. Deshalb wird niemand, der nicht bereits durch seine Nutzung süchtig danach geworden ist (insbesondere beim Hardware Debuggen), microCore IP kaufen. Also kann ich es ebensogut verschenken. 2. Das kann aber zu einem Problem führen: Wenn jemand microCore erstmalig einsetzt, dann gibt es meist Beratungsbedarf. Das ist einerseits schön, weil es für mich Beratungsbusiness bedeutet. Aber wenn microCore SEHR erfolgreich ist, dann kann ich den Beratungsbedarf alleine nicht mehr leisten - und das hemmt die weitere Verbreitung. 3. Deshalb ist vor einigen Jahren in dem EU-Projekt ASSISTEC, das sich um IP-Vermarktung drehte, das Konzept entstanden, zunächst für ca. zwei Jahre nur eine "Exploratory License" anzubieten mit freier Nutzung für R&D, Forschungsinstitute und Universitäten. Und erst danach die "Public License", die die freie kommerzielle Nutzung erlaubt, wenn ein entsprechender know-how Pool entstanden ist. 4. In jedem Fall jedoch behalte ich mir das Recht vor, eine Prüfinstanz zu zertifizieren, die berechtigt ist, Implementationen von microCore die Konformität zum "ursprünglichen Modell" zu bescheinigen. Nur so kann sich ein Markt für microCore Softwarepakete entwickeln. Das führt dazu, dass die Weiterentwicklungen von microCore IMMER sourcecodekompatibel sein werden, was für mindestens die letzten 5 Jahre bereits zutrifft. 5. Aus den Reaktionen in diesem Thread ist deutlich geworden, dass bei der Exploratory License die Akzeptanz verhalten ist und es zumindest in der Industrie keine Design-ins geben wird. Soweit die Faktenlage. Einerseits hätte ich die Möglichkeit, microCore sofort unter die Public License zu stellen mit dem Problem der Beratungsüberforderung. Andererseits könnte ich zunächst die Phase der Exploratory License beibehalten, aber auf Anfrage Firmen, die damit in die Produktentwicklung einsteigen wollen, eine individuellen Lizenz zur freien Nutzung erteilen, wenn die Beratungssituation klar ist. Das hat jedoch den Nachteil, dass für jede individuelle Lizenz die Geschäftsleitung eingeschaltet werden muss. Soweit sind meine Überlegungen gediehen und ich bitte um Feedback.
Klaus S. schrieb: > Einerseits hätte ich die Möglichkeit, microCore sofort unter die Public > License zu stellen mit dem Problem der Beratungsüberforderung. Wenn ich mir den Traffic auf der ZPU-Mailingliste so anschaue, glaube ich nicht, das dir sofort nach Veröffentlichung die Bude eingerannt wird. Und wenn ich von mir ausgehe: da muß erstmal ein neues Projekt gestartet werden, in dessen Rahmen man sich den microCore evtl. mal mit anschaut und evaluiert. Da Hardwareprojekte eher Langläufer sind, kommt das nicht so häufig vor. Duke
Mit den Lizenzen wuerde ich mir ja erst die Arbeit machen, wenn jemand explizites und serioeses Interesse an deiner Nischenloesung als Werkzeug anmeldet. Oder deine OpenSource mit einer anderen Lizenz kompatibel sein muss. Nach meiner Erfahrung kupfern sich die grossen Buden pfiffige Konzepte einfach ab und scheren sich Null um Lizenzbedingungen. Mit Tools kann man nur noch mit viel Glueck Geld verdienen. Und NB: Der Markt ist ziemlich gesaettigt, die Softwerker unter den Ingenieuren lernen zwar schon noch eine neue ASM-Syntax fuer die 'inner loops', aber wollen auch gcc-Port, Eclipse und Debugger fuer umme, plus die kostenlose Support-Community a la Linux. ZPU ist ne gute Messlatte, und auch da broeckelt es, kaum einer will da noch die Tools fuer die Community gratis unterhalten. Bei RISC-V geht das Community-Moment gegen ideal, gegen die Stroemung kann man wirklich nur noch mit harten Alleinstellungsmerkmalen anschwimmen. Mit Forth-Prozessoren ist man da schon in einer ganz anderen Nische.
Klaus S. schrieb: > Soweit sind meine Überlegungen gediehen und ich bitte um Feedback. Hallo Klaus Schön das es so schnell weiter geht. > Vorweg: Ich habe > mich von dem Gedanken verabschiedet, das Produkte lizenzpflichtig sein > sollen. microCore wird freie Firmware sein, so wie Linux oder GCC freie > Software sind. Selbst hier liegt, für gewerbliche Nutzung, der Teufel im Detail. Programme die unter Linux laufen sind nicht notwendigerweise GPL lizensiert. Mit dem GCC compilierte Programme fallen z.B. NICHT automatisch unter die GPL (oder irgend eine andere vorgegebene Lizenz). Wäre z.B. das GCC Kompilat auch unter GPL, dann müsste man ja dem Kunden die kompletten Quellen zur Verfügung stellen. Oft steckt hier aber viel Firmen-knowhow drin was man nicht so "preiswert" verschenken kann. Noch schwieriger wäre hier die Verwendung zugekaufter Libraries für die man die Rechte zur Weitergabe typischerweise nicht hat. > 1. Jeder Ingenieur will alles Mögliche machen, aber eines nicht: Den > Assembler NOCH eines weiteren Prozessors lernen müssen. Deshalb wird > niemand, der nicht bereits durch seine Nutzung süchtig danach geworden > ist (insbesondere beim Hardware Debuggen), microCore IP kaufen. Da kann ich nicht zustimmen. Viele Entwickler haben kein Problem damit sich in Neues einzuarbeiten. Das ist doch eigentlich "Part of the job". Ich sehe da eher Ein ganz anderes Problem. Die Vorteile dieser Art der Entwicklung ist heute nicht mehr sehr verbreitet und braucht darum eine gewisse Neugier um damit anzufangen. Mein AIM-65 hat noch ein Forth-ROM - wieviele Jahre ist das her^^. Aber ein eForth kann man heutzutage genau so wenig unter Windows kompilieren wie Manfred Mahlows e4thcom. Und leider ist Linux in Konzernen immer noch nicht so verbreitet wie Windows. WENN man das am laufen hat, dann ist es eine so hocheffektive Entwicklungsumgebung das Vielen erst mal die Luft wegbleibt. Aber selbst dann muss man sich an diese Art des Entwicklens reinfinden. Man liest heute eher Gamma's "Design Patterns" oder Uncle Bobs "Clean Code". Wer kennt denn noch Moore's "Programming a problem oriented Language" oder Leo Brody's "Thinking Forth"? > 5. Aus den Reaktionen in diesem Thread ist deutlich geworden, dass bei > der Exploratory License die Akzeptanz verhalten ist und es zumindest in > der Industrie keine Design-ins geben wird. Das ist aber verständlich, oder? Zum einen: siehe oben. Zum Anderen: Was nützt eine Lizenz die einen dermassen einschränkt? Seit einiger Zeit kriegt man FPGAs mit ARM8 SOCs, bzw. cortex-M0 Softcore. Oder RISC-V socs (MicroSemi). Die kann ich problemlos auch gewerblich einsetzen. Und die Leute kennen sich damit, bzw. mit der Art der Entwicklung, aus. Nur um das Problem zu verdeutlichen: Ich kann ein Tool mit z.B. VS-Community schreiben. In der Firma darf ich das nicht benutzen, weil da die Lizenzbedingungen nicht passen. Ich müsste also erst mal eine Lizenz durchfechten - Odd job :/ Mache ich das gleich mit dem GCC habe ich da kein Problem. Bei Deinem aktuellen Ansatz geht nur ein bisschen basteln zu Hause weil die Kosten, if any, komplett intransparent sind (nicht böse gemaint. Nur eine Beobachtung). Es gibt einen Bedarf für solche Lösungen. Siehe z.B. Arduino. Den sehe ich sehr oft in irgendwelchen Laboraufbauten bei uns. ABER: da ist die Enstiegshürde selbst für Hobbyisten fast Null. Finde den Unterschied ;) Grüße Andreas P.S: Trotzem ein tolles Projekt. Mach weiter A.
Andreas H. schrieb: >> Vorweg: Ich habe >> mich von dem Gedanken verabschiedet, das Produkte lizenzpflichtig sein >> sollen. microCore wird freie Firmware sein, so wie Linux oder GCC freie >> Software sind. > > Selbst hier liegt, für gewerbliche Nutzung, der Teufel im Detail. > Programme die unter Linux laufen sind nicht notwendigerweise GPL > lizensiert. > Mit dem GCC compilierte Programme fallen z.B. NICHT automatisch unter > die GPL (oder irgend eine andere vorgegebene Lizenz). Oh Missverständnis! Ich hab's aber auch falsch ausgedrückt. Ich wollte sagen: microCore wird freie Firmware sein, im Prinzipe so, wie TCP/IP unter BSD freie Software ist. In GNU-speak wäre das wohl die LGPL. Jedenfalls dürfen meinetwegen Nutzer von microCore alles geheimhalten inklusive der Tatsache, dass sie es nutzen. Mir geht es darum, jegliches Verbreitungshindernis zu vermeiden. Aber ich will - wie ausgeführt - auch nicht von Beratungsanforderungen überfordert werden.
Wenn es ein microCore-PCB mit den typischen Arduinofeatures gäbe, also -FPGA bereits fertig programmiert (schlüsselfertig) -ADC, ca 10 bit, 10kS/s, 4 Kanäle -ca 32k RAM/ROM -ca 10 I/O auf 3.3V oder 5V -ca. 2x PWM, 2x SPI, 2x I2C -(special) 2x EXCEPTION/PAUSE-Eingänge, 2x Interrupt-Ein. -Spannungsversorgung und Programmierung über USB (FTDI) (in dem Fall natürlich on-line auf dem Forthsystem direkt) für 30-50€ ca dann würde ich das ohne Bedenken bei kleinen Projekten die schnell gehen sollen einsetzen Ich würde also statt Arduino den microCore bevorzugen. Der Schlüssel ist, es muss genauso einfach und schnell gehen, mit guter Dokumentation.. Terminalprogramm starten, einstecken und loslegen Ich denke da gerne an das alte Quickbasic zurück, das hatte all das und noch mehr, perfekt für kleine schnelle Projekte die auch noch Spaß machten Und da könnte ich mir durchaus vorstellen dass sich da ein neuer Forth-Enthusiasmus entwickeln könnte bei so manchem Das Beraten müsste man aber outsourcen irgendwie;) Also Community ist das Zauberwort eine faq könnte es ja geben, ein Wiki oder so etwas Also nur meine Idee dazu... Und bedenke, das ist genau die Schnittstelle zwischen Hobby- und Produktiveinsatz, welche zu großer Verbreitung des microCore führen könnte Für das board käme zB der ICE40 von lattice in Frage um den es sowieso schon eine gewisse Community gibt Natürlich bleibt der microCore damit weit hinter seinen Fähigkeiten zurück aber parallel dazu kann er ja selbstredend auf großen FPGAs auch zum Einsatz kommen...
Klakx schrieb: > sema_proc : PROCESS (clk, reset) > BEGIN > IF reset = '1' AND async_reset THEN > flags(f_sema) <= '0'; Deine Begründung mag stimmen, es bleibt aber dabei dass es nicht vernünftig simulierbar ist. Ich würde das erstmal entschlacken.
Proggi schrieb:, und Klakx schrieb im Beitrag #6569869: >>
1 | sema_proc : PROCESS (clk, reset) |
2 | >> BEGIN |
3 | >> IF reset = '1' AND async_reset THEN |
4 | >> flags(f_sema) <= '0'; |
> > Deine Begründung mag stimmen, es bleibt aber dabei dass es nicht > vernünftig simulierbar ist. > Ich würde das erstmal entschlacken. Mit welchem Simulator hast Du es denn versucht? ModelSim hat damit jedenfalls keine Schwierigkeiten. Die Wahlmöglichkeit (synchroner/asynchroner Reset) habe ich deshalb eingebaut, weil sich in der Raumfahrtcommunity ein fast religiöser Streit entwickelt hat, was zuverlässiger ist. Hier der vollständige Code fürs bessere Verständnis:
1 | sema_proc : PROCESS (clk, reset) |
2 | BEGIN
|
3 | IF reset = '1' AND async_reset THEN |
4 | flags(f_sema) <= '0'; |
5 | ELSIF rising_edge(clk) THEN |
6 | .... Code, wenn kein reset aktiv ist ... |
7 | IF reset = '1' AND NOT async_reset THEN |
8 | flags(f_sema) <= '0'; |
9 | END IF; |
10 | END IF; |
11 | END PROCESS sema_proc; |
Die Lösung in diesem Streit besteht übrigens darin, dass die Pintreiber mit asynchronem Reset in safe states gesetzt werden und die interne Logik ein synchrones Reset bekommt. Das war den Protagonisten aber bisher noch nicht aufgefallen. Es wird eben auch da mit Wasser gekocht ;)
blub schrieb: > Wenn es ein microCore-PCB mit den typischen Arduinofeatures gäbe, also Schöne Idee. Das kann gerne jemand machen, ich würde helfen, microCore entsprechend zu konfigurieren. Ich habe aber prinzipiell Bauchschmerzen, die verschiedenen Schnittstelle wie Peripheriechips mit diversesten Konfigurationsmöglichkeiten anzubieten. Das ist doch der Witz an VHDL, dass die Interfaces genau so gemacht werden, wie sie tatsächlich im Projekt gebraucht werden.
Klaus S. schrieb: > Das ist doch der Witz an VHDL, dass die Interfaces genau so gemacht > werden, wie sie tatsächlich im Projekt gebraucht werden. Da stimme ich Dir zu. Es kann ja, wer erstmal ,,angefixt" ist, tiefer einsteigen, sich dran machen den FPGA selbst zu programmieren, diese oder jene Schnittstelle hinzuzufügen. Das schöne ist daß es durchgängig vom Hobbyisten (kauft fertige Platine, programmiert im Terminal) über den Intermediären User (Abwandlung der Peripherie, Erweiterungen an der Hardware) bis hin zum professionellen Einsatz (großes FPGA Projekt, microCore mit erweitertem Befehlssatz) was gibt. Über das forth als Abstraktionsschicht ist der Code portabel auf verschiedensten Konfigurationen lauffähig was die Kultur des Programme-Austauschens beflügeln könnte und bei vielen Nutzern Anklang finden würde. microCore ist sozusagen das Bindeglied dazwischen und eine ,,Marke" (vergleiche ,,Arduino")
blub schrieb: > -FPGA bereits fertig programmiert (schlüsselfertig) > -ADC, ca 10 bit, 10kS/s, 4 Kanäle > -ca 32k RAM/ROM > -ca 10 I/O auf 3.3V oder 5V > -ca. 2x PWM, 2x SPI, 2x I2C > -(special) 2x EXCEPTION/PAUSE-Eingänge, 2x Interrupt-Ein. > -Spannungsversorgung und Programmierung über USB (FTDI) 100baseT Interface Heilandszack. Nun bin ich doch angefixt. Ich brauche nämlich ein Testbed für UDP, weil ich microCore IoT-fähig machen will. Aber ICE40 hat mir zu wenig internes RAM und das BGA-Zeugs ist schlecht fürs Prototyping. Gibt's nicht was ähnlich stromschlankes mit mehr RAM und PQFP-Gehäuse? Microsemi? - Da ist aber die P&R Suite ätzend langsam, aber die statische Timinganalyse ist das Beste, was ich je gesehen habe. Sollten wir vielleicht einen separaten Diskussionsthread für das Board machen?
Klaus S. schrieb: > PQFP-Gehäuse? Microsemi Ich hab mich mal ein bisschen dort umgesehen, es gibt den M2GL010-TQG144I. IGLOO2, 84 I/O, 933.888 kbit RAM, 12.084 LUTs im 144-LQFP-Gehäuse Klaus S. schrieb: > 100baseT ja!
Klaus S. schrieb: > Sollten wir vielleicht einen separaten Diskussionsthread für das Board > machen? Vielleicht
Betr. Board: Auf Spartan6-LX9@TQFP144 hab ich mal fuer div. IoF-Anforderungen das hier angeschmissen: https://hackaday.io/project/162259-netpp-node Ueber den 'goldenen' Bootloader kann man sich eigene Firmware per Ethernet oder roh per USB-JTAG draufspielen.
xml bäh. sorry. aber das Konzept ist faszinierend. Du kennst bson? dubdidu
:
Bearbeitet durch User
blub schrieb: > Ich hab mich mal ein bisschen dort umgesehen, > es gibt den M2GL010-TQG144I. > IGLOO2, 84 I/O, 933.888 kbit RAM, 12.084 LUTs im 144-LQFP-Gehäuse Ich habe mal Synthese und Place&Route gemacht und die Ergebnisse sind erfreulich: 16-bit Datenwortbreite: 16k Datenspeicher, 8k Programmspeicher 30% der LUTs, clock 45 MHz. 32-bit Datenwortbreite: 4k Datenspeicher, 16k Programmspeicher 40& der LUTs, clock 30 MHz. Der IGLOO2-FPGA ist mir aus zwei Gründen lieb: 1. Sehr geringer Stromverbrauch, (Ich habe jahrelang Geräte gebaut, die bis zu einem Jahr auf dem Meeresgrund lagen und aus Batterien versorgt wurden.) 2. Die Konfiguration ist direkt durch Flashzellen definiert und damit ist der Chip sofort nach dem Einschalten betriebsbereit.
Hier: Beitrag "arduino Platine mit microCore und 100baseT" habe ich einen separaten Diskussionsthread für das Board angefangen.
Alle Synopsislibraries rausgeworfen und Version 2300 in https://github.com/microCore-VHDL eingecheckt. Zusätzliche gibt es im Crosscompiler jetzt ein OOP Package, mit dem Operator Overlading auf Forth-Ebene realisiert werden kann. Dadurch ist es möglich, z.B. int16 und uint16 Variable zu definieren, die sich automatisch um allfällige "richtige" Vorzeichenerweiterung kümmern.
Version 2320 veröffentlicht auf https://github.com/microCore-VHDL Die meisten Änderungen wurden gemacht, damit microCore für den XC3S400 mit Xst synthetisiert werden kann. Deshalb ist der VHDL-Code nun wieder VHDL-93, was sicherlich auch weiteren Legacy-FPGAs zugute kommen wird.
Im letzten Jahr habe ich auf microCore UDP/IP realisiert und dabei bemerkt, dass ich keines der existierenden IP-Softwarepakete nutzen kann, weil microCore keine Bytes kennt. Ansonsten war die Realisierung ohne Bytes auch nicht komplexer als eine mit Bytes - aber eben völlig unüblich. Deshalb habe ich endlich Byteadressierung in microCore eingebaut. Das macht nur für 16/32/64 Bitsysteme Sinn. Datenwortbreiten, die nicht 2^n breit sind gibt es nach wie vor, dann aber ohne Byteadressierung. Dazu habe ich heute microCore Version 2400 eingecheckt: https://github.com/microCore-VHDL Bei der Gelegenheit habe ich mal die Divisions- und Multiplikationsinstruktionen überprüft, die bisher nur stochastisch verifiziert wurden. Ein vollständiger und immer noch interaktiver Test lässt sich in 1022 Instruktionen realisieren und deshalb reicht ein microCore mit 10 bit Wortbreite zur Auführung. Dann dauert ein vollständiger Sweep von 20 bit Dividend / 10 bit Divisor nebst Rückmultiplikation + Remainder nur noch 4 Stunden. In "seltenen aber regelmäßigen Situationen" war bei falschem Ergebnis das Overflow Bit im Status nicht gesetzt. Das ist nun korrigiert und microCore verfügt jetzt über vollständig getestete Division/Multiplikation. Welcher andere Prozessor kann das von sich behaupten? (Wäre natürlich bei 16 bit in 11 Tagen auch noch machbar.)
Klaus Schleisiek schrieb: > as reset in der Sensitivity List wurde in fpga.fs einsynchronisiert vom > externen reset_n. Das ist nicht nur fürs P&R wichtig, sondern auch gegen > Metastabilität gut, weil sonst ein Resetende kurz vor einer aktiven > Clockflanke das ganze System aus dem Gleis werfen kann. Da muss ich leider widersprechen. Zum einen hat sich das Thema Metastabilität in den letzten 20 Jahren der Entwicklung deines Cores weiterentwickelt (es ist seit gefühlt 10 Jahren keines mehr, wie auch von Teachern wie PLC2, Xilinx themselves und Drittanbietern bestätigt wird) und zum anderen wird es auch nicht wirklich entschärft: Das Einsynchronisieren von Resets und "Rübersynchronisieren" in andere Domains verschlechtert eher das timing budget, was zur Verfügung steht und verkompliziert das Timing. In der Nähe eines getroffenen timings wird die Wahrscheinlichkeit anderer Fehlereinflüsse drastisch erhöht. Zudem vergibt man sich durch diese asynchronen Geschichten die Möglichkeit, die reset Funktionalität optimieren zu lassen: Die FFs, die ein Signal einsynchronisieren, müssen einzelne FFs bleiben und erst danach darf man spreizen. Das verlängert den synchronen Resetpfad, weil nur die verteilten FFs auch mit anderen Schaltungsteilen zusammengefasst werden können. Im Ergebnis (Xilinx hat das an einem Design gezeigt) führt es dazu, dass ein synchroner Reset in vielen Fällen mit anderen Teilen des designs zusammen gefasst werden kann, weil der Wert, den ein FFs nach einem Reset annehmen muss, durch andere Logikbedingungen zu 50% statisch auch erreicht werden muss, weshalb der synchrone Reset kaum die Respurcen aufbläht. Der Asynchrone, den man noch bekommt, erfordert demgegenüber ein weiteres Netzwerk und kann die Resourcen stark fordern.
Klaus S. schrieb: > Deshalb wird > niemand, der nicht bereits durch seine Nutzung süchtig danach geworden > ist (insbesondere beim Hardware Debuggen), microCore IP kaufen. Das wird definitiv nicht passieren. Die meisten werden es nicht einmal nehmen wenn es kostenlos ist, weil es Bekannteres und gut Gnterstütztes von den Herstellern gibt, um software gesteuerte Debugger zu implementieren, nämlich NIOS und MICROBLAZE. Für diese gibt es Tausend Designs, die man nur anpassen muss. Wie "Ingenieure" haben keine Zeit, uns in etwas einzuarbeiten, was dann nur wir kennen, und nicht der, der das Projekt benutzen oder mal pflegen muss. Da diese beiden voll etabliert und bekannt sind, bleibt es dabei. Xilinx hat sogar den PICO sterben lassen müssen, weil alle nur Micro machten. Duke Scarring schrieb: > Wenn ich mir den Traffic auf der ZPU-Mailingliste so anschaue, q.e.d. Zum Debuggen gibt es heute auch Python und myHDL, womit man sehr schnell in Echtzeit laufende Testbenches erzeugen kann. Auch Logic Analyzer lassen sich damit konfigurieren und aufbauen. Das ist der Weg der Zukunft, weil C sowieo schon für komplizierte Coes benötigt wird, um sie zu steuern, Python bereits zur Erzeugung von Code benutzt wird und auch zur Steuerung und dem Management von Scripten und TCL verwendet wird. Außerdem kriegst du damit sofort den Code, den VUNIT frisst oder in System-C zu integrieren ist, um die Testbenches laufen zu lassen. Die TB muss ja zuerst da sein, weil die den Code entwickeln hilft und auch gebaucht wird, um die Funktion des Test Codes zu prüfen. Erst, wenn C, System-C und Python gezeigt haben, dass sie richtig tun, werden sie genutzt, um code zu generieren, Testbenches oder reale Strukturen daraus zu bauen. Deine Arbeit ist respektabel, aber es wird niemand benutzen können.
Hallo Ludger, ich habe das an anderer Stelle schon beschrieben bei einem Diskussionsstrang, in dem es primär ums Reset ging. Der "wahre Jakob", der sowohl mit asynchronen als auch mit synchronen Reseteingängen funktioniert, geht so: reset_n kommt von einem Pin. SIGNAL reset_a, reset_s, reset : STD_LOGIC; reset_a <= NOT reset_n; synch_reset: synchronize PORT MAP(clk, reset_a, reset_s); reset <= reset_a OR reset_s; Das synchronize ist ganz einfach 2 DFF's hintereinander. Durch das OR wird der Systemreset direkt vom asynchronen Eingang gesetzt, das reset_s stellt sicher, dass es erst nach der aktiven Clockflanke wieder losgelassen wird. Dann hat der Anwender volle Freiheit, das reset entweder auf synchrone oder asynchrone Pins/Logik zu geben und es funktioniert auch, wenn die Clock ausfällt, so dass Ausgangspins immer noch in einen sicheren Zustand gesetzt werden.
Klaus S. schrieb: > reset <= reset_a OR reset_s; Das ist aber genau so ein Konstrukt, der die FPGA-Synthesen ausbremst und auch keiner wirklich mehr braucht, weil der sichere Zustand einer Schaltung auch dadurch herstellbar ist, dass man den gesamten FPGA an seinen Ausgängen für den Sicherheitsfall definiert. Interne Schaltungen alle schnell abschalten, ist redundant und oft zu langsam. Dort wo das benötigt wird, ist das anders gelöst. Da das Niederhalten des FPGA als Baustein bei vielen SIL-Anwendungen auch noch nicht reicht, müssen die kritischen Leitungen entsprechend vorgespannt werden, damit sie beim Wegfall definiert stehen, womit sich die Möglichkeit ergibt, den FPGA mal komplett per Hi-Z aus dem design zunehmen. Diese Schaltung muss ohnehin oft drin sein, weil der FPGA zu Beginn des Ladens noch keine definierten Ausgänge hat, also noch "pennt". Gerade die heutigen großen FPGAs laden ewig, bis sie ihre Ausgänge bedienen können, weswegen man sich im Ggs zu den PLDs von vor 30 Jahren was hatte überlegen müssen. Hat man diese Schutzschaltung aber drin, oder kann die Schaltung einen "nicht vorhandenen" FPGA vertragen, braucht es gar keinen sicheren Zustand, den der FPGA schlagartig einnehmen muss. Wichtiger ist dagegen, dass er wieder kommt und das tut er nicht, wenn die PLL nicht läuft. Läuft die aber, dann synched auch alles und man kann voll synchron bauen. Diese Dualität des asynch + synch stammt aus einer Zeit, als man noch Angst-Leitungen gezogen hat, weil FPGAs reihenweise durchbrennen konnten, nachdem man Leitungen fälschlich zusammengeschaltet hat, die nicht laufenden PLLs die Problembären in der Schaltung waren und man 4 Angst-Flip-Flops gegen Meta eingebaut hat. Das Durchbrennen ist seit 20 Jahren erledigt, weil FPGA-Werkzeuge das prüfen und es sich schaltungstechnisch in den meisten Technologien gar nicht mehr bauen liesse. Die PLL ist eines der sichersten Schaltungsteile! In 20 Jahren hatte ich keinen einzigen Fall, in denen eine PLL stand. Probleme sind eher Ausgänge, die zuviele Reflektionen abbekommen oder generell zuviel Strom gezogen bekommen sowie RAMs, die heiß laufen oder infolge anderer Effekte temporär kaputte Bits liefern. Darum muss man sich kümmern. Das erfordert intelligente Schaltungen, die takten, denken und schauen, ob die Daten ok sind und sie mit anderen aus parallelen TMR-Modulen vergleichen, um dann selber die Ausgänge hochzuheben. Die Mimik Prozessor guckt von aussen und schaltet den FPGA ab, ist Steinzeit. Die Meta-Zustände sind ebenfalls längst Vergangenheit und nur noch in speziellen FPGA-Museen beobachtbar: Es handelt sich bei diesen "Museen" um von einem ganz bestimmten Personenkreis entwickelte, immer noch im Umlauf befindliche Schaltungen, in denen noch alte Spartane laufen, die mit ISE gebaut wurden, wo die Timing-Modelle bis zum Schluss nicht stimmten und man mit aller Gewalt bis an die Grenze des möglichen taktet und einen Haufen Kombi dranhängen hat, die den Takt flach ziehen. Takte laufen in heutigen FPGAs symmetrisch, sind hochverstärkt und damit steil, der Baum ist balanciert und auch die Schaltungen werden balanciert, um gleichförmig zu belasten. Wenn in dem Umfeld "Takt, PLL, Stabilität" etwas schief geht, haben constraints gefehlt, die Modelle des Herstellers stimmen nicht, der Oszillator ist Mist oder man synchronisiert Daten nicht korrekt ein, sodass es ganz ohne Meta zu Inkonsistenzen führt.
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.