zu wenig LED's/Anzeigen auf dem Altera-/Intel-Board?

[Markus F. (mfro)]

... kein Problem. Braucht's nicht.

Die Intel-/Altera-FPGAs können das USB-Blaster Interface als 
jtag-Terminal benutzen, man kann also einfach Debug-Ausgaben an den 
Host-Rechner zurückschicken. Mit dem Qsys-/Nios-Geraffel wird das auch 
fleissig benutzt, leider hat Altera/Intel "vergessen" zu dokumentieren, 
wie man das Interface mit "normalem" VHDL nutzen kann:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity jtag_uart is
    generic
    (
        LOG2_RXFIFO_DEPTH               : natural;
        LOG2_TXFIFO_DEPTH               : natural
    );
    port
    (
        clk                             : in std_ulogic;
        reset_n                         : in std_ulogic;

        rx_data                         : out character;    -- received data
        rx_ready                        : out std_ulogic;   -- received data valid
        rx_data_req                     : in std_ulogic;    -- ask for data
        rx_paused                       : out std_ulogic;   -- receive paused

        tx_data                         : in  character;    -- data to send
        tx_start                        : in  std_ulogic;   -- start sending data
        tx_idle                         : out std_ulogic    -- we are not busy sending
     );
end entity jtag_uart;

architecture rtl of jtag_uart is
    component alt_jtag_atlantic
        generic
        (
            INSTANCE_ID                 : integer := 0;
            LOG2_RXFIFO_DEPTH           : integer := 0;
            LOG2_TXFIFO_DEPTH           : integer := 0;
            SLD_AUTO_INSTANCE_INDEX     : string := "YES"
        );
        port
        (
            clk                         : in std_ulogic;
            rst_n                       : in std_ulogic;
            
            r_dat                       : in character;                         -- data to send
            r_val                       : in std_ulogic;                        -- data is valid
            r_ena                       : out std_ulogic;                       -- allow to send data
            
            t_dat                       : out character;                        -- incoming data
            t_dav                       : in std_ulogic;                        -- give us more data
            t_ena                       : out std_ulogic;                       -- received data available
            t_pause                     : out std_ulogic
        );
    end component alt_jtag_atlantic;

begin
    i_jtag_uart : component alt_jtag_atlantic
        generic map
        (
            INSTANCE_ID                 => 0,
            LOG2_RXFIFO_DEPTH           => LOG2_RXFIFO_DEPTH,
            LOG2_TXFIFO_DEPTH           => LOG2_TXFIFO_DEPTH,
            SLD_AUTO_INSTANCE_INDEX     => "YES"
        )
        port map
        (
            clk                         => clk,
            rst_n                       => reset_n,

            -- alt_jtag_atlantic ports have _very_ strange (backwards) names...
            
            -- this is the receiving part of alt_jtag_atlantic, the ports
            -- we actually *send* data to
            r_dat                       => tx_data,
            r_val                       => tx_start,
            r_ena                       => tx_idle,

            -- this is the sending part of alt_jtag_atlantic, i.e. the ports
            -- we receive data from
            t_dat                       => rx_data,
            t_dav                       => rx_data_req,
            t_ena                       => rx_ready,
            t_pause                     => rx_paused
        );
end architecture rtl;

Mit dieser Komponente kann man Daten (character) über die (ja sowieso 
vorhandene JTAG-Anbindung) an den Host schicken und mit dem (etwas 
versteckten) Programm "nios2-terminal" anzeigen lassen.
Wenn einem die Anzeige nicht paßt, kann man auch eine eigene bauen.

Mir unerklärlich, warum Intel das nicht dokumentiert - schließlich ist 
das ein sehr brauchbares Feature...

[FPGA zum Spass (Gast)]

Markus F. schrieb:
> Wenn einem die Anzeige nicht paßt, kann man auch eine eigene bauen.

Und wie?
Gibts Sourcecode für den PC?

Ich würde das gerne nutzen, aber nicht als Anzeige sondern als RS232 
Ersatz.

[User (Gast)]

FPGA zum Spass schrieb im Beitrag #5816492:
> Markus F. schrieb:
>> Wenn einem die Anzeige nicht paßt, kann man auch eine eigene bauen.
>
> Und wie?
> Gibts Sourcecode für den PC?
>
> Ich würde das gerne nutzen, aber nicht als Anzeige sondern als RS232
> Ersatz.

Dann schau dir mal das hier an:
http://idle-logic.com/2014/07/12/virtual-com-port-connection-de0-nano-vj-uart/
und das hier:
http://idlelogiclabs.com/2012/04/15/talking-to-the-de0-nano-using-the-virtual-jtag-interface/

[Markus F. (mfro)]

