Meinst Du Treiberkapazitäten des CPLD, Ressourcenverbrauch im CPLD oder meine geistigen Kapazitäten?mkarcher hat geschrieben: Fr 11. Nov 2022, 00:19 Ich vermute, dass Dir die Kapazität nicht reicht(..)
An letzterem arbeite ich ja gerade.
Ich will ja nicht den Prozessor nachbauen, sondern die Unterschiede zwischen 68SEC000 und 68000 im CPLD emulieren. Das ist der Wegfall der drei Signale für 6800 Peripheriebausteine und der Übergang von einem 3-line auf ein 2-line Arbitrierungsprotokoll.
Für ersteres gibt es die AN911 von Motorola, da ist das für 020 beschrieben, der sich dieselben Pins eingespart hat.
Und für letzteres gibt es eine 1-seitige AN, wo Motorola das mit ein paar NOT, AND und einen FF beschreibt. Also nicht unbedingt Raketentechnik. Und von den SECs habe ich noch einige hier in der Schublade.
Da sehe ich prinzipiell drei Knackpunkte:mkarcher hat geschrieben: Fr 11. Nov 2022, 00:19(..) dass es in der Endzeit von EDO für Grafikkarten (z.B. Virge/DX, Voodo II) Chips mit 25ns /RAS-Zugriffszeit und 10ns /CAS-Zykluszeit gab.
- woher heute noch zuverlässig bekommen? Also nicht ungetestet von irgendwelchen Grafikkarten runtergelötet.
- Für 8MB bräuchte ich ja 16 (!) Stück davon. -> PCB Fläche -> wie im Gehäuse unterbringen? -> und (untergeordnet) PCB Preis
- Kostenpunkt! Die dürften aufgrund ihrer vermutlich nur noch minimal erhältlichen Stückzahl einen erklecklichen Wert haben. Plus Retroaufschlag.
Für mich erstmal ein no-go: für 8MB 3.3V SRAM (55ns) zahle ich bei Mouser knapp 40,-€ und in 10ns sind es 60,-€ (beides brutto).
Somit wird mir auch klar, warum die nicht mit dem doppelten Takt auf einem CLK Pin gefahren werden, sondern zwei um 180° verschobene Takte bekommen. Dann hat man quasi zwei SDR-SDRAM, jedes hängt an seinem eigenen Takt, wobei der eine das Inverse des anderen ist.mkarcher hat geschrieben: Fr 11. Nov 2022, 00:24Durch das interne Bank-Interleaving im RAM-Chip kommt man auf die doppelte Bus-Rate, ohne die RAM-Technik selbst ändern zu müssen.
Habe gestern meine VHDL-FSM umgestellt und bin da in das selbe Problem gelaufen wie mit dem EMS-Karten Versuch. Mir gehen die Ressourcen im CPLD aus.
Code: Alles auswählen
entity RAM is
port(
-- CPU side
CLK32 : in std_logic;
CPU_ADDR : in std_logic_vector(23 downto 1);
(..)
);
end entity;
architecture Behaviour of RAM is
(..)
signal RAM_PAGE_ACTIVE : std_logic_vector(23 downto 10);
(..)
process(CLK32) begin
if rising_edge(CLK32) then
case FSMState is
(..)
when PAGE_ACTIVATE =>
RAM_PAGE_ACTIVE <= CPU_ADDR(23 downto 10);
(..)
when BANK_IS_ACTIVE =>
if (CPU_ADDR(23 downto 10) = RAM_PAGE_ACTIVE) then -- um diesen Vergleich geht es
(..)
end case;
end if;
end process;
end architecture;
Klappt dann irgendwann auch, aber der Maximaltakt, mit dem ich das CPLD fahren kann, sinkt von 87MHz auf 28MHz! Vollkommen inakzeptabel.
Ich habe auch schon die Zuweisung an RAM_PAGE_ACTIVE aus dem Process herausgezogen und mache ihn kombinatorisch und setze ein std_logic als Flag ob gleich oder ungleich und teste im Process dann auf das Flag. Hat nichts gebracht: der ProductTerm Verbrauch ging zwar etwas runter, letztendlich blieb der Maximaltakt sogar minimal unter meiner getakteten Lösung.
An anderen Stellen prüfe ich, ob der Adressraum meines SDRAM angesprochen wird z.B. so:
Code: Alles auswählen
if (CPU_ADDR(23 downto 20) = "1100") then
(..)
end if;
Entweder ich mache hier grundlegend etwas falsch - was ich nie ausschließen würde - oder das ist einfach so. In dem Fall müsste ich den Vergleich auslagern:
- 2x 74x573, die mir die Adresse latchen - also Ersatz für RAM_PAGE_ACTIVE
- 2x 74x688/74x521 für den Vergleich von RAM_PAGE_ACTIVE mit der aktuellen Adresse, die die CPU ausgibt
