Hat jemand genauere infos bezüglich der verfügbarkeit der Intel FPGAs? Insbesondere kleinere wie Max10: gem. unserer broker beliefert intel nun ausschliesslich US verteidigung, strategische partner und interne produktion. Da die ja von TSMC produziert werden könnte sich bei einem entsprechenden produktionsslot die schlagartig entspannen... Auch infos zu Xilinx sind von intresse; wechsel lohnend? (verfügbarkeit ebenfalls etwas schief)
DigiKey hat kürzlich unsere Intel FPGA Bestellung ebenfalls storniert mit Begründung, das aufgrund einer Anordnung des US Department of Defense keine Exporte dieser Technologie durchgeführt werden. Wenn das auf alle FPGA Hersteller zutrifft werden wir wohl ein riesen Problem haben, so ziemlich alle großen FPGA Hersteller haben ihren Sitz in den USA.
Beitrag #7013970 wurde von einem Moderator gelöscht.
Beitrag #7013973 wurde von einem Moderator gelöscht.
Beitrag #7014000 wurde von einem Moderator gelöscht.
Hört mal das ist einfach albern. Ich sage lediglich, was meine Einschätzung zukünftiger Verfügbarkeit von FPGA Bausteinen ist.
Olaf P. schrieb: > Hört mal das ist einfach albern. Ich sage lediglich, was meine > Einschätzung zukünftiger Verfügbarkeit von FPGA Bausteinen ist. Dich hat hier aber keiner nach deiner un-inspirierten, un-objektiven, un-recherchierten Meinung gefragt. Wenn Deine Selbstdisziplin und/oder deine Schliessmuskel zu schwach sind: https://www.mikrocontroller.net/forum/null
Olaf P. schrieb: > Ich sage lediglich, was meine Einschätzung zukünftiger Verfügbarkeit > von FPGA Bausteinen ist. Und was hat in dieser polemischen Herumpolitisiererei eine schon ewig nicht mehr existente DDR oder der dritte Weltkrieg zu suchen? > Ich sage lediglich, was meine Einschätzung zukünftiger Verfügbarkeit > von FPGA Bausteinen ist. Falls du da noch zu klein warst oder es vergessen hast: wir hatten schon mal so eine Phase der Aufrüstung. Es hat der Entwicklung neuer Technologien und dem wirtschaftlichen Aufschwung nicht wesentlich geschadet.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Olaf P. schrieb: >> Ich sage lediglich, was meine Einschätzung zukünftiger Verfügbarkeit >> von FPGA Bausteinen ist. > Und was hat in dieser polemischen Herumpolitisiererei eine schon ewig > nicht mehr existente DDR oder der dritte Weltkrieg zu suchen? > >> Ich sage lediglich, was meine Einschätzung zukünftiger Verfügbarkeit >> von FPGA Bausteinen ist. > Falls du da noch zu klein warst oder es vergessen hast: wir hatten schon > mal so eine Phase der Aufrüstung. Es hat der Entwicklung neuer > Technologien und dem wirtschaftlichen Aufschwung nicht wesentlich > geschadet. Was willst du denn jetzt? Dich kann ich einfach nicht ernst nehmen.
Olaf P. schrieb: > Dich kann ich einfach nicht ernst nehmen. Mag sein. Deine persönlichen Empfindungen tun aber nichts zur Sache. FPGA schrieb im Beitrag #7013438: > Auch infos zu Xilinx sind von intresse; Wurde von AMD für 50 Milliarden aufgekauft. > wechsel lohnend? Kurz und mittelfristig: du brauchst derzeit nirgendwohin wechseln, weil irgendwie alle um den selben Topf (TSMC) stehen und nach einem Stück Fleisch (Silizium) stochern. Und wenn wechseln, dann nur, wenn du die für den Wechsel vorgesehenen Teile schon für 2 Jahre im Lager hast. Und langfristig: natürlich kann auch AMD/Xilinx all das, was Intel/Altera auch können. Und beide haben gefühlt etwa die selbe Reputation am Markt.
Lothar M. schrieb: > Kurz und mittelfristig: du brauchst derzeit nirgendwohin wechseln, weil > irgendwie alle um den selben Topf (TSMC) stehen Njein, hies es nicht mal das intel nach dem Altera Aufkauf deren fertigungsaufträge auf die eigen Fabs umschrieb?! intel hat noch Fabs im Unterschied zu Xilinx, ARM, Altera, AMD, ... https://en.wikipedia.org/wiki/List_of_Intel_manufacturing_sites https://www.eetimes.com/intel-to-make-14-nm-fpgas-for-altera/
Lothar M. schrieb: > Und langfristig: natürlich kann auch AMD/Xilinx all das, was > Intel/Altera auch können. Und beide haben gefühlt etwa die selbe > Reputation am Markt. Das ist doch wieder so eine Lothar Aussage. Das stimmt einfach nicht und hängt vom Einzelfall ab was man braucht. Die können keineswegs alle das gleiche.
Olaf P. schrieb: > Das ist doch wieder so eine Lothar Aussage. Das stimmt einfach nicht und > hängt vom Einzelfall ab was man braucht. Die können keineswegs alle das > gleiche. Doch! Oder kannst du fundierte Gegenbeispiele nennen?
Fremdschämender Ingenieur schrieb: > Olaf P. schrieb: >> Das ist doch wieder so eine Lothar Aussage. Das stimmt einfach nicht und >> hängt vom Einzelfall ab was man braucht. Die können keineswegs alle das >> gleiche. > > Doch! Oder kannst du fundierte Gegenbeispiele nennen? Kann er das? Nein! Also warum sollte ich?
Olaf P. schrieb: > Die können keineswegs alle das gleiche. Ich habe ja auch nie behauptet, dass da irgendein 1k€-AMD-FPGA gegen irgendein beliebiges 10€-Intel-FPGA ersetzt werden könnte. Ich habe nur gesagt, dass die mit dem selben Wasser kochen, die selbe Technologie verwenden und sich deshalb das selbe Problem auf ähnliche Art lösen werden. Und wenn ich für die Lösung eines Problems ein AMD/Xilinx-FPGA im 100€-Bereich brauche, dann kostet mich diese Lösung auch bei Intel/Altera etwa gleich viel (wenn ich nicht irgendeinen quersubventionierten Preis bekomme). Und irgendwo am Rande des Lieferspektrums gibt es dann sicher auch Ausreißer, wo nur einer der beiden was anbietet. Aber 99% der Aufgaben, die sich mit einem FPGA von I/A lösen lassen, lassen sich auch mit einem FPGA von A/X lösen. Diese Portierbarkeit ist ja der eigentliche Witz...
Beitrag #7014191 wurde von einem Moderator gelöscht.
Beitrag #7014204 wurde von einem Moderator gelöscht.
Olaf P. schrieb: >>> Das stimmt einfach nicht und >>> hängt vom Einzelfall ab was man braucht. Die können keineswegs alle das >>> gleiche. >> >> Doch! Oder kannst du fundierte Gegenbeispiele nennen? > > Kann er das? Nein! Also warum sollte ich? Weil du Interesse an einer fachlichen Diskussion hast und nicht (nur) an eitlen Stänkereien ?!
Lassen wir doch bitte diesen Hickhack (und auch die [indirekten] Beleidigungen). Da mag einem schon mal ein Schipfwort durch den Kopf gehen. Man braucht es ja nicht gleich in die Finger abgeliten zu lassen... Olaf P. schrieb: > Kann er das? Kann er. Ich habe schon 2 Designs von Xilinx nach Altera portiert und kann sagen: es geht problemlos. Und ich habe bei beiden ähnlich guten Support erhalten und bei keinem der beiden Probleme mit der Beschaffung (naja, bis derzeit...).
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Ich habe schon 2 Designs von Xilinx nach Altera portiert Umgekehrt geht's vermutlich nicht so problemlos: Altera hat keine Probleme mit asynchronen Resets, Xilinx schon. Die BUFG von Xilinx sind nur für Clocks, die GLOBAL bei Altera sind explizit auch für Enable-Signale.
Josef G. (bome) schrieb: > Altera hat keine Probleme mit asynchronen Resets, Xilinx schon. Nein xilinx hat nur probleme bei Mischungen von beiden reset-schemes. Und ein (globaler) reset ist bei Xilinx meist unnötig: https://www.xilinx.com/support/documentation/white_papers/wp275.pdf https://www.xilinx.com/support/documentation/white_papers/wp272.pdf
Josef G. (bome) schrieb: > Altera hat keine Probleme mit asynchronen Resets, Xilinx schon. Nein, auch das ist ein falsch erfasstess Gerücht. Altera hat ausschließlich Flipflops mit asynchronem Reset. Xilinx Flipflops können diesen Modus auch. Natürlich muss auch bei Altera der asynchrone Reset einsynchronisiert werden und synchron deaaktiviert werden. Und darüber hinaus können Xilinx FFs eben einen weiteren synchronen Modus, der für synchrone Designs Optimierungen zulässt. Wenn man diesen Modus bewusst verwendet, dann lassen sich synchrone Designs mit synchronem Set/Reset effizienter umsetzen. Diese optimierten Flipflops können natürlich dann nicht verwendet werden, wenn man z. B. in einem üblichen synchronen Design mit einem globalen asynchronem Reset (also nur beim Einschalten oder wenn der Entwickler auf den Knopf drückt) einen Zähler auf 0 oder eine FSM auf "idle" zurücksetzt. Dann muss bei Xilinx ebenso wie bei Altera zusätzliche Logik für einen synchronen Reset (der ja dann laufend kommen wird) auf 0 bzw. "idle" eingefügt werden, denn der asynchrone Reset kann dafür ja nicht verwendet werden.
Hallo Leute, um etwas aufs thema zuruckzukommen: hat wer etwas genauere infos die er ohne NDA etc. zu verletzen publizieren könte (grob verschwommen). Bestenfalls die Produktionsplanung von TSMC 55nm fabs... Für unsere einfache Anwendung können problemlos intel ODER AMD verwendet werden. Lattice wäre vermutlich auch möglich.
Lothar M. schrieb: > Natürlich muss auch bei Altera der asynchrone Reset einsynchronisiert > werden und synchron deaaktiviert werden. Hörst du dir auch selber manchmal zu? Asynchrone reset Signale müssen nicht synchronisiert werden das ist die Idee dahinter.
Lothar M. schrieb: > du brauchst derzeit nirgendwohin wechseln, weil > irgendwie alle um den selben Topf (TSMC) stehen und nach einem Stück > Fleisch (Silizium) stochern. Das wäre vielleicht mal die Chance für alternative Anbieter. Colognechip (als beliebiges Beispiel) lässt zum Beispiel anscheinend bei Globalfoundries fertigen, die auch ein Werk in Dresden haben. (https://colognechip.com/programmable-logic/gatemate/) Da Globalfoundries auch ein Konzern aus den USA ist, löst das zwar nicht direkt politische Probleme, aber eventuell zumindest schonmal Lieferkettenprobleme.
Olaf P. schrieb: > Lothar M. schrieb: >> Natürlich muss auch bei Altera der asynchrone Reset einsynchronisiert >> werden und synchron deaaktiviert werden. > > Hörst du dir auch selber manchmal zu? Asynchrone reset Signale müssen > nicht synchronisiert werden das ist die Idee dahinter. Aua, Gratulation! Du hast es ja echt voll drauf. Mach' einfach weiter so, du bist da etwas großem auf der Spur.
Angehängte Dateien:
-
reinRaus_asyncsync.PNG
150 KB
Olaf P. schrieb: > Lothar M. schrieb: >> Natürlich muss auch bei Altera der asynchrone Reset einsynchronisiert >> werden und synchron deaaktiviert werden. > > Hörst du dir auch selber manchmal zu? Asynchrone reset Signale müssen > nicht synchronisiert werden das ist die Idee dahinter. Schon mal versucht, weiterzudenken als nur bis zur ersten Signalflanke ?! Wie bei jedem Zustand sind auch beim Reset die übergänge in diesen (Reset) zustand (activate reset) wie auch aus diesem Zustand weg (release reset) zu betrachten. Und natürlich darf es beim Verlassen des Resetzustandes nicht zu dem Problemen der timing verletzung wie metastabile Zustände kommen. Anhang aus: https://www.embedded.com/asynchronous-reset-synchronization-and-distribution-challenges-and-solutions/
Dussel schrieb: > Da Globalfoundries auch ein Konzern aus den USA ist, Als AMD waren sie ne US-Firma. Und um seine Schulden zu bezahlen hat AMD seine Fab in Dresden an die Scheichs in Arabien (Mubadala Investment Company) verkauft.
Fpgakuechle K. schrieb: > Schon mal versucht, weiterzudenken als nur bis zur ersten Signalflanke > ?! Das ist doch Blödsinn und so in der Realität auch gar nicht relevant. Lothar macht hier einfach immer auf den allwissenden aber an den Toren des elfenbeinturm hört eben auch sein wissen auf.
Angehängte Dateien:
-
_20220326_131430.JPG
130 KB
Olaf P. schrieb: > Asynchrone reset Signale müssen nicht synchronisiert werden Die Altera AN545 empfiehlt anderes: der asynchrone Reset muss in jede Taktdomäne einsynchronisiert werden. Dort diskutieren wir darüber: Beitrag "Re: Altera Reset Synchronizer richtig machen" Fpgakuechle K. schrieb: > Und natürlich darf es beim Verlassen des Resetzustandes nicht zu dem > Problemen der timing verletzung wie metastabile Zustände kommen. Dabei ist wieder mal die Metastabilität weniger das Problem, denn die Flipflops sind bis zur nächsten Taktflanke locker wieder stabil. Sondern es ist die Laufzeit des Reset-Signals zu den Flipflops. Und wenn also wie gezeichnet der Reset zeitgleich mit der Taktflanke inaktiv wird, dann kann es sein, dass die Hälfte des Designs (bzw. der FSM) schon mit dieser Taktflanke losläuft, die andere Hälfte aber erst bei der nächsten. Siehe z.B. http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html Fremdschämender Ingenieur schrieb: > hies es nicht mal das intel nach dem Altera Aufkauf deren > fertigungsaufträge auf die eigen Fabs umschrieb? Das ist naheliegend, aber so schnell geht die Umstellung und die Freigabe der Fertigung nun auch wieder nicht.
:
Bearbeitet durch Moderator
Olaf P. schrieb: > Das ist doch Blödsinn und so in der Realität auch gar nicht relevant. Auch mit dieser Meinung stehst du hier im Forum reichlich einsam da. > Lothar macht hier einfach immer auf den allwissenden aber an den Toren > des elfenbeinturm hört eben auch sein wissen auf. Ehrlich, nachdem was Du hier von dir gegeben hast (bspw. Beitrag "Re: Verfügbarkeit Intel FPGA"), scheinst Du nicht mal Ansatzweise in der Lage zu sein, das KnowHow anderer zum Thema FPGA zu bewerten. Und nach meiner Einschätzung schreibt eben Lothar, wie viele Andere auch, aus der Praxis als Schaltungsentwickler. Den 'Elfenbeinturm' wie bspw. Studenten und Endlos-Promoirrende findet man eher auf der Seite der Frager und zwanghaften Kommentatoren.
Dussel schrieb: > Lothar M. schrieb: > >> du brauchst derzeit nirgendwohin wechseln, weil >> irgendwie alle um den selben Topf (TSMC) stehen und nach einem Stück >> Fleisch (Silizium) stochern. > > Das wäre vielleicht mal die Chance für alternative Anbieter. Colognechip > (als beliebiges Beispiel) lässt zum Beispiel anscheinend bei > Globalfoundries fertigen, die auch ein Werk in Dresden haben. > (https://colognechip.com/programmable-logic/gatemate/) > Da Globalfoundries auch ein Konzern aus den USA ist, löst das zwar nicht > direkt politische Probleme, aber eventuell zumindest schonmal > Lieferkettenprobleme. Wieso soll die USA ein politisches Problem darstellen? Anyway das ganze ist ein Angebot/Nachfrageproblem... Hat nix mit westlicher politik zu tun. Und politische risiken sind unter westlichen nationen vernachlässigbar. (Dies beinhaltet natürlich nicht die Russerei und seine kommunistischen Nachbarn). Nun das Kölner FPGA ist natürlich zu begrüssen, einsetzen kann ichs dennoch nicht - risiken - langzeitverfügbarkeit, stabilität etc. Lothar M. schrieb: > Olaf P. schrieb: > >> Asynchrone reset Signale müssen nicht synchronisiert werden > > Die Altera AN545 empfiehlt anderes: der asynchrone Reset muss in jede > Taktdomäne einsynchronisiert werden. Dort diskutieren wir darüber: > Beitrag "Re: Altera Reset Synchronizer richtig machen" > Fpgakuechle K. schrieb: > >> Und natürlich darf es beim Verlassen des Resetzustandes nicht zu dem >> Problemen der timing verletzung wie metastabile Zustände kommen. > > Dabei ist wieder mal die Metastabilität weniger das Problem, denn die > Flipflops sind bis zur nächsten Taktflanke locker wieder stabil. Sondern > es ist die Laufzeit des Reset-Signals zu den Flipflops. Und wenn also > wie gezeichnet der Reset zeitgleich mit der Taktflanke inaktiv wird, > dann kann es sein, dass die Hälfte des Designs (bzw. der FSM) schon mit > dieser Taktflanke losläuft, die andere Hälfte aber erst bei der > nächsten. > Siehe z.B. > http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html > Fremdschämender Ingenieur schrieb: > >> hies es nicht mal das intel nach dem Altera Aufkauf deren >> fertigungsaufträge auf die eigen Fabs umschrieb? > > Das ist naheliegend, aber so schnell geht die Umstellung und die > Freigabe der Fertigung nun auch wieder nicht. Denke das wird höchstens für die modernen FPGAs gemacht, ein nodeswitch ist extreeem teuer und eigentlich Sinnbefreit. Der Max10 55nm +NOR Flash TSMC wird vermutlich kaum jemals von intel hergestellt werden.
Du könntest dir mal Gowin anschauen, die haben sich bei der Entwicklung ihrer FPGAs bezüglich Pinout bei einigen High-Runnern der Konkurrenz inspirieren lassen, unter anderem MAX10. Das rettet gerade einigen den Hintern und dementsprechend wird denen aktuell die Bude eingerannt. Die Teile funktionieren, die Tools und sonstige Ressourcen haben aber noch einige Bugs, vor allem, wenn man das in externe Tools einbinden muss.
:
Bearbeitet durch User
FPGA schrieb im Beitrag #7015907: > Wieso soll die USA ein politisches Problem darstellen? Deswegen zum Beispiel: René F. schrieb: > DigiKey hat kürzlich unsere Intel FPGA Bestellung ebenfalls storniert > mit Begründung, das aufgrund einer Anordnung des US Department of > Defense keine Exporte dieser Technologie durchgeführt werden. FPGA schrieb im Beitrag #7015907: > Nun das Kölner FPGA ist natürlich zu begrüssen, einsetzen kann ichs > dennoch nicht - risiken - langzeitverfügbarkeit, stabilität etc. Es ersetzt sicher nicht Hochleistungs-FPGAs in Millionenstückzahlen. Aber im ersten Schritt könnte es für Einzelanfertigungen wie Prototypen und Forschungsobjekte interessant sein. Im Moment wird da wohl oft eines der großen Hersteller genommen, weil es halt da und bekannt ist, also warum nicht. Aber gerade da könnte auch mal was anderes ausprobiert werden. Wenn sich dadurch die Nachfrage steigert, wird das ganze auch für größere Projekte interessanter.
Holger B. schrieb: > Du könntest dir mal Gowin anschauen, die haben sich bei der > Entwicklung ihrer FPGAs bezüglich Pinout bei einigen High-Runnern der > Konkurrenz inspirieren lassen, unter anderem MAX10. Das rettet gerade > einigen den Hintern und dementsprechend wird denen aktuell die Bude > eingerannt. > Die Teile funktionieren, die Tools und sonstige Ressourcen haben aber > noch einige Bugs, vor allem, wenn man das in externe Tools einbinden > muss. Danke, nun Gowin wird garantiert disqualifizert sein (aus etlichen Gründen/Risiken). Lattice wäre evtl. eine Option, evtl microsemi oder ähnich. Nun dass die erste wahl norm zu den beiden Marktführern geht ist ja logisch und hat hauptsächlich mit risk management zu tun. Viele verstehen anscheinend den Unterschied zwischen hobby und Industrie MP nicht: Einen noname hersteller (wie zb Gowin) einzusetzen wäre fahrlässig und riskiert die ganze firma. Oberste priorität: kein (serien) fail! alles andere (unter anderem kosten) ist weniger wichtig
Naja, Gowin wurde bereits von großen FPGA Entwicklerbuden qualifiziert und als MAX10-Ersatz eingesetzt, und ich mach das hier auch nicht als Hobby. Daher kannst du mal davon ausgehen, dass es da eine sorgfältige Abwägung zwischen quartalsweise beliebigen Zuteilungen von Intel mit einem Bruchteil der benötigten Menge nebst resultierendem Produktionsstopp über unbestimmte Zeit und dem Risiko eines bisher unbekannten Herstellers gab. Hätte einer der etablierten was passendes liefern können, würde man das Risiko natürlich nicht eingehen, aber wenn man keine Wahl hat...? Aber gut, freut mich, wenn Du Dir das noch aussuchen kannst!
Ja Pingpong FPGAs sind definitiv keine Option. Ich hoffe das ist für euch auch nur eine überbrückungslösung - die (politischen) risiken übersteigen bei china bei weitem ein: aktuell nicht lieferbar, da us verteidigungsministerium benötigt :P Von allen anderen risiken und dem ethischen aspekt mal abgesehen. Würde mich freuen zu sehen, wenn die Kölner ein etablierter hersteller werden. Lattice ist lieferbar, dies ist eine ernste Option
FPGA schrieb im Beitrag #7016699: > Nun dass die erste wahl norm zu den beiden Marktführern geht ist ja > logisch und hat hauptsächlich mit risk management zu tun. Das so proklamierte Risk-Management hat bestimmt auch vorausgesehen, dass von heute auf morgen gewisse Chips nicht mehr verfügbar/massiv verteuert sind, die Software teils unter aller Sau ist und man wochenlang festhängt, sich Firmenpolitik nach einem Aufkauf ändert, usw. Fazit: Als risikominimierend hat sich herausgestellt, plattformunabhängig zu entwickeln und sich nach Möglichkeit eine Zweitquelle zu sichern. Ich habe mir Gowin, Efinix wie auch die vielversprechende Gatemate-Architektur im Detail angesehen und sehe da gerade bei der Opensource-Synthese eine echte Chance, in dieser Nische zumindest nachhaltig entwickeln zu können. Wo das Silicon nun genau herkommt, dürfte einer fortschrittlich orientierten Industrie, die Resourcen für Reverse-Engineering hat, egal. Mag sein, dass ein DO-256 Handbuch was anderes sagt.
Fitzebutze schrieb: > . Mag sein, dass ein DO-256 Handbuch was > anderes sagt. Die DO-254 "Design Assurance Guidance for Airborne Electronic Hardware" ist nicht nur ein Handbuch/Manual für den Techniker, sie ist die Norm für den Einsatz von FPGA/CPLD's in Flugzeugen. In der DO wird die Elektronik nach verschiedenen 'Risiken' eingeteilt, von DAL-E (juckt nicht) zu DAL-A (Flieger schmiert ab, alle tot). Anspruchsvoll wird es für den Entwickler ab DAL-C, da die dafür geforderten Ausfallwahrscheinlichkeiten geringer als für ein Elektronikbauteilüblich sind (10^-5 bis 10^-7 pro Flugstunde). Deshalb velangt man bspw. die Qualifikation der Toolchain, was heisst das Synthesetools etc. eine gewisse Reife erreicht haben und damit nachgewiesen haben, das sie 'korrekten' Input (bspw. HDL) in äquivalnt korrekten Output (bit-file) umsetzen. Bei dieser Qualifikation tut man sich bei den seit Jahrzehnten bekannten tools/Chips (Xilinx, Microsemi) leichter als bei neueren. Aber auch bei diesen ist (insbesonders bei DAL-A, DAL-B) noch viel (unsicheres) Neuland, so galt der Zynq 2019 noch als nicht für Airborne qualifiziert (könnte heute anders sein). >Fazit: Als risikominimierend hat sich herausgestellt, >plattformunabhängig zu entwickeln und sich nach Möglichkeit eine >Zweitquelle zu sichern. Volle Zustimmung, man sollte sich regelmäßig überzeugen, das man den Quellcode auch auf anderes Hersteller übertragen kann. Das bedeudet oft, das man sich von einigen Hersteller-Sonderlocken trennt, grad bei Altera gibt es da meines Erachtens sehr spezifische Tools die Altera selbst nicht mehr mit updates unterstütztz (z.B. geht Cyclone II nicht mit Quartus älter 13.0 (aktuell 22)). Manche nutzen aus diesem Grund HDL-Designer und synplicity, weil mit diesen tools Designs für verschiedenen Plattformenen generiert werden kann.
DO-254 DAL A oder B ist einfach eine andere Welt im Vergleich zu Consumer FPGA Designs. Dort möchte man kein FPGA verwenden, das nicht gut erprobt ist und vom Hersteller unterstützt wird. Also Xilinx/AMD oder Microsemi. Intel ist da auch im Boot, scheint das allerdings nicht so richtig als seinen Markt zu sehen. Im Aerospace-Bereich sind Stückzahlen eher klein, Lieferverträge sehr lang und Stückkosten nicht so relevant. Allgemein sind FPGAs zur Zeit schwer zu bekommen. Aber es ist möglich für neue Designs Samples zu bekommen. Brot und Butter FPGAs in größeren Stückzahlen eher nicht so leicht. So zumindest mein Eindruck.
Hallo zusammen, Als Kommentar von der Seitenlinie: Microchip (ehemals Microsemi) sind für den mittelbaren Umstieg eine mögliche Alternative. Im Februar gab es zu dem Thema ein Webinar und demnächst macht Arrow ebenfalls eines. Einsatz in sensiblen Bereichen ist damit ok und v.a. die Langzeitverfügbarkeit dort wird ganz stark rausgestellt. Schönen Gruß Schloßgeist
Reinhard schrieb: > DO-254 DAL A oder B ist einfach eine andere Welt im Vergleich zu > Consumer FPGA Designs. Dort möchte man kein FPGA verwenden, das nicht > gut erprobt ist und vom Hersteller unterstützt wird. ... und für das eine entsprechende Lieferzeit / Mindestliefermenge bei last buy garantiert wird ...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.