Hallo,
nach den ersten Schritten in VHDL möchte ich den nächsten Schritt wagen.
Das wäre für mich eine Art "Softcore" selber schnitzen.
Nur bin ich leider Softwerker und tue mich noch etwas schwer, mit dem
"in HW denken".
Von der Idee würde ich gerne ein mehrstufiges Design machen, bei dem es
z.B. einen (oder zwei) Automaten für die Benutzerschnittstelle gibt, mit
mehreren verschiedenen Ein- und Ausgabemöglichkeiten. Diese sehe ich als
völlig zeitunkritisch an.
Dann soll es für jede logische Baugruppe auf dem Dev-Board ein
funktionales Modul geben. Diese sollen natürlich knackig sein, d.h. auf
Zeit optimiert.
Was mir noch fehlt, ist die Umsetzung der logischen Verbindung. Wenn der
Automat der Benutzereingabe seine Werte im Speicher ablegt, wie kann ich
den in einem der funktionllen Module auslesen, ohne deren
Geschwindigkeit total auszubremsen?
Oder macht ein Wrapper für jedes Funktionsmodul Sinn, dass den Speicher
überwacht und dem eigentlichen Modul die aktuellen Werte über Signale
(Leitungen) zuführt?
Wie kann ich in zwei verschiedenen Modulen auf den gleichen
Speicherbereich zugreifen (mal unabhängig ob internen oder externen
Speicher)?
Machen globale Variablen (falls es sowas gibt) Sinn?
Also angenommen ich hätte ein PWM-Modul. Über die Benutzerschnittstelle
würde ich gerne Aktiv/Inaktiv, Frequenz und Busy-Faktor steuern, was
nicht bedeutet, dass ich für die Werte User-IOs verwenden will. Die
Benutzerschnittstelle könnte über PS/2-Tastatur, Drehencoder, UArt oder
Ethernet angesteuert werden. Ausgabe auf LCD ...
Also müsste ich die Werte für Aktiv/Inaktiv, Frequenz und Busy-Faktor
"irgendwo" ablegen, um sie ändern und verwenden zu können.
Hoffe ich konnte verdeutlichen, wo ich noch eine Denkblockade habe.
In der Boardbeschreibung steht am Ende eine UCF-Datei für die
Pinbelegung.
Wie kann ich die in VHDL verwenden, bzw. wie verdrahtet man am Besten
die verwendeten Bausteine (untereinander und mit den FPGA-Pins) im
Toplevel-Modul?
Verdrahten tust du im UCF nur die "äußeren" Pins des FPGA Designs.
Den rest machst du in VHDL.
Für Benutzereingaben würd ich dir den PicoBlaze empfehlen das ist nen
kleiner simpler uC im FPGA der für sowas gemacht wurde.
Weitergeben an andere Module kannst du dann deine Daten indem jedes
Modul ein register (signal) bekommt an das du die Daten per Write Signal
übergibst.
Das "stört" auch nicht dein Modul weil du den Zugriff ja einfach
parrallel erledigen kannst.
Hallo Läubi,
danke für Deine Antwort!
Leider kann ich kein Steno, bzw. lebe in einem höheren verbose-Level ;)
Deshalb muss ich nachfragen ...
Picoblaze verwenden heißt, Verarbeitung der Benutzereingaben in
Assembler programmieren?
Bin leider ein Hochsprachen-Junkie, also ein richtiger Softie.
Habe zwar Beispiele vom Picoblaze gefunden, aber noch nicht wirklich
verstanden.
Die Init-Strings in den vdl-Dateien, sind die der Maschinencode für den
Picoblaze?
Das mit der Weitergabe der Signale habe ich auch noch nicht verstanden.
Falls ich das richtig verstanden habe, "liegen" die Daten ja in
irgendwelchen FFs und die Strippen sind "nur" virtuell.
Wenn der Picoblaze die FFs verwaltet, wozu braucht das funktionale Modul
ein write-Signal? Wenn das Modul ein Register (Signal mit n-Bits Breite)
lesend verwendet, bekommt es dann nicht bei jedem Zugriff den aktuellen
Inhalt?
Wird da irgendwo noch zwischen gepuffert - oder habe ich ne größere
Lücke in meinem Verständnis?
Wie ist das, wenn mehrere Module das gleiche Register verwenden?
Muss der Schreibzugang irgendwie verriegelt werden, oder müssen
Bustechniken, bzw. Treiberproblematiken beachtet werden?
> Das "stört" auch nicht dein Modul weil du den Zugriff ja einfach> parrallel erledigen kannst.
Hm, ja - das habe ich schon verstanden. Nur das Zusammenspiel der Module
habe ich noch nicht gebacken bekommen.
> nach den ersten Schritten in VHDL
Wie weit bist du da gegangen?
> möchte ich den nächsten Schritt wagen.> Das wäre für mich eine Art "Softcore" selber schnitzen.
Dazu solltest du Datenblätter von uCs lesen und verstehen.
Und sieh dir den Picoblaze genau an, der ist recht überschaubar...
Anfänger schrieb:
> Picoblaze verwenden heißt, Verarbeitung der Benutzereingaben in> Assembler programmieren?
Ja, das beste ist du registrierst dich auf der Xilinx website und lädts
den dir mal runter, da ist ein Handbuch dabei welches erklärt wie es
geht.
> Die Init-Strings in den vdl-Dateien, sind die der Maschinencode
Ja die erzeugt aber der Assembler also keine Angst.
> Falls ich das richtig verstanden habe, "liegen" die Daten ja in> irgendwelchen FFs und die Strippen sind "nur" virtuell.
Nö die leigen schon in realen FF und auch die Verbindungen sind real ;)
> Wenn der Picoblaze die FFs verwaltet, wozu braucht das funktionale Modul> ein write-Signal?
Die FFs werden nicht "verwaltet", aber am Eingang der FF liegen halt ggf
Signale an die du (noch) nicht übernehmen willst, das Write-Signal sagt
jezt aber: Okay Daten übernehmen.
Lesen kannst du natürlich jederzeit.
> Wird da irgendwo noch zwischen gepuffert - oder habe ich ne größere> Lücke in meinem Verständnis?
Ein FF ist in diesem Zusammenhang fast immer ein Taktgesteuertes,
puffert also den alten Zusatand bis es den Befehl für was neues kriegt.
> Wie ist das, wenn mehrere Module das gleiche Register verwenden?> Muss der Schreibzugang irgendwie verriegelt werden, oder müssen> Bustechniken, bzw. Treiberproblematiken beachtet werden?
Klar, wie überall auf der Welt ist es in HW nicht anders als in SW wenn
mehrere Schreibn wollen auf das gleiche Ziel muß man sich was ausdenken.
> Hm, ja - das habe ich schon verstanden. Nur das Zusammenspiel der Module> habe ich noch nicht gebacken bekommen.
Da kann ich mich nur Lothar anschließen:
Lothar Miller schrieb:
>> nach den ersten Schritten in VHDL> Wie weit bist du da gegangen?
Vieleicht solltest du vorher noch ein paar kleine Schritte gehen ;)
>> nach den ersten Schritten in VHDL> Wie weit bist du da gegangen?Lach - Du hast mich doch an der Hand geführt :)
War zwar nur ne "Trivialaufgabe", aber den Lerneffekt durch Steigern der
zu kontrollierenden Leitungen halte ich nicht für sonderlich groß.
Deshalb wollte ich von einem Modul auf mehrere Module gehen - ja und wie
ich VHDL verstanden habe, kommt nach 1 gleich 3, denn 2 Module müssen
über ein neues Toplevel-modul verbunden werden.
Aber um die Frage direkt zu beantworten:
Einen Schritt, bzw. soweit, dass ich mir einbilde, das verstanden zu
haben, was Du mir beibringen wolltest.
>> Das wäre für mich eine Art "Softcore" selber schnitzen.> Dazu solltest du Datenblätter von uCs lesen und verstehen.> Und sieh dir den Picoblaze genau an, der ist recht überschaubar...
Hm, ich habe schon Software für AVR geschrieben (wenn auch nur in C), da
sehe ich nicht als Problem. Ich denke, dass ich mit der Software für den
Pico schon zurecht komme.
Wie ich allerdings die beiden Welten unter einen Hut bekomme - dafür
fehlt mir noch ein Plan.
>> Wenn der Picoblaze die FFs verwaltet, wozu braucht das funktionale Modul>> ein write-Signal?> Die FFs werden nicht "verwaltet", aber am Eingang der FF liegen halt ggf> Signale an die du (noch) nicht übernehmen willst, das Write-Signal sagt> jezt aber: Okay Daten übernehmen.
Vielleicht habe ich mich ja begrifflich verirrt.
- Wenn ich im Picoblaze ein Datenwort (z.B. 2 Byte) speichere, in wessen
Hoheit liegen die FFs? - denn der Speicher, der vom Picoblaze
beschrieben wird, besteht doch letztlich auch aus FFs?!?
- Im Picoblaze liegen die Daten an irgendeiner Speicheradresse - wie
kann ich den Speicherbereich von außerhalb des Picos erreichen? - oder
muss der Datenaustausch über die IO-Ports des Picoblaze erfolgen?
- Falls letzteres der Fall sein sollte, wie kann ich 2 bis n Module auf
einen "gemeinsamen" Speicherbereich zugreifen lassen?
>> Hm, ja - das habe ich schon verstanden. Nur das Zusammenspiel der Module>> habe ich noch nicht gebacken bekommen.> Da kann ich mich nur Lothar anschließen:> Lothar Miller schrieb:>>> nach den ersten Schritten in VHDL>> Wie weit bist du da gegangen?> Vieleicht solltest du vorher noch ein paar kleine Schritte gehen ;)
Hättest Du mir vielleicht nen Tip?
Den Picoblaze hätte ich mir nicht unbedingt als 2. Schritt ausgesucht.
Ich hätte eher ein Modul für Taster und Drehencoder geschrieben.
Letzteres traue ich mir schon alleine zu.
Das PWM-Modul sollte auch machbar sein - bleibt also noch die
Kombination.
Ja und weil ich von der SW die Wiederverwendbarkeit, bzw. Kapselung als
wichtig kenne, dachte ich mir, ich versuche den Denkansatz zu
realisieren, dass ich die "Variablen" nicht nur per Taster und
Drehencoder, sondern z.B. auch per Befehlssequenz über UArt oder
Ethernet ändern kann (nicht dass ich letzteres gleich umsetzen will,
aber die (Benutzer-)Schnittstelle soll austauschbar sein).
Wenn mein Denkansatz falsch ist, bitte ich um entsprechende
Zurechtweisung.
> Lach - Du hast mich doch an der Hand geführt :)
Oh, peinlich...
Zur Ehrenrettung: es gibt auch noch andere Anfänger :-/
Ehrlich gesagt wäre mir ein weniger "üblicher" Nick wahrlich besser im
Gedächtnis geblieben...
> Den Picoblaze hätte ich mir nicht unbedingt als 2. Schritt ausgesucht.
Weiser Entschluss...
> Ich hätte eher ein Modul für Taster und Drehencoder geschrieben.> Letzteres traue ich mir schon alleine zu.
Dann mach doch erst mal ein PWM-Modul. Das ist nun wirklich nicht
schwer.
Eingang: clk, Umschaltwert / Ausgang: PWM
Und dann mach ein Modul für den Encoder. Das sollte auch gehen...
Eingang: clk, A, B / Ausgang: Position
Und dann sieh zu, dass der Encoder seinen Wert an die PWM gibt.
Das ist am leichtesten ;-)
Und zum Schluss hängst du den Encoderzähler und die PWM an den Picoblaze
und schreibst eine SW für den uC. Wenn du das hast, hast du das Prinzip
verstanden.
Hallo Lothar,
> ... wäre mir ein weniger "üblicher" Nick wahrlich besser ...
kommt vielleicht demnächst :)
> Dann mach doch erst mal ein PWM-Modul. Das ist nun wirklich nicht> schwer.
Sonst hätte ich ja nicht geschrieben, dass ich es mir zutrauen würde.
Allerdings geht es mir im Moment nicht um's "doing", sondern um's
Verständnis. Die Punkte, von denen ich bereits weiß, wie ich sie mir
erarbeiten kann, brauche ich ja nicht hier diskutieren.
Mir geht es um die Punkte, zu denen mir noch der Zugang / das
Verständnis fehlt.
> Und dann sieh zu, dass der Encoder seinen Wert an die PWM gibt.> Das ist am leichtesten ;-)
Naja, wenn ich feste "Leitungen" ziehe, gebe ich Dir recht.
Aber nicht, wenn ich neben dem Encoder den Wert auch per Tastatur
eingeben können will.
Mir geht es um den Ansatz, die funktionalen Module der
Benutzerschnittstelle (zur Laufzeit!) austauschbar zu machen, d.h.
zwischen Encoder und PWM gibt es den Speicher, der von einer Seite (z.B.
Encoder) geschrieben und von der anderen Seite (z.B. PWM) gelesen wird.
Muss der Speicher unbedingt vom Picoblaze verwaltet werden?
Anfänger schrieb:
> Muss der Speicher unbedingt vom Picoblaze verwaltet werden?
Nein, aber du wirst sehen das besonders für Benutzereingaben der Code
für eine "Hardcoded"- Statemachine schnell groß und unübersichtlich
wird.
> zwischen Encoder und PWM gibt es den Speicher, der von einer Seite (z.B.> Encoder) geschrieben und von der anderen Seite (z.B. PWM) gelesen wird.
Wo ist den das Problem? Es ist schwer dir zu helfen wenn man nicht weiß
was das Problem ist ;)
> Aber nicht, wenn ich neben dem Encoder den Wert auch per Tastatur> eingeben können will.
Dann nuzt man z.B. einen Multiplexer.
Nebenbei hat das alles im Momment noch nichts mit nem Top-Down Entwurf
zu tun ;)
Hier mal ein Beispiel mit einem PicoBlaze.
Das habe ich mal für mein Spartan 3A Baord gebastelt.
1
entitytop_moduleis
2
Port(led:outSTD_LOGIC_VECTOR(7downto0);
3
sw:inSTD_LOGIC_VECTOR(3downto0);
4
ERROR_LED:outstd_logic;
5
clk:inSTD_LOGIC);
6
endtop_module;
Das "TopModul" stellt hier die Physische Verbindung nach außen dar,
einmal die 8 Leds und einmal die 4 Schiebeknöpfe + Takt + eine LED.
Verdrahtet wird das ganze dann mit den "Pins" per UCF File. (Laß ich
hier mal außen vor es sei den du willst das auch nochmal sehen)
1
COMPONENTembedded_kcpsm3
2
PORT(
3
in_port:INstd_logic_vector(7downto0);
4
interrupt:INstd_logic;
5
reset:INstd_logic;
6
clk:INstd_logic;
7
port_id:OUTstd_logic_vector(7downto0);
8
write_strobe:OUTstd_logic;
9
read_strobe:OUTstd_logic;
10
out_port:OUTstd_logic_vector(7downto0);
11
interrupt_ack:OUTstd_logic
12
);
13
ENDCOMPONENT;
Hier wird die Komponente (in diesem Fall der PicoBlaze) bekannt gemacht.
Das ist sowas wie nen Interface bei Java, man muß nicht zwingend wissen
was sich dahinter verbirgt. Das könnte z.B. jezt auch dein PWM Modul
sein, oder eine UART oder oder ...
1
signalinput_port:std_logic_vector(7downto0);
2
signaloutput_port:std_logic_vector(7downto0);
3
signalid_port:std_logic_vector(7downto0);
4
signalwr:std_logic;
5
signalint:std_logic;
6
signalledstate:std_logic:='0';
7
signaloneSecond:integerrange0to25000000:=0;
Dann noch ein paar Signale um alles zu verdrahten.
1
uC:embedded_kcpsm3PORTMAP(
2
port_id=>id_port,
3
write_strobe=>wr,
4
read_strobe=>open,
5
out_port=>output_port,
6
in_port=>input_port,
7
interrupt=>int,
8
interrupt_ack=>open,
9
reset=>'0',
10
clk=>CLK
11
);
Dann wird der eine Instanz aus der obigen Komponente gebildet wo ich
sage was wo hin kommt.
Der Einfacheithalber hab ich jezt die restliche Logik mit ins TopModul
gepackt, eigentlich sollte man das möglichst in ein eigenes Modul packen
1
leddriver:process
2
begin
3
waituntilrising_edge(clk);
4
ifwr='1'then
5
caseid_portis
6
whenx"00"=>
7
led<=output_port;
8
whenx"01"=>
9
pwm_compare<=output_port;
10
whenothers=>null;
11
endcase;
12
endif;
13
endprocess;
Ich warte also auf die Taktflanke, und wenn das Schreibsignal vom
PicoBlaze kommt übernehme ich die Daten in mein internes Register, der
id_port gibt an was das Ziel sein soll (x00 = LEDs, x01 = ein PWM
Compare Register.
Hier brech ich mal ab der Code ist nochmals im Anhang. Du siehst nun
aber denke ich das man zum schreiben (meistens) ein Schreibsignal
benötigt, Gewissermaßen als 'Return Taste' damit die Werte nur
übernommen werden wenn sie gültig sind. Manchmal braucht man auch ein
Lese Signal (z.B. FIFO/LIFO...).
Wenn die Module größer werden sollte man die Natürlich in eine eigene
Componente verpacken.
Wie Läubi schon vermerkt hat, ist ein Multiplexer wohl die einfachste
Art mehrere Eingangsmodule auf einen zentralen Speicher zu leiten. Dein
DevBoard hat mit Sicherheit ein paar Schalter drauf. Je nach
Schalterstellung könntest Du nun den MUX steuern und somit entweder den
Drehkodierer oder die Tastatur als Eingabemöglichkeit nutzen.
1
---------- ---------- ----------
2
| Tast. | | Drehk. | |Schalter|
3
---------- ---------- ----------
4
| | |
5
| | |
6
------------------------------------------
7
\ D0 D1 Adresse /
8
----------------------------------------
9
|
10
|
11
------------
12
| Speicher |
13
------------
14
|
15
|
16
------------
17
| PWM |
18
------------
So in etwa ... Ein Mux ist in VHDL auch fix gemacht. Damit hast Du vor
allem auch gleich das Problem des gleichzeitigen Schreibzugriffs auf den
globalen Speicher gelöst.
1
Dout<=D0whenAddresse='0'elseD1;
Die Anzahl der Eingabegeräte kann man natürlich auch noch beliebig
erhöhen mit nur kleinen Änderungen am Mux.
> Wo ist den das Problem? Es ist schwer dir zu helfen wenn man nicht weiß> was das Problem ist ;)
Yepp! - Vielleicht ist ja mein Brett vorm Kopp einfach zu dick.
Keine Ahnung.
Für mich sind da immer noch 2 Welten, die physisch zwar in einem Chip
liegen, die aber logisch keine Verbindung haben. Oder anders
ausgedrückt, 2 Namensräume, die in unterschiedlichen Zungen reden.
So ähnlich wie Ausländer in Deutschland: solange die Ausländer kein
Deutsch können, bzw. die Deutschen kein Ausländisch, ist keine
Verständigung möglich - man braucht also einen Dolmetscher :)
Sorry, aber der Code, bzw. der Tip mit Multiplexern hat mir nicht weiter
geholfen. Das waren keine neuen Informationen.
Wer weiß, vielleicht steh ich mir ja auch selbst im Wege?
> Nebenbei hat das alles im Momment noch nichts mit nem Top-Down Entwurf> zu tun ;)
Top-Down heißt für mich, alle Anforderungen in überschaubare Häppchen zu
zerkleinern. Wenn ich die Häppchen dann aber nicht zum Zusammenspiel
überreden kann, dann nützt mir die ganze Aufteilung nix.
Also für mich ist das Wissen, wie man die 2 Welten kombiniert
Voraussetzung zum Modularisieren (oder verstehe ich unter Top-Down jetzt
auch was anderes als Ihr?).
> Top-Down heißt für mich, alle Anforderungen in überschaubare Häppchen zu> zerkleinern.
Dann verstehst du Top-Down falsch...
Was du machst ist: "Teile und herrsche"
http://de.wikipedia.org/wiki/Divide_et_impera
Wobei das mit dem "Herrschen" offenbar noch nicht so klappt...
>... alle Anforderungen in überschaubare Häppchen zu zerkleinern.
Das was du hier vorhast, ist sogar eher Bottom-Up: du bastelst viele
Module und willst die jetzt aneinander flanschen...
http://de.wikipedia.org/wiki/Top-down_und_Bottom-up
Top-Down wäre, wenn du sagst: Ich brauche eine Steuerung für ein
Irgendwas. Und dann sagst du dir: Welche Unterkomponenten hat so eine
Irgendwassteuerung und wie stehen die zueinander in Verbindung? Und dann
entwirfst du zuerst die Kommunikation zwischen den Modulen, und füllst
erst danach die einzelnen Module mit Funktionalität.
Hallo,
ich denke, ich habe mein Verständnisproblem gefunden.
Ich habe wohl die Bedeutung von "scratchpad-Ram" mistverstanden -
dachte, das wäre der Platz, an dem der Pico seine Variablen ablegen
würde - und ich hatte keinen Plan, wie ich den Speicher von außen
erreichen kann.
Schätze, wenn der Pico Variablen außerhalb seines Hoheitsgebietes
beschreiben kann, dann ist alles klar wie Kloßbrühe ;)
Sorry für die Verwirrung.
Anfänger schrieb:
> Ich habe wohl die Bedeutung von "scratchpad-Ram" mistverstanden -> dachte, das wäre der Platz, an dem der Pico seine Variablen ablegen> würde - und ich hatte keinen Plan, wie ich den Speicher von außen> erreichen kann.
Das sit sowas wie der SRAM beim AVR/µC...
> Schätze, wenn der Pico Variablen außerhalb seines Hoheitsgebietes> beschreiben kann, dann ist alles klar wie Kloßbrühe ;)
Der Picoblaze hat einen Input und einen Output Port, wie ein µC nur das
diese ggf. halt auf "interne" Komponenten geleitet werden können
anstelle das auf ner Platine hart zu verdrahten.
> Das sit sowas wie der SRAM beim AVR/µC...Genau die Vorstellung hat ja meine Denkblockade ausgelöst !
Wenn die Konfigurationsdaten im SRAM des Pico liegen, kann ich die von
den Logik-Modulen ja nicht erreichen, bzw. auslesen, bzw. das Auslesen
kostet (zu viel) Zeit.
Wenn ich den Pico jedoch dazu bringe, seine Konfigurationsdaten extern
abzulegen, kann ich die von den Logik-Modulen erreichen und (schneller)
auslesen.
Insofern wäre es vielleicht besser, das scratchpad-Ram mit dem Stack,
bzw. Stackvariablen zu vergleichen. Schließlich weiß jeder, dass
Variablen auf dem Stack nach einem return ungültig sind, bzw. der Stack
nur für Ablage von temporären Daten geeignet ist.
Ich weiß, der Vergleich hinkt ein wenig, da die Daten im Scratchpad auch
einen Reset überstehen, aber für so Fremdeinsteiger, wie mich, ist der
Vergleich sicher hilfreicher für das Entwurfsdenken ;)
Noch hilfreicher wäre es, den Picoblaze nicht mit einem µC zu
vergleichen, sondern mit dem Verarbeitungsschritt eines EVA-Diagrams
(ja, ganz alte Schule). Will damit sagen, dass der Pico keine Daten
hält, sondern die von A (inport) nach B (outport) schiebt, wobei er bei
der Schiebeaktion die Daten noch manipulieren kann.
Wenn ich es inzwischen richtig verstanden habe, hat der Picoblaze nur
einen Eingang und einen Ausgang. Will er mehrere Quellen, bzw. Zielorte
erreichen, muss er sich externer Multiplexer bedienen, die er über einen
Adressport steuern kann. Für mich schon anders, als das, was ich bisher
so an µCs kannte.
Anfänger schrieb:
>> Das ist sowas wie der SRAM beim AVR/µC...>> Genau die Vorstellung hat ja meine Denkblockade ausgelöst !> Wenn die Konfigurationsdaten im SRAM des Pico liegen, kann ich die von> den Logik-Modulen ja nicht erreichen, bzw. auslesen, bzw. das Auslesen> kostet (zu viel) Zeit.
Naja stells dir halt vor wie eine "Platine" ... alles IM Controller ist
für die Ausenwelt nicht erreichbar (aber das ist ja auch nicht nötigt).
Alles was nach außen geht (z.B. der aus den Tastatureingaben berechnete
Wert) gehen über die Ports nach draußen. Genauso wie wenn du ein LCD
betreibst was einen eigenen Controller hat, da greift das LCD auch nicht
auf die Register und Variablen des µC zu, sondern der uC sendet über
seine Output Ports bestimmte Sequenzen um das LCD zu beeinflußen.
Genauso ist das auch hier!
Über bestimmte Protokolle sendet man hier an einen anderen "Chip" die
Befehle nur das die Leitungen nicht auf nem PCB sondern im FPGA liegen.
> Wenn ich es inzwischen richtig verstanden habe, hat der Picoblaze nur> einen Eingang und einen Ausgang. Will er mehrere Quellen, bzw. Zielorte> erreichen, muss er sich externer Multiplexer bedienen, die er über einen> Adressport steuern kann.
Genau, siehe mein Beispiel (der id_port regelt das).
> Für mich schon anders, als das, was ich bisher> so an µCs kannte.
Du gennst bestimmt auch keinen uC der (bis zu) 256 8-Bit Ports hat ;)
Ist erstmal gewöhnungsbedürftig das geb ich zu aber gibt einem auch
große Freiheiten.
> vergleichen, sondern mit dem Verarbeitungsschritt eines EVA-Diagrams
Der PicoBalze wird von seinem "Erfinder" als KPSM (Konstant Programable
State Machine) bezeichnet, von daher würde das schon passen ;)