Interne Tristate Signale entfernen

[Sebastian (Gast)]

Hallo zusammen,

ich bin relativ neu in der FPGA Programmierung (komme aus der C Welt) 
und stehe vor folgendem Problem. Das Design soll mit Quartus auf einem 
Cyclone10 synthetisiert werden, ich glaube das ist nebensächlich.

Ich habe ein Modul (nicht Toplevel) mit einem Tristate Signal:

assign b = en ? a : 1'bZ;

b wurde dann auf einen externen Pin belegt, und alles war in Ordnung, 
weil Tristate-Buffer an den Pins existieren. Jetzt möchte ich b auch 
noch intern in einem anderen Modul verwenden, und die Probleme gehen 
los.

always (@posedge clk) begin
[...]
  reg_b <= b;
[...]
end

Hier beschwert sich Quartus zu recht, dass es keine internen 
Tristate-Buffer gibt. Es ist allerdings "nur" eine Warnung, der Tristate 
sei durch ein OR-Gate ersetzt worden. Damit bin ich prinzipiell 
zufrieden; gibt es eine Möglichkeit diesen "Cast" explizit zu machen, 
damit die hässliche Warnung verschwindet?

Ich dachte außerdem ich könnte das Problem so beheben:

reg b_clean;
always begin
case (b) 
 1'b0: b_clean <= 1'b0;
 default: b_clean <= 1'b1;
caseend
end

und dann

 reg_b <= b_clean;

. Die Warnung bleibt jedoch bestehen, obwohl der Synthetisierer damit 
theoretisch in der Lage sein sollte (glaube ich zumindest) das 'Z' 
rauszuoptimieren. Gibt es hier einen besseren Trick?

Danke für eure Hilfe.

[Gustl B. (-gb-)]

Eine einfache Lösung wäre doch en und b ins Toplevel zu ziehen.

[Gerhard H. (ghf)]

Hi,
Warum weist du dann überhaupt 'z' zu? Du könntest genauso gut '0'
oder 'don't care' nehmen, dann hättest du an der Stelle wo das
weiterverarbeitet wird immer einen zumindest elektrisch gültigen Pegel.

Bei 'z' ist das allenfalls mit einem Pull Up/down gegeben. Vor
allem, wenn Teile des Enables von aussen kommen ist das ein
warn-würdiger Zustand.

Und I/O-Pins sind kostbar. Teile von untergeordneter Logik aus
irgendeiner $(EGAL)-Ecke in die Design-Root zu ziehen macht die
ganze Ordnung im Chip kaputt. Man kann nicht mal mehr Teile des
Designs getrennt compilieren & debuggen. Da ist die lokale
Multiplexer-Orgie die sich ergibt immer noch besser als ein
TriState-Bus.

Gruß, Gerhard


(der sich jetzt wieder der Frage zuwendet warum sein SNA33-
Spektrumanalyzer nur noch manchmal funktioniert.  Arrrghh! )

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

Sebastian schrieb:
> gibt es eine Möglichkeit diesen "Cast" explizit zu machen, damit die
> hässliche Warnung verschwindet?
Ja: du musst das Modul explizit so umschreiben, dass es an den Ports 
keine Tristate-Signale verwendet...  ;-)

[Sebastian (Gast)]

Hallo,

vielen Dank für eure Antworten.

Gerhard H. schrieb:
> Warum weist du dann überhaupt 'z' zu? Du könntest genauso gut '0'
> oder 'don't care' nehmen, dann hättest du an der Stelle wo das
> weiterverarbeitet wird immer einen zumindest elektrisch gültigen Pegel.
Lothar M. schrieb:
> Ja: du musst das Modul explizit so umschreiben, dass es an den Ports
> keine Tristate-Signale verwendet...  ;-)
Am externen Pin brauche ich auf jeden Fall ein Tristate Signal. Bei 
meiner Anwendung hantiere ich mit SPI-Signalen. Der MISO muss hier auf 
jeden Fall hochohmig sein wenn der CS nicht gezogen ist, da ein anderer 
SPI Slave die Leitung womöglich treibt.

