POC Computer Version One

[BigDumbDinosaur]

Well, the combination of the Christmas holiday and various other things had put a damper on computing activities. However, I can report that while POC V1.4 is functional, it tops out at 15 MHz. Despite using a GAL for most of the glue logic, V1.4 will not boot at 16 MHz, which means speed-wise, it’s a step back from POC V1.3 which is stable at that speed. I earlier had mentioned a timing problem with generating wait-states as the Ø2 clock is ramped up. Study of that problem has given me some insight on how to avoid it in a discrete design. I’ll come back to that shortly.

Meanwhile, I’ve been mulling what the next step should be in my computing activities. I need to get some software projects done, especially an operating system kernel, but also need a POC unit with more RAM to test that kernel, since one of its design features will be support for preemptive multitasking. In that regard, the initial plan is to “sandbox” processes in individual banks, which means I can simultaneously run as many processes as the system has extended banks. Later on as I continue kernel development, I will figure out how to run multiple processes in one bank.

Getting back to hardware, the next POC unit, V1.5, will be built around discrete logic, since none of the CPLD-based designs I’ve built to date has been stable, and I don’t want to burn up more time on what is, for now, a dead end. A 512KB unit is feasible with discrete logic, although it will be somewhat tricky to avoid timing troubles due to the more complex glue logic needed to prevent ROM and I/O hardware from being mirrored in extended banks (banks $01 through $07 in this case).

In POC V1.3, which is all discrete, the state of a signal called BNK0 tells the glue logic if the effective address is $00xxxx. If the expression BNK0 & A15 & A14 is true (where & is logical AND), I/O ($00C000-$00C7FF, mirrored at $00C800-$00CFFF) or ROM ($00D000-$00FFFF) is being addressed. That being the case, a wait-state at any Ø2 frequency above approximately 12.5 MHz would be required. Wait-states are generated by stretching the high phase of Ø2 for an additional clock cycle, which requires that the decision to wait-state be made well before the clock goes high. Of course, such a decision can't be made until the 65C816 has emitted A16-A23 on D0-D7 and those bits have been propagated through the transparent bank latch—a 74AC573, in POC V1.3.

The bank latch’s output is transformed into the BNK0 term in the BNK0 & A15 & A14 equation. In V1.3 and V1.4, BNK0 = !A16, since there is only 128KB of RAM. In V1.5 with its 512KB, the bank latch has to emit A16, A17 and A18, which means BNK0 = !(A16 | A17 | A18) (where | is logical OR). Hence the design question became one of figuring out how to generate BNK0 without using a lot of extra logic.

In considering this problem vis a vis V1.5, it seems the logical (!) way to generate BNK0 is with a three-input NOR gate, whose inputs are connected to the output of the bank latch. This gate would have to be very fast, since its prop time will be added to that of the latch, whose prop time would be added to the 65C816's tBAS (bank setup time). The 74LVC1G27, which is a three-input NOR with a very small prop time (TPD is 3.5ns maximum on 5 volts), would be ideal for this application...if it weren’t for its minuscule SOT-23 package. There are those who can manually solder SOT-23 (and smaller). I am not a member of that august group.

Along with the generation of BNK0, there is wait-stating to be considered. Having taken a fresh look at clock generation, I’ve concluded that the stretching methods concocted by Jeff (74xx163 synchronous counter) and me (a 74AC109 JK flop controlling a 74AC74 CD flop) are essentially equal in timing constraints, mainly in the available setup time before the rise of Ø2. Jeff’s method is a single-chip solution and is theoretically faster than mine in 74AC logic, which is the fastest logic in which a 5 volt version of the xx163 is available. However, if I can produce equivalent operation with a 74xx74, I’d have a single-chip solution like the synchronous counter, but with the possibility of using 74AHC logic, which aside from being marginally faster than 74AC in some respects, has less-aggressive output edges, which helps with the suppression of ringing.

So I've got some thinking to do.

