Liebe Leute, vorab gesagt - ich bin Anfaenger! Problem-Beschreibung: ich habe 2 dieser CPLD Dev-Boards https://www.openimpulse.com/blog/products-page/product-category/xc9572xl-xilinx-cpld-development-board/ zusammengeschaltet, und es kommt zu eigenartigen Effekten, die ich mir nicht recht erklaeren kann. Board 1 hat die Rolle eines Addressdekoders - eine 16 Bit-Addresse vom Z80 wird dekodiert, und 2 Ausgaenge des CPLDs zeigen an, ob es ein Read IORequest oder ein Write IORequest vom Z80 ist. Diese 2 Ausgaenge des Boards gehen dann in Board 2, das als eine Art Input-Output-Buffer arbeitet. Sobald es also READ oder WRITE vom 1. CPLD bekommt, tut es entweder ein zuvor gespeichertes / "gelatchtes" Byte auf den Z80 Datenbus, oder es speichert / "latched" das aktuelle Byte vom Z80 Datenbus. Soweit so gut. Nun, beide Boards haben einen 5V-Eingang fuer Steckernetzteile. Zunaechst hatte ich jedes Board mit eigenem Stecknetzteil versorgt, und nur GND der beiden Boards mit dem Z80 Ground verbunden, und das fuehrte zu den wildesten Problemen. U.a. habe ich mit den LEDs auf dem 2. Board die Input-Bytes angezeigt, und das fuehrte zu wildem Blinken der LEDs, selbst wenn gar kein IORequest vorlag! Dann dachte ich - nun, viellecht statt 2 Steckernetzteile fuer die DevBoards, einfach die 5V vom Z80-Computer nehmen, und 5V -> 3.3V Spannungswandler eingebaut, Kabel an die 3.3 V Input der beiden DevBoards, und GND, und natuerlich auch GND an den Z80, fertig. Das hat das wilde Blinken der Test/Debugging-LEDs beseitigt, und es funktionierte dann auch zu 90%. Allerdings kommt es immer noch zu eigenartigen Fehlern. Diese verbleibenden Fehler fuehren komischerweise auch dazu, dass die Power-LEDs der DevBoards flickern... und das verstehe ich ehrlich gesagt ueberhaupt nicht. Warum flickern die? Im Schaltplan zu den DevBoards https://www.openimpulse.com/blog/wp-content/uploads/wpsc/downloadables/XC9572XL-Schematic-Diagram.pdf sieht man, dass die nur zwischen GND und 3.3 liegen, also gar nichts mit einem CPLD IO Port zu tun haben. Wie koennen die flickern? Ist die Spannungsversorgung irgendwie instabil? Der Effekt tritt auch nur dann auf, wenn es tatsaechlich IORequests auf der richtigen Addresse gibt, wenn also der 2. CPLD angesprochen wird. Ansonstent flickeren die Power-LEDs der DevBoards nicht. Das Ganze haengt an einem Z80-Computer mit 2 A 5V Steckernetzteil; ich kann mir beim besten Willen nicht vorstellen, dass das unterdimensioniert ist. Es ist eigenartig! Kommt irgendjemand das Problem bekannt vor, oder hat Ideen zur weiteren Eingrenzung des Problems? Vielleicht sind diese DevBoards nicht wirklich dafuer gedacht, dass man sie so zusammenschaltet, und ihnen eine "selbstgestrickte" 3.3 V Spannung zukommen laesst? Ich habe uebrigens auch Siebkondensatoren hinter und vor dem Spannungswandler etc. Das machte keinen Unterschied im Verhalten. Danke und mfG Michael
Michael W. schrieb: > Wie koennen die flickern? Ist die Spannungsversorgung irgendwie instabil? Das ist die absolut einzige Möglichkeit, > und 5V -> 3.3V Spannungswandler eingebaut Was für einen und wozu? Die Boards haben doch eigene Spannungsregler. Zeig doch mal ein Foto, wie du das womit verdrahtet hast... Michael W. schrieb: > Der Effekt tritt auch nur dann auf, wenn es tatsaechlich IORequests auf > der richtigen Addresse gibt, wenn also der 2. CPLD angesprochen wird. > Ansonstent flickeren die Power-LEDs der DevBoards nicht. Evtl. hast du da einen Buskonflikt, der eine Baustein treibt high, der andere low und in der Summe wird der Regler überlastet.
Angehängte Dateien:
-
DSC06882.JPG
420 KB -
DSC06883.JPG
420 KB
Lothar M. schrieb: > Michael W. schrieb: >> Wie koennen die flickern? Ist die Spannungsversorgung irgendwie instabil? > Das ist die absolut einzige Möglichkeit, Aha. Ok, ich gucke mir das mal mit dem Oscilloscope an. >> und 5V -> 3.3V Spannungswandler eingebaut > Was für einen und wozu? Die Boards haben doch eigene Spannungsregler. Ja, aber wie gesagt, wenn ich entweder beide mit Steckernetzteil versorge, kommt es zu dem Problem dass das 2. Board "halluziniert" und meint, es wuerde Input vom 2. Board bekommen, obwohl auch die Logic Probe alles auf Low sieht... und mit einem Steckernetzteil, und dem 2. Board an 3.3 V PIN des ersten (sodass beide vom gleichen Steckernetzteil versorgt werden) ist dieses Problem behoben, allerdings flickert dann ebenfalls die Power LED. > Zeig doch mal ein Foto, wie du das womit verdrahtet hast... OK, ist aber wild! Anbei.
Lothar M. schrieb: > Michael W. schrieb: >> Der Effekt tritt auch nur dann auf, wenn es tatsaechlich IORequests auf >> der richtigen Addresse gibt, wenn also der 2. CPLD angesprochen wird. >> Ansonstent flickeren die Power-LEDs der DevBoards nicht. > Evtl. hast du da einen Buskonflikt, der eine Baustein treibt high, der > andere low und in der Summe wird der Regler überlastet. Interessant. Ja, der 1. CPLD ist nur kombinatorische Logic, der 2. hat 2 8Bit bidirektionale Busse, einen zum Z80, einem zum ATMega 644, die werden in den Tristate-Zustand versetzt je nachdem, ob READ, WRITE vom 1. CPLD, or WRITE2, READ2 vom ATMega 644 kommt. Der 2. CPLD (der simuliert sozusagen 2 74LS374 Flipflops, mit 2 Takt und 2 OE Eingaengen), hat always @(posedge <PIN>) (fuer <PIN>=READ/ WRITE/ READ2/ WRITE2). Zu den BIldern - der CPLD rechts im Bild, der den Spannungswandler in der Naehe hat, ist der Address-Dekoder. Der CPLD links ist der "Flipflop Emulator".
Michael W. schrieb: > PS Der Regulator ist ein 3.3V 950 mA LD1117V33, LD33V. Er bekommt 5 V > vom Z80. Genau solche Dinger sitzen doch eh auf den CPLD Boards. Werden die übrigens warm angesichts der Rückwärtsspeisung?
Lothar M. schrieb: > Michael W. schrieb: >> PS Der Regulator ist ein 3.3V 950 mA LD1117V33, LD33V. Er bekommt 5 V >> vom Z80. > Genau solche Dinger sitzen doch eh auf den CPLD Boards. Werden die > übrigens warm angesichts der Rückwärtsspeisung? Gute Frage, sind auf der Unterseite, muss ich mal nachschaeuen! Gerochen hab' ich nix :D Du meinst, die 3.3 V und GND Pins auf den CPLD Boards sind nur als Ausgaenge gedacht, und nicht, damit man mehrere "Zusammenketten" kann, mit nur einer Stromversorgung (denn dann waere ja mindestens 1 Regulator in diesem Sinne "rueckwaertsgespeist", wenn der Strom vom anderen Regulator kommt - in meinem Falle sind sogar beide rueckwaertsgespeist, ja). Ich habe auch gehoert, dass man nicht mehr als einen Spannugnsregler "parallel" haben kann, da die sonst evtl. oszillieren und sich "gegenseitig regulieren". Daher die Idee, beide Wandler zu umgehen, und sicherzustellen, dass beide CPLDs von einem Wandler gespeist werden, der extern ist.
PS Vielleicht sollte ich die BOards so manipulieren, dass ich die eingebauten Regler entferne, dann gibt es keine (potentiellen Probleme durch) RUeckwaertsspeisung mehr?
Den Regler auszubauen ist eine Möglichkeit, aber zwei Regler (bei Dir vlt. zwei verschiedene) parallel laufenzulassen sollte man nicht (es gibt Boards, bei denen lassen sich die Regler vom Rest trennen, ist hier aber nicht so). Ich hatte auch so ein Board, lief viele Jahre problemlos, bis ich es "überprogrammierte".
Michael W. schrieb: > Ich habe auch gehoert, dass man nicht mehr als einen Spannugnsregler > "parallel" haben kann, da die sonst evtl. oszillieren und sich > "gegenseitig regulieren". So lange du von den beiden erzeugten 3,3V nur die "Massen" miteinander verbindest, geht das völlig problemlos. Ich habe in meinen Designs locker mal 7 Spannungen (von 24V bis runter zu 0,8V) die nur die Masse gemeinsam haben. > Daher die Idee, beide Wandler zu umgehen, und sicherzustellen, dass beide > CPLDs von einem Wandler gespeist werden, der extern ist. Allerdings versetzt du damit eben die beiden schon verbauten Wandler in einen Zustand, der im Datenblatt so nicht vorgesehen ist: am eingang keine Spannung, aber am Ausgang schon...
Lothar M. schrieb: >> Ich habe auch gehoert, dass man nicht mehr als einen Spannugnsregler >> "parallel" haben kann, da die sonst evtl. oszillieren und sich >> "gegenseitig regulieren". > So lange du von den beiden erzeugten 3,3V nur die "Massen" miteinander > verbindest, geht das völlig problemlos. Ich habe in meinen Designs > locker mal 7 Spannungen (von 24V bis runter zu 0,8V) die nur die Masse > gemeinsam haben. Das hatte ich ja auch so gesehen / gemacht - in der 1. Version hatten beide DevBoards separates Steckernetzteil, und nur alle GNDs verbunden (auch mit Z80). Das führte dann allerdings dazu, dass das 2. CPLD der Meinung war, bei einem Low-Pegel vom 1. CPLD am Eingang irgendwelche Flanken zu erkennen, und das führte zum LED-Blinken von D2 - D5. Wie gesagt, die Logic Probe war der Meinung, dass das Signal vom 1. CLPD in den 2. CLPD eine konstante 0 / Low war... Das konnte ich mir nur damit erklären, dass die Spannungspegel vom 1. CLPD irgendwie nciht korrekt vom 2. CLPD interpretiert werden konnten. Da ein solches Signal zum "Latchen" eines Bytes vom Z80 Datenbus führt, und ich die Bytes (obere oder untere 4 Bit) mit den LEDs D2-D5 auf dem Board visualisiere, sah ich die die ganze Zeit wild blinken, obwohl keine Flanken getriggert wurden.Ich habe das oben mit "halluzinieren" des 2. CLPDs beschrieben. Es scheint also so zu sein, dass eben nicht nur die Massen miteinander verbunden werden, sondern "indirekt" über die "Pin-Verbindung" des Triggers vom 1. zum 2. CLPD auch die Spannungen ? Und das führt dann zum Oszillieren....
Lothar M. schrieb: >> Daher die Idee, beide Wandler zu umgehen, und sicherzustellen, dass beide >> CPLDs von einem Wandler gespeist werden, der extern ist. > Allerdings versetzt du damit eben die beiden schon verbauten Wandler in > einen Zustand, der im Datenblatt so nicht vorgesehen ist: am eingang > keine Spannung, aber am Ausgang schon... Ja, ich werde die Dinger einfach auslöten... hoffe, das behebt die Fehler, Vielen Dank an alle für die ganzen Tipps, echt super!
Michael W. schrieb: > Das hatte ich ja auch so gesehen / gemacht - in der 1. Version hatten > beide DevBoards separates Steckernetzteil, und nur alle GNDs verbunden > (auch mit Z80). Das führte dann allerdings dazu, dass das 2. CPLD der > Meinung war, bei einem Low-Pegel vom 1. CPLD am Eingang irgendwelche > Flanken zu erkennen Achtung, du liegst falsch! Es war nicht die Versorgung aus 2 Quellen, sondern der tolle Drahtverhau, der durch diese Doppelversorgung natürlich noch schlimmer war. Und weil du durch Entfernen der Netzteile den Drahtverhau etwas reduziert hast, "funktioniert" das Ganze "besser"... Das Geflacker der LEDs hat aber grundlegend andere Ursachen. Evtl. ist einer der Steckbrettkontakte ausgeleiert --> mal genauer nachmessen, denn deine LED ist ja auch nur ein "binäres Messinstrument" für die Versorgung. > Es scheint also so zu sein... Du hattest doch geschrieben, Zugriff auf ein Oszi zu haben. Miss damit mal verschiedene GND-Pegel deiner Schaltung gegeneinander. Ja, richtig: Masseklemme an Masse und den Tastkopf an die Masse eines anderen, entfernteren Bauteils. Was siehst du dann? Michael W. schrieb: > hoffe, das behebt die Fehler Ich würde da statt ausschließlich mit Hoffnung auch mal etwas systematischer vorgehen. Nur einen Fehler, dessen Ursache man kennt, kann man sinnvoll behandeln. Und du kennst die Ursache offenbar noch nicht.
Lothar M. schrieb: > Das Geflacker der LEDs hat aber grundlegend andere Ursachen. Die Ursache sollte doch schon längst geklärt sein, es ist das Parallelschalten der Regler. Den Rest kann man erst nach einem Blick in die Sources (HDL+Pin-Constraints) klären.
Sigi schrieb: > Die Ursache sollte doch schon längst geklärt sein, > es ist das Parallelschalten der Regler. Da ist doch nach meiner Interpretation derzeit gar nichts parallel geschaltet. Und wenn ich mir diesen vogelwilden Drahtverhau genauer anschaue, geht das alles über den einen Regler auf dem Steckbrett. Dem fehlen natürlich auch noch die Kondensatoren am Ein- und Ausgang, die im Datenblatt samt Kommentar zu finden sind:
1 | 8.2.1 |
2 | Design Requirements |
3 | The device component count is very minimal, employing two resistors as part |
4 | of a voltage divider circuit and an output capacitor for load regulation. |
5 | A 10-μF tantalum on the input is a suitable input capacitor for almost all applications. |
Michael W. schrieb: > Das hatte ich ja auch so gesehen / gemacht - in der 1. Version hatten > beide DevBoards separates Steckernetzteil, und nur alle GNDs verbunden > (auch mit Z80). Das führte dann allerdings dazu, dass das 2. CPLD der > Meinung war, bei einem Low-Pegel vom 1. CPLD am Eingang irgendwelche > Flanken zu erkennen, und das führte zum LED-Blinken von D2 - D5. Wie > gesagt, die Logic Probe war der Meinung, dass das Signal vom 1. CLPD in > den 2. CLPD eine konstante 0 / Low war... das klingt genau nach der sinnvollen Verbindung der Boards. Wenn das 2. CPLD-Board dabei irgendwelche Flanken zu erkennen glaubt, dann hat es vielleicht einfach recht. Dein 1. CPLD als kombinatorischer Adressdekoder kann Glitches liefern. Vielleicht reagiert dein zweites CPLD auf diese. Wenn deine Logik-Probe keine Glitches erkennt liegt es vielleicht nur daran, dass die Glitches für die Logik-Probe zu schmal sind (mit welcher Frequenz tastet die Logic-Probe ab)? Das zweite CPLD reagiert ggf. auf schmalere Glitches, die deine Logic-Probe übersieht.
Achim S. schrieb: > Michael W. schrieb: >> Das hatte ich ja auch so gesehen / gemacht - in der 1. Version hatten >> beide DevBoards separates Steckernetzteil, und nur alle GNDs verbunden >> (auch mit Z80). Das führte dann allerdings dazu, dass das 2. CPLD der >> Meinung war, bei einem Low-Pegel vom 1. CPLD am Eingang irgendwelche >> Flanken zu erkennen, und das führte zum LED-Blinken von D2 - D5. Wie >> gesagt, die Logic Probe war der Meinung, dass das Signal vom 1. CLPD in >> den 2. CLPD eine konstante 0 / Low war... > > das klingt genau nach der sinnvollen Verbindung der Boards. > > Wenn das 2. CPLD-Board dabei irgendwelche Flanken zu erkennen glaubt, > dann hat es vielleicht einfach recht. Dein 1. CPLD als kombinatorischer > Adressdekoder kann Glitches liefern. Vielleicht reagiert dein zweites > CPLD auf diese. > > Wenn deine Logik-Probe keine Glitches erkennt liegt es vielleicht nur > daran, dass die Glitches für die Logik-Probe zu schmal sind (mit welcher > Frequenz tastet die Logic-Probe ab)? Das zweite CPLD reagiert ggf. auf > schmalere Glitches, die deine Logic-Probe übersieht. Ich werde demnaechst mal mit dem Oskar nachsehen. Habe diese Logic Probe: https://www.amazon.com/Elenco-Electronics-LP-560-Logic-Probe/dp/B000Z9HAP4 Captures pulses to 25ns(20MHz) Unwahrscheinlich, da der Z80 mit 4 MhZ getaktet ist... wuesste nicht, was das schnellere Glitches verursachen koennte - aber vielleicht instabile Spannungsversorgung o.ae., ja. Nachgucken ist besser! Werde ich machen.
Lothar M. schrieb: > Und wenn ich mir diesen vogelwilden Drahtverhau genauer > anschaue, geht das alles über den einen Regler auf dem Steckbrett. Dem > fehlen natürlich auch noch die Kondensatoren am Ein- und Ausgang, die im > Datenblatt samt Kommentar zu finden sind: Ja, am Eingang habe ich allerdings einen Kondensator (ist schlecht zu sehen auf dem Bild, aber der ist zwischen GND und VCC vom Z80 oben), und ich hatte versuchsweise auch mal einen an den Ausgang gesteckt, hatte aber keine Auswirkungen auf Stabilitaet.
Lothar M. schrieb: > Michael W. schrieb: >> hoffe, das behebt die Fehler > Ich würde da statt ausschließlich mit Hoffnung auch mal etwas > systematischer vorgehen. Nur einen Fehler, dessen Ursache man kennt, > kann man sinnvoll behandeln. Und du kennst die Ursache offenbar noch > nicht. Ja, Hoffnung ist das falsche Wort... ich bin halt Anfaenger und habe verschiedene Arbeitshypothesen, die ich versuche durchzuarbeiten. Und mit Eurer Hilfe kann ich einige als wahrscheinlicher oder unwahrscheinlicher bewerten, was sehr hilfreich ist!
Der "Drahtverhau" wird nie zuverlaessig irgendwas dekodieren oder latchen. So langsam ist ein Z80 nicht, als das ein so "schlamperter" Aufbau stabil laufen wuerde. Dem Spannungsregler fehlen die Abblockkondis, die Leitungen zum Quarz sind zu lang, ... und die Massefuehrung ist ein Witz, da bunt und quer verteilt. Mit den ausgeloeteten Spannungsreglern wird es die CPLDs auch bald grillen. So wird das nuex...
Sigi schrieb: > Lothar M. schrieb: >> Das Geflacker der LEDs hat aber grundlegend andere Ursachen. > > Die Ursache sollte doch schon längst geklärt sein, > es ist das Parallelschalten der Regler. Den Rest > kann man erst nach einem Blick in die Sources > (HDL+Pin-Constraints) klären. Es ist meine derzeit favorisierte Hypothese. Ich kann die Verilog-Sourcen heute Abend mal posten.
--- schrieb: > Der "Drahtverhau" wird nie zuverlaessig irgendwas dekodieren > oder latchen. So langsam ist ein Z80 nicht, als das ein so > "schlamperter" Aufbau stabil laufen wuerde. Ich geben zu bedenken, dass aehnliche Drahtverhaue https://www.youtube.com/watch?v=GwAH3_dJs_I bereits bestens mit den beiden 74LS374 Flipflops und einem GAL22V10 funktioniert haben; diese Drahtverhaue sind auch nur Prototypen, die ich dann in PCBs ummuenze, s. z.B. hier fuer den vorherigen Drahtverhau: http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/new-'next-generation-speech-synthesizer'-for-the-cpc-464/80/ Aber es stimmt, das ist mein erstes CPLD-Projekt, und diese scheinen etwas empfindlicher zu sein als meine bisherigen Komponenten. Ich habe die Kabel und das Breadboard natuerlich auch unter Beobachtung / in Verdacht. Ich werde die CPLDs mal etwas besser zusammen bringen und die Leitungen kuerzen.
Angehängte Dateien:
-
DSC06876.JPG
310 KB
Michael W. schrieb: > bereits bestens mit den beiden 74LS374 Flipflops und einem GAL22V10 > funktioniert haben; diese Drahtverhaue sind auch nur Prototypen, die ich > dann in PCBs ummuenze, s. z.B. hier fuer den vorherigen Drahtverhau: Anbei mal die GAL22V10 + Flipflops basierte Version, die ebenfalls als Drahtverhau begann :-) Aber ich stimme voll und ganz zu dass ich den Aufbau aufraeumen und verbessern sollte, und kuerzere Leitungen! Allerdings glaube ich nicht, dass es das Problem loest. Der Sinn der ganzen CPLD-Uebung hier ist lediglich, zu sehen, ob ich die beiden Flipflops aus dem Design entfernen kann, und GAL22V10 + Flipflops in ein groesseres CPLD kombinieren kann. Da ich kein groesseres CPLD DevBoard finden konnte, muss ich hier leider fuer den Drahtverhau 2 kombinieren. Die sich dabei ergebenden Problem haette ich warhscinelich gar nicht, wenn ich ein groessers CPLD haette, das genuegend IOs haette. S. auch meine andere Frage nach dem DevBoard fuer einen groesseren CPLD.
--- schrieb: > Mit den ausgeloeteten Spannungsreglern wird es die CPLDs auch > bald grillen. Bratwurst oder Leberkaese? :D
Michael W. schrieb: > Ich habe die Kabel und das Breadboard natuerlich auch unter Beobachtung > / in Verdacht. Ich werde die CPLDs mal etwas besser zusammen bringen und > die Leitungen kuerzen. Wie ich ja Oben schon schrieb hatte ich dasselbe Board, dazu wie bei Dir eine Menge Dupont-Kabel. Beim Board gab's nie Probleme (korrekter Code und Pin-Alllokation vorausgesetzt), Probleme gibt's aber immer wieder bei den Dupont-Kabel (Online/China). Ab und an brechen Kabel und übertragen Signale nur sporadisch, für GND sollte man deshallb immer mehrere Adern/Kabel bzw. ein dickes Kabel/Draht nehmen.
Michael W. schrieb: > Ja, am Eingang habe ich allerdings einen Kondensator (ist schlecht zu > sehen auf dem Bild, aber der ist zwischen GND und VCC vom Z80 oben) Der Kondensator gehört nicht in Richtung E-Werk, sondern auf Millimeterabstand an den Regler... Michael W. schrieb: > und kuerzere Leitungen! Allerdings glaube ich nicht, dass es das Problem > loest. Aber es schadet mit Garantie nicht. Im Besonderen die Masse muss unbedingt stabil und verlässlich sein. Wie gesagt: GND gegen GND messen
Angehängte Dateien:
-
DSC06885.JPG
240 KB
OK, habe also die CPLD-Spannungsregler sauber entfernt / ausgelötet (ging einfach!), den externen Spannungsregler sauberer aufgebaut, die 3.3 V und GNDs sauber mit kurzen und doppelten Kabeln verbunden (die CPLD Boards haben dafür PINs in doppelter Ausführung, auf jeder "Seite"!), die Breadboard GND und 5V-Schienen ebenfalls "doppelt" verkabelt. Ergebnis - immer noch Flackern der Power-LEDs, und zwar von beiden CPLDs. Alle Kabel sind stramm und bombenfest, das Breadboard ist einwandfrei. Ich denke jetzt, es muss ein Bus-Konflikt sein, dass ich auf den Z80-Bus schreibe, wenn ich nicht schreiben sollte... und die CPLDs erkennen das irgendwie und regeln sofort runter. Das führt zum Flackern der Power-LEDs, und ich kann das auch im Lautsprecher des CPCs als "Knacksen" hören, wenn ich den Verstärker voll aufdrehe. Bratwurst oder Leberkäse vom CPLD-Grill gibt's leider noch nicht. Entgegen aller Erwartungen bleibt das alles sehr schön kühl :-)
Michael W. schrieb: > Ich kann die > Verilog-Sourcen heute Abend mal posten. Address-Dekoder:
1 | |
2 | module Main( |
3 | |
4 | i_IORQ, |
5 | i_RD, |
6 | i_WR, |
7 | |
8 | iADR, |
9 | |
10 | oSPEECH_WRITE, |
11 | oSPEECH_WRITE_ATMEGA, |
12 | oSPEECH_READ |
13 | |
14 | ); |
15 | |
16 | input [15:0] iADR; |
17 | input i_IORQ; |
18 | input i_RD; |
19 | input i_WR; |
20 | |
21 | output oSPEECH_WRITE; |
22 | output oSPEECH_WRITE_ATMEGA; |
23 | output oSPEECH_READ; |
24 | |
25 | wire iorq = ~ i_IORQ; |
26 | wire iord = ~ i_RD; |
27 | wire iowr = ~ i_WR; |
28 | |
29 | wire read = iorq & iord; |
30 | wire write = iorq & iowr; |
31 | |
32 | wire ssa_adr = iADR[15:0] == 16'hFBEE; |
33 | wire ls_adr = iADR[15:0] == 16'hFBEE; |
34 | |
35 | wire internal_read = ( ssa_adr | ls_adr ) & read; |
36 | wire internal_write = ( ssa_adr | ls_adr ) & write; |
37 | |
38 | wire oSPEECH_WRITE = internal_write; |
39 | wire oSPEECH_WRITE_ATMEGA = internal_write; |
40 | |
41 | wire oSPEECH_READ = internal_read; |
42 | |
43 | /* |
44 | always @(*) |
45 | begin |
46 | if (oSPEECH_WRITE) |
47 | sr_led <= 4'b0011; |
48 | else if (oSPEECH_READ) |
49 | sr_led <= 4'b1100; |
50 | else |
51 | sr_led <= 4'b1111; |
52 | end |
53 | */ |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | NET "i_IORQ" LOC = "p23" ; |
60 | NET "i_WR" LOC = "p22" ; |
61 | NET "i_RD" LOC = "p21" ; |
62 | |
63 | NET "iADR<0>" LOC = "p27" ; |
64 | NET "iADR<1>" LOC = "p28" ; |
65 | NET "iADR<2>" LOC = "p29" ; |
66 | NET "iADR<3>" LOC = "p30" ; |
67 | NET "iADR<4>" LOC = "p18" ; |
68 | NET "iADR<5>" LOC = "p16" ; |
69 | NET "iADR<6>" LOC = "p14" ; |
70 | NET "iADR<7>" LOC = "p13" ; |
71 | NET "iADR<8>" LOC = "p36" ; |
72 | NET "iADR<9>" LOC = "p37" ; |
73 | NET "iADR<10>" LOC = "p38" ; |
74 | NET "iADR<11>" LOC = "p39" ; |
75 | NET "iADR<12>" LOC = "p40" ; |
76 | NET "iADR<13>" LOC = "p41" ; |
77 | NET "iADR<14>" LOC = "p42" ; |
78 | NET "iADR<15>" LOC = "p43" ; |
79 | |
80 | NET "oSPEECH_READ" LOC = "p5" ; |
81 | NET "oSPEECH_WRITE" LOC = "p3" ; |
82 | NET "oSPEECH_WRITE_ATMEGA" LOC = "p2" ; |
83 | |
84 | endmodule |
FlipFlop-Emulator:
1 | |
2 | module Main( |
3 | |
4 | iDECODER_READ, |
5 | iDECODER_WRITE, |
6 | iCLOCK, |
7 | |
8 | ioCPC_DATA, |
9 | ioATMEGA_DATA, |
10 | |
11 | iREAD_LATCHED_CPC_DATA, |
12 | iLATCH_ATMEGA_DATA, |
13 | |
14 | oLED |
15 | |
16 | ); |
17 | |
18 | inout [7:0] ioCPC_DATA; |
19 | inout [7:0] ioATMEGA_DATA; |
20 | |
21 | input iDECODER_READ; |
22 | input iDECODER_WRITE; |
23 | input iCLOCK; |
24 | |
25 | input iREAD_LATCHED_CPC_DATA; |
26 | input iLATCH_ATMEGA_DATA; |
27 | |
28 | output [3:0] oLED; |
29 | |
30 | reg [3:0] sr_led = 4'b1111; |
31 | |
32 | reg [7:0] cpc_data_in = 0; |
33 | reg [7:0] atmega_data_in = 0; |
34 | |
35 | assign oLED = sr_led; |
36 | |
37 | assign ioCPC_DATA = iDECODER_READ ? atmega_data_in : 8'bz; |
38 | assign ioATMEGA_DATA = iREAD_LATCHED_CPC_DATA ? cpc_data_in : 8'bz; |
39 | |
40 | // when out &fbee, byte -> store in cpc_data |
41 | always @(posedge iDECODER_WRITE ) |
42 | begin |
43 | cpc_data_in <= ioCPC_DATA; |
44 | end |
45 | |
46 | always @(posedge iLATCH_ATMEGA_DATA) |
47 | begin |
48 | atmega_data_in <= ioATMEGA_DATA; |
49 | end |
50 | |
51 | endmodule |
52 | |
53 | |
54 | |
55 | NET "iDECODER_READ" LOC = "p18" ; |
56 | NET "iDECODER_WRITE" LOC = "p21" ; |
57 | NET "iCLOCK" LOC = "p19" ; |
58 | |
59 | NET "iREAD_LATCHED_CPC_DATA" LOC = "p22" ; |
60 | NET "iLATCH_ATMEGA_DATA" LOC = "p23" ; |
61 | |
62 | NET "ioCPC_DATA<0>" LOC = "p39" ; |
63 | NET "ioCPC_DATA<1>" LOC = "p38" ; |
64 | NET "ioCPC_DATA<2>" LOC = "p37" ; |
65 | NET "ioCPC_DATA<3>" LOC = "p36" ; |
66 | NET "ioCPC_DATA<4>" LOC = "p30" ; |
67 | NET "ioCPC_DATA<5>" LOC = "p29" ; |
68 | NET "ioCPC_DATA<6>" LOC = "p28" ; |
69 | NET "ioCPC_DATA<7>" LOC = "p27" ; |
70 | |
71 | |
72 | NET "ioATMEGA_DATA<0>" LOC = "p13" ; |
73 | NET "ioATMEGA_DATA<1>" LOC = "p12" ; |
74 | NET "ioATMEGA_DATA<2>" LOC = "p8" ; |
75 | NET "ioATMEGA_DATA<3>" LOC = "p7" ; |
76 | NET "ioATMEGA_DATA<4>" LOC = "p6" ; |
77 | NET "ioATMEGA_DATA<5>" LOC = "p5" ; |
78 | NET "ioATMEGA_DATA<6>" LOC = "p3" ; |
79 | NET "ioATMEGA_DATA<7>" LOC = "p2" ; |
80 | |
81 | |
82 | NET "oLED<0>" LOC = "p34" ; |
83 | NET "oLED<1>" LOC = "p33" ; |
84 | NET "oLED<2>" LOC = "p32" ; |
85 | NET "oLED<3>" LOC = "p31" ; |
I denke, es gibt noch ein Problem im Verilog-Code vom FlipFlop-Emulator... wie gesagt, Bus-Konflikt wahrscheinlich. Das ist mein 1. Verilog-"Programm".
Michael W. schrieb: > und die CPLDs erkennen das irgendwie und regeln sofort runter. Da "regelt" nichts, sondern der eine Busteilnehmer schaltet im Fehlerfall seine Bus-Pins nach Plus, der andere schaltet seine Pins nach Minus und es fließt dadurch mehr Strom, als der Spannungsregler abkann. Wird der eigentlich warm? > immer noch Flackern der Power-LEDs, und zwar von beiden CPLDs. Alles andere wäre überaus kurios. Denn die hängen ja beide an der selben Spannung. Aber wie gesagt: miss einfach mal mit dem Oszi mal entlang deiner Versorgungskette, wie diese Spannungseinbrüche aussehen, und ob die zusammen mit irgendeinem anderen Signal kommen...
Michael W. schrieb: > I denke, es gibt noch ein Problem im Verilog-Code vom > FlipFlop-Emulator... wie gesagt, Bus-Konflikt wahrscheinlich. Was aber eigentlich unmöglich ist... der CPC / Z80-Datenbus wird also mit dem Inhalt von atmega_data_in Register "beschrieben", wenn iDECODER_READ high ist.
1 | assign ioCPC_DATA = iDECODER_READ ? atmega_data_in : 8'bz; |
Sonst ist der ioCPC_DATA "inout" Bus im Tristate mode (8'bz). Einen Konflikt könnte es nur geben, wenn das iDECODER_READ "zu spät oder zu träge" kommen würde, wenn also der IOREQ & IORD from Z80 schon "vorbei" wäre. Das würde den Bus jammen. S. Address-Dekoder:
1 | wire iorq = ~ i_IORQ; |
2 | wire iord = ~ i_RD; |
3 | wire iowr = ~ i_WR; |
4 | |
5 | wire read = iorq & iord; |
6 | wire write = iorq & iowr; |
7 | |
8 | wire ssa_adr = iADR[15:0] == 16'hFBEE; |
9 | wire ls_adr = iADR[15:0] == 16'hFBEE; |
10 | |
11 | wire internal_read = ( ssa_adr | ls_adr ) & read; |
12 | wire internal_write = ( ssa_adr | ls_adr ) & write; |
13 | |
14 | wire oSPEECH_WRITE = internal_write; |
15 | wire oSPEECH_WRITE_ATMEGA = internal_write; |
16 | |
17 | wire oSPEECH_READ = internal_read; |
oSPEECH_READ vom Address-Dekoder CPLD kommt als iDECODER_READ im FlipFlop-Emulator an. Da niemals gleichzeitig iord und iowr gelten kann vom Z80 aus, kann ich mir eigentlich keinen Reim darauf machen, warum das den Bus jammen könnte... sind die CPLDs wirklich so träge?
Lothar M. schrieb: > Michael W. schrieb: >> und die CPLDs erkennen das irgendwie und regeln sofort runter. > Da "regelt" nichts, sondern der eine Busteilnehmer schaltet im > Fehlerfall seine Bus-Pins nach Plus, der andere schaltet seine Pins nach > Minus und es fließt dadurch mehr Strom, als der Spannungsregler abkann. > Wird der eigentlich warm? Überhaupt nicht - Cool like a cucumber. >> immer noch Flackern der Power-LEDs, und zwar von beiden CPLDs. > Alles andere wäre überaus kurios. Denn die hängen ja beide an der selben > Spannung. > > Aber wie gesagt: miss einfach mal mit dem Oszi mal entlang deiner > Versorgungskette, wie diese Spannungseinbrüche aussehen, und ob die > zusammen mit irgendeinem anderen Signal kommen... OK. Mache ich. Oder evtl. habe ich einfach einen schlechten CPLD? Ich habe sicherheitshalber noch mal so ein Bord bestellt... dauert aber, bis es kommt.
Michael W. schrieb: >> Minus und es fließt dadurch mehr Strom, als der Spannungsregler abkann. Der Spannungswandler ist ja auch ein ziemlicher Oschi, verglichen mit den winzigen Dingern die ich ausgelötet habe...
Michael W. schrieb: > verglichen mit den winzigen Dingern die ich ausgelötet habe... Die waren allerdings auf einem FR4-Kühlkörper montiert. Michael W. schrieb: > Oder evtl. habe ich einfach einen schlechten CPLD? Rätst du noch oder misst du schon?
Lothar M. schrieb: > Rätst du noch oder misst du schon? OK, ich hatte meinen "Richard Feynman"-Moment (die Episode, wo er Radios repariert durch blosses Nachdenken... gemessen wurde da nix - nicht dass ich mich mit Feynman vergleich will... dafuer bin ich dann doch zu bescheiden ;-) ) Ich habe einmal den ATMega 644 aus dem Aufbau entfernt, und lediglich Adress-Dekoder CPLD und FlipFlop-Emulator CPLD laufen lassen. Dabei latched der Flipflop-Emulator nun das Byte vom CPC / Z80-Bus bei IOREQ & WRITE, und gibt es zurueck auf den Z80 / CPC Datenbus bei IOREQ & READ (natuerlich auf der dekodierten IO-Adresse ausschliesslich) - ein "Echo" sozusagen.
1 | |
2 | |
3 | assign ioCPC_DATA = iDECODER_READ ? atmega_data_in : 8'bz; |
4 | assign ioATMEGA_DATA = iREAD_LATCHED_CPC_DATA ? cpc_data_in : 8'bz; |
5 | |
6 | // when out &fbee, byte -> store in cpc_data |
7 | always @(posedge iDECODER_WRITE ) |
8 | begin |
9 | cpc_data_in <= ioCPC_DATA; |
10 | end |
11 | |
12 | // always @(posedge iLATCH_ATMEGA_DATA) |
13 | // Test without ATMega: |
14 | |
15 | always @(posedge iDECODER_READ ) |
16 | begin |
17 | atmega_data_in <= cpc_data_in; |
18 | end |
DAs ganze ist also einfach ein Echo. Dazu mein BASIC-Testprogramm:
1 | 10 a=round(rnd(1)*255) |
2 | 20 out &fbee,a |
3 | 30 b=inp(&fbee) |
4 | 40 if a<>b then print a;:print b |
5 | 50 goto 10 |
Das fuehrte bisher immer zum Flickern der Power-LEDs und Fehlern (wenn auch nur sporadisch, aber haeufig genug!) Zudem habe ich die Leitung "iDECODER_WRITE" zum ATMega 644 entfernt, da dieser ebenfalls darauf triggert (er muss ja wissen, wann es was zu tun gibt). Nun triggert er also nicht mehr. Ergebnis - nicht ein einziger Fehler in 30 Minuten, kein Flickern mehr, keine IO-Fehler / Byte-Differenzen im Echo! Laeuft bombenstabil. Es liegt also irgendwie an der Interaktion zwischen dem ATMega 644-Bus und dem CPLD. Ich werde mir die Signale mal mit dem Logic-Analyzer aufschluesseln / anschauen. Anscheinend gibt es da ein Sychronisationsproblem. Koennte es evtl. sein, dass die CPLD-Signalpegel nicht 100% kompatibel sind mit dem ATMega 644? Es hat also alles nichts mit Spannungswandlern, GND, Kabellaengen oder Wacklern zu tun. Reines ATMega / CPLD Bus- oder Synchronisationsproblem.
Michael W. schrieb: > Es hat also alles nichts mit Spannungswandlern, GND, Kabellaengen oder > Wacklern zu tun. Reines ATMega / CPLD Bus- oder Synchronisationsproblem. Weiss einer, was passiert, wenn sowohl ATMega pins auf INPUT geschaltet sind, und CPLD im Tristate-Modus ist? Ist das eine problematische Kombination? Tristate fuer den ATmega gibt es ja leider nicht...
Michael W. schrieb: > Koennte es evtl. sein, dass die CPLD-Signalpegel nicht 100% kompatibel > sind mit dem ATMega 644? Das steht im Datenblatt und ich kann es bestätigen: sie sind es, das CPLD ist 5V tolerant. Ist eigentlich noch immer Ratestunde? > Das fuehrte bisher immer zum Flickern der Power-LEDs Dann hast du ja eine tolle Möglichkeit, endlich mal zu messen. Ein Tipp, wenn du auch ohne Messen weiter herumbasteln willst: mach mal in den Bus zwischen die beteiligten Komponenten Widerstände rein. 100 Ohm dürften genügen. Dann kommt ein Buskonflikt nicht mehr so hart durch, sondern wird durch die Widerstände abgeschwächt. Und dann könntest du auch links und rechts der Widerstände messen, was da auf dem Bus los ist. Aber was sage ich: schon wieder "messen"... Michael W. schrieb: > Feynman ... die Episode, wo er Radios repariert durch blosses Nachdenken... > gemessen wurde da nix Ist das in der Nähe der Passage, wo er schreibt: "Ich kaufte mir ein Milliamperemeter und verwandelte es in ein Voltmeter mit verschiedenen Skalen..."? Und noch eins zum Thema "Urban Legends": Einstein war nicht schlecht in Mathe... ;-)
Lothar M. schrieb: >> Das fuehrte bisher immer zum Flickern der Power-LEDs > Dann hast du ja eine tolle Möglichkeit, endlich mal zu messen. > > Ein Tipp, wenn du auch ohne Messen weiter herumbasteln willst: Mal eine Frage - was soll durch das Messen denn eigentlich herausgefunden werden? Ist es nicht sinnvoller, einen evtl. Buskonflikt durch Beobachtung mit einem Logic Analyzer zu analysieren und sich die ATMega Software anzusehen, ob diese evtl. Synchronisationsprobleme hat? Das es ein elektrisches Problem gibt, weiss ich doch schon. Inwiefern hilft mir Deine Messerei denn beim Beheben des Problemes, bekomme ich daduch auch nur ein BIt an Information, dass ich nicht ohnehin schon habe? Evtl. fehlt mir da Deine Denke bzw. ich verstehe das nicht ganz. > in den Bus zwischen die beteiligten Komponenten Widerstände rein. 100 > Ohm dürften genügen. Dann kommt ein Buskonflikt nicht mehr so hart > durch, sondern wird durch die Widerstände abgeschwächt. > > Und dann könntest du auch links und rechts der Widerstände messen, was > da auf dem Bus los ist. Aber was sage ich: schon wieder "messen"... Das (Widerstaende) ist ein guter Tipp - allerdings wuerde ich da eher den Logic-Analyzer nehmen. > Michael W. schrieb: >> Feynman ... die Episode, wo er Radios repariert durch blosses Nachdenken... >> gemessen wurde da nix > Ist das in der Nähe der Passage, wo er schreibt: "Ich kaufte mir ein > Milliamperemeter und verwandelte es in ein Voltmeter mit verschiedenen > Skalen..."? Nein, das ist die Episode, wo er durch Nachdenken darauf gekommen ist, dass die Roehre vom Vorverstaerker zu langsam aufheizt, und dass der Hauptversaerker schon warm war und Rauschen verstaerkte, und er hat die Roehren einfach getauscht. Ich bezweifele ja nicht den Sinn des Messens... aber Messen kann vernuenftige Arbeitshypothesen und Plausibilitaets-Checks durch Nachdenken doch nicht ersetzen. Und es scheint mir hier keine Information zu liefern, die ich nicht schon habe. Logic Analyzer erscheint mir sinnvoller? Sorry ich will ja nicht schwierig sein, ich will nur verstehen wie ihr "Elektronik-Genies" so denkt und solche Fehler analysiert. Ich bin ja sehr dankbar fuer die Hilfestellung hier!
Lothar M. schrieb: > Und noch eins zum Thema "Urban Legends": Einstein war nicht schlecht in > Mathe... ;-) Oh, das beruhigt mich jetzt, ich war eigentlich ganz gut in Mathe :D
Michael W. schrieb: > Mal eine Frage - was soll durch das Messen denn eigentlich > herausgefunden werden? Ob die Ursache solche Buskonflikte sind. Denn es ist eben nicht normal, dass durch eine Software die Versorgung zusammenbricht. > Ist es nicht sinnvoller, einen evtl. Buskonflikt > durch Beobachtung mit einem Logic Analyzer zu analysieren und sich die > ATMega Software anzusehen, ob diese evtl. Synchronisationsprobleme hat? Nein. Nicht bevor man nicht sichergestellt hat, dass es eben kein Buskonflikt ist. Denn so ein LA zeichnet ein überaus binäres Bild seiner Umwelt. Der taugt bestenfalls, später irgendwelche Protokoll- oder Timingfehler aufzudecken. > Ich bezweifele ja nicht den Sinn des Messens... aber Messen kann > vernuenftige Arbeitshypothesen und Plausibilitaets-Checks durch > Nachdenken doch nicht ersetzen. Vernünftige Annahmen kann man nur auf sinnvollen Abbildern der Physik machen. Und dafür muss man messen. Wenn es auch ohne Messung ginge, warum gibt es dann Firmen, die solche Geräte bauen und davon leben können? > allerdings wuerde ich da eher den Logic-Analyzer nehmen. Durch die Widerstände geht das sogar wieder, weil du dann siehst, ob rechts und links unterschiedliche Pegel hast. Ich nehme für solche Fälle einfach ein Oszilloskop und einen Tastkopf und sehe mir dei Datenleitungen an. Wenn da neben high und low auch noch ab&zu ein "Zwischending" auftritt, dann habe ich Buskonflikte. Und das kann ein LA eben nicht darstellen. > Nein, das ist die Episode, wo er durch Nachdenken darauf gekommen ist, > dass die Roehre vom Vorverstaerker zu langsam aufheizt, und dass der > Hauptversaerker schon warm war und Rauschen verstaerkte, und er hat die > Roehren einfach getauscht. Ja, die kenne ich auch. Und da hat er eben den Fehler nicht durch "Nachdenken" herausgefunden, sondern durch 70% "Glück" und 30% "Herumbasteln". Aber über dieses Stadium bist du bei deiner Schaltung schon lange weg. Denn "Herumgebastelt" hast du ja unnötigerweise schon. Ich auf jeden Fall bin mir sicher, dass ich mit meiner Vorgehensweise die Ursache des Fehlers schon gefunden hätte. Das war schon ein paar mal der Fall... ;-)
Lothar M. schrieb: > Michael W. schrieb: >> Mal eine Frage - was soll durch das Messen denn eigentlich >> herausgefunden werden? > Ob die Ursache solche Buskonflikte sind. Denn es ist eben nicht > normal, dass durch eine Software die Versorgung zusammenbricht. OK, das verstehe ich! Wuesste zwar nicht, was es sonst sein koennte... ja, ich werde das ueber Wochenede mal machen und dann hier posten. Danke fuer diese Erlaeuterungen, sehr hilfreich!
Danke nochmal an alle, die geholfen haben. Es funktioniert jetzt. I habe den bidirektionalen 8bit breiten IO-Bus zwischen CPLD und ATMega 644 in 2 getrennte input / output Busse aufgesplittet. Das macht die Synchronisation ueberfluessig, und die Software auf dem ATMega einfacher. Zudem hatte ich einen daemlichen Programmierfehler - ich habe auf ATMega-Seite in meinem "Echo-Testprogramm" fuer den Kommunikationstest doch tatsaechlich die Pins mittels "PIND = output" "beschrieben", statt korrekterweise "PORTD = output" zu nehmen! Also kein Wunder, dass es zu Bus-Konflikten kam und es nicht funktionierte... Da hatte ich das Breadboard aber schon auf getrennte Busse geaendert, als ich das bemerkte, insofern weiss ich nicht, ob ausschliesslich dieser Programmierfehler fuer das Flickern der Power-LEDs / den Buskonflikt verantwortlich war. Nun, getrennte Input/Output-Busse ist ohnehin die sauberere Loesung IMHO. Kein Flickern mehr, und keine Uebertragungs- / Synchronisations-Probleme mehr. Und - ich hatte tatseachlich auch ein defektes Kabel!! Und einen umgebogenen Pin am ATMega... einen Wackler auf Datenbus-Seite. Die Augen werden halt doch etwas schlechter mit zunehmenden Alter. All diese kleinen Problemchen summieren sich, und machen die Fehlersuche / das Prototyping mit Breadboards manchmal etwas frickelig. Nun, davon lassen sich Bastel-Freunde wie ich einer bin nicht entmutigen ;-) Also, es funktioniert jetzt alles, nochmals vielen Dank fuer die Anregungen, Gruss, Michael
Angehängte Dateien:
So sieht der Drahtverhau jetzt aus. Funktioniert einwandfrei.
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.