Der Process soll sich selber ausschalten

[GS (chromosoma)]

Manchmal fällt es wirklich schwer  einen passenden Betreff zu finden.:)

Es geht um folgendes:

Gegeben ist FPGA das  mit VHDL "programmiert" wird.

Es gibt insgesamt 3 Processe.

Ein Reciever, Transmitter und Main.

WIe der Name sagt,  Reciever empfäng die 12 Bit langen Befehl.
Sobald die Übertragung  fertig ist, setzt Reciever INSTRFLG auf 1. Das 
sagt den Main-Process, dass er jetzt diese 12 Bit in einen Befehl 
decodieren soll.
Falls Bit 11 =1, werden diese 12 Bit an  den Process "transmitter" 
übergeben.(SET_REF='1')
 Transmitter versendet insgesamt 16 bit seriell, und sobalt er fertig 
ist soll er die Kommunikation unterbrechen.
Die Idee ist, dass Transmitter den INSTRFLG wierder auf 0 setzt 
(RESET=0), und somit wird die  Befehlausführung in MAIN beendet.

Jetzt habe ich folgende  Meldung:

Error (12014): Net "INSTRFLG", which fans out to "SET_VREF", cannot be 
assigned more than one value
  Error (12015): Net is fed by "EXE:C1|FLG"
  Error (12015): Net is fed by "TRANSMITTER:C2|RESET"

Auf INSTRFLG greift somit  sowohl RECIEVER als auch TRANSMITTER, ich 
denke da liegt das Problem.
Mir ist irgendwie nicht ganz klar, wieso der INSTRFLG nicht durch 
Transmitter  geändert werden kann, oder wie ich meine Idee richtig 
realisieren kann.

Anbei  der Quellcode, stark verkürzt für den besseren Übersicht...

 library ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_unsigned.all;
USE ieee.numeric_std.all;


ENTITY FIRMWARE IS
PORT(

CLK_250: IN STD_LOGIC;
CLK_EN: OUT STD_LOGIC;
PD:OUT STD_LOGIC_VECTOR(2 downto 0);
DA_CLK:OUT STD_LOGIC;
SYNC_NOT:OUT STD_LOGIC_VECTOR(2 downto 0);
DA_IN: OUT STD_LOGIC_VECTOR(2 downto 0);
TX_EN,TX_DATA: IN STD_LOGIC

);
END FIRMWARE;

ARCHITECTURE MAIN OF FIRMWARE IS
SIGNAL INSTRUCTION: STD_LOGIC_VECTOR(11 downto 0):=(others=>'0');
SIGNAL INSTRFLG,ERROR: STD_LOGIC;
SIGNAL REC_ERROR:STD_LOGIC:='0';
SIGNAL WAITING: STD_LOGIC:='1';
SIGNAL PRSCL: INTEGER RANGE 0 to 8;
SIGNAL SET_VREF: STD_LOGIC;
   COMPONENT TRANSMITTER IS
  PORT(
       FLAG: IN STD_LOGIC;
       VOLTAGE:IN STD_LOGIC_VECTOR(7 downto 0);
       DA_SL: IN STD_LOGIC_VECTOR(2 downto 0);
       CLK: IN STD_LOGIC;
       SYNC: OUT STD_LOGIC_VECTOR(2 downto 0);
       DA_CLK: OUT STD_LOGIC;
       TX: OUT STD_LOGIC_VECTOR(2 downto 0);
       RESET:OUT STD_LOGIC
       );
   END COMPONENT TRANSMITTER;  
  
  
  COMPONENT EXE IS
  PORT(
    CLK:IN STD_LOGIC;
    REC_EN: IN STD_LOGIC;
    DATALINE: IN STD_LOGIC;
    COMMAND: OUT STD_LOGIC_VECTOR(11 downto 0);
          FLG,ERROR: OUT STD_LOGIC
    );
  END COMPONENT EXE;
BEGIN
C1: EXE PORT MAP(
      CLK_250,
    TX_EN,
      TX_DATA,
      INSTRUCTION,
      INSTRFLG,
      REC_ERROR
      );
C2: TRANSMITTER PORT MAP (
  SET_VREF,
  INSTRUCTION(7 downto 0),
  INSTRUCTION(10 downto 8),
  CLK,
  SYNC_NOT,
  DA_CLK,
          DA_IN,
          INSTRFLG
              );
