Top-down-Entwurf: umdenken lernen (für Softwerker)?

[Anfänger (Gast)]

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?

[Läubi .. (laeubi)]

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.

[Anfänger (Gast)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> 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...

[Läubi .. (laeubi)]

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 ;)

[Anfänger (Gast)]

>> 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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> 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.

[Anfänger (Gast)]

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?

[Läubi .. (laeubi)]

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 ;)

[Läubi .. (laeubi)]

Hier mal ein Beispiel mit einem PicoBlaze.
Das habe ich mal für mein Spartan 3A Baord gebastelt.

entity top_module is
Port ( led : out  STD_LOGIC_VECTOR (7 downto 0);
       sw  : in   STD_LOGIC_VECTOR (3 downto 0);
 ERROR_LED : out  std_logic;
       clk : in   STD_LOGIC);
end top_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)

COMPONENT embedded_kcpsm3
    PORT(
        in_port       : IN std_logic_vector(7 downto 0);
        interrupt     : IN std_logic;
        reset         : IN std_logic;
        clk           : IN std_logic;          
        port_id       : OUT std_logic_vector(7 downto 0);
        write_strobe  : OUT std_logic;
        read_strobe   : OUT std_logic;
        out_port      : OUT std_logic_vector(7 downto 0);
        interrupt_ack : OUT std_logic
        );
    END COMPONENT;

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 ...

signal input_port  : std_logic_vector(7 downto 0);
signal output_port : std_logic_vector(7 downto 0);
signal id_port     : std_logic_vector(7 downto 0);
signal wr          : std_logic;
signal int         : std_logic;
signal ledstate    : std_logic := '0';
signal oneSecond   : integer range 0 to 25000000 := 0;

Dann noch ein paar Signale um alles zu verdrahten.

uC: embedded_kcpsm3 PORT MAP(
    port_id      => id_port,
    write_strobe => wr,
    read_strobe  => open,
    out_port     => output_port,
    in_port      => input_port,
    interrupt    => int,
    interrupt_ack => open,
    reset       => '0',
    clk         => CLK
);

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

leddriver: process
    begin
        wait until rising_edge(clk);
        if wr = '1' then
            case id_port is
                when x"00" =>
                    led <= output_port;
                when x"01" =>
                    pwm_compare <= output_port;
                when others => null;
            end case;
        end if;
    end process;

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.

[mac4ever (Gast)]

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.

    ----------     ----------     ----------
    | Tast.  |     | Drehk. |     |Schalter|
    ----------     ----------     ----------
        |              |              |
        |              |              |
    ------------------------------------------
    \  D0              D1            Adresse /
     ----------------------------------------
                       |
                       |
                  ------------
                  | Speicher |
                  ------------
                       |
                       |
                  ------------
                  |   PWM    |
                  ------------

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.

Dout <= D0 when Addresse = '0' else D1;

Die Anzahl der Eingabegeräte kann man natürlich auch noch beliebig 
erhöhen mit nur kleinen Änderungen am Mux.

[Anfänger (Gast)]

> 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?).

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> 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.

[Anfänger (Gast)]

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.

[Läubi .. (laeubi)]

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.

[Anfänger (Gast)]

> 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.

[Läubi .. (laeubi)]

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 ;)