diff --git a/Documentation/index.html b/Documentation/index.html index ee92e93..27e4d3a 100644 --- a/Documentation/index.html +++ b/Documentation/index.html @@ -182,27 +182,30 @@ The Ready signals are always high during ROM access so all ROM accesses complete

5. Back-to-Back RAM Access


+{name: 'CAS', wave: '1..01..01.', phase: 0.90, period: 2}, +]}

This diagram introduces the DRAM access timing.

At 25 MHz for a 4-clock read cycle, there are only 2.5 clock cycles (100 ns) between @@ -218,116 +221,117 @@ which outputs row addresses to the DRAM array when RASEL is low and column addre The /CAS signal is a function of RASEL. RASEL changes after FCLK rises. If RASEL is high at the next falling edge, /CAS is asserted. Otherwise if RASEL is low, /CAS is deasserted at the next falling edge.

-"RS" is the RAM state. The RS state changes after the rising edge of the clock -and can take on values 0-7.
-In RS0, the RAM is considered to be idle.
-At the rising edge of the clock in RS0 a RAM cycle begins if, if /AS is asserted, -a RAM address is present, and a RAM cycle has not already occurred for this /AS cycle.
-In this case, we know that /RAS has been active for at least 10 nanoseconds, so RASEL is brogught high.
-This switches the RA bus from row to column addresses and RS0 transitions to RS5.
-At the falling edge in the middle of RS5, /CAS is brought low. RS5 always transitions to RS6.
-At the end of RS6, RASEL is brought low again, switching the RA multiplexers back to row addresses -in preparation for the next DRAM access cycle. RS6 always transitions to RS7.
-RS7 is the state in which a RAM access or refresh is concluded. At the falling edge in the middle of RS7, /CAS is brought high.
-RS7 transitions to RS2 if a refresh request is pending, otherwise RS7 transitions to RS0.
-The states RS1 and RS2-RS4 will be discussed in association with the subsequent refresh cycle diagrams.
-The RS and RAMCS signals are used to generate the Ready0 ready signal input to the FSB. -Ready0 is high if and only if RS==0 and RAMCS is active.
-

-Also notice how, during write cycles, -it is undefined whether the cycle is conducted as an "early write" or an "OE-controlled write" cycle.
-/OE is held high at all times during write cycles, -but /LWE and /UWE are asynchronous functions of MC68k's /LDS and /UDS signals.
-It is undefined during a write cycle whether /LWE and /UWE will go low before or after /CAS falls.
-Since /OE is held high during write cycles, the order of the /WE signals and /CAS is of no consequence.

6. Long-running RAM Access


-This diagram shows the timing for a long-running RAM access, -in which the RAM read or write completes sooner than MC68k removes /AS.
+This diagram shows the timing for a long-running RAM access, in which the RAM read or write completes sooner than MC68k removes /AS.

-There are cases in which a DRAM access completes in time for termination of a 4-clock bus cycle, -but the bus cycle is lengthened because not all of the Ready signals to the FSB controller have gone high.
-If RS0 is returned to after a DRAM access but /AS remains asserted, -then the DRAM must not enter RS5-7 and thus not initiate any additional /CAS cycles.
-Notice how /CAS goes high in the middle of RS7 but /RAS stays low until the end of the /AS cycle. -Using EDO DRAM allows the data bus output to be maintained while /RAS is low.
-However, if FPM DRAM is used or if a refresh cycle occurs before /AS rises, -then maintenance of read data on the data bus falls to the bus capacitance and the bus hold resistors.
-Therefore it is best not to prolong DRAM read cycles, even when using EDO DRAM, so that there is no possibility of -an intervening DRAM refresh cycle causing the data outputs to tristate.
-Fortunately, although DRAM write cycles shadowed to main sound and video memory need to be extended -when the posted write FIFO is full, there is no need to extend DRAM read cycles.
-Therefore we do not attempt to extend the /CAS pulse to fix this problem until /AS rises since the /CAS pulse -could be interrupted by a refresh cycle anyway.
-To fix this problem, we could extend the /CAS pulse until /AS is high and have the -DRAM controller conform to the DRAM "hidden refresh" protocol but it is not necessary.

7. Refresh During Idle


This diagram shows the timing of a refresh occurring after the bus and DRAM are and have been idle for at least one clock cycle. -