PROCESS (CLK_250) 
BEGIN
IF(CLK_250'EVENT AND CLK_250='1')THEN
           
     CASE INSTRFLG IS---new command recieved
    WHEN '1'=>   
    CASE INSTRUCTION(11) IS
    WHEN '1'=> ---SEND DATA TO TRAMSITTER
      SET_VREF<='1'; ---START TRANSMISSION
    WHEN '0'=> 
       CASE  INSTRUCTION(10) IS
       WHEN '1' .......... blablabla
    END CASE;
          WHEN '0'=>
      SET_VREF<='0'; ----STOP TRANMISSION
      WAITING<='1';----wait for  new command
          WHEN OTHERS =>NULL;
    END CASE;
END IF;
---END OF MAIN PROCESS
END PROCESS;
END MAIN;

RECIEVER

library ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_unsigned.all;
USE ieee.numeric_std.all;

ENTITY EXE IS
PORT(
CLK:IN STD_LOGIC;
REC_EN: IN STD_LOGIC;
DATALINE: IN STD_LOGIC;
COMMAND: OUT STD_LOGIC_VECTOR(11 downto 0);
FLG,ERROR:OUT STD_LOGIC
);
END EXE;

 ARCHITECTURE  RECIEVER OF EXE IS
 
 SIGNAL COUNTER : INTEGER RANGE 0 to 26040:=0;--- BOUDRATE 9600 bit/sec
 SIGNAL DATA:STD_LOGIC_VECTOR(11 downto 0):=(others=>'0');
 BEGIN
 
 PROCESS(CLK)
 VARIABLE INDEX : INTEGER RANGE 0 to 12:=0;
 BEGIN
 IF(CLK'EVENT AND CLK='1')THEN
  

 IF(REC_EN='1') THEN ----START  recieving data
    IF (COUNTER<10)THEN
    COUNTER<=COUNTER+1;
    ELSE 
    COUNTER<=0;
   END IF; 
 
  IF(INDEX<12 AND COUNTER=9)THEN
  DATA(INDEX)<=DATALINE;
  INDEX:=INDEX+1;
  FLG<='0';
  END IF;
 END IF;
 IF(REC_EN='0')THEN ----STOP recieving data, send command.
   IF(INDEX=12)THEN---- VALID DATA
  COUNTER<=0;
  INDEX:=0;
  COMMAND<=DATA;
  FLG<='1';----SET INSTRFLG TO 1
  ELSE ---- Invalid DATA
  COUNTER<=0;
  ERROR<='1';
  INDEX:=0;
  END IF;  
END IF;
END IF;
END PROCESS;
END RECIEVER;

TRANSMITTER

library ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_unsigned.all;
USE ieee.numeric_std.all;

ENTITY TRANSMITTER IS

PORT(
FLAG: IN STD_LOGIC;
VOLTAGE:IN STD_LOGIC_VECTOR(7 downto 0);
DA_SL: IN STD_LOGIC_VECTOR(2 downto 0);
CLK: IN STD_LOGIC;
SYNC: OUT STD_LOGIC_VECTOR(2 downto 0);
DA_CLK: OUT STD_LOGIC;
TX: OUT STD_LOGIC_VECTOR(2 downto 0);
RESET: OUT STD_LOGIC
);
END TRANSMITTER;

ARCHITECTURE TX OF TRANSMITTER IS
SIGNAL DA_COUNTER: INTEGER RANGE 0 to 10:=0;
SIGNAL DATA: STD_LOGIC_VECTOR(15 downto 0);
SIGNAL ERROR: STD_LOGIC:='0';
 
BEGIN
DATA(5 downto 0)<="000000";---"DONT CARE" bits
DATA(15 downto 14)<="00";--- NORMAL MODE
PROCESS (FLAG,CLK,DA_SL)
VARIABLE INDEX : INTEGER  RANGE 0 TO 15:=15;
BEGIN
IF(CLK'EVENT AND CLK='1')THEN

   CASE FLAG IS----send data
     WHEN '1' =>
        DATA(13 downto 6)<=VOLTAGE;
         CASE DA_SL IS---SELECT  DAC_SYNC
       WHEN "001" =>
        SYNC <=NOT "001";
      WHEN "010" =>
        SYNC <=NOT "010";
      WHEN "011" =>
        SYNC <=NOT "100";
      WHEN "111"=>
        SYNC <=NOT "111";
      WHEN OTHERS =>
        ERROR <='1';
      END CASE;
        IF (DA_COUNTER<9) THEN  
      DA_COUNTER<=DA_COUNTER+1;
         ELSE 
         DA_COUNTER<=0;
       END IF;
      
     IF(DA_COUNTER<5) THEN---DA_CLK CONTROLL
       DA_CLK<='1';
      TX<=(OTHERS=>DATA(INDEX)); ---SET BIT
       ELSE 
      DA_CLK<='0';
     END IF;
     IF (INDEX=0) THEN ---TRANSMISSION COMPLETE; RESET INSTRFLG.
     RESET<='0';
     END IF;
     IF (DA_COUNTER=7 AND INDEX>0 )THEN
       INDEX:=INDEX-1; --- SAVES BIT ON FALLING EDGE, SET NEW INDEX
     END IF;  
     WHEN '0'=>   ---RESET INDEX, SYNC OFF
     INDEX:=15;
     SYNC<="111";
     DA_COUNTER<=0;
     WHEN OTHERS=> NULL;
      END CASE;
     
END IF;
  
END PROCESS;
END TX;

Ich weiss, das ist viel Code, aber ich hofe jemand hier wird mir doch 
Helfen:))

Vielend dank im Vorraus

[Hmm (Gast)]

>Ich weiss, das ist viel Code, ...

Deswegen soll langer Code auch als Anhang gepostet werden.
Steht bei jedem Anfang eines neuen Postings:
"Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang"

Und dann: Das schreibt sich "Receiver" auch wenn es sich "Reßiwer" 
spricht.

[Moog (Gast)]

Du kannst nicht ohne Weiteres von zwei Stellen aus ein Signal "ändern". 
Das würde ja realisiert als eine "Leitung" die von zwei Treibern 
angesteuert wird. Wenn ein Treiber ein High treibt, und der andere ein 
Low...

Es gibt beim std_logic dafür die "schwachen" Zustände 'H' und 'L' (im 
Gegensatz zu den starken '0' und '1') sowie den hochohmigen Zustand 'Z'. 
Damit könntest du das realisieren.

Aber bevor du dich verkünstelst: Nimm doch einfach zwei Signale! Ein 
'start' in die eine Richtung, ein 'done' in die andere.

[GS (chromosoma)]

Na, den START Signal muss ich  ja trotzdem mit  DONE  auf Null setzen, 
damit ich später wieder starten kann.

zB
If(DONE='1') THEN
 START='0'
END IF;

 Ist das dann nich das Gleiche?

[mensch (Gast)]

Hi, geht's vill mit ner Or-Verknüpfung der beiden Signale?

[Christian R. (supachris)]

Böser Kommunist schrieb:
> Na, den START Signal muss ich  ja trotzdem mit  DONE  auf Null setzen,
> damit ich später wieder starten kann.
>
> zB
> If(DONE='1') THEN
>  START='0'
> END IF;
>
>  Ist das dann nich das Gleiche?

Nee, weil du das in dem gleichen Prozess machst wie das setzen.

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

Christian R. schrieb:
> Nee, weil du das in dem gleichen Prozess machst wie das setzen.
Nennt sich dann Handshake. Und der zeitliche Ablauf der nötigen 4 
Schritte ist so:

              a            b c d
               _____   ______
 Start     ___|     ...      |_______
                            ___ 
 Done      _________...____|   |_____

a Start wird signalisiert, das Senden beginnt
b Senden fertig wird mit Done signalisiert
c Start wird deaktiviert, wenn Done aktiv ist
c Done wird deaktiviert, wenn erkannt wird, dass Start inaktiv ist

library ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_unsigned.all;
USE ieee.numeric_std.all;

Viel hilft viel, oder wie?
die std_logic_unsigned bringt nichts ohne die std_logic_arith. Und die 
beiden zusammen dürfen nie mit der numeric_std verwendet werden. Siehe 
dazu den Beitrag "Re: Ganze Zahl in Ziffern zerlegen" und den 
Beitrag "std_logic_vector auf integer umwandeln"

  PROCESS (FLAG,CLK,DA_SL)
  VARIABLE INDEX : INTEGER  RANGE 0 TO 15:=15;
  BEGIN
  IF(CLK'EVENT AND CLK='1')THEN

Ich sag' jetzt mal nichts weiter zur speichernden(!) Variable INDEX, das 
steht alles schon im Beitrag "Variable vs Signal". Aber 
das mit der Sensitivliste muss ich doch sagen: FLAG und DA_SL sind 
zuviel. Der Prozess ist nur auf CLK sensitiv...


Hier wäre ein Schieberegister evtl. die bessere Lösung gegenüber einem 
Multiplexer. Besonders in einem FPGA...

      TX<=(OTHERS=>DATA(INDEX)); ---SET BIT

Ein Tipp: sieh dir einfach an, wie das im Inneren eines Mikrocontrollers 
gemacht wird. Das Datenblatt gibt das meist schon ausreichend viel 
Informationen. Und uCs sind schon lang am Markt, da konnte die Evolution 
schon einige Fehldesigns ausbügeln....

[GS (chromosoma)]

Danke für die Antworten. Handshake werde ich noch ausprobieren. Die 
Sensitivliste  ist noch veraltet,  ich habe vorher dort was anderes 
geschrieben.


Den Unterschied zwischen Variablen und Signale  ist mir noch nicht ganz 
klar, oder besser gesagt, wieso so viele gegen variablen sind. Ich 
verwende  die Variablen  einfach für bessere Übersichtlichkeit: alle 
processbezogene Sachen werden auch im Process deklariert.
Außerdem habe ich im Buch gelesen, dass Variablen sofort aktualisiert 
werden, während  Signale auf das Ende des Process warten müssen.
Im Buch stand übrigens  nichts gegen Variablen an sich.

[Jürgen S. (engineer)]

Böser Kommunist schrieb:
> ist mir noch nicht ganz klar, oder besser gesagt, wieso so viele
> gegen variablen sind.

Weil Variablen von Anfängern komplett falsch verwendet werden, weil sie 
den Sinn und Nutzen dahinter (im Bezug auf die Synthese) nicht verstehen 
und die fehlerhafte Nutzung zu massenhaften Problemen führt.

> Ich verwende  die Variablen  einfach für bessere Übersichtlichkeit:
Aus genau dem Grund verwende ich keine. 90% meiner VHDL-Codes kommen 
vollständig ohne Variablen aus. Selbst in Testbenches brauche ich oft 
keine.

> alle processbezogene Sachen werden auch im Process deklariert.
Was sind nach Deiner Vorstellung "prozessbezogene Sachen"?

> Außerdem habe ich im Buch gelesen, dass Variablen sofort aktualisiert
> werden, während  Signale auf das Ende des Process warten müssen.
Ohweh, Ich sehe sie schon vor dem geistigen Auge, die armen notleidenden 
Signale, die auf die Barikaden gehen, weil sie immer bis zum Ende des 
Prozesses dumm in der Ecke rumhängen und nicht aktualisiert werden, 
während die offenkundig bevorzugten Variablen schon munter weiterrechen 
dürfen. Wo bleibt die Gerechtigkeit beim VHDL?

Jetzt mal im Ernst: Du hast schon verstanden, dass das so sein muss, 
dass Signale erst im nächsten Takt ihren Wert kriegen dürfen und man 
innen drin immer die alten Werte hat? Erinnere Dich mal an die 
Datenverarbeitungsvorlesung, erstes Semester, wo es um die Zustände 
Z(t+1) = f(Z(t) ..) ging, das ist genau das. Variablen sind im 
synthetisierbaren Code nur ein Hilfsmittel zum vereinfachten formulieren 
von Zwischenergebnissen, sonst nix.

> Im Buch stand übrigens nichts gegen Variablen an sich.
Der Autor ist wahrscheinlich vom Förderverein zur Intensivierung der 
Variablennutzung in HDL-Codes geschmiert worden. Jedenfalls ist der 
Nachname des Autors schon mal nicht Miller. Das steht fest. :-)

Warte mal bis übernächstes Jahr: Dann kommt das vom EU-Ministerium für 
Gleichstellungsfragen geförderte VHDL 2015. In dem müssen dann auch die 
Signale sofort aktualisiert werden und dürfen nicht mehr benachteiligt 
werden. Das wird schick!

[GS (chromosoma)]

> Was sind nach Deiner Vorstellung "prozessbezogene Sachen"?

z.B. interne Counter, Hilfsvariablen, etc. die nur für den Process 
wichtig sind.

> Errinnere Dich mal an die Datenverarbeitungsvorlesung
Habe so eine Vorlesung nicht gehabt:)


