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 :)
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. ;-)
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
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.
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?
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 !"
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:
1 | 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!
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.
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
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!
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.