[kernelthread]

BigDumbDinosaur wrote:

Wait-states are generated by stretching the high phase of Ø2 for an additional clock cycle, which requires that the decision to wait-state be made well before the clock goes high.

I don't think the bit in bold is necessarily true. If you use a slightly more complicated state machine to generate the clock you can defer the decision about whether to stretch to just before the time at which the clock would go low without stretching, which gives you an extra half clock period for the system to make up its mind.
A related problem is how to generate the chip select for a 6522 device - that does expect CS to be asserted a certain time before the clock rises, which would put you straight back into the same bad situation if you use the same clock for the CPU and the VIA. The only way I can think of to avoid this is to use a different clock, maybe running at half the CPU's nominal frequency, to clock the VIA and arrange the generation of VIA CS at the appropriate point. That would also give the advantage of a constant clock for the VIA timers so they aren't affected by the stretching.

[Dr Jefyll]

kernelthread wrote:

you can defer the decision about whether to stretch to just before the time at which the clock would go low without stretching

Yes, I like that. There is a certain complication, and it's one that's been bothering me for some time. But today things seem a little clearer.

The complication is that Phi2 is usually what's used to qualify the /WE pulse that's sent to RAM and to non-65xx peripherals. And that's fine for devices that don't need extra time, because you want the rise of Phi2 to cause /WE to go low without delay. But in the case of a device that does need extra time, there could be trouble ("rogue" writes to incorrect addresses) if Phi2 causes /WE to go low without delay.

This seems to imply that by the time Phi2 rises we need to know whether or not extra time will be required. And, in an overclocked system, knowing this by the time Phi2 rises is a problem.

Okay, so this morning I'm doing a head slap. The problem goes away if devices that need extra time don't use the same /WE pulse that's sent to fast devices. A little extra logic can give slow devices a /WE pulse of their own -- it would be a fairly minor addition to the clock-stretch circuit. Forgive me if that's what you already had in mind, kernelthread.

-- Jeff

[kernelthread]

Dr Jefyll wrote:

The complication is that Phi2 is usually what's used to qualify the /WE pulse that's sent to RAM and to non-65xx peripherals. And that's fine for devices that don't need extra time, because you want the rise of Phi2 to cause /WE to go low without delay. But in the case of a device that does need extra time, there could be trouble ("rogue" writes to incorrect addresses) if Phi2 causes /WE to go low without delay.

This seems to imply that by the time Phi2 rises we need to know whether or not extra time will be required. And, in an overclocked system, knowing this by the time Phi2 rises is a problem.

Okay, so this morning I'm doing a head slap. The problem goes away if devices that need extra time don't use the same /WE pulse that's sent to fast devices. A little extra logic can give slow devices a /WE pulse of their own -- it would be a fairly minor addition to the clock-stretch circuit. Forgive me if that's what you already had in mind, kernelthread.

-- Jeff

To be honest, I hadn't realised this might be a problem. I was just considering a system consisting of RAM, ROM and VIA(s). RAM WE can be qualified with PHI2 as usual, as can WE for Flash memory if that is being used for ROM. VIAs are a problem because the chip select has to be asserted before the VIA input clock rises. But then you also don't really want to use PHI2 as the VIA input clock because the timers will be affected by clock stretching - you ideally want a constant clock input to the VIA so you can get predictable timing intervals.

I've come up with some Verilog code (not tested) to do what I was thinking of:

Code: Select all

input FCLK;			// fast clock, 2 x nominal CPU frequency
input nRST;			// system reset signal

reg [2:0] STATE;	// Clock stretch state (see below)
reg PHI2;			// clock to CPU
reg VIA_CLK;		// clock for VIAs and similar peripherals (half nominal CPU frequency, constant frequency)
reg VIA_SEL;		// chip select for VIAs
                    // asserted when VIA_CLK is low when VIA access is needed
                    // deasserted at following VIA_CLK falling edge