Das Buch, das ich für den Anfang  gelesen habe war "Circuit Design with 
VHDL" Volnei A. Pedroni.



>weil sie
den Sinn und Nutzen dahinter (im Bezug auf die Synthese) nicht verstehen

Kannst du bitte kurz beschreiben wofür die  Variablen gedacht sind, und 
zu welchen Problemen diese führen können. Evtl. mit einem simplem 
Beispiel?

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

> Kannst du bitte kurz beschreiben wofür die Variablen gedacht sind,
Für Zwischenergebnisse. Aber nicht zum Speichern. Variablen werden also 
immer am Prozessanfang initialisiert.

> und zu welchen Problemen diese führen können.
> Evtl. mit einem simplem Beispiel?
Ich hatte vier Posts weiter oben einen Link zum Thread Variable vs. 
Signal eingefügt. Bitte jetzt Zutreffendes ankreuzen:
[ ] ich habe den Link zum Thread nicht gesehen
[ ] ich habe das, was im Thread beschrieben ist, nicht verstanden

[GS (chromosoma)]

[V] ich habe das, was im Thread beschrieben ist, nicht verstanden

So wie ich es verstanden habe, die Signalzuweisung  ist sequenziel und 
die Variabelnzuweisung parralel, sprich sofort.Etwa so...
Was ich nicht ganz verstehe, in deinem Bsp:

>   process(din)
>   variable var: std_logic;
>   begin
>      res1 <= var;
>      var  := din;
>      res2 <= var;
>   end process;
>

Ist das nicht selbsverständlich, dass res1 den alten Wert erhält, weil 
die  "var" aktualisierung  erst danach erfolgt?
Obwohl, wenn Variablen parralel arbeiten, sollte das nicht passieren.

ehm...ich bin durcheinander.

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

Böser Kommunist schrieb:
> in deinem Bsp: ....
> Ist das nicht selbsverständlich, dass res1 den alten Wert erhält, weil
> die  "var" aktualisierung  erst danach erfolgt?
Ich beantworte dir diese Frage nicht, weil sie rein akademisch ist.
Du musst dir eines klar machen: die Simulation arbeitet ausschließlich 
mit der Sensitivliste, der Synthese ist die Sensitivliste schnurzegal. 
Letztendlich darf dich aber nur die Synthese interessieren, denn nur mit 
der Synthese kannst du ein Design in Hardware umsetzen. Du musst also 
deinen VHDL-Code so schreiben, dass er das Verhalten deiner Harware 
richtig simuliert. Mit diesem neuerworben Wissen siehst du dir diesen 
Prozess nocheinmal an.

Und du erkennst, dass die (Verhaltens-)Simulation falsch sein muss, 
weil der Simulator nur bei einer Änderung von din den Prozess neu 
berechnet, (und so res1 ein von din abhängiges, speicherndes Verhalten 
vorgaukelt), die Synthese aber erkennt, dass die Signale einfach 
geradeaus durchverdrahtet werden.
Und du wirst diesen Prozess nie richtig simulieren können (also so, wie 
sich die Hardware verhalten wird), weil die die Variable var nicht in 
die Sensitivliste (zur Neuberechnung des Prozesses) aufnehmen kannst.

