VHDL - Pin Assignments Verständnisfrage

[Martin S. (sirnails)]

Hallo miteinander,

ich probiere hier gerade mit meinem FPGA-Board herum und stelle mir nun 
die Frage, wie ich die PINs in VHDL ansprechen kann, und wie diese am 
sinnvollsten bezeichnet werden sollten.

Rein logisch ist ja ein Eingang entweder einer 0 oder 1, und damit 
einfach nur vom Typ "Bit". Wenn ich also schreibe (Syntax ist jetzt frei 
aus dem Gedächtnis, und nicht unbedingt richtig):

entity abc is
  Port(
    CLK  : in bit;
    EN   : in bit;
    LED     : out natural range 2 downto 0
  );
  
end abc;

dann stellen sich mir die Fragen:

a) Was nehme ich für LED. STD_LOGIC_VECTOR, NATURAL RANGE oder auch 
einfach nur BIT? Oder gar was ganz anderes?

b) Wie sieht es mit den Eingängen aus? Kann CLK auch ein STD_LOGIC sein? 
Wie wird hier differenziert, was wann genommen wird?

c) In den Pin Assignments ist LED[0] meinetwegen am FPGA-PIN 100, LED[1] 
an 101 usw. Wird dann automatisch auf diesen Ausgang gemappt? Ich hatte 
das so probiert, allerdings meckert er dann bei LED: "OUTPUT IS DRIVEN 
TO VCC". Also irgendwie mag er das nicht.

Kann mir das bitte einer halbwegs verständlich erklären? Vielen Dank :-)

[Christian R. (supachris)]

Nimm mal besser std_logic und std_logic_vector für Sachen, die nach 
außen gehen. Wo kriegt man eigentlich das Bit immer gelehrt?

Und nimm intern für alles, was rechnen soll, dann unsigned und signed, 
nimm keine alten Synopsis Libs, sondern ausschließlich die 
ieee.numeric_std.all

Für das Pin-Assignment brauchst du eine zur Architektur passende Datei, 
wo das drin steht. Wenn du Xilinx hast, eine UCF Datei. Infos dazu, wie 
die aussieht, findest du massig im netz oder hier in den Artikeln.

[Martin S. (sirnails)]

Christian R. schrieb:
> Nimm mal besser std_logic und std_logic_vector für Sachen, die nach
> außen gehen. Wo kriegt man eigentlich das Bit immer gelehrt?

Hmm ehrliche Antwort? Der Lehrer ist schuld.

> Und nimm intern für alles, was rechnen soll, dann unsigned und signed,
> nimm keine alten Synopsis Libs, sondern ausschließlich die
> ieee.numeric_std.all

Ist Natural Range denn nicht in der STD.all drinnen? Und worin liegt 
jetzt der Unterscheid zwischen Natural Range und std_logic_vector?

> Für das Pin-Assignment brauchst du eine zur Architektur passende Datei,
> wo das drin steht. Wenn du Xilinx hast, eine UCF Datei. Infos dazu, wie
> die aussieht, findest du massig im netz oder hier in den Artikeln.

Das habe ich mir fast gedacht. Nur wie spreche ich das in VHDL an? 
Quartus kennt ja nur den PIN-Namen. Wenn ich ein Schematics aufmache, 
und irgendeine Leitung wie einen bekannten Pin nenne, wird automatisch 
auf diesen Pin geleitet. Wenn ich das in VHDL versuche, kommt der mit 
seinem "STUCK TO Vcc", obwohl "Unused pins as tri-stated" eingeschaltet 
ist.

[Christian R. (supachris)]

Wieso willst du das unbedingt in dem VHDL File machen? Das gehört 
logisch gesehen da nicht rein. Es geht zwar (je nach Toolchain), ist 
meiner Meinung nach aber unsauber. Wie das bei Quartus geht, weiß ich 
nicht. Normalerweise haben die externen Singnale sinnvolle Namen (am 
besten die Namen der Netze im Schltplan) und dann wird das über eine 
extra Datei den FPGA Pins/Balls zugewiesen.

[M. Schwaikert (Gast)]

Christian R. schrieb:
> Wieso willst du das unbedingt in dem VHDL File machen?

Hmm.. Weil ich nicht weiß, wie das besser geht.

Ich versuche die Logik dahinter zu verstehen. In erster Linie habe ich 
innerhalb meiner VHDL meine Leitungen willkürlich benannt. Dem Compiler 
ist es ja eigentlich egal, wie ich meine Leitungen nenne. Beim Mapping 
macht er eh draus, was er will.