reg DELAYED_SEL;    // delayed chip select for any other purpose
                    // asserted at beginning of first stretch cycle
                    // deasserted at end of bus cycle
                    // maybe useful if any device requires more settling time before RD/WR strobes activated

/* STATE values:

000     First half cycle of every bus cycle, PHI2 = 0
001     Second half cycle of every bus cycle, PHI2 = 1. Last half cycle if no stretching needed.
010     6 input clocks (3 nominal CPU cycles) remaining, PHI2 = 1
011     5 input clocks (2.5 nominal CPU cycles) remaining, PHI2 = 1
100     4 input clocks (2 nominal CPU cycles) remaining, PHI2 = 1
101     3 input clocks (1.5 nominal CPU cycles) remaining, PHI2 = 1
110     2 input clocks (1 nominal CPU cycles remaining, PHI2 = 1
111     Last half cycle following stretch, PHI2 = 1

*/

// These logic terms should be capable of evaluation within one clock period of FCLK
// It is assumed they are functions of the active address, so remain asserted for the entire bus cycle
wire STRETCH1 = ... ;	// insert logic to determine if device needs stretch by 1 cycle
wire STRETCH2 = ... ;	// insert logic to determine if device needs stretch by 2 cycles
wire STRETCH3 = ... ;	// insert logic to determine if device needs stretch by 3 cycles
wire IS_VIA = ... ;		// insert logic to determine if it's a VIA

