Tri-state-Ports (inout) in VIVADO HLS

[Andreas N. (poolspieler)]

Hallo zusammen,
ich muss einen Tri-state Port unter VIVADO HLS implementieren.
Leider weiß ich nicht, wie ich diesen in SystemC beschreiben soll.

Das wäre ein Ausgang:
void main_bla(ap_uint<1> *ich_bin_ein_ausgang) { ... }

Das wäre ein Eingang:
void main_bla(ap_uint<1> ich_bin_ein_eingang) { ... }

Nur wie kann ich nun einen Tri-State-Port erzeugen?
Wäre super, wenn jemand eine Idee hätte.
Weder in der Doku, noch im Netz habe ich etwas sinnvolles gefunden.

Viele Grüße,

Poolspieler

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Hallo,

bidirektional Ports gibt es üblicherweise in RAM-Interfaces, µC-Port 
o.ä. Dort gibt es dann auch ein Schreib/Lese-Kommando/Leitung. Damit 
kann man dann die Richtung der Datenleitungen umdrehen. Nun überlege 
einmal, anhand welchen Signals HLS die Datenrichtung bestimmen soll.

Grundsätzlich habe ich den Eindruck, du weißt nicht, wofür HLS gedacht 
ist. Es dient nicht dazu, VHDL/Verilog grundsätzlich zu ersetzen. 
Sondern nur um numerische Algorithmen, welche man u.U. schon in C hat, 
auf einen FPGA zu bringen. Klassiker sind Video/Audio-Encoder oder 
Dekoder.

Kein erfahrener Entwickler wird auf die Idee kommen, ein Bus-IF, dass 
man wunderbar in VHDL/Verilog beschreiben kann, in C zu beschreiben.

Tom

[Andreas N. (poolspieler)]

Hallo Tom,
vielen Dank für Deine Antwort.

Aus meiner Sicht wirbt XILINX damit, dass HLS den workflow extrem 
beschleunigen soll. Und das tut es auch.
Ich habe im EDK 13.3 viele IPs für den PLB-Bus geschrieben (welche über 
das SDK angesteuert werden). Und das ist aus meiner Sicht richtig 
aufwendig. Man muss an sehr vielen Stellen Code hinzufügen, um die 
Anbindung an den PLB-Bus umzusetzen.

In HLS sind das nur wenige Zeilen (jetzt natürlich für den AXI-Bus).
Deshalb habe ich es mir "angetan" und versuche zu 100% auf HLS 
umzusteigen.
Bisher hat das auch sehr gut geklappt.
Leider habe ich nun das Problem mit den Bidirektionalen Ports.

Nun zu Deiner (fast richtigen) Anmerkung:
Woher soll HLS es wissen, ob es ein Ausgang, oder ein Eingang ist:

Möglichkeit1: in SystemC gibt es den Datentyp sc_inout. Dieser schaltet 
auf IN, wenn gelesen wird, oder auf OUT, wenn ausgegeben wird. 
https://www.doulos.com/knowhow/systemc/faq/
Bestimmt gibt es so etwas auch nicht Objektorientiert - leider habe ich 
bis jetzt nichts gefunden.

Möglichkeit2: in VHDL würde man für einen bidirektionalen Port drei 
variablen anlegen: mein_port_I, mein_port_O, mein_port_T
Von mein_port_I kann gelesen werden. Auf mein_port_O kann geschrieben 
werden. Und mein_port_T gibt die aktuelle Richtung des Ports an.
--> Und genau das hätte ich in HLS auch erwartet. Ich habe genau diese 
drei Variablen angelegt. Leider hängt HLS beim kompilieren im VHDL-Code 
ein _V an. Somit gibt es dann im generierten VHDL-Code die Ports 
mein_port_I_V, mein_port_O_V, mein_port_T_V. Und hier liegt wohl das 
Problem. Man müsste HLS lediglich mitteilen, dass es nicht das _V 
anhängen soll.
Nun könnte ich den generierten VHDL-Code anpassen. Doch dann wäre der 
Vorteil von HLS nicht mehr gegeben - und man könnte gleich alles in VHDL 
programmieren.