Böser Kommunist schrieb:
> So wie ich es verstanden habe, die Signalzuweisung  ist sequenziel und
> die Variabelnzuweisung parralel, sprich sofort.Etwa so...
Keine Ahnung was auch immer da irgendwer mit sequentiell oder parallel 
meint. Ich glaube, diese Begriffe dienen nur der Verwirrung von 
Anfängern. In der Hardware ist letztlich alles parallel realisiert, also 
immer da...


Nochmal kurz zum Mitschreiben:
Variablen sind dort sinnvoll und geeignet, wo eine komplizierte 
Berechnung in kleine Schritte aufgeteilt werden soll/muss. Aber immer 
steht am Anfang des Prozesses eine Zuweisung an die Variable:
http://www.lothar-miller.de/s9y/archives/78-Bubblesort.html
http://www.lothar-miller.de/s9y/archives/84-Binaer-nach-BCD-mit-1-Takt-pro-Stelle.html
http://www.lothar-miller.de/s9y/archives/67-Vektor-nach-BCD-kombinatorisch.html
http://www.lothar-miller.de/s9y/archives/29-Division-in-VHDL.html
http://www.lothar-miller.de/s9y/archives/73-Wurzel-in-VHDL.html
http://www.lothar-miller.de/s9y/archives/68-Graycode-Umwandlung.html

Und so richtig austoben kann man sich mit Variablen, Schleifen und 
sostwas in Testbenches, denn die müssen ja nicht synthetisierbar sein:
http://www.lothar-miller.de/s9y/archives/75-PS2-Tastatur.html