Mich interessiert, wie jetzt die Schnittstelle Interne Logik -> externe 
Ausgänge zu handhaben ist.

Daher meine Frage mit LED. Wenn ich meine "externe Datei" mit der 
Pinbelegung des entsprechenden FPGA importiere, so ist LED dort als 
fester Name einer Reihe von PINs fest zugeordnet.

Spreche ich dann in VHDL eben diesen Port an, wenn ich

entity abc is
  Port(
    LED     : out std_logic_vector 2 downto 0
  );
  
end abc;

schreibe?

> Das gehört
> logisch gesehen da nicht rein. Es geht zwar (je nach Toolchain), ist
> meiner Meinung nach aber unsauber. Wie das bei Quartus geht, weiß ich
> nicht. Normalerweise haben die externen Singnale sinnvolle Namen (am
> besten die Namen der Netze im Schltplan) und dann wird das über eine
> extra Datei den FPGA Pins/Balls zugewiesen.

Hmm... leider nicht so wirklich. Im Datenblatt des UP3-Boards wird nur 
von LED gesprochen, ein Mäusepiano heißt "KEY3.1" bis "KEY3.4". Als ich 
versucht habe, dem ganzen andere Namen zu geben, hat der Fitter den 
Dienst verweigert, da er die Namen nicht kannte. Quartus ist da manchmal 
eine regelrechte Krankheit.

[Marius W. (mw1987)]

Christian R. schrieb:
> Wo kriegt man eigentlich das Bit immer gelehrt?

Das Reichardt/Schwarz-Buch "VHDL Synthese" nutzt "bit" relativ häufig. 
Ich habs bis heute nicht verstanden, warum immer bit statt std_logic. 
Angeblich wäre das für den Anfänger einfacher...

MfG
Marius

[Christian R. (supachris)]

M. Schwaikert schrieb:
> Mich interessiert, wie jetzt die Schnittstelle Interne Logik -> externe
> Ausgänge zu handhaben ist.

Das regelt eine spezielle Steuerdatei, je nach Toolchain. Meistens kann 
man das auch mit einer GUI festlegen. Wie das für dein Quartus geht, 
steht doch in dem Manual aus dem Link in deinem anderen Thread: 
http://www.slscorp.com/UP3Support/pages/documents.php d abei LEDs and 
PushButtons im PDF ist beschrieben, wie man die Signale aus dem TopLevel 
VHDL auf die verfügbaren Pins/Balls am FPGA bringt. Geht wohl da auch 
per GUI.

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

Marius Wensing schrieb:
> Ich habs bis heute nicht verstanden, warum immer bit statt std_logic.
Früher hieß es, das wäre schneller zu simulieren (weil nur 2-wertig 
statt 9-wertig). Das selbe gilt für die Verwendung von nicht aufgelösten 
Signalen (unresolved) std_ulogic: auch hier heißt es, die Simulation 
liefe schneller.
In der Praxis mag das vor 20 Jahren mal so gewesen sein, inzwischen sind 
die Simulator-Compiler aber gewohnt, mit std_logic umzugehen.

> Angeblich wäre das für den Anfänger einfacher...
Für einen Anfänger ist an sich alles gleich einfach. Wichtiger ist 
eigentlich, das zu lernen, was üblicher ist...

[M. Schwaikert (Gast)]

Christian R. schrieb:
> M. Schwaikert schrieb:
>> Mich interessiert, wie jetzt die Schnittstelle Interne Logik -> externe
>> Ausgänge zu handhaben ist.
>
> Das regelt eine spezielle Steuerdatei, je nach Toolchain. Meistens kann
> man das auch mit einer GUI festlegen. Wie das für dein Quartus geht,
> steht doch in dem Manual aus dem Link in deinem anderen Thread:
> http://www.slscorp.com/UP3Support/pages/documents.php d abei LEDs and
> PushButtons im PDF ist beschrieben, wie man die Signale aus dem TopLevel
> VHDL auf die verfügbaren Pins/Balls am FPGA bringt. Geht wohl da auch
> per GUI.

Ach ich Narr. Ich habe das total überlesen. Leider ist der Link im PDF 
mit der VHDL nicht mehr verfügbar. Aber ich denke, ich habe das soweit 
verstanden. In Quartus lässt sich also die Definition laden, oder 
manuell festlegen.

[M. Schwaikert (Gast)]

Ich habe einen kleinen Versuch gestartet:

