Lattice - Clock definieren

Das wird ohne Code schwierig bis unmoeglich zu debuggen sein. Kannst du 
das Diamonad Projekt mal irgendwo hochladen, damit man mal einen Blick 
reinwerfen kann?

Hast du schonmal ein Diamond Projekt erfolgreich durchgezogen? Falls 
nein wuerde ich vll. erstmal mit einer Schritt fuer Schritt Anleitung 
anfangen und die gute alte "Hello World" LED zum blinken bringen.

Tobias B. schrieb:
> Kannst du
> das Diamonad Projekt mal irgendwo hochladen, damit man mal einen Blick
> reinwerfen kann?

Vielen Dank für dein Angebot.
Das Projekt ist angehängt.

Tobias B. schrieb:
> Hast du schonmal ein Diamond Projekt erfolgreich durchgezogen? Falls
> nein wuerde ich vll. erstmal mit einer Schritt fuer Schritt Anleitung
> anfangen und die gute alte "Hello World" LED zum blinken bringen.

Ja, hab bereits ein paar LEDs blinken lassen. Das hat funktioniert. Ich 
habe früher auch einige Projekte mit Quartus durchgeführt. Mir ist von 
daher der eigentliche Workflow bekannt.. Hab das KnowHow nun etwa 1 Jahr 
nicht gebraucht und starte nun mit einer mir (bis auf das LED-Beispiel) 
unbekannten IDE.

Bin über jede Hilfe dankbar.

EDIT: INFO -----

Der eingangs erwähnte Clock "CLK_A" ist in dieser Form nicht mehr in 
meinem main.vhd vorhanden. Das main.vhd hat ohnehin noch keine sinnvolle 
Funktion erhalten. Daher ist es momentan noch nicht wichtig, welcher 
Port innerhalb der main.vhd als Clock für Pin C8 fungiert.

Es geht mir lediglich darum, erstmal alle Constraints aufsetzen zu 
können. Daher versuche ich, alle Pins korrekt zu definieren.

Ebenso habe ich versucht, eine 7:1 Gearbox (LVDS) in main.vhd zu 
instanziieren. Dies funktioniert ebenfalls nicht, solange 
gearboxtest.ipx aktiviert ist (für die Implementation aktiviert).

Ok, das Projekt sieht echt uebel aus. Sich da durchzuwuehlen waere 
verschwendete Lebenszeit.

Setzte doch mal ein neues auf und fange mit einem Port an und geh dann 
nach und nach durch. Port definieren, Constraint File schreiben, bauen 
lassen. Dann solltest du auch relativ schnell merken wo die Probleme 
liegen.

Tobias B. schrieb:
> Ok, das Projekt sieht echt uebel aus. Sich da durchzuwuehlen waere
> verschwendete Lebenszeit.

Vermutlich hat der IP-Generator alles verwüstet...

Tobias B. schrieb:
> Setzte doch mal ein neues auf und fange mit einem Port an und geh dann
> nach und nach durch. Port definieren, Constraint File schreiben, bauen
> lassen. Dann solltest du auch relativ schnell merken wo die Probleme
> liegen.

Ok, mach ich.

Ich melde mich nochmals mit einem neuen Projekt. Danke!

Also, hab ein neues Projekt erstellt. Diesesmal deutlich weniger "Müll" 
im Ordner enthalten.

Wie würdest du nun fortfahren?

Ich habe bereits einen Multicycle constraint angelegt:

1

MULTICYCLE FROM GROUP "RGB_DATA" READPATHS TO PORT "PX_CLK" 1.000000 ns ;

Was ich konkret machen möchte ist, mit dem PX_CLK Takt die Signale der 
Gruppe RGB_DATA einlesen. Daher möchte ich sicherstellen, dass PX_CLK 
erst als letztes seinen Zustand ändert.

Ist für dieses Vorhaben die obige Bedignung korrekt?

Zusätzlich liegt PX_CLK an einem Clockeingang des FPGAs. Daher würde ich 
PX_CLK gerne als Takt definieren. Und damit wäre ich nun wieder bei der 
ursprünglichen Frage angekommen :)

Offenbar war das Problem, dass ich den PX_CLK nicht ausschliesslich als 
Clock verwendet habe. Nachdem ich den PX_CLK aus der or-Kette entfernt 
habe (am Ende der VHD-Datei) wird mir der PX_CLK nun als Clock erkannt.

1

process(PX_CLK)

2

  begin

3

    if(rising_edge(PX_CLK)) then

4

...

5

  end if;

6

end process;

Sobald ich nun die PLL mittels ipexpress hinzufüge, gibts nur noch 
errors.

Meldungen:

1

ERROR - Based on the current IO attributes settings, port [BLUE_A[3]] cannot be assigned to pin [L14].

2

ERROR - The port [BLUE_A[4]] doesn't exist in the design.

3

...

Es scheint so, als würde die main.vhd gar nicht mehr berücksichtigt 
werden.

