UART empfangen auf FPGA

Weil txd_tmp immer '1' ist.

1

TXD      <= txsr(txsr'left);

2

txd_tmp  <= txsr(0);

3

:

4

         txsr     <= txsr(txsr'left-1 downto 1) & '1';  

5

:

6

         rxd_sr <= rxd_sr(rxd_sr'left-1 downto 0) & txd_tmp;

Du taktest immer nur eine '1' in den Empfänger hinein...

Ich habe es jetzt so umgeschrieben:
  TXD      <= txsr(txsr'left);
  txd_tmp  <= txsr(txsr'left);
Das Ergebnis sieht folgendmaßen aus(s. Anhang)

Wo liegt jetzt noch der Fehler?
Warum fängt der Empfang erst beim 4.Bit an und müsste es nicht in der 
Bitmitte sein?

U.A. weil die erste fallende Flanke nicht erkannt werden kann:

1

:

2

    if (rxd_sr(3 downto 2) = "10") then                 -- fallende Flanke Startbit            

3

:

Denn die geht ja von 'U' nach '0'...  :-o

Sieh dir auch mal die internen Signale an: txbitcnt und rxbitcnt

BTW:
Irgendwie scheint mir der Empfänger (bezogen auf den Sender) mit einer 
falschen Baudrate zu laufen... :-/

txbitctr fängt auch erst bei 3 an zu zählen...

habe die flankenerkennung auf "01" gesetzt, sieht jetzt etwas besser 
aus:

    if (rxd_sr(3 downto 2) = "01") then

Aber noch nicht 100%!?

> if (rxd_sr(3 downto 2) = "01") then
Du strocherst aber arg im Trüben... :-/

Kurz und gut: Das Startbit ist eine fallende Flanke.
Dein Problem ist, dass eine Flanke von 'U' nach '0' eben gerade 
keine fallende Flanke ist (ich meine, so was schon mal geschrieben zu 
haben...).
Initialisiere doch einfach mal das txsr mit dem Ruhepegel:
signal txsr     : std_logic_vector  (9 downto 0) := (others=>'1');

Mit angehängtem Quellcode "UART.vhd" habe ich jetzt das das Ergebnis 
"Simulation4.jpeg".

Es sieht fast gut aus. Nur gibt es denke ich noch das Problem mit der 
Abtastung in dr Bitmitte. Wieso ist diese aber auch unbegint notwendig?
Und es wird irgendwarum erst die die zweite negative Flanke erkannt!?

Gruß

> Nur gibt es denke ich noch das Problem mit der Abtastung in dr Bitmitte.
Als Tipp: das rxd_sr bringt dir 4 Takte Latency.
Mach das mal kürzer:

1

   signal rxd_sr    : std_logic_vector (1 downto 0) := "11";  -- Flankenerkennung und Eintakten

2

  :

3

          rxsr     <= rxd_sr(rxd_sr'left-1) & rxsr(1); -- rechts schieben, weil LSB first         

4

 :

5

    if (rxd_sr = "10") then                 -- fallende Flanke Startbit

> ... Abtastung in dr Bitmitte. Wieso ist diese unbegint notwendig?
Stell dir mal vor, der Sender sendet mit 3% Fehler (z.B. 9900Bits/sec 
statt mit 9600Bits/sec). Kannst du dir jetzt vorstellen, welchen Vorteil 
die Abtastung in der Bitmitte hat?

Das Resultat ist dieses. (siehe Anhang)

Der Sender ist in meinem Fall ja eine UART in einem FPGA-implementiert. 
Un dwird zu Testzwecken auch nur so mit einer konstanten Baudrate 
versendet. Da kann ich doch mit einer Fehlerrate von nahezu 0% rechnen!?

Für die Praxis ist das natürlich sinnvoll.


Warum zählt txbitcnt eigentlich bis 10 es sind ja keine 11Bit pro Frame?

> Das Resultat ist dieses. (siehe Anhang)
Der Abtastzeitpunkt ist schon besser. Jetzt kontrollierst du noch, 
weshalb du lauter 'U' eintaktest, dann bist du fertig.

> Warum zählt txbitcnt eigentlich bis 10
Hmm... weil es so beschrieben ist?  :-/

Ganz einfach: während txbitcnt=0..9 werden Bits übertragen
(1 Startbit, 8 Datenbits, 1 Stopbit).
txbitcnt=10 ist der Ruhezustand des Senders.

> Jetzt kontrollierst du noch,
> weshalb du lauter 'U' eintaktest, dann bist du fertig.

Meines Erachtens nach werden keine 'U' eingetaktet. Gesendet wird ja 
kein 'U' und dasselbe Signal wird auch eingetaktet.

Dies Variante habe ich auch schon auspropiert. Klappt auch gut. Das ist 
ja aber nur der Sender. Der funktioniert bereits. Es geht hier um den 
Empänger!!!

H.H.

Nochmal zum Thema zurück:

> Jetzt kontrollierst du noch, weshalb du lauter 'U' eintaktest, dann bist > du 
fertig.

Meines Erachtens nach werden keine 'U' eingetaktet. Gesendet wird ja
kein 'U' und dasselbe Signal wird auch eingetaktet.

> Aus meiner Sicht ist es immer wichtig einen syncronen Reset einzubauen,
> damit es nicht zu undefinierten Zuständen kommen kann.
Ein "wirklicher" Reset sind nur sehr selten nötig. Oft braucht den der 
Entwickler nur für seinen Reset-Taster. Dazu gibt es ein schönes Paper 
von Xilinx:
http://www.xilinx.com/support/documentation/white_papers/wp272.pdf
Fazit: When creating each section of a design, simply ask, “Does this 
bit need to be reset”?

> Meines Erachtens nach werden keine 'U' eingetaktet.
Die Simulation sagt was anderes  :-o

> Die Simulation sagt was anderes  :-o

Ich verstehe nicht es nicht.
wenn ich die Parameter ändere wie du es vorgeshclagen hast:

signal rxd_sr    : std_logic_vector (1 downto 0) := "11";  -- 
Flankenerkennung und Eintakten
  :
 rxsr     <= rxd_sr(rxd_sr'left-1) & rxsr(1); -- rechts schieben, weil 
LSB first
 :
if (rxd_sr = "10") then            -- fallende Flanke Startbit

...dann  erhalte ich für das eintakten 'U', wenn es auf die 
Ursprünglichen Werte gesetzt wird. ist die Abtastung zwar nicht in der 
Mitte, aber kein 'U'!

Ich habe keine Ahnung woran es jetzt liegt!???????

"Mitdenken!" sagte der Meister zum Stift  :-/

Probier mal statt:

1

   rxd_sr <= rxd_sr(rxd_sr'left-1 downto 0) & txd_tmp;

das da:

1

    rxd_sr <= rxd_sr(0) & txd_tmp;

Und wenn das nichts hilft, hindert dich keiner, in der simulation mal 
das rxd_sr genauer anzuschauen...

> Und wenn das nichts hilft, hindert dich keiner, in der simulation mal
> das rxd_sr genauer anzuschauen...

Es scheinst sich mit

       rxd_sr <= rxd_sr(0) & txd_tmp;

irgendwie nichts zu tun...

rxd_sr sieht doch gut aus...

Da ist der Fehler:
rxsr     <= rxd_sr(rxd_sr'left-1) & rxsr(1);

Du schiebst in die falsche Richtung. Probier mal:
rxsr     <= rxd_sr(1) & rxsr(rxsr'left downto 1); -- rechts schieben, 
weil LSB first

Bitte nicht einfach Copy-Paste machen und alle Fehler mitkopieren... :-/

Habe

> rxsr <= rxd_sr(1) & rxsr(rxsr'left downto 1);

probiert. Es funktiont ab dem zweiten Frame!
Es müsste so auch in Ordung sein, da ich sowieso eine Endlosschleife 
habe.

Noch eine Modifikation:
letztendlich soll bei

Generic ( Quarz_Taktfrequenz : integer  := 50000000; --Hertz
            Baudrate : integer :=  12000000          -- Bits/S
          );

empfangenwerden

Es funktioniert zwar noch, aber selbst beim 2. Frame ist die Abtastung 
nicht wie im vorigen Bild "Simulation7" etwa in der Mitte. Sie es 
rutscht dann richtung nächstes Bit.

Kann man da was machen

> Kann man da was machen
Wenn du unbedingt (selber schuld) diese Geschwindigkeit asynchron 
fahren willst, und damit zufrieden bist, dass die simulation schön 
aussieht, dann solltest du hier was machen:

1

 rxcnt    <= ((Quarz_Taktfrequenz/Baudrate)-1)/2; -- erst mal nur halbe Bitzeit abwarten

Probiers mal so:

1

 rxcnt    <= 2; -- erst mal nur halbe Bitzeit abwarten

Nimm eine vernünftige Baudrate. 12MBit/s sind zu schnell für eine RS232 
Schnitte. Hier solltest du dir ein sinnvolles Interface aussuchen. Z.B. 
ein synchrones Interface wie SPI. Wenns unbedingt asynchron sein soll, 
dann mit Manchester-Codierung, damit pro Bit wieder aufsynchronisiert 
werden kann.

Funktioniert! Besten Dank!

beim Syntaxcheck ist jetzt doch noch ein Fehler aufgetreten der für die 
Simulation scheinbar keine Rolle gespielt hat:


 Line 113. Size of concat operation is different than size of the 
target.

Er bezieht aich auf diese Zeile im Sendungsprocess:
  txsr     <= txsr(txsr'left-1 downto 1) & '1';

Weis im Moment nicht wied er zu beseitigen wäre.

txsr     <= txsr(txsr'left-1 downto 1) & '1';

Mitdenken...  :-/

txsr     <= txsr(txsr'left-1 downto 0) & '1';

Da hätte der Simulator aber auch meckern müssen...

Danke!

Nochmal zu diesem Thema:
Bisher habe ich AA übertragen, da hat alles funktioniert:

Übertrage ich jetzt x"C2" kommt am Emfänger nichts mehr an???
Die UART ist dich nicht nur zum Empfang von x"AA" geeignet?

Gruß

Du hast ein Problem mit der Schieberichtung:
C2 = 11000010
43 = 01000011
Siehst du was?
Wenn du 71 sendest wirst du 8E empfangen usw.usf.
Fazit: wenn der Sender das MSB zuerst rausschiebt, dann sollte der 
Empfänger auch das MSB zuerst empfangen...

1

   txsr  <= txsr(txsr'left-1 downto 1) & '1';       -- links schieben, mit MSB beginnen

2

3

   rxsr  <= rxd_sr(1) & rxsr(rxsr'left downto 1);   -- rechts schieben, weil LSB first

Mach das Empfangsregister doch so:

1

   rxsr  <= rxsr(rxsr'left downto 1) & rxd_sr(1);   -- links schieben, weil MSB first

PS: Phänomenal, dass du das nicht selber siehst ;-)

> hab' das gerade auch von oben bis unten durchgelesen
Donnerwetter, meine Hochachtung.
Ich musste es immer nur in kleinen Häppchen aufnehmen   ;-)

Eine weitere Frage:
Das Startbit des UART-Signals ist nicht genauso lang wie die Datenbits.
Das macht mir Probleme, wenn ich es Manchestercodieren will, weil da 
alle Bits gleich lang sein müssen.
Beim Stoppbit wird hier bewusst länger gewartet, aber das Startbit ist 
irgendwarum länger. Bei meiner Frequenz ist das Startbit 100ns, die 
Datenbits 80ns. Warum dieser Unterschied bei gleicher Bitrate?
Ziel ist es alles gleich lang zu machen.

Mit der oben genannten MUX-Version ist das kein Problem, aber bei der 
verwendeten schon.

> Warum dieser Unterschied bei gleicher Bitrate?
Mein Glückwunsch, du hast einen Takt Latency entdeckt.

Das ursprüngliche Konzept dieser UART setzt eine Baudrate voraus, die 
wesentlich geringer als die FPGA-Taktfrequenz ist. Da kann man 20ns 
Verzögerung schon mal tolerieren ;-)

Du solltest bei derart knappen Timing keinesfalls irgendwelche Werte 
herrechnen. Hier muss jeder Takt ausgezählt werden.

1

  Generic ( Quarz_Taktfrequenz : integer   := 50000000;  -- Hertz               

2

            Baudrate : integer :=  12000000              -- Bits/Sec             

3

        );

Du solltest bei derart knappen Timing keinesfalls irgendwelche Werte 
herrechnen. Denn so schön diese Formel aussieht:

1

      if txcnt < ((Quarz_Taktfrequenz/Baudrate)-1)then

So falsch ist das Ergebnis:
50000000/12000000 = 4,16666666

> Bei meiner Frequenz ist das Startbit 100ns, die Datenbits 80ns.
80ns sind damit genauso falsch wie 100ns. Richtig wären 83,3333ns. Die 
wirst du aber mit einem 20ns Takt niemals erreichen...

> Ziel ist es alles gleich lang zu machen.
Dann starte den Zähler bei 1:

1

   if (tx_start = '1' and tx_busy = '0') then   -- dauernd senden, solange tx_start aktiv

2

      txcnt    <= 1;                            -- Z�hler initialisieren

>> Ziel ist es alles gleich lang zu machen.
>Dann starte den Zähler bei 1:
>if (tx_start = '1' and tx_busy = '0') >then
>    txcnt    <= 1;

Was wäre zu ändern um für das Stoppbit die gleiche anforderung zu 
stellen? Müsste der Zähler dann einfach nur bis neun gehen? Mir scheint 
wenn ich den zähler bis neun gehen lasse, dann iwrd das Stoppbit zu 
kurz. (txbitcnt geht nur bis 2)

>  Was wäre zu ändern ...
Du hast eine ganz andere Aufgabenstellung, warum fängst du mit einer SIO 
an, machst die dann rasend schnell, und hängst anschliessend noch einen 
Manchesterdecoder dazu?

Das wäre wie wenn du sagst:
Ich brauche ein Fortbewegungsmittel, also nehme ich mir ein Moped 
(RS232-SIO). Dann bastle ich solang dran herum, dass ich damit damit 300 
fahren kann (12Mbit/sec). Und zum Schluss mache ich Flügel dran 
(Mnachester), dann bin ich fertig.
Richtig wäre gleich zu sagen: ich brauche ein Flugzeug.

>  Was wäre zu ändern ...
Ich klinke mich hier aus, denn du schießt dir gerade mit dem tx_busy ins 
Knie. An dem haben wir ganz zu Anfang (weißt du das noch?) herumgemacht.

Wie gesagt: du brauchst (selber) erst mal eine genaue Definition der 
Zielaufgabe. Welche Daten mit welcher Geschwindigkeit mit welcher 
Codierung. Wozu willst du das überhaupt verwenden? Wäre ein anderes 
Protokoll nicht geeigneter?

Ziel:

ca.5Mbit Daten(muss nicht genau sein), die Manchestercodiert übertragen 
werden sollen.(also 10Mbit)
1. FPGA sendet -> kapazitive Übertragungsstrecke(deswegen 
Manchestercodiert für gleichspannungsfreiheit) -> 2.Fpga empfängt wertet 
aus.

Es soll nur eine RS232 simuliert werden, d.h. die Daten sollen die 
"Form" einer UART haben und werden per LVDS übertragen.
Ok, aber danke bis hierher!

> Ok, aber danke bis hierher!
De nada ;-)