Forum: FPGA, VHDL & Co. IN OUT Buffer Syntheseprobleme


von Spartanischer (Gast)


Lesenswert?

Hallo,

das Problem ist schon gelöst, nur verstanden habe ich es nicht.
Ich wollte einen INOUT Buffer beschreiben und zwar wie folgt.
INOUT Pin : INOUTPIN


Das hier funktioniert:
1
GRM_INST : entity work.GRM port map (clk, SCK_SIG,DATA_OUT_SIG, INOUTPIN, DATA_OE_SIG ... );
2
INOUTPIN <= DATA_OUT_SIG when ( DATA_OE_SIG = '1' ) else ( 'Z' );

Das hier funktioniert nicht!
1
GRM_INST : entity work.GRM port map (clk, SCK_SIG,DATA_OUT_SIG, DATA_IN_SIG, DATA_OE_SIG ....);
2
-- buffer bi direktional
3
INOUTPIN <= DATA_OUT_SIG when ( DATA_OE_SIG = '1' ) else ( 'Z' );
4
DATA_IN_SIG <= INOUTPIN;

Fehler:

ERROR:ConstraintSystem:59 - Constraint <NET "INOUTPIN" LOC = R8;>
   [Toplevel_Lagegeber.ucf(5)]: NET "INOUTPIN" not found.  Please verify 
that:
   1. The specified design element actually exists in the original 
design.
   2. The specified object is spelled correctly in the constraint source 
file.

Ich hatte den Buffer erst in der eingebunden entity, dass hat gar nicht 
funktioniert. Begründung war, das interne Logik keine Tristatebuffer 
kennt. Warum kann Xilinxs das dann nicht verbinden, wenn nur Signale 
dazwischen sind?

Liebe Grüße und vielen Dank.

von Georg A. (georga)


Lesenswert?

> NET "INOUTPIN" not found.

Evtl. wurde das Signal bei Optimierungen zu DATA_IN_SIG oder in ganz was 
anonymes umbenannt. Kannst ja mal ohne Constraint und der ersten Methode 
nachschauen, mit welchem Namen es wirklich rauskommt...

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Wenn da Signale dazwischen sind, ist es technisch UNMÖGLICH das als 
INOUT zu bauen bzw adäquat zu formulieren. Wie soll das gehen? Man kann 
die IO-Struktur nur 100% nach oben weitergeben und das ist eben 
zumindest unschön.

Daher der Ratschlag: Funktionslogik von Physik trennen und die Buffer 
oben ausdrücklich beschreiben. Im Logikdesign dann nur eindeutige 
Signale mit Richtung. Ein Signal ist im Logikdesign keine Leitung, 
sondern ein Gleichheitszeichen bzw eine Quell-Zuweisung.

: Bearbeitet durch User
von Georg A. (georga)


Lesenswert?

> Wenn da Signale dazwischen sind, ist es technisch UNMÖGLICH das als
> INOUT zu bauen bzw adäquat zu formulieren.

Das ist aber wohl nicht das obige Problem ;) INOUT ist ja auch nur im 
Top-Level nach aussen, die Module haben IN, OUT und OE. Die Synthese 
lief ja beim zweiten Beispiel auch anstandslos durch. Nur der Router 
findet das Signal für den Pin nicht mehr unter dem gedachten Namen. Da 
hat sich xst vermutlich für den anderen entschieden.

von Spartanischer (Gast)


Lesenswert?

Jürgen Schuhmacher schrieb:
> Daher der Ratschlag: Funktionslogik von Physik trennen und die Buffer
> oben ausdrücklich beschreiben. Im Logikdesign dann nur eindeutige
> Signale mit Richtung. Ein Signal ist im Logikdesign keine Leitung,
> sondern ein Gleichheitszeichen bzw eine Quell-Zuweisung.

Kannst du bitte noch mal beschreiben, wie man das dann "schön" macht.

Komponente hat IN, OUT und OE
Die Toplevel hat einen INOUT Pin

@ Georg
wo kann ich das nachschauen?
bzw. wie würdest du das machen?

von Georg A. (georga)


Lesenswert?

> wo kann ich das nachschauen?

Das eine Constraint rausnehmen und schauen, wo ein unbekannter/neuer Pin 
entsteht ;) Das sollte prinzipiell auch schon im Map-Report bei den IOB 
Properties da stehen...

Ich vermute zumindest, dass es diese Marotte vom xst ist, die effektiven 
Signalnamen aufgrund irgendeiner Heuristik/Optimierung unerwartet 
umzubenennen. Nachdem man in den Constraints für Pins nur existierende 
Netze angeben kann, fällt das dann eben manchmal auf die Nase...

: Bearbeitet durch User
von berndl (Gast)


Lesenswert?

da wie ueblich mal wieder >99% der Beschreibung fehlen, moechte ich auch 
nicht allzuviel dazu sagen... Nur soviel: Du scheinst einen inout durch 
verschiedene Hierarchien zu verdrahten. Das ist auch ok solange da 'ein 
einfacher Draht' ist. Schau dir mal die IO-Zellen deines FPGA an und was 
passiert, wenn du den Pin Empfaenger/Treiber abschnorcheln willst...

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Spartanischer schrieb:
> Kannst du bitte noch mal beschreiben, wie man das dann "schön" macht.

Auf Toplevel Ebene einen Buffer-Kostrukt oder es per VHDL inferieren, 
indem man das Verhalten mit VHDL beschreibt:

if internal_oe = '1' then INOUTPORT <= "Z"; else internal_data_out;

internal_data_input <= INOUTPORT;

Dann hast Du innen zwei logische Signale und einen physischen Port, die 
auch namentlich bestehen und nicht wegoptimiert oder umbenannt werden. 
Die bidirektionalen Ports tief ins Logik-Design reinzuschleppen ist 
einfach nur kontraproduktiv, da man etwas beschreibt, was es praktisch 
nicht gibt. Die Zwischensignale MÜSSEN förmlich wegoptimiert werden, 
damit sinnvolle Physik entsteht, wodurch man sich nicht wundern darf, 
wenn dann Referenzen ins Leere gehen, weil die Synthese das nicht 
handhaben kann bzw einen Schmarrn zusammenbaut.

berndl schrieb:
> Das ist auch ok solange da 'ein
> einfacher Draht' ist.

Nein, das ist eben nicht ok. Ich kann Dir ein design zeigen, wo Altera 
Quartus den SRAM-Datenbus rausgeschmissen hat. Das Signal war im 
Toplevel korrekt verdrahtet und ging mittels Mentors HDL-Designer an ein 
Modul. Die Synthese hat es nicht kapiert. Wenn, müsste/könnte man die 
Signale dann als "buffer" deklarieren, ich bleibe aber dabei, dass das 
eine unsinnige Darstellung ist, weil in einem Logikdesign die Physik 
nichts zu suchen hat.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.