Macintosh-HW/Warp-SE
1
0
Fork 0
mirror of https://github.com/garrettsworkshop/Warp-SE.git synced 2024-06-06 07:29:28 +00:00
Code Issues Projects Releases Wiki Activity

Documentation update

Browse Source
This commit is contained in:
Zane Kaminski 2021-11-02 14:23:38 -04:00
parent e6e0c528f0
commit 169d96f84b
3 changed files with 56 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
Docs/CPLD.graffle
View File

Binary file not shown.

BIN
Docs/CPLD.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1.2 MiB

After

Width:  |  Height:  |  Size: 1.4 MiB

110
Docs/index.html
View File

@ -84,7 +84,7 @@ There are some details of the MC68000 bus cycle that complicate the synchronizat
Primarily, /AS falls after a rising edge of the clock but rises after a falling edge. <br/>
Since the worst-case clock-to-output delay of MC68000 is equal to half of one clock cycle, <br/>
attempting to detect bus activity by registering /AS strictly on the rising or falling edge
would result in entrance into a metastable state. <br/>
might result in entrance into a metastable state. <br/>
Therefore we introduce the "bus active" BACT signal. BACT is the disjunction of the address strobe asynchronously and as registered on the previous falling edge of the FSB clock. <br/>
The key useful feature of the BACT signal is that it is always valid at the rising edge of FCLK.
</p>
@ -101,7 +101,7 @@ The key useful feature of the BACT signal is that it is always valid at the risi
{name: 'Ready0', wave: 'x122x.', phase:-0.20, period: 2},
{name: 'Ready1', wave: 'x122x.', phase:-0.20, period: 2},
{name: 'Ready2', wave: 'x122x.', phase:-0.20, period: 2},
{name: 'Ready', wave: 'x122x.', phase:-0.20, period: 2},
{name: 'Ready', wave: 'x1..x.', phase:-0.20, period: 2},
]}
</script><br/><p>
Given BACT, the FSB controller asserts either /DTACK or /VPA when BACT is true and removes both /DTACK and /VPA when BACT is false. <br/>
@ -127,7 +127,7 @@ Note that MC68000's "/AS inactive-to-/DTACK inactive" parameter of two clock cyc
{name: 'Ready0', wave: 'x10...x.', phase:-0.20, period: 2},
{name: 'Ready1', wave: 'x0.10.x.', phase:-0.20, period: 2},
{name: 'Ready2', wave: 'x010..x.', phase:-0.20, period: 2},
{name: 'Ready', wave: 'x0.12.x.', phase:-0.20, period: 2},
{name: 'Ready', wave: 'x0.1..x.', phase:-0.20, period: 2},
]}
</script><br/><p>
As discussed, the Ready signals do not each need to be active all at once. The FSB controller "remembers" that each Ready signal has been asserted. <br/>
@ -204,14 +204,14 @@ 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
the MC68k's assertion of /AS and when it latches data from the bus. <br/>
Subtracting the 25ns /AS tCO and 5ns data in tSU, that leaves only 70ns during which to initiate and complete a DRAM access,
not accounting for any RAS control delay in the CPLD. <br/>
not accounting for any RAS delay in the CPLD. <br/>
Therefore to minimize RAM access latency, RAS is implemented not as a registered output
but as an asynchronous decode of the address, /AS, and the internal RAS enable signal. <br/>
With 10ns delay in the CPLD, 25 MHz operation with 60ns DRAM is just possible.
</p><p>
Similarly, the RA multiplexed DRAM address bus is an asynchronous multiplexer controlled by the RASEL signal <br/>
which outputs row addresses to the DRAM array when RASEL is low and column addresses when RASEL is high. <br/>
The /CAS signal is a function of RASEL, which changes after FCLK rises. If RASEL is high at the next falling edge, /CAS is asserted.
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.
</p><p>
"RS" is the RAM state. The RS state changes after the rising edge of the clock
@ -227,8 +227,8 @@ in preparation for the next DRAM access cycle. RS6 always transitions to RS7. <b
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. <br/>
RS7 transitions to RS2 if a refresh request is pending, otherwise RS7 transitions to RS0. <br/>
The states RS1 and RS2-RS4 will be discussed in association with the subsequent refresh cycle diagrams. <br/>
RAMReady is used along with a RAM select signal to generate the Ready0 signal input to the FSB controller.
RAMReady is high if and only if the RAM state is in RS0.<br/>
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.<br/>
</p><p>
Also notice how, during write cycles,
it is undefined whether the cycle is conducted as an "early write" or an "OE-controlled write" cycle. <br/>
@ -244,7 +244,7 @@ Since /OE is held high during write cycles, the order of the /WE signals and /CA
{name: 'A', wave: 'x2......x.', phase: 0.25, period: 2, data:['000000-3FFFFF']},
{name: 'RW', wave: 'x..1............x...', phase: 0.25, period: 1, data:['read or write','read or write']},
{name: 'AS', wave: '1...x0........................x1.......', phase:-0.25, period: 0.5},
{name: 'Ready', wave: '0.....1...', phase:-0.20, period: 2},
{name: 'Ready', wave: '0....1....', phase:-0.20, period: 2},
{name: 'DTACK', wave: '1.....0..1', phase:-0.20, period: 2},
{name: 'D (RD)', wave: 'z....x2..z..........', phase:-0.30},
{name: 'D (WR)', wave: 'z..x2...........z...', phase: 0.00},
@ -288,8 +288,7 @@ DRAM controller conform to theDRAM "hidden refresh" protocol but it is not neces
]}</script><br/><p>
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.
</p><p>
RAM states RS1, RS2, RS3, RS4, and RS7 are used for refresh. <br/>
RS1 is used when initiating a refresh during a long-running /RAS cycle and will be discussed subsequently. <br/>
RAM states RS2, RS3, RS4, and RS7 are used for refresh. <br/>
RS2-RS4 implement the main refresh behavior. <br/>
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. <br/>
@ -297,11 +296,11 @@ With RASEN low, /AS activity does not cause a /RAS pulse and the DRAM controller
to initiate refresh cycles. <br/>
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. <br/>
RREQ is also cleared in RS2 since entrance into RS11 constitutes acceptance of a pending refresh request. <br/>
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. <br/>
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. <br/>
RREQ is cleared after the first rising edge on which RefRAS is active.<br/>
In RS7, /RAS and /CAS remain inactive. RS7 serves to implement the requisite RAS precharge time between DRAM cycles.<br/>
RASEN is brought high again after the rising edge concluding RS7 and RS7 transitions to RS0 and the DRAM is considered idle again.<br/>
</p><p>
@ -340,14 +339,14 @@ after the previous DRAM access is terminated before /RAS is pulsed for refresh.
<h3 id="t9">9. Refresh Immediately Following DRAM Access - Bus Transaction Terminated While Refresh In-Progress</h3>
<script type="WaveDrom">
{signal: [
{name: 'MCLK', wave: 'p.......', phase: 0.00, period: 2},
{name: 'AS', wave: '0.................x1....x......', phase:-0.25, period:0.5},
{name: 'RS', wave: '22222222', phase:-0.20, period: 2, data:[6,7,1,2,3,4,7,0,0,0,0]},
{name: 'RefReq', wave: '21...0..', phase:-0.20, period: 2},
{name: 'RASEN', wave: '1.0....1', phase:-0.20, period: 2},
{name: 'RRAS', wave: '1...0.1.', phase:-0.20, period:2},
{name: 'RAS', wave: '0.......1.......0.......1...x..', phase:-0.40, period:0.5},
{name: 'CAS', wave: '0.1.0.1.', phase: 0.80, period: 2},
{name: 'MCLK', wave: 'p......', phase: 0.00, period: 2},
{name: 'AS', wave: '0.............x1....x......', phase:-0.25, period:0.5},
{name: 'RS', wave: '2222222', phase:-0.20, period: 2, data:[6,7,2,3,4,7,0,0,0,0]},
{name: 'RefReq', wave: '21..0..', phase:-0.20, period: 2},
{name: 'RASEN', wave: '1.0...1', phase:-0.20, period: 2},
{name: 'RRAS', wave: '1..0.1.', phase:-0.20, period:2},
{name: 'RAS', wave: '0.......1...0.......1...x..', phase:-0.40, period:0.5},
{name: 'CAS', wave: '0.10.1.', phase: 0.80, period: 2},
]}
</script><br/><p>
This diagram shows the case where a refresh request occurs during a long-running DRAM access
@ -358,22 +357,22 @@ Therefore we must provide for the case where a DRAM access completes and a refre
In this case, the rising edge of RASEN causes /RAS to go inactive, as opposed to the rising edge of /AS. <br/>
Therefore, the /RAS precharge pulse width in this case is much shorter than
a refresh occurring during idle or immediately following a DRAM access. <br/>
In order to satisfy the tRP precharge time and tRC cycle timing parameters,
an additional state, RS1, must be inserted in which /RAS and /CAS are both held in precharge.
At 25 MHz, the /RAS precharge width is only 40ns. This is the minimum tRP for 60ns DRAM and is the tightest timing parameter in the Warp-SE. <br/>
We could purpose RS1 to add additional precharge time if necessary.
</p>
<h3 id="t10">10. Refresh Immediately Following DRAM Access - Bus Transaction Terminated After Refresh Completes</h3>
<script type="WaveDrom">
{signal: [
{name: 'MCLK', wave: 'p.........', phase: 0.00, period: 2},
{name: 'AS', wave: '0.............................x1....x...', phase:-0.25, period:0.5},
{name: 'RS', wave: '2222222222', phase:-0.20, period: 2, data:[6,7,1,2,3,4,7,0,0,0]},
{name: 'RefReq', wave: '21.0......', phase:-0.20, period: 2},
{name: 'RASEN', wave: '1.0......1', phase:-0.20, period: 2},
{name: 'RRAS', wave: '1...0.1...', phase:-0.20, period:2},
{name: 'RAS', wave: '0.......1.......0.......1...........x...', phase:-0.40, period:0.5},
{name: 'CAS', wave: '0.1.0.1...', phase: 0.80, period: 2},
{name: 'MCLK', wave: 'p........', phase: 0.00, period: 2},
{name: 'AS', wave: '0.........................x1....x...', phase:-0.25, period:0.5},
{name: 'RS', wave: '222222222', phase:-0.20, period: 2, data:[6,7,2,3,4,7,0,0,0]},
{name: 'RefReq', wave: '21..0....', phase:-0.20, period: 2},
{name: 'RASEN', wave: '1.0.....1', phase:-0.20, period: 2},
{name: 'RRAS', wave: '1..0.1...', phase:-0.20, period:2},
{name: 'RAS', wave: '0.......1...0.......1...........x...', phase:-0.40, period:0.5},
{name: 'CAS', wave: '0.10.1...', phase: 0.80, period: 2},
]}
</script><br/><p>
This diagram shows the case where a refresh request occurs during a long-running DRAM access
@ -381,21 +380,22 @@ and the /AS cycle does not terminate before the refresh ends.
</p><p>
This case is similar to the previous but there is a key difference.
/AS does not rise until after the refresh cycle completes. <br/>
Therefore if RASEN were brought high upon exit from RS7 into RS0, there may be an improperly-short /RAS pulse. <br/>
Therefore if RASEN were brought high upon exit from RS7 into RS0, there may be an improperly-short /RAS pulse
terminated by the rising edge of the /AS. <br/>
Consequently RASEN enablement is held off the first rising edge during which BACT is low.
</p>
<h3 id="t11">11. Refresh in the "Middle" of DRAM Access</h3>
<script type="WaveDrom">
{signal: [
{name: 'MCLK', wave: 'p.......', phase: 0.00, period: 2},
{name: 'AS', wave: '0...............................', phase:-0.25, period:0.5},
{name: 'RS', wave: '22222222', phase:-0.20, period: 2, data:[6,7,0,0,0,1,2,3]},
{name: 'RefReq', wave: '0...1...', phase:-0.20, period: 2},
{name: 'RASEN', wave: '1....0..', phase:-0.20, period: 2},
{name: 'RRAS', wave: '1......0', phase:-0.20, period:2},
{name: 'RAS', wave: '0...................1.......0...', phase:-0.40, period:0.5},
{name: 'CAS', wave: '0.1....0', phase: 0.80, period: 2},
{name: 'MCLK', wave: 'p......', phase: 0.00, period: 2},
{name: 'AS', wave: '0...........................', phase:-0.25, period:0.5},
{name: 'RS', wave: '2222222', phase:-0.20, period: 2, data:[6,7,0,0,0,2,3]},
{name: 'RefReq', wave: '0...1..', phase:-0.20, period: 2},
{name: 'RASEN', wave: '1....0.', phase:-0.20, period: 2},
{name: 'RRAS', wave: '1.....0', phase:-0.20, period:2},
{name: 'RAS', wave: '0...................1...0...', phase:-0.40, period:0.5},
{name: 'CAS', wave: '0.1...0', phase: 0.80, period: 2},
]}
</script><br/><p>
This diagram shows the case where a refresh request occurs in the "middle" of a long-running DRAM access. <br/>
@ -405,21 +405,21 @@ The remainder of the timing is given by diagrams 9 or 10.
<h3 id="t12">12. Concurrent DRAM Access and Refresh Requests</h3>
<script type="WaveDrom">
{signal: [
{name: 'MCLK', wave: 'p..........', phase: 0.00, period: 2},
{name: 'A', wave: 'x2.......x.', phase: 0.25, period: 2, data:['000000-4FFFFF']},
{name: '/AS', wave: '1..x0............................x1........', phase:-0.75, period: 0.5},
{name: 'DTACK', wave: '1......0..1', phase:-0.30, period: 2},
{name: 'DS (RD)', wave: '1..x0............................x1.......', phase:-0.75, period: 0.5},
{name: 'OE (RD)', wave: '1...x.0..........................x.1.....', phase:-0.75, period: 0.5},
{name: 'DS (WR)', wave: '1......x0........................x1.......', phase:-0.75, period: 0.5},
{name: 'WE (WR)', wave: '1.......................0........x.1......', phase:-0.75, period: 0.5},
{name: 'RS', wave: '22222222222', phase:-0.20, period: 2, data:[0,2,3,4,6,7,0,5,6,7,0]},
{name: 'Ready0', wave: 'x0....10.x.', phase:-0.20, period: 2},
{name: 'RefReq', wave: '1..0.......', phase:-0.20, period: 2},
{name: 'RASEN', wave: '10....1....', phase:-0.20, period: 2},
{name: 'RRAS', wave: '1...0...1.............', phase:-0.20},
{name: '/RAS', wave: '1.......0.......1.......0.........x.1......', phase:-0.45, period: 0.5},
{name: '/CAS', wave: '1.0.1...0.1', phase: 0.70, period: 2},
{name: 'MCLK', wave: 'p.........', phase: 0.00, period: 2},
{name: 'A', wave: 'x2......x.', phase: 0.25, period: 2, data:['000000-4FFFFF']},
{name: '/AS', wave: '1..x0........................x1........', phase:-0.75, period: 0.5},
{name: 'DTACK', wave: '1.....0..1', phase:-0.30, period: 2},
{name: 'DS (RD)', wave: '1..x0........................x1.......', phase:-0.75, period: 0.5},
{name: 'OE (RD)', wave: '1...x.0......................x.1.....', phase:-0.75, period: 0.5},
{name: 'DS (WR)', wave: '1......x0....................x1.......', phase:-0.75, period: 0.5},
{name: 'WE (WR)', wave: '1.......................0....x.1......', phase:-0.75, period: 0.5},
{name: 'RS', wave: '2222222222', phase:-0.20, period: 2, data:[0,2,3,4,7,0,5,6,7,0]},
{name: 'Ready0', wave: 'x0...10.x.', phase:-0.20, period: 2},
{name: 'RefReq', wave: '1..0......', phase:-0.20, period: 2},
{name: 'RASEN', wave: '10...1....', phase:-0.20, period: 2},
{name: 'RRAS', wave: '1...0...1...........', phase:-0.20},
{name: '/RAS', wave: '1.......0.......1...0.........x.1......', phase:-0.45, period: 0.5},
{name: '/CAS', wave: '1.0.1..0.1', phase: 0.70, period: 2},
]}
</script><br/><p>
This diagram shows the timing of a refresh starting concurrently with the beginning of a RAM access cycle.
@ -659,7 +659,7 @@ The IOB slave port holds Ready1 low until the I/O bus transaction is completed.
<script type="WaveDrom">
{signal: [
{name: 'MCLK', wave: 'p...|..|..', period: 2},
{name: 'IOAS', wave: '010.|..|..', period: 2, phase:-0.3},
{name: 'IOSTART', wave: '010.|..|..', period: 2, phase:-0.3},
{name: 'PS', wave: '2222|22|22', period: 2, data:[0,0,2,2,2,1,1,0], phase:-0.3},
{name: 'IOACT', wave: '0...|1.|0.', phase:-0.3, period: 2},
{name: 'IOREQ', wave: '0.1.|.0|..', phase:-0.3, period: 2},
@ -673,7 +673,7 @@ The IOB slave port holds Ready1 low until the I/O bus transaction is completed.
This diagram shows the behavior of the I/O bus slave port controller under a single read/write request.
</p><p>
Here we are just showing the signals relevant to the I/O bus slave port controller rather than all of the M68k FSB signals. <br/>
IOAS is a decode of the address, the FSB's /AS, and the IODone signal and represents when an I/O bus cycle request
IOSTART true when the I/O bus space is selected, BACT is low, and the I/O request has not been recognized this current BACT cycle.
has been submitted but not yet accepted by the I/O bus slave port controller. <br/>
If the posted write FIFO is empty then the IOB slave port controller can submit
a new access request to the master controller. <br/>