Das hier dürfte geeigneter/einfacher sein:

https://github.com/thotypous/alterajtaguart

(im "software") Verzeichnis. Einfach die Altera-C++-Libraries linken, 
das war's.

[Hfg (Gast)]

Funktioniert bei mir bis Quartus 17.1. Ab Quartus 18.0 bekomme ich als 
Error 'Selected UART is not compatible with this version of the 
library'. Weiss jemand warum ?

[Markus F. (mfro)]

Hfg schrieb:
> Funktioniert bei mir bis Quartus 17.1. Ab Quartus 18.0 bekomme ich
> als
> Error 'Selected UART is not compatible with this version of the
> library'. Weiss jemand warum ?

Wo/wann kommt die Meldung?

Wurde gegen die .DLL/.so der entsprechenden Quartus-Version gelinkt?

[Markus F. (mfro)]

FPGA zum Spass schrieb im Beitrag #5816492:
> Ich würde das gerne nutzen, aber nicht als Anzeige sondern als RS232
> Ersatz.

wenn Du nur ein Terminal brauchst, kannst Du das nios2-terminal direkt 
nutzen (dazu muss kein NIOS auf dem Chip sein).

[FPGA zum Spass (Gast)]

Nein, kein Terminal, echten Datentransfer mit höheren Datenraten als 
RS232 aus eigener Applikation heraus.

Hat sich aber erledigt, nutze jetzt ein FTDI PMOD mit 3 fliegenden 
Drähten auf Stiftleiste verbunden(TX/RX/GND).
Für ~10€ bekomme ich so echte ~250Kbyte/s bei Blocktransfers mit 
geringstmöglichem Programmieraufwand.

[-gb- (Gast)]

Der FT232RL kann 3MBaud, das kommen die 250kByte/s schon gut hin. Der 
FT(2)232H kann 12MBaud, da bekommt man über ein MByte/s hin mit einem 
normalen UART.

[FPGA zum Spass (Gast)]

Der FT232h kann 480 Mbit/s, allerdings wird das mit fliegenden Drähten 
sicherlich schwierig, außerdem wirst du das nicht gemeint haben.

Über die JTAG Leitung lassen sich theoretisch 12Mbit erreichen bei dem 
USB-Blaster.
Praktisch habe ich das aber noch nicht gesehen.
Auch das Demo Tool von Terasic, was beim DE2-115 dabei ist, erreicht das 
nichtmal im Ansatz.

Das Demo-Github Projekt hat leider genau bei hohen Datenraten offene 
Probleme.

Hat denn mal jemand tatsächlich solche Datenraten damit erreicht?
Wenn ja wechsle ich liebend gerne.

[Markus F. (mfro)]

FPGA zum Spass schrieb im Beitrag #5937599:
> Hat denn mal jemand tatsächlich solche Datenraten damit erreicht?
> Wenn ja wechsle ich liebend gerne.

Etwa 1 MB/s (MAX 10 mit USB-Blaster auf dem Board) sind drin, wenn ich 
mich nicht verrechnet habe. Das verlinkte github-Projekt scheint sich 
mit den Handshake-Signalen bei hohen Datenraten irgendwie zu verheddern, 
das ist mir mit meinem eigenen Code noch nicht passiert: 
https://github.com/mfro0/jtag_terminal

[-gb- (Gast)]

Ja der FT(2)232H kann volles USB 2, aber wenn man den nur als UART 
verwendet, dann kann er 12MBit/s.

[FPGA zum Spass (Gast)]

Markus F. schrieb:
> Etwa 1 MB/s (MAX 10 mit USB-Blaster auf dem Board) sind drin, wenn ich
> mich nicht verrechnet habe...das ist mir mit meinem eigenen Code noch nicht 
passiert:
> https://github.com/mfro0/jtag_terminal

Du nutzt aber auch keine hohen Datenraten, oder?

Ich glaub, ich werds dann doch mal selbst probieren müssen was man 
rausholen kann.

Wenn ich 200Kbyte/s erreiche würde ich schon nutzen, dann brauch ich das 
frei fliegende PMOD nicht mehr....auch wenn ich ungern damit von Altera 
abhängig werde.

[Markus F. (mfro)]

FPGA zum Spass schrieb im Beitrag #5938474:
> Du nutzt aber auch keine hohen Datenraten, oder?

ich hab's nur einmal mit einem kleinen Testprogramm den Durchsatz 
gemessen und kam dabei - wenn ich mich nicht täusche - wie oben 
beschrieben auf etwa 1 MB/s.

Das Programm ist auch auf github.

[FPGA zum Spass (Gast)]

Kannst du mir bitte mal verraten was das für ein Protokoll sein soll?