Viele Grüße,

Andreas

[Thomas R. (Firma: abaxor engineering) (abaxor)]

Hallo Andreas,

AXI und PLB sind interne Busse, da gibt es keine bidirektionalen Ports.

Andreas N. schrieb:
> öglichkeit1: in SystemC gibt es den Datentyp sc_inout. Dieser schaltet
> auf IN, wenn gelesen wird, oder auf OUT, wenn ausgegeben wird.

Lässt sich sc_inout synthetisieren?


> Möglichkeit2: in VHDL würde man für einen bidirektionalen Port drei
> variablen anlegen: mein_port_I, mein_port_O, mein_port_T
> Von mein_port_I kann gelesen werden. Auf mein_port_O kann geschrieben
> werden. Und mein_port_T gibt die aktuelle Richtung des Ports an.
> --> Und genau das hätte ich in HLS auch erwartet. Ich habe genau diese
> drei Variablen angelegt. Leider hängt HLS beim kompilieren im VHDL-Code
> ein _V an. Somit gibt es dann im generierten VHDL-Code die Ports
> mein_port_I_V, mein_port_O_V, mein_port_T_V. Und hier liegt wohl das
> Problem. Man müsste HLS lediglich mitteilen, dass es nicht das _V
> anhängen soll.
> Nun könnte ich den generierten VHDL-Code anpassen. Doch dann wäre der
> Vorteil von HLS nicht mehr gegeben - und man könnte gleich alles in VHDL
> programmieren.

Du könntest dir aber einen Wrapper schreiben, der das gewollte 
Namensschema wieder herstellt.

Tom

[Andreas N. (poolspieler)]

Thomas R. schrieb:
> Hallo Andreas,
>
> AXI und PLB sind interne Busse, da gibt es keine bidirektionalen Ports.

Hallo Tom,
da habe ich mich wohl ungünstig ausgedrückt.
Meine Custom-IP ist im EDK (über PLB) bzw. in VIVADO (über AXI) an den 
jeweiligen Datenbus angeschlossen.
Der MicroBlaze bzw. das Processing System (PS) im ZYNQ steuern dann die 
Custom-IP an. Diese hat dann die Logik (user logic) und die Ports zu 
externen Bausteinen (z.B. EEPROMs, ADCs, etc..

> Andreas N. schrieb:
>> öglichkeit1: in SystemC gibt es den Datentyp sc_inout. Dieser schaltet
>> auf IN, wenn gelesen wird, oder auf OUT, wenn ausgegeben wird.
>
> Lässt sich sc_inout synthetisieren?
Das habe ich nicht versucht, weil ich sonst SystemC tiefer anschauen 
müsste. Dies möchte ich möglichst vermeiden...

>> Möglichkeit2: in VHDL würde man für einen bidirektionalen Port drei
>> variablen anlegen: mein_port_I, mein_port_O, mein_port_T
>> Von mein_port_I kann gelesen werden. Auf mein_port_O kann geschrieben
>> werden. Und mein_port_T gibt die aktuelle Richtung des Ports an.
>> --> Und genau das hätte ich in HLS auch erwartet. Ich habe genau diese
>> drei Variablen angelegt. Leider hängt HLS beim kompilieren im VHDL-Code
>> ein _V an. Somit gibt es dann im generierten VHDL-Code die Ports
>> mein_port_I_V, mein_port_O_V, mein_port_T_V. Und hier liegt wohl das
>> Problem. Man müsste HLS lediglich mitteilen, dass es nicht das _V
>> anhängen soll.
>> Nun könnte ich den generierten VHDL-Code anpassen. Doch dann wäre der
>> Vorteil von HLS nicht mehr gegeben - und man könnte gleich alles in VHDL
>> programmieren.
>
> Du könntest dir aber einen Wrapper schreiben, der das gewollte
> Namensschema wieder herstellt.
Eventuell hast Du Recht - und ich muss diesen Weg gehen.
Ich werde damit experimentieren.
Wenn ich mehr weiß, dann melde ich mich wieder.

Viele Grüße,

Andreas