Hallo zusammen,
schon seit Stunden suche ich verzweifelt, wie man einen Pin in VHDL auf
ein Signal legt.
Das kann ja nicht so schwer sein, nur finde ich nichts und mein Buch
kommt erst nächste Woche.
Kann mir jemand helfen, wie ich das tue und welche LIB ich evtl.
einbinden muss.
Mal der erste Teil meines Testprogramms:
Steven () schrieb:> Dankeschön, aber ich dachte eher daran dem internen signal ein pin> zuzuweisen.
Such mal nach "Constraints File" und "Constraints Editor":
Beitrag "Constraint Files in Lattice"
"Constraints" bedeutet "Beschränkung", und genau das willst du tun: der
Toolchain keine freie Auswahl bei den Pins lassen, sondern die Auswahl
auf 1 Pin beschränken.
> attribute location of clockout : signal is "B1";
Mag sein, dass das ginge, es ist trotzdem eine Sackgasse, denn in eine
VHDL-Beschreibung gehört so wenig wie möglich Hardwareabhängigkeit.
Hallo Steven,
die Attribute heisst 'LOC' und nicht Location.
z.B.
Entity pcie_wb_01 is
Port (
i_refclkp : in std_logic;
i_refclkn : in std_logic;
i_rst_n : in std_logic;
i_hdinp0 : in std_logic;
i_hdinn0 : in std_logic;
o_dl_up : out std_logic;
o_hdoutp0 : out std_logic;
o_hdoutn0 : out std_logic;
o_phy_ltssm_state : out std_logic_vector(3 downto 0);
o_phy_ltssm_substate : out std_logic_vector(2 downto 0);
o_wb_cycle : out std_logic
);
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
attribute DRIVE : string; -- 20, 16, 12 (def.), 8, 4
attribute IO_TYPE : string; -- LVTTL33, LVCMOS33 etc.
attribute LOC : string;
attribute PULLMODE : string; -- UP, DOWN, NONE
attribute SLEWRATE : string; -- FAST, SLOW
attribute syn_keep : boolean;
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
attribute LOC of i_rst_n : signal is "E18";
attribute LOC of o_dl_up : signal is "U19";
attribute LOC of o_phy_ltssm_state : signal is "U18, AA21, Y20,
W19";
attribute LOC of o_phy_ltssm_substate : signal is "V19, AA20, AB20";
attribute LOC of o_wb_cycle : signal is "B12";
End pcie_wb_01;
Super, danke an alle!
Dann kenne ich ja die Möglichkeiten und den Tipp es in die LPF-File zu
schreiben.
Brauche ich für das LOC Attribute noch eine spezielle Include-File?
Und gibt es für die Befehle in der LPF-File auch eine Dokumentation?
Gruß Steven
Ulrich S. schrieb:> Lothar hat recht, die Pinbelegung hat in den VHD-Files nichts zu suchen> und gehört ins LPF-File!
So ein Blödsinn! Wie kommst du zu dieser Aussage? Falsche Farbe? Zu
viele Zeichen auf der Festplatte? Oder hast du doch etwas fundierteres
zu bieten?
VHDL Attribute sind sehr wohl dafür geeignet Information in eine HDL
Beschreibung zu plazieren, die von einem späteren Schritt in einem
Design Flow (z.B. Layout Tools etc) ausgewertet werden. Andere Tools
ignorieren diese Angaben einfach sofern sie nichts damit anfangen
können. Und es bleibt trotzdem syntaktisch korrekt. Man kann es als eine
einfache Objektbeschreibung des Komponenten betrachten, alles was zur
'Interface Beschreibung' gehört, ist somit in der Entity Datei.
Und noch schöner, User Defined Attributes sind auch erlaubt. Somit ist
das ganze Konzept je nach Bedarf bestens erweiterbar. Mit einem
einfachen Parser (oder Regexp) holt man die Info an geeigneter Stelle
wieder heraus. Ein grosser Vorteil gerade für automatisierte aber
trotzdem offene Design Flows.
cfgardiner schrieb:> So ein Blödsinn! Wie kommst du zu dieser Aussage? Falsche Farbe? Zu> viele Zeichen auf der Festplatte? Oder hast du doch etwas fundierteres> zu bieten?>> VHDL Attribute sind sehr wohl dafür geeignet Information in eine HDL> Beschreibung zu plazieren, die von einem späteren Schritt in einem> Design Flow (z.B. Layout Tools etc) ausgewertet werden. Andere Tools> ignorieren diese Angaben einfach sofern sie nichts damit anfangen> können. Und es bleibt trotzdem syntaktisch korrekt. Man kann es als eine> einfache Objektbeschreibung des Komponenten betrachten, alles was zur> 'Interface Beschreibung' gehört, ist somit in der Entity Datei.>> Und noch schöner, User Defined Attributes sind auch erlaubt. Somit ist> das ganze Konzept je nach Bedarf bestens erweiterbar. Mit einem> einfachen Parser (oder Regexp) holt man die Info an geeigneter Stelle> wieder heraus. Ein grosser Vorteil gerade für automatisierte aber> trotzdem offene Design Flows.
Super, und jetzt schreibst du einen VHDL Design, den du vlt. auf
mehreren Plattformen (verschiedene Chips eines Herstellers oder gar
verschiedene Hersteller) verwenden moechtest. Und du darfst dann alles
noch mal durchfilzen, nur weil du z.B. Pinbelegung in Attribute verpackt
hast. In einer eingeschraenkten Welt und damit auch Sichtweise mag das
ja sinnvoll sein... Aber wenn du Logik entwickelst und auch nur einen
Millimeter ueber den Tellerrand schaust, dann ist das kompletter
Bloedsinn!
Ich bin froh, dass ich meine Designs relativ leicht von einer Plattform
auf eine andere ueberfuehren kann. Und Attribute haben da leider keinen
Platz!
berndl schrieb:> Super, und jetzt schreibst du einen VHDL Design, den du vlt. auf> mehreren Plattformen (verschiedene Chips eines Herstellers oder gar> verschiedene Hersteller) verwenden moechtest.
Nun, dein hehres Ziel einer Technologie unabhängigen Beschreibung wird
zwangsläufig an zwei stellen (mindestens) scheitern. Nämlich ganz unten
wenn du z.B. Embedded RAM, IP-Cores, spezial Zellen usw. verwendest und
ganz oben wenn deine 100% Hersteller unabhängige VHDL Beschreibung auf
einem bestimmten FPGA/ASIC mit einer bestimmten Pinning zu einem Produkt
wird und nicht mehr nur eine Studie oder akademische Spielerei ist.
Genau an diesen Stellen haben VHDL Attributes ihre grosse Vorteile,
zumindest wenn der Design Process ein wiederholbarer Flow ist.
>Und du darfst dann alles> noch mal durchfilzen, nur weil du z.B. Pinbelegung in Attribute verpackt> hast.
Tja, man muss es halt nur richtig machen. Dann ist gar nicht so viel
'durchzufilzen'. Wenn ich den top-level von FPGA Technologie A nach
Technologie B portiere muss so oder so eine neue Pin Beschreibung her,
egal ob in einer constraint Datei oder angepasste top-level entity.
> In einer eingeschraenkten Welt und damit auch Sichtweise mag das> ja sinnvoll sein... Aber wenn du Logik entwickelst und auch nur einen> Millimeter ueber den Tellerrand schaust, dann ist das kompletter> Bloedsinn!
Nun würde mich deine Definition von 'eingeschraenkt' interessieren.
Endet vermutlich an den Rändern deines Badezimmerspiegels, alles was
versucht sich hier hineinzudrängen ist wohl suspekt. Constraint Dateien
sind meistens Tool/Hersteller spezifisch (z.B. von Synopsys/Synplify
übernommen, kopiert etc). Attribute sind eigentlich dazu gedacht genau
das Gegenteil zu sein. d.h. Informationen zu verpacken, die zwar durch
alle Design Instanzen durchgereicht werden, aber nur da ausgewertet
werden wo sie tatsächlich Bedeutung haben. Mit anderen Worten, tragen
Information, die eben ausserhalb des aktuellen Tellerrands von Interesse
sind. Und das Bezugsobjekt ist schlimmsten Falls mit etwas scrollen
sofort identifizerbar.
>> Ich bin froh, dass ich meine Designs relativ leicht von einer Plattform> auf eine andere ueberfuehren kann. Und Attribute haben da leider keinen> Platz!
Zwingt dich keiner dazu Attribute zu verwenden. Wenn du sie nicht
verstehst wäre es sogar besser die Finger davon zu lassen (die
kategorische Behauptung 'sie hätten keinen Platz' scheint diese
Vermutung zu unterstützen). Aber jetzt muss ich mich doch outen, ohne
Reue gebe ich zu, mindestens ein Design mit Constraint Dateien
(möglicherweise sogar ganz ohne Attributes) erfolgreich abgeschlossen zu
haben.
Ganz großes Kino!
Wie gut, das man sich an die Profis mit der großen Klappe hält.
Man könnte sich es auch einfach machen und im Diamond unter Tools das
Spredsheet-View aufmachen.
Das ist übersichtlich, einfach und komfortabel - vor allem funktioniert
es! ;)
Ulrich S. schrieb:> Man könnte sich es auch einfach machen und im Diamond unter Tools das> Spredsheet-View aufmachen.
Das wurde schon ganz weit oben aufgezeigt im
Beitrag "Re: VHDL Lattice Pin ansteuern"
BTW:
> Spredsheet
Meinst du das Spreadsheet?
Aber ich habe den Verdacht, es klemmt da noch ganz woanders...
Also von vorn:
Steven () schrieb:> ... welche LIB ich evtl. einbinden muss.> Mal der erste Teil meines Testprogramms:
Lib einbinden? Programm?
Vergiss diese Softwaredenkweise. Du machst Hardwarebeschreibung.
> nur finde ich nichts
Was und wonach suchst du denn?
> und mein Buch kommt erst nächste Woche.
Welches Buch denn? Erwartest du darin die Lösung des Problems?
> use ieee.std_logic_arith.all;> use ieee.std_logic_unsigned.all;
Siehe den Beitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete"
BTW:
Früher (tm) hat man bei einem Problem einfach mal eine Weile rumprobiert
und/oder die AppNotes/TechNotes der Hersteller gelesen.
Lothar Miller schrieb:> BTW:>> Spredsheet> Meinst du das Spreadsheet?
Ja.
Lothar Miller schrieb:> Aber ich habe den Verdacht, es klemmt da noch ganz woanders...
Er hätte wenigstens die Fehlermeldung posten können.
Danke schonmal an alle...
@cfgardiner
Also ich benutze zum Einstieg das Pico-Board mit dem MachXO2 (1200ZE)
im Anhang ein Screenshot mit Fehlermeldung
@Lothar Miller
Ja ok, dann "Code"
Was ist dann das hier: "library ieee;" ?
>Was und wonach suchst du denn?
Nach einem guten Einstieg, damit Du deine Nerven beruhigen kannst.
>Welches Buch denn? Erwartest du darin die Lösung des Problems?
Ja
Gruß Steven
Hi Steven,
ja, in deinem Code fehlt einfach die Zeile
attribute LOC : string;
Diese muss noch vor der folgenden Zeile erscheinen.
attribute LOC of clockout : signal is "B1";
Zum Verständnis, zuerst muss die Attribute definiert werden. 'LOC' ist
eine Anwenderdefinierte Attribute, theoretisch kann es vom beliebigen
VHDL Typ sein, hier eben 'string'. Dann, nachdem du der Typ deiner
Attribute definiert hast, kannst du eine Attributeninstanz mit enem VHDL
Objekt verbinden. Dieser schritt machst du z.B. mit
attribute LOC of clockout : signal is "B1";
Vielleicht noch eine nützlich Attribute, wenn du verhindern willst, dass
Pins nur deswegen wegoptimiert werden, weil dein Design noch nicht
fertig ist, kannst du folgende Zeilen verwenden:
attribute syn_keep : boolean;
attribute syn_keep of clkout : signal is true;
Steven () schrieb:>>Was und wonach suchst du denn?> Nach einem guten Einstieg
Der geht anders, du musst andere Fragen stellen. Wenn du nicht findest,
welche Lib man einbinden muss, um einen Pin "anzusteuern", dann
hauptsächlich deshalb, weil man eben keine Lib einbinden muss.
>>Welches Buch denn? Erwartest du darin die Lösung des Problems?> Ja
Das war die Antwort auf die zweite Frage. Und: du wirst die Antwort in
diesem Buch nicht finden... ;-)
cfgardiner schrieb:> ja, in deinem Code fehlt einfach die Zeile> attribute LOC : string;
Das alles (und noch viel mehr) findet man auf der ersten Seite, wenn man
mit Google nach den bisher gefallenen Begriffen sucht:
https://www.google.de/search?q=attribute+loc+lattice+diamond
Z.B. als Codebeispiel im Dokument
http://www.latticesemi.com/lit/docs/technotes/tn1091.pdf
unter Appendix A zusammen mit anderen Attributen (Pullup, Pulldown,
OpenDrain...)
Hi Steven,
noch etwas, schau dir bitte folgende *.csv Datei von der Lattice
Webseite an.
http://www.latticesemi.com/dynamic/view_document.cfm?document_id=39442
Bei MachXO2, sind Bezeichner wie B1 eben nur die Pin Koordinate. In
diesem Fall lautet der Bezeichner für die Pinbelegung "PL2A". Die
Bezeichner stehen in Spalte 'B (Pin/Ball Function)' in der o.g. Datei.
d.h. dein Entity sollte wie folgt ausschauen:
Library IEEE;
Use IEEE.std_logic_1164.all;
entity myClock is
port(
clockout: out std_logic );
attribute LOC : string;
attribute LOC of clockout : signal is "PL2A";
end myClock;
Wie du siehst, du brauchst nur die 1164'er Bibliothek. Ich würde auch
'std_logic' statt 'bit' als Typ von deinem Ausgangssignal verwenden. Bit
kann nur '0' oder '1' modellieren. std_logic dagegen kennt 9 Zustände
'0', '1', 'X' (undefined), 'U' (uninitialised), '-' (don't care), 'H'
(weak high e.g. pull up), 'L' (weak low e.g. Pull down), 'Z'
(tri-state), 'W' (weak undefined)
std_logic, std_logic_vector / std_ulogic, std_ulogic_vector erlauben
eben ein genaueres modellieren des möglichen Signalverhaltens.
danke @cfgardiner für die Tipps.
>Der geht anders, du musst andere Fragen stellen. Wenn du nicht findest,>welche Lib man einbinden muss, um einen Pin "anzusteuern", dann>hauptsächlich deshalb, weil man eben keine Lib einbinden muss.
Deswegen frag ich.
>Das war die Antwort auf die zweite Frage. Und: du wirst die Antwort in>diesem Buch nicht finden... ;-)
Gut das ich gefragt hab.
>Das alles (und noch viel mehr) findet man auf der ersten Seite, wenn man>mit Google nach den bisher gefallenen Begriffen sucht:
Danke!
Gruß Steven
cfgardiner schrieb:> Bei MachXO2, sind Bezeichner wie B1 eben nur die Pin Koordinate. In> diesem Fall lautet der Bezeichner für die Pinbelegung "PL2A". Die> Bezeichner stehen in Spalte 'B (Pin/Ball Function)' in der o.g. Datei.
Die Pinnummer, bzw Pinkoordinate ist ebenfalls erlaubt.
Beispiel aus dem Handbuch für den MachXO2:
1
--***Attribute Declaration***
2
ATTRIBUTELOC:string;
3
--*** LOC assignment for I/O Pin***
4
ATTRIBUTELOCOFinput_vector:SIGNALIS“E3,B3,C3“;
Das Handbuch enthält das Datenblatt und alle relevanten Technotes in
einer PDF.
Die 1. Maßnahme bei Unklarheiten sollte doch das Durchforschen der
Herstellerseite nach der Dokumentation sein.
Thread beobachten
Seitenaufteilung abschalten