mikrocontroller.net

Forum: FPGA, VHDL & Co. Lattice MachXO3 - Takt invertieren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Ich möchte mit einem MachXO3 RGB Daten (VSYNC, HSYNC, DE, etc..) 
einlesen. Nun wollte ich im ersten Moment die entsprechende bank mit dem 
Pixelclock als Takt versorgen... Aber da hab ich mir gedacht, dass es 
wohl besser wäre, wenn ich mit einem um 180 Grad verschobenen Takt 
(verschoben zum Pixelclock) die Daten sampeln würde.

Was meint ihr?

Wenn ja, wird es vermutlich nicht genügen, diese verschiebung durch 
einen simplen Inverter ala "CLK <= not PixelClock" zu machen, oder?

Bietet die PLL des MachXO3 eine option ala 1:1 Verhältnis mit 
Phasendrehung?

Oder sollte ich dazu einen externen hardware Inverter verwenden?

Danke schonmal :)

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Wenn ja, wird es vermutlich nicht genügen, diese verschiebung durch
> einen simplen Inverter ala "CLK <= not PixelClock" zu machen, oder?

Genau, das geht nicht.

Kennst du die Timing Beziehung deiner Signale zur Clock? Falls ja, dann 
diese in die Timing Constraints hacken. Diamond wird dann schon meckern, 
wenns was zu meckern gibt. ;-)

von Holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für deine Antwort.

Tobias B. schrieb:
> Kennst du die Timing Beziehung deiner Signale zur Clock? Falls ja, dann
> diese in die Timing Constraints hacken. Diamond wird dann schon meckern,
> wenns was zu meckern gibt. ;-)

Ich denke die kann ich herausbekommen. Es geht mir jedoch darum, ob ich 
noch was am Layout der Leiterplatte ändern muss. Aktuell hab ich den 
Pixelclock an den PCLKT1_0 Eingang des MachXO3 geroutet. Wäre schade, 
wenn ich im Nachhinein erst erfahren würde, dass ich den Clock lieber wo 
anders hin gemacht hätte. Denkst du (ihr), dass ich die Verdrahtung des 
Pixelclocks so belassen kann?

Der Chip besitzt ja einen Clockeingang der entweder diferentiell oder 
single ended angesprochen werden kann. Ich möchte single ended 
verwenden. Wenn ich nun beim PCLKT1_0 meinen Takt anschliesse, kann ich 
dann den anderen Eingang PCLKC1_0 für ein anderes Signal verwenden?

Vielen Dank

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
In der Regel ist der Workflow ein Henne/Ei Problem. Wenn dein FPGA 
Design an der Leistungsgrenze des Devices krazt, dann waerst du froh 
gewesen du haettest beim Layouten die richtige Entscheidung getroffen. 
Wenn das PCB Aerger macht, bist du froh, dass du den FPGA 
umkonfigurieren kannst.

Meine Empfehlung:

1.) Bevor du das PCB final routest, ueberlege dir welche FPGA Pins die 
idealen fuer dein Routing waeren.

2.) Dann nimmst du dieses Pinning und jagst erstmal ein Beispiel FPGA 
Design mit diesem Pinning durch die Tool Chain (Achtung das nichts 
wegoptimiert wird!) und schaust dass da prinzipiell keine Fehler 
auftauchen. Manchmal tauchen hier allerhand interessante Dinge auf, z.B. 
das bei einem bestimmtem Chip bei bestimmten Package an einer Bank 
irgendwelche Signal Standards nicht zur Verffuegung stehen. Oder das 
z.B. Standards auf einer Bank gemischt werden die sich mit gegebener 
Bankspannung nicht mischen lassen

3.) Wenn das klappt, dann fuegst du noch Timing Constraints hinzu und 
schaust ob auch da keine Stolpersteine zu erwarten sind. Je genauer du 
die Constraints hier schon kennst (z.B. weil dein PCB Tool diese 
ausspuckt + die Infos aus dem Datenblatt der Signal Quelle / Senke), 
desto weniger boese Ueberraschungen erwarten dich am Ende.

4.) Fertig Routen / Code schreiben

Als Faustregel wuerde ich im Zweifel immer versuchen das PCB Routing 
moeglichst optimal zu machen, FPGA intern bekommt man Timings noch 
relativ gut in Griff. Auch der MachXO3 hat programmierbare Delays an den 
Pins, ebenso kann die PLL den globalen Takt verschieben.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für deine Antwort.

Tobias B. schrieb:
> Dann nimmst du dieses Pinning und jagst erstmal ein Beispiel FPGA
> Design mit diesem Pinning durch die Tool Chain (Achtung das nichts
> wegoptimiert wird!) und schaust dass da prinzipiell keine Fehler
> auftauchen.