Mein Code ist momentan ganz gut strukturiert. Ich dachte das könnte ich 
so beibehalten. Ein zweites MISO-Signal für interne Verwendung zu bauen 
(das nicht tristatet) wäre natürlich möglich, ist aber natürlich auch 
eine Redundanz die mir meiner Meinung nach Struktur kaputt macht.

Viele Grüße
Sebastian

[Christoph Z. (christophz)]

Es ist ganz üblich bzw. von den Tools so gefordert, dass alles was mit 
den physikalischen Eigenschaften von I/O Pins zu tun hat im Top Level 
behandelt wird. So wie dein Tri-state oder auch differenzielle 
Ein-/Ausgänge.

In deinem Fall würde ich jetzt aus dem SPI-Slave Modul zwei Signale zum 
Top Level führen: MISO und MISO Enable.

Im Top Level nutzt du dann MISO Enable um den Pin auf tri-state zu legen 
oder eben auf MISO. Dass passt dann zu den FPGA Architekturen und lässt 
sich so direkt in andere Tools portieren.

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

Sebastian schrieb:
> Bei meiner Anwendung hantiere ich mit SPI-Signalen. Der MISO muss hier
> auf jeden Fall hochohmig sein wenn der CS nicht gezogen ist, da ein
> anderer SPI Slave die Leitung womöglich treibt.
Aber du wirst doch intern im FPGA nicht mit SPI zwischen Modulen 
kommunizieren wollen?

[Duke Scarring (Gast)]

Lothar M. schrieb:
> Aber du wirst doch intern im FPGA nicht mit SPI zwischen Modulen
> kommunizieren wollen?
Warum nicht?
Das habe ich auch schon gemacht. Zwar nicht direkt Master/Slave, aber 
eine Art Adressmultiplexer, der verschiedene Sub-SPI-Slaves an die 
externe Schnittstelle legt.

[Sebastian (Gast)]

Christoph Z. schrieb:
> In deinem Fall würde ich jetzt aus dem SPI-Slave Modul zwei Signale zum
> Top Level führen: MISO und MISO Enable.
Hallo Christoph. Das scheint mir ein guter Kompromiss. Danke für den 
Tipp.

Lothar M. schrieb:
> Aber du wirst doch intern im FPGA nicht mit SPI zwischen Modulen
> kommunizieren wollen?
Nein, das mache ich nicht. Ich route aber SPI-Signale einmal durch den 
FPGA; sprich der Slave sitzt auf der einen Seite, der Master auf der 
anderen, und das FPGA dazwischen. Der Sinn dahinter ist ein 
SPI-Multiplexing betreiben zu können, bei dem ich zwischen Mastern 
umschalten kann.

Viele Grüße
Sebastian

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

Sebastian schrieb:
> Der Sinn dahinter ist ein SPI-Multiplexing betreiben zu können, bei dem
> ich zwischen Mastern umschalten kann.
Ok, wenn man den Singlemasterbus zum Multimasterbus umbiegen will, dann 
braucht es natürlich besondere Maßnahmen.
Ich würde aber wie christophz den dafür nötigen Busmultiplexer ganz oben 
im Top-Level abhandeln und nach innen statt mit ternären 
Tristatesignalen ausschließlich mit binären 01-Signalen arbeiten.

[J. S. (engineer)]

Sebastian schrieb:
> Hier beschwert sich Quartus zu recht, dass es keine internen
> Tristate-Buffer gibt.

Die einfachste Möglichkeit, solche Probleme zu umgehen, ist erst gar 
nicht zu falschen Beschreibungen zu greifen. Interne Tristatesignale 
sind immer die Folge von Beschreibungsdefiziten, weil jemand Physik 
nicht von Logik trennen will oder kann und beider vermengt.

Tristate-Buffer gehören ausnahmslos auf das Toplevel, weil sie die 
Anbindung der Logik an die Elektronik leisten (und damit auch 
FPGA-spezifisch sind).