Der Altera Pinplaner bietet etliche I/O Standards an. Z.B. ist beim max10 2.5V standart. Ich habe alle I/O bänke mit 3.3V versorgt. Der intene LDO (?) scheint aber nicht zu funktionieren, da schön die 3.3V rauskommen. Daher generell die Frage hat diese einstellung überhaupt einen einfluss? Wie können die Clamping dioden aktiviert/deaktiviert werden? Wieso ist nicht bei 3.3V GPIO 3.3V LVCMOS standard? Weshalb hat LVCMOS nur 2ma drive strengh (und 2.5V 25mA)?
> Der intene LDO (?) scheint aber nicht zu funktionieren, da schön die > 3.3V rauskommen. Du erwartest, dass man mit dem I/O-Standard die Ausgabespannung festlegen kann? Das mag's evtl. geben aber ich kenne kein FPGA, bei dem das möglich ist. Die Ausgangsspannung enstpricht generell der Bankspannung. Die einstellbare I/O-Spannung (per I/O-Standard) bezieht sich auf den Eingang! > Wie können die Clamping dioden aktiviert/deaktiviert werden? Für Altera kann ich Dir das auch nicht genau sagen, aber falls das überhaupt vorgesehen ist (z.B. für PCI), steht's im Datasheet. > Wieso ist > nicht bei 3.3V GPIO 3.3V LVCMOS standard? Weshalb hat LVCMOS nur 2ma > drive strengh (und 2.5V 25mA)? Altera fragen!
Max M. schrieb: > Der Altera Pinplaner bietet etliche I/O Standards an. Z.B. ist beim > max10 2.5V standart. Ich habe alle I/O bänke mit 3.3V versorgt. > Der intene LDO (?) scheint aber nicht zu funktionieren, da schön die > 3.3V rauskommen. Da gibt es keinen LDO/Spannungswandler für IO-Pegel im FPGA, sondern Extra Stromversorgungspin, bei dem man die gewollte IO-Spannung einspeist. Tipp1: nicht gleich mit den Tools rumspielen, sondern erst mal Datenblatt/Tutorial durcharbeiten. Tipp2: Es gibt nicht den MAX10-FPGA sondern verschiedene Subtypen, die sich auch in der Spannungsversorgung (single/dual supply) unterscheiden file:///C:/Users/dipli/Downloads/ug_m10_pwr-683400-666288.pdf
Bradward B. schrieb: > Tipp2: Es gibt nicht den MAX10-FPGA sondern verschiedene Subtypen, die > sich auch in der Spannungsversorgung (single/dual supply) unterscheiden ja, ich nutze den SC (single) nur 3.3V (aber hat vermutlich intern einen LDO für den core da ich bezweifle, dass sie den 65nm prozess auf 3.3V nutzen, da dies integrationsdichte extrem negativ beeinflussen würde (zumindest wäre der Flachenverlust viel höher als ein LDO zu integrieren)). Bradward B. schrieb: > Da gibt es keinen LDO/Spannungswandler für IO-Pegel im FPGA, sondern > Extra Stromversorgungspin, bei dem man die gewollte IO-Spannung > einspeist. Soweit auch sinnvoll nachvollziehbar. Aber dann erkläre mir bitte weshalb man den I/O pegel im Quartus wählen kann???, wenn die I/O pegel extern vorgegeben werden durch die Bank Speisung. Pat A. schrieb: > Für Altera kann ich Dir das auch nicht genau sagen, aber falls das > überhaupt vorgesehen ist (z.B. für PCI), steht's im Datasheet. genau die PCI Dioden, hab gelesen sei im constraint file zu machen. Ohne infos wie... Nun vorerst ist mir nur wichtig, dass diese per default aktiv sind (habe keine ambitionen diese zu deaktivieren). Pat A. schrieb: > Das mag's evtl. geben aber ich kenne kein FPGA, bei dem > das möglich ist. Die Ausgangsspannung enstpricht generell der > Bankspannung. Ok macht sinn soweit, dann ist diese Einstellmöglichkeit im Pinplaner ohne sinn? Pat A. schrieb: > Die einstellbare I/O-Spannung (per I/O-Standard) bezieht sich auf den > Eingang! Kann auch bei ausgang im pinplaner gewählt werden. Aber beim Eingang, also die wahl des Pegels im Pinplaner hat einen einfluss auf die VL sowie VH? Ausgang soweit keinen einfluss? Oder nur auf output current?
:
Bearbeitet durch User
>> Da gibt es keinen LDO/Spannungswandler für IO-Pegel im FPGA, sondern >> Extra Stromversorgungspin, bei dem man die gewollte IO-Spannung >> einspeist. > > Soweit auch sinnvoll nachvollziehbar. Aber dann erkläre mir bitte > weshalb man den I/O pegel im Quartus wählen kann???, wenn die I/O pegel > extern vorgegeben werden durch die Bank Speisung. Du wurdest bereits aufgefordert das Datenblatt, Tool-manual oder Tutorial durchzuarbeiten. Und eben ein Turorial für genau diese IC-Familie (FPGA) und diese tools und nicht versuchen irgendwelches Arduino/Mikrocontroller-Halbbildung bequemerweise aber falsch weiterzuspinnen. Da wird nichts "gewählt" - da werden constraints (Randbedingungen) für die timing-basierte Synthese und Place & Route festgelegt. Xilinx nennt deshalb ihr tool "constraint editor" und nicht wie Altera leicht irreführend "pin-planner". https://www.intel.com/content/www/us/en/docs/programmable/683143/24-2/i-o-planning-overview.html
:
Bearbeitet durch User
Pat A. schrieb: > Du erwartest, dass man mit dem I/O-Standard die Ausgabespannung > festlegen kann? Das mag's evtl. geben aber ich kenne kein FPGA, bei dem > das möglich ist. Die Ausgangsspannung enstpricht generell der > Bankspannung. Doch klar, wenn man da LVDS25 statt LVCMOS25 einstellt, dann sieht man am Ausgang andere Pegel. Auch Drivestrength ist nicht nur eine Constraint für Timing oder so, das ändert wirklich etwas am Ausgang.
Gustl B. schrieb: > Doch klar, wenn man da LVDS25 statt LVCMOS25 einstellt, dann sieht man > am Ausgang andere Pegel. Der TO ist Anfänger und kämpft schon mit den Standard-IOs. Da brauchst Du ihn nicht noch weiter mit Differentiellen-IOs zu verwirren. Die hierbei unterschiedlichen Pegel (im Vergleich zur Bankspannung) ergeben sich IMHO nur aus den verschiedenen Terminierungen (intern bzw. extern) der verschiedenen LVDS-Standards. > Auch Drivestrength ist nicht nur eine Constraint für Timing oder so, das > ändert wirklich etwas am Ausgang. Ganz genau, aber so ein Constraint legt die Ausgangsspannung nicht auf einen festen Wert, sondern bestimmt sozusagen nur den Innenwiderstand der Spannungsquelle des IOs, womit auch o.g. interne Terminierungen geschaltet werden. Nebenbei: es gibt meistens auch noch Contraints für die Slew Rate, also die Flankensteilheit - ändern aber auch nicht an der IO-Spannung ;-)
Der Begriff "Constraints" wird halt ziemlich mehrdeutig verwendet. Manche, die physical constraints" wirken wie configuration bits, andere stellen timing informationen für die tools bereit, andere steuern ds mapping, Placement. Für die IO-Constraints könnte man ja mal einen Blick auf das Blockbild einer IO-Zelle werfen, dann wird vielleicht klarer welche config-schalter in den constraints stecken und was eben "hart verdrahtet" ist. (Anhang aus https://www.intel.com/content/www/us/en/docs/programmable/683751/22-1/i-o-elements.html)
Pat A. schrieb: > Der TO ist Anfänger und kämpft schon mit den Standard-IOs. Da brauchst > Du ihn nicht noch weiter mit Differentiellen-IOs zu verwirren. Das hat mir vor Jahren auch zu denken gegeben, dass mitgelieferte Beispielprojekte dort 2.5 V einstellten, aber alle IO-Baenke an die 3.3 V angeschlossen waren. Die (Ausgangs-)Logikpegel sprachen auch eine eindeutige Sprache. Es ist schon in Ordnung, bei einem Zweifel einmal zu fragen.
Bradward B. schrieb: > file:///C:/Users/dipli/Downloads/ug_m10_pwr-683400-666288.pdf Dann gib doch mal Deine Festplatte im Internet frei. 😂 https://cdrdv2-public.intel.com/666288/ug_m10_pwr-683400-666288.pdf
Beitrag #7729448 wurde von einem Moderator gelöscht.
Beitrag #7729477 wurde von einem Moderator gelöscht.
Beitrag #7729931 wurde von einem Moderator gelöscht.
Max M. schrieb: > Aber dann erkläre mir bitte weshalb man den I/O pegel im Quartus wählen > kann, wenn die I/O pegel extern vorgegeben werden durch die Bank Speisung. Warum muss man beim AVR per #define die Taktfrequenz angeben, obwohl die ja per Oszillator vorgegeben wird? Damit die Toolchain weiß, welche Prescaler ausgerechnet werden müssen. Wenn du dann deinen AVR mit 8 MHz taktest, aber 16MHz angegeben hast, dann kann es halt zu Fehlfunktionen kommen. Und beim FPGA muss man diese IO-Konfigurationswerte angeben, dass die Toolchain weiß, welches Interface man zu verwenden gedenkt. Wenn du dann ein IO-Interface mit 3V3 versorgst, aber 2V5 angibst, dann kann es halt zu Fehlfunktionen kommen.
:
Bearbeitet durch Moderator
> Warum muss man beim AVR per #define die Taktfrequenz angeben, Muss man nicht ! Bei der Erklärung einer FPGA-Technologie Analogien zum Mikrocontroller oder AVR heranzuziehen verwirrt den User eher als das es dem Verständnis der digitalen Grundlagentechnik hilft. Es ist eben keine Hochsprachen -> Maschinensprache Kompilierung sondern eine Logik-Synthese/automatisiertes Place and Route.
:
Bearbeitet durch User
Wer es unbedingt ganz genau wissen will, was der IO-Standard an einem Pin einstellt, kann mit der Vollversion von Quartus2 einen "Field Change" machen, und sich dann alle einstellbaren Properties des Pins ansehen (, und natuerlich auch aendern. :) Von Vorteil ist es dann, die eingestellten Parameter mit einem hinreichend schnellen Scope unter verschiedenen Lastsituationen auch zu pruefen bzw. bei einem Eingang die Umschaltpegel zu messen. Es koennte in "exotischen" Situationen ja einmal nuetzlich sein.
Bradward B. schrieb: >> Warum muss man beim AVR per #define die Taktfrequenz angeben, > Muss man nicht ! Wenn man mit den Defaulteinstellungen zufrieden ist und die zur Hardware passen. Oder wenn man ein Programm schreibt, das völlig unabhängig von der Taktfrequenz funktioniert. Und auch beim FPGA muss man nichts angeben, wenn man mit den Defaulteinstellungen zufrieden ist und sie zur Hardware passen. > Bei der Erklärung einer FPGA-Technologie Analogien zum Mikrocontroller > oder AVR heranzuziehen verwirrt den User eher als das es dem Verständnis > der digitalen Grundlagentechnik hilft. Ich vergleiche nicht die Technologie, sondern die Toolchain. Und der Toolchain muss man in beiden Fällen sagen, wie die Hardware aussieht, für die der Code geschrieben wird. Denn sonst macht sie ggfs. Blödsinn.
Lothar M. schrieb: > Max M. schrieb: >> Aber dann erkläre mir bitte weshalb man den I/O pegel im Quartus wählen >> kann, wenn die I/O pegel extern vorgegeben werden durch die Bank Speisung. > Warum muss man beim AVR per #define die Taktfrequenz angeben, obwohl die > ja per Oszillator vorgegeben wird? Damit die Toolchain weiß, welche > Prescaler ausgerechnet werden müssen. Die AVR Toolchain braucht die Infos für Prescaler. Weshalb benötigt Quartus die Info ob die I/O Bank mit 2.5 oder 3.3V gespiesen ist? Bradward B. schrieb: > Für die IO-Constraints könnte man ja mal einen Blick auf das Blockbild > einer IO-Zelle werfen, Danke! Ein Paar Fragen dazu: Input: 1. Wie kann damit ein Schmitttrigger verhalten gemacht werden (ist auswählbar) 2. Wie kann TTL Logiklevel oder CMOS gewählt werden? I/O: 3. Wieso ist eine Wählbare PCI Diode gegen VCCIO (wie wählen?) und keine Diode gegen GND? Output: 4. Wie können gem Blockschaltbild LVDS Pegel generiert werden? 5. Gem. Blockschaldbild sind die einzigen Parameter: Slewrate, Opendrain, Drivestrenght, Pullup, PCI Diode und irgend ein Bushold (ist die für Schmitt?). Mit diesen Parametern kann bei weitem nicht der volle Einstellbereich im Pinplaner abgedeckt werden?!?
Max M. schrieb: > Weshalb benötigt > Quartus die Info ob die I/O Bank mit 2.5 oder 3.3V gespiesen ist? Fürs Timing.
Max M. schrieb: > Ein Paar Fragen dazu: > Input: > 2. Wie kann TTL Logiklevel oder CMOS gewählt werden? TTL also 5 V gibt es nicht und CMOS geht mit LVCMOS33. > I/O: > 3. Wieso ist eine Wählbare PCI Diode gegen VCCIO (wie wählen?) und keine > Diode gegen GND? Hersteller fragen. > Output: > 4. Wie können gem Blockschaltbild LVDS Pegel generiert werden? Der LVDS Pegel entsteht durch die Terminierung. Erstmal ist das nur eine Stromquelle/senke. > 5. Gem. Blockschaldbild sind die einzigen Parameter: Slewrate, > Opendrain, Drivestrenght, Pullup, PCI Diode und irgend ein Bushold (ist > die für Schmitt?). > Mit diesen Parametern kann bei weitem nicht der volle Einstellbereich im > Pinplaner abgedeckt werden?!? Das Schaltbild oben zeigt die IO Zelle vom MAX 10. Das ist ein sehr minimalistisches FPGA. Gut möglich, dass der Pinplanner alles anbietet was die Vereinigungsmenge aller FPGAs von Intel kann. Ob das dann funktioniert sagt die Synthese.
Max M. schrieb: > Aber dann erkläre mir bitte > weshalb man den I/O pegel im Quartus wählen kann???, wenn die I/O pegel > extern vorgegeben werden durch die Bank Speisung. Weil das Tool das wissen muss, um a) das Pinout automatisch oder halbautomatisch herstellen zu können und b) es prüfen zu können. Zudem gibt es innerhalb einer Spannungsdefinition unzählige Treiberkonfigurationen z.B. eben CMOS und TTL, die mit derselben Spannung arbeiten, aber andere Pegel und auch anderes Verhalten haben. Umsomehr gilt das bei z.B. LVDS und HSTL. Ferner kommen manche Pins nur als Paar vor und müssen entsprechend verschaltet werden, was dann bei Takttreibern wieder Auswirkungen auf das Routing hat. Letztlich geht es hier auch um die Verifikation des eingestellten Standards sowie um timing-Simulation und Check der Implementierung.
:
Bearbeitet durch User
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.