Hallo, bin VHDL Anfänger. Habe ein kleines FX2 Projekt gestartet, einen kleinen LA, 24(16bit)/48(8bit)/98(4bit) msps, um mich im FX2 (usb) einzuarbeiten. Kennt jemand einen kleinen cpld/fpga, welcher wenige mA benötigt, also kein Energieverschwender, mit dem ein Eingangsfilter sowie eine Run-length Kompression erreicht werden kann. Der Baustein sollte ca 200Msps erreichen können. Weiteres Kriterium, freie Entwicklungsumgebung. 22 I/O würden reichen aus, da mich eigentlich 8bit reichen würden. Danke im Voraus.
@ Chris S. (schris) >24(16bit)/48(8bit)/98(4bit) msps, um mich im FX2 (usb) einzuarbeiten. ???? >Kennt jemand einen kleinen cpld/fpga, welcher wenige mA benötigt, >also kein Energieverschwender, Ach ja, die bösen FPGAs sind alles Energieverschwender, jaja. Was sind bei dir wenige mA? 5? 50? Letzeres schaffen FPGAs, aber ganz sicher nicht bei 200 MHz ;-) > mit dem ein Eingangsfilter sowie eine >Run-length Kompression erreicht werden kann. Das musst du schon selber machen. > Der Baustein sollte ca >200Msps >erreichen können. Kann jedes halbwegs aktuelle FPGA. >Weiteres Kriterium, freie Entwicklungsumgebung. 22 I/O würden reichen >aus, >da mich eigentlich 8bit reichen würden. Kauf dir ein kleines Evalboard. Spartan 3 von Xilinx, oder Cyclone I oder II von Altera. Die kleinsten reichen für deine ersten Gehversuche. MFG Falk
... oder Lattice MachXO. > da mich eigentlich 8bit reichen würden. Schön wenn dich 8 Bit reichen ;-) Aber du weißt schon, dass du hier drei Baustellen aufmachst? Die eine ist, mal eine anständige Kommunikation mit dem Cypress hinzubekommen. Die zweite, eine blitzsaubere Software für den PC zu schreiben. Und die dritte ist: wie kannst du 200MSps RL-Codieren, den Trigger reinhacken usw. usf. Jede davon dürfte dich einige Zeit beschäftigen und Software ist sowieso nie fertig. Konzentrier dich doch erst mal auf den 1. Teil: >... mich im FX2 (usb) einzuarbeiten.
Falk Brunner wrote: > @ Chris S. (schris) > >>24(16bit)/48(8bit)/98(4bit) msps, um mich im FX2 (usb) einzuarbeiten. > Habe mit dem FX2 ein LA gemacht, das folgendes kann: - 16 Signale mit 24 Msps oder - 8 Signale mit 48 Msps oder - 4 Signale mit 98 Msps Dazu habe ich die Platine von http://www.triplespark.net/elec/periph/USB-FX2/circuit.html verwendet, will allerdings demnächst eine eigene mit dem QNF Gehäuse routen. > >>Kennt jemand einen kleinen cpld/fpga, welcher wenige mA benötigt, >>also kein Energieverschwender, > > Ach ja, die bösen FPGAs sind alles Energieverschwender, jaja. > Was sind bei dir wenige mA? 5? 50? > Letzeres schaffen FPGAs, aber ganz sicher nicht bei 200 MHz ;-) > Das Ganze sollte ohne externe Spannungsquelle über USB funktionieren, also sollte es ca 480 mA Spize (worst case) nicht überschreiten. 170 mA werden für FX2 sowie die Buffer benötigt, 2 leds, sind dann ca 300mA maximal, darf aber auch kurzzeitig nicht überschritten werden, denn sonst meckern einige Computer und deaktivieren vorsichtshabler den USB-Port. >> mit dem ein Eingangsfilter sowie eine >>Run-length Kompression erreicht werden kann. > > Das musst du schon selber machen. Das ist klar. > >> Der Baustein sollte ca >>200Msps >>erreichen können. > > Kann jedes halbwegs aktuelle FPGA. > >>Weiteres Kriterium, freie Entwicklungsumgebung. 22 I/O würden reichen >>aus, >>da mich eigentlich 8bit reichen würden. > > Kauf dir ein kleines Evalboard. Spartan 3 von Xilinx, oder Cyclone I > oder II von Altera. Die kleinsten reichen für deine ersten Gehversuche. > Ich habe ein Spartan 3 eval-board von Xilinx, verbraucht aber verdammt viel Strohm im nichts Tun. Habe gehört, Spartan2 ist in dieser Hinsicht besser. Eigentlich aber spielte ich mit dem Gedanken, das in ein CLPD reinzupacken, da ja keine Triggerung usw gebraucht wird. Weiters wäre ich mit einer Busbreite von 4 oder 8bit zufrieden, da ich den Haupteinsatztzweck in der Fehlersuche von seriellen Protokollen sehe, sowie überprüfung von entprellungen usw. Lothar Miller wrote: > ... oder Lattice MachXO. > >> da mich eigentlich 8bit reichen würden. > Schön wenn dich 8 Bit reichen ;-) Hauptzweck sollte die Protokollanalyse bei seriellen Schnittstellen sein. Als generisches LA sind das zu wenig, ist aber für einiges zu gebrauchen. Zudem gibt es die Möglichkeit, 16bit ohne RLE zu haben. Auch wenig, und wenig Bandbreite, nur 24 Msps, aber nicht schlecht. > > Aber du weißt schon, dass du hier drei Baustellen aufmachst? > Die eine ist, mal eine anständige Kommunikation mit dem Cypress > hinzubekommen. Das brauche ich auch in zukünftigen Projekten. > Die zweite, eine blitzsaubere Software für den PC zu schreiben. Das stimmt, bin am Anfang auch mit was halbfertigen zufrieden, so halbfertige LA-SW gibt es haufenweise, die angepasst werden könnte. > Und die dritte ist: wie kannst du 200MSps RL-Codieren, den Trigger > reinhacken usw. usf. Trigger würde ich im PC machen, nicht auf dem Board. RL-Codierung, einfach den vorhergehenden Sample mit dem derzeitigen vergleichen, und einen Zähler hochzählen. Wenn overflow oder ungleich, Wert inkl Zähler rausschicken. > > Jede davon dürfte dich einige Zeit beschäftigen und Software ist sowieso > nie fertig. Konzentrier dich doch erst mal auf den 1. Teil: >>... mich im FX2 (usb) einzuarbeiten. Das ist bereits geschehen. Das Projekt hätte einen zimlichen Mehrnutzen, wenn man mittels eines kleineren FPGA oder CPLD´s die Bandbreite des LA hochsetzen könnte.
@ Chris S. (schris) >Das Ganze sollte ohne externe Spannungsquelle über USB funktionieren, >also sollte es ca 480 mA Spize (worst case) nicht überschreiten. >170 mA werden für FX2 sowie die Buffer benötigt, 2 leds, sind dann >ca 300mA maximal, Bei 4,5V min. macht 1,35W. Die per Schaltregler auf 1,2V für den Kern runtersetzen macht bei 90% Wirkungsgrad ca. 1,2W. Sagen wir rund 1W für den Kern und 200mW für die IOs, wobei das schon SEHR viel ist. Und 1W in nem FPGA verheizen, da muss schon TIERISCH die Post abgehen. >Ich habe ein Spartan 3 eval-board von Xilinx, verbraucht aber verdammt >viel Strohm im nichts Tun. Glaub ich kaum. So ein Spartan 3 zieht 30mA im Leerlauf, ggf. weniger. Der Rest geht irgendwo anders flöten. > Habe gehört, Spartan2 ist in dieser Hinsicht >besser. Nö. Nicht wirklich. >Eigentlich aber spielte ich mit dem Gedanken, das in ein CLPD >reinzupacken, da ja keine Triggerung usw gebraucht wird. LA ohne Trigger? Naja. Ein CPLD ist machbar, Coolrunner II ist dein Freund. Oder was von Rationpharm, ähhh Altera. ;-) >Haupteinsatztzweck in der Fehlersuche von seriellen Protokollen sehe, >sowie überprüfung von entprellungen usw. Dafür nen LA? Naja . . . >Trigger würde ich im PC machen, nicht auf dem Board. Vollkommen falscher Ansatz. Der Trigger muss sinnvoll direkt auf die Erfassung. > RL-Codierung, >einfach den vorhergehenden Sample mit dem derzeitigen vergleichen, und > einen Zähler hochzählen. Wenn overflow oder ungleich, Wert inkl Zähler >rausschicken. Fast. MFg Falk
Danke, Altera ist der richtige Anstoß gewesen. CollrunnerII hatte ich schon gesehen, war aber nicht so das Richtige. Warscheinlich komme ich noch mit 100mA Durchschnitt aus, nicht Spitze, das geht leider nicht. Zum Projekt, das sollte eine Art LA werden, welche z.B. usb Full-Speed sniffen kann, auch ohne RC, oder z.B. SD-Karten interfacing, wie auch z.B. Smartcards, RF-Transponder usw, wobei die Pakete ähnlich Etherreal auf high-level angezeigt und getriggert werden können, vom PC aus, das geht nicht wirklich gut vom FPGA aus. Da die BAndbreite ausreichend ist, geht das auch. Die RC ist für höhere Geschwindigkeiten gedacht, z.B. SDRAM Timing Verification oder so, und auch, um das Gerät standalone ein Protokoll aufzeichnen zu lassen, wie RS485, ... und in ein Flash zu speichern. Ok Protokolle, wie z.B. rs485, i2c usw kann man auch ein uC dranhängen, bei unbekannten Protokollen, oder solche, wo unterschiedliche Geschwindigkeiten gefahren wird, finde ich so ein Gerät praktisch. Wie gesagt, hauptsächlich diente mir das Projekt auch als Lernprojekt, um den FX2 besser kennenzulernen, da ich diesen in Zukunft für einige FPGA-Projekte verwenden will. Da es dem Anschein nach mit relativ wenig Zusatzaufwand möglich ist, aus dem Lernprojekt was Nützliches zu machen, was ich brauchen kann, möchte ich das auch umsetzen. Chris
Hallo, wenn du den trigger im PC machst, dann musst du sicherstellen, dass alle Daten den PC auch erreichen. Das bedeutet, du musst einen kontinuierlichen Datenstrom ohne Unterbrechungen in den PC bekommen. Leider ist das aber nicht garantiert. Du wirst Lücken in der Datenübertragung haben. Die Daten die in dieser Zeit anfallen musst du irgendwo zwischenspeichern. Deshalb solltest du auf jeden Fall noch einen Speicher mit vorsehen. Unter Umständen reicht die RAM - Kapazität in einem FPGA aus. Ein CPLD wird ohne zusätzlichen Speicher die Aufgabe nicht erfüllen können. Ich habe Versuche mit dem FX2 gemacht und dabei mittlere Datenübertragungen nahe der 40 MByte/sec geschafft. Aber nie ohne Unterbrechungen. Selbst bei Quad Buffer in einem Endpoint. Dazu hab ich das Digilent Nexys Board genommen. Ist allerdings alles schon wieder eine Weile her. mfg DerDan
Ja, das Problem habe ich auch festgestellt. Ehrlich gesagt, durch die Datenkompression erwarte ich nicht nur einen Geschwindigkeitsvorteil, sondern auch eine Datenreduktion, sodass der interne Fifo ausreichen sollte und ich keinen externen Fifo brauchen sollte.
Auch weitaus weniger Datenrate kann man nicht garantiert ohne Lücken übertragen. USB ist halt leider niedrig priorisiert und auf keinen Fall echtzeitfähig. Ich erreiche im Mittel hier mit dem FX2 auch etwa 40MB/s, aber eben nicht kontinuierlich. Eventuell wäre dann isochrones Streaming etwas für dich...da wird ja die Bandbreite garantiert. Sind dann ziemlich genau 24MB/s. Aber eben ohne Handshake, also kann zwischendurch mal was verloren gehen.
@Chris S.: Hier kannst Du Dir ja ein bischen was abgucken: http://www.sump.org/projects/analyzer/ Duke
DerDan wrote: > Ich habe Versuche mit dem FX2 gemacht und dabei mittlere > Datenübertragungen nahe der 40 MByte/sec geschafft. Aber nie ohne > Unterbrechungen. Selbst bei Quad Buffer in einem Endpoint. Auf welchem Betriebssystem? Falls dieses von Redmond kommt - wen wunderts ;-)
Na du bist ja ein ganz toller. Das tritt bei Windows auf und genauso gut bei Debian Linux mit der LibUSB. Das liegt ganz einfach am niedrig priorisiertem BULK-Transfer und ist unabhängig vom OS, weil es der Hostcontroller macht.
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.