Ich habe jetzt einfach mal nur den rx_data Port mit 8 LEDs verbunden, 
weil ich davon ausgegangen bin das bei "character" 8 Bits pro 
Lesezugriff rauskommen.

Ergebnis:

Wenn ich mit dieser Schleife jedes mögliche Byte runter schreibe, dann 
kommt ab und zu mal 1 an und meistens 0.
Hä?


Allgemein, das man nichtmal zum alt_jtag_atlantic Doku findet...
Kann ich überhaupt 100 Mhz als clk benutzen?
Darf man, so wie du das machst wirklich dauerhaft rx_data_req auf 1 
lassen bis etwas kommt?

while (true)
{
   for (int i = 0; i < 255; i++)
   {
      char* sendbytes = new char[1];
      sendbytes[0] = i;
      jtagatlantic_write(atlantic, sendbytes, 1);
   }
}

[Markus F. (mfro)]

FPGA zum Spass schrieb im Beitrag #5939103:
> Kann ich überhaupt 100 Mhz als clk benutzen?

ich denke, man kann.

> Darf man, so wie du das machst wirklich dauerhaft rx_data_req auf 1
> lassen bis etwas kommt?
> while (true)
> {
>    for (int i = 0; i < 255; i++)
>    {
>       char* sendbytes = new char[1];
>       sendbytes[0] = i;
>       jtagatlantic_write(atlantic, sendbytes, 1);
>    }
> }

ich denke, das kann so nicht wirklich funktionieren, ohne den Empfänger 
bzw. den Sendepuffer zu überfahren.

Du solltest den Rückgabewert von jtagatlantic_write() abfragen und wenn 
der 0 oder -1 ist, nochmal versuchen, zu senden.

Jedenfalls sehe ich keine andere Möglichkeit zu ermitteln, ob die andere 
Seite empfangsbereit ist/war.

[FPGA zum Spass (Gast)]

ich lasse das im Einzelschritt im Debugger laufen, 1 Byte alle paar 
Sekunden, im FPGA wird dauerhaft versucht zu lesen, genau wie in deinem 
jtag_terminal_cy3.vhd

Sehe nicht wie es da überfahren könnte....

Den Rückkanal bekomme ich auch nichts ans laufen, da ist nie ein Byte 
drinne.

Keine Ahnung woran das liegt...
- vielleicht an meinem Board(DE2-115 mit Cyclone 4)
- vileleicht daran, das ich auf Windows mit Quartus 11 arbeite
- vielleicht daran, das ich  mir die jtag_atlantic.lib aus der .dll 
selbst erzeugen musste

Das einzige was aktuell geht ist das jtagatlantic_open, was nur dann 
nicht null zurückliefert wenn im FPGA tatsächlich der Core drin ist.

[Markus F. (mfro)]

FPGA zum Spass schrieb im Beitrag #5939209:
> ich lasse das im Einzelschritt im Debugger laufen, 1 Byte alle
> paar
> Sekunden, im FPGA wird dauerhaft versucht zu lesen, genau wie in deinem
> jtag_terminal_cy3.vhd
>
> Sehe nicht wie es da überfahren könnte....
>
Das war in deinem Post nicht erkennbar.

> Den Rückkanal bekomme ich auch nichts ans laufen, da ist nie ein Byte
> drinne.
>
Du tust aber schon was rein, oder?


> - vileleicht daran, das ich auf Windows mit Quartus 11 arbeite
> - vielleicht daran, das ich  mir die jtag_atlantic.lib aus der .dll

Keine Ahnung. Ich selbst habe (Linux) Quartus 13.0, 13.1 und 18.1 
erfolgreich getestet. Funktioniert das nios2-terminal (das dieselbe 
Funktionalität verwendet) bei dir bzw. gibt's das in der 11 überhaupt 
schon?

[FPGA zum Spass (Gast)]

Naja, das Terasic Demo Tool was beim Board dabei ist läuft über die 
Schnittstelle.
Das verwendet allerdings andere DLLs.

Markus F. schrieb:
> Funktioniert das nios2-terminal

Weiß ich nicht, kenne ich nicht.


Markus F. schrieb:
> Du tust aber schon was rein, oder?

Ja, wobei vielleicht zu schnell, immer wenn IDLE = '1'. Selbst wenn das 
zu schnell ist, dann sollte aber zumindest mehr wie Garnichts ankommen.

Ich probiere jetzt mal noch exakt dein Design für das DE2-115 
umzusetzen. Wenns auch nicht geht lad ichs als zip hoch, vielleicht 
sieht ja jemand was.

[FPGA zum Spass (Gast)]

So, habs jetzt nochmal mit dem Loopback aus jtag_terminal_cy3 probiert.

Bei "ret" im C++ Testprogramm kommt immer eine 0 zurück.

