Verfügbarkeit Intel FPGA

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.

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

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.

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:
>>> 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 ?!

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

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.

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.

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.

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

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