Muss ich dazu in meinem VHDL-Code bereits alle zukünftigen Ports 
deklarieren?

Tobias B. schrieb:
> Wenn das klappt, dann fuegst du noch Timing Constraints hinzu und
> schaust ob auch da keine Stolpersteine zu erwarten sind. Je genauer du
> die Constraints hier schon kennst (z.B. weil dein PCB Tool diese
> ausspuckt + die Infos aus dem Datenblatt der Signal Quelle / Senke),
> desto weniger boese Ueberraschungen erwarten dich am Ende.

Das geht alles, ohne fertigen VHDL-Code?

von Christoph Z. (christophz)


Bewertung
1 lesenswert
nicht lesenswert
Ja, du musst dazu alle verwendeten Ports im VHDL und im Constraint File 
(mit I/O Standard) deklarieren, sonst gibt es für das P&R Tool ja keine 
Arbeit, wo es dann motzen könnte.

Einen fertigen VHDL Code brauchst du noch nicht, falls du einigermassen 
passende IP Cores hast, bzw. zum Ausprobieren bekommst, hilft das 
natürlich massiv.
Ansonsten musst du mal die Eingangs-/Ausgangslogik zusammenfummeln, 
damit dieser Teil schon grob das macht, was es am Ende auch tun soll.

Also in deinem Fall z. B. die RGB Daten mit dem Pixelclock einlesen und 
in ein FIFO wegschreiben. Die Ausgangspins des FIFO legst du der 
Einfachheit halber auf weitere I/Os, damit es nicht wegoptimiert wird.

Tobias B. schrieb:
> 2.) Dann nimmst du dieses Pinning und jagst erstmal ein Beispiel FPGA
> Design mit diesem Pinning durch die Tool Chain (Achtung das nichts
> wegoptimiert wird!) und schaust dass da prinzipiell keine Fehler
> auftauchen. Manchmal tauchen hier allerhand interessante Dinge auf,

Been there, done that: 
Beitrag "Re: Zeigt her eure SMD löt-Kunst !"

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für deine Antwort.

Leider gibt es in meinem Design offenbar kein CLK. Bzw. CLKNET. Da kann 
ich nichts auswählen.

Ich habe ein sdc file angelegt und folgendes eingetragen:
create_clock  -period 480.769 -name {clk} [get_ports {clk}]

Leider bleibt das File grau.
Weisst du, oder jemand anderes, wie ich einen Clock definieren 
kann/muss?

Danke!

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Leider gibt es in meinem Design offenbar kein CLK. Bzw. CLKNET. Da kann
> ich nichts auswählen.

Deshalb brauchst du auch, wie Christoph bereits schrieb, einen minimalen 
Code der zumindest irgendetwas tut, so dass die Signale nicht 
wegoptimiert werden. wahrscheinlich wird alles rausoptimiert, daher gibt 
es auch keine Clock mehr.

Kannst ja mal die Logs der Synthese anhaengen, dann kann man etwas mehr 
dazu sagen.

Holger K. schrieb:
> Ich habe ein sdc file angelegt und folgendes eingetragen:
> create_clock  -period 480.769 -name {clk} [get_ports {clk}]
>
> Leider bleibt das File grau.

Unterstuetzt Diamond .sdc Files? Ich kenne das nur das man das in das 
.lpf File eintraegt, welches in der File List unter "LPF Constraint 
Files" auftaucht.

von Effe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Du könntest den Takt auch via PLL invertieren bzw. verschieben.

Also das ging bis jetzt bei diversen ICE40 und MachXO2 also würde ich 
denken dass es beim MachXO3 auch klappt.

Ich bin dann aber erst recht auf den LFE5 umgestiegen da der noch eine 
Ecke billiger ist und Multiboot & Encryption unterstützt. 0.8mm Pitch 
ist auch ganz ok. Dafür braucht er halt nen externen Flash.

https://www.mouser.de/ProductDetail/Lattice/LFE5U-12F-6BG256C?qs=sGAEpiMZZMve4%2FbfQkoj%252BIvLucGH%2Fmv63xcEeTWspyA%3D

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für deine Antwort und den Tipp mit dem LFE

Geht der auch mit der kostenlosen Diamond Software?
Und wie siehst mit 3.3V ein und Ausgängen aus?

Dann wäre der wirklich super!

von Andi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Geht der auch mit der kostenlosen Diamond Software?
> Und wie siehst mit 3.3V ein und Ausgängen aus?
>
> Dann wäre der wirklich super!

Ja, die ECP5 FPGAs ohne SERDES werden von der gratis Diamond Version 
unterstützt.

3.3V IO ist auch kein Problem.

Zusätzlich haben die noch den Vorteil, dass es eine freie OpenSource 
Toolchain dafür gibt. Synthese, Place'n Route, Download, siehe Yosys und 
Projekt Trellis.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.