... 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:
1
libraryieee;
2
useieee.std_logic_1164.all;
3
useieee.numeric_std.all;
4
5
entityjtag_uartis
6
generic
7
(
8
LOG2_RXFIFO_DEPTH:natural;
9
LOG2_TXFIFO_DEPTH:natural
10
);
11
port
12
(
13
clk:instd_ulogic;
14
reset_n:instd_ulogic;
15
16
rx_data:outcharacter;-- received data
17
rx_ready:outstd_ulogic;-- received data valid
18
rx_data_req:instd_ulogic;-- ask for data
19
rx_paused:outstd_ulogic;-- receive paused
20
21
tx_data:incharacter;-- data to send
22
tx_start:instd_ulogic;-- start sending data
23
tx_idle:outstd_ulogic-- we are not busy sending
24
);
25
endentityjtag_uart;
26
27
architecturertlofjtag_uartis
28
componentalt_jtag_atlantic
29
generic
30
(
31
INSTANCE_ID:integer:=0;
32
LOG2_RXFIFO_DEPTH:integer:=0;
33
LOG2_TXFIFO_DEPTH:integer:=0;
34
SLD_AUTO_INSTANCE_INDEX:string:="YES"
35
);
36
port
37
(
38
clk:instd_ulogic;
39
rst_n:instd_ulogic;
40
41
r_dat:incharacter;-- data to send
42
r_val:instd_ulogic;-- data is valid
43
r_ena:outstd_ulogic;-- allow to send data
44
45
t_dat:outcharacter;-- incoming data
46
t_dav:instd_ulogic;-- give us more data
47
t_ena:outstd_ulogic;-- received data available
48
t_pause:outstd_ulogic
49
);
50
endcomponentalt_jtag_atlantic;
51
52
begin
53
i_jtag_uart:componentalt_jtag_atlantic
54
genericmap
55
(
56
INSTANCE_ID=>0,
57
LOG2_RXFIFO_DEPTH=>LOG2_RXFIFO_DEPTH,
58
LOG2_TXFIFO_DEPTH=>LOG2_TXFIFO_DEPTH,
59
SLD_AUTO_INSTANCE_INDEX=>"YES"
60
)
61
portmap
62
(
63
clk=>clk,
64
rst_n=>reset_n,
65
66
-- alt_jtag_atlantic ports have _very_ strange (backwards) names...
67
68
-- this is the receiving part of alt_jtag_atlantic, the ports
69
-- we actually *send* data to
70
r_dat=>tx_data,
71
r_val=>tx_start,
72
r_ena=>tx_idle,
73
74
-- this is the sending part of alt_jtag_atlantic, i.e. the ports
75
-- we receive data from
76
t_dat=>rx_data,
77
t_dav=>rx_data_req,
78
t_ena=>rx_ready,
79
t_pause=>rx_paused
80
);
81
endarchitecturertl;
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...
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.
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 ?
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?
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).
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.
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.
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.
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
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.
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.
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?
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.
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.
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?
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.
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?
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?
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?
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.
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.
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?
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.
