Hallo,
dies ist mein erstes Projekt mit einem FPGA.
Vorher habe ich VHDL auf nem 95144 PLD schon probiert, das Ding ist mit
einigen Adressvergleichen aber ruckzuck voll.
Ich habe mir eine Platine gemacht, auf dem Levelshifter für den 16 Bit
breiten Adressbus sowie 8Bit breiten Datenbus für die Pegelanpassung
draufsitzen.
Ausserdem sind auf dem Board 12 7-Segment-Anzeigen, 16 LEDs, 8 Schalter
sowie 2 Taster.
Das ganze hängt an einem ATARI 800XL oder 130XE ! (Ja, die leben noch
:-) )
Auf den oberen 6 Anzeigen wird eine über eine im Atari "freigemachte"
Adresse die "Debug-Adresse" eingestellt, über die unteren 6 quasi das
gleiche nochmal, allerdings mit zuschaltbaren "Triggerausgang", der
mittels 74x123 ein längeres Taktsignal ausgibt, wenn auf die
"Trigger-Adresse" zugegriffen wird. Diesen Ausgang kann man z.B. für das
einschalten eines Freezers benutzen (als Taster-Simulation). Ausserdem
gibt es die Möglichkeit, bei Trigger-Treffer einen kurzen Piepton
einzuschalten.
Die Anzeigen, LEDs, Schalter und Taster sind gemultiplext. Das
funktioniert auch sehr gut.
Weiterhin sind ein Platz für ein 29C040 Flash oder ein 128/512K SRAM
sowie ein Platz für ein 27x64-512 Eprom / 28C256 EEprom auf der Platine.
Das einblenden dieser Chips in einen bestimmten Speicherbereich vom
Atari funktioniert auch problemlos. (Lesen und Schreiben)
Nun hatte ich zeitweise über 200 Warnungen von Quartus bekommen,
nach etlichen lesen im Forum bin ich dahintergekommen, daß es immer
besser sei, bei steigender/fallender Flanke als bei "clk = '1'" den
Block laufen zu lassen. das ganze Listing überarbeitet und siehe da, die
ganzen bösen Latches waren weg. Es kommen noch viele Warnmeldungen, da
einige Pins noch keine Funktion haben.
Wo ich aber am meisten Probleme habe, ist das schreiben auf
Speicherzellen, die vom FPGA verwaltet werden. Lesen geht 1a und
fehlerfrei!
Liegt es evt. an der Schreibweise?
Was wäre richtig oder falsch bei folgenden Beispiel:
if data_out_enable or adr >= x"D380" and adr <= x"D3FF" then
if (data_out_enable) or ((adr >= x"D380") and (adr <= x"D3FF")) then
if (data_out_enable = true) or ((adr >= x"D380") and (adr <= x"D3FF"))
then
gibt es hier Unterschiede, ob = true oder nicht da steht und obs in
Klammer ist?
hier noch eine Routine, die mir Kopfzerbrechen macht... Schreibwerte
werden "manchmal!", meist aber garnicht verarbeitet!
------------------------------------------------------------------------
-- $D3F0 REGISTER-WRITE-ENABLE Byte übernehmen
-- (nur bei #$55 werden Schreibzugriffe auf die DebugAdr-Register
erlaubt)
------------------------------------------------------------------------
decode_d3f0: process(phi2short, rw, adr, data, run_ok, trigger_we)
begin
if falling_edge(phi2short) and (run_ok) then
if (adr = x"D3F0") then
if (rw = '0') then
trigger_we <= data;
else
if (data = x"55") then
dp(12) <= '1';
enable_trgset <= true;
else
dp(12) <= '0';
enable_trgset <= false;
end if;
end if;
end if;
end if;
end process decode_d3f0;
----------------------------------------------------------------------
wobei phi2short der etwas verkürzte PHI2 Systemtakt des Ataris ist
(1.77Mhz), run_ok ist ein signal, welches 2sekunden nach dem einschalten
auf true geht. Dieser Timer ist nötig, da der Atari beim Powerup erst
alle Adressen überschreibt.
beim schreiben in D3F0 wird das Byte am Datenbus in trigger_we kopiert
(hoffe ich) und beim lesen auf hex55 verglichen, wenn es 55 sein sollte,
sollen die Triggeradressen beschreibbar sein (enable_trgset=true).
Sollte es der Wert 55 sein, wird ein Dezimalpunkt (dp12) zur Kontrolle
eingeschaltet.
Warum DIESES nur selten funktioniert, ist mir ein Rätsel!
Habe ich hier irgendwo einen Denkfehler ?
Gruß,
Wolfram.
mega-hz schrieb:> Hallo,>> dies ist mein erstes Projekt mit einem FPGA.> .......>> Gruß,> Wolfram.
Oh sorry, habe gerade gesehen, daß ich nicht eingeloggt war...
Nu aber.
Gibt es eigentlich einen Unterschied ob ich schreibe,
trigger_we <= data;
oder
trigger_we(7 downto 0) <= data(7 downto 0);
wenn beide 8 Bit breit sind?
Gruß,
Wolfram.
Du bist noch etwas zu sehr C verhaftet ;) Für die Bedingung im IF
braucht es keine Klammern. Dagegen aber sehr wohl für verbundene
OR/ANDs, da AND im Gegensatz zu C nicht stärker als OR bindet.
Allerdings sollte der Synthesizer dann auch Fehlermeldungen bringen.
Du hast aber generell ein Problem mit dem Alter deines "Opfers". Damals
war voll synchrones Design (alles flankengesteuert) aus Sparsamkeit
selten und es hat alles munter mit fallenden, steigenden und
phasenverschobenen/unsymmetrischen Takten kreuz und quer rumgewerkelt.
Zudem war das Zeug schweinelahm, sodass Unsauberkeiten in der
Signalführung (Ringing) oder leichte Setup/Hold-Verletzungen nicht so
aufgefallen sind. Heutige Chips sind da grob 50-100mal schneller und
können da Unsinn produzieren. Du solltest die Signale amFPGA mal mit
einem Oszi anschauen und wirklich überprüfen, ob deine zeitlichen
Annahmen mit den qualifizierenden Flanken und Steuersignalen dazu
wirklich stimmen.
Gefährlich sind auch Unterschwinger bei fallenden Flanken, weil die
schnell wieder in den 1-Bereich reinschiessen. Wenn es mit Osziprobe
besser wird, ist das ein typisches Zeichen dafür, selbst wenn man es auf
dem Oszi nicht erkennen kann.
ich habe das ganze schon auf global_slow_slew_rate eingestellt, damit es
nicht so steile flanken gibt, ein muss i.V. mit so einem alten Atari.
Ich versteh nicht ganz, was an den Chips langsam sein soll wenn man
bedenkt, daß die schnellsten signale nur 1.77Mhz sind (CLK) alles andere
ist nochmal die hälfte...
der Cylone1 ist zwar älter aber für diese Zwecke doch völlig
ausreichend.
(Denke ich so)
Ich muss dazusagen, daß es bereits viel besser schon lief, aber
irgendwas habe ich wohl geändert, was das schreiben fast nicht mehr
zulässt. Ich finds einfach nicht...
> damit es nicht so steile flanken gibt,
Und selbst die werden noch viel steiler sein, als das Original.
> was an den Chips langsam sein soll wenn man bedenkt, daß die> schnellsten signale nur 1.77Mhz sind (CLK)
Mit alt meinte ich die Chips aus der Atari-Zeit. Wenn da ein Signal mal
für 5ns durch Ringing kurz High wurde, ist das meist untergegangen...
> was das schreiben fast nicht mehr zulässt.
Fast nicht mehr klingt nach Timing/Signalintegritätsproblemen.
Ha, ich hab das Problem gelöst:
Irgendwo hatte ich ja gelesen, man sollte Prozesse am Besten bei
steigender/fallender Flanke des Taktes laufen lassen...
Im Fall meines Bustreiber-Prozesses darf das aber nicht nur bei
steigender Flanke passieren, sondern immer wenn der Takt HI ist!
Allerdings gab es immer viele böse Latchesn wenn ich das so shrieb:
if (phi2 = '1') then ....
also hab ich
if rising_edge(phi2) then
geschrieben. Die Folge war, daß zwar keine Latches erzeugt wurden aber
die Bustreiber waren nur sehr kurz "an".
Nun habe ich herausgefunden (Danke HIAS), das die Latches erzeugt
wurden, weil ich nicht alle Signale gesetzt hatte...
Hier mal der alte falsche Code und dann der richtige:
----------------------------------------------------------------------
set_bustreiber: process(dout, dout_enable, ram_rom_access, phi2, rw)
begin
adress_en <= '0';
adress_dir <= '0';
if rising_edge(phi2) then
if (rw = '1') then
if (ram_rom_access = true) then
data_en <= '1';
else
if (dout_enable) then
data_dir <= '1';
data_en <= '0';
data <= dout;
else
data_dir <= '0';
data_en <= '0';
data <= (others => '1');
end if;
end if;
end if;
end if;
end process set_bustreiber;
---------------------------------------------------------------
der neue Code:
------------------------------------------------------------------------
set_bustreiber: process(data_out, data_out_enable, ram_rom_access, phi2,
rw)
begin
data_dir <= '0';
data_en <= '0';
data <= (others => 'Z');
adress_en <= '0';
adress_dir <= '0';
if (phi2 = '1') then
adress_en <= '0';
adress_dir <= '0';
if (rw = '1') then
if (ram_rom_access = true) then
data_en <= '1';
else
if (data_out_enable) then
data_dir <= '1';
data_en <= '0';
data <= data_out;
end if;
end if;
end if;
end if;
end process set_bustreiber;
------------------------------------------------------------------------
-
So,nun funktioniert es prima!
@Georg:
Ja, die Signale auf dem Atari haben uns jahrelang Nerven gekostet!
Wenn man sich den Systemtakt anschaut, denkt man, ein 3jähriger hätte
versucht, ne Sinuskurve zu malen :-)
Irgendwann haben wir auch rausgefunden, daß nicht nur bedingt durch die
schlechte Form des Taktes sondern auch durch eigentlich zu lange Hi-Zeit
des Taktes oft Schreibprobleme (mit selbst entwickelter HW und
moderneren Chips) gab. Nach einfügen eines 74LS123 wird dieser Takt nun
etwas verkürtzt und gleichzeitig in Rechteck Form gebracht.
Das die Ataris selber so gut und stabil laufen, kann man eigentlich
nicht verstehen. Aber NMOS war was feines...
Hallo,
Da ich ein paar alte Projekt-Leichen zuende bringen möchte,
muss ich diesen alten Text mal wieder hervorholen...
Die oben beschriebene Platine mit dem FPGA läuft bis heute nicht so gewünscht.
Das Hauptproblem ist folgendes:
es soll bei Zugriff auf eine (irgendeine vorher definierte) Adresse
-lesend,schreibend oder beides- diese ausgeblendet werden und "eigener" Inhalt eingeblendet werden, z.B. von einem Eprom.
Das merkwürdige ist: in einem Speicherbereich von D300-D3FF welcher von einem GAL des ATARIs für eine 6520 PIA ausdekodiert ist (diese belegt D300-D303) funktioniert das einblenden eigener Inhalte, in dem Testfall ein Text der vom FPGA dort eingeblendet wird.
Möchte ich nun aber einen 8 oder 16KB großen Block in einem anderen Bereich einblenden, hängt sich der ATARI auf.
Aber nicht nur bei solchen größeren Speicherblöcken:
Auch bei einer einzigen Adresse z.B. im 2000er Bereich funktioniert dies nicht. Dann steht dort nur FF und nicht der Wert der eingeblendet werden soll.
Dies ist noch das einzige Problem, wäre das gelöst könnte man die Platine als super Debug/Entwicklungshilfe benutzen.
Vielleicht kann ja mal jemand über das VHDL Listing schauen?
(Manchmal programmiert man ja blind um den Fehler herum, wieder und wieder...)
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.NUMERIC_STD.ALL;
Der Code sowie auch Quartus 11 stammen ja aus der Vergangenheit,
warum sollte das nun nicht ok sein?
Sowas ist auch ungünstig:
test : process(clk50, phi2, phi2short, option_test_quarz, option_test_schalter)
begin
1
if falling_edge(clk50) then -- ok, der quarzoszillator funktioniert!
2
3
if (option_test_quarz = true) then
-- ...
1
end if;
2
3
if falling_edge(phi2) then
4
5
if (option_test_schalter = true) then
-- ...
1
end if;
2
3
end if;
end process test;
Gehört in die Sensitivity list nur der Takt (und ein evtl.
vorhandener asynchroner Reset) und nicht der ganze andere
Kladderadatsch.
In einem Prozess auf zwei unterschiedliche Taktsignale zu reagieren
stellt u.U. den Synthesizer auf eine harte Probe.
Dies ist eigentlich nur eine Testroutine um während der Entwicklung
eine Art Lebenszeichen anzuzeigen, daher der name test.
Ich glaube nicht, daß sich dieser Codeabschnitt auf das eigentliche Problem deutet.
Nein, müsste ich dann nicht auch den kompletten Atari simulieren?
Jain. Ich simuliere immer nur soweit, das ich sehen kann, ob etwas funktioniert.
Das muß nicht die komplette CPU oder Peripherie sein.
Wenn ich ein Modul habe, was an einem Bus hängt, dann simuliere ich eben die Buszugriffe auf mein Modul.
Falls die CPU als VHDL vorliegt, kann es auch einfacher sein, sich kleine Testprogramme in Assembler zu schreiben und die CPU gleich mit zu simulieren.
Wolfram F. schrieb:
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.NUMERIC_STD.ALL;
Der Code sowie auch Quartus 11 stammen ja aus der Vergangenheit,
warum sollte das nun nicht ok sein?
Weil std_logic_arith und numeric_std an einigen Stellen nicht kompatibel zueinander sind.
Hier kannst du auf beide Bibliotheken verzichten, weil gar nicht gerechnet wird.
Und falls es doch was zu rechnen gibt, nimm die numeric_std (und nur die, keine arith _irgendwas), die ist in sich konsistent.
Dies ist eigentlich nur eine Testroutine um während der Entwicklung
eine Art Lebenszeichen anzuzeigen, daher der name test.
Ja, mag sein, aber nur weil es eine Testroutine ist, sollte man nicht in schlechten Stil verfallen. Das färbt sonst ab.
Ich glaube nicht, daß sich dieser Codeabschnitt auf das eigentliche
Problem deutet.
Richtig. Anbei eine rudimentäre Testbench, die nur ein paar Takte zur Verfügung stellt. Da müßten jetzt noch die zu verifizierenden Zugriffe drin abgebildet werden...
ich bekomme etliche Warnungen vom Quartus-Compiler,
Brauchbarer sind Warnungen von einem Simulator.
Ich habe noch kein umfangreicheres Projekt gehabt, was ohne Warnungen durch einen Synthesizer gegangen ist. Wenn man seinen Code dann anpasst, poppen nur andere Warnungen auf...
Warning: Skipped module PowerPlay
Power Analyzer due to the assignment FLOW_ENABLE_POWER_ANALYZER
Warning: Skipped module PowerPlay Power Analyzer due to the assignment
FLOW_ENABLE_POWER_ANALYZER
Eine Leistungsanalyse wird gebraucht, wenn die Stromversorgung optimiert werden muß. Hier m.E. nicht relevant.
Warning: Parallel compilation is not licensed and has been disabled
Unwichtig, im Hobby hat man Zeit.
Warning (10540): VHDL Signal Declaration warning at
ATARI_PBI_FPGA.vhd(83): used explicit default value for signal "IRQ"
because signal was never assigned a value
Die Default-Zuweisung an den Signalausgängen würde ich wegmachen.
Verschiebe das besser in den Codeteil:
1
signal...
2
begin
3
-- defaults
4
trigger<='0';
5
IRQ<='0';
6
refresh<='0';
7
-- hier gehts weiter
8
...
Warning (10036): Verilog HDL or VHDL warning at ATARI_PBI_FPGA.vhd(192):
object "portb" assigned a value but never read
Dem sollte man nachgehen. Üblicherweise werden alle Signale gebraucht.
BTW: Kannst du evtl. den Code vom PIA bereitstellen? Dann könnte man den gleich mit simulieren.
Warning (10540): VHDL Signal Declaration warning at
ATARI_PBI_FPGA.vhd(199): used explicit default value for signal
"option_test_quarz" because signal was never assigned a value
"option_test_schalter" because signal was never assigned a value
"option_display" because signal was never assigned a value
"option_flash_ram", which holds its previous value in one or more paths
Hier würde ich das Signal ggf. in eine Konstante oder einen Generic umwandeln.
Die Schalter werden ja nicht zur Laufzeit angepasst.
ATARI_PBI_FPGA.vhd(722): signal "adr" is read inside the Process
Statement but isn't in the Process Statement's sensitivity list
Sowas ist ernstzunehmen, da hier Simulation und FPGA unterschiedlich reagieren.
Warning: The following nodes have both tri-state and non-tri-state
drivers
Das klingt wild, ich überblicke es aber gerade nicht. Möglicherweise liegt es daran, das option_flash_ram ein Signal ist.
Irgendwas passiert da im Adressbreich um 0xD3xx herum, aber ob es das
ist, was dir vorschwebt, weiß ich nicht...
Ja, das ist richtig:
Die PIA sitzt mit ihren 4 Aressen in D300-D303, der Bereich von D304-D3FF
ist im Atari unbenutz, dort blende ich Register für Debug-Adresse und einiges mehr ein, auch zum Test einen kleinen Teil eines Eproms und Srams sowie etwas Text. Siehe Anfang vom Listing.
Das merkwürdige ist, in diesem D3XX Bereich funktioniert das alles prima,
wenn ich aber versuche z.B. ein anderes Betriebssystem-ROM in C000-FFFF oder ein Modul-ROM in A000-BFFF einzublenden, stürzt der Atari ab.
Selbst, wenn ich nur in einer bestimmte Adresse z.B. 2000 bei Zugriff einen bestimmten Wert einblende, ist dieser nicht da.
Dazu muss ich noch erwähnen:
Es gibt im Atari eine Leitung die Refresh heisst.
Wenn diese Leitung auf LOW gezogen wird, wird RAM und ROM (je nach Adressbereich) ausgeblendet.
Genau das wird im D303-D3FF Bereich gemacht:
Bei Zugriff REF setzen, damit ist der Speicherbereich "frei", dann "meine" Werte dort einblenden.
Der Adressbereich des Ataris ist folgendermaßen aufgebaut:
0000-7FFF RAM
8000-9FFF RAM oder Steckmodul-ROM
A000-BFFF RAM oder Steckmodul oder BASIC-ROM
C000-CFFF RAM oder Betriebssystem-ROM
D000-D7FF Hardware-Register
D800-DFFF RAM oder Paralellbus
E000-FFFF RAM oder Betriebssystem-ROM
Ich habe Modelsim verwendet. Das gab es m.E. früher auch mal bei Quartus/Altera bzw. ISE/Xilinx mit der Einschränkung für kleine Designs dazu. Xilinx ist später auf das eigene ISIM umgeschwenkt.
Prinzipiell sollte jeder VHDL-Simulator funktionieren.
Mit ghdl und gtkwave gibt es auch eine open source-Lösung.
Die Leitung des ATARIs um Speicher auszublenden muss auf LOW gezogen werden.
Da ich ursprünglich dafür einen Transistor geplant hatte es aber verworfen habe, war noch die Invertierung des FPGA Ausgangs drin.
Habe nun den Status des Pins auf "Z" gemacht und die aktivierung auf "0" anstatt "1". Keine Abstürze mehr,
zugriff auf alle Adressen!
WAS für ein blöder Fehler! All die Jahre hätte der schon sinnvolle Dinge tun können...
