Einen DSP in VHDL zu programmieren hatte ich mir auch mal überlegt. Deine Implementierung klingt sehr speziell, kann der auch beliebige Programme abarbeiten? Du setzt für deine Anwendungen ja die fetten FPGAs ein, meinst du sowas würde auch für einen Cyclone oder Spartan funktionieren?
400 MHz Takt, wie es schon die einfachen DSPs können, würde man aber zumindest mit den kleineren FPGAs wohl schonmal nicht hinbekommen, daher müsste man sich wohl einen ausgefallenen und auf die Anwendung angepassten Befehlssatz ausdenken. Das kostet aber wieder LEs, wenn's schnell laufen soll. Ich hatte mal spaßeshalber einen FIR-Filter mit dem Megawizard ausprobiert und je nach Anzahl taps ist der Cyclone dann schnell voll :-(
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Ist auch mein Kenntnisstand. Betankung war schon, die Triebwerke haben auch schon gelaufen, so wie die aussehen.
Was die Vernietung angeht: Fragt mal die Leute, in wieweit im Vorraus derzeit bzw. damals Niete im Flugzeugbereich vorbestellt werden müssen. Das ist nicht $Alubaumarktpopkram. Alcoa hat sich sicherlich 'ne goldene Nase dadran verdient. Motto: Eh wir bei dem Bedarf 'n neue Fabrik hochziehen (die sicherlich auch ausgelastet wäre). Es ging IIRC so in den Bereich >6 Monate für ,,Standard''-Titanniete EN6114/EN6115.
Runter kommen sie alle, das wie ist da kein Problem. Das Problem ist, was passiert, wenn die Kohlefaserstruktur den Boden berührt (ohne Fahrwerk, mit etwas zu viel \Delta v_vertikal und \Delta v_horizontal... das ist das, was spannend ist und wo auch einige meinen, daß die Zulassung ein Problem sein/werden kann.
[x] Eine gekaufte nie.
Die Lastenabteilung sollte wissen, was sie macht, das Engineering, die Fertigung...
AA587 ist bei IIRC 1,93 LL geknackt. Das ist so ziemlich genau das, was damals auch die Musterzulassung hatte. Nur hatte AA587 da schon einige Jahre konditionierung und Flug hinter sich und einen nicht auf dem Stand der Dinge/Schulungsunterlagen trainierten Co/Piloten.
Stimmt. Ob NDT vom Frauenarzt die Delas erkennen kann ist fraglich...verdammt dicht unter der Oberfläche...
Es wird seit längerem davon geredet, die A310-Baureihe bis 2050 fliegen zu lassen. Da haben dann die letzten Flieger 50 Jahre auf dem Buckel, davon wohl locker 25 Jahre in der Luft. Auf die Betriebsdauer/Lastzyklen werden noch Windenergieanlagen kommen, der Rest?
Im Seitenleitwerksbereich wird CFK an Zivilflugzeugen bei Airbus seit Mitte der achtziger Jahre eingesetzt.
Das ist das Problem, die hatten wohl angenommen dass die Beschaffung einfacher sei. Hier letztens: Mutter so in etwa Eurer Groesse M8 entsprechend, fuer Fluggeraet zugelassen. $20. Pro Stueck!
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Hat bisher alles nichts zu sagen. Das kriegt man notfalls auch mit einem Modell aus Holz und Alu hin.
Jup, deshalb musste Boeing fuer den Rollout diese Billignieten verwenden und nachher wieder rausbohren. Ob das der Rumpf ueberlebt hat ist noch die Frage.
Schon... Die Teile sollten beim Aufsetzen noch alle miteinander verbunden sein und auch bleiben. Kaeme nicht so gut wenn bei den Flugtests z.B. ein Triebwerk einen eigenen Weg geht...
Gehoert zur Zulassung auch eine Bruchlandung? Wenn ja wuerde ich davon gerne ein Video sehen... :)
So ein DSP kann auch schon mal gerne ein paar Watt verbrauchen, zumindest wenn es in dem Bereich geht, den Oliver brauchen würde, also z.B. der MSC8156 (6-Core DSP, 1 GHz, wobei ich da aber leider kein detailiertes Datenblatt mit Stromverbrauch zu gefunden habe, die Freescale-Seite ist auch nicht gerade intutiv zu bedienen).
Bei Geräten für die Steckdose ist das aber nebensächlich, solange man die Abwärme aus dem Gerät herausbekommt. Da kann man dann auch einen FPGA nehmen, falls DSPs dazu nicht geeignet wären, z.B. weil man schnelle Spezialfunktionen braucht, und davon viel parallel, die man wohlmöglich nur mit vielen oder sehr schnellen DSP realisieren könnte. Ggf. braucht das Gesamtsystem mit FPGAs dann sogar weniger Strom als konventionell aufgebaut.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Kommt drauf an wofuer. Bei den DTV-Konvertern hier in USA wurden den Herstellern sehr strenge Auflagen gemacht, was die Dinger verbrauchen duerfen. IIRC waren das 8 Watt ab Steckdose, wenn sie das Energy Star Label bekommen sollten (m.W. mussten sie das um fuer das Rabattprogramm zugelassen zu werden). Unsere bleiben kaelter als das DSL Modem, obwohl sie ganz anderes Kaliber rechnen muessen um 1080 Zeilen-Bilder auf NTSC umzuwandeln.
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Bei Geräten mit so großen Stückzahlen setzt man wahrscheinlich auch keinen FPGA ein, denn schon ein entsprechend leistungsfähiger FPGA alleine würde wohl mehr kosten, als das ganze Gerät später kosten darf. Für solche Standardanwendungen gibt es aber bestimmt auch ein paar Standardchips, wo das stromsparend implementiert ist.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Im Prinzip ja. Es ist sogar eine Sonderbehandlung für schnelle Branches eingerichtet.
Mit einem Spartan 3A DSP würde er funktionieren, die hiesigen Vertreter von Xilinx liegen mir auch ziemlich in den Ohren, dass ich den verwenden möge. Die von Lattice allerdings auch ;-)
Wir nutzen momentan einen ECP2M-70 für unser CIFDM Basisband-Board, weil der auch SERDES Links hat, über die sowohl das optische GigE als auch optionale High Speed ADC geführt sind.
Preislich liegen die ECP2M etwas höher als die Spartan, aber nicht so viel.
Heißt: Es ist absolut vorstellbar, dass das Ding irgendwann mal ein Standardteil so wie ein WLAN Chip wird und Ihr dann mit so einem Stick ins Internet kommt ;-) Technisch passt es da locker rein.
Momentan befinden sich in dem FPGA zwei CIFDM Engines (vollduplex) mit je (!) zwei Polyphasenfilterbänken (FIR) gemäß meiner neuartigen Architektur einschließlich je zwei Hardware FFT je Engine und eben einem Vektorprozessor für so Dinge wie Synchronisation, Equalization und Encoding/Decoding. Außerdem sind da noch Gemeinschaftsfunktionen (GigE, Unterstützung FEC, ADC Downsampling usw.) untergebracht.
Damit Du einen Eindruck hast: Wir unterhalten uns um rund 12000 Zeilen VHDL, allerdings mit doch einigen Kommentaren im Programmcode. Das passt alles in ein FPGA der Kategorie ECP2M.
Die Engines haben einen vollen Befehlssatz, allerdings keinen beliebig großen Speicher, dafür können sie sehr effizient mit komplexen Zahlen rechnen und eben mit Feldern aus diesen. Es geht z.B. darum, dass pro Engine eine CORDIC- Pipeline vorhanden ist, die eben ein I/Q Paar pro Zyklus umsetzen kann. Ein klassischer DSP kann das auch, aber eben nicht als
Einen richtigen Dual Core DSP haben wir auch auf dem Board, und genau da zeigen sich die Unterschiede:
Grundsätzlich kann sowohl so ein FPGA als auch ein DSP alles, es grüßt die Touring Maschine.
Aber: Das FPGA ist bezüglich des Befehlssatzes unheimlich flexibel, dafür ist der DSP mit klassischen Befehlen und mit dem Cache unheimlich schnell.
Der Grund sind primär die Routing Delays auf dem FPGA, nicht die Logik, das Routing kostet rund 70 bis 80% der Zykluszeit. Genau das entfällt beim festverdrahteten DSP, der Cache ist optimal angepasst usw. Und man kann halt nicht alles beliebig per Pipeline regeln, irgendwann wird auch vorne ein Ergebnis von hinten benötigt oder es kommt ein bedingter Sprungbefehl.
Bei letzterem tun sich übrigens selbst große Prozessoren unheimlich schwer, wenn er nicht vorhersagbar ist (eben weil da echt was entschieden wird, CORDIC ist ein ganz klassischer Fall für derlei CPU-Unbill, die Sprünge sind nur vom Ergebnis abhängig), da haut es jedesmal die ganze Pipeline weg.
Ohnehin ist so ein CPU-Design im FPGA unheimlich lehrreich, da merkt man schnell, wo die Tücken bei einer klassischen CPU
Unsere Engine läuft mit 125 bis 150 MHz je nach FPGA Typ ( und Preis ;-/
Das reicht völlig, selbst für breite Funkkanäle.
Sowas sollte man auch sauber codieren, wenn man weiß, was man macht, kann man unheimlich viel aus den FPGA rausholen.
Unser CODEC ist jedenfalls ein Baustein, den man sich so vor
5 Jahren nicht hätte vorstellen können. Ich nehme mal an, dass das auch einer der Gründe ist, warum in Richtung unseres neuen Modulationsverfahrens kaum geforscht wurde, außerdem war damals noch nicht klar, wie man derlei Signal mit krummen Abständen wirtschaftlich synthetisieren kann.
Aber er ist keine Vaporware, das Ding spielt und wir testen zur Zeit real im UHF Funkfeld (wir haben eine Versuchsfunklizenz) ebenso wie auf langen Kabeln, wie dicht man z.B. die beiden Kämme aneinander ranführen kann, sprich wieviel Daten da reinpassen, auch wenn der Funk mal nicht so gut ist. Bisher sieht es sehr gut aus, mit dem richtigen (!) Sendesignal trennen sich die beiden Kämme tatsächlich so, wie wir uns das theoretisch gedacht haben, d.h. das kommt fast an ein orthogonales Schema ran, nur eben mit endlich gescheiten Filtern statt mit dem sin(x)/x Krempel.
Und wir haben momentan sogar noch einigen Platz im FPGA, allerdings relativiert sich das etwas durch die steigenden Routing Delays, sprich: Will man das FPGA ausquetschen, dann wird es lahm,
@Jörg: Du siehst, das ist echt nicht sooo schwer, einen DSP zu bauen, es ist wirklich eine Frage der NRE (Maskenkosten) und des Absatzmarktes. Im Grunde braucht man eine ganze DSP Familie und eine Grundauslastung der Fab, dafür war z.B. in der Vergangenheit Automotive sehr gut (daher z.B. die Grundausrichtung Infineon dorthin). Es gibt im internationalen Bereich (ich rede nicht vom US Chaos) auch nicht sooo viele relevante Patente, Du weißt vielleicht, dass ich sogar selber in dem Segment noch eines geholt habe.
Sprich: Man braucht Abnehmer, man braucht Kapital, man braucht wenige extrem gute Entwickler, die das gewisse Extra erfinden, damit der werte Durchschnittsingenieur das Risiko eingeht, auf diesen Typ zu schwenken.
Genau wegen dem Kapital sind z.B. die Scheichs bei AMD (jetzt Globalfoundries) eingestiegen, inzwischen kann in Dresden übrigens jeder fertigen lassen, der die NRE und ein Design mitbringt.
Das erinnert mich alles an einen Scan Converter und Puls Prozessor, als die ansonsten dafuer ueblichen TRW Chips fuer azimuthal-kartesisch und fuer CORDIC drohten vom Markt zu gehen (was sie denn spaeter auch taten). Allerdings musste dafuer das Netzteil aufgestockt werden.
Diese Ausrichtung koennte jetzt zu akutem Handlungsbedarf fuehren ;-)
Wobei Maskenkosten ziemlich angezogen sind. Fuer die Maerkte in denen ich so entwickle rechnet sich das nur selten (haben wir aber schon gemacht). iPhone oder TomTom sind natuerlich was ganz anderes, weil jeder sowas haben muss. Oder glaubt haben zu muessen. Oder der Nachbar hat eins und da muss man natuerlich unbedingt ...
Das ist doch schonmal was, dann duerfte der Standort zumindest mittelfristig gesichert sein.
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Ich habe sowieso den Eindruck, daß die sich im Funktionsumfang immer mehr angleichen, zumindest was die Grundfunktionalitäten betreffen. Z.B. die
18x18 Multiplier und PLLs findet man heutzutage eigentlich überall. Unterschiede gibt es dann nur noch in den IO-Ports, Anzahl BRAMs und Anzahl LEs.
Jörg würde bei dem Preis wohl ein Herzinfarkt bekommen :-)
Kann man das so einfach umsetzen? Von Altera und Xilinx weiß ich, daß die ein Hardcopy-Prozess anbieten, wo man seinen FPGA in ein Chip giessen lassen kann.
Nicht schlecht. Habe gerade mal ein wc über die VHDL-Dateien von meinem aktuellen Projekt laufen lassen und liegt auch in dieser Größenordnung, wobei aber auch viele Testbenches mit Testvektoren enthalten sind. DSP- oder CPU-Entwicklung habe ich bisher aber noch nicht gemacht (von Spielprojekten, wie
formatting link
, was zum Ziel hatte, eine möglichst kleine CPU zu generieren, mal abgesehen).
Braucht man bei modernen FPGAs noch CORDIC? So wie ich es mal angewendet habe (24 Bit sin/cos-Generierung in 27 Schritten:
formatting link
), war der Vorteil, daß man keine Multiplikation braucht, sodaß man sowas vielleicht sogar in einen CPLD bekommen würde. Mit Hardware Multiplieren müsste es aber doch bessere Algorithm geben, oder? Zumindest für sin/cos trifft das zu.
Ja, ist vielleicht doch nicht schlecht, einen FPGA und eine DSP zu kombinieren, die dann jeweils für die für sie besten Aufgaben eingesetzt werden.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Das ist hier nicht so schlimm, alles POE, ein paar Watt.
[ Infineon Automotive ]
Infineon ist die Spezial-Halbleiterschmiede der deutschen Automobilindustrie, der Kapitalbedarf liegt dem Vernehmen nach bei einigen hundert Millionen Euro.
Zur Not dürfen halt die Fahrzeughersteller etwas zusammenlegen, klar, dass sie es erstmal beim Staat probieren. Ich bin schon für eine brancheninterne Lösung, die Automobilfirmen in Europa können den Betrag locker heben.
Pleitegehen wird deshalb weder Infineon noch die Fahrzeughersteller.
Nicht unbedingt.
Teuer sind die Phasenmasken für z.B. 65nm oder 90nm Prozesse, hingegen ist 300nm durchaus bezahlbar und analog für vieles sehr gut geeignet.
Das ist genau der Punkt, an dem bei reiner Digitaltechnik FPGAs interessant sind: Selber würde man vielleicht 300nm zahlen wollen, das FPGA ist aber z.B. in 90nm aufgebaut. Macht z.B. die achtfache Transistorzahl (das geht nicht ganz quadratisch wegen den oberen Metalllagen), selbst wenn davon die Häfte für die FPGA Routinglogik verbraten werden, kann das FPGA immer noch die vierfache Anzahl an Logikelementen bieten.
Technisch sind die FPGA ebenfalls kein Hexenwerk, es hat Logikelemente und es hat Boxen mit Transfer Gates und gut ist.
Deshalb ist die Konkurrenz auch groß, es gibt einige gute Anbieter, gefertigt wird international, z.B. Lattice bei Fujitsu in Japan, was sicher qualitativ eine sehr gute Wahl ist.
Das Know How steckt in der Software, primär aber vorallem der Aufwand, denn im Grunde wirft so ein VHDL Compiler "einfach" das Ergebnis der Datenflußanalyse aus, die auch bei klassischen Compilern zum Einsatz kommt. Am Ende hat es da wirklich eine Netzliste, die platziert wird (ein gutes Placement macht unheimlich viel aus), sprich geeignet auf die vorhandenen Logikelemente verteilt, und das Routing ist eine Art Channel Router, da ja nur kurze Pfade zu finden und keinerlei Geometrie zu berücksichtigen ist. Trotzdem sind die heutigen FPGA Tools schon recht leistungsfähig, da steckt viel Arbeit drin.
Man könnte die Netzliste jetzt auch in ein Standardzellen- Placement oder einen Logikzellen-Generator stecken und dann ein echtes ASIC draus machen, nur: Ob das selbst bei mittleren Stückzahlen billiger wird, das wage ich aus o.g. Gründen sehr zu bezweifeln. Und wesentlich flexibler (mal eben die Logik ändern, auch wenn das "mal eben" inzwischen auch eine Stunde rechnet) ist beim ASIC nicht.
Der Nachteil ist wirklich das Routing Delay (die Transfer Gates haben halt einen Innenwiderstand, mit dem C der Leitung gibt das ein RC-Glied, Mux. als Alternative erzeugen ebenfalls Verzögerungen), der Stromverbrauch ist bei modernen FPGA garnicht mal soviel höher als bei einem ASIC.
Die setzen auch vielfach Standard-IC's ein.
[ AMD ]
Eben, das macht schon Sinn, und so ist man in Dresden zudem zu einer Fab gekommen, die auch für andere Unternehmen fertigt.
Wir haben den Vorteil, dass wir kein Dritt-IP einsetzen, d.h. ich kann beliebig lustig portieren.
Na, der lebt noch und die Preise, die Du bei den Üblichen Verdächtigen Kataloganbietern siehst, sind nicht jene, die man uns angeboten hat.
Ich möchte da aber nicht ins Detail gehen, das wäre nicht fair gegenüber unseren Geschäftspartnern.
Wir haben allgemeingültigen VHDL Code geschrieben und selbst bei FPGAs kommt am Ende aus dem VHDL Compiler eine Netzliste.
Die Frage ist, ob es momentan Sinn macht, und das sieht erstmal nicht so aus, solange die Stückzahlen nicht in die Millionen gehen. Und bitte immer bedenken: Ein FPGA ist sehr flexibel, auch später im Feld.
Das ist bei mir ohne Testbenches gezählt.
Warum sollte ich die wertvollen Multiplizierer dafür verheizen, wenn es eine so elegante Lösung wie CORDIC gibt. Die Schrittzahl stört mich dank Pipelining nicht.
Das war die Intention, 600 MHz Befehlstakt geht schlecht mit dem FPGA, Vektor-Pipelines und Hardware-FFT schlecht mit dem DSP. So haben wir das Beste aus beiden Welten.
Glaube ich auch nicht. Wenn's eng wird, nimmt man einfach den Steuerzahler als Dukatenesel. Haben wir ja nun auf beiden Atlantikseiten erlebt. Der zahlt immer, weil er gar nicht erst gefragt wird. Ausser diesmal in Kalifornien und er hat nee gesagt...
Bei uns werden gelegentlich auch analog kleine Nodes benoetigt, wenn mehrere Chips in eine winzige Katheterspitze gepfercht werden muessen.
Allerdings sind FPGA zumindest fuer die meisten meiner Projekte einfach zu teuer. Das ist seit gut 20 Jahren so. Damals PALs und GALs, und gegen den Durst dieser Dinger war selbst ein Dodge Challenger eine Spardose.
Wenn ich die ganzen Schaltregler beim derzeitigen Projekt fertig habe geht's an die Logik, und auch die wird wohl wieder das uebliche CMOS Grab. 74HC und Konsorten sind so unschlagbar billig. Ist aber natuerlich nicht in Deiner Geschwindigkeitsklasse, wobei Reaktionen innerhalb einiger zig nsec schon noetig sind, um einen gepfefferten Knall zu verhindern.
Wir haben das mal getan, Stueckzahlen so gut 50k/Jahr, da hatte sich das ASIC gerechnet. Einfach weil die FPGA so tierisch teuer waren. Oh war der Sales Rep nachher bedroeppelt.
Nicht so ganz. Jim Thompson von der s.e.d. NG mischt im Bereich GPS kraftig mit, alles Custom.
Freut mich, besonders da es endlich mal eine Erfolgsgeschichte im Osten des Landes ist. Sofern das ohne Subventionen weitergeht ...
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Bei Digikey habe ich den Lattice-Chip jetzt nicht gefunden, aber hängt wohl auch immer vom Verhandlungsgeschick und der Menge ab, wie teuer das dann wird.
Hängt wahrscheinlich immer von der Anwendung ab. Wenn man z.B. 20 Schritte braucht, um einen Multiplizierer zu sparen, dann braucht man auch 20 Pipeline-Stages, um dieselbe Geschwindigkeit zu bekommen und solange was in der Pipeline ist, hat man keinen Zugriff darauf, sodaß die Berechnungen unabhängig voneinander sein müssen und keine Verzweigungen drin vorkommen dürfen. Wenn man die Multiplizierer aber in FIRs z.B. für schnelle parallele Verarbeitung braucht, könnte das schon sinnvoll sein, den Rest per CORDIC zu bauen, je nachdem wie effizient man eine Pipeline-Stage implementieren kann, oder falls es an bestimmten Stellen nicht so schnell sein braucht. Aber da erzähle ich dir wahrscheinlich nichts neues :-)
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Nicht eher da du doch bitte auf den Spartan 6 warten sollst, weil der das alles viel schicker machen wird? Der Vaporwareverdacht schwingt da doch immer mit, mal schauen wann das tatsächlich mal etwas konkreter wird.
Die Spartan 6 sehen zumindest ziemlich nach Reaktion auf diese Lattice Bausteine aus.
Wobei die Anzahl an Zeilen wenig sagt, wie groß das am Ende wird. Oft ist doch gerade die raffinierte Lösung ein paar Zeilen länger dafür im FPGA kleiner und schneller.
Wobei zumindest die DSP Slices bei den Xilinxteilen sehr nette Direktverbindungen haben. Begreift zwar das Synthesetool nicht selbstständig, aber wenn man ihm das von Hand beibringt und die Struktur aufs eigene Problem passt wird das ganze schon sehr schnell. Da hat man dann eher das Problem, das die restliche Logik im FPGA nicht mithalten kann.
Habs jetzt nur kurz überflogen, aber sieht für mich nach einem Kandidaten für ein conditional move aus. Hat der DSP keinen entsprechenden Befehl?
Auch beliebt ist immer: (fast alle) RAM Blöcke voll. Wirklich voll bekommt man die Teile imho kaum, vorher stösst man eher an die Barriere Geschwindigkeit oder RAM Blöcke. Macht auch nicht wirklich mehr Spaß damit zu arbeiten, wenn die Teile fast ganz voll sind und an der Geschwindigkeitsbarriere kratzen und die Routingzeiten plötzlich viel länger werden, bis er einen Lösung findet, die gerade noch so funktioniert.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.