Siehst du einen Fehler?

[Markus F. (mfro)]

Nicht beim eben mal drübergucken - sieht aus wie das, was bei mir 
funktioniert.

Möglicherweise ist dein Quartus (jtag libs) tatsächlich zu alt?

Hast Du mal in die Release Notes der Folgeversionen reingeschaut, ob da 
die Behebung eines jtag-Fehlers beschrieben ist?

[Edi M. (Gast)]

FPGA zum Spass schrieb im Beitrag #5939494:
> So, habs jetzt nochmal mit dem Loopback aus jtag_terminal_cy3 probiert.

In Deinem Code lese ich was von "JTAGATLANTIC". Dieses Atlantic ist m.W. 
der allererste Bus den Altera in einem SOPC verwendet hat.

Warum lese ich erst heute von solchen Ausgabeoptionen?

[FPGA zum Spass (Gast)]

Wollte mich erstmal für die schroffen Antworten gestern entschuldigen.
War etwas genervt, weil so etwas scheinbar einfaches soviele Probleme 
macht.

Schade das du auch nichts siehst, hatte noch die Hoffnung das ich 
irgendwo zu blind war.

Ich bin mir aber sicher das dein Code funktioniert, das tut er 
schließlich auch bei Anderen, also liegt der Fehler bei mir oder 
Quartus11 oder Windows oder was auch immer.

Wäre ich noch auf dem alten, lahmen rs232, dann wäre mein Druck groß 
genug jetzt weiter zu forschen, aber so werde ich hier aufgeben. Es 
bleibt leider im Hobby nicht unendlich viel Zeit.

Trotzdem danke für die Hilfe. Sollte ich es mal irgendwann es schaffen 
auf Linux zu wechseln, dann probiere ich es noch einmal. Sollte anhand 
der verfügbaren Quellen ja dann wenig Aufwand sein.

[Hfg (Gast)]

Hallo,

ich hatte gestern Zeit um nochmals an dem Problem mit Q18.x 
weiterzuarbeiten.

Der Fehler der von der libjtagatlanic.dll zurkommt ist

"No UART matching the specified device/instance" und nicht der in meinem 
früheren Betrag erwähnte (Falsche Dekodierung Zahl => Ausgabe).


Aus Experimenten mit dem Core habe ich festgestellt, dass ab der Q18.x 
das Generic SLD_AUTO_INSTANCE_INDEX anscheinend keine Verwendung mehr 
hat bzw. immmer SLD_AUTO_INSTANCE_INDEX="YES" angenommen wird.

Ich hatte meinen Core mit SLD_AUTO_INSTANCE_INDEX="NO" und 
INSTANCE_ID=253
parametrisiert. Unter Q<=17.x hat das problemlos funktioniert. Sprich 
ich konnte mit dem Index 253 bei der Funktion jtagatlantic_open(0, -1, 
253) arbeiten.

Wie schon erwähnt funktioniert das bei Q18.x nicht mehr und ich muss 0 
verwenden. Füge ich noch z.B. einen jtag_uart Core hinzu (verwendet 
intern auch ein alt_jtag_atlantic Core), hat dieser den Index 1.

Q18 scheint einfach den Index um 1 zu erhöhen, sobald ein File mit eine 
Core in der Synthes verarbeitet wird.

Ich kann mich erinnern, das Quartus X in einem Report gezeigt wie die 
Kodierung ist. Finde das aber bei Q18.x nicht.

[Markus F. (mfro)]

Ehrlich gesagt habe ich nie probiert, einen JTAG UART mit einem 
speziellen Index zu erzeugen.

In der 18.1-Dokumentation (z.B. bei altsource_probe, das ja 
wahrscheinlich denselben Mechanismus verwendet) ist 
SLD_AUTO_INSTANCE_INDEX allerdings noch dokumentiert. Dort steht auch, 
dass das ignoriert (und stattdessen ein fortlaufender Index vergeben) 
würde, wenn es jenen schon im Design gibt.

Kann es sein, dass das bei dir der Fall ist?

Für die 18.1 (die ich übrigens - was die Qualität angeht - nicht 
unbedingt für Intel's Glanzstück halte) gibt es mittlerweile einen 
ziemlich dicken Patch - hast Du den installiert?

[HFG (Gast)]

Den von Dir in der Doku gefundenen Hinweis beschreibt gerade mein 
Verhalten. Danke !
Ich habe den aktuellsten Patch installiert, das Verhalten ist laut 
deinem Hinweis korrekt.

Blöd ist, dass der meiner Meinung nach hilfreiche Core in keiner Doku 
offizeiell erwähnt wird.Sonsr wäre mir das veilleicht selbst 
aufgefallen.