Hallo zusammen, ich möchte hier unser Projekt vorstellen: es handelt sich um einen FPGA-basierten Logic Analyzer, welcher auf gängigen FPGA-boards laufen kann. Grobe Eckdaten: 32 Kanäle, 200MHz, 128MiB sample memory, Ethernet. Es handelt sich um eine Erweiterung des "sump". Ich poste dies hier in der Codesammlung, da der Löwenanteil doch der VHDL-Code da drin ist. :-) Alle Details und sources zum Projekts gibts hier: http://www.bastli.ethz.ch/index.php?page=BitHoundEn Viel Spass damit! Herzlichen Gruss aus der Schweiz
Hallo Mario, schönes Projekt, hat sich eine Menge Zeit gekostet. Toll das ihr es trotzdem der Community wieder zur Verfügung stellt. Es würde sich anbieten daraus mal wieder ein mikrokontroller.net Projekt zu machen. Gruß Stephan
Wenn ich etwas Zeit hätte, würde ich es auf meine Alteraboards portieren.
Juergen Schuhmacher schrieb: > Wenn ich etwas Zeit hätte, würde ich es auf meine Alteraboards > portieren. Warum?
Lehrmann Michael schrieb: > Warum? Vermutlich deswegen, damit er sich nicht extra ein neues (und teures) Xilinx Board kaufen muss, sonder die bestehenden verwenden kann.
Das Projekt gefällt mir. Müsste sich auch sicher leicht portieren lassen. Um das für typische Designs zu nutzen, müsste es allerdings etwas aufgepeppt werden. 32 Bits ist ein bischen wenig.
Hallo Mario und Lukas, schoenes Projekt, ich hab's gerade mal auf meinem Atlys am laufen (halt nix an den LA I/Os angeschlossen). Prima vor allem, dass ihr: * das unter GPL stellt * klasse dokumentiert habt * alles auch unter Linux prozessierbar gemacht habt (Skripte, makefile, ...) Fuer meine Spielereien mit dem Atlys werde ich euer Projekt sicherlich als weitere Grundlage verwenden, denn es hat alles was ich brauche: * PC Client zum Zugriff ueber Ethernet * DHCP * Einen einfachen, freien uC im FPGA * ...und noch einiges anderes Danke!
Hoi Berndl, schön, dass es klappt! :-) Wir arbeiten gerade an einer Verbesserung: Trigger und GUI werden stark verbessert und verändert - danach schafft er auch 400MHz mit dem Atlys-Board, soviel sei schonmal verraten ;-) Wir berichten zu gegebener Zeit. Lg Mario
jo, schoen dass ihr weiter macht. Ich werde euren Design mal versuchen komplett runter zu strippen. Daraus soll irgendwann mal 'Asteroids' mit Netzwerkanbindung fuer die Statistik werden. Ausgabe von 'Asteroids' natuerlich mit dem HDMI Interface...
Ich hätte dir sonst noch einen "gestrippten" AVR Softcore (derselbe wie im BitHound, direkt mit Wishbone-Anschluss) Bei Interesse kann ich ihn dir als Mail schicken. Lg Mario
Ah, ich denke mit eurem 'normalen' Code komme ich schon klar. Ich will ja ausser dem LA alles benutzen. Also muss ich nur wenig von eurem Code rauswerfen, der Rest kann ja bleiben. Nochmal danke, - berndl
Sodele - Version 2.0 von BitHound ist ab sofort online: http://www.bastli.ethz.ch/index.php?page=BitHoundEn Es gibt viele tiefgreifende Verbesserungen, u.A. ein cooler Trigger! ==> Viel Spass damit! Lg Mario
Hi Mario, schoen, dass ihr da nochmal nachgelegt habt. Kann es aber sein, dass ihr manche Sachen fuer Linux (noch) nicht nachgezogen habt? Z.B. ./Project/FPGA/Source/loadFw.sh? Da wird auf 'xst_13_1/LATop.bit' referenziert, dieses Subdirectory gibt es aber gar nicht. Ist mir beim ersten drueber gucken aufgefallen, ich werd's mal bei Gelegenheit durch die Toolchain hier jagen (alles unter Linux). Gruss, - berndl
Hoppla, ja, das wurde wohl vergessen. Wir haben aber festgestellt, dass Xilinx ISE unter Linux extrem schlecht bis gar nicht funktioniert... (Unter Ubuntu)...Da lief z.T. gar nichts und wir mussten alles im Windows machen... ==> Viel Glück! Lg Mario
oehm, also hier privat laeuft Xilinx ISE 12.3 unter Ubuntu 10.04 eigentlich besser (mindestens gleich gut) als der ganze Krempel 'auf Arbeit' unter Windows XP. Wie's mit neuen ISE Versionen und Win7 aussieht weiss ich allerdings nicht... Gruss, - berndl
Hallo zusammen, ich bin der Kollege von Mario. Also ISE 13.1 geht überhaupt nicht. Das Design braucht um zu kompilieren die ganzen Optimierungen die standardmässig off sind. Wenn man die im ISE 13.1 aktiviert bleibt es hängen oder crasht. Unter 12.3 und Linux traten diese Probleme vereinzelt auch auf, wir haben aber nicht versucht das zu fixen. Weil oben von portieren gesprochen wurde: das ist für Version 2.0 (mit 400MHz sampling) wohl nur schwer möglich. Das Design ist sehr stark optimiert, Teile des FPGA Layout wurden von hand gemacht um maximale Taktrate zu erhalten. Wenn mal also bei einem low end FPGA wie Spartan oder Cyclone bleibt ist das sehr mühsam. LG, Lukas
Hallo Lukas und Mario, also ich bin gerade am spielen mit dem Bithound2 FPGA. Was habt ihr denn da gemacht? Die .ucf file vom Bithound1 war noch 'geradeaus' und fuer mich nachvollziehbar. Die vom Bithound2 (ihr habt da angefangen, mit XPS rumzuspielen, oder?) ist ja eine Katastrophe... Also ich blicke da nicht mehr durch :o( Immerhin ist ISE12.3 unter Linux bei mir ohne Fehler durchgelaufen (auch Timing hat die Toolchain als ok gemeldet). Nur mit der 'Strategy' gab es eine Warnung, ich habe mal auf 'Performance with IOB Packing' umgestellt. Das habe ich gerade mal durch die Toolchain 12.3 gejagt, er meldet mir bzgl. Timing: 'All constraints met', also GRUEN. Aber ich habe die .ucf nicht wirklich analysiert und verstanden... Ansonsten hab' ich im Setup nix geaendert, eure Probleme kann ich erstmal nicht nachvollziehen Gruss, - berndl PS: Eure mitgelieferte .xise (Projektdatei) lief bei mir mit 12.3 ohne meckern, das scheint ja dann die passende Version zu sein (ISE kann ja erstmal nicht eine .xise von 13.x in 12.x importieren, das hatte mich auch gewundert...)
Hallo berndl, die mitgelieferte .xise ist in Version 12.x erstellt weil 13.1 nicht funktioniert. Das UCF ist deshalb so lange weil es nicht von Hand sondern mit PlanAhead erstellt wurde. Die timing kritischen Logikteile werden dort auf bestimmte LUTs / FFs im FPGA fixiert. Dadurch ist es möglich stufenweise alle Timing-Probleme in den Griff zu bekommen. Der Preis dafür ist halt das endlos lange UCF. Das funktioniert so lange gut so lange du nicht an der krtischen Logik (alles was mit 200MHz läuft) rumspielst. Also LA core, Trigger, etc. Wenn du das änderst musst du entweder im UCF die entsprechenden Einträge löschen oder im PlanAhead die Fixierungen aufheben. Wenn du das machst musst du dann wieder in mehrere Implementationsschritten solange optimieren und rumschieben bis es passt. MfG, Lukas
Ich nehme an, ihr werdet eure Gründe haben, warum das so manuell platziert ist, aber die FPGA-Expertern schwärmen mir doch immer wieder vor, wie einfach das in der Hochsprachenformulierung ist und sich das design von alleine platziert. Wieviel schneller wird der Analyzer durch das händische Routing?
Ohne händisches Routing schafft er das timing nicht... :-) Jaja, so gut ist ISE noch nicht, dass es das von alleine schafft...
Moin, Wäre eine Weiterentwicklung mit extra Platinen ohne Evalboard denkbar? In welchem preislichen Bereich könnte man das relaisieren und ist Interesse vorhanden, das zu tun?
Mal zur Dokumentation: Nicht jeder hat Lust, wenn er schon eine "richtige" Layoutsoftware benutzt, Ki(nder)Cad zu installieren. Ein paar PDFs oder PNGs sollten da schon noch drin sein...
Dokumentieren ist den meisten Ingenieren nicht gegeben. Ist auch beruflich meistens so,,,
Hoi Zäme, klar wäre eine entsprechende Weiterentwicklung ohne Evalboard denkbar. Wir haben dazu leider keine Zeit... :-) Und zur Doku: Für CHF50 pro Stunde ergänze ich dir die PDFs gerne ;-) Gruess!
Thomas Werner schrieb: > Ich nehme an, ihr werdet eure Gründe haben, warum das so manuell > platziert ist, aber die FPGA-Expertern schwärmen mir doch immer wieder > vor, wie einfach das in der Hochsprachenformulierung ist und sich das > design von alleine platziert. Wer von optimaler Entwicklung allein durch Verwendung von FPGA-Hochsprachen spricht ist kein FPGA Experte sondern ein VHDL/Verilog-Programmierer. Ohne das richtige Architekturkonzept und tiefen KnowHow von Board-design und FPGA-Interna keine optimale Lösung. Der Lösungsraum ist einfach zu groß als das dieser durch Optimierungsalgorithmen komplett abgesucht werden kann. Ohne Clevere Einschränkung (constraints, hier LOCATION-constraints) ist da nix optimales zu schaffen, wer anderes verspricht ist ein akademischer Träumer. MfG,
Solange aber doch das Design in den Chip passt, funzt es doch? Und wieviel Knowhow vom Chip soll man haben, um eine bessere Lösung zu finden, als das Tool? Das kennt doch die Resourcen am Besten.
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.