Ok, ich musste die Top-Level unit definieren

Project -> Active Implementation -> Set top level unit

Holger K. schrieb:
> Ok, ich musste die Top-Level unit definieren
>
> Project -> Active Implementation -> Set top level unit

Ja, das wollte ich Dir auch gerade raten. Wenn Du was mit IPExpress 
generierst, wird eine VHDL Datei angelegt, aber nicht im Project 
angezeigt. Die liegt dann in dem Projektordner. Daraus kopiere ich immer 
die port map und fuege sie ins Top-Level-Modul ein.

Holger K. schrieb:
> Ich habe bereits einen Multicycle constraint angelegt:
> MULTICYCLE FROM GROUP "RGB_DATA" READPATHS TO PORT "PX_CLK" 1.000000 ns
> ;
>
> Was ich konkret machen möchte ist, mit dem PX_CLK Takt die Signale der
> Gruppe RGB_DATA einlesen. Daher möchte ich sicherstellen, dass PX_CLK
> erst als letztes seinen Zustand ändert.

Ich verstehe, was du machen möchtest. Aber ich habe absolut keinen 
Schimmmer, wieso du auf die Idee kommst, das du nun ein Multicycle 
constraint nehmen könntest. Kannst du mal die Diamond Doku zum 
Multicycle lesen und uns erklären, für welche Fälle dieser benötigt 
wird?

Eigentlich sollte es reichen, dass du ein Register hast, dass PX_CLK als 
Clock nutzt und RGB_DATA am Dateneingang. Dass PX_CLK später als die 
Daten ankommen, darum kümmert sich das P&R Tool.

Richtigerweise muss für PX_CLK per constraint eine Periodenzeit 
angegeben werden (wenn von extern kommend, falls das der Ausgang der PLL 
ist, dann musst du das nicht noch extra machen).

Wenn das sauber klappt, wäre der nächste Schritt, falls vorhanden, 
Verzögerungszeiten verursacht durch das Leiterplattenlayout als 
constraints hinzu zu fügen. (Könnte das ev. das sein, was du oben 
eigentlich definieren wolltest?)

Vielen Dank für eure Antworten.

Christoph Z. schrieb:
> Eigentlich sollte es reichen, dass du ein Register hast, dass PX_CLK als
> Clock nutzt und RGB_DATA am Dateneingang. Dass PX_CLK später als die
> Daten ankommen, darum kümmert sich das P&R Tool.

Sehr gut! Das war mir nich bewusst.

Christoph Z. schrieb:
> Richtigerweise muss für PX_CLK per constraint eine Periodenzeit
> angegeben werden (wenn von extern kommend, falls das der Ausgang der PLL
> ist, dann musst du das nicht noch extra machen).

Wie macht man das, wenn PX_CLK variabel ist? Ich nehme dan, da wird 
einfach der Wort-Case = kürzeste Periodendauer definiert?

Christoph Z. schrieb:
> Wenn das sauber klappt, wäre der nächste Schritt, falls vorhanden,
> Verzögerungszeiten verursacht durch das Leiterplattenlayout als
> constraints hinzu zu fügen. (Könnte das ev. das sein, was du oben
> eigentlich definieren wolltest?)

Ehrlich gesagt, nein, ich habe wirklich gedacht, der Multicyclepath 
definiere ein "minimal delay" zwischen der Gruppe und dem Clock. Aber 
jetzt wo ich so darüber schreibe erinnere ich mich, Multycycle 
constraints beim DDR2 Memory treiber in Quartus verwendet zu haben.

Holger K. schrieb:
> Wie macht man das, wenn PX_CLK variabel ist? Ich nehme dan, da wird
> einfach der Wort-Case = kürzeste Periodendauer definiert?

Ja.

Super. Vielen Dank für deine Antwort.

Aktuell bin ich gerade daran, mein Design mit Active-HDL zu simulieren. 
Funktioniert eigentlich ganz gut. Mit Ausnahme der LVDS 7:1 Gearbox. 
Lässt sich diese ebenfalls simulieren? Aktuell ist deren Clock 1/3 des 
Grundtaktes. Ich bekomme zwar Output aber nicht den erwarteten, 7-fachen 
Takt.

Ich habe diese in meiner main.vhd drin.. Mein Testbench erzeugt einen 
Grundclock welcher auch auf die Gearbox geht.

Gibt es da grundsätzlich etwas zu beachten bei der Simulation solcher 
"HW" IP-Cores?

Danke

Wobei die Simulation sogar mit der Realität übereinstimmt.
Der Grundtatk (CLK_IN - 12MHz) wird um Faktor 4 geteilt. Auf 3 MHz.
So ist es auch auf dem Oszilloskop ersichtlich.

Einstellungen sind gemäss Anhang.

CLK: 12MHz
clk_s: 6MHz
reset: low
dataout wird von 0..128 hochgezählt.