library ieee;
use ieee.std_logic_1164.all;

entity testdevice is
  port(
    PBSwitch  :  in   std_logic_vector( 3 downto 0);
    LED_inv  :  out  natural range 3 downto 0;
    clk    :  in std_logic);
end testdevice;

architecture verhalten of testdevice is

  signal temp  : integer;

  begin
  
  testproc : process(clk)
      
    begin
      
      if (clk = '1' and clk'event) then
        if (PBSwitch(0) = '0') then
          if (temp = 15) then
            temp <= temp + 1;
          else
            temp <= 0;
          end if;
        end if;
      end if;
      
      LED_inv <= temp;
    
    end process testproc;
    
end verhalten;

1)
Nun gefällt mir das Natural Range als Ausgang nicht. Wenn ich allerdings 
als std_logic_vector (3 downto 0); deklariere, so darf ich LED_inv <= 
temp; nicht zuweisen. Wie geht das eleganter?

2) Er meckert, LED_inv[1] wäre "Stuck to ground". Warum nur diese eine, 
und nicht alle? Ich verstehe das nicht ganz?!

3) Wann nimmt man eigentlich buffer, variable und signal? Von variable 
weiß ich, dass die Änderung sofort übernommen wird, während signal erst 
zum Ende des Prozesses übernommen wird. Was ist dann mit Buffer? Wann 
sollte es wie eingesetzt werden?

Es wäre nett, wenn mir das noch jemand erklären könnte, damit ich 
endlich mal ein wenig Land sehe :-)

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

M. Schwaikert schrieb:
> Nun gefällt mir das Natural Range als Ausgang nicht.
Das ist schon mal ein ganz gutes Gefühl... ;-)

> so darf ich LED_inv <= temp; nicht zuweisen. Wie geht das eleganter?
Nimm die numeric_std und deren Konvertierungen und Casts:
http://www.lothar-miller.de/s9y/archives/14-Numeric_Std.html

> Wann nimmt man eigentlich buffer,
Gar nicht!
Das wäre ein rücklesbarer OUT-Port. Das ist unnötig. besser erzeugst du 
ein lokales Signal und weist dieses explizit an einer Stelle einem 
Ausgang zu.

> variable
Als Anfänger: gar nicht!
Als Fortgeschrittener: in Prozessen für lokale Zwischenergebnisse.
Und am besten niemals als Zähler.

> und signal?
Ein Signal ist der übliche Informationsträger in VHDL. Das kann eine 
Leitung sein oder auch ein Fliflop.

> Er meckert, LED_inv[1] wäre "Stuck to ground".
LED_inv hat nur 2 Bits. Damit lassen sich die Zahlen 0 bis 3 darstellen.

Und weil du das machst:
          if (temp = 15) then
            temp <= temp + 1;
          else
            temp <= 0;
          end if;
bleibt dein Zähler immer auf dem Defaultwert stehen. Denn das bedeutet 
ja: Wenn der Zähler 15 ist, dann zähle eins weiter. Ich würde dir mal 
das Thema Simulation ans Herz legen. Da wirst du dann gleich sehen, dass 
dein Zähler nicht vom Fleck kommt. Denn weil kein Init-Wert angegeben 
ist, hat das
signal temp  : integer;
beim Start der Simulation den Wert von −2147483647...  :-o

[M. Schwaikert (Gast)]

Lothar Miller schrieb:
> M. Schwaikert schrieb:
>> Nun gefällt mir das Natural Range als Ausgang nicht.
> Das ist schon mal ein ganz gutes Gefühl... ;-)

Hab ich fast befürchtet :-)

>> so darf ich LED_inv <= temp; nicht zuweisen. Wie geht das eleganter?
> Nimm die numeric_std und deren Konvertierungen und Casts:
> http://www.lothar-miller.de/s9y/archives/14-Numeric_Std.html

Ok. Dann führe ich mir das mal zu Gemüte.

>> Wann nimmt man eigentlich buffer,
> Gar nicht!
> Das wäre ein rücklesbarer OUT-Port. Das ist unnötig. besser erzeugst du
> ein lokales Signal und weist dieses explizit an einer Stelle einem
> Ausgang zu.

Ach stimmt. Irgend soetwas hatte unser Professor mal am Rande erwähnt.


>> und signal?
> Ein Signal ist der übliche Informationsträger in VHDL. Das kann eine
> Leitung sein oder auch ein Fliflop.