-RAM states RS2, RS3, RS4, and RS7 are used for refresh.
-RS2-RS4 implement the main refresh behavior.
-When a refresh request is pending at the rising edge ending RS0 or RS7 while /RAS is inactive, -RASEN is brought low and RS2 is entered.
-With RASEN low, /AS activity does not cause a /RAS pulse and the DRAM controller uses the registered /RRAS signal -to initiate refresh cycles.
-At the falling edge in the middle of RS2, /CAS is activated. Then at the rising edge concluding RS2, /RAS is activated -and RS2 transitions to RS3.
-In RS3, /RAS and /CAS remain active, and RS3 transitions to RS4. -RS3 and RS4 serve to implement the requisite /RAS pulse width for a refresh.
-At the falling edge in the middle of RS4, /CAS is deactivated. Then at the rising edge concluding RS4, /RAS is deactivated -and RS4 transitions to RS7.
-RREQ is cleared after the first rising edge on which RefRAS is active.
-In RS7, /RAS and /CAS remain inactive. RS7 serves to implement the requisite RAS precharge time between DRAM cycles.
-RASEN is brought high again after the rising edge concluding RS7 and RS7 transitions to RS0 and the DRAM is considered idle again.
-

-Also notice how a RASEN can only be disabled if /RAS is high or if a DRAM cycle is complete, otherwise -there may be a tRAS timing violation. This constrains the timing of a refresh. +

-

8A. Refresh Immediately Following DRAM Access - Bus Transaction Terminated Immediately

+

8A. Refresh Immediately Following DRAM Access - Idle afterwards


+ + +

8B. Refresh Immediately Following DRAM Access - RAM access immediately afterwards

+
diff --git a/cpld/RAM.v b/cpld/RAM.v index 3f37739..1fb36a1 100644 --- a/cpld/RAM.v +++ b/cpld/RAM.v @@ -42,7 +42,7 @@ module RAM( assign nROMWE = !(!nAS && !nWE); /* Shared ROM and RAM /OE control */ - always @(posedge CLK) nOE <= !(BACT && !nWE && !(BACTr && DTACKr)); + always @(posedge CLK) nOE <= !(BACT && nWE && !(BACTr && DTACKr)); /* RAM address mux (and ROM address on RA8) */ // RA11 doesn't do anything so both should be identical. @@ -69,10 +69,10 @@ module RAM( always @(posedge CLK) begin case (RS[2:0]) 0: begin // Idle/ready - if (RS0toRef) begin // Go to refresh + if (RS0toRef) begin // Refresh RAS I RS <= 4; RASEL <= 0; - RASrr <= 0; + RASrr <= 1; RASEN <= 0; RAMReady <= 0; end else if (BACT && RAMCS && RASEN) begin // Access RAM @@ -95,19 +95,12 @@ module RAM( RASEN <= 0; RAMReady <= 1; end 2: begin // finish RAM access - if (DTACKr) begin // Cycle ending - RS <= 3; - RASEL <= 0; - RASrr <= 0; - RASEN <= 0; - RAMReady <= 1; - end else begin - RS <= 2; - RASEL <= 1; - RASrr <= 0; - RASEN <= 0; - RAMReady <= 1; - end + if (DTACKr) RS <= 3; // Cycle ending + else RS <= 2; // Cycle not ending yet + RASEL <= 0; + RASrr <= 0; + RASEN <= 0; + RAMReady <= 1; end 3: begin //AS cycle complete if (RefUrg) begin // Refresh RAS RS <= 4; @@ -122,32 +115,24 @@ module RAM( RASEN <= 1; RAMReady <= 1; end - end 4: begin // Refresh RAS I + end 4: begin // Refresh RAS II RS <= 5; RASEL <= 0; RASrr <= 1; RASEN <= 0; RAMReady <= 0; - end 5: begin // Refresh RAS II + end 5: begin // Refresh precharge I RS <= 6; RASEL <= 0; - RASrr <= 1; + RASrr <= 0; + RASEN <= 0; + RAMReady <= 0; + end 6: begin // Refresh precharge II + RS <= 7; + RASEL <= 0; + RASrr <= 0; RASEN <= 0; RAMReady <= 0; - end 6: begin // Refresh precharge I / II - if (RASrr) begin - RS <= 6; - RASEL <= 0; - RASrr <= 0; - RASEN <= 0; - RAMReady <= 0; - end else begin - RS <= 7; - RASEL <= 0; - RASrr <= 0; - RASEN <= 0; - RAMReady <= 0; - end end 7: begin // Reenable RAM and go to idle/ready RS <= 0; RASEL <= 0;