Hallo Forum, mein Chef meint, dass man bei der Synthese in Quartus auswählen kann, ob der spätere FPGA im Temperaturbereich für "Commercial" oder "Industrial" ausgelegt sein soll. Weiß einer von euch wo man das einstellen kann? Ich finde den Button für "Commercial" oder "Industrial" einfach nicht und mein Chef weiß auch nicht wo der sein kann. Grüß Kasi
device options : Temperaturen müssen aber selber eingestellt werden, also z.B. bis 120 Grad etc.
Altera bietet einige FPGA auch als "Industrial-Grade" an. Ein "Industrial-Grade" FPGA erkennst du am Device Suffix ...Ix (x=2 bis 8). z.B. EP3C5U256I7
Ahh danke. Bei mir war das mit der Temperatur immer grau, weil ich Auto Device an hatte.
Weder die Temperaturangabe noch die Angabe des Commercial-/Industrial-Grades hat einen Einfluss auf das Syntheseergebnis. Gruß, fpga-dev
> Weder die Temperaturangabe noch die Angabe des > Commercial-/Industrial-Grades hat einen Einfluss auf das > Syntheseergebnis. Das würd ich jetzt mal so nicht unterschreiben. Je heisser ein Chip wird umso höher sind die Signallaufzeiten. Somit kann es durchaus sein dass ein Design bei 50°C noch funktioniert, aber bei 100° nicht mehr weil die Setup-Zeit zu kurz bemessen ist. Andersrum gehts natürlich, wenn ein Design für 120° synthetisiert ist läufts auch bei 50°, wenns für 50° synthetisiert ist läufts auch auf nem Chip bei dem 120° draufsteht. Nur obs bei 120° noch läuft ist Glückssache. Inwiefern Altera die angegebene Temperatur berücksichtigt und wie gross die Sicherheitspielräume sind kann ich nicht beurteilen. Ich würde aber davon abraten ein Design für nen Industrial Grade FPGA mit den Constraints für nen Commercial zu synthetisieren. Ansonsten viel Spass beim Fehlersuchen :-)
Die Synthese richtet sich nur an der FPGA-Zielarchitektur. Diese ist bei Commercial bzw. Industrial FPGAs identisch. Der einzige Unterschied ist, daß nach der Fertigung die einzelnen FPGA-Chips getestet und aufgrund ihrer besserer bzw. schlechterer Temperaturverträglichkeiten zu Industrial bzw. Commercial-Typen gelabelt werden. Es gibt keine gesonderten Fertigungslinien für die unterschiedlichen FPGA-Varianten. Höhere Temperatur wirkt sich negativ auf die Signallaufzeiten und Leistungsverbrauch. Also sind die einzigen Entwurfsschritte Timing- bzw- Power-Analyse, in denen die explizite Temperaturangabe zur genaueren Ergebnissen der Analyse beitragen KANN. (Wenn die Temperaturangaben wirklich von der Software verwendet werden, was m.E. bei Altera und Xilinx nicht der Fall ist.) Gruß, fpga-dev
> Höhere Temperatur wirkt sich negativ auf die Signallaufzeiten und > Leistungsverbrauch. Also sind die einzigen Entwurfsschritte Timing- bzw- > Power-Analyse, in denen die explizite Temperaturangabe zur genaueren > Ergebnissen der Analyse beitragen KANN. Nicht unbedingt exclusiv, wenn zb. Register retiming eingeschaltet ist sind die Signallaufzeiten schon auch für Synthese relevant. Das ganze ist natürlich nur von Interesse wenn das Design bis aufs letzte MHz ausgequetscht wird oder unter Grenzbedingungen läuft (Über/Unterspannung). > (Wenn die Temperaturangaben > wirklich von der Software verwendet werden, was m.E. bei Altera und > Xilinx nicht der Fall ist.) Würdest du deine Hand dafür ins Feuer legen? Ich nicht, deshalb stell ich das schön brav alles richtig ein und hoffe dass die Library-Designer bei Altera alles richtig gemacht haben.
> Würdest du deine Hand dafür ins Feuer legen? Reicht es nicht, daß ich mit meinem Namen dafür gerade stehe? ;) Probiere folgendes aus: - Nimm ein Design mit Industial-Grade FPGA, - Stelle 100° Grad ein und führe nur die Timing-Analyse durch (Processing->Compiler Tool->Classic Timing Analyzer), - Ändere die max. Betriebstemperatur auf 125°, führe nochmal die Timing-Analyse durch (ohne neu zu Synthetisieren) Die beiden Werte werden identisch sein. Die Frage ist nun: wenn schon die Timing-Analyse nichts von unterschiedlichen Signallaufzeiten merkt (weil die Temperatur nicht in die Berechnungen einbezogen wird), wie soll es die (Re-)Synthese tun können? Gruß, fpga-dev
Ganz ehrlich, ich habs noch nicht ausprobiert. Es kommt natürlich auch darauf an, auf welche Daten die Timing-Analyse zugreift. Wenn die Daten durch die Synthese festgelegt werden, ist dein Ansatz zum scheitern verurteilt. Hast du mal unterschiedliche Synthesen laufen lassen und die Ausgaben der Timing-Analysen miteinander verglichen? Ich weiss nur, dass richtige Synthese-Software (z.b. Synopsys Design Compiler) für die ASIC-Herstellung durchaus mit Librarys versorgt wird, die dort Laufzeitunterschiede machen. Deswegen werden auch slow corner (warm + niedrige spannung) und fast corner (kalt + hohe spannung) Timing-Analysen gemacht um sicherzustellen dass die Synthese für alle Eventualitäten genügend Luft gelassen hat. Deswegen bleibe ich dabei: Ohne genau zu Wissen was die Software tut würde ich keinen Industrial FPGA mit Commercial Constraints synthetisieren. Aus irgend nem Grund steht ja Industrial drauf, und wenn ich den Vorteil mit der fehlenden Einstellung (eventuell, je nachdem was die Software macht) wieder verspiele isses Blödsinn - meine Meinung, du darfst gern ne andere haben :-)
> Es kommt natürlich auch darauf an, auf welche Daten die > Timing-Analyse zugreift. Wenn die Daten durch die Synthese > festgelegt werden, ist dein Ansatz zum scheitern verurteilt. Du offenbarst ein oberflächliches Verständnis von der Funktionalität der von dir eingesetzter Software. Nach der Platzierung und Verdrahtung ist die Position jeder Logikressource und der Verbindungspfad jedes Signals einer Netzliste festgelegt. Nur danach kann eine exakte Timing-Analyse erfolgen. Dazu geht der Timing-Analyzer alle mögliche Signalpfade von den Signalquellen zur Signalsenken ab und schaut für jedes verwendete Segment die Verzögerungszeiten in einer Timing-Datei nach. Die Verzögerungszeiten werden für jedes Signalpfad aufsummiert. Die Timing-Datei mit den Verzögerungszeiten wird von dem FPGA-Hersteller mitgeliefert und wird von den Tools selbst nicht geändert. In der Timing-Datei sind die Verzögerungszeiten für jede Segmentart in Abhängigkeit von dem Speedgrade, Fanout und Entfernung zum Signalabgriff angegeben. Temperatur wird nicht berücksichtigt. Ändert man die Verdrahtung und Platzierung nicht, kann leicht überprüft werden, welche Faktoren einen Einfluß auf die Timing-Analyse haben. So wie ich in dem vorherigen Posting vorgeschlagen habe. Die Physical-Synthesis beinhaltet nur einen Feedback von der Timing-Analyse zur Synthese. Dazu wird das Design im mehreren Iteration platziert, verdrahtet, einer Timing-Analyse und ReSynthesis unterworfen. Liefert die Timing-Analyse keine abweichenden Ergebnisse, so erzeugt auch die PhysicalSynthesis exakt dasselbe Ergebnis. > Aus irgend nem Grund steht ja Industrial drauf [..] Dafür gibt es einen einzigen Grund: Diese FPGAs können den zugesicherten Speedgrade auch bei höheren Temperaturen halten. Nicht mehr und nicht weniger. Gruß, fpga-dev.de
> Ich weiss nur, dass richtige Synthese-Software (z.b. Synopsys Design > Compiler) für die ASIC-Herstellung durchaus mit Librarys versorgt wird, > die dort Laufzeitunterschiede machen. Den Unterschied zwischen FPGA und ASIC Designflow kennst du leider nicht. Da die Verdrahtungsressourcen bei den FPGAs fest vorgegeben sind, müssen Verzögerungszeiten der einzelnen Segmente nur einmal von dem FPGA-Hersteller bestimmt werden. Bei den ASICs ist die Verdrahtung nicht festgelegt, deshalb muss nach der Synthese, Platzierung und Verdrahtung eine SPICE-Simulation die exakten Verzögerungszeiten der unterschiedlichen Signalpfade bzw. Segmente bestimmen. Diese Spice-Simulation entfällt bei den FPGAs. Gruß, fpga-dev.de
40:30 für Valerij und damit Spielball! AG hat Aufschlag :-) Ich möchte noch hinzufügen, daß es zumindest bei Xilinx einen Unterschied macht, mit welchen Bibliotheken man arbeitet. Bisweilen werden da noch ganz andere Sachen vernachlässigt. Grundsätzlich ist es aber nachvollziehbar, daß bei FPGAs kaum temperaturabhängige Analysesn betrieben werden, weil die Einflussgrößen des Routing infolge der Plazierung mehrfach stärker Frequenzlimitierend sind.
So unterschiedlich ist der Designflow nicht. Bei den ASICs an denen ich gearbeitet habe lief das ganze folgendermassen ab: Die Fab entwirft einen Satz Standardzellen (and, or...) für den gewünschten Prozess. Diese Standardzellen werden mit Spice simuliert, verifiziert und dann an die Entwickler verteilt. Darin enthalten sind Delays für alle Grenzfälle. Die Synthese macht jetzt eine Netzliste mit Rückgriff auf die Standardzellen-Lib, d.h. da steht dann drin: wire 1828397 kommt an and2_2398898. Die Timing-Analyse geht jetzt her und sammelt sämtliche Delays (inklusive der Interconnect-Delays) auf dem Weg auf und präsentiert am Schluss ne Zeit für den Pfad. Was da für eine Zeit steht, hängt davon ab, wie die Delays in der Lib angegeben sind. Beim FPGA heissen die Standardzellen halt LUT-xy usw. und das Routing-Delay berechnet sich wegen des Prinzips anders. Dabei sammelt die Analyse wieder die Delays der LUT + Delays der Routing-Muxes + Wire Delays auf. Das Prinzip ist das gleiche: HDL wird auf Zellen mit bestimmten Funktionen gemappt, und was die Funktionen können steht in der Library. Wenn jetzt Quartus (und das wissen wir nicht) bei der Synthese einen Satz Timing-Analyser Libs generiert und dabei die Einstellungen der Synthese reinschreibt, kannst du an deinem Timing-Analyser einstellen was du willst, der Delay wird sich nicht ändern. Die Temperatur hat natürlich einen Einfluss auf die Signallaufzeit, auch bei fest vorverdrahteten FPGAs. Die ganzen Schaltprozesse sind bei hohen Frequenzen alle kapazitiv. Wenn die Zuleitung durch die höhere Temperatur einen höheren Widerstand hat, dauert es länger bis die Eingangs-Kapazität vom nächsten Gatter weit genug aufgeladen/entladen ist. Der Ausgangstreiber hat einen höheren Widerstand und bringt weniger Strom. Dabei ist es völlig belanglos ob die Routing-Struktur auf dem FPGA läuft oder auf dem ASIC. > Dafür gibt es einen einzigen Grund: Diese FPGAs können den zugesicherten > Speedgrade auch bei höheren Temperaturen halten. Und allen gängigen physikalischen Gesetzen trotzen? Interessant! Eine Spice-Simulation wird bei grössen ASICs höchstens als letzter Schritt noch gemacht, aber erst dann wenn es darum geht, die Masken zu machen. Alle Synthese-Simulations-Verifikationsschritte vorher basieren auf Libraries
> Das Prinzip ist das gleiche: HDL wird auf Zellen mit bestimmten > Funktionen gemappt, und was die Funktionen können steht in der Library. Stimmt nicht! Auszug aus meiner Dissertation: "[...] Bibliothekenbasierte Logiksyntheseverfahren, die Netzlisten aus den in den Bibliotheken enthaltenen Grundgattern erzeugen, waren auf SRAM-basierten FPGAs nicht direkt anwendbar, weil eine LUT mit K Eingängen 2^K unterschiedliche Funktionen implementieren kann. Dadurch würden die für diese Verfahren notwendigen Bibliotheken überexponentiell wachsen. Deshalb fand in den Jahren nach der Einführung der SRAM-basierten FPGAs eine intensive Forschung auf der Suche nach geeigneteren Logiksynthesealgorithmen statt. [...]" Nachzulesen in - John Lockwood; Logik Synthesis for Field Programmable Gate Array (FPGA)Technology; VLSI Handbook, second Edition, CRC Press 2006 - Jason Cong, Yuzheng Ding; Combinational logic synthesis for LUT based field programmable gate arrays; April 1996, ACM Transactions on Design Automation of Electronic Systems (TODAES), Volume 1, Issue 2 > Wenn jetzt Quartus (und das wissen wir nicht) bei der Synthese einen > Satz Timing-Analyser Libs generiert und dabei die Einstellungen > der Synthese reinschreibt Wie oft soll man wiederholen, daß die Timing-Bibliotheken nicht verändert und von den Herstellern mit den Tools ausgeliefert werden? > Und allen gängigen physikalischen Gesetzen trotzen? Bei der FPGA-Fertigung kann u.a. Maskenversatz auftretten. Das führt in der Regel zu langsamer schaltenden P-MOS und/oder N-MOS-Transistoren. Die Schalt- und Verzögerungszeiten werden vom Hersteller getestet und die FPGAs mit entsprechnenden Speedgrades versehen, so daß die garantierten Verzögerungzeiten die in den Timing-Bibliotheken vermerkten nicht verletzen. Dadurch entfällt die Notwendigkeit einer aufwendigen Timing-Analyse per Spice-Simulation. Die Timing-Analyse ist bei den FPGAs eine einfachere Aufsummierung der in Timing-Bibliothekn vermerketen Verzögerungszeiten. @AG: bei Bedarf kann ich eine Reihe von Büchern empfehlen, die offengelegten Wissenslücken sicher schließen würden ;) Gruß, fpga-dev
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.