Forum: FPGA, VHDL & Co. microCore, ein Echtzeitprozessor in VHDL für FPGAs


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Klaus S. (kschleisiek)


Bewertung
5 lesenswert
nicht lesenswert
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.

von Klakx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Klaus Schleisiek (Gast)


Bewertung
4 lesenswert
nicht lesenswert
"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.

von Martin S. (strubi)


Bewertung
1 lesenswert
nicht lesenswert
>
> 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...)

von Mathearsch (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Was ist ein Echtzeitprozessor?

von Klaus Schleisiek (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Klaus S. (kschleisiek)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Martin S. (strubi)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Klaus S. (kschleisiek)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas H. (ahz)


Bewertung
0 lesenswert
nicht lesenswert
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

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
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

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Klaus S. (kschleisiek)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Josef (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klaus S. schrieb:
> 3. Der "Pause" Mechanismus

Könntest du das etwas ausführlicher erläutern?
Hat die CPU Interrupts?

von Klaus S. (kschleisiek)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Klaus S. (kschleisiek)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Klaus S. (kschleisiek)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas H. (ahz)


Bewertung
0 lesenswert
nicht lesenswert
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

von Klaus S. (kschleisiek)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Duke Scarring (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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

von Martin S. (strubi)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Andreas H. (ahz)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Klaus S. (kschleisiek)


Bewertung
0 lesenswert
nicht lesenswert
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.

von blub (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Proggi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Klaus S. (kschleisiek)


Bewertung
1 lesenswert
nicht lesenswert
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 
;)

von Klaus S. (kschleisiek)


Bewertung
0 lesenswert
nicht lesenswert
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.

von blub (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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")

von Klaus S. (kschleisiek)


Bewertung
0 lesenswert
nicht lesenswert
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?

von blub (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

von blub (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klaus S. schrieb:
> Sollten wir vielleicht einen separaten Diskussionsthread für das Board
> machen?

Vielleicht

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jonas B. (jibi)


Bewertung
0 lesenswert
nicht lesenswert
xml bäh. sorry. aber das Konzept ist faszinierend. Du kennst bson? 
dubdidu

: Bearbeitet durch User
von Klaus S. (kschleisiek)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Klaus S. (kschleisiek)


Bewertung
0 lesenswert
nicht lesenswert
Hier: Beitrag "arduino Platine mit microCore und 100baseT" habe ich einen 
separaten Diskussionsthread für das Board angefangen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.