always @(posedge FCLK or negedge nRST) begin
	if (!nRST) begin
		STATE <= 3'b000;
		PHI2 <= 1'b0;
		VIA_CLK <= 1'b0;
		VIA_SEL <= 1'b0;
		DELAYED_SEL <= 1'b0;
	end
	else if (STATE == 3'b000) begin
        // CPU clock is low in state 000, high in any other state
		STATE <= 3'b001;
		PHI2 <= 1'b1;
	end
    else if (STATE == 3'b001) begin
        // Second state of bus cycle - need to determine required wait states
        // by the end of this state.
        if (STRETCH1) begin
            // state increments twice before PHI2 goes low again
            STATE <= 3'b110;

            // delayed select asserted at beginning of stretch
		    DELAYED_SEL <= 1'b1;
        end
        else if (STRETCH2) begin
            // state increments 4 times before PHI2 goes low again
            STATE <= 3'b100;

            // delayed select asserted at beginning of stretch
		    DELAYED_SEL <= 1'b1;
        end
        else if (STRETCH3) begin
            // state increments 6 times before PHI2 goes low again
            STATE <= 3'b010;

            // delayed select asserted at beginning of stretch
		    DELAYED_SEL <= 1'b1;
        end
        else if (IS_VIA) begin
            // VIA_CLK will toggle at the next input clock, however it is not
            // known whether it will go low or high
            // If it will go low, assert VIA_SEL at the same time and do a 2 cycle stretch
            // If it will go high, don't assert VIA_SEL yet, but start a 3 cycle stretch
            // VIA_SEL will be asserted after 1 cycle of stretch
            if (VIA_CLK) begin
                // VIA_CLK will go low at next input clock, so assert VIA_SEL there as well
                VIA_SEL <= 1'b1;

                // need 2 cycle stretch
                STATE <= 3'b100;
            end
            else begin
                // need 3 cycle stretch, don't assert VIA_SEL yet
                STATE <= 3'b010;
            end
        end
        else begin
            // no stretching needed - back to PHI2=0
            STATE <= 3'b000;
		    PHI2 <= 1'b0;
        end
    end
    else if (STATE == 3'b111) begin
        // Last state of bus cycle following stretching
        // Back to PHI2=0 on next input clock
        STATE <= 3'b000;
		PHI2 <= 1'b0;

        // VIA select deasserted here
        VIA_SEL <= 1'b0;

        // delayed select deasserted here
		DELAYED_SEL <= 1'b0;
    end
    else begin
        // stretching operation underway but not yet at the end
        // states 010, 011, 100, 101, 110
        if ((STATE == 3'b011) & IS_VIA) begin
            // VIA_CLK will go low at next input clock, so assert VIA_SEL there as well
            VIA_SEL <= 1'b1;
        end

        STATE <= STATE + 3'b001;
    end

    if (STATE[0]) begin
        // VIA_CLK toggles whenever unstretched clock would fall
        // i.e. when state number transitions from odd to even
        VIA_CLK <= ~VIA_CLK;
    end
end

I added a DELAYED_SEL signal to accommodate any devices which need additional settling time for the address and/or data before being activated, following your suggestion.

[BigDumbDinosaur]

kernelthread wrote:

I've come up with some Verilog code...

As I previously noted, POC V1.5 is an all-discrete design, so Verilog isn’t going to be of much help. I’m still mulling this and have sketched out a couple of possibilities that are starting to close in on a solution.

[BigDumbDinosaur]

Well, I haven’t been around much for the last month or so.  Cardiac problems started to mount and then suddenly I was (literally) down and almost out.  I won’t go into detail about it—PM me if you are interested.  Suffice to say, I’ve dodged a few bullets in the past.  This time, it was a howitzer shell. 

Meanwhile, POC V1.3 has been running, unattended, on one of the desks in my office, racking up some uptime.  I captured some video as I queried it to see how far uptime had gone.  It’s not the best quality, as I’m not real skilled with the video editing software I’ve got.  I need to learn how to make the brightness and contrast better.

BTW, after I captured the uptime, I ran the program that I use to set V1.3’s hardware clock from one of my Linux boxes.  The program reads the old RTC value, sets the RTC to the current (Zulu) time, resynchs binary sequential time (BST) with the refreshed RTC time and finishes by reporting how much BST was skewed.  BST was off 1.63 seconds.  The last time I resynched the clock was in June.  Yep!  It only drifted 1.63 seconds in a four-month period.

BST is ultimately driven by the jiffy IRQ generated by DUART #1’s counter/timer, which runs at a fraction of the 3.6864 MHz clock that drives both DUARTs.  The oscillator I used is rated at 50 PPM.  Clearly, it drifts a lot less than that.

As for the status of this project, I’m trying to decide what more, if anything, I should do with V1.3, and what more I could do with regard to future projects.

[sburrow]

BigDumbDinosaur wrote:

Well, I haven’t been around much for the last month or so. Cardiac problems started to mount and then suddenly I was (literally) down and almost out. I won’t go into detail about it—PM me if you are interested. Suffice to say, I’ve dodged a few bullets in the past. This time, it was a howitzer shell.

Glad you are still alive BDD, was getting concerned for you. I don't know how old you really are, what all you do for your health, (heck, I don't even know your real name!), but I do hope you stick around a good while longer. Thank you for all that you do here.

Chad

[gfoot]

Yes, glad you're OK and I hope you recover well - and it's great that V1.3 is still happy and stable, and sad that V1.4 didn't work out so well, but I've been looking forward to seeing what you do with POC V1.5 and POC V2.0! I do think the '163 counter needing to commit so soon in the clock cycle is a limitation, and presumably going back to separate flipflops (whether '74s or '109s) can support delaying the decision regarding whether a cycle is stretched or not until nearer where the falling edge would have been. I've been trying to do the same thing with my own circuit, as the time from the CPU's address setup to that stretching decision has been the "long pole" for me.

[plasmo]

BDD,
Glad to see you posting again. I understand cardiologists are hard to schedule nowadays, I'm glad you are able to see the doctor and get the problem solved.

[BigDumbDinosaur]

gfoot wrote:

Yes, glad you’re OK and I hope you recover well...

Thanks.

Quote:

- and it’s great that V1.3 is still happy and stable, and sad that V1.4 didn’t work out so well, but I’ve been looking forward to seeing what you do with POC V1.5 and POC V2.0!

As I earlier noted, V1.4 was useful in that I gained insight into the timing quagmire caused by having to make the wait-state decision during Ø2 low.  V1.3 tops out at 16 MHz and after having run V1.4 and observed it with the 'scope and the logic analyzer, it’s now clear why that limit exists.

While I was in the hospital, I had some time to think about this, which leads me to believe I’ve likely reached a wall that I can’t penetrate with an all-discrete logic design.  The primary problem is in being able to recognize when the effective address is in bank $00 in a time-efficient manner.  None of the methods I’ve conjured to date are fast enough to produce a reliable wait-state once the Ø2 clock half-cycle period gets shorter than about 30ns.

Quote:

I do think the ’163 counter needing to commit so soon in the clock cycle is a limitation, and presumably going back to separate flipflops (whether ’74s or ’109s) can support delaying the decision regarding whether a cycle is stretched or not until nearer where the falling edge would have been.  I’ve been trying to do the same thing with my own circuit, as the time from the CPU’s address setup to that stretching decision has been the "long pole" for me.

Yep, it does seem to be an elusive goal.  The 163 counter worked well enough in POC V1.2 to allow 20 MHz operation, with what appeared to be enough head room to reach 25 MHz.  However, V1.2 didn’t have extended RAM, so the glue logic was faster and the amount of time available to reach a wait-state decision was correspondingly greater.

I’ve been thinking about another clock-stretching method that involves gating clock signals coming out of a single AC74 flop driven by the oscillator, and not trying to stretch the clock by using something that ultimately marches in step with the Ø2 × 2 oscillator signal, which is what the 163 is doing.  However, a method has yet to gel for me.  If it does, I will build a test circuit to prove the theory before trying it in another POC design.

[gfoot]

I wonder if you could use a synchronous reset on the '163 when PHI2 is high if the bank was zero, so that it resets the counter to zero on fast cycles and ends phase 2 on time; it would leave the counter set to zero, but you'll load something else next cycle I think. In fact if you then always load the counter for a slow cycle when PHI2 is low, then I think you've moved the decision later in the cycle, as needed. I think aside from the reset connection this is quite close to the circuit you already had.

Edit: Specifically looking at the V1.4 schematic, I'm suggesting connecting pin 4 of U2 to ground and adding a NAND of PHI2 and /WSE, and connecting the output of that gate to pin 1 of U2. Sorry I can't draw a schematic at the moment.

[BigDumbDinosaur]

Restlessness in the middle of the night caused me to think some more about this clock situation and how to make a circuit that would be faster to respond to the need to stretch the clock during a ROM or I/O access.  When I wake up during the wee hours and it’s not due to a call of nature, I go down to my office and work on something until sleepy.  So it was with the clock thingie.

Alternate Stretchable Clock Generator

Above is a one-wait-state test circuit that I may build to see what happens.  For easy of construction, I would tap into my supply of PDIP gates.  A practical application would likely use some of those dinky 1G gates to save space and reduce prop delay to a low single-digit value—although prop delay is not really a concern if it’s roughly the same for both clock signals.

Incidentally, the observant will note that GCLK will slightly lead Ø2 in the above circuit.  That lead could be minimized by deriving GCLK from yet another OR.  I think that leading signal would be more a concern in a system that has a VIA or other 65xx silicon that is slaved to Ø2.  I’m thinking the lead shouldn’t upset the wait-state timing, since the 109 flop’s response time to a low on /K when GCLK goes high ranges from 3ns to 9ns on 5 volts.  If it does prove to be an issue, then I would insert the OR into GCLK.

[gfoot]

This looks pretty fast, and even slightly simpler than V1.3's I think - at least, using more primitive gates!

I don't think GCLK leading PHI2 will upset the timing per se, but I think this circuit still requires being sure about the need to wait-state long enough in advance of the rising edge of PHI2. I guess the Schmitt triggered inverters won't be there in the final circuit, so your wait-state enable signal just needs to satisfy the setup time for the 74AC109, ahead of GCLK, which also leads PHI2's transition by about one 74AC32 gate delay. So I think the sequence is:

GCLK falls => 74AC32 gate delay => PHI2 falls => 65C816 bank/address delays => decoding propagation delay for /WSE => 74AC109 setup requirement => GCLK rises => 74AC109 clock triggered

And that needs to fit within half a GCLK cycle.

I don't think you used GCLK externally in V1.3, but adding the extra OR gate might help here within this circuit by delaying the 74AC109's clock being triggered, giving you more time for the wait-state enable logic to complete. It doesn't seem necessary to align with PHI2, it's probably OK and even beneficial to delay even further. There's a limit though, because of course you still need the address decoding to be more or less complete before you start anything like a RAM write operation - the value of a delay here is just to cover the cost of the wait state logic.

[BigDumbDinosaur]

gfoot wrote:

This looks pretty fast, and even slightly simpler than V1.3’s I think - at least, using more primitive gates!

One paper, it is faster and also less timing-critical, since the prop time of the (N)OR gates is largely irrelevant.  As long as the 109’s /Q goes high at least one (N)OR prop time before the next fall of Ø2, the clock will be held in the Ø2-high condition in time for the next cycle.

Quote:

I don’t think GCLK leading PHI2 will upset the timing per se...

However, I think GCLK leading Ø2 could (theoretically) result in a glitch in the middle of the stretched cycle.  The critical condition would be if the 109’s tPLH on the /K input was at the fast end of its spec (~3ns) and one of the gates was also fast.

Quote:

...but I think this circuit still requires being sure about the need to wait-state long enough in advance of the rising edge of PHI2.

Yep, that requirement still exists.  However, everything is now running at the oscillator speed, which is the same as the unstretched Ø2 frequency.  That provides some timing relief to the glue logic.  In V1.3’s circuit, with the AC74 flop subdividing the oscillator, the 109’s Q has to go low at least the AC74’s /PRE prop time before the rise of the oscillator signal, which is transitioning at Ø2 × 2.

Quote:

I guess the Schmitt triggered inverters won’t be there in the final circuit...

Correct.  The Schmitts are there only to debounce the push-to-test button.

Quote:

...so your wait-state enable signal just needs to satisfy the setup time for the 74AC109, ahead of GCLK, which also leads PHI2’s transition by about one 74AC32 gate delay.  So I think the sequence is:

GCLK falls => 74AC32 gate delay => PHI2 falls => 65C816 bank/address delays => decoding propagation delay for /WSE => 74AC109 setup requirement => GCLK rises => 74AC109 clock triggered

And that needs to fit within half a GCLK cycle.

­¡Exactamente, amigo mío!  Only, with this circuit, a GCLK half-cycle is the same duration as a Ø2 half-cycle, so the timing is more relaxed.

Quote:

I don’t think you used GCLK externally in V1.3...

I didn’t, because there is no 65xx I/O hardware.

Quote:

...but adding the extra OR gate might help here within this circuit by delaying the 74AC109’s clock being triggered, giving you more time for the wait-state enable logic to complete.  It doesn’t seem necessary to align with PHI2, it’s probably OK and even beneficial to delay even further.

As I previously noted, as long as the 109 responds before the end of Ø2 high plus a gate delay in the first of the stretched cycles, the circuit should fly.

When I build the test rig, I’m going to arrange things so I can insert one or two of the extra OR gates in series with GCLK to see what happens with varying GCLK’s phase relative to Ø2.  The logic analyzer should tell the tale. 

[BigDumbDinosaur]

BigDumbDinosaur wrote:

When I build the test rig, I’m going to arrange things so I can insert one or two of the extra OR gates in series with GCLK to see what happens with varying GCLK’s phase relative to Ø2.  The logic analyzer should tell the tale. 

I've moved further blather about this clock stuff to Generating Wait-States with Clock Trickery, since clock generation of any type per se is not specific to my POC contraptions.