Hallo zusammen I.) Ich möchte für ein ARM9-Board mit PC/104-Schnittstelle eine Interfacekarte bauen. Die Interfacekarte sollte mit einem FPGA bestückt werden, welcher einerseits die Dekodierung der an PC/104-Schnittstelle vornimmt und Benutzerlogik aufnehmen kann. Die Benutzerlogik sollte später ohne Hardwareeingriffe änderbar sein. Am liebsten wäre mir mit Standards zu arbeiten. Praktisch wäre s.w.wenn ein Konfigurationsfile vom per PC/104-Schnittstelle übertragen werden kann. Frage 1: Ist dieses Vorgehen Eurer Meinung nach überhaupt praktikabel und sinnvoll? II.) Alternativ könnte man ja auch eine JTAG-Schnittstelle aufbauen und an einer Standardschnitttelle des ARM-Boards eine Art Wiggler anbringen und diesen zusätzlich mit der Interfacekarte verbinden:) Frage 2: Wie sehen bitte evtl. bessere Lösungen aus? Beste Grüsse Geri
> PC/104 = ISA Also nicht PC104+ = PCI? Der ISA-Bus ist ein obsoleter, asynchroner Bus (mit haarsträubend vermurkstem Timing) willst du wirklich darauf aufsetzen? Zur Sache: Ich würde vorschlagen, du lässt dein FPGA aus einem Config-Flash booten. Wenn du jetzt z.B. den JTAG-Port des Config-Flashs an FPGA-Pins anschliesst, dann kannst du über den PC104-Bus und das FPGA diesen Config-Flash umprogrammieren.
Hallo Lothar Vielen Dank für Deine Rückmeldung. ja, ich meinte wirklich den PC104-Bus. Ich bisher der Annahme, dass dieser Bus bei vielen Embedded-Systemenn weit verbreitet zum Einsatz kommt. Sozusagen ein Standard... Die Codierung wäre sehr einfach. Mit ist aber auch aufgefallen, dass dieser Bus recht langsam ist:) Ich bin aber flexibel bei der Boardwahl. Für mich ist es auch mehr ein "Lern-Projekt":) Es sollte aber sinnvoll sein. Es gibt ja massig AMR9-Boards. Verstehe ich dich richtig? Du würdest eher den PC104+-Bus bevorzugen? Vielleicht ist es heutzutage auch besser, gleich ein Controller-Board mit FPGA zu verwenden... Mit gefällt nur die Modularität mit dem BUS-Sytem sehr gut. Zur Verbindung PC104-FPGA. Das kann ich gut nachvollziehen. Was passiert aber, wenn beim Schreiben der Konfig-Flashes ein Fehler auftritt? Nehmen wir aber mal an, das ist nicht das Problem. Gibt es Standard-Implementatierungen für JTAG-Signalgenerierung durch eine FPGA? Eine Option wäre vielleicht auch noch ein zusätzliches CPLD auf der Interfacekarte zu platzieren, welches die Programmierung des FPGA-Konfigurationsspeichers vornimmt:) Beste Grüsse und nochmals vielen Dank Geri
> Was passiert aber, wenn beim Schreiben der Konfig-Flashes ein Fehler > auftritt? Dann muß das Flash manuell mit einem Programmierkabel neu programmiert werden. > Gibt es Standard-Implementatierungen für JTAG-Signalgenerierung > durch eine FPGA? Nein, die Signale werden dann nicht durch das FPGA generiert, sondern vom Prozessor. Und nur über das FPGA an die JTAG-Pins ausgegeben. > Eine Option wäre vielleicht auch noch ein zusätzliches CPLD auf der > Interfacekarte zu platzieren, welches die Programmierung des > FPGA-Konfigurationsspeichers vornimmt:) Beim ISA geht das (da gibt es keine Initialisierung wie beim PCI...). Über das CPLD (am ISA-Bus) werden per Software die Konfigurationsdaten ins FPGA gebracht. Vorteile: weil die Konfigdaten auf dem Prozessorspeicher liegen ist kein Konfig-PROM nötig. Und ein Hardware-Update kann einfach wie ein Softwareupdate gehandhabt werden. Aber ISA ist wirklich uralt, eigentlich ein Zombie... > Du würdest eher den PC104+-Bus bevorzugen? Diese PC104 CPUs sind mir ein Greuel: Jede hat irgendwelche Schnittstellen irgendwo anders und irgendwie anders belegt. Meine Plattform derzeit ist ETX und dessen Nachfolger...
Sowas wie dieses: http://www.systerra.de/index.php?seite=35&inhalt=2345 http://www.systerra.de/index.php?seite=35&inhalt=2259 Der ISA-Bus ist uralt. Aber immer noch sehr beliebt in der Steuerungstechnik. Gerade bei den I/O-Karten des PC104-FF werden immer noch neue Karten nur mit diesem Bus angeboten.
Vielen Dank für Eure Infos! "Meine Plattform derzeit ist ETX und dessen Nachfolger..." Das sieht mir schon recht fortschrittlich, nur halt auch etwas komplexer aus:) ETC, XTXund ETCexpress... @Volker: Die Boards sehen mit recht leistungsfähig aus. Für meinen Fall möchte ich eine Stück Hardware mit IOs mit Schutzschaltung und Leitungstreiber aufbauen. Vielleicht wäre aber es auch besser, ein ARM9-Board mit PC104-Bus plus so ein FPGA_Modul anzuschaffen und lediglich den IO-Teil zu implementieren. Der Lerneffekt würde dann halt ein wenig darunter leiden:) Habe hier auch noch einen interessanten Link dazu gefunden http://www.fpga-faq.com/FPGA_Boards.shtml Nun bin ich gespalten und frage mich ob es dann immer noch Sinn macht auf dieser - vielleicht schon verlateten Technologie - aufzubauen:) Beste Grüsse Geri
Bei PC104 gibt es allerdings noch eine kleine Gemeinheit die Du unbedingt beachten solltest: PC104 hat standardmäßig 5V Pegel. Das verträgt nun mal kein neuerer FGPA. Eine Abhilfe kann da aber ein CPLD sein. Sozusagen als Pegelwandler. Es gibt eine ganze Reihe von aktuellen CPLDs, welchen 5V tolerante Eingänge haben. Sie treiben zwar nur 3,3V aktiv am Ausgang, das ist aber am ISA-Bus normalerweise kein Problem. Dann kannst Du ja auch gleich, wie vorgeschlagen, die Konfiguration des FPGAs über den ISA-Bus und den CPLD durchführen und sparst Dir den Config-Flash. Pegelwandlerschaltkreise gehen natürlich auch.
> PC104 hat standardmäßig 5V Pegel.
Wie schaffen das die neuen Industrie-PC-Boards? Da ist doch auch alles
3.3V, zB. der ISA-Bus aus der Southbridge... Ich kann mir jetzt nicht
vorstellen, dass die da Pegelwandler drinhaben...
> Wie schaffen das die neuen Industrie-PC-Boards? Es gibt da ausreichend viele Kompatibilitätsprobleme :-o Ein FPGA mit 3,3V IO-Spannung geht ja nicht sofort kaputt, wenn es mal 5V am Eingangspin abbekommt. Aber dann, das böse Erwachen ein paar Jahre später... Und wie gesagt: ISA ist tot PCI steht kurz vor dem Ende PCIe ist das aktuelle Bussystem
@Mathias: Danke für den Hinweis. Nun leuchtet mir auch wieso viele Erweiterungsboards mit CPLD und nicht mit FPGAs ausgerüstet sind. Beste Grüsse Geri
Das muss nicht unbedingt mit den 5V zu tun haben. Es könnte nur die Integration des GAL/PAL-Grabs eines alten Designs sein. Oder die benötigte Logik ist wirklich simpel, so dass es ein CPLD für ein paar EUR tut. Oder die FPGA-Konfigurationszeit ist zu lang. Oder der Entwickler hat Berührungsängste mit den komplexen FPGAs. Etc.p.p. :-)
ich habe mit einem Arm9 und mit FPGAs im geleichen System gearbeit. Diese system hatte für den FPGA einen SPI bootflash. Das ist sehr unzwckmäßig, weil, das System nur über einen JTAG programmierbar ist. Eine bessere Lösung ist einen SPI am ARM für einen JTAG umzufunktionieren. Der parallel Flash am ARM ist groß genug um so ein Bitfile mit zu speichern. Auf dem ARM9 wurde zuerst das U-boot als bootloader gestartet. Im U-boot gibt es ein Codeschnipsel, der vor dem Starten des Linux den FPGA beschreibt. Leider habe ich keinen Hinweis gefunden wie die Hardwar für diesen Codeschnipsel aussieht. Eine Bessere Grundlage bietet xc3sprog. Diese Tool läuft super und ist im Quellcode verfügbar. Damit sollte es keine Probleme geben aus der USB Schnittstelle eine SPI zu machen. Wenn du noch einen FTP server auf dem ARM laufen lässt. Kannst du das Bitfile per ftp aufschieben. Per FTP habe ich das Verzeichnis immer aktuell gehalten auch die Linuxapplikationen.
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.