Hi, ich möchte mit einer Zustandsmaschine sowohl auf die steigende als auch auf die fallende Flanke eines Taktsignals (ca. 7 MHz) reagieren. Die Flipflops reagieren ja immer nur auf eine der beiden Flanken. Ich verwende einen Xilinx XC9572XL mit ISE14.7. Hintergrund: ich möchte für eine 68000 Motorola CPU die S-States mitzählen um das Bustiming für DTACK und andere Signale zu machen, ausgehend von der fallenden Flanke von /AS. Gibt es dafür eine gute Lösung die ohne zusätzlichen externen Takt auskommt? Prinzipiell würde ich ja einen doppelt so schnellen Takt benötigen, d.h. einen 14 MHz Takt. Beim nächsten Layout werde ich noch /CDAC als Signal routen, dann kann ich einen solchen 14 MHz Takt erzeugen, aber bei der aktuellen Board Revision habe ich nur ein 7 MHz Signal. Momentan versuche ich gerade noch ob ich mit den Vorschlägen aus Beitrag "Synchronisieren auf rising- und falling-edge" zurechtkommen, aber meine Situation ist eine andere. In VHDL bin ich ein Neuling. Mir geht es nicht nur darum, das konkrete Problem zu lösen sondern grundsätzlich die Anwendung von VHDL zu verstehen. Der 68000er Bus ist eigentlich ein asynchroner Bus. Wie man den am besten mit CPLD verheiratet, die eigentlich lieber synchronisierte Logic haben wollen habe ich noch nicht verstanden. Michael
:
Bearbeitet durch User
Michael D. schrieb: > Gibt es dafür eine gute Lösung die ohne zusätzlichen externen Takt > auskommt? Mach einen Zähler, der die steigenden Flanken zählt und einen, der die fallenden Flanken zählt. Addiere beide Zähler. > Ich verwende einen Xilinx XC9572XL mit ISE14.7. OK, vergiss den Ansatz wieder... > Prinzipiell würde ich ja einen doppelt so schnellen Takt > benötigen, d.h. einen 14 MHz Takt. Ich würde ein FPGA nehmen und das ganze Design vollständig synchron zu einer vielfachen Taktfrequenz (z. B. 56 MHz) aufsetzen. Dann ist es auch kein Problem, irgendwelche im Original "phasenverschobenen" Mikro-FSM zu implementieren. Mit diesem Ansatz haben wir eine Z80 CPU samt Peripheriebausteinen (Zähler, Interruptcontoller, SIO) in ein FPGA gepackt, dass die alte Software unverändert weiter verwendet werden konnte. Michael D. schrieb: > Der 68000er Bus ist eigentlich ein asynchroner Bus. Wie man den am > besten mit CPLD verheiratet, die eigentlich lieber synchronisierte Logic > haben wollen habe ich noch nicht verstanden. Wen. Man da Taktdomänen überschreiten muss (weil das CPLD nicht synchron zum 68k Bus läuft) dann nimmt man da aufgrund der teuren Flipflops kein CPLD, sondern ein FPGA und betreibt am Businterface ausreichend Oversampling.
:
Bearbeitet durch Moderator
Michael D. schrieb: > Hintergrund: ich möchte für eine 68000 Motorola CPU die S-States > mitzählen um das Bustiming für DTACK und andere Signale zu machen, > ausgehend von der fallenden Flanke von /AS. Nimm einen µC und zähle die Flanken in Software ;-) Ansonsten ist XOR mit Laufzeitverzögerung an einem Eingang die "übliche" Funktion dafür. Es gab mal 74HC86.
Lothar M. schrieb: >Mach einen Zähler, der die steigenden Flanken zählt und einen, der die >fallenden Flanken zählt. Addiere beide Zähler. >> Ich verwende einen Xilinx XC9572XL mit ISE14.7. >OK, vergiss den Ansatz wieder... Genau, sonst habe ich das Problem zu wissen, wann das Ergebnis der Addition stabil ist und das würde genau wieder die Taktflanke benötigen die mir fehlt :-) Mein Projekt war ursprünglich auf einem ATF22V10C implementiert, komplett mit Latches, d.h. selbsthaltende Logik mit set und reset Signal. Als Zähler werden direkt die um 90° versetzten 3,5 MHz Clocks /C1 und /C3 verwendet (leider kann man damit nur bis 3 Zählen und nicht bis 7). Das funktionierte am Ende auch "ganz gut" (TM). Dummerweise muss man dafür den Bus dann auf /C1 synchronisieren, was zusätzliche Wait States bedeuten könnte. In der Praxis sind diese Wait States aber unwahrscheinlich, da der Bus von den Custom Chips sowieso bereits auf /C1 synchronisiert ist. Jetzt wollte ich das "einfach" auf einen XC9572XL übertragen, aber mit den Latches läuft das nur teilweise und stürzt nach spätestens 400 Speicherzugriffen ab. Wenn es wenigstens sofort abstürzen würde, könnte ich es einfacher debuggen. > Ich würde ein FPGA nehmen und das ganze Design vollständig synchron zu > einer vielfachen Taktfrequenz (z. B. 56 MHz) aufsetzen. Danke für die Tips! Dafür habe ich ein paar Beispiele gefunden (z.B. das Amiga Greta Projekt https://github.com/endofexclusive/greta). So langsam verstehe ich auch, warum das alle so machen :-) Der Haupt-Nachteil der bei Greta direkt am Bild ersichtlich ist, ist die fehlende 5V Kompatibilität der FPGAs, d.h. es werden eine Menge Pegelwandler benötigt. Ich habe sogar 10 Amiga Expansion-Port FPGA Adapter-Boards mit Pegelwandlern fertigen lassen, nur muss ich erstmal mit VHDL Erfahrung sammeln, bevor ich das in Betrieb nehme. Das soll dann auch gleich den 68000er komplett ersetzen und eigenes RAM einbinden. Der FPGA ist nicht direkt auf dem Board, es werden fertige FPGA Boards zum draufstecken verwendet. Falls jemand für den A500/A1000 sowas braucht kann er sich gerne melden. Ob die Boards funktionieren weiß ich noch nicht. Michael
:
Bearbeitet durch User
Die Flipflops in Xilinx Coolrunners können auf beide Clockflanken triggern, also auf clock'event. Gerhard
Michael D. schrieb: > Ich habe sogar 10 Amiga Expansion-Port FPGA Adapter-Boards mit > Pegelwandlern fertigen lassen, ... > > Falls jemand für den A500/A1000 sowas braucht kann er sich gerne melden. > Ob die Boards funktionieren weiß ich noch nicht. Dieses Angebot solltest Du unter einen passenden Titel (Bspw. "Biete für Commodore Amiga Expansionport DIY Breakoutplatine mit 5V <-> 3V3 Levelshifter") in ein passender Unterforum, bspw.: https://www.mikrocontroller.net/forum/pc-hardware-software oder https://www.mikrocontroller.net/forum/mikrocontroller-elektronik mit Schaltplan und Foto im Anhang stellen. Unter dem Titel "FF-clock in einem 3V3 CPLD" dürfte keiner ein solches Retro-Projekt vermuten.
Fpgakuechle K. schrieb: > https://www.mikrocontroller.net/forum/pc-hardware-software oder > https://www.mikrocontroller.net/forum/mikrocontroller-elektronik > mit Schaltplan und Foto im Anhang stellen. > Unter dem Titel "FF-clock in einem 3V3 CPLD" dürfte keiner ein solches > Retro-Projekt vermuten. und auch bitte ins Amiga / C64- Forum.
Fpgakuechle K. schrieb: > Dieses Angebot solltest Du unter einen passenden Titel (Bspw. "Biete für > Commodore Amiga Expansionport DIY Breakoutplatine mit 5V <-> 3V3 > Levelshifter") in ein passender Unterforum Das werde ich gerne machen, sobald ich wenigstens den Smoketest machen konnte. Leider ist die Lernkurve bei VHDL doch länger als gehofft, so dass dies noch etwas dauern kann. Die letzten beiden Tage habe ich aber viel gelernt und bin ein großes Stück weitergekommen. Das Angebot war so gedacht, dass die ein bis zwei Interessenten die zufällig darüberstolpern und sich mit VHDL besser auskennen als ich selbst dies gerne haben können. Wenn es mehr werden würden, dann wird der Support zu aufwändig und ich komme mit dem eigentlichen Projekt nicht voran, daher möchte ich das noch nicht großartig anbieten. Die Lösung für das hier angesprochene Problem war, einen doppelt so schnellen Takt zu verwenden und dann nur auf die steigende Flanke zu triggern. Dazu muss ich leider ein Kabel ziehen. Michael
Angehängte Dateien:
-
clks_amiga.PNG
45 KB -
MC68k_Bustiming.PNG
6,3 KB
Michael D. schrieb: > Fpgakuechle K. schrieb: >> Dieses Angebot solltest Du unter einen passenden Titel (Bspw. "Biete für >> Commodore Amiga Expansionport DIY Breakoutplatine mit 5V <-> 3V3 >> Levelshifter") in ein passender Unterforum > > Das werde ich gerne machen, sobald ich wenigstens den Smoketest machen > konnte. Leider ist die Lernkurve bei VHDL doch länger als gehofft, so > dass dies noch etwas dauern kann. Zum Hardwaredebug braucht es im Unterschied zur C-Programmierung nicht immer den Level HDL-Sourcecode, sondern Logicanalyzer (Oscilloscope) und Generator. Je nach FPGA-Hersteller kann man auch Fpga-internen Logicanalyzer und Generator verwenden (signaltap, Chipscope ILA/VIO) > Die Lösung für das hier angesprochene Problem war, einen doppelt so > schnellen Takt zu verwenden und dann nur auf die steigende Flanke zu > triggern. Vielleicht solltes du sogar den vierfachen Clock verwenden, weil das ohnehin der Masterclock im Amiga ist (auch wenn er am A500/1000 nicht am Expansion-Port aufliegt (siehe Anhang-snippet aus "Amiga System Programmer's Guide" by Dittrich, Gelfand, Schemmel)). Der (FAT-) Agnus teilt wohl den 28MHz clock auf den CPU-Clock runter. > Hintergrund: ich möchte für eine 68000 Motorola CPU die S-States > mitzählen um das Bustiming für DTACK und andere Signale zu machen, > ausgehend von der fallenden Flanke von /AS. Hab dazu auch ein Bild für die Leser angehangen (aus http://users.cecs.anu.edu.au/~Matthew.James/engn3213-2002/notes/busnode7.html)
Gerhard H. schrieb: > Die Flipflops in Xilinx Coolrunners können auf beide > Clockflanken triggern, also auf clock'event. > > Gerhard Ich meine, Dual Edge Trigger haben nur die Coolrunner II und da gehört der XL9572XL nicht dazu?
Warum machst du nicht einfach eine XOR wo du das Q vom FF drauf verbindest? Geht doch wunderbar mit den CPLD und den XOR ausgang fürst du dann auf den CLOCK dann zählt dir dein Counter jede Flanke. Habe ich in den ALTERA Max II oft als Clockverdoppler "missbraucht". Aber auch schon viel früher in GAL22V10 so umgesetzt,
Markus F. schrieb: > Ich meine Korrekt. Und die Coolrunner II sind natürlich auch nicht 5V-tolerant: https://support.xilinx.com/s/article/13520?language=en_US
Patrick L. schrieb: > Warum machst du nicht einfach eine XOR wo du das Q vom FF drauf > verbindest? Dann braucht er trotzdem einen schnelleren Takt und zwar einen nochmal schnelleren als Faktor 2, nämlich dann wenn das Puls-Pausen-Verhältnis des observierten Taktes nicht 50% ist und man sicher sein kann, dass er beide erwischt. Einfacher wäre es, man halbiert die Takte mit einem JK-FF und lässt 2 davon auf den Flanken laufen. Deren Ausgang auf eine EXOR-Synch-Schaltung kann mit dem einfachen Takt mitzählen. Man hat dann nur immer einen Fehler von 0 / +1 an Takten und muss mit 2 multiplizieren, beim Ausgeben.
Michael D. schrieb: > Hintergrund: ich möchte für eine 68000 Motorola CPU die S-States > mitzählen um das Bustiming für DTACK und andere Signale zu machen, > ausgehend von der fallenden Flanke von /AS. > > Gibt es dafür eine gute Lösung die ohne zusätzlichen externen Takt > auskommt? Prinzipiell würde ich ja einen doppelt so schnellen Takt > benötigen, d.h. einen 14 MHz Takt. Du hast ja in deinem zweiten Post eine latch-basierte Lösung erwähnt. Das müsste sich doch ohne grössere Probleme um C1 und C3 erweitern lassen. Ich denke mal, dass das auch ohne zusätzliche Taktung möglich ist.
Sigi schrieb: > Du hast ja in deinem zweiten Post eine latch-basierte Lösung > erwähnt. Das müsste sich doch ohne grössere Probleme um C1 und > C3 erweitern lassen. Die Lösung hat C1 und C3 massiv verwendet, sonst wäre es nicht gegangen. Der Versuch dies 1:1 auf den XC9572XL zu übertragen hat leider nicht geklappt, wahrscheinlich durch die Optimierungen der Logik. Es kamen ja auch einige Warnings, die sind jetzt alle weg. Vielleicht hätte es funktioniert, wenn ich die Optimierungen alle abgeschaltet hätte. Ich wollte ja auchmal lernen, wie man das mit synchroner Logik macht. Michael
Michael D. schrieb: > Ich wollte ja auchmal lernen, wie man das mit synchroner Logik macht Das kann aber schnell kompliziert werden, wenn der Takt nicht irgendwie synchron zu C1 oder C3 ist. Einfaches Sampeln setzt auch Entprellung zur Stabilisierung voraus, und da kann z.B. ein 9572XL schon schnell zu klein werden (was ich aber beim 68000 und einer Busansteuerung nicht glaube). Der Absturz deiner Oben erwähnten Schaltung kann z.B. auf falsche/fehlende Entprellung zurückzuführen sein (muss aber nicht). Ich habe schon mal für Retroprojekte eine SRAM/Flash-Ansteuerung für einen 68000er geschrieben, lief vollständig asynchron, und das ohne Probleme.
Michael D. schrieb: > Sigi schrieb: > >> Du hast ja in deinem zweiten Post eine latch-basierte Lösung >> erwähnt. Das müsste sich doch ohne grössere Probleme um C1 und >> C3 erweitern lassen. > > Die Lösung hat C1 und C3 massiv verwendet, sonst wäre es nicht gegangen. Es wäre für alle nachvollziehbarer wenn nicht irgendwelches Amiga-Chinesisch verwendet würde, sondern allgemeine Termini der Digitaltechnik zu verwenden. Hier, die Verwendung von Phasenverschobenen clock-Signalen. Bei dem fokussierten Problem (statt falling und rising nur eiune Taktflanke zu verwenden) kann man statt der Verschiebung um Viertel-Periode des halben Taktes (wie bei C1,C3) auch eine um die halbe Periode Verschobenen Originaltakt (7M) verwenden, um eben mit nur single edge triggernden FF Waveformen wie aus both edge trigerenden FF zu erzeugen. Deshalb haben ja FÜGA's Taktaufbereitung (PLL/DLL/DCM/...) um eben diese kompßlexeren Taktschemen zu erzeugen. Beim Amiga macht das wohl AGNUSs und GARY (?) und da wäre zu überlegen ob man statt 3.58MHz Taktreplica C1, C3 nicht auch andere nehme könnte (7M und CDAC). (für die verschiedenen Signalbezeichnungen siehe https://www.mikrocontroller.net/attachment/542213/clks_amiga.PNG) -- > Der Versuch dies 1:1 auf den XC9572XL zu übertragen hat leider nicht > geklappt, wahrscheinlich durch die Optimierungen der Logik. Es kamen ja > auch einige Warnings, die sind jetzt alle weg. Vielleicht hätte es > funktioniert, wenn ich die Optimierungen alle abgeschaltet hätte. > Der Absturz > deiner Oben erwähnten Schaltung kann z.B. auf falsche/fehlende > Entprellung zurückzuführen sein (muss aber nicht). Das ist das Hauptproblem hier, man weiss nicht, was an der Schaltung nicht funktioniert und beschreibt es dann noch mit Begriffen aus der Softwareprogrammierung ("Absturz"). Weil es noch nicht erwähnt wurde, nehme ich stark an, das es an fehlenden/falschen/ignorierten Timing constraints liegt und noch nie gemessen oder simuliert wurde was die Schaltung überhauüt tut. Zum Erlernen von HDL gehört das aber dazu, das man weiss wie man Simulation, STA und Messtechnik zum debuggen einsetzt.
Fpgakuechle K. schrieb: > Das ist das Hauptproblem hier, man weiss nicht, was an der Schaltung > nicht funktioniert und beschreibt es dann noch mit Begriffen aus der > Softwareprogrammierung ("Absturz"). Hier sind wir dann scheinbar wieder bei einem von Lothar's Lieblingsthemen, dem "Programmieren". Da du hier aber einen Zustandsautomaten hast, ist es formaltheoretisch Software UND Hardwarebeschreibung, HDL kümmert sich nur um das entsprechende Mappen passend für einen FPGA oder CPLD. Und damit ist umgangssprachlich "Absturz" akzeptabel (abgesehen davon, dass "Absturz" kein formaltheoretischer Terminus ist, sondern ugs.). Fpgakuechle K. schrieb: > eil es noch nicht erwähnt wurde, nehme ich stark an, das es an > fehlenden/falschen/ignorierten Timing constraints liegt imho halte ich es für keinen Fehlergrund: Die Problemstellung lässt sich ohne grosse Berücksichtigung der Timingconstraints lösen, insbesondere bei 3-4MHz. Ein 95xxXL ist dafür viel zu schnell, um bei latchgetriebener Lösung zu Problemen zu führen (einzig ein zu schnelles Reagieren kann mMn evtl zu Problemen führen, durch das Schnellersein wird aber das gesamte Timing der SRAM/Flash-Seite auf der Zeitachse nach Vorne gezogen, sollte also auch kein Problem sein). Also ich hab so etwas schonmal aus Langeweile gemacht (9500 ohne XL), ohne irgendwelche Timingconstraints. Natürlich habe ich mir im Anschluss die Timingresultate angeschaut, bei den "kleinen" Automaten zur Busansteuerung aber immer sowas von keine Problem. Fpgakuechle K. schrieb: > Deshalb haben ja FÜGA's Taktaufbereitung > (PLL/DLL/DCM/...) nicht aber CPLDs, und insbes. die 95xxXLer haben dazu noch 5V-tolerante IOs, die man im Falle von FPGAs durch Levenshifter ergänzen müsste, also komplett von oversized. Davon abgesehen braucht's oft keine Clockinfos in Form von z.B. C1 etc., einfach mal im 68000er Hardwaremanual die Bustimings angucken. Das Beste wird aber sein, der TO postet einfach mal seine alte/neue HDL-Beschreibung.
Angehängte Dateien:
Fpgakuechle K. schrieb: > Bei dem fokussierten Problem (statt falling und rising nur > eine Taktflanke zu verwenden) kann man statt der Verschiebung > um Viertel-Periode des halben Taktes (wie bei C1,C3) auch eine um die > halbe Periode Verschobenen Originaltakt (7M) verwenden Es geht um ein Board welches am Amiga 500 Expansion Port hängt. Dort stehen nur die folgenden 3 Taktsignale zur Verfügung: /C1, /C3 und CDAC. Der 7M Originaltakt steht dort leider nicht zur Verfügung. Aus diesen Signalen kann ein leicht verschobenes 7M und ein 14M Signal rückgewonnen werden:
1 | CLK7M <= not(nC1 xor nC3); |
2 | CLK14M <= CLK7M xor CDAC; |
> Das ist das Hauptproblem hier, man weiss nicht, was an der Schaltung > nicht funktioniert und beschreibt es dann noch mit Begriffen aus der > Softwareprogrammierung ("Absturz"). Ja, der Amiga ist abgestürzt. Der CPLD ist nicht abgestürzt. Das Hauptproblem wurde durch den 14M Takt behoben. Mit dem kann ich auf beide Flanken des 7M Signals triggern und alles ist in Ordnung. Ohne zusätzliches Signal wäre es nett gewesen, daher die Frage ob man auf beide Flanken triggern kann. Jetzt muss ich eben die Prototypen per Kabel patchen und in der nächsten Revision CDAC noch routen, auch kein Beinbruch. Das Lesen von Flash funktioniert jetzt, d.h. der Rechner bootet vom externen Flash. Das Timing vom Schreiben muss ich noch korrigieren, daher mache ich dafür jetzt gerade die VHDL Testsuite. Da dies meine erste ist muss ich mir erst mal überlegen, wie ich das am besten aufbaue. > Weil es noch nicht erwähnt wurde, nehme ich stark an, das es an > fehlenden/falschen/ignorierten Timing constraints liegt Der 10 ns CPLD ist eher viel zu schnell und hat viel zu steile Flanken. Ich habe die Outputs jetzt mal auf "SLOW" gesetzt um die Überschwinger etwas zu dämpfen. Wir reden hier über Open Collector Logik bei einem 7 MHz Bus. Ggf muss ich noch Serienwiderstände oder zusätzliche Pullups einbauen. Falls du das mit nicht beachteten Timing constraints meinst, dann ja. > und noch nie gemessen oder simuliert wurde was die Schaltung überhaupt tut. Solange ich nicht einmal weiß, ob bzw. wie man FlipFlops auf beide Flanken triggern kann, bin ich vielleicht noch nicht so weit eine vollständige Testsuite implementiert zu haben. Aber sie ist vorhanden und wächst (momentan 300 Zeilen TestSuite ich schätze ich brauche ca. viermal soviel). > Erlernen von HDL gehört das aber dazu, das man weiss wie man Simulation, > STA und Messtechnik zum debuggen einsetzt. 16 Kanal Logicanalyzer ist bestellt. Die Testsuite ist in Arbeit. Die ersten beiden Test-Zyklen sehen aktuell so aus, der HauptTeil zwischen "speriod * 0.75" und "speriod * 7" im fullcycle 1 fehlt noch (speriod=1/14MHz, 8 speriods sind ein fullcycle):
1 | stim_proc: process |
2 | begin |
3 | -- fullcycle 0: reset |
4 | nRES <= '1', '0' after speriod * 2, '1' after speriod * 6; |
5 | |
6 | wait for speriod * 7; |
7 | assert (nOVR='Z') report "nOVR failed" severity error; |
8 | assert (nDTACK='Z') report "nDTACK failed" severity error; |
9 | assert (nWE_KICK='1') report "nWE_KICK failed" severity error; |
10 | assert (nOE_KICK='1') report "nOE_KICK failed" severity error; |
11 | assert (nRTC_CS='1') report "nRTC_CS failed" severity error; |
12 | assert (nRTC_WR='1') report "nRTC_WR failed" severity error; |
13 | assert (nRTC_RD='1') report "nRTC_RD failed" severity error; |
14 | |
15 | -- fullcycle 1: read reset vector from 0x000000 to 0x000007 (SP + PC) when OVL_LOCAL is 1: reads from flash |
16 | wait until fullcycle'event; |
17 | A <= (others => 'U'), x"00" after speriod * 1.5, (others => 'U') after speriod * 8.0; |
18 | ALOW <= (others => 'U'), x"0" after speriod * 1.5, (others => 'U') after speriod * 8.0; |
19 | nAS <= '1', '0' after speriod * 2.5, '1' after speriod * 7.1; |
20 | nLDS <= '1', '0' after speriod * 2.5, '1' after speriod * 7.1; |
21 | nUDS <= '1', '0' after speriod * 2.5, '1' after speriod * 7.1; |
22 | D <= (others => 'U'), x"00" after speriod * 6.5, (others => 'U') after speriod * 8.0; |
23 | |
24 | wait for speriod * 0.75; |
25 | assert (nOVR='Z') report "nOVR failed" severity error; |
26 | assert (nDTACK='Z') report "nDTACK failed" severity error; |
27 | assert (nWE_KICK='1') report "nWE_KICK failed" severity error; |
28 | assert (nOE_KICK='1') report "nOE_KICK failed" severity error; |
29 | assert (nRTC_CS='1') report "nRTC_CS failed" severity error; |
30 | assert (nRTC_WR='1') report "nRTC_WR failed" severity error; |
31 | assert (nRTC_RD='1') report "nRTC_RD failed" severity error; |
32 | --assert (A18_FLASH='0') report "A18_FLASH failed" severity error; |
33 | |
34 | wait for speriod * 7; |
35 | assert (nOVR='Z') report "nOVR failed" severity error; |
36 | assert (nDTACK='Z') report "nDTACK failed" severity error; |
37 | assert (nWE_KICK='1') report "nWE_KICK failed" severity error; |
38 | assert (nOE_KICK='1') report "nOE_KICK failed" severity error; |
39 | assert (nRTC_CS='1') report "nRTC_CS failed" severity error; |
40 | assert (nRTC_WR='1') report "nRTC_WR failed" severity error; |
41 | assert (nRTC_RD='1') report "nRTC_RD failed" severity error; |
Im Anhang ist die Simulation des fullcycle 1 zu sehen. Michael
:
Bearbeitet durch User
Michael D. schrieb: > Der 10 ns CPLD ist eher viel zu schnell und hat viel zu steile Flanken. > Ich habe die Outputs jetzt mal auf "SLOW" gesetzt um die Überschwinger > etwas zu dämpfen. Wir reden hier über Open Collector Logik bei einem 7 > MHz Bus. > Ggf muss ich noch Serienwiderstände oder zusätzliche Pullups einbauen. Ja auch deshalb ist es angeraten einen neuen thread mit problemspezifischen Topic zu starten, hier bspw. "Schaltungsdesign Busplatine 68k f. Commodore Amiga". 'Zu schnell' kann man eigentlich nicht sagen, das propagation delay kann eigentlich nicht kurz genug sein, weil damit auch der skew (Laufzeitunterscheide auf dem Bus geringer wird. Was ein Problem werden kann, ist, wenn die Flanken sehr steil sind, wegen unpassender Terminierung reflektiert werden und so verursachte Störungen auf andere Leitungen einkoppeln. Sowas bekommt man aber u.a. mit ner gescheiten Massefläche auf PCB den in den Griff. Das das board openCollector nutzt oder nutzen muß sollte man auch direkt klären, dazu später. Beispiele für PullUps und Serienwiderstände in diesem Fall kann man sich bei I2C abschauen, das ist auch OC und es gibt auch schnelle Varianten in der Nähe zu 7 MHz. dabei nimmt man eher kleine Pullups (3k3) und mehr statt wenig Treiberstärke (Slew Fast, Drive strength). http://lembke.eu/arduinoablage/20201103i2cpullupcalculator/ Hierzu sollt man auch mal mit dem Scope die reale Anstiegszeit messen. Das geht auch mit einem (alten) analogen scope, wenn man per Software regelmäßig Pulse losschickt, da muss es nicht unbedingt ein Speicherscope sein. Bei der Simulation dürfte hier eine post-fit Simulation hilfreich sein, nicht die übliche event-basierte behaviroual. Die dazu gehörige back-annotierte (VHDL) Netzliste ist bei CPLDs nicht so umfangreich wie bei FPGA's. Falls du den gesamtem source (.vhd und *.ucf (pining, timing timing constraints)) zur Verfügung stellst, kann das sich hier jemand im Forum für dich machen. Mein Verständnis hier leidet etwas unter Widersprüchen in der Beschreibung. Zu einem heisst es, es sollen nur Signale am port expander genutztz werden, zum anderen beginnt der Thread genau mit dem Wunch sich 'fehlende' signale nachzubauen. Zum anderen sollen Pegelwandler vermieden werden, allerdings scheint genau das die Funktion des CPLD hier zu sein, die er aber eher schlech als recht erfüllt. Die XC9500XL ist nicht 5V kompatibel sondern nur tolerant, passend wäre die Vorgängerserie ohne XL also XC9500, aber die ist wohl komplett vom Markt. Der CPLD verträgt nur etwas höhere Spannung kann sie aber nicht direkt liefern, deshalb wohl das OpenCollector-Konstrukt. Da wären bidirektionale Levelshifter die bessere Wahl. zum Thema Levelshift gibt es jede Menge Doku: https://www.xilinx.com/support/documentation/user_guides/ug445.pdf https://www.mikrocontroller.net/articles/Pegelwandler Persönlich habe ich gute Erfahrung mit Analog-Schalter und Diode gemacht, das ist als FPGA (Spartan 2E) -BasierteAutomobillösung zu Zehntausenden produziert worden.
Beitrag #6941855 wurde vom Autor gelöscht.
Angehängte Dateien:
Tobias (. schrieb: > Dann braucht er trotzdem einen schnelleren Takt und zwar einen nochmal > schnelleren als Faktor 2, nämlich dann wenn das Puls-Pausen-Verhältnis > des observierten Taktes nicht 50% ist und man sicher sein kann, dass er > beide erwischt. Wiso? Ich löse dies so (Siehe Bild) falls mein Text nicht verständlich war. Dan brauchst du kein schnelleres(Siehe Bild MAX+PLUS II)
Angehängte Dateien:
Fpgakuechle K. schrieb: > Ja auch deshalb ist es angeraten einen neuen thread mit > problemspezifischen Topic zu starten Sorry, ich wollte das eigentlich garnicht diskutieren. Ich hatte nur in einem Nebensatz erwähnt, wie ich das bisher gemacht hatte und dann ging die Diskussion los. Ich habe auch aktuell kein direktes VHDL Problem mehr. Das Lesen vom Flash funktioniert. Das Erase geht noch nicht, aber da ist wahrscheinlich die Software die im Amiga läuft schuld. Ein 29F040B unterscheidet sich vom Aufbau doch etwas vom MBM29F160. Die Kommandos sind ähnlich, aber die Aufteilung in Regions ist anders. Das muss ich eben noch anpassen. > Was ein Problem werden kann, ist, wenn die Flanken sehr > steil sind, wegen unpassender Terminierung reflektiert werden Der Mist an dem Bus ist, dass der durchgeschleift ist und kein definiertes Ende hat. Da ich mir nicht sicher sein kann, dass mein Board am Ende vom Bus hängt, darf ich es eigentlich auch nicht einfach terminieren. Das mit dem Durchschleifen sollte man nicht wirklich machen, aber sonst kann man eben keine zwei Erweiterungen anschließen. Letztendlich wurden ja dann der A2000/3000/4000 gebaut mit "definierten" Slots. Da hat der Bus ein definiertes Ende. > und so verursachte Störungen auf andere Leitungen einkoppeln. > Sowas bekommt man aber u.a. mit ner gescheiten Massefläche auf PCB den in den Griff. Das Board hat so viel Masse-Füllung wie es ging, siehe Bild. Auf dieser Revision sind zwei unterschiedliche 16 MBit Flash chips drauf, da ich die beide testen will. Im finalen Board wird es nur einer sein, da geht dann mehr Masse. > Das das board openCollector nutzt oder nutzen muß sollte man auch direkt > klären, dazu später. Beispiele für PullUps und Serienwiderstände in > diesem Fall kann man sich bei I2C abschauen, das ist auch OC und es gibt > auch schnelle Varianten in der Nähe zu 7 MHz. dabei nimmt man eher > kleine Pullups (3k3) und mehr statt wenig Treiberstärke (Slew Fast, > Drive strength). > http://lembke.eu/arduinoablage/20201103i2cpullupcalculator/ Auf dem Amiga Board ist ein 470 Ohm Pullup verbaut. > Hierzu sollt man auch mal mit dem Scope die reale Anstiegszeit messen. Die Fall-Time liegt zwischen 5 und 6 ns, die Rise-Time bei ca. 58 ns. Die Rise-Flanke hängt ja nur vom Pullup ab. Die Messung mache ich auf meinem Board, d.h. beim am weitesten entfernten Punkt vom Pull-Up. Ein zusätzlicher Pull-Up auf meinem Board sollte die Fall-Time wenig beeinflussen, aber die Rise-Time hoffentlich deutlich drücken. Die I/O Speed beim XC9572XL ist auf SLOW eingestellt, die könnte ich ja wieder auf FAST zurück ändern, falls die Rise-Time zu stark leidet. > Bei der Simulation dürfte hier eine post-fit Simulation hilfreich sein, Was braucht man dazu um die zu machen? Sind die Tools im Lieferumfang der kostenlosen ISE Suite dabei? > Die dazu gehörige > back-annotierte (VHDL) Netzliste ist bei CPLDs nicht so umfangreich wie > bei FPGA's. Falls du den gesamtem source (.vhd und *.ucf (pining, timing > timing constraints)) zur Verfügung stellst, kann das sich hier jemand im > Forum für dich machen. Timing constraints habe ich noch keine definiert, die muss ich erstmal herleiten. > Mein Verständnis hier leidet etwas unter Widersprüchen in der > Beschreibung. Zu einem heisst es, es sollen nur Signale am port expander > genutztz werden Das sind keine Widersprüche. Es können nur Signale genutzt werden, die dort zur Verfügung stehen. > zum anderen beginnt der Thread genau mit dem Wunch sich > 'fehlende' signale nachzubauen. Das ist ein Muss und gängige Praxis die genau so in den Amiga Hardware Reference Manuals definiert ist. Ich habe den Bus nicht definiert, ich möchte ihn nur nutzen. > Zum anderen sollen Pegelwandler vermieden werden, Die brauche ich für die Erzeugung eines Open Collector Signals ja auch nicht, ich verwende ja nur 'Z' und '0'. Die '1' treibt der Pullup. > allerdings scheint genau das die Funktion des CPLD > hier zu sein, die er aber eher schlech als recht erfüllt. > Die XC9500XL ist nicht 5V kompatibel sondern nur tolerant Ich sehe hier kein Problem und keinen Widerspruch. > Die XC9500XL ist nicht 5V kompatibel sondern nur tolerant, passend wäre die > Vorgängerserie ohne XL also XC9500, aber die ist wohl komplett vom > Markt. Der CPLD verträgt nur etwas höhere Spannung kann sie aber nicht > direkt liefern, deshalb wohl das OpenCollector-Konstrukt. Nein, ich verwende Open Collector weil der Bus das so vorgibt. Es geht um /DTACK und /OVR. > Da wären bidirektionale Levelshifter die bessere Wahl. Ja, leider nur nicht passend zu Definition der genannten Amiga Zorro Bus Signale. Das endet sonst in einem Krieg der Treiber. Michael
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.