Damit kann ich auf jeden Falle schonmal einiges anfangen. Danke Lothar. 
Ich dachte eigentlich C++ wäre eine Krankheit, aber VHDL ist drauf und 
dran den ersten Platz zu stürmen :-)

Bzgl. des "hängenden" Pins hat Du aber auch keine Idee, oder? Manchmal 
haut Quartus wegen irgendwelcher ganz anderer Fehler komische Meldungen 
heraus. Dass muss nicht unbedingt immer nachvollziehbar sein.

[Valko Z. (hydravliska)]

Hallo,

@supachris

Ich dürfte die Vorlesung von Herr Reichardt besuchen. Das ganze "bit" 
Geschichte wurde eingesetzt, so dass alles vereinfacht wird.

Wenn man ganz am Anfang mit "X" (wie oft bei std_logic zu sehen ist wenn 
man nicht weiss was man tut) konfrontiert wird, ist es einfach schwer 
das ganze nachzuvollziehen.

Klar wird "bit" nicht in der Praxis eingesetzt aber als Lehrmittel finde 
ich es persönlich ganz gut.

Gruss,
Valentin

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

Valko S. schrieb:
> Das ganze "bit" Geschichte wurde eingesetzt, so dass
> alles vereinfacht wird.
Das sollte aber öfters mal wieder explizit angesprochen werden...

Valko S. schrieb:
> Wenn man ganz am Anfang mit "X" konfrontiert wird
Erst mal wird man mit einem 'U' konfrontiert...  ;-)
Und wenn man das sieht, dann weiß man sofort, dass da ein nicht 
initialisiertes speicherndes Signal unterwegs ist.
Mit einem 'X' wird man erst konfrontiert, wenn man das std_logic 
Signal aus 2 Quellen mit unterschiedlichem Pegel treibt. Bei einem bit 
Signal mit einer Multi-Source bleibt bereits der Compiler mit einem 
Fehler stehen. Mir scheint dieser "Vorteil" gering.

[Valko Z. (hydravliska)]

Hi,

@Lothar

ich verstehe was du meinst, leider tun das nicht alle die in eine 
Vorlesung sitzen :)

Für Leute, die kein Lust auf FPGAs usw. haben, ist mehr oder weniger 
egal was ein "bit" und was ein "std_logic" ist, hauptsache durch :) (das 
ist natürlich meine Meinung, ich will keiner schlecht machen oder so 
was).

Deswegen gab es auch Wahlpflichtfächer, wer Lust auf was komplexeres hat 
darf teilnehmen.

Gruss,
Valentin

[M. Schwaikert (Gast)]

Hallo Valentin,

genau aus diesem Grund habe ich auch das SWP belegt. Allerdings bin ich 
mit dem Informationsgehalt nicht sonderlich zufrieden. Viel lief á la 
"Macht mal bis es funktioniert" ab. Und so sollte es eigentlich nicht 
sein. So ergibt sich dann, dass man nicht einmal weiß, wie man std_logic 
auf ein unsigned oder integer castet. Ich bin auf viele Dinge erst durch 
eigene Experimente und Eure Hinweise aufmerksam geworden, und konnte 
verifizieren bzw. falsifizieren, weil ich ein Board herumliegen habe.

Das hat demnach auch weniger etwas mit Interesse zu tun. Viel hängt halt 
doch vom Professor ab.

[Valko Z. (hydravliska)]

Hi,

also von meinem Studium bin ich mehr als zufrieden.

Wir dürften ISE Webpack, EDK, SDK und auch SystemGenerator anwenden. 
Ausserdem hatten wir Zugang zum Virtex2 und Virtex5 Boards, so dass auch 
etwas komplexere Aufgaben erfüllt werden können.

Parallel zu der Vorlesung "Digitale Systeme" hatten wir "Digitale 
Signalverarbeitung auf Signalprozessoren" und es war oft die Rede wie 
sich die zwei Themen überlappen/unterscheiden.

Ich fand es sehr interessant so wie viele anderen.

Aber für alle anderen war die eigentliche Pflichtvorlesung mehr als 
verwirrend.

Edit: Wie du schon gesagt hast, es hängt viel von dem Professor ab. VHDL 
ist nur ein Mittel zum FPGA Entwicklung. Die FPGA Architekturen sind 
recht komplex und, meiner Meinung nach, ist es sehr schwer für sagen wir 
mal 8 Termine pro Semester(und wenn man Glück hat, 2 Semester im 
gesamten Studium) der FPGA Guru zu werden :-)

Gruss,
Valentin