Servus allerseits Seit Jahren vertreibe ich ein Geraet in kleiner Stückzahl. Es checkt Kabelbaeume und zeigt an, wo ein eventueller Fehler vorhanden ist. In der ersten Version kontrollierte ein STM32F407 mehrere I/O Boards via SPI. Weil es mir nicht gelang, die SPI frei von Störungen zu halten, musste ich die Geschwindigkeit ziemlich drosseln. Was sich natürlich sehr negativ auf die gesamte Test-Laufzeit auswirkte. In der zweiten Version verpasste ich jedem Board eine STM32F103, die via SPI die I/Os auf ihren Boards kontrollierten und via USART/RS485 mit dem Master STM32F407 kommunizierten. Bis zu 3 Boards (zu je 128 I/O) war die Gesamtlaufzeit akzeptabel. Aber bei 4 Boards war's vorbei mit lustig. Nun muss ich für einen Kunden ein Geraet mit 1.024 Verbindungen herstellen. Diesmal ohne Schnick-Schnack wie variable Ausgangsspannung, analoge Messerfassung usw. usf. Weiss aber nicht so recht, wie ich das anpacken soll. Mein erster Gedanke war, jedes Board mit einem 32bit-Bus mit dem Master zu verbinden, wobei jedes Board für 64 I/Os zustaendig ist. Der erste Entwurf steht: aber viel zu viele 74HCxxx. Das alles zu routen wird alles andere als einfach sein. Weshalb ich mir überlege, ob ich nicht gleich jedem Board eine 144pin CPU verpassen soll, um mich von all diesen Logik-Bausteinen zu befreien. Nun kam mir die Idee das Ganze mit FPGAs zu lösen; von denen ich aber z.Zt. nicht viel verstehe. Bin aber lernfaehig :) Was ich braeuchte: - 32-bit I/O tri-state faehig (Bus) - 12-bit Inputs für Adress- und Steuer-Signale - 64-bit I/O mit min. 10mA Ausgangstrom - kein BGA Nice to have: - interner Flash - read-out protection - wenn ich jeden dieser 64 I/O intern an einen A/D-Converter umleiten könnte. 2 Fragen: - Kann man dieses Vorhaben mit FPGA lösen? Wenn ja: irgendwelche konkreten Vorschlaege für eine FPGA? - (Vielleicht eine etwas blöde, nebulöse Frage) Wie gross waere der Mehrgewinn, das Ganze mit FPGA zu lösen (und nicht mit MCU oder Logik-Bausteinen)?
Latticesemi: MachXO2, was sonst? LCMXO2-1200-HC.... im TQFP144 sollte alles machen, was du brauchst (ja, einer alleine reicht nicht, aber einer pro Lp) > - (Vielleicht eine etwas blöde, nebulöse Frage) Wie gross waere der > Mehrgewinn, das Ganze mit FPGA zu lösen (und nicht mit MCU oder > Logik-Bausteinen)? Das ist keine nebulöse Frage, sondern die einzig richtige Strategie. MCU und Logik war gestern.
Mehmet K. schrieb: > Was ich braeuchte: > - 32-bit I/O tri-state faehig (Bus) > - 12-bit Inputs für Adress- und Steuer-Signale Wieso ein 32 Bit Bus für nur 64 IO? Ich würde da eher auf eine parallele SPI Schnittstelle gehen, so wie bei SD Karten auch verwendet wird. > Nice to have: - interner Flash > - read-out protection MachXO2 > - wenn ich jeden dieser 64 I/O intern an einen A/D-Converter umleiten > könnte. Solche FPGA gibt es nicht. > Weil es mir nicht gelang, die SPI frei von Störungen zu halten Warum nicht? Und was für Störungen? SPI ist eigentlich extrem gutmütig, wenn man den richtigen SPI Mode nimmt und den Takt sauber terminiert hat.
Lothar M. schrieb: > Wieso ein 32 Bit Bus für nur 64 IO? Weil es ja 16 boards sind mit je 64 I/Os. Lothar M. schrieb: > Solche FPGA gibt es nicht. Schade. Lothar M. schrieb: > Und was für Störungen? Die Termininierung habe ich nicht hingekriegt. Und weil mir die Zeit davonlief, war es einfacher, die Geschweindigkeit herabzusetzen. Auch liefen 3 SPIs parallel und hin und wieder kam es zu Uebersprechungen. Kurzum: ein Fiasko. Lothar M. schrieb: > Ich würde da eher auf eine parallele SPI Schnittstelle gehen, so wie bei > SD Karten auch verwendet wird. Wegen meinen alptraumartigen Erfahrungen, die ich mit SPI in Eigenbau hatte, versuche ich SPI nicht mehr in Eigenregie aufzusetzen.
Ein SPI ist ja nun kein Hexenwerk. Und es ist sicher einfacher, 4 Signale störungsfrei über eine Leitung zu bringen als 44. Denn ein paralleler Bus hat die selbe Physik...
Bei 1.024 Verbindungen macht es schon einen Unterschied, ob ich mit 32bit oder 4bit arbeite. Um auch Dioden zu erkennen, muss ich jeden einzelnen IO auf Ausgang schalten und alle anderen einlesen. Und selbst bei der lausigsten Terminierung: eine kurze Pause um den Bus-State zu beruhigen, wird die Gesamt-Testlaufzeit auch nicht in einen nicht-akzeptablen Bereich verschieben. Nicht so aber bei 4bit. Okay, bei FPGA haette ich jetzt die Freiheit auf Nummer Sicher gehend das Ganze als 32bit zu entwerfen, um dann mal zu testen, ob ich es auch mit 4bit hinkriege. Aber diesbezüglich ist mein Selbstvertrauen ziemlich rampuniert :)
:
Bearbeitet durch User
Mehmet K. schrieb: > Um auch Dioden zu erkennen, muss ich jeden einzelnen IO auf Ausgang > schalten und alle anderen einlesen. Wieviel Zeit braucht so eine Messung mindestens? Oder andersrum: wie schnell möchtest du da durchschalten?
Ich würde an deiner Stelle entweder 16 Module mit uC in Serie laufen lassen oder 4 Module (a 256 Ports) mit uC die dann aber auch jeweils 4 Onboard SPI Busse (a 64 Ports) haben. Je nach Leitungslänge und Störumfeld kann es auch Sinn machen RS485 Treiber und Empfänger in den Bus zwischen den einzelnen Teilnehmern zu schalten. Schönes Bild un kleine Erlöärung zu der RS485-SPI Kombination: http://www.deathbylogic.com/2014/10/spi-over-long-distances/ Wieviele bits brauchst du pro Ausgang? mit 1/0/Tri sind 2 Bit notwendig. Wenn du dann noch pro 128 bit eine 16 Bit Prüfsumme mitlieferst pro Ausgangsmodul wärst du bei 2304 Bit pro Testmuster. Bei 512 Kbit/s hast du dann unter 5 ms pro Muster Übertragungsdauer. Und wärend das eine Muster noch getestet wird, kannst du das nächste schon übertragen. Mit gutem Timing schaffst du dann deine 200 Muster pro Sekunde. Eine Andere Idee wäre es vom Master nur die Ports zu Übertragen die sich ändern und das wieder mit Checksumme und Bestätigung. Dann brauchst du nur noch wenige Bits pro Testmuster. Oder deine Module haben gleich das Testmuster lokal gespeichert und der Master gibt nur noch an welches Muster geprüft werden soll. Und die Module sagen nur noch OK oder Fehler. Dann weiß der Master auch was Sache ist. eine Übersicht zu guten Checksummen findest du hier: https://users.ece.cmu.edu/~koopman/pubs/KoopmanCRCWebinar9May2012.pdf
Lothar M. schrieb: > Wieviel Zeit braucht so eine Messung mindestens? Oder andersrum: wie > schnell möchtest du da durchschalten? Bei den Geraeten mit einer eignenen MCU auf jedem Board (je 128pins), komme ich bei 3 x 128 pins auf eine Gesamtdauer von ca. 5 - 6 Sekunden. Diese Zeitspanne wird, da meist eine grosse Anzahl von Kabelbaeumen getesten werden muss, als zu lang empfunden. Mein Ziel ist es, bei 1.024 Verbindungen das Ergebnis nach spaetestens 10 Sekunden auszugeben.
Dennis R. schrieb: > Ich würde an deiner Stelle ... Wie ich oben schon festhielt: Die Lösung, jedem Board eine MCU zu verpassen, ist die eine Option, die ich auch beherrschen würde. Aber: mit dieser Lösung wird es zu unnötigen Verzögerungen kommen. Denn die MCU muss ja erst den Befehl auf seinem Bus erkennen, in die entsprechende Funktion springen usw. usf. Auch ist bei dieser Art der Aufgaben-Teilung der Master sich nie sicher, was an seiner Peripherie gerade ablaeuft. FPGA ist für diese Aufgabe schon die idealere Lösung. Fragt sich nur, ob ich diesen Brocken auf die Schnelle verdauen werden kann.
Göpel Electronic hat sowas fertig im Angebot, die arbeiten hauptsächlich mit JTAG. Wir nutzen das zum Leiterplatten Test, das Ding testet selbst mit wenigen MHz JTAG Frequenz ein paar Tausend Verbindungen zwischen FPGAs in wenigen Sekunden durch. Man muss natürlich auch die Pattern intelligent wählen.
Christian R. schrieb: > die arbeiten hauptsächlich mit JTAG. Und JTAG ist von der Physik her nichts Anderes als SPI: 4 Kupferleitungen, auf denen seriell die Daten unterwegs sind. Die Bilder ähneln sich dementsprechend sehr: https://upload.wikimedia.org/wikipedia/commons/c/c9/Jtag_chain.svg https://upload.wikimedia.org/wikipedia/commons/9/97/SPI_three_slaves_daisy_chained.svg Mehmet K. schrieb: > Mein Ziel ist es, bei 1.024 Verbindungen das Ergebnis nach spaetestens > 10 Sekunden auszugeben. Wieviele verschiedene (Einzel-)Testmuster musst du dafür anlegen und abprüfen? Welche räumlichen Dimensionen hat das Gerät?
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Und JTAG ist von der Physik her nichts Anderes als SPI: 4 > Kupferleitungen, auf denen seriell die Daten unterwegs sind. Die Bilder > ähneln sich dementsprechend sehr: Das ist mir klar. Ich habs nur eingeworfen um zu verdeutlichen dass es zwischen den Modulen höchstwahrscheinlich keinen Parallelbus braucht.
Christian R. schrieb: > Das ist mir klar. Ist mir klar, dass es dir klar ist. Deshalb auch das "Und" quasi als Weiterführung deines Gedankens... ;-)
Lothar M. schrieb: > Wieviele verschiedene (Einzel-)Testmuster musst du dafür anlegen und > abprüfen? Ich arbeite nicht mit pass/fail, sondern gebe auch stets an, wo der Fehler ist. > Welche räumlichen Dimensionen hat das Gerät? Ca. 30x25x30cm Hinten am Geraet sind jeweils die 6 DIN41612 Konnektoren (2x32pin). Diese werden an einen für den jeweiligen Kabelbaum angepassten Adapter angeschlossen. Die Laenge der getesteten Kabel variert sehr stark: von 50cm bis 20m. Ich werde mal den Tipp vom Bürovorsteher mir zu Herzen nehmen und den LCMXO2-1200 mir etwas genauer anschauen. Danke für all die Hinweise.
Dennis R. schrieb: > Oder deine Module haben gleich das Testmuster lokal gespeichert und der > Master gibt nur noch an welches Muster geprüft werden soll. Und die > Module sagen nur noch OK oder Fehler. Ich finde diese Lösung sehr elegant und sie erscheint mir gut umsetzbar. Natürlich musst Du die elektrischen Probleme der SPI-Übertragung in den Griff bekommen. Das musst Du bei einer FPGA-Lösung aber auch. Mehmet K. schrieb: > Wie ich oben schon festhielt: Die Lösung, jedem Board eine MCU zu > verpassen, ist die eine Option, die ich auch beherrschen würde. Aber: > mit dieser Lösung wird es zu unnötigen Verzögerungen kommen. Denn die > MCU muss ja erst den Befehl auf seinem Bus erkennen, in die > entsprechende Funktion springen usw. usf. Ist das wirklich der Flaschenhals? Sagen wir der Master sendet 2 Bytes per SPI, das reicht dann für 65535 verschiedene Muster. Das zu decodieren, das Muster zu laden etc. sollte ein µC schnell genug schaffen. > Auch ist bei dieser Art der Aufgaben-Teilung der Master sich nie sicher, > was an seiner Peripherie gerade ablaeuft. Der Master könnte danach jeden einzelnen µC nach dem Status befragen. Er bekommt dann wieder die Muster-Nummer plus z.B. ein Bit für OK oder nicht OK zurück. Durch das Auslesen der Muster-Nummer weiß der Master ganz sicher, daß der Slave-µC den Muster-Lade-Befehl richtig verstanden hat. Im Fall von einem Fehler kann der Master dann über einen anderen Befehl jedes einzelne Bit auslesen. Das ist natürlich langsamer, aber ich vermute mal daß der Fehlerfall nicht so zeitkritisch ist.
Mehmet K. schrieb: > Lothar M. schrieb: >> Wieviele verschiedene (Einzel-)Testmuster musst du dafür anlegen und >> abprüfen? > Ich arbeite nicht mit pass/fail, sondern gebe auch stets an, wo der > Fehler ist. Das war jetzt zwar schon eine Antwort, aber nicht die auf meine Frage(n). Zudem kannst du da evtl. zweistufig arbeiten: wenn bei den abgelegten Prüfmustern ein Fehler auftritt dann muss dieser Fehlerfall nochmal genauer geschaut werden. Mehmet K. schrieb: > Ich werde mal den Tipp vom Bürovorsteher mir zu Herzen nehmen und den > LCMXO2-1200 mir etwas genauer anschauen. Du solltest aber beachten, dass FPGAs prinzipiell eine andere Designstrategie als z.B. einfache Schieberegister oder CPLDs haben: du hast bei FPGAs einen internen Takt um die 100MHz und mit diesem tastest du dann deine Eingänge ab und berechnest du Ausgänge. Du wirst eigenartige Effekte erleben, wenn du z.B. ein FPGA direkt wie ein "dummes" 74573 Latch oder ein 74374 Flipflop ansteuern willst.
Moin, ich unterschreib mal MachXO2, mit dem MachXO2-Breakout-Board kann man prima komplexe Systemtests realisieren. Da passt auch der uC mit ins FPGA. Bei 1024 I/O würde ich allerdings anfangen, über sinnvolles Multiplexen nachzudenken.
@Mehmet Kendi (mkmk) >> Und was für Störungen? >Die Termininierung habe ich nicht hingekriegt. Und weil mir die Zeit Wenn das Bastler hinkriegen, dann schaffst du das auch. Beitrag "Re: Skurriles Problem mit BS170 Mosfets" >Wegen meinen alptraumartigen Erfahrungen, die ich mit SPI in Eigenbau >hatte, versuche ich SPI nicht mehr in Eigenregie aufzusetzen. Ein Trauma sollte man aktiv bewältigen und letztendlich überwinden und sich davon NICHT lebenslang verfolgen lassen.
@ Mehmet Kendi (mkmk) >Mein Ziel ist es, bei 1.024 Verbindungen das Ergebnis nach spaetestens >10 Sekunden auszugeben. Klingt machbar. Aber die Frage ist dabei, wieviele Bitoperationen dafür nötig sind. Wenn sich in der 1Kbit Kette immer nur ein Bit ändert, du dafür aber alle 1k neu laden musst, wäre das doof. Dito umgekehrt, wenn du immer nur wenige Bit auswerten musst, dafür aber alle lesen musst, wäre das auch doof. Aber nur solange, wie das zeitlich kritisch wird. Brute force ist zwar nicht elegant, reicht aber oft ;-) SPI schafft LOCKER 10 MBIT/s, da kann man 1kbit pro sekunde 10k mal lesen oder schreiben. Hmm. Reicht das?
Lothar M. schrieb: > Du wirst > eigenartige Effekte erleben, wenn du z.B. ein FPGA direkt wie ein > "dummes" 74573 Latch oder ein 74374 Flipflop ansteuern willst. Ich dachte, ich könnte dank FPGA auf alles was mit 74 beginnt verzichten: an den I/Os Schutzdioden und Widerstaende. Sonst nichts. Falsch gedacht?
Falk B. schrieb: > SPI schafft LOCKER 10 MBIT/s, da kann man 1kbit pro sekunde 10k mal > lesen oder schreiben. Hmm. Reicht das? Natürlich reicht das. Wenn! Wenn man SPI nicht vermasselt. Aber nach all den Buh-Rufen betreffend meinen SPI-Künsten werde ich das nochmals anpacken müssen. Das Projekt ist nicht dringend. Habe Zeit bis Ende Jahr.
> an den I/Os Schutzdioden und Widerstaende. Sonst nichts. Falsch gedacht?
Nun ja, im Prinzip schon, aber wenn das Gerät idiotensicher sein soll...
Ich würde zumindest noch kräftige Leitungstreiber spendieren.
Was denkst du, was meine Kunden schon alles kaputtbekommen haben.
Ich habe mal damit angefangen, im Datenblatt des MachX02 herumzustöbern. Falls ich mich nicht verguckt habe, scheinen seine Ausgaenge kurzschlussfest zu sein; haben aber nur so um die 5mA. Weshalb natürlich Leitungstreiben angebracht sind.
Signale breiten sich mit 15cm / nanosekunde aus bei eps_r=4. D.h. bei einem 4m langen Kabelbaum dauert es 26ns bis ein HIGH/LOW hinten das Erste Mal rauskommt. Bei Fehlen jeglicher Terminierung dauert es dann 100ns bis Reflexionen sicher abgeklungen sind. Die Reflexionen können heftig sein, ein temporär 2x größeres Ausgangssignal als man vorne reingesteckt hat wäre möglich ( 6.6V statt 3.3V). Ob es eine gute Idee ist Datenpakete reinzustecken und zu kucken ob sie hinten rauskommen: was ist wenn eine Ader gebrochen ist und die Signale durch reines Übersprechen es trotzdem schaffen durchzukommen?
@ Mehmet Kendi (mkmk) >Falls ich mich nicht verguckt habe, scheinen seine Ausgaenge >kurzschlussfest zu sein; haben aber nur so um die 5mA. >Weshalb natürlich Leitungstreiben angebracht sind. Wieso? Zum Durchklingeln eines Kabelbaums reicht das doch locker.
Frank F. schrieb: > Ob es eine gute Idee ist Datenpakete reinzustecken und zu kucken ob > sie hinten rauskommen: was ist wenn eine Ader gebrochen ist und die > Signale > durch reines Übersprechen es trotzdem schaffen durchzukommen? Solche Probleme wie Reflektionen, Ueberspannungen, fehlende Ader etc. habe ich im Griff. Aber trotzdem Danke für den Hinweis.
Lothar M. schrieb: > Wieviele verschiedene (Einzel-)Testmuster musst du dafür anlegen und > abprüfen? Sorry für die verspaetete Antwort. Ist schon 'ne Zeit her, seit ich mich mit dem Geraet intensiv beschaeftigt habe. Also ich "kann" nur 1 bit als Ausgang schalten und n-1 Eingaenge einlesen. Ich könnte zwar 1 bit als Ausgang schalten und 7 einlesen. Also bei 384 pins waeren dies max. 48 Ausgaenge und 336 Eingaenge. Aber das waere ein Mehr an SPI-Verkehr gewesen (habe es zumindest so im Kopf). Wegen meinem glücklichen Haendchen in Sachen SPI habe ich mir dies nicht angetan.
:
Bearbeitet durch User
Mehmet K. schrieb: > Ich dachte, ich könnte dank FPGA auf alles was mit 74 beginnt verzichte Es ist kein "verzichten können", sondern ein "verzichten müssen": du darfst nicht einfach ein Steuersignal als Latch oder Takt nehmen wie z.B. die steigende Flanke eines WR Signals. Sondern du baust einen Zustandsautomaten, der mit 100MHz läuft und für den erst mal alle externe Signale einsynchronisiert werden. Auf diese Art machst du quasi eine art Coprozessor. > Aber nach all den Buh-Rufen betreffend meinen SPI-Künsten werde ich > das nochmals anpacken müssen. So wie dort im Lauf des Threads entwickelt sieht z.B. ein SPI-Slave auf dem FPGA aus: Beitrag "Erfahrung mit SPI Slave und Spartan 6 FPGA?" Und dort finden sich ein paar Worte zur Terminnierung: Beitrag "Serienwiderstand bei Hochfrequenz" Beitrag "Signalproblem bei langem Kabel" > Habe Zeit bis Ende Jahr. Dann solltest du bald mit den ersten Spielereien auf dem FPGA anfangen. Und mein Vorschlag: nimm VHDL (dann bekommst du hier am ehesten Hilfe) und such hier im Forum nach "Postulate", dann findest du schon mal die üblichsten Anfängerprobleme... ;-)
Falk B. schrieb: > Wieso? Zum Durchklingeln eines Kabelbaums reicht das doch locker. Stimmt. Keine Ahnung wieso ich - als ich Obiges schrieb - der Meinung war, HC-Bausteine haetten mehr Power. Vermutlich gedanklich an ALS- oder AS-Bausteine abgeschweift.
@ Mehmet Kendi (mkmk) >> Wieso? Zum Durchklingeln eines Kabelbaums reicht das doch locker. >Stimmt. Keine Ahnung wieso ich - als ich Obiges schrieb - der Meinung >war, HC-Bausteine haetten mehr Power. Das haben sie schon, wenn gleich dann die Logikpegel ggf. nicht mehr ganz normgerecht sind.
> Stimmt. Keine Ahnung wieso ich - als ich Obiges schrieb - der Meinung > war, HC-Bausteine haetten mehr Power. Dein Kunde bekommt den FPGA garantiert durchgeheizt. Ein schnöder Treiber ist schneller gewechselt als der FPGA.
@Bernd G. (Firma: LWL flex SSI) (berndg) >Dein Kunde bekommt den FPGA garantiert durchgeheizt. Ein schnöder >Treiber ist schneller gewechselt als der FPGA. Die wahrscheinlichste Todesfalle ist ESD. Dagegen helfen Schutzdioden, die gibt es im 2, 4, 8er Pack. Und ein Längswiderstand als Angstwiderstand ist auch leicht platziert. Soooo einfach würde ich mir nicht Angst machen lassen.
Bernd G. schrieb: > Ein schnöder Treiber ist schneller gewechselt als der FPGA. Aber dann hat man wieder das Gelecke, dass man den Treiber umschalten muss zum Lesen. Wenn man direkt den FPGA-Pin verwendet, dann kann man sogar den Pegel des Ausgangs leicht zurücklesen und so evtl. aus diesem Pegel auch Erkenntnisse gewinnen.
Das ist natürlich auch richtig. Also vorsichtshalber ein paar Baugruppen mehr fertigen lassen, die der Kunde dann im Schadensfall gut bezahlen muss. Eine Reparatur macht ohnehin zuviel Aufwand.
@Lothar Danke für Deine Links im Beitrag Beitrag "Re: FPGA dazu geeignet?" Die Theorie in Sachen Terminierung, Wellenwiderstand etc. sind mir schon bekannt. Nur scheint es, dass die Umsetzung in die Praxis nicht so recht klappen mag. Was ich aber als heftig empfand war Dein erster Link: Beitrag "Erfahrung mit SPI Slave und Spartan 6 FPGA?" Waehrend der Lektüre musste ich des öfteren schlucken. Und insbesondere der Satz "Das war ja einfach..." im letzten Beitrag war echt demoralisierend. Ich werde mir jetzt das Eval-Board LCMX02-1200ZE-PE-EVN bestellen; aber angesichts Deines Satzes "Dann solltest du bald mit den ersten Spielereien auf dem FPGA anfangen." werde ich zweigleisig fahren und nicht alle meine Karten auf FPGA setzen.
Mehmet K. schrieb: > werde ich zweigleisig fahren und nicht alle meine Karten auf FPGA > setzen. Das halte ich für eine sinnvolle Strategie... ?
Habe mich nun doch dazu entschlossen, ins kalte Wasser zu springen und nur auf die FPGA-Karte zu setzen: wer nichts waget, darf nichts hoffen. Die ersten Gehversuche mit einem MachXO2 Development-Kit waren zwar echt gruselig - aber irgendwie ist diese FPGA-Welt doch sehr faszinierend. Ich habe nun für die LCMXO2-1200HC (TQFP-144) eine PCB entworfen, zu der ich eine Fragen haette. Gehe ich recht in der Annahme, dass wenn ich diese FPGA mit der JTAG-Schnittstelle ansprechen will, alle Pins als IO benutz werden können ausser: - JTAG (TDO, TDI, TCK TMS) - JTAGENB Anscheinend kann man die MachXO2 auch nur mit SPI und I2C ansprechen; aber in diesem Fall möchte ich doch mit der JTAG-Schnittstelle arbeiten. Anbei die Pinout-Liste (die auf der Lattice-Seite zu finden alles andere als einfach war). Dank im voraus.
:
Bearbeitet durch User
> Gehe ich recht in der Annahme, dass wenn ich diese FPGA mit der > JTAG-Schnittstelle ansprechen will, alle Pins als IO benutz werden > können ausser: > - JTAG (TDO, TDI, TCK TMS) > - JTAGENB Ja, völlig korrekt. Wenn du von außen einen Takt zuführen willst, musst du selbigen allerdings wirklich an einen Clock-Eingang legen, sonst winkt die Synthese ab :-( Ja, die Pinout-Liste ist wirklich saumäßig.
Wenn Du nur den JTAG Mode benutzt, kannst Du sogar den JTAGENB als IO pin nutzen. Per default wird der JTAG port genutzt. Erst wenn das abgeschaltet wird, kann mann mit dem JTAGENB pin zwischen verschieden Modi hin und her schalten. Datasheet: Use care when using JTAGENB to selectively enable and disable the JTAG port. Any external logic connected to the JTAG I/O must not contend with the JTAG programming port. ... The JTAG port is enabled by default when the MachXO2 is in the Feature Row HW Default Mode state. ... The JTAG port, when set in the DISABLE state, enables the JTAGENB input. JTAGENB permits the JTAG pins to be multiplexed. Asserting JTAGENB high causes the JTAG pins to take on the IEEE 1149.1 personality. De-asserting JTAGENB (i.e. driven low) causes the JTAG port pins to become general purpose I/O. Design the JTAG port circuitry carefully when taking advantage of JTAG port pin multiplexing. Avoid bus contention between logic attached to the JTAG port. Ich verzichte auf andere Modi und nutze ausschliesslich den JTAG Mode und den JTAGENB pin als IO Pin. Gruss Joerg
Man muss nicht unbedingt einen dedizierten Takteingang verwenden. Man muss nur Taktnetze verwenden. Auf die kommt man intern auch über Umwege. Und dann die Frage, was das mit dem Thema JTAG zu tun hat? Der besonders hat ja seinen eigenen Takt mit handgerierter Oszillaton.
OMg, danke für deine Klugscheißerei, es war nur ein Hinweis am Rande, weiter nichts.
Bürovorsteher schrieb: > Wenn du von außen einen Takt zuführen willst Verdammt! Den Clock habe ich doch tatsaechlich vergessen gehabt. Faengt ja gut an :) Danke für den Hinweis.
Mehmet K. schrieb: > Ich habe nun für die LCMXO2-1200HC (TQFP-144) eine PCB entworfen, zu der > ich eine Fragen haette. Es gibt bei Lattice eine 'MachXO2 Hardware Checklist' (Technical Note TN1208) [1]. Hast Du die schon mal durchgesehen? Duke [1] http://www.latticesemi.com/~/media/LatticeSemi/Documents/ApplicationNotes/MO/MachXO2HardwareChecklist.pdf?document_id=39095
Joerg Hagedorn schrieb: > Ich verzichte auf andere Modi und nutze ausschliesslich den JTAG Mode > und den JTAGENB pin als IO Pin. War mir schon aufgefallen, dass dieser Pin auf dem Dev-Board nicht benutzt wird. Wollte nur auf Numme sicher gehen. Danke für die Richtigstellung.
Bürovorsteher schrieb: > Wenn du von außen einen Takt zuführen willst, Irgendwie hatte ich im Hinterkopf, dass der MachXO2 dazu imstande ist, intern einen Clock zu erzeugen. Auf dem Dev-Board wird er zwar vom Takt des FTDI gespeist, aber im Datenblatt lese ich was von "Flexible On-Chip Clocking". Weltbester FPGA-Pongo schrieb im Beitrag #5018450: > Man muss nicht unbedingt einen dedizierten Takteingang verwenden. Kann ich also wie gehabt auf eine externe Taktquelle verzichten?
> Kann ich also wie gehabt auf eine externe Taktquelle verzichten? Du kannst drauf verzichten, ich kenne deine weiteren Intentionen nicht. Der interne Takt jittert und wandert, hält aber seine spezifizierte Taktrate recht gut ein. > Ich verzichte auf andere Modi und nutze ausschliesslich den JTAG Mode > und den JTAGENB pin als IO Pin. Wenn man ein Pin frei hat und den JTAGENB nicht zwangsweise als IO nutzen muss, ist es empfehlenswert, ihn trotzdem auf High zu legen. Damit vermeidet man, dass man sich als Anfänger (oder auch als selbsternannter Experte) durch Entfernen des JTAGENB-Häkchens irgendwann selbst aussperrt. Ist zwar behebbar, aber ärgerlich.
> Kann ich also wie gehabt auf eine externe Taktquelle verzichten?
Nachtrag: manches Eingangssignal entpuppt sich erst bei näherer
Betrachtung als Taktsignal und möchte als solches behandelt werden.
Duke Scarring schrieb: > Es gibt bei Lattice eine 'MachXO2 Hardware Checklist' (Technical Note > TN1208) [1]. Hast Du die schon mal durchgesehen? War mir bis anhin nicht bekannt: 2 Fehler weniger. Danke!
Bürovorsteher schrieb: > Du kannst drauf verzichten, ich kenne deine weiteren Intentionen nicht. > Der interne Takt jittert und wandert, hält aber seine spezifizierte > Taktrate recht gut ein. Ich beabsichtige anfaenglich alles mit kombinatorischer Logik zu erschlagen. Vermutlich werde ich nur 2 oder 3 Signale synchronisieren müssen. Erst wenn ich so das Geraet zum Laufen gebracht habe, werde ich versuchen Gebiete zu betreten, die etwas mehr Ruhm und Ehre versprechen :) Steht der interne Takt mit dieser (anfaenglicher) Intention im Einklang?
Bürovorsteher schrieb: > Nachtrag: manches Eingangssignal entpuppt sich erst bei näherer > Betrachtung als Taktsignal und möchte als solches behandelt werden. Nachtrag 2: die meisten Takte, die ein Anfänger in einem Design hat, sind eigentlich nur stinknormale einzusynchronisierende Eingangssignale...
:
Bearbeitet durch Moderator
> Nachtrag 2: die meisten Takte, die ein Anfänger in einem Design hat, > sind eigentlich nur stinknormale einzusynchronisietende > Eingangssignale... Nun ja, irgendjemand muss ja das letzte Wort haben :-) Dem Meister sei es gestattet.
> Steht der interne Takt mit dieser (anfaenglicher) Intention im Einklang?
Ja.
Vorsichtige Naturen sehen trotzdem einen Bestückungsplatz für einen
Oszillator vor.
Thread beobachten
Seitenaufteilung abschalten
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.