Habe in meiner Thesis die Huffman-Dekodierung für einen MP3 Player in VHDL gebaut. Das war schon mal ganz interessant und ich suche jetzt nach einer Idee, was man noch so mit VHDL/FPGAs anstellen kann. Ich könnte natürlich das MP3-Dekoder Projekt weiter verfolgen, aber ist unwahrscheinlich, dass ich damit in absehbarer Zeit fertig werde. Realisiert sind im Grunde bisher nur der Huffman Dekoder und die Synthese-Filterbank. Daraus könnte man auch ein Community-Projekt machen, aber glaube nicht das da viel bei rum kommt. Ich hatte auch mal die Idee einen Sigma-Delta DAC komplett im FPGA zu bauen. Habe mir dazu mal die delta sigma toolbox von Matlab angeschaut (http://www.mathworks.com/matlabcentral/fileexchange/19-delta-sigma-toolbox). Hier gibt es auch ein Paper, wo sowas schon mal gemacht wurde: http://www.ee.usyd.edu.au/people/philip.leong/UserFiles/File/papers/dac_fpt03.pdf Aber irgendwie ist das auch nicht mal eben so zum Basteln geeignet - viel Signalverarbeitung, da qualmt der Kopf wieder so.... :-) Ansonsten würde ich das super interessant finden. Idealerweise sollte noch irgend ein Nutzen aus dem Projekt zu ziehen sein. Also entweder, das man es wirklich als "Produkt" nutzen kann (hatte auch schon an eine (Binär)-Uhr mit CPLD gedacht, ist aber eher nicht besonders anspruchsvoll) oder das es einen "akademischen" nutzen hat (wie z.B. der delta sigma DAC - ich habe bisher noch keinen mit höherer Ordnung als Open Core gefunden). Interessant würde ich halt Signalverarbeitungs-Themen finden. Ein Radio-Empfänger mit IQ Demodulation als Direktempfänger wäre auch interessant. Wollte z.B. mal eine DCF77 Antenne bauen, das Signal sampeln und weiter verarbeiten (also Phase und Amplitude raus ziehen und irgendwie auswerten). Oder Projekte bei welchen die Vorzüge eines FPGAs (Parallel-Verarbeitung und Geschwindigkeit) genutzt und auch tatsächlich benötigt werden. Jetzt zwanghaft ein Projekt mit FPGA zu realisieren ist nicht nötig, habe auch Mikrocontroller hier rum fliegen... Vielleicht hat ja jemand auch weiter führende Infos/Quellen zu den oben genannten Themen, die das ganze ein wenig einfacher machen.
Angehängte Dateien:
-
MACH_XO2_PACTRON.PNG
460 KB
Marius S. schrieb: > Oder Projekte bei welchen die Vorzüge eines FPGAs (Parallel-Verarbeitung > und Geschwindigkeit) genutzt und auch tatsächlich benötigt werden. Jetzt > zwanghaft ein Projekt mit FPGA zu realisieren ist nicht nötig, habe auch > Mikrocontroller hier rum fliegen... Na super ! Tip: Evtl eine "WIFI Mobile" BAT Driven FPGA "Low Power Anwendung" , die man am Handgelenk tragen kann. Mit einem Wifi Chip noch dazu. Microcip --> Chip: MRF24WBOMB for Wifi . Damit geht es via Handy Kopplung ins WEB. Das ist eine Weltneuheit Mobile FPGA Wifi Internet (PHONE) Kopplung. Das ist die Backplane von der Mobil Platine. Marius S. schrieb: > (hatte auch schon an eine (Binär)-Uhr mit CPLD gedacht, ist aber eher > nicht besonders anspruchsvoll) oder das es einen "akademischen" nutzen > hat (wie z.B. der delta sigma DAC - Der DAC am Handgelenk fürs Prüffeld mit Dokumentation über Wifi Gruss Holger. PS. Das ist die Front-Plane von der Mobil Platine. > (hatte auch schon an eine (Binär)-Uhr mit CPLD gedacht, JA so ganz aus GLAS {[{[{[{[ Bild zur WEB-UHR Beitrag "Lattice MachXo2 Bat.Powerd Stand Alone Soc" Microcip --> Chip: MRF24WBOMB for Wifi .LINK Beitrag "MIDI over WIFI ( RF Bluethoot Dect USB ) Homemade Interface" Und der ist über die Busleiste andock_bar als MODUL. "MACH_XO2_PACTRON.PNG"
:
Bearbeitet durch User
Marius S. schrieb: > Vielleicht hat ja jemand auch weiter führende Infos/Quellen zu den oben > genannten Themen, die das ganze ein wenig einfacher machen. MP3 Ref+ Low Power von Peter Sieg. mit ALTERA MP3 Sourcen (Arrow Elecronics FPGA Ref-Designs) Beitrag "ALTERA The Low Power Reference Platform (LPRP) = 19,99€!!" ------------------------------------------------------------------------ --- Zum anlesen Hier nur mal als Beispiel für den Wifi Chip die Com-Kopplung http://www.basic4ppc.com/android/help/serial.html Gruss Holger. TIP: ------------------------------------------------------------------------ >Idealerweise sollte noch irgend ein Nutzen aus dem Projekt zu ziehen >sein. Also entweder, das man es wirklich als "Produkt" nutzen kann Z.B ein X-Bee oben auf dem Board is ein 6 Pol-Connect Slot, damit kannst du den Data-Streem via dem Decoder Abgreifen, und lauscht damit alles ab, was rein und raus geht, also dein eigener PHY-FPGA Anschluss. ------------------------------------------------------------------------ --
:
Bearbeitet durch User
Link: Professor Bruce Land http://www.cornell.edu/search/?q=fpga&submit=go&tab= Da sind 100 Projecte- mit Project-Bildern + Doku. + Source Code. Fast alles Altera. Professor Bruce Land cornell.edu Schau mal rein bitte, da findest du sicher was, weil halt das ganz gut beschrieben ist, finde ich. Gruss Holger. Professor Bruce Land in youtube. Da sind auch Vorlesungen zum Wolfson Chip via MP3, I2C-Bus >--> 2Channel.. Wolfson MP3-Interface --------------------------------------------------------------------- Das MP3 ist in meinem obigen Link nur mit dem ALTERA Cyclon II FPGA gemacht. Die Source ist von "Arrow Electronics". ###################################################################### Title: Sound Bite Link: https://instruct1.cit.cornell.edu/Courses/ece576/FinalProjects/f2009/csm44_jck46/index.html ###################################################################### Auch Netzwerk-FPGA Karten, nur den (+/-)--PHY -- rest [FPGA]--RAM-IF.
:
Bearbeitet durch User
Wie waers mit einem kompletten Computer samt Compiler und Betriebssystem? :-) http://www.projectoberon.com Da bin ich kuerzlich drueber gestolpert. Mark
Naja, gleich nen ganzen Rechner? Es gibt ja schon Projekte dieser Art in Massen unter anderem auch das 8Bit Projekt von Josef hier im Forum. Was das Obereon Projekt angeht, sehe ich nocht nicht, auf welcher HW das läuft. Habe mir das HW PDF angesehen und auch das Daugtherboard-PDF. Wo ist die Hauptplatine? Ein Spartan Eval board? Ehrlich gesagt bin ich skeptisch mit solchen Projekten wo man auch auf dem zweiten Blick noch nicht erkennnt, wie es grundsätlich aussieht. Solche halbgut dokumentierten Projekte mag ich ganz besonders :-( Das ist aber meistens genau das, was aus solchen "Ich hau mal schnell was raus"-Ideen wird. Eine Art Selbstbefriedigung für den Erfinder, mit begrenztem Wert für andere User.
Also fuer mich war es das erste mal, dass ich nen kompletten Rechner inclusive Graphischen Betriebssystem gesehen habe. Hier gibts ein Bild. http://www.schleibinger.com/bilder/oberon.jpg Dss ganze laeuft auf einem Spartan III Board. Mark
FPGA-Projektor schrieb im Beitrag #3575389: > Wie wäre es mit einem neuen Telespiel a la FPGA Arcade für eines der > aktuellen eval-boards? Das is 3D Vector Equipment, aber sehr lange Ladezeit. Da sind von Grundlagen bis zum Kompexen X-Dim Vector-Array alles drin. FPGA Arcade Haberer Haberer suche ich noch raus, der baut Spiel(e)-Konsolen aus FPGAs, haupsächlich mit ALTERA (Cyclone II) ------------------------------------------------------------------------ Link: Für die Mathematik ...--> http://aranna.altervista.org/data2/3d_game_programming_with_DirectX11.pdf ------------------------------------------------------------------------ - Gruss Holger.
:
Bearbeitet durch User
Kannst dir evtl. auch mal mein Projekt ansehen, vielleicht findest du einige brauchbare Ideen. <Werbung> Beitrag "FPGA basierendes System" http://www.goldmomo.de </Werbung>
Vor Weihnachten wurde für den RaspberryPi und den BeagleBone ein FPGA Erweiterungsboard angekündet: http://www.heise.de/newsticker/meldung/LOGi-FPGA-Adapter-fuer-RasPi-und-BeagleBone-2069532.html?wt_mc=rss.ho.beitrag.atom Da kam auch schnell die Frage auf, was wäre ein Beispielhaftes "Killer Feature" das so eine Erweiterung rechtfertigt. Nach etwas Überlegung kam mir dann diese Idee: Aus der Kombination eines BeagleBone black mit zusammen mit dem FPGA Erweiterungsboard könnte eine sehr kompakte, performante CNC Steuerung gebaut werden. Dazu müssen zwei bestehenden OpenSource Projekte auf diese Plattform portiert werden. LinuxCNC gibt es schon für den RaspberryPi, dass heisst für den BeagleBone müsste sich das mit abschätzbarem Aufwand auch portieren lassen. LinuxCNC setzt auf die Echtzeit-Kernel Erweiterung Xenomai die es auch für ARM gibt: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RaspbianXenomaiBuild Das Zweite wäre, das HostMot2 FPGA Design portieren auf den LOGi und ab geht die Post: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HostMot2 HostMot2 wird sonst mit den AnyIO Karten von Mesa Electronics eingesetzt. Damit werden Signale für Schrittmotoren generiert, PWM Signale für Servo Steuerungen, Encoder Signale Ausgewertet etc. Denkbare Erweiterungen im FPGA reichen von Watchdog/Hartbeat Überwachung über weitere Sensorschnittstellen (Analoge Ein-/Ausgänge mit delta-Sigma :-) ), Feldbusanbindungen, Temperaturüberwachung etc.
FPGA-Projektor schrieb im Beitrag #3575946: > Naja, gleich nen ganzen Rechner? Es gibt ja schon Projekte dieser > Art in > Massen unter anderem auch das 8Bit Projekt von Josef hier im Forum. Was aber eher zu den abschreckenden Beispielen gehört...
Leute, all die Sachen, die man besser mit nem µC machen kann, sollte man auch mit nem µC machen. Also nix mit Komplettrechner, CNC-Steuerung und so. Aber es gibt ein riesiges Feld, wo ein µC überfordert ist: die digitale Signalverarbeitung. Vorschlag 1: SDR, also erstmal KW-Empfänger, dann KW-Transceiver. Vorschlag 2: ebenfalls SDR: Breitband-Empfänger, sagen wir mal 30 MHz bis 3 GHz, mit Dekodern für alles, was einem da begegnet, incl. DAB+ usw. Vorschlag 3: Wettersat-Empfänger mit Dekoder für HRPT usw. W.S.
Also es gibt durchaus Felder, bei denen man mit UCs arbeiten könnte und dennoch FPGAs eingesetzt werden. Eine CNC gehört jetzt nun nicht gerade dazu, aber PLCs werden in inzwischen mit FPGAs realisiert, z.B. von Phönix Contact. Altera hatte da mal ein Seminar, wo sie uns deren App als Beispiel für NIOS verklickert haben. Weiters ergeben sich hochperformante Versionen von existierenen DSP-Aplikationen im Consumerbereich, die aufgrund des Kostendrucks mit reduzierter Leistung gegenüber dem Machbaren verkauft werden, um einen Markt zu haben. Consumer Audio ist das ein Punkt. Mir ist da ein Projekt von der embedded in Erinnrung, wo einer eine komplette Filterbank zur Klangbearbeitung für Studios aufgebaut hat, so wie sie früher für analoge Synthesizer benutzt wurde. Und dann gibt es ja die Synthesizer selber, die seit Neuestem in FPGAs gepresst werden, wie der hier in FPGAs, die noch gar nicht lieferbar sind: http://fpgasynth.beepworld.de/cyclone.htm Das Beste sind natürlich die SDR-Projekte für die Heimanwendung, aber da kommt gleich soviel Aufwand bei raus, dass es richtig ins Geld geht. Ein SDr-Projekt mit Antennen und HF-Design und pipapo täte ich mir jetzt garnicht alleine zutrauen. Dafür habe ich meine HF-Konstruktionsheinis, die mir das basteln :-D Aber vielleicht könnte man sowas auf Langwelle mit FPGAs machen, so als virtuellen Schwingkreis. Oder gleich einen Knallfunkensender a la Marconi mit GTP-Transceivern für die Musikübertragung in den Garten, wie Gustel Buheitl.
W.S. schrieb: > Leute, > all die Sachen, die man besser mit nem µC machen kann, sollte man auch > mit nem µC machen. Also nix mit Komplettrechner, CNC-Steuerung und so. Du meinst "billiger" statt "besser". Ein FPGA kann locker die Aufgaben eines 8/16 bit uC übernehmen und dazu ein Mehrfaches an Ports und peripherieansteuerung. Digitale Filter, Graphikdisplayansteuerung, mehr Interrupts nachrüsten - kein Problem. Anders sieht es bei den embedded Prozessoren in Smartphones aus, mehrere Cores im GHz bereich - da sieht ein FPGA alt aus. Retrocomputing - also der nachbau älterer Computer wie die Homecomputer der Achtziger ist m.E. ein lehrreiches FPGA-projekt. Schau mal: Retrocomputing auf FPGA MfG
Tippgeber schrieb: > Also es gibt durchaus Felder, bei denen man mit UCs arbeiten könnte und > dennoch FPGAs eingesetzt werden. Eine CNC gehört jetzt nun nicht gerade > dazu, aber PLCs werden in inzwischen mit FPGAs realisiert Für das Protokoll, da es oben schon anders geschrieben wurde: Die CNC Steruerung selber läuft beim obigen Vorschlag auf einem 1 GHz ARM Cortex-A8 von TI. Als Basis dient ein Linux mit Echtzeiterweiterung. LinuxCNC übernimmt auch das Benutzerinterface mit Monitor/Tastatur/Maus. Trajektorien berechenungen und PID Regler für die Achspositionierung läuft auch auf dem ARM. Was dieser ARM aber nicht kann (und viele andere schnelle Prozessoren auch nicht) ist das Ausgeben von mehren (>5) PWM Kanälen bzw. Step/Direction Signalen und das einlesen von mehreren (>5) Encoder Signalen (Quadratur, Sin/Cos) dafür braucht der Prozessor Hardware unterstüztung (z. B. per FPGA), dafür steht das OpenSource FPGA Design HostMot2 zur Verfügung. Bisher waren solche Steuerungen gleich ganze PCs mit PCI Einsteckkarten. Mit dem BeagleBone und dem erwähnten FPGA Board würde das ganze auf die Grösse einer Festplatte zusammen schrumpfen.
> Die CNC Steruerung selber läuft beim obigen Vorschlag auf einem 1 GHz > ARM Cortex-A8 von TI. Als Basis dient ein Linux mit Echtzeiterweiterung. Also ein richtig performanter Microcontroller, der mit einem Multitaskingsystem so richtig schon abgebremst- , dann mit einer RTE wieder etwas datendurchsätziger gemacht wird, um dann mit C einfach und schnell arbeiten zu können. Und das soll jetzt in einen FPGA?
Technicker schrieb: > Und das soll jetzt in einen FPGA? Nein, das soll in den ARM. Aktuell gibt es nur Entwicklungsversionen für den Raspberry Pi, das ist noch nicht fertig. Aktuell läuft das alles auf einem x86 Prozessor. Technicker schrieb: > Multitaskingsystem so richtig schon abgebremst- , dann mit einer RTE > wieder etwas datendurchsätziger gemacht wird, um dann mit C einfach und > schnell arbeiten zu können. Schick mal eine Bewerbung an meinen Chef, der wird dich mögen. Er versucht gerade auf einem 1 GHz ARM ohne OS, ohne Scheduler, ohne C++, ohne Trace Debugger etc. einen additiven Synthesizer mit 80 kHz update Rate, ein TCP/IP Interface mit LXI Unterstützung und einen EtherCat Master zu Implementieren, so dass sie gleichzeitig laufen und sich nicht in die Quere kommen. Ich bin froh, dass ich ihm dabei nicht helfen muss.
Hanno schrieb: > FPGA-Projektor schrieb im Beitrag #3575946: >> Naja, gleich nen ganzen Rechner? Es gibt ja schon Projekte dieser >> Art in >> Massen unter anderem auch das 8Bit Projekt von Josef hier im Forum. > > Was aber eher zu den abschreckenden Beispielen gehört... Begründung?
Oh,Oh, da fühlt sich jemand getroffen :-) Also meine Meinng zu Josefs Projekt ist eher positiv, wenn ich auch nicht sehe, wer das einsetzen sollte ... ... wenn schon die Soft-CPUs, die turnusmässig Verwendung finden (oder fanden?) als Hw ausgelegt werden, wie ich lesen darf: Christoph Z. schrieb: > versucht gerade auf einem 1 GHz ARM ohne OS, ohne Scheduler, ohne C++, > ohne Trace Debugger etc. einen additiven Synthesizer mit 80 kHz update > Rate, ein TCP/IP Interface nun, die ersten Musiksynthesizer hatten auch kein OS und liefen prächtig. Ok, sie hatten kein TCP/IP Interface aber wer braucht das? Da hat sich Dein Chef in jedem Fall was Ordentliches vorgenommen. Wenn er es hier liest, sei ihm mein Respekt ausgesprochen. Allerdings würde ich ihn fragen, wozu er ausgerechnet 80kHz Rate braucht. Müssten das nicht 48 oder 96 sein?
Fpga Kuechle schrieb: > Du meinst "billiger" statt "besser". Ein FPGA kann locker die Aufgaben > eines 8/16 bit uC übernehmen und dazu ein Mehrfaches an Du irrst. Ich meine tatsächlich BESSER. Die allermeisten Aufgaben, die so für einen µC anstehen, kann ein FPGA nämlich überhaupt nicht besser, sondern nur schlechter oder allenfalls gleichgut, dann aber zu wesentlich höheren Kosten - und zu wesentlich höherem Entwicklungsaufwand. Hast du einen wirklich guten USB-Core oder Ethernet-Core oder DSP-Core oder sonstige Peripheriecores (SDRAM, DDRAM, SD-Card usw) in deinem Portfolio? Wohl eher nicht, du müßtest dir das alles zukaufen. Ich geb dir mal ein paar Beispiele: a) ein simpler 4 Bit Controller, der im Audioverstärker die Kanalumschaltung, die Lautstärke und die IR-Bedienung erledigt und nur ein paar Pfennige (oder Yen) gekostet hat b) eine 300 MHz Mips im DVDplayer (ESS-Chips), mit SDRAM, Farbgrafik, chipinternem 64 Bit Signalprozessor, 208er Gehäuse was noch für zweilagige LP taugt - und für den Preis eines FPGAs von einer Größe, wo sowas hineinpassen würde, könnte man 3 komplette Player kaufen. c) ein heutzutage üblicher µC, z.B. ein LPC4088, den es für ca. 8..9 Euro fertig zu kaufen gibt. Schau dir mal an, was der alles drin hat, von Gleitkomma-Rechenwerk über TFT-Controller, USB, Ethernet, SDRAM-Anschluß, riesiger interner Flash, recht großer interner RAM und und und... Glaubst du, mit einem überhaupt erschwinglichen FPGA das alles nachbilden zu können? Also: einen richtigen µC per FPGA ersetzen zu wollen, ist Mumpitz, weil man nie und nimmer an das Preis/Leistungs-Verhältnis herankommt und alerhöchstwahrscheinlich auch die auf dem Chip verbauten Cores nie und nimmer durch was Eigenes ersetzt kriegt. Es gibt nur eine Ausnahme: Wenn ein tolles Ing-Büro Auftragsarbeiten macht und die Innereien ihres Werkes auf keinen Fall preisgeben will, wäre ein FPGA ne geeignete Hardware, um Rechte an dem darin verbauten Gehirnschmalz zu erheben. Aber das ist kein technisches Kriterium. W.S.
W.S. schrieb: > Also: einen richtigen µC per FPGA ersetzen zu wollen, ist Mumpitz, weil > man nie und nimmer an das Preis/Leistungs-Verhältnis herankommt und > alerhöchstwahrscheinlich auch die auf dem Chip verbauten Cores nie und > nimmer durch was Eigenes ersetzt kriegt. > > Es gibt nur eine Ausnahme: Wenn ein tolles Ing-Büro Auftragsarbeiten > macht und die Innereien ihres Werkes auf keinen Fall preisgeben will, > wäre ein FPGA ne geeignete Hardware, um Rechte an dem darin verbauten > Gehirnschmalz zu erheben. Aber das ist kein technisches Kriterium. +1
Na, ein paar mehr Gründe gibt es schon, FPGAs statt eines fertigen Controllers zu nehmen, als da wären: - Supportverpflichtungen, Lieferbarkeit und Absicherung gegen Abkündigung. Es gibt mehr als eine Firma, die alte Prozessoren und deren FW mit FPGA Code absorbiert, um dem nachzukommen und immer wieder parat zu haben - Resistenz gegenüber nachträglich gemeldeten bugs in den Prozessoren, die man im Feld nur per FPGA updaten kann, - minimale Modifikationen der Funktion, um ein Alleinstellungsmerkmal zu erzielen - nötige Änderungen der Funktion, um kundenspezifische Optimierungen zu erwirken ... wobei die letzten beiden Punkte kein 1:1 replacement wären. Grundsätzlich hat W.S. natürlich Recht: Was mit einem Prozessor zu machen ist, sollte mit einem solchen gemacht werden. Allerdings ist das insofern eine etwas luftige Diskussion, als dass Prozessoren in grossen Massen ja für all die Fälle verfügbar gemacht werden, die Standard sind und viele Applikationen abdecken, während FPGAs eben für das genaue Gegenteil erdacht wurden. Der ständige Vergleich FPGAs <-> MCs ist also ein müßiger. Ich habe mithin den Eindruck, dass in nicht wenigen Applikationen ein Softcore oder eine Software auf einem Hardcore nur deshalb eingesetzt werden, weil sie eben da sind oder weil die Software da war oder weil der Bearbeiter einen Softwarehintergrund hat und sich damit sicherer fühlt.
@ W.S. (Gast) >Du irrst. >Ich meine tatsächlich BESSER. Stimmt. >Die allermeisten Aufgaben, die so für einen µC anstehen, kann ein FPGA >nämlich überhaupt nicht besser, sondern nur schlechter oder allenfalls >gleichgut, dann aber zu wesentlich höheren Kosten - und zu wesentlich >höherem Entwicklungsaufwand. Stimmt, wobei man dabei klar betonen muss "die so für einen µC anstehen". Und es ist logisch, dass es unsinnig ist, einen ASIC wie so einen uC in einem FPGA nachzubauen. Das ist bestenfalls eine akademische Fingerübung. >a) ein simpler 4 Bit Controller, der im Audioverstärker die >Kanalumschaltung, die Lautstärke und die IR-Bedienung erledigt und nur >ein paar Pfennige (oder Yen) gekostet hat Klar. >b) eine 300 MHz Mips im DVDplayer (ESS-Chips), mit SDRAM, Farbgrafik, >c) ein heutzutage üblicher µC, z.B. ein LPC4088, den es für ca. 8..9 >Euro fertig zu kaufen gibt. Schau dir mal an, was der alles drin hat, >Also: einen richtigen µC per FPGA ersetzen zu wollen, ist Mumpitz, weil >man nie und nimmer an das Preis/Leistungs-Verhältnis herankommt und Stimmt. Eine Aufgabe, für die es einen gut geeigneten uC/ASIC gibt, löst man am besten mit eben diesem (technisch wie ökonomisch). Aber für Aufgaben, für die es leistungsmässig oder funktional keinen passenden uC gibt, braucht man ein FPGA. Sei es wegen des hohen Datendurchsatzes oder wegen eher mittelschneller oder sogar langsamer Gluelogic, die durchaus mal ein mittleres FPGA füllen kann.
Eine Idee zum Thema: Wie wäre es mit einem Konfigurationstool für FPGAs? Wir haben nach wie vor keine sinnvolle FPGA-spezifische Versionsverwaltung, Entityverwaltung und Packageverwaltung.
W.S. schrieb: > Fpga Kuechle schrieb: >> Du meinst "billiger" statt "besser". Ein FPGA kann locker die Aufgaben >> eines 8/16 bit uC übernehmen und dazu ein Mehrfaches an > > Du irrst. > > Ich meine tatsächlich BESSER. > > Die allermeisten Aufgaben, die so für einen µC anstehen, kann ein FPGA > nämlich überhaupt nicht besser, sondern nur schlechter oder allenfalls > gleichgut, Nö, I2c, SPI, Timer und die übliche uC-Aufgaben kann jeder FPGA in (fast) beliebiger Anzahl und mit (fast) beliebigen Parametern). 4 UARTS, 2x I"C Slave, 1I2C Master und 3x McBSP parallel kein Problem für einen FPGA. > > Hast du einen wirklich guten USB-Core oder > Ethernet-Core oder DSP-Core oder sonstige Peripheriecores (SDRAM, DDRAM, > SD-Card usw) in deinem Portfolio? USB und Ethernet lagert man schon wegen der speziellen Signalpegel in externe IC's aus, FPGA-Memorycontroller sind Standard, die gibts als Soft- und zuweilen auch als Hardcore gratis dazu, ebenso DSP-Cores (Filter). > Wohl eher nicht, du müßtest dir das > alles zukaufen. Nö, nix Zukauf; vieles gibts geschenkt (siehe unten); das meiste schreibt man selbst. > Ich geb dir mal ein paar Beispiele: > a) ein simpler 4 Bit Controller, der im Audioverstärker die > Kanalumschaltung, die Lautstärke und die IR-Bedienung erledigt und nur > ein paar Pfennige (oder Yen) gekostet hat Das ist billiger, nicht besser. > b) eine 300 MHz Mips im DVDplayer (ESS-Chips), mit SDRAM, Farbgrafik, > chipinternem 64 Bit Signalprozessor, 208er Gehäuse was noch für > zweilagige LP taugt - und für den Preis eines FPGAs von einer Größe, wo > sowas hineinpassen würde, könnte man 3 komplette Player kaufen. das ist keine 8/16bit mikrocontroler-Anwendung > c) ein heutzutage üblicher µC, z.B. ein LPC4088, den es für ca. 8..9 > Euro fertig zu kaufen gibt. Schau dir mal an, was der alles drin hat, > von Gleitkomma-Rechenwerk über TFT-Controller, USB, Ethernet, > SDRAM-Anschluß, riesiger interner Flash, recht großer interner RAM und > und und... Glaubst du, mit einem überhaupt erschwinglichen FPGA das > alles nachbilden zu können? Auch das ist billiger und nicht besser, 96 kbyte onboard SRAM sind heutzutage kein problem mehr für einen FPGA. Bspw. hat der XC6SLX25 bereits 100 kbyte. Dazu 2 Hardware-Memorycontroller und genügend Logik-Resourcen für mehrere Displaycontroller oder Numerik-Coprozessoren. Nicht zu vergessen die 38 DSP-Blöcke, von denen jeder einzelner einen Hardware-Multiplizierer mitbringt. Soviel Flash hat ein FPGA zwar nicht, aber dafür ist dank der Gigabit-Tranceiver die es inzwischen auch in den preiswerternen FPGA's gibt auch eine SATA-Silicon Disc angeschlossen -> rasant schneller Flash zum Abwinken > Also: einen richtigen µC per FPGA ersetzen zu wollen, ist Mumpitz, weil > man nie und nimmer an das Preis/Leistungs-Verhältnis herankommt wurde ja auch nicht behauptet > und > alerhöchstwahrscheinlich auch die auf dem Chip verbauten Cores nie und > nimmer durch was Eigenes ersetzt kriegt. Nö, stimmt für die kleinen Mikrocontroller nicht. Bspw. ist ein PCI-Core schon fast üblich für ein FPGA, das gibt es erst bei der Klasse der embedded Prozessoren. Komplett selber schreiben ist meist auch nicht nötig, schau mal auf http://opencores.org/projects was da so alles verschenkt wird. Nicht zu vergessen was für die Hauseigenen Softcores an Periepheriecontrollern samt SDK mitgeliefert wird. Oder die Nachbauten an 16 bit computern die sich schon mit den ältlichen Spartan3 - FPGA realisieren lassen, inklusive der CPU. Das hab ich noch auf keinem mikrocontroller gesehen. Es gibt kaum Anwendungen die ein uC wirklich "besser" kann als ein FPGA. Ein uC ist ein billige Generealist, ein FPGA ein Spezialist der seinen Preis hat, dafür aber den 0815 Kram eines Generalisten nebenher mitmacht. Deshalb integrieren immer mehr FPGA-Anwendungn den IO-uC im FPGA, anstatt einen externen uC dazuzupacken (Microblaze, NIOS). MfG
Ingenieur offline schrieb: > Eine Idee zum Thema: Wie wäre es mit einem Konfigurationstool für FPGAs? > Wir haben nach wie vor keine sinnvolle FPGA-spezifische > Versionsverwaltung, Entityverwaltung und Packageverwaltung. Da hast du ein wunden Punkt aufgedeckt. Ich hatte immer mal ein Auge auf ein Tool. http://sourceforge.net/projects/kactus2/ Habe es aber gerade aus dem Auge verloren, wie weit die Entwickler sind. Wenn jemand weiterführende Info hat, auch an mich.
@ Fpga Kuechle (fpgakuechle) Benutzerseite >Nö, I2c, SPI, Timer und die übliche uC-Aufgaben kann jeder FPGA in >(fast) beliebiger Anzahl und mit (fast) beliebigen Parametern). 4 UARTS, >2x I"C Slave, 1I2C Master und 3x McBSP parallel kein Problem für einen >FPGA. Reichlich Verschwendung für ein FPGA ;-) >> a) ein simpler 4 Bit Controller, der im Audioverstärker die >> Kanalumschaltung, die Lautstärke und die IR-Bedienung erledigt und nur >> ein paar Pfennige (oder Yen) gekostet hat >Das ist billiger, nicht besser. Muss man WIRKLICH auif so ein billiges Beispiel anspringen? >> b) eine 300 MHz Mips im DVDplayer (ESS-Chips), mit SDRAM, Farbgrafik, >> chipinternem 64 Bit Signalprozessor, 208er Gehäuse was noch für >> zweilagige LP taugt - und für den Preis eines FPGAs von einer Größe, wo >> sowas hineinpassen würde, könnte man 3 komplette Player kaufen. >das ist keine 8/16bit mikrocontroler-Anwendung >Auch das ist billiger und nicht besser, 96 kbyte onboard SRAM sind >heutzutage kein problem mehr für einen FPGA. Bspw. hat der XC6SLX25 >bereits 100 kbyte. Dazu 2 Hardware-Memorycontroller und genügend >Logik-Resourcen für mehrere Displaycontroller oder >Numerik-Coprozessoren. Nicht zu vergessen die 38 DSP-Blöcke, von denen >jeder einzelner einen Hardware-Multiplizierer mitbringt. Soviel Flash >hat ein FPGA zwar nicht, aber dafür ist dank der Gigabit-Tranceiver die >es inzwischen auch in den preiswerternen FPGA's gibt auch eine >SATA-Silicon Disc angeschlossen -> rasant schneller Flash zum Abwinken Alles schön und gut und heute erstaunlich billig, aber die Silikoneffizienz von FPGAs ist nun mal prinzipbedingt schelchter als die von ASICs. >Oder die Nachbauten an 16 bit computern die sich schon mit den ältlichen >Spartan3 - FPGA realisieren lassen, inklusive der CPU. Das hab ich noch >auf keinem mikrocontroller gesehen. Klar, gab es auch schon, ARM-Emulator auf dem AVR ;-) Schöne Speilerei, sicherlich auch ein gutes Lernobjekt, aber keine Praxisanwending. >Es gibt kaum Anwendungen die ein uC wirklich "besser" kann als ein FPGA. Ach komm schon, hast du wirklich sooo einen FPGA-Tunnelblick? >Ein uC ist ein billige Generealist, ein FPGA ein Spezialist der seinen >Preis hat, dafür aber den 0815 Kram eines Generalisten nebenher >mitmacht. Mit goldenen Bits ;-) >Deshalb integrieren immer mehr FPGA-Anwendungn den IO-uC im FPGA, >anstatt einen externen uC dazuzupacken (Microblaze, NIOS). Alles hat seinen Platz, aber billiger ist es nicht immer.
Hardwarespezi schrieb: > Christoph Z. schrieb: >> versucht gerade auf einem 1 GHz ARM ohne OS, ohne Scheduler, ohne C++, >> ohne Trace Debugger etc. einen additiven Synthesizer mit 80 kHz update >> Rate, ein TCP/IP Interface > > nun, die ersten Musiksynthesizer hatten auch kein OS und liefen > prächtig. Ok, sie hatten kein TCP/IP Interface aber wer braucht das? > > Da hat sich Dein Chef in jedem Fall was Ordentliches vorgenommen. Wenn > er es hier liest, sei ihm mein Respekt ausgesprochen. Allerdings würde > ich ihn fragen, wozu er ausgerechnet 80kHz Rate braucht. Müssten das > nicht 48 oder 96 sein? Er hat sich das nicht "vorgenommen" das ist sein aktueller Job, mir wäre es völlig egal, wenn er so in seiner Freizeit programmiert. TCP/IP steht im Pflichtenheft, 80 kHz weil die Leistungselektronik so schnell taktet (Keine Musik sondern Leistungselektronik für Prüflabore). Das Problem ist nicht, das es nicht geht. Sondern das mit dem gewählten Ansatz es so gut wie unmöglich ist, dass mehr als ein Entwickler daran arbeitet, dass die Fehlersuche und das einhalten der Harten-Echtzeit mit der Länge des Codes immer schwieriger wird (Weil keine Partitionierung und zu wenig Kontrolle der Prioritäten).
Josef G. schrieb: > Hanno schrieb: >> FPGA-Projektor schrieb im Beitrag #3575946: >>> Naja, gleich nen ganzen Rechner? Es gibt ja schon Projekte dieser >>> Art in >>> Massen unter anderem auch das 8Bit Projekt von Josef hier im Forum. >> >> Was aber eher zu den abschreckenden Beispielen gehört... > > Begründung? Hunderte Signale, die in ca. 50 Prozessen miteinander in Verbindung stehen, dazu 2 Takte, vermutlich haufenweise Latches. Das sollte Begründung genug sein, ansonsten gibt es ja noch unzählige andere Threads, wo dein Projekt kritisiert wird. Respekt, dass du es durchgezogen hast, aber es ist wirklich ein abschreckendes Beispiel.
Alexander F. schrieb: > vermutlich haufenweise Latches. Vielleicht eine handvoll, und die sind bewusst eingebaut. > noch unzählige andere Threads, Ich kenne nur zwei. Siehe meine Benutzerseite.
Alexander F. schrieb: > Josef G. schrieb: >> Hanno schrieb: >>> FPGA-Projektor schrieb im Beitrag #3575946: >>> Was aber eher zu den abschreckenden Beispielen gehört... >> >> Begründung? > > Hunderte Signale, die in ca. 50 Prozessen miteinander in Verbindung > stehen, dazu 2 Takte, vermutlich haufenweise Latches. > Das sollte Begründung genug sein, ansonsten gibt es ja noch unzählige Also mich schreckt eher ein Design ab, in dem es nur einen einzigen Prozess gibt. FF nach Funktionsgruppen in dedizierte Prozesse zu packen ist Kernelement eines strukturierten designs - "Divide et impera". Und eine CPU braucht eben mehr interne Steuersignale als ein simpler counter. Sind halt Tausende Gatter die verschaltet werden wollen. Mehr als einen Takt ist heutzutage auch Stand der Technik: Core Takt umd Mem-IO Takt. MfG,
> vermutlich haufenweise Latches Vermutungen sind an der Stelle schlecht. Besser wäre es, sie zu lokalisieren und dem Erzeuger einen Tipp zu geben, dort nachzubessern - so es welche gibt und diese stören. > Mehr als einen Takt ist heutzutage auch Stand der Technik: > Core Takt umd Mem-IO Takt. Gehört der Speichertakt zur CPU? wie löst man das am Saubersten?
Marius S. schrieb: > ich suche jetzt nach einer Idee, was man noch so mit VHDL/FPGAs anstellen > kann. Ich find die Seite hier recht schick: http://www.fpga4fun.com/
Frank Petelka schrieb: >> Mehr als einen Takt ist heutzutage auch Stand der Technik: >> Core Takt umd Mem-IO Takt. > Gehört der Speichertakt zur CPU? > wie löst man das am Saubersten? Core Takt umd Mem-IO Takt ist hier ein von mir gewähltes beispiel das so nix mit dem 8Bit Projekt von Josef zu tun haben muß. Ich denk da an PC-CPU#s mit Core Takt im GHz-Bereich und DDR-RAM takt deutlich drunter. Dazwischen ist der cache. Der memory takt kann vom CPU-Takt abgeleitet sein oder auch nicht. Dann nimmt man hald DualPortSpeicher oder FiFO's mit seperaten Takt für Speicher und CPU-Seite. So was hat heute ein FPGA schon "an Bord" siehe BlockRAM. MfG,
René D. schrieb: > Ingenieur offline schrieb: >> Eine Idee zum Thema: Wie wäre es mit einem Konfigurationstool für FPGAs? >> Wir haben nach wie vor keine sinnvolle FPGA-spezifische >> Versionsverwaltung, Entityverwaltung und Packageverwaltung. > > Da hast du ein wunden Punkt aufgedeckt. > Ich hatte immer mal ein Auge auf ein Tool. > http://sourceforge.net/projects/kactus2/ > > Habe es aber gerade aus dem Auge verloren, wie weit die Entwickler sind. > Wenn jemand weiterführende Info hat, auch an mich. Es dröppelt vor sich hin, wie so viele sourceforge Projekte. Wenn es keinen Projektleiter gibt, gibt es keine Ergebnisse. Ob VHDL oder Software ist egal. Und daran kranken die Projekte. Allesamt. Und es fehlt an der -kritikfähigkeit, wenn unsereins denen was schreibt und sie beraten will ...
Mit einem FPGA lassen sich Daten in Echtzeit beobachten, damit eignen sie sich meines Dafürhaltens für die Datenanalyse. Könnte man mit einem FPGA eine Echtzeitbeobachtung für Ethernet und andere Protokolle bauen?
Klar, wieso auch nicht? Ist vermutlich nicht so ganz einfach weil du dann irgendwie die Packete zerlegen wollen wirst. Ich würde dafür Wireshark nehmen, das kann das auch und viele Switches können Ports spiegeln.
Ja, aber das Problem ist, das WS nur gültige Pakete empfangen kann und man nicht weiss, was los ist, wenn es NICHT geht.
Ach so, ja stimmt. Klar das wäre ein Projekt, aber eher ein arbeitsintensives. Ich habe von Netzwerken kaum Ahnung, aber ich würde die Auswertung nicht in VHDL machen, dafür würde ich eine CPU nehmen. Netzwerkkarten gibt es auch schon fertig und echt günstig. Also dafür würde ein normaler PC reichen, das im FPGA zu machen ist zwar vermutlich sehr lehrreich, aber extremst komplex. Wober ... es kann natürlich sein, dass die ganzen ferigen Netzwerkkarten nur Packete mit richtiger Checksumme akzeptieren. Wenn du also alles empfangen willst kannst du mit einem FPGA dieses Teilstück bauen, also das Teil das einfach alles was über die Netzwerkbuchse reinkommt an Software weiterreicht und eben nicht vorher prüft. Man könnte das auch dahin erweitern, dass man in der Software dann Filter einstellen kann also für Packettypen - und das dann im FPGA gemacht wird.
Schon reichlich mühsam die Suche nach sinnvollen Anwendungen, was? Aber hier steht wohl eher der Spaß an komplizierter Technik im Vordergrund ;) Nehmt im konkreten Projekt aber dann nen simplen AVR/PIC und gut ist...
Also das kommt sehr auf die Datenrate an. Also komplettes Gigabit macht so ein AVR nicht mit. Aber FPGA und AVR geht vermutlich. Der AVR stellt im FPGA den Filter ein welche (wenigen) Packete der durchlassen soll, und diese kann der AVR dann auswerten. Aber auch sonst wäre es eigentlich hybsch mal mit FPGA Netzwerk zu machen und das dann über PCIe an den Computer zu übergeben. Da lernt man bestimmt einiges.
Elektrotechniker im Urlaub schrieb: > Mit einem FPGA lassen sich Daten in Echtzeit beobachten, damit eignen > sie sich meines Dafürhaltens für die Datenanalyse. Könnte man mit einem > FPGA eine Echtzeitbeobachtung für Ethernet und andere Protokolle bauen? paket parsing 400 Gbit/s mit Virtex-7: http://www.xilinx.com/innovation/research-labs/conferences/ANCS_final.pdf Bloom filter: http://test.algo-logic.com/~jwlockwd/publications/hoti11_bloom.pdf Deep Paket Inspection with Hardware support: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-156.pdf MfG,
Elektrotechniker im Urlaub schrieb: > Ja, aber das Problem ist, das WS nur gültige Pakete empfangen kann und > man nicht weiss, was los ist, wenn es NICHT geht. Das ist nicht das Problem von Wireshark. Das hängt von der darunterliegenden lib und der verwendeten Netzwerkkarte ob alle Pakete durchgeleitet werden. Es gibt verschieden Stellen wo Pakete ausgefilter werden. Es gibt da so eine Möglichkeit. Ich hatte es mal versucht, aber alle bei mit verbauten Netzwerkkarten konnten da nicht. Man sieht aber bei ei er Punkt zu Punkt Verbindung ohne Last an der LED ob sinnlose Paket auf den Ether sind.
Tippgeber schrieb: > Und dann gibt es > ja die Synthesizer selber, die seit Neuestem in FPGAs gepresst werden, das habe ich auch verfolgt ja. Für mich wären solche Projekte sehr interessant, weil ich auch Musik mache und mit einer Band auch Geld damit verdiene. Ich habe auch schon öfters überlegt und Ideen gehabt, was man so bauen könnte, aber: Ich bin nicht so sicher, ob es wirtschaftlich ist, einen Audioprozessor oder einen Synthesizer komplett in VHDL zu bauen. Ok, es gibt da einige, die das gemacht haben - die bekanntesten sind sicher der FPGA-Synth von Chris Stellis oder die Schaltungen von Theo van Elst. Die sind aber alle irgendwo stecken geblieben und es gibt keine wirklichen Anwendungen davon, was wohl daran liegt, dass die Meisten, die so etwas bauen, keine richtigen Musiker sind und die Kiste dann nicht wirklich verwenden. Andere wiederum, die es verwenden könnten, sind aber nicht dazu in der Lage, das weiter zu bauen, weil sie keine FPGA-Entwickler sind. Von daher sind die FPGAs für Musikproduktion technisch vielleicht ganz interessant, weil sie eine gigantische Klangqualität und Stimmvielfalt ermöglichen und man sogar eigene Geräte bauen könnte, aber das, was es bisher gibt, ist musikalisch nicht unbedingt nützlich oder nicht praktikabel. Es gibt nur wenige Musiker, die wirklich programmieren und die nehmen sich dann lieber eine fertige DSP-Plattform wie den Nord Lead. Da kann man virtuell am Bildschirm verkabeln. Das kapieren die Meisten noch, wobei ich sagen muss, dass unser Keyboarder da auch nicht mehr viel macht: Einmal ein Setup eingestellt, wird es verwendet. Rumgespielt wird nur bei der Suche nach neuen Klängen. Der einzige FPGA-Synthesizer, der wohl auch in Musikproduktionen eingesetzt zu werden scheint, ist der Pyratone von Jürgen Schuhmacher (user engineer), aber den wird man nicht so einfach nachbauen oder umbauen können, zumal der Code nicht offen ist. Blieben noch die open projects, wie man sie auf Github und open cores findet, aber da ist die community klein. Oft werden sie entwickelt und mit großem Enthusiasmus als open source angekündigt, dann aber geht es nicht mehr voran. Bei dem vor einem Jahr angekündigten Cylone-IV-Synth von Rolf Sassinger , siehe oben, hat sich nicht mehr viel getan. Noch ärmer sieht es bei den vielen Abschlussarbeiten aus: Bald jede Hochschule hat jährlich irgendein Projekt mit einem FPGA-MIDI-Synthesizer, aber die Produzieren nichts, was es nicht schon in den 70ern besser gab und heraus kommen nur ein paar Dudeltöne. Das ist überhaupt nicht zu gebrauchen und hat auch mit Musik nichts zu tun. Für einen richtigen FPGA-Synthesizer-Prozessor bräuchte es nach meiner Meinung dann auch irgendeine Art von Baukasten, mit dem der Nutzer auch klarkommt. Auf VHDL als Musikprogrammiersprache zu setzen, halte ich für eine Sackgasse. Ich möchte nicht in Bergen von Code suchen, wo ich Schnittstellen finden kann, um etwas eigenes einzufügen und mich umständlich in Spezialarchitekturen hineindenken. Genau genommen, will ich das nicht mal für C-Software tun. Allenfalls das Projekt von Rene Böllhof (user theMason) ist frei verfügbar und wäre in Software zu programmieren. Da ginge was, denke ich, weil man in C oder ASM nun mal leichter denken kann und nicht gezwungen ist, die Hardware zu ändern, wenn man nicht will. Es käme aber darauf an, eine Hardware zu haben, die Musikschnittstellen hat, die man kaufen und direkt einsetzen kann. Daran scheitert es ja meistens. Und dann braucht es eine gute Doku und ein modulares Design, das auf den ersten Blick verständlich ist.
Wenn ich richtig informiert bin, dann ist in "neuem" KURZWEIL Forte ein FPGA untergebracht. Mich juckt es in den Fingern das Teil zu kaufen und auseinander zuschrauben... :-) Du hast aber Recht, dass kein Musiker in VHDL was machen möchte. Das komplette System muss Open Source sein. Dazu muss das FPGA Design ausgegorren sein UND die Software drumherum dazu (GUI um zu experementieren). Kein Debugger oder JTAG USB Blaster, sondern einfach schön mit einer APP oder über USB. Dazu muss es viele (Sound)Beispiele geben. Um das alles zu bewerkstelligen braucht man Leute, viele Leute. Und das ist genau das Problem. Damit jeder so eine Entwicklungsplattform hat, muss es irgendwas Arduino-/RPi mäßiges geben, mit Audioschnittstellen und dann auch noch preiswert. Wieviele sind bereit dafür Geld auszugeben? Mit 50 Euro ist man vielleicht gerade so beim Selbskostenpreis, wenn man Glück hat. Um auf diesen Preis zu kommen müsste man vielleicht 500-1000 Stück verkaufen. Es werden sich aber maximal 10-20 finden, und diese Leute werden auch noch unterschiedliche Wünsche haben: "ich möchte bessere DACs", "ich brauche Xilinx", "ich brauche zwei Stereo-Eingänge, statt einen"... Tja, es ist nicht einfach... Grüße Kest
Roland hat hat glaube Ich auch einen Synthy im portefolio. Scheint eine Art von Tb303 clone zu sein.
musicker schrieb: > Roland hat hat glaube Ich auch einen Synthy im portefolio. Scheint eine > Art von Tb303 clone zu sein. Roland hat generell viele Synthesizer im Portfolio. Hat einer davon speziell etwas mit diesem Thread zu tun?
musicker schrieb: > Der AIRA hat wohl einen solchen Fpga drin. Ja, es gibt einige, die FPGAs drin haben und dies zu unterschiedlichen Zwecken. Nicht alle machen damit ausschließlich oder überhaupt Klangsynthese und die, welche es tun, z.T. auch aus Gründen der langfristigen Kosteneinsparung, in dem sie bestimmte Funktionen später in einen digitalen ASIC packen. So macher FPGA-Synth der momentan rumlungert, dürfte eine Art Prototyp sein. Musik mit FPGAs ist ziemlicher Luxus und nur gerechtfertigt, wenn hinten auch eine angemessene Qualität rauskommt, was ich bei keinem der mir bekannten derzeitigen Produkte beobachte. Die sind - auch wegen der Schnittstellen MIDI rein und Audio raus, immer noch limitiert. Selbst, wenn 192kHz rauskommen sollen und USB-MIDI verarbeitet wird, was schon das höchste der Gefühle ist, kann man auch auf Prozessoren setzen. Mit einer Handvoll DSPs lässt sich das alles viel billiger bauen, stromsparender betreiben und vor allem leichter pflegen und ich stimme zu, dass bei einem Selbstbausystem die Pflege, Modularität etc das Entscheidende ist. Als ich vor über 10 Jahren begann, FPGAs herzunehmen, waren die Prozessoren und Interfaces einfach noch nicht so weit und auch die Qualität der VA-Synths nicht wirklich virtuell analog. Das hat sich ja nun schon geändert. Von dem her ist es umso interessanter, dass nun einige Hersteller damit anfangen. Einige rühmen sich sogar, die jeweils ersten gewesen zu sein, die FPGAs eingesetzt haben wollen, aber bei genauerer Betrachtung sind das genau die, die es in den letzten 10 Jahren verpennt haben, Innovationen an den Start zu bringen und nun probieren, ihre alten Analogkisten neu zu vermarkten, indem sie sie in Hardware gießen :-) Nun gut, schauen wir, wie groß der Markt dafür ist. In Zeiten, in denen man für kleines Geld einen Blofeld kaufen kann, sehe ich keine große Chance für FPGA-Synthesizer, jedenfalls nicht, für hochkarätige. Der Bedarf an hoher Klangqualität ist einfach nicht da.
Martin K. schrieb: > Für einen richtigen FPGA-Synthesizer-Prozessor bräuchte es nach meiner > Meinung dann auch irgendeine Art von Baukasten, mit dem der Nutzer auch > klarkommt. Deine und Kests Forderung kann ich nachvollziehen, aber sie widerspricht ja gerade der flexiblen und auch effektiven Nutzung von FPGA-Hardware. Alles, was es in einem Baukasten gibt, müsste definiert und vorgearbeitet werden und es müsste standardisierte Schnittstellen zwischen den Modulen geben. Welche Module und Strukturen soll man anbieten? Nur eine flexible, selber definierte, also offene Struktur, schafft Raum. Dass da nicht alles mit allem zu verheiraten ist, liegt in der Natur des Sache. All das reduziert auch die Möglichkeiten, in einem FPGA wirklich etwas SCHNELL zu machen - vor allem eine pipeline lässt sich damit nur statisch aufziehen und nicht dynamisch, wie ich es mache. Damit werden die FPGAs langsam und unwirtschaftlich. Aus meiner Sicht ist das nicht nötig, weil "analog" dazu betrachtet, auch bei den klassischen Synthesizern immer Kabel gezogen werden. In meinem Fall werden sie eben virtuell gezogen. Damit muss man sich auseinandersetzen. Zudem gibt es ja mit Simulink und anderen Tools schon Optionen, Cores zusammenzuklicken. Aber das, was damit geht, gibt es in Synthesizern schon. Interessant ist ja eben das, was es in anderen Geräten NICHT gibt. Alles weitere dazu in diesem thread: Beitrag "Suche Mitwirkende für Universal-FPGA board"
Alexander F. schrieb: > ansonsten gibt es ja noch unzählige > andere Threads, wo dein Projekt kritisiert wird. Es wird kritisiert, aber fast immer unsachlich und ohne Begründung. Oder kannst du mal eine stichhaltige Begründung zitieren? Beitrag "8bit-Computing mit FPGA"
Jürgen S. schrieb: > sehe ich keine große > Chance für FPGA-Synthesizer, jedenfalls nicht, für hochkarätige. Nun, die Firma Roland scheint ja wohl Bedarf für FPGA-Synthesizer zu sehen und die sind ja offenbar "hochkarätig" :-) Josef G. schrieb: > kannst du mal eine stichhaltige Begründung zitieren? Meine Begründung wäre, dass die Zeit für 8bit-Computer vorbei ist. Das ist Technologie aus den 80ern, die niemand mehr sinnvoll einsetzen kann. Im Übrigen gilt dies hier schon oben Gesagte: Beitrag "Re: Ideen für FPGA-Projekte?" Kest schrieb: > Mit 50 Euro ist man vielleicht gerade so beim > Selbskostenpreis, wenn man Glück hat. Um auf diesen Preis zu kommen > müsste man vielleicht 500-1000 Stück verkaufen Bei einer Platine mit einem leistungsfähigen FPGA kannst Du soviel verkaufen, wie Du willst und wirst niemals auf 50,- kommen. Da muss man anders rangehen: 1) Marktanalyse 2) Bedarfsanalyse 3) Kostenschätzung 4) Entwicklungsschätzung 5) time-to-market 6) Gewinn und Rendite 7) Entscheidung
FPGA-Projektor schrieb im Beitrag #4447628: > Nun, die Firma Roland scheint ja wohl Bedarf für FPGA-Synthesizer zu > sehen und die sind ja offenbar "hochkarätig" :-) Ohne auf die Details der Roland-Architektur abzuheben, stelle ich doch mal in Frage, ob hier ein FPGA wirklich zur Klangsynthese nötig war und warum. Generell: Richtig ist, dass man mit FPGAs für eine dedizierte Grenzfrequenz eine genügende gute Granularität darzustellen in der Lage ist, um die "analogtypischen" Effekte, also die Einflüsse von Ungenauigkeiten, Nichtlinearitäten und Rauschen im Zeitbereich, also auf der Basis physikalischer Ereignisse in die Rechnung einfließen lassen zu können, ohne sie erst abstrakt-mathematisch durch Gleichungen abbilden zu müssen, wodurch man zu einem natürlichen Verlauf der Oszillatoramplituden und -phasen mit all den real entstehenden Oberwellen, Transienten und Offsets etc gelangt. Dies gelingt bei einem typischen Aufbau der zur Realisation der DGL 2.Ordnung nötigen Elemente samt Einflussoptionen im FPGA ohne Taktung oder Pipeline bis etwa 1/10 der Abtastfrequenz, d.h. der so erzeugte selbstschwingende Generator kehrt nach minimal 10 Takten zu seinem Anfangswert zurück. Will man das jetzt analog genau, also auf praktisch rund 100dB genau machen, braucht es entweder eine sehr hohe Y-Auflösung, die dann im FPGA wieder einige FF-Takte zusätzlich nach sich zieht oder man akzeptiert eine geringe Grenzfrequenz - hat also sozusagen eine höhere Abtastfrequenz. Will man zudem eine quasi Synchronität zwischen Einfluss und Wirkung, muss man wenigsten über 2 Loops hinweg denken. Realistisch sind da also 1/20/2 etc = 1/40 der Frequenz. Das ist ein guter trade off zwischen Abtastung und Bedarf an Rechenelementen wegen der Genauigkeit. Bei meinem ersten Versuch dieser Art hatte ich ein 10 MHz PLD zur Verfügung und gelangte folgerichtig zur "analogen" Rate von rund 500kHz. Diese ist schon absolut fein genug, um sie mit 44kHz, 48kHz oder was auch immer unsynchronisiert abtasten- und dennoch sauber abbilden zu können, wenn sie digital ausgegeben werden soll. Da damit aber nur Frequenzen bis maximal 20kHz Oberwelle produziert werden, waren die entsprechend hypergenau. Aber: Heute sind wir bei zwar bei der 4-fachen Abtastrate, haben aber effektiv 20mal schnellere FPGAs. Die DSPs und Prozessoren sind auch erheblich schneller und vor allem genauer geworden. Wozu man also 1. bei der heutigen Prozessortechnologie überhaupt- und 2. im konkreten Fall unbedingt FPGAs braucht, um (wörtlich der AIRA-Beschreibung entnommen) "4 fette Oszillatoren" zu erzeugen, ist mir nicht schlüssig. Meine VAs sind vielleicht nicht so komplex wie die vom Grossen R, aber im pipeline-Betrieb generieren sie je nach Abtastrate / Taktfrequenz mehrere Tausend Stimmen gleichzeitig per Architekturelement. Dazu folgende Betrachtung: Die "Fettigkeit" von Oszillatoren äußert sich bei FPGAs ja "lediglich" in der Komplexität der Schaltung und damit der Länge der Rechenpipeline und selbst bei einem überfetten Oszillator mit 100 Parametern, Einflussgrössen, Rückkopplungen und Prozessschritten, liefe diese bei einem 200MHz-FPGA noch mit Faktor 2MHz im Loop. Das wären also 40 virtuelle Oszillatoren in einer normalen 2D-pipeline mit 48kHz. Im aktuell kleinsten Artix bekommt man geschätzt 10-30 solcher Architekturen hinein. Macht bei mir an die 1000 virtuelle Monster-Oszillatoren auf der typischen Abtastrate von 48kHz, die in einem FPGA machbar sind. In einer 3D-pipeline liessen sich sie 100 Latenzschritte noch verwerten und man landet schon bei einer Architektur bei wieder ff/fs = 200MHz/192kHz = 1000 Oszillatorkanälen. Ich glaube eher, daß wir da Marketingaspekte als Ursache sehen müssen. In Anlehnung dessen, was Du zu der "Technologie aus den 80ern" selbst schreibst, soll da wohl etwas aus Nostalgiegründen hochgehalten werden. Vielleicht haben sie aber auch die gesamte Stromversorgung, samt schnuddeligem Netzteil, die interne Verkabelung mit EMI-Einfluss und die Potiunlinearitäten sowie die prellenden Schalter modelliert. Die waren ja durchaus klanggebend. :D
:
Bearbeitet durch User
Alexander F. schrieb: > Josef G. schrieb: >> Hanno schrieb: >>> FPGA-Projektor schrieb im Beitrag #3575946: >>>> ... unter anderem auch das 8Bit Projekt von Josef hier im Forum. >>> >>> Was aber eher zu den abschreckenden Beispielen gehört... >> >> Begründung? > > Hunderte Signale, die in ca. 50 Prozessen miteinander in Verbindung > stehen, dazu 2 Takte, Die Aussage "dazu 2 Takte" gilt nur noch eingeschränkt. Siehe meinen Beitrag vom 24.02.2016 im Thread "8bit-Computing mit FPGA". Link funktioniert möglicherweise nur für unangemeldete Benutzer Beitrag "Re: 8bit-Computing mit FPGA"
Eine spontane Idee für ein FPGA-Progjekt kommt mir gerade in den Sinn, wo ich das so lese: Wie wäre es mit einem Co-Prozessor-Core für komplexe Rechnungen, zum Lösen von Gleichungen, eine Art Gauß-Algorithmus oder Determinantenberechnungen? Sowas kann man doch immer gebrauchen.
Markus W. schrieb: > Wie wäre es mit einem Co-Prozessor-Core für komplexe Rechnungen, zum > Lösen von Gleichungen, eine Art Gauß-Algorithmus oder > Determinantenberechnungen? Macht man heute mit Grafikkarten für ein paar hundert Euro: http://ta.twi.tudelft.nl/nw/users/mmbaumann/projects/PI_BA/piBA.pdf https://www.tu-ilmenau.de/fileadmin/media/simulation/studentische_arbeiten_themen/Haupt_Projektseminar.pdf Man kann auch uC mit einem FPGA/CPLD beschleunigen Problem ist allerdings die Daten zwischen beiden auszutauschen. Sinn macht das erst wennprozessor und coprozessor auf den gleichen Speicher zugreifen was heutzutage auch nicht einfach ist. füt einen Softcore wie den ublaze könnte man noch neben den FPU's weitere coprozessoren designen die werden aber wohl nur eine sehr speziellen Anwendungsbereich haben. MfG,
Markus W. schrieb: > Eine spontane Idee für ein FPGA-Progjekt kommt mir gerade in den > Sinn, > wo ich das so lese: > > Wie wäre es mit einem Co-Prozessor-Core für komplexe Rechnungen, zum > Lösen von Gleichungen, eine Art Gauß-Algorithmus oder > Determinantenberechnungen? > > Sowas kann man doch immer gebrauchen. Moin, gebrauchen, oh ja. Das Problem, bzw. die meiste Arbeit macht schlussendlich die Toolchain. Die Frage ist immer, machst Du es dediziert für genau ein Projekt/Aufgabe oder generisch, so dass es andere nutzen können. Dann ist der logische Schritt letzerer Aufgabe immer ein Prozessor, für den du entweder Microcode oder gar richtige Assemblermnemonics designst. Das wird dann meist so aufwendig, dass man es fürs Projekt eben doch meist hart codiert. Da gibt es auch so einige Ansätze, wie HiCoVec, usw. - die sehen mir jedoch alle nicht sonderlich weiterverfolgt aus. Mit den DSP-Toolboxen aus der Python-HDL-Welt lässt sich da allerdings einiges beschleunigen. Das geht dann meist auch in die Richtung der nvidia-Recheneinheiten. Für skalare Zerlegung habe ich mal eine Engine gebastelt, mit der z.B. DCT geht (JPEG-Encoder). Mit der Host-CPU (auf dem FPGA) lädt man VLIW-Microcode in das kurze (16 Befehle) Programm-Memory der jeweiligen Unit. Das ist aber für den Anwender u.U. kryptisch, dass sich nicht mal ein externer Assembler rechnet. Wer vielleicht den Blackfin kennt: Dessen Parallelprogrammierung haben trotz toll lesbarem Assembler nicht sonderlich viele Nutzer ausgelotet. Schlussendlich läufts fast immer auf eine Library hinaus, die der Anwender aus seinem Programm aufruft. Das grösste Problem schlussendlich stellt sich jedoch oft an einer ganz anderen Stelle, bei der die DSP-Konzepte so richig knifflig werden: - Wie kommen die Daten rein? - Müssen sie ev. umsortiert werden und wie? - Wie integriert man den Beschleuniger effektiv in seinen bestehenden SoC? Zu letzerem gibt's einige nette Tricks mit Opcode-Windows um bestehende Befehlssätze aufzubohren, aber das geht mit uBlaze und Konsorten natürlich nicht. Vermutlich wird der Trend immer mehr in Richtung HLS gehen (ob mit C oder Python sei dahingestellt) und das super-versatile Tool ein In-House-Tool bleiben oder wie manche 8-Bit-CPU-Spielereien unter erheblichen Akzeptanzschwierigkeiten leiden. Gruss, - Strubi
Das Problem mit den HighLevelSynthesis-Ansätzen ist, dass FPGA doch sehr viel low Level Beschreibung benötigt, was die Beschreibungsebenen weit auseinander zieht und verkompliziert. Je mehr Tools dann im Spiel sind, desto schneller geht die Kompatibilität flöten. Nimm mal einen HL-Codegenerator wie MATLAB und ein SOPC-System vom Hersteller und bringe dann noch einen externen Simulator sowie Synthesizer ins Spiel. Irgendwo knackt es immer.
Nochmals zu dem Thema SoftCores: Wie weit sind denn auf dem FPGA-Sektor eigentlich die Compiler? Kann man davon ausgehen, ähnliche Qualität und Komfort zu bekommen, wie auf den Controller-Plattformen? Oder wird die Software extern für einen Controller gemacht und verfiziert und dann nur draufgesteckt? Ist so ein virtueller AVR in einem FPGA voll kompatibel? Ich denke von den intern verbauten ARMs kann man das erwarten nehme ich an(?)
Martin K. schrieb: > von den intern verbauten ARMs kann man das erwarten nehme ich an(?) Der Prozessorkern selbst natürlich schon. Der Trick ist immmer die Peripherie und die EA. Und da ist ein ARM von ST mit dem anderen von NXP auch nicht "kompatibel"...
Moin, > > Wie weit sind denn auf dem FPGA-Sektor eigentlich die Compiler? Kann man > davon ausgehen, ähnliche Qualität und Komfort zu bekommen, wie auf den > Controller-Plattformen? Oder wird die Software extern für einen > Controller gemacht und verfiziert und dann nur draufgesteckt? Das hängt halt wieder etwas von der Architektur ab und wie entsprechend das Zusammenspiel verifiziert wurde. Im Schnitt ist es recht gut. Kann nur zu folgenden was sagen: - Microblaze: Gut getestet, breiter Support für OS, dasselbe gilt offenar auch für NIOSII, da schenkt sich nix. - MIPS32/16: Sehr robust (modulo Core-Eigenheiten), da Architektur gut etabliert - Lattice mico32: Ist etwas her, ansich eine schöne (mips-alike) Architektur, aber das Ding flog in die Ecke, u.a. wegen einigen Bugs im GCC, die eine saubere Portierung verhinderten. - ZPU: Ziemlich robust für einen freien Core, gut verifizierbar, allerdings kein Support in GCC 4.x (nur alte 3er Toolchain) Wie die Board-Supply-Packages (für die jeweiligen HW-Varianten mit unterschiedlicher Peripherie) dann jeweils ausschauen, ist eine andere Geschichte, da macht man meist viel selber. Wo es bei den meisten Cores hapert, sind die Debugging-Features, das bewegt sich bei den meisten - wenn überhaupt - auf OpenOCD-Schema: Manchmal stabil, manchmal nicht. Aber dazu kann man einen anderen Thread aufmachen :-) Im Prinzip - wenn man sich den Aufriss mit der Testbench gibt - sind manche Softcores sogar deutlich fehlerfreier und beweisbarer als z.B. ein ARM7 und der eigentliche Clue ist: Als User kannst du die Fehler selber finden. Bei einem harten-Core dauert es Monate, bis die Hersteller überhaupt mal einen Bug zugeben :-) Grüsse, - Strubi
Hallo Strubi, möchtest Du nicht mal eine deiner MIPS Versionen mit Debugger Support veröffentlichen? Viele Grüße, Michael
Sowas wäre mal ein nettes Projekt: Ein fetter Core mit einem fixen und gut ausgebauten Debug-Port mit kompletter Tool Chain, an der sich mehrere Leutchen beteiligen.
Michael schrieb: > Hallo Strubi, > > möchtest Du nicht mal eine deiner MIPS Versionen mit > Debugger Support veröffentlichen? > > Viele Grüße, > Michael Hi Michael, ich bin vom MIPS etwas weggekommen, da er nicht auf die kleinen Plattformen (wie MachXO2) passt, ausserdem ist das Ding zu komplex geworden, um es für eine Community a la OpenSource zu supporten. Aber ich überlege noch, mein SoC-Environment mit der Zealot (OpenSource) bzw. ZPUng (meine beschleunigte Variante) teilweise offenzulegen. Im Prinzip liegt die Debugger-Anbindung schon eine Weile offen in div. git repos rum. So ein paar Infos gibts auf http://tech.section5.ch/news/, gab auch mal hier nen Thread "Neue CPU Aspekte" o.ä. Nur habe ich bzgl. OpenSource und HDL nicht grade die besten Erfahrungen gemacht. Kameramann schrieb: > Sowas wäre mal ein nettes Projekt: Ein fetter Core mit einem fixen und > gut ausgebauten Debug-Port mit kompletter Tool Chain, an der sich > mehrere Leutchen beteiligen. Gibt's doch alles (OrSoC, Leon, usw.). Nur an der minimaleren Ecke sieht's halt mau aus. D.h. 'fett' sollte es gerade eben nicht, aber trotzdem 32 bit, GCC und JTAG-Debugger und DSP-Extensions. Das schafft die ZPU-Architektur mit Bravour und hat dabei den kompaktesten Code für einen 32-Bitter. Grüsse, - Strubi
Fpga K. schrieb: > Macht man heute mit Grafikkarten für ein paar hundert Euro: Dies erfordert einen PC, ich meinte eher sowas wie einen VHDL Core zum reinwerfen in bestehende FPGA-Designs.
Schade jetzt wurde der Thread interessant. Das Debuggen ist ein heißer Punkt. Ich habe bei mir den GDB als Software Stub laufen und der Debugger ist als Software in der CPU. Als Breakpoint wird ein Opcode hinterlegt, der ein Interrupt wirft.
Schaut wohl so aus, ja. Ich war auch eine Weile nicht aktiv. Für mich wäre das interessant gewesen, wenn es mit FPGAs ein einfacher Weise gelänge, Funktionen zu realisieren, die mit DSPs zu langsam sind.
Wenn ich über die Vorteile von FPGAs wie Parallelisierung nachdenke, stelle ich mir Multisensorsysteme/Arrays vor. Ich halte einige Anwendungen für möglich, die z.B. Arrays aus Hall-Sensoren zum Visualisieren von statischen und beweglichen Magnetfeldern einsetzen. Zudem ist es sicherlich interessant und nützlich Ultraschalsensor-Arrays zu bauen, die z.B. ein "2D/3D-Abtasten" von der Umgebung für Sehbehinderte erleichten würden. Oder, wenn man halt Spass haben will, könnte man über Bau eines grobkörnigen 3D-Scanners mit Photodioden-Array und kodiereten Beleuchtungsfeld nachdenken.
abc schrieb: > System Generator for DSP. > Oder etwas von Altera oder Labview. Das hört sich aber nicht mehr so einfach an. Soweit mir bekannt, will MATHWORKS auch Geld für seine Produkte. Labview ist schon mal nicht umsonst und ein Entwickler in unserer Firma hat mir davon abgeraten, damit FPGAs zu machen. Bei mir wäre es auch in erster Linie Video.
Martin K. schrieb: > abc schrieb: >> System Generator for DSP. >> Oder etwas von Altera oder Labview. > > Das hört sich aber nicht mehr so einfach an. Soweit mir bekannt, will > MATHWORKS auch Geld für seine Produkte. Labview ist schon mal nicht > umsonst und ein Entwickler in unserer Firma hat mir davon abgeraten, > damit FPGAs zu machen. > > Bei mir wäre es auch in erster Linie Video. Gab es nicht schon Bild-Filter, als das Teil noch "System Generator" hieß? Es hängt eben davon ab, mit wieviel Kenntnissen und Fähigkeiten welche Funktionsumfänge realisiert werden sollen. Im Detail hängt es auch von den Performanz-Anforderungen ab. Mit dem Systemgenerator habe ich bereits Softwaretechniker größere Systeme samt FFTs für den FPGA erstellen lassen. Die Erfahrung war positiv. Mit Labview habe ich so etwas noch nicht gemacht. Speziell für Video gibt es auch noch weitere, kleinere Firmen, die graphisch gestützte Tools (ggf auch mit Möglichkeit zur Eingabe von Scripten) für die Bild/Videoverarbeitung anbieten. Das Design wird dann auf den FPGA oder DSP synthetisiert. Natürlich kosten die Tools etwas. Dafür kommt man mit weniger Expertise im Haus schneller zu brauchbaren Ergebnissen. Es hängt eben davon ab, was man hat und was man möchte. Ggf. besteht die Möglichkeit, die Tools zu testen. Ebenso kann man sich in den Videos/Tutorials einen Eindruck verschaffen.
FFTs und Ähnliche Sachen, sind auch nicht so das Problem, weil die ja als Core existieren. Der System Generator schaltet die letztlich auch nur als Grafik zusammen. Entscheidender ist der Aufbau der image pipe an sich, vor allem Funktion und Umsetzung und deren Parallelisierung nimmt einem ja niemand ab. Kamil R. schrieb: > Ich halte einige Anwendungen für möglich, die z.B. Arrays aus > Hall-Sensoren zum Visualisieren von Magnetfeldern einsetzen. Das wird schon gemacht und nicht nur mit Hallsensoren. Hatte in meiner Anfangszeit mal eine APP, die sogar über DSPs lief. Dann: In jedem MRT werden Magnetfelder 3-dimensional erfasst und verrechnet, auch und vor allem mit FPGAs. Zweidimensional gibt es das sogar als Messsystemzubehör für Oszilloskope von Agilent: Man legt eine Platine auf ein DIN A4-Brett und kann sich grafisch wie in einem Wärmebild die EMV ansehen. > Zudem ist es sicherlich interessant und nützlich Ultraschalsensor-Arrays > zu bauen, die z.B. ein "2D/3D-Abtasten" von der Umgebung für > Sehbehinderte erleichten würden. Auch das wird gemacht, wenn auch in meinem Fall nicht für die Sehbehinderten, sondern die automatische Pbjekterkennung. Ob man da Blinden helfen kann, ist eher zweifelhaft, weil die Ortsauflösung von Ultraschall nicht so hoch ist. Wenigstens nicht in Luft. Mit FPGAs kann man aber sehr schon 1-BIT-DA-Wandler bauen, die ohne Wandler über viele Pins viele analoge Sensoren abtasten. https://www.mikrocontroller.net/articles/Analog-IO_mit_digitalen_Bausteinen Damals waren es bis zu 256 Kanäle in einem Spartan 3E. Sehr platzsparend. Im MEMS-Zeitalter geht das heute freilich digital rein.
:
Bearbeitet durch User
Jürgen S. schrieb: > FFTs und Ähnliche Sachen, sind auch nicht so das Problem, weil die ja > als Core existieren. Der System Generator schaltet die letztlich auch > nur als Grafik zusammen. Entscheidender ist der Aufbau der image pipe an > sich, vor allem Funktion und Umsetzung und deren Parallelisierung nimmt > einem ja niemand ab. Die FFTs waren händisch zusammen gebaut. Der System Generator hat folgende Vorteile: . aufgrund der graphischen Gestaltung leicht verständlich . Submodule per Click . Voller Funktionsumfang, dh, es ist prinzipiell alles realisierbar; . Parallelität und Design-Struktur "graphisch erkennbar" . Es lässt sich nur "sinnvolles" zusammenklicken. . Es gibt weniger Syntaxfehler und auch Sematikfehler. . Waren sogar VHDL-Module einbindbar? . Komfortables HIL Nachteile: Preis, Abhängigkeit
Jürgen S. schrieb: >...weil die Ortsauflösung von >Ultraschall nicht so hoch ist. Wenigstens nicht in Luft. Ich denke, dass herkömmliche Radare in der Tat besser für die Aufgabe geeignet wäre. Doch der Kostenfaktor, wie bei im Tread erwähntet Privatprojekten, schätze ich höher für Radar- als für Ultraschal-Sensoren. Wie sieht es mit Kosten für Infrarotsensoren aus? Jürgen S. schrieb: >Auch das wird gemacht, wenn auch in meinem Fall nicht für die >Sehbehinderten, sondern die automatische Pbjekterkennung. Ob man da >Blinden helfen kann, ist eher zweifelhaft... Könnte gerade dies für Sehunterstützung-Anwendung interessant sein: Das Gerät erkennt Objekt und seine Position, dann "leitet/sagt/mitteilt" es an die Person weiter. Jürgen S. schrieb: > Zweidimensional gibt es das sogar als Messsystemzubehör für Oszilloskope > von Agilent: Man legt eine Platine auf ein DIN A4-Brett und kann sich > grafisch wie in einem Wärmebild die EMV ansehen. Das ist sehr interessant für mich, hast Du vielleicht mehr Information dazu?
Kamil R. schrieb: > Könnte gerade dies für Sehunterstützung-Anwendung interessant sein: Das > Gerät erkennt Objekt und seine Position, dann "leitet/sagt/mitteilt" es > an die Person weiter. Möglich ist das definitiv. Es gibt ja sogar in den USA Trainingscenter, wo Leute lernen, mit der Zunge zu schnalzen und anhand des Echos die Umgebung zu erkennen. > Das ist sehr interessant für mich, hast Du vielleicht mehr Information > dazu? Kann sein, dass ich Agilent fälschlicherweise ins Spiel gebracht hatte: Was ich selber gesehen habe war das DATATEC EMSCAN: http://www.datatec.de/nocache/App-Note-EHX-EMV-Scanner,w14701687906331.htm
abc schrieb: > . aufgrund der graphischen Gestaltung leicht verständlich Trotz graphischer Gestaltung nicht verständlich, weil die Vorteile grafischer Gestaltung, nämlich farbliche Markierung, Kenntlichmachung von Signal- und Netzeigenschaften nicht oder nur unzureichende genutzt wird und ferner faktisch wichtige Dinge in anonymisierten Symbolen versteckt werden. > . Submodule per Click Sofern verfügbar und funktionabel. Vorhandene Submodule als VHDL können mit COPY und PASTE genau so leicht eingesetzt werden > . Voller Funktionsumfang, dh, es ist prinzipiell alles realisierbar; Keineswegs. Im Sysgen sind mitnichten alle Cores akutell verfügbar, die man beim Coregen direkt erhält und auch die decken nicht alles ab. > . Parallelität und Design-Struktur "graphisch erkennbar" Nur zweidimensional und welches Komplexe Design in schon zweidimensional? Ein einfaches generisches Beschreiben von mehrdimensionalen Modulstrukturen ist faktisch unmöglich. > . Es lässt sich nur "sinnvolles" zusammenklicken. Das stimmt nicht. Da kann man alles mit allem kombinieren, wenn der Port passt, auch wenn die Funktion keinen Sinn gibt. Umgekehrt verhindern bestimmte Einschränkungen einfache Dinge, die in VHDL einfach zu formulieren sind. Da habe ich tonnenweise Beispiele. > . Es gibt weniger Syntaxfehler und auch Sematikfehler. Ich wüsste nicht, wie man bei einem HDL-Design einen Sema(n)tikfehler einbauen könnte, der persistent bliebe - und Syntaxfehler compilieren nicht. Falsch interpretierte Signale durch das Simulinksystem aber sehr wohl. Ich erinnere mich noch wie gestern an einen Fall, wo es schlicht unmöglich war, aus einfachen Grafikelementen eine dumme PWM-Ausgabe hinzubekommen. Es compilierte, funktionierte aber nicht. Fehler war trotz einschalten von Mathworks sowie eines erfahrenen Simulink-Nutzers der Nachbarabteilung nicht zu lösen. > . Waren sogar VHDL-Module einbindbar? Ja, das geht und das war die Rettung: Grafikgespiele raus, embedded Matlab rein und an den HW-nahen Stellen die Logikblöckchen, die angeblich zählen können, durch VHDL ersetzt. Es gäbe noch weitere Punkte - habe das damals mal genauer aufgeschlüsselt, wo das System überall muckt. Massivster Ärger waren Signale die nicht und falsch im WAVE Window angezeigt wurden, verschwanden und verwechselt wurden. Eine Systemvalidierung ist damit schlicht unmöglich. > . Komfortables HIL Das ist der einzige Punkt, in dem Ich Dir zustimme. Warum auch immer, hat man es geschaft, ein Design in einen wrapper reinwerfen zu können, der dann auf dem FPGA asynchron läuft und die Simulation massiv beschleunigt. Das wäre ein echter und wichtiger Vorteil des Systems. Die Nachteile wiegen den für tpyische Entwicklungen aber meistens auf! Wer nicht unbedingt mit MATLAB arbeiten muss, um sein System hinzustellen, lässt im Zweifel lieber die Finger davon. > Nachteile: > Preis, Abhängigkeit Der Preis ist eigentlich egal, bei den Kosten für Entwickler, die Modellieren, Simulieren, Rechnen und physikalisches Testen. Man muss im Gegenteil eher veranschlagen, dass das Entwickeln mit dem System länger dauert, weil MATLAB den Rechner komplett blockiert, während man mit einer offenen toolchain ModelSIM, Synthese, Editing und Dokumentieren parallel erledigen kann. Abhängigkeit ist schon ein Punkt. Einmal verfasste Grafiken können nicht uneingeschränkt in die nächste Version portiert werden und zu einem anderen Hersteller schon gleich gar nicht. Die ärgerlichste und gefährlichste Abhängigkeit ist aber die vom Tool selber: Was an Macken drin ist, ist nicht zu beheben. Teamwork ist ein Thema. Es ist praktisch unmöglich an demselben design zu arbeiten. Versionskontrolle bei Grafik ist auch nicht so prickelnd.
Jürgen S. schrieb: > abc schrieb: >> . Voller Funktionsumfang, dh, es ist prinzipiell alles realisierbar; > Keineswegs. Im Sysgen sind mitnichten alle Cores akutell verfügbar, die > man beim Coregen direkt erhält und auch die decken nicht alles ab. > >> . Parallelität und Design-Struktur "graphisch erkennbar" > Nur zweidimensional und welches Komplexe Design in schon > zweidimensional? Der Synopsys RTL Viewer schafft es auch, jedes Design in 2D darzustellen. Nur kann man da die Grafiken nicht editieren und es ist auch nicht so übersichtlich. > Ein einfaches generisches Beschreiben [...] ist faktisch unmöglich. ja. >> . Es lässt sich nur "sinnvolles" zusammen klicken. > Das stimmt nicht. Da kann man alles mit allem kombinieren, wenn der Port > passt, auch wenn die Funktion keinen Sinn gibt. Umgekehrt verhindern > bestimmte Einschränkungen einfache Dinge, die in VHDL einfach zu > formulieren sind. Da habe ich tonnenweise Beispiele. If reset=1 and rising_edge(reset)... > Ich erinnere mich noch wie gestern an einen Fall, wo es schlicht > unmöglich war, aus einfachen Grafikelementen eine dumme PWM-Ausgabe > hinzubekommen. Es compilierte, funktionierte aber nicht. Fehler war > trotz einschalten von Mathworks sowie eines erfahrenen Simulink-Nutzers > der Nachbarabteilung nicht zu lösen. Gut, dass jemand auch negative Erfahrungen berichtet. ...irgendwie ging das mit der Teamwork am selben Design. Validierung/Test haben wir ganz sicher nicht mit dem WAVE-Editor gemacht. Vielleicht nicht mal getestet. Eher unnötig gerade mit einem solchen Tool. Eine DSP-Chain ist schnell zusammen geklickt und kann auch komplexer sein. Darüber hinaus können viele Entwickler ohne HDL-Kenntnisse relativ schnell produktiv tätig sein. Dabei typische Stolperfallen und Aufwände nimmt es einem in beiden Fällen ab. Es ist nicht für HDL-Coder, nicht als VHDL-Ersatz und auch nicht zum Beschreiben großer state machines, Komponenten mit "vielen" Steuersignalen, CPUs oder ganzer SoCs geeignet. Dafür hatte ich es hier auch nicht empfohlen. Wenn man bei jedem Fehler im Synthesetool oder Silicon hinschmeißen würde, dürfte man gar nichts mehr machen. Gut, ihr hattet mehr Fehler. In welchem Jahr war das?
abc schrieb: > Der Synopsys RTL Viewer schafft es auch, jedes Design in 2D > darzustellen. Vollommen unlesbar und ohne jeden Nutzen. Das widerspricht eher einer Übersicht, die Durchblick durch die Schaltung schaffen könnte. > Eine DSP-Chain ist schnell zusammen geklickt und kann auch komplexer > sein. Darüber hinaus können viele Entwickler ohne HDL-Kenntnisse relativ > schnell produktiv tätig sein. Ich habe momentan so einen Fall, wo sich mehrere Entwickler scheinbar produktiv um ein Thema tummeln, sich um die Lizenzen und Vorgehensweisen prügeln. Das schnelle Zusammenklicken führt nach meiner Beobachtung nur dazu, dass die Thematik von vielen Projektleitern noch weiter unterschätzt wird, als es ohnehin schon der Fall ist.
Thomas U. schrieb: >> Eine DSP-Chain ist schnell zusammen geklickt und kann auch komplexer >> sein. Darüber hinaus können viele Entwickler ohne HDL-Kenntnisse relativ >> schnell produktiv tätig sein. > Ich habe momentan so einen Fall, wo sich mehrere Entwickler scheinbar > produktiv um ein Thema tummeln, sich um die Lizenzen und Vorgehensweisen > prügeln. Das schnelle Zusammenklicken führt nach meiner Beobachtung nur > dazu, dass die Thematik von vielen Projektleitern noch weiter > unterschätzt wird, als es ohnehin schon der Fall ist. Und? Soll Deine Einzelfall-Beobachtung irgendetwas über die Allgemeinheit oder die prinzipielle Nützlichkeit bei sinngemäßer Anwendung aussagen? Oder ist das ein Job-Angebot?
abc schrieb: > Thomas U. schrieb: >>> Eine DSP-Chain ist schnell zusammen geklickt und kann auch komplexer >>> sein. Darüber hinaus können viele Entwickler ohne HDL-Kenntnisse relativ >>> schnell produktiv tätig sein. >> Ich habe momentan so einen Fall, wo sich mehrere Entwickler scheinbar >> produktiv um ein Thema tummeln, sich um die Lizenzen und Vorgehensweisen >> prügeln. Das schnelle Zusammenklicken führt nach meiner Beobachtung nur >> dazu, dass die Thematik von vielen Projektleitern noch weiter >> unterschätzt wird, als es ohnehin schon der Fall ist. > > Und? Soll Deine Einzelfall-Beobachtung irgendetwas über die > Allgemeinheit oder die prinzipielle Nützlichkeit bei sinngemäßer > Anwendung aussagen? Oder ist das ein Job-Angebot? Ich fürchte, dass das keine Einzelfälle sind :-) Die Threads über grafisches Programmieren sind hier schon geradezu inflationär. Unterm Strich gelten leider doch immer wieder die Naturgesetze: Der Europäer ist prinzipiell eher Sprachenmensch als Bildermensch (bei den Japanern mag das etwas anders sein). Deswegen war dashierzulande mit grafischem Entwickeln noch nie so richtig nachhaltig, abgesehen vom fehlenden Standard und fehlenden Testbenches.
Hallo, ich schlage vor, dass du einen BPSK-Transceiver entwickelst. Der soll per USB an den PC gekoppelt werde und dessen Ausgang an eine Antenne. Ein weiterr Ausgang für die Steuerung einer magnetischen Antenne wäre für meine Verhältnisse äusserst hinfreich. Unter Linux sollte es ein geeignetes Programm geben, welches die Abwicklung einer Kommunikation steuert. Und falls das noch nicht reicht: es gibt weitere digitale Betriebsarten: alle FSK, Pactor, (..............) Falls du das auf einen Spartan3 packst, könnte ich das auf vorhandenem Inventar nutzen. PC mit Linux ist bereits vorhanden :-) Gruss Robert
Es müsste etwas sein, was es noch nicht gibt, aber was möchte man mit FPGAs noch groß tun? Es sind in aller Regel die typischen Hobbyprojekte und die beziehen sich immer irgendwie auf die Sinne des Menschen: 1. Hören 2. Sehen 3. Fühlen 4. Riechen Beim Hören gibt es die Tonerzeugung und die Bearbeitung, beim Sehen ist es irgendwie Dasselbe, riechen kann man FPGAs, wenn sie zuviel Strom abgekriegt haben - nur das Fühlen kommt etwas zu kurz! Bliebe etwas im Bereich Reizstrom oder Magnetfelderzeugung, die man in den Muskeln spüren kann. Was wirklich interessant wäre, sind Decoder, die der geplanten Manifestierung von Bezahldiensten durch Kopierschutz entgegenwirken. Soweit ich weiß gibt es schon Premieredecoder. Wie sieht es denn z.B. aus mit dem DVB-T2 Format? Das Signal muss irgendwie zu entschlüsseln sein, damit man ohne irgendwelche Karten oder Bezahlcodes mitschauen kann. Nach einem jüngsten Urteil sind die ja zu privaten Zwecken erlaubt, sofern man die entwickelte Software nicht weitergibt.
Es reicht, wenn der Entwickler die Software betreibt und die Ergebnisse ins Netz stellt. :-) Robert
Nun, die Sofware ist vielleicht schon da und braucht nur noch die richtige Videoplattform? Beitrag "Re: Suche Mitwirkende für Hochleistungs-FPGA board" :-)
Strubi schrieb: > Ich fürchte, dass das keine Einzelfälle sind :-) Das ist der Regelfall. Zu den Einzelfällen zähle ich eher die, welche nach umfassender Erfahrung mit den grafischen Werkzeugen dies als Königsweg einschätzen. > dashierzulande mit grafischem Entwickeln noch nie so richtig nachhaltig, > abgesehen vom fehlenden Standard und fehlenden Testbenches. Ich glaube eher nicht, daß es was mit Nationaöitäten zu tun hat. Das sind schon durchaus pragmatische Gründe.
Zum "grafischen Entwickeln" fällt mir noch was ein, was Ich schon mehrfach mal probieren wollte, aber aus Zeitgründen nie angegangen bin: Eine Toolbox mit VHDL-Modellen für Elektroniksimulation. Ursprünglich mla mit den ISE-Blocksymbolen ausprobiert, müsste sich das mit dem in Vivado inzwischen stabiler darstellenden Blockdesign zu machen sein: Es gibt eine Reihe von Symbolen, hinter denen sich Analogmodelle verbergen und die wie in einem Netzwerk zusammengeschaltet werden. Das VHDL kann dann das Verhalten im Zeitbereich simulieren. Per Skalierung wird das Thema der Zeitauslösung erledigt. Ich denke da z.B. an analoge Filter, Bauelemente mit Verlusten und parasitären Effekten. Schaltungen bis zu einigen Kiloherz liessen sich damit sogar in Echtzeit betreiben.
Ich komme nochmals zurück zu dem Thema weiter oben: W.S. schrieb: > c) ein heutzutage üblicher µC, z.B. ein LPC4088, den es für ca. 8..9 > Euro fertig zu kaufen gibt. Schau dir mal an, was der alles drin hat, > von Gleitkomma-Rechenwerk über TFT-Controller, USB, Ethernet, > SDRAM-Anschluß, riesiger interner Flash, recht großer interner RAM und > und und... Glaubst du, mit einem überhaupt erschwinglichen FPGA das > alles nachbilden zu können? Das kann man nur unterstützen! Nachzubilden ist mit einem FPGA so ziemlich gar nichts, was es zu kaufen gibt. Das ist aber nicht wirklich die Frage. Der Task ist "Neubilden", als Prototypen zu bauen von Schaltungen und Funktionen, die es noch nicht gibt. Dort benötigt man Modelle der Interfaces, deren Funktionen und Dinge, die man nicht in Echtzei in einem Controller realisieren kann. Den Kostenvergleich Microontroller und FPGA wird der FPGA immer verlieren. Kommen wir mal zu einem konkreten Beispiel und damit einer Idee für ein FPGA-Probjekt: Eine Überwachungsschaltung für Microcontroller mit eingebautem Assembler, der versteht, was der Controller tut und nachvollziehen kann, was er macht und Echtzeitsysteme zu tracken. Wer möchte?
Weltbester FPGA-Pongo schrieb im Beitrag #5189422: > Überwachungsschaltung für Microcontroller Gibt es doch schon: Lock-Step Dual-Core http://www.ti.com/content/dam/ticom/images/products/ic/microcontrollers/hercules/diagrams/tms570-hercules-mcu-block-diagram.png
Den kenne Ich, allerdings möchte Ich mehr tun. Ich komme da später nochmals drauf zu sprechen und stelle das genauer vor.
> > Eine Überwachungsschaltung für Microcontroller mit eingebautem > Assembler, der versteht, was der Controller tut und nachvollziehen kann, > was er macht und Echtzeitsysteme zu tracken. > > Wer möchte? Also ich habe dein Problem nicht ganz verstanden. Was du unter Überwachungsschalter verstehst? Ich habe einen Mikrocotroller als Softcore, der die MIPS-I Befehle ausführt. Da bin ich bereits so weit, dass ich auch C Programme ausführen kann und diese auch mit dem GDB über eine UART Zweidrahtleitung debugen kann. weitere Watchdogs oder Werteüberprüfer sollten kein Problem in VHDL sein.
Weltbester FPGA-Pongo schrieb im Beitrag #5189422: > Eine Überwachungsschaltung für Microcontroller mit eingebautem > Assembler, der versteht, was der Controller tut und nachvollziehen kann, > was er macht und Echtzeitsysteme zu tracken. > > Wer möchte? Ha, ha. Dir ist aber schon klar, was das für ein Aufwand ist? Manche Firmen stecken da locker einige 100k rein. Und du meinst sicher Disassembler... Der Sinn für 'Safety-Computing' erschliesst sich mir allerdings nicht ganz, eher noch für Reverse-Engineering, oder FPGA als Trace-Debugger. Da machen viele ihr eigenes Ding und geben nix raus. Wenn's um Safety und Verhinderung bösartiger Attacken geht: Mehr Sinn macht für mich, auf eine Softcore-Architektur aufzubauen, die eine elegante Einbindung effektiver Watchpoint-Units erlaubt, wie z.B. gewisse Stackmaschinen. In meiner ZPUng mit WPU habe ich z.B. Checkpoints im Programm an gewissen kritischen Stellen, die deterministisch angefahren werden (müssen), da ist der Wert eines gewissen Registers (verwursteter SP und PC) immer jeweils identisch mit einer "nonce". Der Vergleich damit ist natürlich das kritische Element, egal wie redundant der ausgelegt ist. Trotzdem deutlich robuster als z.B. ein 0815 ARM, aber nur, was Programmablauf angeht, redundante ALU ist nicht drin. Die Frage ist immer, was du grundsätzlich haben willst: eine Schaltung, die jeden Fehler möglichst hochwahrscheinlich erkennt und Alarm schlägt, oder eine die möglichst irgendwie weiterläuft und versucht, zu korrigieren. Ich denke mal, jeder fängt mit ersterem an und macht bei v2 unter Umständen nochmal alles neu von vorne. Letzteres geht mit einer Stackmaschine nur bedingt gut.
Jürgen S. schrieb: > Einige rühmen sich sogar, die jeweils > ersten gewesen zu sein, die FPGAs eingesetzt haben wollen, aber bei > genauerer Betrachtung sind das genau die, die es in den letzten 10 > Jahren verpennt haben, Innovationen an den Start zu bringen und nun > probieren, ihre alten Analogkisten neu zu vermarkten, indem sie sie in > Hardware gießen Ich nehme an, Du meinst die Firma Roland. Ich bin kein eingefleischter Elektromusik-Kenner, aber die Synthesizer scheinen sich ja doch einer gewissen Beliebtheit zu erfreuen. Die digitalen remakes verkaufen sich angeblich bestens. Vorteil: Bei einem digitalen Abbild der urtümlich analogen Hardware hat man zumindest die Gewähr, dass die Klangqualität sich nicht über die Zeit verändert. Wenn Radios und Fernseher über die Jahre mehr und mehr rauschen und knistern, dürfte das auch für analoge Musikelektronik gelten. Für meine alten (e-guit)-Bodentreter jedenfalls gilt es. :-> Warum sollte man das also nicht tun? Mal davon abgesehen, glaube Ich nicht, dass ausgerechnet die die letzten gewesen sein sollten, welche sich mit FPGAs befasst haben. Mit irgendwas werden die die Klang-ASICS in ihren Modellen schon geprototyped haben. Wie ist das eigentlich bei Yamaha? Solche DX7-Klassiker müssten eigentlich auch leicht zu portieren sein.
Strubi schrieb: > Mehr Sinn macht für mich, auf eine Softcore-Architektur aufzubauen, die > eine elegante Einbindung effektiver Watchpoint-Units erlaubt, wie z.B. > gewisse Stackmaschinen. In meiner ZPUng mit WPU habe ich z.B. > Checkpoints im Programm an gewissen kritischen Stellen, die > deterministisch angefahren werden (müssen), da ist der Wert eines > gewissen Registers (verwursteter SP und PC) Könnte man das bitte nochmal in etwas klarere Worte fassen, was damit gemeint ist? Wie sollte eine solche Architektur aussehen? Was soll sie können?
An F. schrieb: > Könnte man das bitte nochmal in etwas klarere Worte fassen, was damit > gemeint ist? > Man könnte. Aber man könnte auch einfach googeln. > Wie sollte eine solche Architektur aussehen? > Der Thread hat einen Bart, aber nu denn: Möglichst simpel, deshalb: Stackmaschine und so wenige States wie möglich. > Was soll sie können? Sie kann bereits. Bei Modifikation kritischer Programmteile (Buffer Overflow, Glitch-Attacken, usw.) schlägt die Watchpoint-Unit zu und das System geht in eine 'harte' failsafe-Sequenz.
Strubi schrieb: > Bei Modifikation kritischer Programmteile (Buffer Overflow, > Glitch-Attacken, usw.) schlägt die Watchpoint-Unit zu und das System > geht in eine 'harte' failsafe-Sequenz. Also eine Art Echtzeitüberwachung gegen Programmierfehler, bzw auch Ablauffehler. Wäre die Frage, wie man das standardisiert, daß es als Projekt für andere nutzbar wäre. Ähnliches gibt es als Anforderung in verschiedenen Sicherheitsbereichen, dort wird es aber etwas anders gelöst.
An Fi. schrieb: > aber die Synthesizer scheinen sich ja doch einer > gewissen Beliebtheit zu erfreuen. Die digitalen remakes verkaufen sich > angeblich bestens. Ja, allerdings taucht gerade der AIRA derzeit verdächtig häufig in der Bucht auf, nachdem der Nutzer ihn einige Monate im Gebrauch hatte. Da haben wohl gleich mehrere Produzenten mal schnell nach Erscheinen was ausprobiert und dann, nachdem es eine Weile im Studio rumstand, keine Verwendung mehr für das "digitale remake". Ich finde das seltsam, weil der ja nicht teuer ist, man also nicht viel verliert, umgekehrt kaum was bekommt und einen Synthie mit eigenem Sound eigentlich immer irgendwie gebrauchen kann. Alte Virus-Geräte und Waldorf-Synthies laufen da deutlich besser. Auch die Originale der remakes laufen besser. :D > Vorteil: Bei einem digitalen Abbild der urtümlich > analogen Hardware hat man zumindest die Gewähr, dass die Klangqualität > sich nicht über die Zeit verändert. Das ist zweifellos richtig und auch mein von mir gerne vorgebrachtes Argument für mein Analogmodelling im FPGA. Allerdings habe Ich auch gelernt, daß sehr gute Analoggeräte hoher Qualität (auch Synthesizer) ohne Weiteres 20 Jahre überdauern, ohne wesentlich zu altern. Es gibt da sogar einige Flagschiffe aus den 70ern und 80ern, die von den Nutzern derart gut gewartet sind, daß sie praktisch Neuqualität haben. Davon kann man sich auf privaten Synthi-Messen überzeugen. > Mal davon abgesehen, glaube Ich nicht, dass ausgerechnet die die letzten > gewesen sein sollten, welche sich mit FPGAs befasst haben. Mit irgendwas > werden die die Klang-ASICS in ihren Modellen schon geprototyped haben. Wahrscheinlich. Und mehr noch: Es gibt Firmen, die kaufen VHDL ein, um sie in ihre WAVE-Gen-Asics zu stecken :-) > Wie ist das eigentlich bei Yamaha? Solche DX7-Klassiker müssten > eigentlich auch leicht zu portieren sein. Die den Yamahas eigene Pseudo-FM-Synthese habe Ich in meinem Synth drin, nebst einer Idee von mir, das zu erweitern. Auch die Modifier, wie sie in den OPL-Chips benutzt werden, verwende Ich ähnlich. Allerdings müsste man, um es perfekt abzubilden, die genauen Parameter kennen. Daran happert eigentlich jede Classic-Synth-Emulation. Die Verschaltung kann man noch gut nachbilden, aber die Wirkungsketten sind einfach zu lang, um es auszutesten und richtig darzustellen. Daher funktionieren die patches nicht und es ist oft bei gleicher Struktur nicht möglich, den Sound ähnlich hinzubekommen. Das habe Ich bei meinen Versuchen, vorhandene Synths nachbilden, lernen müssen. Die Firmen rücken da auch nicht mit raus, Yamaha schon mal gleich gar nicht. Mit den richtigen Kontakten, vor allem zu ehemaligen Entwicklern der Musikbranche, geht aber ein bissl was. Trotzdem habe Ich mich davon verabschiedet, existente Klangerzeuger nachzubilden. Wer einen DX7-Klang haben will, soll sich ein Gerät kaufen.
Jetzt mal zu dem anderen Thema hier: Microcontroller mit FPGAs überwachen, ist ein wachsendes Thema, hatte damit auch schon mehrfach zu tun. Auch hier gibt es einige threads dazu, wie diesen: Beitrag "Microcontroller-Sicherheit in MIL-Systemen durch FPGAs erhöhen" Gehen wir mal weiter und überlegen, wie man CPUs überwachen kann, z.B. wird Intel nicht nur deshalb FPGA-Komponenten in ihre CPUs einfügen wollen, um debugging zu betreiben: Welche Möglichkeiten gibt es, direkt auf die CPU(s) einzuwirken, zB. in Sachen Thread-Management / Cache-Management? Strubi schrieb: > Mehr Sinn macht für mich, auf eine Softcore-Architektur aufzubauen, die > eine elegante Einbindung effektiver Watchpoint-Units erlaubt, wie z.B. > gewisse Stackmaschinen. In meiner ZPUng mit WPU habe ich z.B. > Checkpoints im Programm an gewissen kritischen Stellen D.h. Du modifizierst direkt die MCU-VDHL? Oder nur die Software? An F. schrieb: > Ähnliches gibt es als Anforderung in > verschiedenen Sicherheitsbereichen, dort wird es aber etwas anders > gelöst. Beispiele?
Jürgen S. schrieb: > D.h. Du modifizierst direkt die MCU-VDHL? Oder nur die Software? Nur die Software, bzw. RAM-Inhalt, da für eine Programmänderung nicht nochmal die Synthese durchlaufen soll. Allerdings ist das noch SRAM, einen sauberen Weg, um auch distributed RAM (Register-Initialisierung) schnell im Bit-File portabel zu ersetzen habe ich nicht gefunden. Jürgen S. schrieb: > Gehen wir mal weiter und überlegen, wie man CPUs überwachen kann, z.B. > wird Intel nicht nur deshalb FPGA-Komponenten in ihre CPUs einfügen > wollen, um debugging zu betreiben: Ich vermute mal, dass bei Intel wie auch ARM solche Safety-Ansätze architekturbedingt kaum noch machbar sind, die Systeme sind einfach zu komplex geworden. i86 ist ja heutzutage nur noch ein gigantischer Mikrocode-'Workaround'. Das Ziel der FPGA-Integration in die CPUs ist wohl eher die Flexibilität, nah am I/O-Bus schnell vorverarbeiten und routen zu können, also primär Servermarkt, wo die Safety in der Grössenordnung eher irrelevant ist. Für bare metal Safety würde ich mich nie auf einen Intel verlassen, wenn man mich in die Haftung nehmen kann. Was ist z.B. mit Coverage bei i86? Wo du Cache ansprichst: Da gehts ja immens um die letzte Meile an Geschwindigkeit, wie soll da eine FPGA-Logikzelle mit interferieren? Könnte Intel wirklich Interesse dran haben, Nutzern Zugriff auf ihre L1-Cache-Logik zu gewähren? An F. schrieb: > Wäre die Frage, wie man das standardisiert, daß es als > Projekt für andere nutzbar wäre Das lässt sich wohl kaum standardisieren, da eben sehr spezifisch betr. Stack-Maschinen-Architektur. Standard hiesse hier faktisch OpenSource, und dafür muss man schon in der HDL-Welt ne Menge Zeit opfern um das effektiv durchzuziehen. Und dann hat jeder Anwender/Prüfer seine eigenen Vorstellungen von Safety..
Martin S. schrieb: > Ich vermute mal, dass bei Intel wie auch ARM solche Safety-Ansätze > architekturbedingt kaum noch machbar sind, die Systeme sind einfach zu > komplex geworden. Nur bei den dicken ARMs. Für die Kleinen (Cortex-M und so) geht das noch. Die dicken ARM-Chips wirken irgendwie nichtmal im Ansatz wie RISC. > Das Ziel der FPGA-Integration in die CPUs ist wohl eher > die Flexibilität, nah am I/O-Bus schnell vorverarbeiten und > routen zu können, also primär Servermarkt, wo die Safety in der > Grössenordnung eher irrelevant ist. Exakt, einerseits will man (d.h. RZ-Betreiber wie Amazon) Dinge wie IP-Stack und Webserver in den FPGA legen können, andererseits dem Kunden noch mehr Geschwindigkeit für eigene Algorithmen bieten können. Wenn man hört, dass die Preise für Rechenzeit sekundengenau abgerechnet werden, klingt das so ein bisschen wie die Anfangszeit der Computer, nur mit anderen Zeitskalen. Genauso wie Cloud vs. Terminal... > Für bare metal Safety würde ich mich nie auf einen Intel > verlassen, wenn man mich in die Haftung nehmen kann. Das ist eine interessante Frage: Kann man dich dafür in Haftung nehmen, eins der am häufigsten verwendeten Produkte einzusetzen (sofern der Hersteller das nicht explizit ausschließt)? > Wo du Cache ansprichst: Da gehts ja immens um die letzte Meile an > Geschwindigkeit, wie soll da eine FPGA-Logikzelle mit interferieren? > Könnte Intel wirklich Interesse dran haben, Nutzern Zugriff auf ihre > L1-Cache-Logik zu gewähren? Die Xeon-Chips, die ich vor wenigen Jahren auf einer Messe gesehen habe, hatten den FPGA direkt am QPI hängen, also erst hinter dem L3-Cache. Ich bezweifle, dass man überhaupt L1-/L2-Caches sinnvoll aus dem Core rausrouten kann. > Standard hiesse hier faktisch OpenSource, und dafür muss man schon > in der HDL-Welt ne Menge Zeit opfern um das effektiv durchzuziehen. PicoRV32 ist ein formal verifizierter RISC-V Core. Zwar keine Stackmaschine, aber immerhin. Außerdem hat er ein Debug-Interface, mit dem man die ausgeführten Instruktionen in Echtzeit rausrouten könnte, um den Core selbst zu überwachen. Was mich ja viel mehr interessiert ist die Frage, wie man eigentlich einen Compiler - oder insbesondere die ganzen HDL-Toolchains - sauber verifiziert. Wo ist die Garantie, dass Vivado, Quartus oder Diamond keinen Mist bauen? Oder dass die FPGAs auch funktionieren wie beschrieben? Oder gilt dann einfach nur: > Und dann hat jeder Anwender/Prüfer seine eigenen > Vorstellungen von Safety.. Der Hersteller des Tools zertifiziert Fehlerfreiheit und gut ist?
S. R. schrieb: > Was mich ja viel mehr interessiert ist die Frage, wie man eigentlich > einen Compiler - oder insbesondere die ganzen HDL-Toolchains - sauber > verifiziert. Im Prinzip genau so, wie man auch einen SW-Compiler verifiziert, soweit das geht: Per Inititial und Induktion. Die Frage ist, WAS man da verifizieren möchte und inwieweit das sinnvoll ist. Wir haben in der Anfangszeit z.B. die Richtigkeit von RAM-Synthesen am konkreten Beispiel sowie generischer Modifikationen getestet. Auch solche Themen wie automatische Erkennung von FSMs, Richtigkeit deren Codierung in Abhängigkeit der Verzweigung und Sicherheitsgewinn durch one-hot-codierung. Allerdings hat man da schon das Problem, die wenigen Fälle, die nachweisbar funktionieren, voll zu extrapolieren. Meistens beschränkt man sich auf solche Dinge wie Optimierungen. In dem Zusammenhang sind Simulationsoptimierungen bei ModelSIM aufgefallen, allerdings eher anders herum: Sie lieferten falsche Ergebnisse von richtigen Schaltungen. In der jüngeren Zeit ist mir das aber nicht mehr untergekommen. Toolfreigaben gibt es nach einer gewissen Zeit der Nutzung. Man hat seine Erfahrungen mit der Korrektheit einer bestimmten SW-Version und gibt sie irgendwann frei. Die Erfahrungen stammen abgesehen von solchen show stoppern wie errata sheets der Hersteller einfach aus der Praxis - siehe weiter unten. > Wo ist die Garantie, dass Vivado, Quartus oder Diamond > keinen Mist bauen? Oder dass die FPGAs auch funktionieren wie > beschrieben? Eine Garantie für die Richtigkeit der Software mit dem großen X? Der Herr belieben zu scherzen :-) Sobald man etwas vom CoreGen benutzt, hat man doch Fehler und Mängel en masse. Das ist bekannt. Da muss man anders heran: > Oder gilt dann einfach nur: > Der Hersteller des Tools zertifiziert Fehlerfreiheit und gut ist? Mir ist gar nicht genau bekannt, ob und in welchem Umfang Hersteller ÜBERHAUPT etwas formell zertifizieren. Ich wüsste auch nicht, wie das gehen soll: Man liefert das vierteljährliche Update aus und hat zuvor alles regressiv getestet? :D Ok, Ich bin eigentlich sicher, dass X und A ihre SW testen, aber Garantien gibt es da sicher keine. Wie gesagt muss man da anders heran und zwar mit funktionellen Tests, welche die Gerätefunktion im Kontext der Betriebssoftware prüft, da nur so ein Durchgriff bis hin zur Synthese und dem realen Chip besteht. Eine Simulation alleine reicht da nicht. Dieser Sachverhalt war übrigens lange das Argument für manche Projektverantwortlichen und Entwickler, herzlich wenig mittels Simulation zu Verifizieren und lieber gleich in die Synthese zu gehen, da "doch getestet werden muss". Ich sehe das ein wenig anders, da sich Vieles nur in der Simulation effektiv darstellen und prüfen lässt, zumindest sind im virtuellen System Szenarien machbar, die aufgrund Zeit und Kosten real unter den Tisch fallen würden, nach dem Motto "man kann nicht alles testen". An dem Punkt kommt die Risikobewertung ins Spiel: Fehler, die infolge von fehlerhaften Simulationen oder Synthesen eingebaut werden, müssen daraufhin untersucht werden, mit welcher Wahrscheinlichkeit und Auswirkung sie sich letztlich fortpflanzen und dann gfs abgesegnet werden. Meistens ist es aber ohnehin so, dass solche anzunehmenden Fehler kausale Bestandteile von ganzen Verhaltensketten sind, bei denen es mehr- und wahrscheinlichere Störungen gibt, wie z.B. Bedienfehler, Messfehler, Kabelbrüche aber auch trickreiche Programmierfehler, die nur zu sporadischem Fehlverhalten führen. Das federt man dann durch Redundanz ab. Es gibt also irgendwo eine doppelte Berechnung, eine doppelte Messung, eine doppelte Übertragung und sonstige Einrichtungen, die sicherstellen, dass ein System erwartungsgemäß funktioniert. In den Fällen, in denen das während des Tests oder des Betriebs nicht darstellbar ist, werden Testdaten und Testfehler eingespeist (durchaus auch im normal operation mode) die erkannt werden müssen, um die Sicherheitsfunktion zu testen. Z.B. Überläufe von Wandlern, Kabelfehler, RAM-Fehler, oder irgendwelche kippenden Bits werden dann zuverlässig erkannt. Es spielt dann keine Rolle mehr, ob die Schaltung keinen Überlaufschutz hat, ob ein Elektronikfehler vorliegt und später auftritt oder ob die Software was Falsches gebaut hat. Das Problem ist dann mehr, die Ursache zu finden. Die einst glitzernden Teilbilder eines ausgelesenen Sensors entpuppten sich erst nach einiger Zeit als Spartan-6-RAM-Fehler und der Ausfall eines S-RAM-Anschlusses war in der Tat ein SW-Versions-Problem. Die Nutzung von Simulation während der Entwicklung ist somit hauptsächlich eine Frage der Ökonomie der Entwicklung. Was schon durch Verifikation an Fehlern rausgeworfen wurde, kommt nicht in die Synthese und problematisiert später den Komponenten-Test. Was dort wiederum rausgeworfen wurde (z.B. eben ein mögliches, schlechtes Compilat), verkompliziert nicht den Endgerätetest. Der Endtest muss zwar so oder so stattfinden - er geht dann aber nicht wegen einer miesen Syntheseeinstellung oder eines SW-Fehlers daneben und generiert Suchaufwand. Was die Nutzung der Synthestools angeht, kann man z.B. das Gelingen der Synthese zusammen mit der timing-Analyse als Verifikation hernehmen. Dabei werden ja alle wichtigen Extremfälle betrachtet. Das Design muss aus formellen Gründen das timing erfüllen, selbst wenn in einem Test bei Zimmertemperatur alles funktioniert.
Jürgen S. schrieb: >> Oder gilt dann einfach nur: >> Der Hersteller des Tools zertifiziert Fehlerfreiheit und gut ist? > Mir ist gar nicht genau bekannt, ob und in welchem Umfang Hersteller > ÜBERHAUPT etwas formell zertifizieren. Naja, sie behaupten halt, dass ihre Software funktioniert. ;-) Aber danke für die Erklärung... ich lese das einfach mal als "Verifikation der Simulation", "Timinganalyse durch die Software" (= bisschen Vertrauen), "Risikoanalyse plus evtl. Redundanz" und "gründliches Testen des Gesamtsystems" (nicht nur der Komponente).
S. R. schrieb: >> Für bare metal Safety würde ich mich nie auf einen Intel >> verlassen, wenn man mich in die Haftung nehmen kann. > > Das ist eine interessante Frage: Kann man dich dafür in Haftung nehmen, > eins der am häufigsten verwendeten Produkte einzusetzen (sofern der > Hersteller das nicht explizit ausschließt)? Macht das nicht jeder Hersteller? Bei Xilinx steht z.B. sowas in jedem Datenblatt ("Notice of Disclaimer"):
1 | Xilinx products are not designed or intended to be fail-safe or |
2 | for use in any application requiring fail-safe performance; you assume sole risk and liability for use of Xilinx products in Critical |
3 | Applications: http://www.xilinx.com/warranty.htm#critapps. |
Würde mich wundern, wenn das nicht bei Intel auch drin stehen würde. Duke
S. R. schrieb: > Das ist eine interessante Frage: Kann man dich dafür in Haftung nehmen, > eins der am häufigsten verwendeten Produkte einzusetzen (sofern der > Hersteller das nicht explizit ausschließt)? Da stehen überall Disclaimer...hindert ja keinen dran, das Zeug trotzdem zu verbauen. Auch wenn ich an Bug X nicht schuld wäre, müsste ich im Streitfall nachweisen, dass ich einen effektiven Workaround hätte. Für manche dürfte die Anzahl Transistoren per Die schon Ausschlusskriterium sein. Von der Psychologie ganz zu schweigen, die häufig genutzte Systeme (die ebenso häufig gehackt werden) mit sich bringen. Ja, und dann den Nachweis zu erbringen: dazu bräuchte man ein Simulationsmodell... S. R. schrieb: > PicoRV32 ist ein formal verifizierter RISC-V Core. Zwar keine > Stackmaschine, aber immerhin. Außerdem hat er ein Debug-Interface, mit > dem man die ausgeführten Instruktionen in Echtzeit rausrouten könnte, um > den Core selbst zu überwachen. Eine gute Trace-Unit ist IMHO heutzutage eine Mindestanforderung, auch um das Resultat der von dir angesprochenen Tools (denen man wohl einfach vertrauen muss) in der HW zu verifizieren. Jürgen S. schrieb: > Fehler, die infolge von fehlerhaften Simulationen oder Synthesen > eingebaut werden, müssen daraufhin untersucht werden, mit welcher > Wahrscheinlichkeit und Auswirkung sie sich letztlich fortpflanzen und > dann gfs abgesegnet werden. Die Fehlerfortpflanzung ist IMHO der grösste Knackpunkt, der auch am meisten Komplexität beim Testen verursacht. Da frage ich mich, wie das bei einfachen ARMs schon vonstatten gehen soll, wenn ein Effekt eines Glitch am I/O bis auf die Pipeline runter untersucht werden müsste. Konkret hatte ich da mal was auf dem Tisch, wo der alte Klassiker (UART-Pin beim Booten auf L ziehen) ausreichte um alle Sicherheitsfunktionen des Chips ausser Gefecht zu setzen. Fazit: Bug im UART-Core und Boot-ROM. Dann kommt vom "Autor" irgendwann was wie: Das ist ein unrealistischer Fall, der nur in bösartigen Umgebungen auftreten könnte (und wir verbitten uns natürlich jegliche Bösartigkeit). Am Beispiel einer Glitchattacke sollte man dann also zeigen, dass während einigen us alle Arten von 'schwachen Bits' keinen Mist produzieren können. Da reicht die formale Verifikation des Programmcode eben nicht mehr. Würde mich schon noch interessieren, wenn jemand zum Risc-V etwas aus dem Nähkästchen plaudern könnte. Immerhin hat die Opensource-HDL schon das Potential, eine gute Safety(Security) zu ermöglichen. Jürgen S. schrieb: > Man liefert das vierteljährliche Update aus und hat zuvor > alles regressiv getestet? :D Ok, Ich bin eigentlich sicher, dass X und > A ihre SW testen, aber Garantien gibt es da sicher keine. Naja, wenn Timing, Place&Route fehlschlagen würde, gäbe es einiges zu verlieren. Da werden die Hersteller im eigenen Interesse regresstesten. Wo sie fast alle eher 'sloppy' werden, ist im anwender-orientierten SW-Engineering (GUI/Nutzerfreundlichkeit).
Martin S. schrieb: > Da stehen überall Disclaimer...hindert ja keinen dran, das Zeug trotzdem > zu verbauen. Ganz so einfach ist es nicht. Wenn eine Firma z.B. ausdrücklich ausschließt, dass ihr Produkt in der Medizintechnik verwendet werden kann, dann kommt man da nicht so ohne Weiteres drum herum. Das ist auch durchaus bei einigen Produkten der Fall. Ich hatte da schon Chips für bluetooth und WLAN-Kommunikation, sogar Treiber für Busleitungen. Das hat wohl auch damit zu tun, dass eine Firme gfs nicht in einen Fall involviert werden möchte, bzw. schlechte Erfahrungen gemacht hat. In einem Fall gab es mal ein Problem mit der FDA, woraufhin der Lieferant zwei Produkte abgekündigt hat. In einem Fall erging dann die Entscheidung, genau aus diesem Grund, eine Funktion eines Chips im FPGA nachbzubilden, um es dort verifizieren und auch fixen zu können und vor Allem unter Eigenregie zu haben.
Jürgen S. schrieb: > Ganz so einfach ist es nicht. Wenn eine Firma z.B. ausdrücklich > ausschließt, dass ihr Produkt in der Medizintechnik verwendet werden > kann, dann kommt man da nicht so ohne Weiteres drum herum. Das ist auch > durchaus bei einigen Produkten der Fall. Die Gründe dafür waren auch mir lange unverständlich, bis ich eine Unterredung mit einem FAE eines US-amerikanischen Halbleiterherstellers hatte, der mir erklärte, was es für finanzielle Folgen haben kann, wenn irgend ein Unkundiger in den USA oder Canada gegen einen Hersteller klagt, weil er einfach sein Gerät nicht richtig bedient hat. Dann muss das Hersteller nachweisen, dass es funktionieren musste, was er bei Chips nicht kann. Deshalb geben die dann gerne das Risiko an den Hersteller weiter. Da hat es Klagen gegeben. Die Hersteller haben reagiert und schließen die Benutzung aus oder geben die Emphehlung, es nicht zu verwenden. Reine Politik! Jürgen S. schrieb: > An Fi. schrieb: >> aber die Synthesizer scheinen sich ja doch einer >> gewissen Beliebtheit zu erfreuen. Die digitalen remakes verkaufen sich >> angeblich bestens. > > Ja, allerdings taucht gerade der AIRA derzeit verdächtig häufig in der > Bucht auf, nachdem der Nutzer ihn einige Monate im Gebrauch hatte. Da > haben wohl gleich mehrere Produzenten mal schnell nach Erscheinen was > ausprobiert und dann, nachdem es eine Weile im Studio rumstand, keine > Verwendung mehr für das "digitale remake". Das ist mir auch schon aufgefallen. Das gilt auch für andere remakes aus dem Analog-Musik-Umfeld. Taugt alles nicht viel. Momentan werden wieder verstärkt echte analoge Remakes gekauft.
Fpga K. schrieb: > Man kann auch uC mit einem FPGA/CPLD beschleunigen Problem ist > allerdings die Daten zwischen beiden auszutauschen. Das liesse sich mit einem DMA oder verdoppelter Speicherfläche lösen. Oft hängt der FPGA ja auch zwischen einem uc und einem DDR-RAM.
Andreas F. schrieb: > was es für finanzielle Folgen haben kann, wenn > irgend ein Unkundiger in den USA oder Canada gegen einen Hersteller > klagt, weil er einfach sein Gerät nicht richtig bedient hat. Dann muss > das Hersteller nachweisen, dass es funktionieren musste, was er bei > Chips nicht kann. Deshalb geben die dann gerne das Risiko an den > Hersteller weiter. Da hat es Klagen gegeben. Die Hersteller haben > reagiert und schließen die Benutzung aus Das finde ich pervers! Wie verfährt man in einem solchen Fall? Wenn Medizingeräte vernetzt werden, braucht es einen Ethernet-Chip und dasselber gilt für USB. Was verbauen die Medizinfirmen, wenn sie gewisse Chips nicht verwenden dürfen?
Tobias N. schrieb: > Andreas F. schrieb: >> Dann muss >> das Hersteller nachweisen, dass es funktionieren musste, was er bei >> Chips nicht kann. Deshalb geben die dann gerne das Risiko an den >> Hersteller weiter. Da hat es Klagen gegeben. Die Hersteller haben >> reagiert und schließen die Benutzung aus > > Was verbauen die Medizinfirmen, wenn sie gewisse > Chips nicht verwenden dürfen? Sie erbringen den Nachweis, das so wie sie das Gerät entwickelten, der Chip richtig funktionierte, respektive, das Risiko für den Patienten bei 'Fehlverhalten des Chips' minimiert wurde. Also Selfmonitoring, fail-safe design, Redundanzen, keim single point of failure, komplexitätsvermeidung etc. pp.. Auch bei der 'Vernetzung' hat es eine Risikoabschätzung zu geben. Warum vernetzen wenn es keinen wesentlichen Vorteiol für den Patienten gibt..
Fpgakuechle K. schrieb: > Sie erbringen den Nachweis, das so wie sie das Gerät entwickelten, der > Chip richtig funktionierte, Halte ich aber trotzde für kritisch, wenn ein Hersteller sagt, dass seine Zulieferteile nicht geeignet sind. Der Hersteller mit dem gro´ßen X schließt offenbar alles kategorisch aus: Duke Scarring schrieb: > Bei Xilinx steht z.B. sowas in jedem Datenblatt ("Notice of > Disclaimer"): Wie auch immer, würde auch sicher den Rahmen sprengen, das alles aufzuarbeiten. Ich werfe lieber eine weitere Idee für FPGA-Projekte in den Raum: Wie wäre es mit einem Echtzeit-Flugsimulator? Wenn das auf Heim-Computern schon ging, müsste man doch mit FPGAs eine deutlich schnellere und realistischere Grafik hinbekommen, oder?
Tobias N. schrieb: > Halte ich aber trotzde für kritisch, wenn ein Hersteller sagt, dass > seine Zulieferteile nicht geeignet sind. Und warum sollten die nicht geeignet sein? Im OP Saal sind die Randbedingungen nicht wesentlich anderst, als bei dir daheim im Wohnzimmer wo der Bluray Player steht. Warum sollte man den FPGA da nicht verwenden duerfen? Anderst sieht es fuer Anwendungen z.B. im Weltall aus, wo die Chips eine gewissen Strahelnsicherheit mitbringen muessen. Da gibts es dann wirklich spezielle Chips. Du beziehst dich bei Xilinx sicher auf diesen Claim:
1 | PRODUCTS ARE NOT DESIGNED OR INTENDED TO BE FAIL-SAFE, OR FOR USE IN ANY APPLICATION REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS LIFE-SUPPORT OR SAFETY DEVICES OR SYSTEMS, CLASS III MEDICAL DEVICES, NUCLEAR FACILITIES, APPLICATIONS RELATED TO THE DEPLOYMENT OF AIRBAGS, OR ANY OTHER APPLICATIONS THAT COULD LEAD TO DEATH, PERSONAL INJURY OR SEVERE PROPERTY OR ENVIRONMENTAL DAMAGE, OR FOR USE IN ANY APPLICATIONS THAT AFFECT CONTROL OF A VEHICLE OR AIRCRAFT (COLLECTIVELY, “CRITICAL APPLICATIONS”). CUSTOMER AGREES, PRIOR TO USING OR DISTRIBUTING ANY SYSTEMS THAT INCORPORATE PRODUCTS, TO THOROUGHLY TEST THE SAME FOR SAFETY PURPOSES. CUSTOMER FURTHER AGREES TO ASSUME THE SOLE RISK AND LIABILITY OF ANY USE OF PRODUCTS IN CRITICAL APPLICATIONS, SUBJECT ONLY TO APPLICABLE LAWS AND REGULATIONS GOVERNING LIMITATIONS ON PRODUCT LIABILITY, AND CUSTOMER SHALL INDEMNIFY AND HOLD HARMLESS XILINX FROM ANY CLAIMS WITH RESPECT TO OR ARISING FROM SUCH USE. |
Liess dir mal den Teil ab "CUSTOMER AGREES" durch. Xilinx sichert sich da einfach von jedwegen Haftungsanspruechen ab. Ist in den USA nichts ungewoehnliches. Testen musst du dein MEdizinprodukt so oder so, sonst bekommst du keine Zulassung. Daher ist dieser Claim einfach nur Makulatur.
Tobias B. schrieb: > Daher ist dieser Claim einfach nur > Makulatur. > "Testen muss man sowieso" Stimmt eigentlich, aber es wirft trotzdem aus Projektsicht Fragen auf, wenn das opening lautet "not inteded for use" denn wie will man denn ein gegenteiliges "intende" begründen? Für welche Anwendung sind die Bautsteine denn gemacht, wo man nichts testen muss? Conumer und Spielzeug? Aus meiner Sicht ist das zwiespältig. Entweder habe ich eine gewisse Sicherheit mit einem Bauteil, dann kann ich das absolut angeben und muss es nicht auf Branchen einschränken. Komisch ist auch, dass sie es nur für MED Klasse 3 ausschließen, während z.b. die 2 und 2b an denen ich schon gearbeitet habe, genau so am Menschen eingesetzt werden können und schaden können (und folglich getestet werden müssen).
Tobias N. schrieb: > Stimmt eigentlich, aber es wirft trotzdem aus Projektsicht Fragen auf, > wenn das opening lautet "not inteded for use" denn wie will man denn ein > gegenteiliges "intende" begründen? Der Projektleiter den das stutzig macht, sollte schleunigst aufhoeren Projektleiter zu sein oder zumindest raus aus der Medizintechnik. ;-) Tobias N. schrieb: > Komisch ist auch, dass sie es nur > für MED Klasse 3 ausschließen, während z.b. die 2 und 2b an denen ich > schon gearbeitet habe, genau so am Menschen eingesetzt werden können und > schaden können (und folglich getestet werden müssen). Wie gesagt, das sind rein rechtliche Dinge, weil in den USA da alles etwas "spezieller" ist mit den Schadensersatzanforderungen. Was soll den im OP oder am Menschen besonders sein, warum dieser Baustein mit der Umgebung nicht zurechtkommen sollte? Die ganzen Devices werden in Millionen und aber Millionen Stueckzahlen produziert und durchlaufen eine Verifikationskette die dem was die Medizintechnik fordert weit ueberlegen ist. Die Hersteller haben an deren Device Qualitaet ein ganz simples Interesse: Wenn die Teile regelmaessig ausfallen, kauft sie keiner.
:
Bearbeitet durch User
Tobias B. schrieb: > Die ganzen Devices > werden in Millionen und aber Millionen Stueckzahlen produziert und > durchlaufen eine Verifikationskette die dem was die Medizintechnik > fordert weit ueberlegen ist. Verifikationskette, aber nicht Test. Gerade FPGAs werden nicht alle einzeln getestet und die meisten Chips auch nicht. Ferner gibt es kaum einen Chip, der nicht irgendeinen funktioniellen Fehler oder ein Manko hat, denn die findet weder ein Verifikations-tool noch ein ASIC-Compiler. Auch in der formellen Validierung fällt nur auf, was mit einem Reqirement erfasst worden war.
Tobias N. schrieb: > Aus meiner Sicht ist das zwiespältig. Entweder habe ich eine gewisse > Sicherheit mit einem Bauteil, dann kann ich das absolut angeben und muss > es nicht auf Branchen einschränken. Wozu sollte sich ein Hersteller von Bauteilen Deine Probleme aufbürden? Du hast zwei Möglichkeiten: a.) Die Verantwortung selbst übernehmen; das machst Du mit irgendwelchen Tests, Validierungen, Methoden und Versicherungen, b.) Die (Teil-)Verantwortung jemanden anders übernehmen lassen, dazu gibst Du ihm ganz viel Geld, und der macht dann Punkt a (oder b). So simple funktioniert die Welt. Was Du aber willst, ist dass jemand die Verantwortung für Deinen Mist übernimmt, ohne dass Du ihm viel Geld gibst.
Weltbester FPGA-Pongo schrieb im Beitrag #6701607: > Tobias B. schrieb: >> Die ganzen Devices >> werden in Millionen und aber Millionen Stueckzahlen produziert und >> durchlaufen eine Verifikationskette die dem was die Medizintechnik >> fordert weit ueberlegen ist. > > Verifikationskette, aber nicht Test. Gerade FPGAs werden nicht alle > einzeln getestet und die meisten Chips auch nicht. Doch, nach jeden Fertigungsschritt gibt es es einen Test, ob der Schritt (Belichten, Ätzen, Polieren, Implantieren, ...) so gepasst hat/haben müsste. Und es gibt Stichproben durch die QS, die anhand Repräsentativer Einzeltest die Mindestqualität für die gesamte Charge bestimmen. Passt es nicht, wird die Charge nicht weite prozessiert. Und während des processing werden die wichtigsten Parameter (Temperatur, Fluß Arbeitsstoff, etc. überwacht). Passen die nicht wird die Qualität auch nicht passen. Natürlich ist Testabdeckung (test coverage) und Test dauer ein Problem. Dafür werden extra Teststrukturen und Testpattern entwickelt, die möglichst kurz, möglichst viel testen.
Fpgakuechle K. schrieb: > Und es gibt Stichproben durch die QS, die anhand Repräsentativer > Einzeltest die Mindestqualität für die gesamte Charge bestimmen. > [...] > Dafür werden extra Teststrukturen und Testpattern entwickelt, die > möglichst kurz, möglichst viel testen. Eben genau das: Mit Stichproben und Statistik wird eine Kennzahl über den Block gebildet, und die Einzelstücke werden (wenn überhaupt) nur kurz getestet. Damit bekommt man einen recht guten Überblick über die Gesamtqualität. Aber man bekommt keine Garantie für das Einzelstück. Das reicht dann nicht für alle Branchen, also wird der Chip dafür nicht beworben oder explizit ausgenommen. Witzigerweise sind das die gleichen Branchen, in denen der Schadensersatz bei Ausfall irrsinnige Werte annehmen kann.
FPGAs enthalten ja sehr viele identische Schaltungen. Eigentlich wäre da ein Test der Einzelstücke schon sinnvoll denn dann könnte man defekte LUTs z. B. markieren und das Bauteil trotzdem verkaufen und die Waver Ausbeute steigern. Das sind ja doch recht große Siliziumstückchen, da werden schon gelegentlich Fehler vorkommen.
Gustl B. schrieb: > FPGAs enthalten ja sehr viele identische Schaltungen. Eigentlich wäre da > ein Test der Einzelstücke schon sinnvoll denn dann könnte man defekte > LUTs z. B. markieren und das Bauteil trotzdem verkaufen und die Waver > Ausbeute steigern. Das sind ja doch recht große Siliziumstückchen, da > werden schon gelegentlich Fehler vorkommen. Dann würde sich ja u.U. jeder FPGA anders verhalten. Das Route und Place wäre dann für jeden einzelnen Chip nötig und würde auch verschiedene Ergebnisse liefern. Das stelle ich mir auch vom Testen her sehr aufwändig vor.
Guter Punkt! Ich Dachte an Speichermedien, da wird das ja getestet, bei FPGAs macht das tatsächlich keinen Sinn. Was man machen kann als Hersteller ist testen und dann die mit vielen Defekten als kleinere FPGAs verkaufen. Vielleicht wird das ja auch gemacht.
S. R. schrieb: > Aber man bekommt keine Garantie für das Einzelstück. Das reicht dann > nicht für alle Branchen, also wird der Chip dafür nicht beworben oder > explizit ausgenommen. Die Qualitaet, welche dann in die Risikoanalyse einfliesst, kann man aus den Relaibility Reports der entsprechenden Hersteller rauslesen. Ein Beispiel dazu von Xilinx: https://www.xilinx.com/support/documentation/user_guides/ug116.pdf Damit laesst sich dann relativ gut einen Wert fuer die Fehlerwahrscheinlichkeit zum Aufstellen der Riskomatrix entnehmen, bzw. abschaetzen.
Tobias B. schrieb: > S. R. schrieb: >> Aber man bekommt keine Garantie für das Einzelstück. Das reicht dann >> nicht für alle Branchen, also wird der Chip dafür nicht beworben oder >> explizit ausgenommen. > > Die Qualitaet, welche dann in die Risikoanalyse einfliesst, kann man aus > den Relaibility Reports der entsprechenden Hersteller rauslesen. Ein Njein, man kann den Hinweis "PRODUCTS ARE NOT DESIGNED OR INTENDED TO BE FAIL-SAFE, OR FOR USE IN ANY APPLICATION REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS LIFE-SUPPORT ..." nicht nur in Richtung: "Die madigen Teile die trotz QA immer noch ausgeliefert werden, muss der Kunde selbst aussortieren." lesen, sondern auch wie: "Auch ein System aufgebaut aus den nicht-madigen Teilen ist nicht zwangsläufig Ausfallsicher im Sinne der Medizintechnik etc. pp." Wenn man also CPU's der Firma x einbaut, bei der Endfertigung des Gerätes aber nicht darauf achtet, das die richtige (fehlerärmste) Software draufkommt (sondern eine Testversion) und somit die CPU den Patienten ins Verderben steuert, dann ist nicht der Hersteller der CPU dafür verantwortlich (obwohl die Produkthaftung in diese Richtung ausgelegt werden kann). (Beispiel aus der Lauftfahrt: https://www.heise.de/newsticker/meldung/Absturz-des-Airbus-A400M-Doch-Softwarefehler-in-der-Triebwerksteuerung-2678691.html) Als Ingenieur sollte man aber genug 'Handwerkszeug' kennen um die Ausfallsicherheit bis zum geforderten Grad zu verbessern (Komplexitätsvermeidung, funktionalle/strukturelle Redundanz, Safe-Harbor-Zustande im Arbeitsprozess, self monitoring, closed loop, sau8berer Entwurfsprozess (regression tests, Änderungsdokumentation,test-the-test, sauberes Konfigurationsmanagment).
Fpgakuechle K. schrieb: > nicht nur in Richtung: "Die madigen Teile die trotz QA immer noch > ausgeliefert werden, muss der Kunde selbst aussortieren." lesen, sondern > auch wie: "Auch ein System aufgebaut aus den nicht-madigen Teilen ist > nicht zwangsläufig Ausfallsicher im Sinne der Medizintechnik etc. pp." > > Wenn man also CPU's der Firma x einbaut, bei der Endfertigung des > Gerätes aber nicht darauf achtet, das die richtige (fehlerärmste) > Software draufkommt (sondern eine Testversion) und somit die CPU den > Patienten ins Verderben steuert, dann ist nicht der Hersteller der CPU > dafür verantwortlich (obwohl die Produkthaftung in diese Richtung > ausgelegt werden kann). Versteh ich nicht, das eine schliesst das andere doch nicht aus. In deiner Riskoanalyse hast du z.B. den Punkt: Hardware Defekt FPGA. Je nach Auswirkung (das kann zwischen aergerlich fuer den Kunden und dessen Tod rangieren) muessen jetzt entsprechende Gegenmassnahmen eingeleitet werden. Eine ist z.B. ein 100% Systemtest. ODer was man auch amchen kann ein ICT Test, dann prueft man die FPGAs idealerweise noch direkt in der Fertigung. Wenn das nicht ausreicht, weil die Teile z.B. auch ausfallen koennen, muss man sich weitere Strategien ueberlegen. Z.B. Redundanz im System. Und wenn das nicht reicht, dreifache und wenn das nicht reicht vierfache, usw. Man sieht, es wuerde nie aufhoeren, weil man nie ein 100% ausfallsicheres System bekommt. Ab wann der Grad an Sicherheit erreicht ist, entscheidet halt die Risikoanalyse nicht ein Warnhinweis des Herstellers. Dieser kann maximal in die Risikoanalyse mit einfliessen, ist aber keinesfalls ein zwingender Showstopper.
Tobias B. schrieb: > Versteh ich nicht, das eine schliesst das andere doch nicht aus. > > In deiner Riskoanalyse hast du z.B. den Punkt: Hardware Defekt FPGA. Je > nach Auswirkung (das kann zwischen aergerlich fuer den Kunden und dessen > Tod rangieren) muessen jetzt entsprechende Gegenmassnahmen eingeleitet > werden. > > Eine ist z.B. ein 100% Systemtest. ODer was man auch amchen kann ein ICT > Test, dann prueft man die FPGAs idealerweise noch direkt in der > Fertigung. > > Wenn das nicht ausreicht, weil die Teile z.B. auch ausfallen koennen, > muss man sich weitere Strategien ueberlegen. Z.B. Redundanz im System. > Und wenn das nicht reicht, dreifache und wenn das nicht reicht > vierfache, usw. Man sieht, es wuerde nie aufhoeren, weil man nie ein > 100% ausfallsicheres System bekommt. Hm, vielleicht ein Übersetzungsproblem: "Fail-Safe"(Ausfallsicher?) und "Fail into Safe" (Schadensbegrenzung?) Man betrachtet eben nicht nur den Ausfall an sich, sondern die Auswirkung des Ausfalls. Und da gibt es eben counter measure (gegen den Ausfall gerichtet) und Mitigation (Abschwächung) (gegen die fatalen Auswirkungen des Ausfalls gerichtet). Und dann schaut man eben nach Single source of failure"verursacht durch "shared resources". Also was nützt die Vervielfachung der CPU's, wenn die Ausfallursache (Überspannungsspike) wegen der gemeinsamen Masse alle CPU;s gleichzeitig erreicht ?!. Also schaut man das man im System auch einen unabhängigen Pfad zur Steuerung hat. Das kann ein manueller Eingriff sein (NotAus-Buzzer) der über eine gepufferte Stromversorgung (GoldCap-Batterie) das system in einen sicheren Zustand überführt. Auch redundante System dürfen ausfallen, aber eben nicht alle gleichzeitig oder unmittelbar hintereinander (Kaskaden-Effekt).
Alles in allem steht bei diesen ganzen Betrachtungen die Risikoanalyse im Vordergrund. Auch bei einem redundanten System, koennte rein zufaellig und super unwahrscheinlich, beide Teilsystem gleichzeitig ausfallen, z.B. Hardware bedingter Defekt. Irgendwann muss man dann halt mal das geringe Restrisiko in Kauf nehmen, sonst kann kein Produkt zu Land, zu Wasser oder in der Luft an den Start gehen. ;-) Aber um nochmal auf die eigene Frage zurueckzukommen: Nur weil z.B. Xilinx diesen Hinweis mit ihren Produkten, IPs, etc. rausgibt, heisst es noch lange nicht, dass deren Material in Klasse 3 Medizinprodukten verwendet werden darf. Ich muss halt in meiner Risikoanalyse schluessig nachvollziehbar darlegen, warum ich mich fuer den entsprechend Chip entscheide und ob das Produkt aus Ausfallwahrscheinlichkeit und moeglicher Schaden mich dazu zwingt entsprechende Risikominimierungsmassnahmen zu treffen oder nicht. Mehr ist es, zumindest in der Medizintechnik fuer die ich sprechen kann, nicht.
Leute, kommt mal wieder auf's Thema zurück: Da sucht der TO nach Einsatzfällen für FPGA von mäßiger Kompliziertheit, weil er selbst offenbar zu tief in der Furche steht, um über deren Rand zu blicken. Ich hätte da noch einen Vorschlag: Bau aus einem FPGA oder CPLD und einem beliebigen µC einen ordentlichen digitalen Universalzähler. So ein Ding, was sowohl Frequenzen bis - na, sagen wir mal - 10 GHz und Zeiten bis 10 Sekunden mit 100 ps Auflösung und gleicher Absolutgenauigkeit messen kann und nicht bloß eine auf dem Basteltisch herumfliegende LP nebst Draht-Igel ist, sondern ein fertiges durchkonstruiertes Gerät. W.S.
W.S. schrieb: > Leute, kommt mal wieder auf's Thema zurück: Da sucht der TO nach > Einsatzfällen für FPGA Der TO ist glaube ich schon lange weg - er hat seit der Themeneröffnung ein Haus gebaut und eine Familie gegründet ;-)
W.S. schrieb: > Bau aus einem FPGA oder CPLD und > einem beliebigen µC einen ordentlichen digitalen Universalzähler. So ein > Ding, was sowohl Frequenzen bis - na, sagen wir mal - 10 GHz und Zeiten > bis 10 Sekunden mit 100 ps Auflösung und gleicher Absolutgenauigkeit > messen kann und nicht bloß eine auf dem Basteltisch herumfliegende LP > nebst Draht-Igel ist, sondern ein fertiges durchkonstruiertes Gerät. und wozu sollte so etwas gebaut werden? Einfache Zähler gibt es vom Chinesen in der Bucht und hochgenaue Systeme erfordern gutes Analogdesign, um auf Bruchteile von ns genau zählen zu können. Das ist dann kein FPGA-Projekt mehr.
Tobias N. schrieb: > und wozu sollte so etwas gebaut werden? Ja, wozu eigentlich? Und warum baue ich Dinge mit FPGAs, wenn es doch eigentlich schon alles gibt (beim Chinesen)? Ich sag's Dir: 1. Man lernt was dabei. 2. Man hat die Funktionalität selbst in der Hand uns ist nur begrenzt vom eigenen Wissen und Budget. Gebaut und billig verkauft wird nämlich nur das, was sich in der breiten Masse auch absetzen lässt. Duke
Gustl B. schrieb: > Was man machen kann als > Hersteller ist testen und dann die mit vielen Defekten als kleinere > FPGAs verkaufen. Vielleicht wird das ja auch gemacht. Denke ich nicht, dass "viele Defekte" ausschlaggebend sind. Eher, ob es kleinere Varianten gibt, die Fehlerfrei sind, während die größeren Varianten Fehler hätten.
Mampf F. schrieb: > Eher, ob es kleinere Varianten gibt, die Fehlerfrei sind, während die > größeren Varianten Fehler hätten. Definitiv nicht. Die "kleinen Varianten" sind dediziert produzierte Chips mit weniger Chipfläche, die ihr eigenes bond-Schema haben. Man kann nicht einfach einen großen Chip, der Teilfehler hat, in ein kleines Gehäuse packen und /oder ihn als Kleinen verkaufen. Das müsste im Gehäuse oder auf dem Chip vorgesehen werden und das ist viel zu teuer. Ich glaube auch nicht, dass es gelingt, mehr FPGA-Fläche vorzusehen und einiges davon totzulegen, falls es nicht geht, wie manche meinen. Kaputte FPGAs werden aussortiert. Mit Bildsensoren wird das gemacht, allerdings bekommen die ein EEPROM beigepackt, in dem die Zeilen und Pixelfehler dokumentiert sind, damit die Fehlerkorrektur "betrügen" kann, indem sie interpoliert. Bei den FPGAs wird man einfach produktionstechnisch weit genug von den Möglichkeiten wegbleiben, um die Ausbeute zu bekommen, d.h. man könnte kleiner, enger, schneller etc, produziert aber nicht am limit. Dann werden sie mit einem in-Circuit-Tester die teueren FPGAs beladen und schauen, ob sie funktionieren. Das lässt sich ja leicht machen. Die billigen werden jedenfalls nicht vollständig getestet. Das ist nebenbei der Grund, warum wir in vielen Anwendungen FPGAs auf Steckboards einsetzen mit B2B-connector: Die Platine kostet um die 1.500 und soll nicht weggeworfen werden, wenn der FPGA nicht tut. Soweit mir bekannt, hatten wir in der Produktion dieses Systems so 15-20m den Fall, dass sich FPGAs beladen liessen aber komische Fehler zeigten. Das FPGA-System hat noch Flashes mit drauf, die ebenfalls kaputtgeschrieben werden können, obendrein kann das System mit Minderbstückung aufgerüstet werden, indem einfach ein FPGA-Stecksystem mit mehr Power eingefügt wird. Drei Fliegen mit einer Klappe. Was sie natürlich tun, ist ein Selektieren nach maximaler Geschwindigkeit: Bei Typen die es in verschiedenen Geschwindigkeiten gibt, kann man sicher sein, dass das ein und dasselbe Chip-Layout ist, dass mal besser und mal weniger gut produziert wurde. Was anders sind LoPower-FPGAs: Die werden entsprechend gebaut. Von Altera weiß ich, dass sie Cyclone II Chips doppelt selektierten. Es gab eine Lo Power und eine Fast-Version. Die Lo-power, die an sich schon langsam sind, die nicht low genug waren wurden als billige Chips verkauft. Ebenso die Fast, die nicht schnell genug waren. Damit hatte der Kunde beim Kauf eines billigen Chips entweder einen Stromfresser, der zufällig langsam war, oder einen systematisch langsamen, der zufällig etwas mehr Strom aufnahm. Wir haben damals die Dinger Chargenweise erstanden und auf Steck-Boards löten lassen. Als sie vom Bestücker kamen, hat ein Werkstudent sie in den Tester gesteckt und gemessen. Die Stromsparer haben wir in die Stromspar-Anwendung verbaut und die Fresser in die andere, wo es egal war. Die Chips waren extrem billig, teileise im einstelligen Eurobereich.
Weltbester FPGA-Pongo schrieb im Beitrag #6716210: > Kaputte FPGAs werden aussortiert. Würde den wahnsinnigen Preis der Monster erklären :-)
Mampf F. schrieb: > Würde den wahnsinnigen Preis der Monster erklären :-) Würde ich gar nicht mal sagen. Ein FPGA Design zu erzeugen, dass einen eigenen, wohl bekannten FPGA mit all einen Funktionen testet, ist einfach zu machen. Das Meisten ist schon da, weil es zu allen Komponenten Verilog Modelle gibt, mit denen die ASIC-HW simuliert und erzeugt worden ist. Von daher ist so etwas schnell zusammenzustecken. Einmal compile und fertig. Das hineinzuladen und in einem Chip-Tester durchrattern zu lassen, damit alle Funktionen einmal tickeln, sollte nicht viel kosten. Ein ASIC-Test kostet rund 100,- die Stunde und ist in wenigen Minuten durch. Das sind laut unseres Lieferanten 3,- pro Chip. Lohnt sich halt nur bei Chips, die 10,- .. 20,- in der Herstellung kosten und wenn ausreichend viele kaputte gefiltert werden. So ein dicker FPGA ist für 5,- ... 10,- Euro zu testen, ein Chiptest-Aufbau für FPGAs wird mit 250.000 veranschlagt, inklusive Testsoftware anpassen. Muss man eben 10.000 verkaufen, damit sich das gut umlegen lässt und die 100,- euro -Grenze unterschreitet. Ich denke, dass die meisten Kosten einfach die Produktion des Chips selber sind. Einen unserer Aufträge hochskaliert sind das rund 10-20 Mio Fixkosten zum Produktionsanlauf, wenn alles steht. Jetzt ist die Frage, was die Neuentwicklung eines FPGAs kostet. Irgendwas zwischen 10% und 50% so eines Chips müssen jeweils komplett neu gemacht werden. Ausgehend von unseren Chip-Designer-Kapazitäten sind das 20-40 Designer x 1-2 Jahre x 150k, also 50-200 Mio. Das ist der große Brocken, der umgelegt werden muss. Nicht zu vergessen, die paar Euro für die 9-Dollar-Inder, die Vivado an den neuen Chip anpassen.
Tobias N. schrieb: > und wozu sollte... OK, man kann sich auf den Standpunkt des reinen Käufers stellen: Gebaut wird nichts, was es bereits zu kaufen gibt. Man kann das verallgemeinern: Wozu schreiben wir hier eigentlich? Es ist doch bereits alles gesagt. W.S.
Weltbester FPGA-Pongo schrieb im Beitrag #6716210: > Die "kleinen Varianten" sind dediziert produzierte > Chips mit weniger Chipfläche, die ihr eigenes bond-Schema haben. Man > kann nicht einfach einen großen Chip, der Teilfehler hat, in ein kleines > Gehäuse packen und /oder ihn als Kleinen verkaufen. Glaube ich nicht. Es gibt oft größere und kleinere FPGAs die pinkompatibel sind. Ich stelle mir das so vor: Man fertigt nur wenige Modelle, die testet man und dann verkauft man Exemplare mit Fehlern als kleineres Modell im gleichen Package oder bondet defekte IO Bänke nicht und verkauft die in einem anderen Package. Bei CPUs wird/wurde das gemacht, wenn teile vom Cache defeht waren oder ein CPU Kern, dann wurde der Kern deaktiviert und das Exemplar als kleineres Modell verkauft. Bei FPGAs könnte man die DSPs, BRAMs und so testen und danach selektieren.
Gustl B. schrieb: > Weltbester FPGA-Pongo schrieb im Beitrag #6716210: >> Die "kleinen Varianten" sind dediziert produzierte >> Chips mit weniger Chipfläche, die ihr eigenes bond-Schema haben. Man >> kann nicht einfach einen großen Chip, der Teilfehler hat, in ein kleines >> Gehäuse packen und /oder ihn als Kleinen verkaufen. > > Glaube ich nicht. Es gibt oft größere und kleinere FPGAs die > pinkompatibel sind. Ich stelle mir das so vor: > > Man fertigt nur wenige Modelle, die testet man und dann verkauft man > Exemplare mit Fehlern als kleineres Modell im gleichen Package oder > bondet defekte IO Bänke nicht und verkauft die in einem anderen Package. > Bei CPUs wird/wurde das gemacht, wenn teile vom Cache defeht waren oder > ein CPU Kern, dann wurde der Kern deaktiviert und das Exemplar als > kleineres Modell verkauft. Bei FPGAs könnte man die DSPs, BRAMs und so > testen und danach selektieren. Moin Gustl, da hast du leider die Funktionsweise von FPGAs nicht ganz verstanden... Ein Prozessor wird normal extra so aufgebaut, dass die Laufzeiten der Signale im Rahmen des Taktes genau so passen, sodass man einzelne Kerne deaktivieren kann. Bei einem FPGA, welches flexible ist, ist das nicht so einfach möglich! Nach der Synthese des FPGA Designs kommt das Placement und bei dem muss genau bekannt sein, welche Teile wo genau im Chips verwendet werden. Das entscheidet dann die Routen durch den Chip, aber auch die Signallaufzeit, welche besonders bei komplexeren Designs entscheident ist. Die FPGA Tools (nennenswert Vivado und Quatus) erlauben es dir sogar dir eignzelnen Zellen des Chips genau einzusehen und auch zu manupulieren. Speziell in komplexeren FPGA Designs ist dies nicht mehr optional und der Entwickler muss genau sein FPGA kennen und einzelne Komponenten adressieren! Bei einer CPU hingegen wird einfach nur auf eine Ausführung an einem belibigen Ort gesetzt.
Das Problem ist ein Anderes. Wenn man selektieren würde dann wäre ein Bitstream nicht mehr für alle Modelle einer Modellreihe verwendbar sondern man müsste dem Synthesetool mitteilen welche Defekte das Exemplar hat und dann speziell für einzelne Exemplare Bitstreams bauen. Ginge bestimmt, wird aber wohl nicht gemacht und wäre aufwändig.
Gustl B. schrieb: > Das Problem ist ein Anderes. Wenn man selektieren würde dann wäre > ein > Bitstream nicht mehr für alle Modelle einer Modellreihe verwendbar > sondern man müsste dem Synthesetool mitteilen welche Defekte das > Exemplar hat und dann speziell für einzelne Exemplare Bitstreams bauen. > Ginge bestimmt, wird aber wohl nicht gemacht und wäre aufwändig. 1. Das Synthesetool hat mit dem Placement nichts zu tun, sondern übersetzt die Modellierungssprache nur in ein Ziel verständliches Model. 2. Die Idee mag erstmal klug wirken ist aber aus mindestens zwei Gründen absoluter Unfug und kann auch lebensgefährlich enden (FPGAs landen auch in Beatmungsgeräten und anderen Geräten): a) Das Tool bekommt zum Teil spezifischen Input des Design Engineers, welcher keinerlei Bedeutung mehr hätte, wenn sich die Position im Chip und die Laufzeit verändern würde. Simpler Hinweis zu den Bedeutungen: Es gibt globale und regionale Taktnetze, die unterschiedliche Wirkungen haben. b)Ignorieren wir mal Punkt a. und fokussieren uns einfach nur auf Rechenleistung. Das Routing eines kleineren FPGAs kann im Grenzbereich bei erhöhten Füllgrad gerne mal 30 Minuten dauern. Bei größeren FPGAs (z.b. Virtex Reihe) gehen wir hier mal von Stunden aus. Selbst wenn die Positionen im Chip und die entsprechende Beschreibung keine Rolle spielen würden, dann würden wir hier pro gefertigter Instanz des Produkts im Zweifelsfall von Stunden zusätzlicher Rechenleistung ausgehen müssen. Was für eine Firma würde sowas in kauf nehmen wollen?
gandalf schrieb: > Das Tool bekommt zum Teil spezifischen Input des Design Engineers, > welcher keinerlei Bedeutung mehr hätte, wenn sich die Position im Chip > und die Laufzeit verändern würde. Doch nicht zur Laufzeit. Das Tool, Synthese und P&R bekommt aber mitgeteilt was in dem Chip wo vorhanden ist und was nicht. Wenn da etwas vom Design vorgegeben ist was aber nicht im Chip vorhanden ist, dann geht das schlicht nicht. Ist doch auch jetzt schon so, dass man problemlos mehr Logik, BRAM, ... in seiner Beschreibung verwenden kann als im FPGA verfügbar ist. Da kommt dann schlicht kein Bitstream bei rum. Ja, finanziell lohnt sich das nicht. Da bleibt die Frage ob das nicht weniger freingranular ginge. So FPGAs sind oft in recht große Bereiche aufgeteilt. Wenn man also ein großes und ein kleines FPGA hat die sich in einigen Bereichen identisch sind, dann könnte man vielleicht die Bereiche deaktivieren die das große FPGA zusätzlich eingebaut hat wenn die einen Defekt haben.
Gustl B. schrieb: > Ja, finanziell lohnt sich das nicht. Da bleibt die Frage ob das nicht > weniger freingranular ginge. So FPGAs sind oft in recht große Bereiche > aufgeteilt. Wenn man also ein großes und ein kleines FPGA hat die sich > in einigen Bereichen identisch sind, dann könnte man vielleicht die > Bereiche deaktivieren die das große FPGA zusätzlich eingebaut hat wenn > die einen Defekt haben. Ich gehe zu meiner initialen Aussage zurück: schau dir mal ein richtigen FPGA an. In jedem FPGA spielt jeder einzelne Bereich eine genaue Rolle und hat einen Bezug zu den einzelnen IOs. Was du vorschlägst ist eine Trennung von IO Schaltungen und der berechnenden Logik mit synchronisierten Laufzeiten der Signale. Das würde entsprechende FPGAs viel komplizierter machen und nicht unbedingt den Ausschuss verringern. Nimm dir mal als Beispiel Mikrocontroller. Die können auch keine einzelnen Kerne deaktivieren und wenn da mal ein Chip nicht funktioniert, dann werden die einfach aussortiert. So einfach geht das und so einfach muss es auch leider laufen.
Klar hängen die IOs da mit dran. Aber die muss man nicht alle bonden. Es gibt das gleiche FPGA Modell oft in vielen Packages, mal mit mehr mal mit weniger IOs. Da könnte ich mir schon vorstellen, dass in den kleineren Packages FPGAs verwendet werden bei denen manche IO Bänke Defekte haben. Einen XC7A15T gibt es mit 106 IOs aber auch mit 250 IOs zu kaufen und mal mit Trasceivern und mal ohne. gandalf schrieb: > Das > würde entsprechende FPGAs viel komplizierter machen und nicht unbedingt > den Ausschuss verringern. Das wird spannend, denn genau das macht Xilinx bei den Versals. Da gibt es viele Hardwareblöcke die durch ein NoC untereinander verbunden sind. Die programmierbare Logic ist dabei nur einer der Hardwareblöcke.
Ok, vereinfachen wir die Diskussion: Ein CPU Hersteller entwickelt eine CPU mit 6 Kernen. Als fertige Produkte werden einmal die Premium 6 Kern CPU, sowie eine 4 Kern und eine 2 Kern CPU angeboten. Wir stellen uns dabei die Matrix bei der Premium Variante so vor: Kernel: 1, 2 ,3 ,4 ,5 ,6 Welche Kerne in den nicht premium Varianten verwendet werden spielt keine Rolle. Den alle Chips mit entsprechenden Schäden an den IOs werden sowieso aussortiert. Die Laufzeiten sind vom Design her sowieso betrachtet und in entsprechenden Mux und Demux vorgesehen. Wie machst du das bei einem FPGA? Nach welchem Schema willst du einzelne Bereiche des Chips raus werfen? Darf es nur die Gruppe 1, 2 und 3 sein oder wie machst du die Mischung? Und wie garantierst du die genaue Arbeit der anderen Kerne?
gandalf schrieb: > Wie machst du das bei einem FPGA? Gar nicht. Wenn an einem einzelnen FPGA der Block-RAM oder MRAM kaputt ist, wird der aussortiert, sofern man es findet. @Gustl: Der Umstand, dass kleine FPGA im selben Gehäuse existieren, wie größere impliziert nicht, dass sie dieselbe Chip-Struktur haben. Sie haben eventuell das gleiche bond-Schema aber das ist hier gewollt und die kleinen werden dadurch gebaut, dass man von vorn herein weniger einbaut und damit kleinere Chipflächen hat. Die Beispiele, die für das "Retten" defekter Chips genannt hast, sind ASIC, bei denen ungewollt ein Fehler im Design sass und dann einer überlegt hat, was man damit machen kann. Das könnte es beim FPGA auch mal geben, aber dort wird das eher durch work arounds in der SW gelöst, wie das bekannte Adressproblem beim Spartan 6.
Weltbester FPGA-Pongo schrieb im Beitrag #6717436: > Die Beispiele, die für das "Retten" defekter Chips genannt hast, sind > ASIC, bei denen ungewollt ein Fehler im Design sass Nein. Beim Phenom X3 wurde schlicht ein CPU Kern deaktiviert. Klar kann man auch von Hause aus gleich kleinere Chips fertigen lassen. Aber wenn man größere fertigt und da die Ausbeute nicht so hoch ist wäre es schon sinnvoll einen Teil davon als kleinere Chips noch verkaufen zu können. Bei FPGAs müsste dann aber der funktionierende, also defektfreie, Teil vollständig mindestens dem kleineren FPGA Modell entsprechen. Sprich man lässt nur Zeug weg das da noch zusätzlich mehr dabei wäre. Ob das so ist weiß ich nicht. Bei SoCs und so ist das aber sehr weit verbreitet. Gibt es den Unterschied ASIC/FPGA überhaupt bei der Chipfertigung? Also macht das für die Fertigung einen Unterschied? Einmal ist das ASIC, also das A in dem ASIC die CPU/SoC/... und einmal steht das A für rekonfigurierbar. Am Ende ist eine CPU oder ein FPGA beides Hardware die sich zur Laufzeit nicht mehr verändert, das ist fest im Chip. Wenn da ein Defekt ist dann ist der da. So ein FPGA ist auch gar nicht rekonfigurierbare Hardware denn die Hardware verändert sich nicht, es sieht nur für den Anwender so aus als wäre sie konfigurierbar.
So so. Ihr seid jetzt also beim Diskutieren bei "wie verscherbelt man fehlerhafte Chips" angekommen. Ich schätze mal, daß der TO daraus keine Ideen schöpfen kann, was er mit seinen grad auf Hochglanz polierten Fähigkeiten beim Schreiben von VHDL oder so anstellen kann. Andererseits scheinen konkrete Vorschläge, die zu einem benutzbaren Gerät führen, hier nicht wirklich in Betracht zu kommen, also WOZU wird hier WAS diskutiert? W.S.
W.S. schrieb: > Ihr seid jetzt also beim Diskutieren bei "wie verscherbelt man > fehlerhafte Chips" angekommen. Vielleicht wäre es ein nettes Projekt, einen Code zu schreiben, der defekte Chips aufspüren kann. Oder einen, der die maximale Geschwindigkeit eines FPGA aufdeckt. So eine Art Benchmark, den man reinladen kann und schaut, ob der eigene FPGA in der SPEC ist.
Gustl B. schrieb: > Bei FPGAs müsste dann aber der funktionierende, also defektfreie, Teil > vollständig mindestens dem kleineren FPGA Modell entsprechen. Sprich man > lässt nur Zeug weg das da noch zusätzlich mehr dabei wäre. Ob das so ist > weiß ich nicht. Bei SoCs und so ist das aber sehr weit verbreitet. Das ist jetzt erstmal in kleinem Rahmen theoretisch möglich, wobei sich aber die Aufbauten von einer regulären CPU deutlich unterscheiden und das nicht unbedingt eins zu eins transferierter ist. Eine normale Computer CPU, die du die ganze Zeit referenziert, sind sehr komplexe CISC Prozessoren und es dort bisher ein anderes Thema Teile auszuschalten, sodass es keine Konsequenzen gibt. Gustl B. schrieb: > Gibt es den Unterschied ASIC/FPGA überhaupt bei der Chipfertigung? Also > macht das für die Fertigung einen Unterschied? Einmal ist das ASIC, also > das A in dem ASIC die CPU/SoC/... und einmal steht das A für > rekonfigurierbar. Am Ende ist eine CPU oder ein FPGA beides Hardware die > sich zur Laufzeit nicht mehr verändert, das ist fest im Chip. Wenn da > ein Defekt ist dann ist der da. So ein FPGA ist auch gar nicht > rekonfigurierbare Hardware denn die Hardware verändert sich nicht, es > sieht nur für den Anwender so aus als wäre sie konfigurierbar. Hier möchte ich dir noch einmal darauf hinweisen, dass du im unter deinem Namen schreibst und dies auch in Zukunft bei Bewerbungen gefunden werden kann... Das A in ASIC steh nicht für die CPU/SoC/... es steht für Application und gerade das ist in CPU und SoC nicht enthalten. Ein FTDI UART<->USB Wandler ist ein ASIC, da er eine spezifische Anwendung realisiert, ein SoC ist ein SoC und die Application wird durch die Software definiert. Und das A in FPGA steht auch nicht für konfigurierbAr, sondern für Array... Und dieses Array sagt nicht Konfigurierbarkeit aus. Bitte spende einfach etwas Zeit die Themen, über die du schreibst, zu verstehen. Der markierte Absatz deutet aber an, dass du weder die Fachbegriffe, noch die Englische Sprache verstehst.
gandalf schrieb: > Ein FTDI UART<->USB > Wandler ist ein ASIC Welche Anwendung wird denn da realisiert? JTAG? UART? SYNC FIFO? Nur FIFO? SPI? Tja das sind viele Anwendungen die da möglich sind mit so einem ASIC. Und genauso sieht das mit einer CPU aus, da sind auch sehr viele Anwendungen möglich aber eben nicht alle. Ich will sagen die Einteilung in ASIC oder nicht ist nicht sinnvoll. Es gibt Chips und die werden gefertigt um für irgendetwas nützlich zu sein, da kann man sagen ein Anwendungsfeld oder so. Aber wenn ein Chip gefertigt ist, dann ist das feste Hardware, die ändert sich nicht mehr. Gut, fusebits die man durchbrennen kann, OK, aber sonst bleibt das unverändert. Auch im FPGA. Es sieht nur so aus als wäre die Hardware veränderbar weil sich das Verhalten ändert aber in Wirklichkeit ändert sich die Hardware nicht. Und dann sind das Graustufen. Es gibt Chips die dienen nur für wenige Anwendungen bis hin zu Chips die für viele Anwendungen taugen. SoC oder FPGA kann man auch als Anwendung sehen. Der Chip wird eben gefertigt um als FPGA rekonfigurierbar zu sein oder Rechner zu dienen. gandalf schrieb: > Hier möchte ich dir noch einmal darauf hinweisen, dass du im unter > deinem Namen schreibst und dies auch in Zukunft bei Bewerbungen gefunden > werden kann... Selbstverständlich, das mache ich seit vielen Jahren. Durch mein Lehramtstudium habe ich immer einen gut bezahlten Plan B. gandalf schrieb: > Und das A in FPGA steht auch nicht für konfigurierbAr, sondern für > Array... Das habe ich nicht behauptet. Ich meinte das gleiche A in ASIC. Für mich ist ein FPGA ein ASIC und ein FTDI Stein ebenfalls nur unterscheiden sie sich eben in dem was man unter der Anwendung versteht. Ja, das FPGA ist universeller, kann also in mehr Anwendungen verwendet werden aber trotzdem nicht für alle Anwendungen. Ist also daher Anwendungsspezifisch. Aber wie schon gesagt macht die Unterscheidung ASIC oder nicht aus meiner Sicht keinen Sinn. Selbst viele Chips mit CPUs sind klar auf eine Anwendung zugeschnitten. gandalf schrieb: > Der markierte Absatz deutet aber an, dass du weder die > Fachbegriffe, noch die Englische Sprache verstehst. Alles Gute, alles Liebe (-:
Lieber Gustl, bitte nimm dir noch eimal die Zeit in Ruhe und in Entspannung über deine Aussagen nachzudenken. Gustl B. schrieb: > ... Für mich ist ein FPGA ein ASIC und ... Du bist aber nicht das Maß der Dinge, sondern es sind die Leute, die den Fachbereich prägen und definieren. Dazu gehören Berufsschullehrer nicht. Stell dir doch bitte einmal vor, dass deine Schüler deine Meinung in die Wirtschaft tragen. Dann treffen sie auf Akademiker, die zum Teil Doktortitel haben, und kollidieren dann komplett mit den Verständnissen. Dann heißt es bei deinen Schülern "Ja, aber Herr Gustl hat gesagt, dass ein FPGA ein ASIC ist." und die Antwort ist dann nur "Ok, dein Lehrer hat keine Ahung gehabt." Gustl B. schrieb: > Ich will sagen die Einteilung in ASIC oder nicht ist nicht sinnvoll. Es > gibt Chips und die werden gefertigt um für irgendetwas nützlich zu sein, > da kann man sagen ein Anwendungsfeld oder so. Aber wenn ein Chip > gefertigt ist, dann ist das feste Hardware, die ändert sich nicht mehr. ASIC ist nicht die Einteilung in fertigen Chip, sondern es ist die Einteilung in spezifische Lösungen, die von einem FPGA abgebildet werden können, aber in einem gezielten Chip realisiert werden können. Für nichts anderes steht der Begriff. Da ich selber mal vor meinem Studium eine Fachkraft gewesen bin, bitte ich dich an dieser Stelle inständig noch einmal eine richtige Recherche zu betreiben und im Zweifelsfall Fragen an fachkundiges Personal zu stellen. Stell dir einfach nur die Schüler vor, dennen du helfen willst. Willst du wirklich inkauf nehmen, dass du da unfug erzählst und deine top Schüler, die du fördern willst, bei guten Stellen aussortiert werden, weil sie deine Aussagen wiederholen?
@Gustl: Du verbeisst dich in die Theorie, dass man Firmen im großem Stile Hardware verbauen und dann teilfreischalten, sei es aus marketing-Gründe oder Fehler. Das ist praktisch nicht der Fall! Bei ASICs passiert das sicher schon einmal, aber die FPGA-Strukturen sind doch weitgehend bekannt - da gibt es kaum Fehler und wenn- sind sie bei jedem FPGA anders. Allenfalls geht da mal ein Block-RAM nicht weil falsch verdrahtet oder das Timing zu schlecht. Dann fliegt das aus dem Router raus und der Chip hat ein BRAM weniger. Es macht in keinem Fall Sinn, Chipfläche einzubauen und dann absichtlich nicht freizuschalten, nur um den FPGA billiger verkaufen zu können. Schau dir die FPGAs mal genauer an wie die skaliert sind. Da gibt es keinen Bruch in der Resourcen-Progression. Beispiel ARTIX 15,25,50,100,200 das sind gewollte Größen.
gandalf schrieb: > Dazu gehören Berufsschullehrer nicht. Bin ich nicht, habe ich nie behauptet. gandalf schrieb: > Du bist aber nicht das Maß der Dinge, sondern es sind die Leute, die den > Fachbereich prägen und definieren. Ja, trotzdem kann man Definitionen hinterfragen. Die Bezeichnung ASIC ist schon steinalt, da hat sich viel verändert. gandalf schrieb: > sondern es ist die > Einteilung in spezifische Lösungen, die von einem FPGA abgebildet werden > können, aber in einem gezielten Chip realisiert werden können. Was ist denn dann ein ASIC? Das ist so eine butterweiche Definition, dass da (fast) Alles drunter fallen kann. Alles was in einem FPGA abgebildet werden kann kann in einem dedizierten Chip realisiert werden. Auch CPUs. Sind die dann auch ASICs? Wie sieht es mit GPUs aus? RAM? Was ist denn das genaue Kriterium ob ein Chip ein ASIC ist oder nicht? Macht das die Stückzahl? Ob konfigurierbare Logik enthalten ist oder nicht? Ob eine CPU enthalten ist oder nicht? Es gibt da auch viele Zwitter, FPGAs mit Hardware CPU. Ist der Chip dann ein ASIC wegen der CPU oder kein ASIC weil ein FPGA Teil enthalten ist? Das sind Graustufen und aus meiner Sicht nicht sinnvoll. Jeder Chip wird für ein Anwendungsfeld gefertigt, auch wenn die Anwendung dann ist, dass der rekonfigurierbar ist oder eine CPU enthält. Weltbester FPGA-Pongo schrieb im Beitrag #6718905: > Du verbeisst dich in die Theorie, dass man Firmen im großem Stile > Hardware verbauen und dann teilfreischalten, sei es aus marketing-Gründe > oder Fehler. Das ist praktisch nicht der Fall! Ähm doch?! Der M1 von Apple hat mal 7 mal 8 GPU Kerne. Das ist eben Selektion. Man designt ein Modell und weil die Ausbeute nicht irre gut ist kann man die mit Defekten auch noch verkaufen, als kleineres Modell. Weltbester FPGA-Pongo schrieb im Beitrag #6718905: > Es macht in keinem Fall Sinn, Chipfläche einzubauen und dann absichtlich > nicht freizuschalten, nur um den FPGA billiger verkaufen zu können. Das meine ich auch nicht. Ich meine, dass man größere Modelle mit Defekten noch als kleineres Modell verkauft. Das ist besser als wegschmeißen. So ein dicker XC7A200T hat 10 Clock Regions, die sehen sich recht ähnlich, nicht alle, aber manche. Wenn da eine einen Defekt hat, dann könnte man die nicht anschließen und das als z. B. XC7A100T verkaufen. Ich behaupte nicht, dass das so gemacht wir, aber als Hersteller hat man eigentlich das Ziel alles was gefertigt wird auch irgendwie zu verkaufen. Wenn auch für weniger Geld aber eben für Geld. Mich würde das also wundern wenn sowas nicht gemacht wird.
:
Bearbeitet durch User
Weltbester FPGA-Pongo schrieb im Beitrag #6718905: > Du verbeisst dich in die Theorie, dass man Firmen im großem Stile > Hardware verbauen und dann teilfreischalten, sei es aus marketing-Gründe > oder Fehler. Das ist praktisch nicht der Fall! Natürlich wird das gemacht. Das lässt sich sehr gut mit FPGAs beweisen, für die es eine freie Toolchain gibt. Da hat dann der halb so grosse FPGA plötzlich gleich viele LUTs und gleich viel RAM, wie der nächst grössere. Es ist manchmal nur die Hersteller eigene Toolchain, die sich weigert die eigentlich vorhandenen Resourcen auch zu nutzen. Dass da wirklich Fehler in den nicht benutzten Teilen vorhanden sind, kann ich mir nicht vorstellen, da müsste man umfangreiche Tabellen im Chip mitspeichern und der IDE übermitteln. Ich denke es sind tatsächlich nur Marketing Überlegungen, denn die Masken zur Herstellung solcher Chips mit kleinen Strukturgrössen kosten mehrere Millionen. ---- FPGA, CPLD, ASIC sind alles nur Bezeichnungen, die man nicht wörtlich nehmen darf. Es sind doch eigentlich alles Complexe Logic Devices, ob Prozessor oder FPGA oder ASIC. Und natürlich kann man FPGAs nicht nur im Feld programmieren. Und ja, ein FPGA ist auch irgendwie ein ASIC, der halt vom FPGA Hersteller für die Anwendung als FPGA entwickelt wurde. Ein ASIC ist es halt dann, wenn du ihn für deine Anwendung extra entwickelst und herstellen lässt. Dazu braucht es spezielle Tools und viel Geld.
Weltbester FPGA-Pongo schrieb im Beitrag #6716281: > Ich denke, > dass die meisten Kosten einfach die Produktion des Chips selber sind. Dazu habe ich vor kurzem ein interessantes Video angesehen: https://www.youtube.com/watch?v=tvVobTtgss0 Ist erstaunlicherweise gar nicht soo teuer, wie man manchmal denkt. Andi schrieb: > FPGA, CPLD, ASIC sind alles nur Bezeichnungen, die man nicht wörtlich > nehmen darf. Es sind doch eigentlich alles Complexe Logic Devices, <trollmode = on> Nein, das sind alles VLSI! Und noch eine Abkürzung weil es noch nicht vorgekommen ist: ASSP <trollmode = off>
Zum Thema Produktionskosten bei Xilinx: https://www.xilinx.com/publications/archives/xcell/Xcell84.pdf Seite 4. Leider relativ sporadisch, aber zumindest bekommt man mal ein Haendchen fuer die Groessenordnungen.
Gustl B. schrieb: > Was ist denn das genaue Kriterium ob ein Chip ein ASIC ist oder nicht? Ganz einfach: Wenn ein Chip für mehr als die gedachte Anwendung konstruiert und benutzbar ist, dann ist es kein ASIC. Also fallen alle FPGA und alle programmierbaren Controller und alle Standard-Logik nicht darunter. W.S.
Macht doch einen eigenen Thread auf! Eure Diskussion ist doch völlig am Thema vorbei.
Tobias B. schrieb: > Zum Thema Produktionskosten bei Xilinx: > https://www.xilinx.com/publications/archives/xcell/Xcell84.pdf > Seite 4. Dort wird über 14/16 nm gejammert, das es doppelt so teuer sei, wie 20 nm. Inzwischen wird 7 nm ausgeliefert: https://www.elektroniknet.de/halbleiter/programierbare-logik/7-nm-versal-ai-core-und-versal-prime-in-serie.186261.html Der Apple M1 wird in 5 nm gefertigt. Zumindest Xilinx setzt auf die neueste Technologie und scheint damit auch Geld zu verdienen. W.S. schrieb: > Wenn ein Chip für mehr als die gedachte Anwendung > konstruiert und benutzbar ist, dann ist es kein ASIC. Einen NE555 kann man auch für viele verschiedene Anwendungen verwenden. Der ist nach Deiner Definition also kein ASIC... Duke
Duke Scarring schrieb: > Einen NE555 kann man auch für viele verschiedene Anwendungen verwenden. > Der ist nach Deiner Definition also kein ASIC... Hat er auch nie behauptet oder? Ein NE555 ist ein ASSP und kein ASIC. Steckt doch schon in den Begriff Application Specific Integrated Circuit. Ist der NE555 "Specific"? Nein, also ist es kein ASIC.
Ich habe mich gerade selber getrollt -_- Natürlich steht das erste S in ASSP auch für Specific. Kern bleibt aber gleich: ASIC steht für eigene Chips, die man sich selber entwickelt und die eine speziellere Aufgabe übernehmen. Der Begriff wird Weltweit von Entwicklern (mit Ausnahme von Gustl und Duke) dafür verwendet. Da ihr aber anscheinend so top Entwickler seid, die erkannt haben, dass die ganze Welt etwas falsch macht schlage ich doch einfach mal vor, dass ihr hier bitte neue Begrifflichkeiten einführt.
gandalf schrieb: > Kern bleibt aber gleich: ASIC steht für eigene Chips, die man sich > selber entwickelt und die eine speziellere Aufgabe übernehmen. Du hast ja tatsächlich zu einem Teil Recht. Und zwar mit dem "selber". Ich würde nämlich sagen, dass die Definition von ASIC oder nicht gar nicht Chip Typen oder so unterscheidet, sondern eher wer den baut. Wenn eine Firma den für sich selbst entwirft, fertigen lässt oder selber baut und dann selber verwendet würde ich sagen das ist ein ASIC weil zugeschnitten auf genau das was die Firma braucht. Sowas wie der FSD Chipo im Tesla, da ist ein neuronales Netz drinnen, da sind GPUs und CPUs drinnen, trotzdem würde ich sagen ASIC weil den ausserhalb von Tesla keiner verwendet und Tesla ihn für eigene Zwecke entworfen hat. Nicht ASIC würde ich zu den Chips sagen die man verkauft. Also eine Intel CPU. Klar auch die hat ihr Anwendungsfeld und wurde so entworfen, dass ie das möglichst optimal abdeckt, aber welche Anwendung genau damit gemacht wird ist unklar bei der Herstellung, das entscheidet der Kunde. Vielleicht sollte man sogar sagen dass Chips die für eine Aufgabe designt werden ASICs sind und solche bei denen nur ein grobes Aufgabenfeld klar ist aber viele Kunden die unterschiedlich verwenden können keine ASICs sind. Sorry wegen OT, das ASIC/nicht ASIC hatte ich oben eher am Rande erwähnt und dachte nicht, dass darüber diskutiert wird. Ich finde die Definition eher schwammig aber ja, der Begriff ist weit verbreitet. So wie auch KI. Was ist das? Ist auch schwammig, weit verbreitet, mal werden genetische Algorithmen, mal neuronale Netze, mal sogar nur Machine Learning mit von Menschen geschriebenen Algorithmen drunter verstanden.
Gustl B. schrieb: >> Ein FTDI UART<->USB Wandler ist ein ASIC > Welche Anwendung wird denn da realisiert? "Implementation eines asynchronen seriellen Protokolls über USB." Dass die konkrete Implementationen ein paar Freiheiten besitzt, mit denen man etwas mehr als nur "115k2 8n1" machen kann, hat damit nichts zu tun. Der Punkt ist, dass der Baustein fixed-function und damit auf eine Anwendung zugeschnitten ist. Dass er mit der gleichen Funktionalität auch für andere Anwendungen einsetzbar ist, hat damit erstmal nichts zu tun. Eine CPU oder ein SoC sind auch fixed-function, aber ein FPGA ist es nicht. > SoC oder FPGA kann man auch als Anwendung sehen. Wenn du einen Chip nur zum Selbstzweck fertigst, dann mag das so sein. In die Kategorie fällt z.B. der bo8. Übliche ASIC-Designs werden aber nicht zum Selbstzweck gefertigt. > Für mich ist ein FPGA ein ASIC und ein FTDI Stein ebenfalls Was du glaubst, ist für den Rest der Welt unerheblich. Gustl B. schrieb: > Ja, trotzdem kann man Definitionen hinterfragen. Die Bezeichnung ASIC > ist schon steinalt, da hat sich viel verändert. Die Definition von "Tisch" ist auch schon steinalt und muss nicht ständig hinterfragt werden. > Was ist denn dann ein ASIC? Ein anwendungsspezifischer Schaltkreis. Mit anderen Worten, ein Schaltkreis, der für eine bestimmte Anwendung (oder vielleicht auch mehrere) entwickelt wurde. > Was ist denn das genaue Kriterium ob ein Chip ein ASIC ist oder nicht? Nun, das ist wie folgt... > So wie auch KI. > Was ist das? Ist auch schwammig, weit verbreitet, mal werden genetische > Algorithmen, mal neuronale Netze, mal sogar nur Machine Learning mit von > Menschen geschriebenen Algorithmen drunter verstanden. ...es gab mal eine knallharte Definition, was KI ist. Und dann kamen irgendwelche Marketingfuzzis sowie Leute mit halbgarem Verständnis der Materie, fanden den Begriff cool und haben den auf alles angewendet, was auch nur irgendwie danach riechen könnte, wenn man Schnupfen hat. Im Endergebnis ist "KI" inzwischen alles und nichts, weil der Begriff komplett verwässert wurde. Genau das machst du hier auch: Du versuchst, mit Gewalt zu beweisen, dass die Definition von ASIC nicht exakt eindeutig ist bzw. dass die theoretische Definition auf die meisten realen ASICs nicht perfekt zutrifft. Schön, mach den Begriff komplett kaputt, schreib ein Paper drüber und freu dich. Wollen wir noch schnell diskutieren, ob ein AVR ein 8-Bit oder ein 16-Bit-Prozessor ist? Schließlich ist dessen Flash 16-bittig adressiert, der Program Counter ist 16 Bit breit und es gibt Befehle, die mit 16 Bit breiten Daten umgehen können. Also ist es ein 16 Bit-Prozessor, oder? Oder?
:
Bearbeitet durch User
Duke Scarring schrieb: > Einen NE555 kann man auch für viele verschiedene Anwendungen verwenden. > Der ist nach Deiner Definition also kein ASIC... Richtig. Auch ein 7400 ist kein ASIC. W.S.
S. R. schrieb: >> Was ist denn dann ein ASIC? > > Ein anwendungsspezifischer Schaltkreis. Mit anderen Worten, ein > Schaltkreis, der für eine bestimmte Anwendung (oder vielleicht auch > mehrere) entwickelt wurde. Und wenn die Anwendung 4xNAND heißt? Geht dann ein 7400 als ASIC durch? Wann und wo und durch wen wird denn bestimmt, was anwendungsspezifisch ist? Und was ist, wenn ich eine Chip habe, der Wäsche waschen kann und plötzlich entdeckt jemand: Hey damit kann man auch Kaffee kochen und Nudeln al dente machen! Dann ist es plötzlich kein ASIC mehr?!? Duke
Beitrag #6721951 wurde vom Autor gelöscht.
Duke Scarring schrieb: > Und wenn die Anwendung 4xNAND heißt? Dann kauft man den fertig ein, ist guenstiger als selbst zu produzieren, bzw. als Auftragsfertigung produzieren zu lassen. ;-)
Duke Scarring schrieb: > Und wenn die Anwendung 4xNAND heißt? Werde jetzt mal nicht albern. Niemand kauft im Supermarkt eine Tüte 4xNAND. Die Leute wollen z.B. einen Fotoapparat (wo früher zu Zeiten von Kleinbild ein ASIC für die Belichtung drinsteckte) oder (früher) einen tragbaren CD-Player (wo für die Spurführung des Lesekopfes ein ASIC drinsteckte) oder andere Konsumgüter dieser Provenienz. Und dein Nachbar kennt vermutlich keine Anwendung, die 4xNAND heißt. W.S.
S. R. schrieb: > Eine CPU oder ein SoC sind auch fixed-function, aber ein FPGA Wieso ist eine CPU "fixed function"? Die ist programmierbar. Das ist doch der Punkt, dass der FPGA aus der statischen Ecke kommt und sich auf die CPU zubewegt, indem die Funktion austauschbar wird. "fixed" ist hier alleine die Hardware. Die ist aber auch im FPGA "fixed". Eine Schaltung ergibt sich nur durch das Programmieren. Und warum ist nun auch ein SoC ein fixed system? Das ist das Weicheste, was man momentan kaufen kann, weil nicht einmal die Verteilung der Funktionen (= Applikation) vorgegeben ist sondern vom Anwender entschieden wird, ob er es in der PS oder PL macht. >Ideen für FPGA-Projekte Ich hätte eine Idee: Man baut einen link-Core in Verilog, den man in jedes FPGA eincompilieren kann. Sobald der Anwender unsicher ist, ob er einen FPGA, ein PLD, ein Soc oder einen ASIC vor sich hat, erkennt der Core das automatisch und öffnet einen browser mit einer Erklärseite mit links in die Wikipedia oder FPGA-related.
Duke Scarring schrieb: > Und wenn die Anwendung 4xNAND heißt? Geht dann ein 7400 als ASIC durch? > Wann und wo und durch wen wird denn bestimmt, was anwendungsspezifisch > ist? "Anwendungsspezifich" bedeutet einfach, dass es eine beschränkte Intention gab, die zur Entwicklung geführt hat. Dass ein Chip noch für andere Dinge einsetzbar ist, mag sein, widerspricht dem aber nicht. Vigra wurde anwendungsspezifisch entwickelt und war zunächst ein Herzmedikament, das später zweckentfremdet wurde. Ich mache mal dasselbe und zweckentfremde einen Herzschrittmacher, dessen Elektroden ich mir in den S.....z stecke, damit sich da mehr tut. Vielleicht klappt es. Gfs muss noch mit einem FPGA eine taugliche Pulsfolge erzeugt werden. W.S. schrieb: > Niemand kauft im Supermarkt eine Tüte 4xNAND. Du wirst Lachen: Ich war mal vor Unzeiten beruflich in Tokyo: Dort gibt es Wochenmärkte für Elektronik! Unter anderem sitzen dort auch Händler, die noch Chips aus alten Produktionen haben und in kleinen Tüten abgepackt verkaufen. Meistens irgendwelche Japanischen Spezial-Chips aus der Unterhaltungselektronik. Es gibt aber auch die ganz normalen Logikbausteine. Und es gibt alte CPUs aus den 1980er, die du hier nicht mehr bekommst. Das Geschäft ist aber tricky geworden, seit sich Chinesen eingemischt haben und faule Kopien einschleusten.
Weltbester FPGA-Pongo schrieb im Beitrag #6722364: > W.S. schrieb: >> Niemand kauft im Supermarkt eine Tüte 4xNAND. > Du wirst Lachen: > > Ich war mal vor Unzeiten beruflich in Tokyo: Dort gibt es Wochenmärkte > für Elektronik! Hoho haha! Mag sein. Ist aber deutlich erkennbar, daß das Angebot nur an sehr spezielles Publikum gerichtet ist - und nicht an die Nicht-Elektroniker, die mMn die Anzahl der Elektroniker bei weitem übertrifft und in deren Supermärkten man eher Gemüse und Haushaltsdinge bekommt. Dein Einwurf ist dennoch lustig. W.S.
Duke Scarring schrieb: > Geht dann ein 7400 als ASIC durch? Ist ein 7400 für eine bestimmte Anwendung entwickelt worden oder ist der eher als Universalbaustein gedacht? > Und was ist, wenn ich eine Chip habe, der Wäsche waschen kann und > plötzlich entdeckt jemand: Hey damit kann man auch Kaffee kochen und > Nudeln al dente machen! Ist dein Wäschewaschchip für eine bestimmte Anwendung entwickelt worden oder ist der eher als Universalbaustein gedacht? Weltbester FPGA-Pongo schrieb im Beitrag #6722346: >> Eine CPU oder ein SoC sind auch fixed-function, aber ein FPGA > Wieso ist eine CPU "fixed function"? Die ist programmierbar. Die Flexibilität einer CPU kommt durch das Programm, nicht durch ihre (Hardware-)Struktur.
S. R. schrieb: > Ist ein 7400 für eine bestimmte Anwendung entwickelt worden oder ist der > eher als Universalbaustein gedacht? Das ist eine gute Frage. Ich war damals bei der Entwicklungsentscheidung nicht dabei.
S. R. schrieb: > Die Flexibilität einer CPU kommt durch das Programm, nicht durch ihre > (Hardware-)Struktur. Das würde ich dann aber eher "fixed structure" nennen. Dann wäre eine CPU auf dem Level eines ASIC. Parametriert werden die ja alle irgendwie. Allerdings wäre der FPGA auch fixed structure. Nur die Schaltung die reinkommt nicht. Ein Zwischending also? W.S. schrieb: > Ich hätte da noch einen Vorschlag: Bau aus einem FPGA oder CPLD und > einem beliebigen µC einen ordentlichen digitalen Universalzähler. So ein > Ding, was sowohl Frequenzen bis - na, sagen wir mal - 10 GHz und Zeiten > bis 10 Sekunden mit 100 ps Auflösung und gleicher Absolutgenauigkeit > messen kann und nicht bloß eine auf dem Basteltisch herumfliegende LP > nebst Draht-Igel ist, sondern ein fertiges durchkonstruiertes Gerät. Alles, was über die Systemtaktfrequenz des FPGA hinausgeht, ist nicht mehr ohne spezielle Methoden und Anpassung an das PCB-design zu machen. Das ist dann ein komplettes high speed Elektronik-Projekt. Das braucht dann schon etwas mehr Erfahrung, als es der Bastler mitbringt. Interessant wäre das aber ganz sicher. Es müsste halt ein PCB her, in ausreichenden Stückzahlen mit analogem Frontend, das an genug Abnehmer verteilt werden könnte.
Duke Scarring schrieb: > S. R. schrieb: >> Ist ein 7400 für eine bestimmte Anwendung entwickelt worden oder ist der >> eher als Universalbaustein gedacht? > Das ist eine gute Frage. > Ich war damals bei der Entwicklungsentscheidung nicht dabei. Die Typennummer ist schon ein wichtiger Hinweis darauf, dass dieser Baustein zusammen mit allen anderen Bausteinen der 74er Serie für universelle Anwendung gedacht ist. Jürgen S. schrieb: > S. R. schrieb: >> Die Flexibilität einer CPU kommt durch das Programm, nicht durch ihre >> (Hardware-)Struktur. > > Das würde ich dann aber eher "fixed structure" nennen. Dann wäre eine > CPU auf dem Level eines ASIC. Das ist der Punkt den ich angesprochen hatte und nur Gandalf aufgegriffen hat: Zwischen ASIC (Chip im Hörgerät wo das Logo des Hörgeräteherstllers auf dem Chip ist) und Universalanwendung (74er, OPV, 555, AM29er, FPGA, bei den einfacheren auch mit second-source) liegt der grosse Bereich der ASSP (Application Specific Standard Products): Chips die für eine bestimmte Anwendung gemacht sind, aber an viele Gerätehersteller verkauft werden (OEM), also Chip(sets) um Smartphones, Blueray Player, USB-Seriell Wandler, Class-D Verstärker, DP nach HDMI Wandler, Ethernet Switch, GPS Empfänger etc. zu bauen. Hier gibt es auch viele Chipfirmen die sich auch auf gewisse Bereich spezialisiert haben, z. B. Rockchip, FTDI, Hypex, SiliconImage, Marvell, uBlox. Der Chip/CPU den Samsung für ihre NVMe SSDs baut ist ein ASIC Die Microcontroller von TI/Microchip etc. sind ASSP Lattice Crosslink sind ASSP (hier kann ich aber schon wählen ob soft-core oder nicht und welches Instruction Set) FPGAs im allgemeinen sind Universalchips, unterscheidet sich ja auch nicht so stark von den Möglichkeiten eines (grossen) Sack voll 74er Chips.
Duke Scarring schrieb: >> Ist ein 7400 für eine bestimmte Anwendung entwickelt worden >> oder ist der eher als Universalbaustein gedacht? > Das ist eine gute Frage. > Ich war damals bei der Entwicklungsentscheidung nicht dabei. Und was würdest du mit deinem aktuellen Wissensstand so vermuten? Jürgen S. schrieb: >> Die Flexibilität einer CPU kommt durch das Programm, >> nicht durch ihre (Hardware-)Struktur. > Das würde ich dann aber eher "fixed structure" nennen. > Dann wäre eine CPU auf dem Level eines ASIC. Ja, das kann man so sehen. Allerdings sehe ich an der Stelle trotzdem eine feste Funktion ("Ausführung von Programmcode"). > Allerdings wäre der FPGA auch fixed structure. > Nur die Schaltung die reinkommt nicht. Ein Zwischending also? Genau. Ein FPGA ist eben kein ASIC.
W.S. schrieb: > Leute, kommt mal wieder auf's Thema zurück: Da sucht der TO nach > Einsatzfällen für FPGA von mäßiger Kompliziertheit, weil er selbst > offenbar zu tief in der Furche steht, um über deren Rand zu blicken. > > Ich hätte da noch einen Vorschlag: Bau aus einem FPGA oder CPLD und > einem beliebigen µC einen ordentlichen digitalen Universalzähler. So ein > Ding, was sowohl Frequenzen bis - na, sagen wir mal - 10 GHz und Zeiten > bis 10 Sekunden mit 100 ps Auflösung und gleicher Absolutgenauigkeit > messen kann und nicht bloß eine auf dem Basteltisch herumfliegende LP > nebst Draht-Igel ist, sondern ein fertiges durchkonstruiertes Gerät. > > W.S. Mit einem TDC7200, einem µC, ein paar Flipflops und einem entsprechender Vorteiler schaffst du das ohne FPGA und viel billiger.
Hans-Georg L. schrieb: > Mit einem TDC7200, einem µC, ein paar Flipflops und einem entsprechender > Vorteiler schaffst du das ohne FPGA und viel billiger. Der Vorteiler macht es aber wieder ungenauer, weil er die Dynamik der Frequenzen glättet. Damit bekommt man nur Durchschnittswerte, was sich für Messungen eignet, bei denen es um die Erfassung einer konstanten Frequenz geht. Interessanter wäre aus meiner Sicht ein Frequenzanalysator, der die Verteilung messen kann.
S. R. schrieb: > Genau. Ein FPGA ist eben kein ASIC. Kann man sehen wie man will ;-) Beispiel Xilinx Zynq, das Entwickungs und Testsystem bestand aus einer Herde von FPGA. Daraus wurde ein ASIC das als FPGA verkauft wird. Die Grenzen sind da wirklich fliesend.
Harald E. schrieb: > Hans-Georg L. schrieb: >> Mit einem TDC7200, einem µC, ein paar Flipflops und einem entsprechender >> Vorteiler schaffst du das ohne FPGA und viel billiger. > > Der Vorteiler macht es aber wieder ungenauer, weil er die Dynamik der > Frequenzen glättet. Damit bekommt man nur Durchschnittswerte, was sich > für Messungen eignet, bei denen es um die Erfassung einer konstanten > Frequenz geht. > > Interessanter wäre aus meiner Sicht ein Frequenzanalysator, der die > Verteilung messen kann. Ich mag die Vorteiler auch nicht, die üblichen IC schwingen oft wenn kein Eingangssignal da ist. 100ps Auflösung braucht man bei 10 GHz auch eher nicht.
S. R. schrieb: > Duke Scarring schrieb: >>> Ist ein 7400 für eine bestimmte Anwendung entwickelt worden >>> oder ist der eher als Universalbaustein gedacht? >> Das ist eine gute Frage. >> Ich war damals bei der Entwicklungsentscheidung nicht dabei. > Und was würdest du mit deinem aktuellen Wissensstand so vermuten? Das die TTL-Logik der Nachfolger der DTL-Logik sind. Diese wiederum hatten als Vorgänger die "resistor transistor logic" (RTL). Und da schreibt Wiki:
1 | Die RTL war die erste Form digitaler elektronischer Schaltkreise, die in den 1950er Jahren von Texas Instruments speziell zum Einsatz in der Feldseismik entwickelt wurde. |
Die meisten Produkte dürften ursprünglich eine spezifische Applikation im Blick gehabt haben. Aber letztendlich geht es hier eher um des Kaisers Bart. Und von mir aus darf jeder die Dinger bezeichnen, wie er will. Duke
Duke Scarring schrieb: > Das die TTL-Logik der Nachfolger der DTL-Logik sind. Wer der Vorgänger oder der Nachfolger sein mag, ist hier herzlich uninteressant. Ebenso ist die Frage nach der besonderen Funktion des Bauteils hier nicht interessant. Wichtig ist lediglich, ob das Bauteil für eine spezielle Anwendung (sprich Gerät) gedacht ist oder ob es so allgemein gehalten ist, daß es seine Funktion in eine Vielzahl von Geräten einbringen kann. Und das kann der 7400, genau so wie es auch der NE555 kann. Das sind also keine ASIC's. Hans-Georg L. schrieb: > 100ps Auflösung braucht man bei 10 GHz auch > eher nicht. Ah ja... OK, über detaillierte Spezifizierungen kann man diskutieren. Aber wenn man 10 GHz messen will, dann braucht man die besagten 100ps oder sogar noch weniger. Zumindest wäre mMn ein universeller Zähler eine sinnvolle Anwendung für ein FPGA oder ein CPLD. Und ein mikrowellengeeigneter Vorteiler ist für alles, was (so ungefähr) übe die 500 MHz hinausgeht, obendrein notwendig. W.S.
Da mir grad auch keine Idee für FPGA-Projekte einfällt, nun auch meine 3Cents zum Thema Asics oder nicht: Aus Chipenwicklersicht ist mir das Wurscht! Weil: Management sagt: mach tollen Chip, ich mach VHDLcoding+Synthese usw. dann 'klatschen' wir die Blöcke in einem Siliziumviereckzusammen. Meiner Firma aber nicht: dort wird als ASIC deklariert wenn ein Kunde sagt das er einen Chip für genau diese Anwendung will - dann trägt der Kunde weitestgehend das Unternehmerische Risiko, nicht die Chipenwicklungsfirma! In derselben Firma sind aber auch Leute welche sagen das so und so een Chip sich doch wie geschnitten Brot verkaufen würde, dann wird lang und breit spezifiziert und der Chip evtl. schlussendlich entwickelt und danach wird versucht ihn zu verkaufen. Der Anlass zu dem Chip können auch Kundenwünsche sein, der Unterschied zum ASIC: die Chipentwicklungsfirma selbst trägt das Risiko, der Kunde kauft oder auch nicht! So und nun ein prominentes Beispiel für einen "ASIC" der dann ein frei verfügbares Bauelement wurde: der Intel 4004 https://de.wikipedia.org/wiki/Intel_4004 Zitat: "Der Intel 4004 wurde 1969 von der japanischen Firma Busicom zunächst für neuartige Rechenmaschinen bei Intel in Auftrag gegeben ..." (...) "Intel kaufte später die Rechte am Design des Intel 4004 für 60.000 US-Dollar von Busicom zurück"
Marius S. schrieb: > Oder Projekte bei welchen die Vorzüge eines FPGAs (Parallel-Verarbeitung > und Geschwindigkeit) genutzt und auch tatsächlich benötigt werden. Jetzt > zwanghaft ein Projekt mit FPGA zu realisieren ist nicht nötig, habe auch > Mikrocontroller hier rum fliegen... SoundCam images sound in realtime - SoundCam on Kickstarter https://www.youtube.com/watch?v=-VmPZeYx2II&t=241s LAUFZEITMESSUNG ::64 Sound-Tastpunkte: ::::: Analog FilterStufen.....
Markus W. schrieb: > Wieviele werden denn da verwendet? > Und warum? FLUKE hat das wohl gekauft, aber macht nur LeckagenAnalyse damit. Druckluft Lecksuche mit der SoundCam.........FLUKE SoundCam VibrationsAnalyse Zersörungsfreie Werkstückprüfung Produktprüfung in dynamic & Echtzeit...mit Aufzeichnung der Daten ......post DataAnalyse. 70 GByte. Bewegte Umgebungsluft .. Aerosolforschung.... Maschinenakustik ...... Motorenbau E oder KFZ. Industrie-Schallkamera Soundcam Akustikkamera mit FilterFunktion. https://www.youtube.com/watch?v=i8lFEoMJjb0 -------------- https://soundcam.com/ Did you know The Modal Shop rents Acoustic Cameras? The SoundCam is a live action acoustic camera used to locate sound sources via an array of MEMS-mircophones. Learn more and see the SoundCam in action here:
Noise-Vibration-Harshness: Durch das stetige Ansteigen der Komfortansprüche an heutige Fahrzeuge, gewinnen in der heutigen Entwicklung Themen an Bedeutung, die früher noch eher eine untergeordnete Rolle spielten. Ein typisches Beispiel dafür findet sich in dem akustischen Verhalten eines Antriebs wieder. Dieser Fachbereich wird auch als Noise-Vibration-Harshness (NVH) bezeichnet. Durch die immer leiser werdenden Motoren gilt es durch verschiedene Methoden das NVH-Verhalten zu analysieren und zu beurteilen. Auf Basis der Untersuchungen soll das Auftreten von störenden oder unangenehmen Geräuschen im Betrieb des Fahrzeuges frühzeitig erkannt und entsprechende Gegenmaßnahmen durchgeführt werden. https://www.hs-esslingen.de/fileadmin/media/Fakultaeten/mt/Labor_LM/Forschungsprojekt_LFM.pdf Ist also ein Signifikantes Messgerät ... Industrieanwendung, PrototypenBau. Endless Alications.... Gruss Holger.
Holger schrieb: > FLUKE hat das wohl gekauft, aber macht nur LeckagenAnalyse damit. Mess-Prinzip: Lecks untersuchen. Die in die......... Kamera integrierte Anordnung winziger empfindlicher Mikrofone erzeugt pro Frequenz ein Spektrum von Schallpegeln. Anhand dieser Signale berechnet ein Algorithmus eine Schallabbildung, die als SoundMap™ bezeichnet und einem Sichtbild überlagert wird. Diese SoundMap wird je nach der ausgewählten Frequenz automatisch angepasst, um Hintergrundrauschen auszufiltern. Diese Technologie stellt dies eine bessere Methode zum schnellen und einfachen Auffinden von Druckluft-, Gas-, Dampf- und Vakuumlecks dar.
Holger schrieb: > pro Frequenz ein Spektrum von Schallpegeln. das ist etwas seltsam formuliert. Heraus kommt das Spektrum selbst, also ein Satz von Schallpegeln und dies für (wahrscheinlich) eine zweidimensionale Anordnung. Damit muss der FPGA (wenn verbaut) für jedes Mikrofon eine FFT machen. Ein Akustikkamera, die wir schon benutzt haben, hatte ein Array von 256 solcher Mikrofone. Bei 48kHz Abtastfrequenz müsste das in einem FPGA mit 64 solcher FFTs für immerhin 1024 Frequenzen machbar sein.
Angehängte Dateien:
Weltbester FPGA-Pongo schrieb im Beitrag #6716281: > Ich denke, > dass die meisten Kosten einfach die Produktion des Chips selber sind. > Einen unserer Aufträge hochskaliert sind das rund 10-20 Mio Fixkosten > zum Produktionsanlauf, wenn alles steht. Jetzt ist die Frage, was die > Neuentwicklung eines FPGAs kostet. Die Chips werden sicher nicht von Grund auf gebaut, sondern man greift auf Vorhandenes zurück. Dies ist ein Beispiel für eine Chip-Kosten-Kalkulation aus meiner EX-Firma. Die Zahlen sind etwas abgeändert, kommen aber von der Größenordnung her hin und müssten auch für Altera oder Xilinx passen. Angefangen mit der ChipFläche und Umfang der realisierbaren Zahl der Funktionen kommt man zu der Zahl der Chips je Wafer. Abzüglich der fehlerhaften Chips und einem Rückstellmuster je Wafer erhält man die nutzbaren Chips. Über die Produktionskosten kommt man zu einem Produktionspreis je Stück. Hinzu kommen die Designkosten und Fixkosten, die bei größeren Chips höher sind, da umfangreicher. Über die Pyramide der angestrebten Verkaufszahlen erhält man mit den Produktionskosten den minimalen Abgabepreis in Fettdruck. Dann gibt es mit fact einen marktabhängigen Aufschlag, der von der Nachfrage und der Konkurrenz abhängt. Chips die unter Druck sind, werden billiger abgegeben. Danach wird eine minimale Abgabemenge an den Distri definiert, um auf wenigstens 5-stellige Beträge zu kommen und so dessen EK festgelegt Der enthält einen Aufpreis zum Verhandeln von einigen Tausend. Der Distri haut dann je Bestelleinheit seine 20% und einen Obulus drauf und errechnet den VK des Chips – gfs einen Staffelpreis dazwischen. Wenn man sich jetzt vorstellt, die Kunden würden mehr von den teuren FPGAs kaufen, dann würden sich die Preise auch runterteilen und man müsste einen Ultrascale Plus für 500 Ocken erstehen können.
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.