MEMCTRL DESIGN

I’ve discussed the responsibilities of MEMCTRL design: address decoding, on-chip bus control, and external RAM control. Now, let’s review its implementation (see Figure 6).

In address decoding, if the next access is a load/store to address FFxx, the access is to memory-mapped I/O, and SELIO is asserted. Otherwise, it’s a RAM access.

Within each peripheral’s DCTRL instance, its SELi (decoded from AN7:5) and CTRLSELIO combine to develop that peripheral’s output and clock enables.

For bus control, the current state of the memory transaction finite state machine determines which controls are asserted. The CPU asserts ACE (address clock enable) to request the next transaction and awaits RDY. MEMCTRL decodes the request, and the FSM enters the IO, RAMRD, or RAMWR state. The latter has three sub-states—W12, W34, and W56—corresponding to pairs of the W1–W6 half-states described previously.

In the IO state, RDY is asserted unless the selected peripheral deasserts CTRL0, the I/O ready line, thereby inserting a wait state.

In the RAMRD state, RDY is asserted immediately because all RAM reads require only one clock cycle. In the RAMWR state, RDY is asserted on W34 for byte stores and on W56 for word stores.

The write controller uses flip-flops W23_45 and W45, which are clocked on CLK falling edges. So, W34 is true during W3 and W4, while W45 is true during W4 and W5. From the W* signals you derive glitch-free control signals XA_0, /WE, /OE, and so on.

The rest of MEMCTRL is straightforward. Note how E encodes (renames) the various peripheral control signals to CTRL15:0.

I technology-mapped some logic using FMAPs. Timing analysis had revealed poor automatic mapping of this logic. This change shaved a few nanoseconds off the critical path.

Now that we’ve covered the implementation of MEMCTRL, let’s turn our attention to peripherals.