[mike (Gast)]

> in deinem Bsp: ....
> Ist das nicht selbsverständlich, dass res1 den alten Wert erhält, weil
> die  "var" aktualisierung  erst danach erfolgt?

Ganz klar NEIN, denn wie Du selber richtig geschrieben hast, bekommen 
Signale erst am Ende des Prozesses ihre Werte. Beide res stehen dann auf 
din.

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

mike schrieb:
> Ganz klar NEIN, denn wie Du selber richtig geschrieben hast, bekommen
> Signale erst am Ende des Prozesses ihre Werte.
Aber jetzt kommts: sie bekommen den letzten Wert, der ihnen /bis 
dahin/ zugewiesen wurde. Probiers einfach mal aus...

> Beide res stehen dann auf din.
Das gilt nur für das Syntheseergebnis, aber nicht für die Simulation!
Zur Abkürzung ein Link auf die Lösung im 
Beitrag "Re: Variable vs Signal"

[mike (Gast)]

Stimmt. Das ist natürlich klasse, wenn man zwischendrin geschickt mit 
den Signalen bastelt. Einfach genial.

[Jürgen S. (engineer)]

Lothar Miller schrieb:
>> So wie ich es verstanden habe, die Signalzuweisung  ist sequenziel und
>> die Variabelnzuweisung parralel, sprich sofort.Etwa so...
> Keine Ahnung was auch immer da irgendwer mit sequentiell oder parallel
> meint. Ich glaube, diese Begriffe dienen nur der Verwirrung von
> Anfängern. In der Hardware ist letztlich alles parallel realisiert, also
> immer da...

Ich würde mal stark annehmen, dass sich die Begriffe auf den zeitlichen 
Ablauf des Prozesses beziehen. Die Variablenzuweisung wäre dann aber 
sequenziell, weil die Zeitebene eine Rolle spielt, wärend die 
Signalzuweisung parallel ist, weil die Zeitabhängigkeit nicht exisitert: 
Alle Signale werden zur gleichen Zeit, nämlich beim Übergang in die 
nächste Zeitscheibe geändert, egal, wie sie sequeniell angeordnet sind. 
Dies ist quasi parallel, da es zwischen diesen Signalzuweisungen keine 
Zeit vergeht. Die Darstellung an sich macht schon Sinn. Allerdings gibt 
es anschaulichere Darstellungen des Sachverhaltes.

Das Beispiel oben zeigt aber wieder einmal dass genau hier der Hae im 
Pfeffer liegt. Man muss sich bei der Nuzung von Variablen über die 
Sequenz Gedanken machen, bei Signalen nicht - jedenfalls nicht innerhalb 
einer Zeitebene.

[GS (chromosoma)]

Also Fazit ist: Nur Signale verwenden?

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

Böser Kommunist schrieb:
> Also Fazit ist: Nur Signale verwenden?
Soweit wie möglich.
Und wenn schon Variablen verwendet werden sollen, dann werden die vor 
der Verwendung initialisiert und nur zum Ablegen von Zwischenergebnissen 
verwendet. Ein paar sinnvolle Beispiele habe ich aufgezeigt und das hier 
ist auch ein Musterbeispiel für die Verwendung von Variablen:
http://www.lothar-miller.de/s9y/archives/86-Einsen-im-Vektor-zaehlen.html

Aber eine speichernde Variable ist für mich von vorn herein suspekt.

[Duke Scarring (Gast)]

Böser Kommunist schrieb:
> WIe der Name sagt,  Reciever empfäng die 12 Bit langen Befehl.
> Sobald die Übertragung  fertig ist, setzt Reciever INSTRFLG auf 1. Das
> sagt den Main-Process, dass er jetzt diese 12 Bit in einen Befehl
> decodieren soll.
Statt der vorgeschlagenen Handshakesache könntest Du auch Dein INSTRFLG 
sofort wieder auf '0' setzten. Damit wird es zu einem 
Instruction_enable.
Dein Main-Process und andere müssen dann nur aktiv werden, wenn das Bit 
'1' ist. Damit das Konzept richtig funktioniert, dürfen die 
Instructionen nicht schneller kommen, als sie verarbeitet werden können.

Jürgen Schuhmacher schrieb:
> die armen notleidenden
> Signale, die auf die Barikaden gehen
Du solltest öfters einen Clown frühstücken (bzw. zum Abendbrot 
verspeisen) (+1 gefällt mir :-)

Duke