Moin, dieses CRUVI ist ein Standard ( https://imgs.xkcd.com/comics/standards.png ) für eine Highspeed und eine Lowspeed Platinen Steckverbindung. Leider finde ich ausser https://github.com/micro-FPGA/CRUVI-DOC/blob/master/specification/CRUVI_Specification.pdf keine echte Spezifikation wie Datenrate und so Zeug. Digilent hat sich eben erst dem https://syzygyfpga.io/ Standard angeschlossen. Was soll man also machen wenn man eine bastelfreundliche Platine entwerfen will? Wird es jetzt üblich, dass man noch eine Adapterplatine dazwischenhängen muss? Wieso verwendet man Platinenverbinder und keine Platine -> Kabel / Kabel -> Platine Stecker/Buchsen wie z. B. USB-C das ja relativ viele IOs bietet und auch einen Mix aus Highspeed und Lowspeed erlaubt.
Der einzige bastelfreundliche Standard der sich (leider) durchgesetzt hat ist PMOD, aber das ist ziemlich beschränkt. Gustl B. schrieb: > Wieso verwendet man Platinenverbinder und keine Platine -> Kabel / Kabel > -> Platine Stecker/Buchsen wie z. B. USB-C Dann hätte man ein langes USB C Kabel und es flattern da 2 Platinen frei in der Gegend rum... und jemand könnte denken es wäre ein normaler USB Anschluss... weiss nicht. Für SY-dingens gibt es Kabel, aber die sind teuer (60 Euro+).
Gustl B. schrieb: > Wieso verwendet man Platinenverbinder und keine Platine -> Kabel / Kabel > -> Platine Stecker/Buchsen wie z. B. USB-C das ja relativ viele IOs > bietet und auch einen Mix aus Highspeed und Lowspeed erlaubt. Die materialmäßige Verbindung ist noch der kleinste Teil, es muß auch der Signalstandard/Terminierung/Wellenwiderstand etc pp. passen. LVDS ist IMHO der erste Versuch der sich in Sachen highspeed durchsetzen konnte, es gibt da auch einen Verbinderstandard mit LVDS-Pärchen dafür - FPGA Mezzanine Card (FMC). Neben USB-C_KABEL werden auch gerne Mini-HDMI-Kabel eingesetzt: https://egpu.io/forums/expresscard-mpcie-m-2-adapters/exp-gdc-hdmi-to-mpcie-wiring-diagram/ Und man sollte auch beachten das Kabel empfindlich gegenüber einstrahlenden Stürungen sind, weswegen bei HDMI die High-Speed Leitungen extra geschirmt sind. Oder mindestens wie bei LVDS paarweise verdrillt (Twisted Pair) https://amtek-co.com.tw/ecatalog/202009-lvds-cable/
User32 schrieb: > Dann hätte man ein langes USB C Kabel und es flattern da 2 Platinen frei > in der Gegend rum... und jemand könnte denken es wäre ein normaler USB > Anschluss... weiss nicht. Naja man könnte auch auf das Kabel verzichten und der kleinen Platine einen USB-C Stecker geben. Ja vielleicht ist so ein USB typischer Verbinder schlecht weil verwirrend, andererseits sind die Kabel und so recht günstig. Was mit an den Standards wie CRUVI nicht gefällt ist, dass das wieder zwei verschiedene sind. Wozu braucht man die Unterscheidung zwischen Lowspeed und Highspeed, dann man da nicht einen Stecker/Buchse nehmen die für Beides taugt? Warum nicht M.2? Warum nicht PCIe 1x? Fpgakuechle K. schrieb: > es gibt da auch einen Verbinderstandard mit LVDS-Pärchen dafür - FPGA > Mezzanine Card (FMC). Einen? FMC ist relativ neu, davor gab es schon mehrere Standards wie HSMC, VHDC, ... Fpgakuechle K. schrieb: > Und man sollte auch beachten das Kabel empfindlich gegenüber > einstrahlenden Stürungen sind, weswegen bei HDMI die High-Speed > Leitungen extra geschirmt sind. HDMI könnte man auch nehmen, auch bei USB-C sind die Adern geschirmt, ich sehe da kein Problem von Kabeln gegenüber ungeschirmten Board to Board Verbindern.
Fuer Board to board per Kabel ist SATA auch ein netter Hack, die Kabel und Stecker sind billig und halten etwas besser Geruettel aus als HDMI oder USB-C. Bastelfreundlich und robust ist LVDS halt selten. Ansonsten sehe ich nicht viel Sinn darin, nach Arduino-Manier eine weitere me-too-Loesung als 'Standard' zu promoten, davon duerfte es noch weit entfernt sein.
SATA ist in der Tat sehr nett, hat aber im Vergleich zu USB-C und HDMI weniger Leitungen. Auch die Spannungsversorgung die bei USB-C möglich ist (und auch bei HDMI wenn man sich nicht an den Standard hält) gibt es da leider nicht. Dafür gibt es bei SATA schöne Stecker mit Verriegelung. Vielleicht sollte man das einfach lassen und FMC verwenden.
Gustl B. schrieb: > Fpgakuechle K. schrieb: >> es gibt da auch einen Verbinderstandard mit LVDS-Pärchen dafür - FPGA >> Mezzanine Card (FMC). > > Einen? FMC ist relativ neu, davor gab es schon mehrere Standards wie > HSMC, VHDC, ... Der Vollständigkeit sei hier neben Kabel und Steckboard auch noch die klassische backplane Verbindung aufgezählt, insbesonders ATCA: https://en.wikipedia.org/wiki/Advanced_Telecommunications_Computing_Architecture http://www.interfacebus.com/ATCA_Chassis_Manufacturers.html Aber so ein FPGA-Rack ist dann wohl eher nicht für 'Bastler gedacht'. > HDMI könnte man auch nehmen, auch bei USB-C sind die Adern geschirmt, > ich sehe da kein Problem von Kabeln gegenüber ungeschirmten Board to > Board Verbindern. Kabelmäßig war auch mal PCIexpess im Spiel, allerdings ist das Interfacing im FPGA wegen dem PCIe-core eher resourcen intensiv. https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=687
Mir geht es nicht um die Verbindung selbst sondern wirklich nur um Buchse/Stecker. Und da fände ich einen Universalverbinder gut der sowohl differentielle Paare für hohe Datenraten kann als auch quasi als Pmod Nachfolger für normale Signale verwendet werden kann und da mindestens ebenfalls 8 Leitungen bietet. Außerdem wäre wie bei Pmod eine Spannungsversorgung gut. USB-C kann das. Die PCIe Verbinder oder M.2 können das auch.
Gustl B. schrieb: > Was soll man also machen wenn man eine bastelfreundliche Platine > entwerfen will? Stiftleisten im 2,54mm (100mil)-Raster. Das ist der einzig wahre Standard :-)
Martin S. schrieb: > Bastelfreundlich und robust ist LVDS halt selten. Kommt auf die gewünschte Ü-Geschwindigkeit an. Ich vernetze viele Platinen mit LVDS. Lässt sich auch manuell gut adaptieren, wenn man einen Mehrfach-OP an den Ausgang der Signale hängt.
Gibt es hier schon Neuigkeiten? Ich müsste mich jetzt zwischen CRUVI und SYZYGY entscheiden. Für CRUVI: - Benötigt keinen uC - hat mehr differentielle Leitungen Gegen CRUVI: - Wenige FPGA Boards verfügbar - Keines davon kann LVDS mit >= 1 GBit/s Für SYZYGY: - Viele mehrere FPGA Boards - Schnelles LVDS mit käuflichen Board möglich Gegen SYZYGY: - VADJ braucht zwingend einen uC wenn man sich an den Standard halten möchte - Weniger (10) differentielle Leitungen Duke Scarring schrieb: > Stiftleisten im 2,54mm (100mil)-Raster. > Das ist der einzig wahre Standard :-) Das ist wirklich eine Option. Taugt sogar für schnelles LVDS.
Abgesehen von den technischen Details finde ich sehr interessant, dass CRUVI offenbar von dem neuen Unternehmen MicroFPGA geschaffen wurde. Als Autor bei Github findet man ausschließlich Antti Lukats, den Geschäftsführer (vermutlich auch Gesellschafter) von MicroFPGA. Er war/ist wiederum einer der wichtigsten Entwickler bei Trenz Electronic und treibt sich auch hier im Mikrocontroller-Forum von Zeit zu Zeit herum. Laut LinkedIn ist er nach wie vor auch CTO bei Trenz.
:
Bearbeitet durch User
Nun, im CRUVI Standard stehen schon ein paar mehr Leute drinnen:
1 | Name Company |
2 | Helmut Plötz Arrow |
3 | Paul Gardner-Stephen Flinders University |
4 | Benjamin Gittins Synaptic Laboratories Ltd |
5 | Antti Lukats MicroFPGA UG |
6 | Matthew Burns Samtec |
7 | Edmund Humenberger Symbiotic EDA |
8 | Thorsten Trenz Trenz Electronic GmbH |
Aber wo ich schon dabei bin: - Wie wird beim CRUVI die VADJ eingestellt? Mit Widerstandswerten oder wird die fest vom FPGA Board vorgegeben? - Sind weitere CRUVI FPGA Boards aktuell in Planung mit schnellerem LVDS? Der Cyclone10LP kann leider kein ganzes GBit/s. - Ist spezifiziert wie viel Strom ein Modul ziehen darf? - Ist für den LS Connector eine SPI Belegung spezifiziert? Gerne auch mit mehrenen SDOs falls man wie ich einen ADC IC mit mehreren Kanälen verwenden will. Und eine Anmerkung: Beim LS Modul finde ich die Anordnung bezüglich der Richtung nicht ideal. Wenn man da einen ADC verbaut, dann sind die digitalen Signale sehr nahe am analogen Eingang. Da würde ich den Eingang fast in den hinteren Teil setzen dort wo sonst der HS Anschluss liegt. Falls ich mich für CRUVI entscheide würde ich ein HS Modul mit HMCAD1511 und ein LS Modul mit einem galvanisch getrennten ADC AD7380 beitragen. Eigentlich wollte ich kein FPGA Board bauen, aber gut, vielleicht auch das dann mit Xilinx 7er Serie und vielleicht auch USB3, jedenfalls dann aber 2 oder 3 CRUVI jeweils mit HS und LS. Habe mich aber noch nicht entschieden, vielleicht werden es auch ganz normale 2,54mm Stecker/Buchsen.
Die Leistungen von Herrn Lukats in Ehren, aber ich sehe hier noch nicht den wirklichen Nutzen: PMOD war klar eine Bastellösung und für das Professionelle gibt es Glasfaser-Optionen, mehr als man je einsetzen kann und wenn es um das rauhe Industrieumfeld geht, haben wir MODBUS, CAN und was weiss ich. Unds: Es obliegt doch jedem Einzelnen selbst, einen vorgeschlagenen Standard zu nutzen, oder nicht. Ich sehe für mich und meine Firma keinen Nutzen darin. Soll das ein neuer Bastelstandard sein, ist es zu umständlich und teuer. So richtig "High-Speed" und trotzdem fast industrietauglich geht über HDMI. Da gibt es Transceiver und Kabel in allen Lagen. Mit einem nur 10,- Euro teuren Transceiver-Chip bekommts du 30 Bit (10x RGB) mit fast 150MHz raus. Mit Kabel und zwei Steckerbuchsen sind das €40,- um zwei FPGAs zu verbinden und das mit bis zu 20m!!!! Mit ein wenig Koordination und overhead und Benutzung von 24 Bit sind das 90Mbit / Euro. Wer bietet mehr? Wer will und kann, darf die Transceiver noch einsparen und im FPGA nachbauen. Wird aber nicht viel bringen.
Erstmal geht es nur drum eine Zusatzplatine mit einem FPGA-Board zu verbinden. Und das NICHT über lange Entfernungen. Aber eben mit mehr IOs als PMOD und mit ein paar differentiellen Leitungen. Und auch möglichst mit einem Standard-Verbinder. Wir haben als Quasi-Standard PMOD und dann gibt es als Standards FMC und HSMC. Dazwischen gibt es nichts. CRUVI und SYZYGY versuchen diese Lücke zu füllen. Ja, ich hatte oben auch USB-C erwähnt, das war eine Idee um dies es hier aber nicht gehen soll. CRUVI/SYZYGY sind keine Konkurrenz zu Kabellösungen. Klar könnte ich auch eine eigene Bastellösung verwenden, klar, aber dann ist das sonst nicht nützlich falls ich das nach Github hochlade und bei der eigenen Bastellösung muss ich auch zwingend mein eigenes FPGA Board erstellen.
Gustl B. schrieb: > Erstmal geht es nur drum eine Zusatzplatine mit einem FPGA-Board zu > verbinden. Und das NICHT über lange Entfernungen. Sicher, nur war mein Einwurf so zu verstehen, dass diese Verbindung derart robust ist, dass sie über etliche Meter taugt. Möchte man nur Platinen direkt anbinden und Ports sparen, reicht eine Realisation im FPGA ohne Transmitter (und was HDMI angeht, sogar ohne den HDMI-Core und man nutzt nur den PHY-Teil, also die Transceiver). > auch möglichst mit einem Standard-Verbinder Darüber kann man jetzt diskutieren, was eine Standard-Verbinder ist. PMOD ist ein abgesägter Pfostenstecket, der musste sich erst einmal etablieren. Aber jeder andere B2B-Connector ist ebenso ein Standard. Ich habe mir die SPEC jetzt gezogen und finde dort einen kleinen SAMTEC. Ok, der ist sicher sinnvoller, als den fetten FMC und dann "low pin count" anzubieten (der Stecker kostet 2x35,- Euro!). Nur wieivel billiger ist das kleine SAMTEC? 2x20? Enclustra hat gezeigt, wie man das macht indem man einfach das Modul als steckbares RAM-Modul baut. Damit fällt ein Stecker weg und der übrige liegt bei unter 15,-. Ich finde das schon bemerkenswert, wenn die Platine, die der Drittanbieter bereitstellen soll, mal direkt einen Fuffy teuer wird, ohne dass es da einen Vorteil von gibt. > der eigenen Bastellösung muss ich auch zwingend mein eigenes FPGA Board > erstellen. Du musst doch ohnehin dein eigenes PCB machen, oder was? Gehen wir das doch mal praktisch an: Wenn man richig was Ordentliches anflanschen will, braucht es nicht nur Kontakte sondern auch mechanisch stabile Verbindungen, weil das "Ordentliche" nicht gerade klein ausfallen wird. Einfach nur was draufstecken und dann lose verknüppeln, tut nicht, weil zu wackelig. Der FMC-Stecker hat den Vorteil, dass er ausreichende Steckraten und -festigkeit hat und obendrein verschraubt werden kann. Darüber gibt es in der SPEC nichts, dass man Bohrungen hätte oder etc. Was es auch nirgends gibt: Eine SPEC für die Transmissions-Raten. Was kann der Standard, bzw. was soll er können? Ich finde es allemal praktischer, eine Flexilösung zu nehmen und auf eine andere, beliebig große Platine darüber oder darunter zu brücken, die man dann falten und auch in ein Produkt einbauen kann und nicht nur einen fliegenden Aufbau als Proto hat.
Weltbester FPGA-Pongo schrieb im Beitrag #6907355: > Darüber kann man jetzt diskutieren, was eine Standard-Verbinder ist. > PMOD ist ein abgesägter Pfostenstecket, der musste sich erst einmal > etablieren. Richtig. Aber der hat sich etabliert und es gibt ein ordentliches Angebot an Zusatzplatinen und auch FPGA Boards. Weltbester FPGA-Pongo schrieb im Beitrag #6907355: > Aber jeder andere B2B-Connector ist ebenso ein Standard. Der sich aber noch nicht etabliert hat. Weltbester FPGA-Pongo schrieb im Beitrag #6907355: > Nur wieivel billiger ist das kleine SAMTEC? 2x20? Also bei mir ist der Platinenplatz der größte Posten. Aber auch das ist mir eher egal weil es nur wenige Platinen werden. Jedenfalls der Samtec bei CRUVI (ST4-30-1.50-L-D-P) kostet einzeln 5 €. Finde ich OK. Weltbester FPGA-Pongo schrieb im Beitrag #6907355: > Enclustra hat gezeigt, wie man > das macht indem man einfach das Modul als steckbares RAM-Modul baut. Ein RAM Stecker ist lang, braucht also viel Platz auf der Platine und dann braucht es noch eine Verriegelung. Weltbester FPGA-Pongo schrieb im Beitrag #6907355: > Du musst doch ohnehin dein eigenes PCB machen, oder was? Wenn ich mich an einen Standard halte den es gibt dann nicht. Dann kann ich mir das FPGA Board auch kaufen. Weltbester FPGA-Pongo schrieb im Beitrag #6907355: > auch mechanisch stabile Verbindungen Und genau das bietet CRUVI/SYZYGY, denn da wird das Modul verschraubt. Weltbester FPGA-Pongo schrieb im Beitrag #6907355: > Was es auch nirgends gibt: Eine SPEC für die Transmissions-Raten. Was > kann der Standard, bzw. was soll er können? Naja, da kann man das Datenblatt vom Stecker/Buchse angucken. Weltbester FPGA-Pongo schrieb im Beitrag #6907355: > eine Flexilösung zu nehmen und auf > eine andere, beliebig große Platine darüber oder darunter zu brücken, Hm. Für größere Entfernungen oder wenn es flexibel sein muss dann ja, aber sonst möchte ich die Zusatzplatine gerne schön fest angeschlossen. Jedenfalls, ich kann da jetzt für mich natürlich eine gute Lösung finden. Das ist nicht das Problem. Ich kann ja auch CRUVI/SYZYGY verwenden aber anders belegen. Dann passt das zwar für mich zu kaufbaren FPGA Boards, aber entspricht nicht der Spezifikation. Mein Ziel ist es aber, das dann irgendwo bei Github hochzuladen damit das auch Andere nutzen können. Und dafür möchte ich mich an einen Standard halten. Und jetzt geht es mir eigentlich nur drum ob CRUVI oder SYZYGY oder was ganz Anderes. Anforderungen sind dass es günstige (> 500 €) FPGA-Boards gibt/in naher Zukunft geben wird und dass die dann auch 1 GBit/s LVDS können. So wie die Situation aber aussieht werde ich entweder a) SYZYGY verwenden und kein FPGA-Board bauen oder b) CRUVI verwenden und auch gleich ein FPGA-Board entwerfen. Aus Spieltrieb wird es wohl b.
Gustl B. schrieb: > Anforderungen sind dass es günstige (> 500 €) FPGA-Boards > gibt/in naher Zukunft geben wird und dass die dann auch > 1 GBit/s LVDS können. Günstig und mehr als 500 €?
Naja, wenn ich das selber baue, also sehr kleine Stückzahl, dann liegt der Preis in sehr ähnlicher Region. Aktuell gibt es gar kein FPGA-Board mit CRUVI oder SYZYGY das 1 GBit/LVDS (RX) kann. Die Boards die man kaufen kann haben alle entweder einen Cyclone 10 LP drauf oder einen Artix/Zynq der 7 er Serie mit Speedgrade 1. Tja und die können das laut Spec nicht. Doch, ein Board gibt es das hier https://digilent.com/shop/genesys-zu-zynq-ultrascale-mpsoc-development-board/ Aber das brauche ich nicht. Ich will nur einen schnellen ADC anbinden, brauche nicht viel Logik, keine Transceiver, keinen externen RAM, wenig BRAM. Mir würde ein kleiner Artix7 mit Speedgrade 3 reichen. Aber leider nicht käuflich. Aber Spartan 7 Speedgrade 2 kann das auch, also wird es vielleicht so einer. Artix7 100 mit Speedgrade 3 ist auch lieferbar, aber kostet schon ganz ordentlich. Naja, aktuell ist der ADC den ich verbauen möchte auch nicht lieferbar.
Was soll denn eigentlich gebaut werden, was eine so aufwändige Zusatzplatine benötigt?
Hi, soweit ich weiß wird es bald von Trenz noch einige FPGA Boards geben mit CRUVI HS (auch mit größeren und schnelleren FPGAs). Ich denke es kommt drauf an wann die Chips geliefert werden wann die erhältlich sind. Generell kann man da bei Trenz mehr Flexibilität bei den FPGAs erwarten denke ich als bei SYZYGY.
Videomann schrieb: > Was soll denn eigentlich gebaut werden, was eine so aufwändige > Zusatzplatine benötigt? Ich brauche für Messungen einen "langsamen" (wenige MSample/s) genauen (13-14 rauschfreie Bits wären schön) ADC und gleichzeitig einen schnellen ADC mit so 300 MHz Analogbandbreite aber da reichen 6 rauschfreie Bits. Beides habe ich einzeln habe ich schon gebaut, aber das soll beides an gleichen FPGA hängen. Und es soll modular werden, denn wenn ich an einem Analogfrontend was neu layoute will ich nicht gleich eine ganze FPGA Platine bestellen und bestücken müssen. Ich habe jetzt den langsamen ADC hier, und zwar mit PMOD. Das kann man aber auch schnell auf CRUVI-LS umlayouten. Wobei ich den Sinn hinter CRUVI-LS nicht sehe. Es gibt schon PMOD, also wieso CRUVI-LS? Ausserdem ist bei CRUVI-LS der Stecker recht doof angelegt, also dessen Position. Denn wenn man eine möglichst große CRUVI-LS Tochterkarte bauen will, dann ist der Anschluss recht mittig. Gerade bei empfindlichem Analogkram will man aber den Digitalkram möglichst an einem und das Analogzeug am anderen Ende der Platine haben. Naja. Andererseits, ich könnte auch meinen langsamen ADC der nur SPI verwendet ebenfalls mit einem CRUVI-HS Stecker anschließen. Warum auch nicht. Den schnellen ADC layoute ich gerade, und zwar für CRUVI-HS. Leon B. schrieb: > Hi, soweit ich weiß wird es bald von Trenz noch einige FPGA Boards geben > mit CRUVI HS (auch mit größeren und schnelleren FPGAs). Das wäre schön, aber da muss man dann auch sehen was die wirklich bieten. Aber zu CRUVI fehlt mir noch einiges an Dokumentation. Am Stecker sind einige Pins zwar benannt, aber es steht nicht dabei was das bedeutet. Was ist HSO? Was ist MODE? Wieso ist da nur ein Pin für VADJ? Wie viel Strom darf eine Zusatzkarte immer minimal ziehen? Ich werde jetzt den schnellen ADC fertig layouten und dann auch eine FPGA Platine bauen. Die wird zweimal das volle CRUVI bekommen (HS+LS) und dazu noch ein paar mal PMOD. Aber das dauert noch, wird vermutlich Mitte bis Ende Januar ...
Gustl B. schrieb: > Wobei ich den Sinn hinter CRUVI-LS nicht sehe. Der Vorteil im Vergleich zu PMOD ist, dass Erweiterung und FPGA Board eine Einheit bilden und die Platine nicht lose am Stecker hängt. > Aber zu CRUVI fehlt mir noch einiges an Dokumentation. Am Stecker sind > einige Pins zwar benannt, aber es steht nicht dabei was das bedeutet. > Was ist HSO? Was ist MODE? Wieso ist da nur ein Pin für VADJ? Wie viel > Strom darf eine Zusatzkarte immer minimal ziehen? Vielleicht hilft es einmal hier den Schaltplan anzugucken: https://shop.vhdplus.com/product/vhdplus-core-max10/ VADJ kommt von einem Spannungsregler auf dem FPGA Board und wird da von dem FPGA eingestellt. Bei dem Strom gibt es soweit ich weiß keine Vorgabe, aber der Spannungsregler kann 1A womit auch der FPGA versorgt wird. Die Pins können erstmal frei belegt werden. Vorrangig die differentiellen Pins. Je nach Einsatz gibt es auch eine empfohlene Belegung, das habe ich mal in den Anhang gepackt. Vielleicht kannst du dir auch mal das Board hier angucken: https://shop.trenz-electronic.de/de/TEB0707-02-Trenz-Electronic-4-x-5-Modul-Carrier-fuer-CRUVI-Erweiterungsboards?c=578 Da kann man ja verschiedene FPGAs draufstecken.
:
Bearbeitet durch User
Leon B. schrieb: > Der Vorteil im Vergleich zu PMOD ist, dass Erweiterung und FPGA Board > eine Einheit bilden und die Platine nicht lose am Stecker hängt. Da hätte man auch PMOD senkrecht hinstellen können. Und gegen loses Herumgehänge helfen die Schrauben. Bei SYZYGY hat man das auch gelöst. Leon B. schrieb: > Je nach Einsatz gibt es auch eine empfohlene Belegung, das habe ich mal > in den Anhang gepackt. Danke! Leon B. schrieb: > Vielleicht kannst du dir auch mal das Board hier angucken: Das habe ich schon gesehen. Für mich sieht das recht kompliziert aus mit den zwei FPGAs und dann müsste ich noch gucken welche der IOs zu welchen Bänken gehören und so und manche CRUVI Pind hängen an dem einen, manche an dem anderen FPGA. Mag sein, dass das Sinn macht, ich will das möglichst einfach. Ein FPGA, USB mit FT2232 und noch einem FT600 wenn genug IOs übrig bleiben, dann noch PMOD und mehr will ich nicht. Und es ist ja auch Spieltrieb. Sonst müsste ich hier abends wieder anderen Hobbys nachgehen die im Winter bei dem Wetter keinen Spaß machen.
Gustl B. schrieb: > Da hätte man auch PMOD senkrecht hinstellen können. > > Und gegen loses Herumgehänge helfen die Schrauben. Bei SYZYGY hat man > das auch gelöst. Ja kann man alles irgendwie lösen, aber ich finde CRUVI LS ist da schon eine recht kompakte und einfache Lösung. > Das habe ich schon gesehen. Für mich sieht das recht kompliziert aus Ja das stimmt. Aber da wird es auf jeden Fall bald noch bessere Lösungen geben. Ich arbeite auch gerade an einer FT600 Erweiterung wenn man mehr Power als vom FT2232 braucht. Wenn du erstmal bei CRUVI drin bist findest du ja vielleicht auf meiner Seite noch was interessantes: https://vhdplus.com/
Den FT60X kann man wirklich schön verwenden und bekommt auch ordentlich Durchsatz. Leon B. schrieb: > https://vhdplus.com/ Hatte ich auch gesehen samt dem MAX10 Board. Tja ich weiß nicht wirklich was ich von dem Ansatz halten soll. Es gibt ja aktuell mehrere Ansätze die das mit den FPGAs und den Zusatzmodulen einfacher gestalten sollen. Ich glaube das ist nicht der richtige Weg. Am Ende baut man ja doch eine Konfiguration für eine bestimmte Hardwarezusammenstellung. Das mit FPGAs ist einfach nicht dazu gedacht, dass man zur Laufzeit Hardware wechselt, das braucht man im Alltag so gut wie nie. Und auch so Sprachen wie MyHDL. Ja, nett, sieht für Einsteiger einfach aus, aber ist das nicht eine arglistige Täuschung? Der Anfänger denkt sich dieses Python, das kann ich, also kann ich auch FPGA mit MyHDL. Und dann muss der aber erst mit der Zeit merken, dass er trotzdem die ganze Logikdenke braucht wie wenn er VHDL schreiben würde. Clock Domain Crossing, verschiedenste Constraints setzen, ... und wenn es optimiert werden soll, dann ist es ebenfalls wichtig die Hardware zu kennen. Kann der Baustein echte dual Port BRAMs? Wie sehen die DSP Blöcke aus? Macht es Sinn in Hardware durch 3 zu teilen? Ja klar baut das die Synthese zu einem Fetten Logikgrab, aber * 341 und dann / 1024 geht wunderbar in einen DSP und läuft viel schneller. Ich werde da noch ein paar Jahre abwarten und zugucken. Was mich interessieren würde wäre ein Vergleich zwischen MyHDL und handgeschriebenem VHDL. Was braucht mehr Ressourcen und das schafft den höheren Takt.
Gustl B. schrieb: > Ich werde da noch ein paar Jahre abwarten und zugucken. Was mich > interessieren würde wäre ein Vergleich zwischen MyHDL und > handgeschriebenem VHDL. Was braucht mehr Ressourcen und das schafft den > höheren Takt. Eine rhetorische Frage :-) Nur wer einen sehr schlechten und ungeschickten Ansatz wählt, kommt mit händischem VHDL schlechter bei weg, weil die Synthese keine Konzepte- sondern nur Umsetzungen optimieren kann. Das gleiche Funktionskonzept ist mit einer optimierten Strategie immer sehr viel flebibler. Ein schlechtes Konzept unterliegt. Das zeigt sich schon bei der Nutzung der Xilinx-Cores: Man bastelt sich etwas aus einem Baukasten zusammen und benutzt deren Funktionskonzept. Verbindet man dann Elemente, die nicht für einander geschaffen sind und vorwegoptimiert wurden, braucht es Adapter und Converter. Bereits bei AXI geht das los und zieht sich wie ein Faden durch das System. Alles was universell und vorgefertig ist, verschlingt Resourcen und Timing-Reserve. Manuell gebaut ist (im FPGA!) immer schnell, wenn der Designer weis, was er tut. Klar: Er braucht gfs viel länger. MYHDL kann so zumindest ein guter Ansatz sein, reine Mathematik oder Schleifen schnell ins FPGA zu bringen und sei es nur, um es zu testen.
Also es ist natürlich immer eine Sache ob man im professionellen Umfeld etwas entwickelt und alles möglichst effizient gestalten will, oder ob man als Bastler mit FPGAs anfangen will. Ich sag mal, lieber habe ich einen mehr, der sich an FPGAs rantraut und anfängt erste Projekte zu erstellen mit vorgefertigten Blöcken und einer einfacheren Sprache (Eigentlich setzen wir dabei nicht auf MyHDL sondern auf VHDP), als dass FPGA Entwicklung wie jetzt erst nach einem abgeschlossenen Elektrotechnik Studium beginnt. Für euch als welche die sich schon besser auskennen bieten wir halt vor allem tools (Live Errors, einfacheres Simulieren, Logic Analyzer, Plotter, Serial Monitor, Quartus Integration), die man mit Quartus oder VS Code nicht alle in einem Programm bekommen würde. Programmieren kann man dann einfach wie zuvor in VHDL. Gerade bei Leuten die mit FPGAs anfangen hab ich eigentlich nur gutes gehört. Dann werden zwar mal ein paar Logik Elemente mehr benötigt, aber wenn es darum geht dürfte man erst garnicht zu VHDL greifen sondern müsste alle Logikblöcke einzeln verbinden. Und naja allein dadurch dass man VHDL und Quartus benutzt lernt man ja auch nicht dass durch 3 teilen nicht so gut ist
:
Bearbeitet durch User
Weltbester FPGA-Pongo schrieb im Beitrag #6924035: > Bereits bei AXI geht das los und zieht sich wie > ein Faden durch das System. Das mit dem AXI ist ja schön und gut, aber muss man nicht nutzen, auch die IPs nicht. Und dann hoffe ich immer, dass die Toolchain den Overhead wegoptimiert. AXI ist gut wenn man schnell etwas haben möchte, und eben nicht die ganzen IPs selber schreibt. Weltbester FPGA-Pongo schrieb im Beitrag #6924035: > MYHDL kann > so zumindest ein guter Ansatz sein, reine Mathematik oder Schleifen > schnell ins FPGA zu bringen und sei es nur, um es zu testen. Da mag das sinnvoll sein. Leon B. schrieb: > Ich sag mal, lieber habe ich einen mehr, der sich an FPGAs rantraut und > anfängt erste Projekte zu erstellen mit vorgefertigten Blöcken und einer > einfacheren Sprache (Eigentlich setzen wir dabei nicht auf MyHDL sondern > auf VHDP), als dass FPGA Entwicklung wie jetzt erst nach einem > abgeschlossenen Elektrotechnik Studium beginnt. Stimmt. VHDP habe ich mir noch nicht angeguckt. Vielleicht eines Tages.
Ich könnte stattdessen besser mal ein Video machen zu Sachen die man beachten muss. Wenn ich noch ein paar Ideen habt was man bei FPGA Programmierung beachten muss, könnt ihr ja gerne noch was auflisten. Wir vereinfachen ja nicht nur Dinge für Beginner sondern helfen auch dabei zu verstehen wie man damit umgeht: https://www.youtube.com/channel/UC7qiOvlaBSiWyAb7R1xTaEw/videos Wobei ich zugeben muss, dass es da leider auch noch recht oberflächlich geblieben ist.
:
Bearbeitet durch User
Gustl B. schrieb: > Ich werde da noch ein paar Jahre abwarten und zugucken. Was mich > interessieren würde wäre ein Vergleich zwischen MyHDL und > handgeschriebenem VHDL. Was braucht mehr Ressourcen und das schafft den > höheren Takt. Da schenkt sich a priori nix, da es von der Synthesesoftware abhaengt, wie es gemappt wird und wie es PnR anordnet. Die Staerken der Python-HDL im allgemeinen liegen darin, dass man sich mit einer Menge Unzulaenglichkeiten von VHDL oder Verilog nicht herumschlagen muss und beim Design von Testbenches oder (formaler) Verifikation eine Menge Erleichterungen erfaehrt und grosse Projekte viel sauberer und effizienter zu handhaben sind. Ansonsten ist klassisches MyHDL am selben event-orientierten Prozess-Konzept orientiert wie die V*-Sprachen und simuliert mit der eingebauten Simulationsmoeglichkeit entsprechend. Insofern passiert da gegenueber V* nichts obskures und der Synthese-Schritt ist derselbe. Wenn's allerdings um eingebaute Synthese und HLS-Mapping fuer eine Menge unterschiedlicher Architekturen geht, ist Python der klare Gewinner. Gibt da eine Menge Beispiele im Netz, aber das ist eher was fuer einen andern Thread.
Angehängte Dateien:
-
CRUVI_SPEC.png
5,8 KB -
CRUVI_LIB.png
11 KB
So, und ich habe noch eine spezielle Frage zu CRUVI: Auf meiner Zusatzplatine brauche ich für CRUVI-HS den Stecker ST4-30-1.50-L-D-P-TR richtig? Dazu habe ich mir die Eagle-Lib beim Hersteller runtergeladen. Die ist hier im Anhang. Ist die Nummerierung der Pins korrekt? Ich habe ein Bildchen angehängt wie das in der CRUVI Spec aussieht und dann eines wie das in der Eagle-Lib aussieht. Bei der Eagle-Lib ist Pin 1 dort wo auch der Punkt eingezeichnet ist. Muss ich jetzt die Pinnummerierung ändern oder ist es vielleicht so, dass die CRUVI-Spec den Header auf der Trägerplatine zeigt und das so mit der Zusatzplatine zusammenpasst, dass Pin 60 auf der Zusatzplatine Pin 1 auf dem Träger treffen muss? Bin etwas verwirrt. Edith hat gerade mal die Pins gespiegelt und eine neue Eagle-Lib hochgeladen. Passt die?
:
Bearbeitet durch User
Angehängte Dateien:
-
leer.png
5,2 KB
Vielleicht wird es so noch klarer mit einem anderen Bildchen. Ist das so korrekt wie im Anhang? Da bei dem Punkt am Header ist Pin 1. Der Header ist auf der Unterseite und wir gucken von oben durch die Platine hindurch. Das fehlt bei der CRUVI-Spec, dass dabei steht ob die jeweiligen Bildchen den Blick durch die Platine zeugen von oben oder ob das von der Headerseite her ist. Vielen Dank!
:
Bearbeitet durch User
Hier mal ein Projekt wie ich es habe. Brauchst du den LS Stecker? Nicht alle Steckplätze haben auch den LS Stecker. Ich würde wenn möglich ehr nur den HS oder LS Stecker benutzen.
Nein, den LS brauche ich nicht, aber um das auch mechanisch mal zu testen werde ich den mit layouten. Danke für die Dateien. Nur zur Sicherheit: Du hast das schon fertigen lassen und das funktioniert?
Die Platine selber nicht. Aber die Stecker Position und Löcher etc. habe ich von einer funktionierenden Platine
Angehängte Dateien:
-
CRUVI_HS.png
45 KB
OK. Also Position vom Stecker ist mir klar, mir geht es um die Nummerierung der Pins. Aber gut, dann verwende ich das wie bei dir. Sieht also hier so aus. Wieder der Blick von oben durch die Platine.
Gustl B. schrieb: > mir geht es um die Nummerierung der Pins. Ja da hab ich auch nichts dran verändert. Sind ja alle beschriftet im Schaltplan > Sieht also hier so aus. Wieder der Blick von oben durch die Platine. Ja sieht richtig aus
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.