Another semi-fail - again with the W65C02

[BillO]

GaBuZoMeu wrote:

Well, I scanned the WDC65C02 (an old one, 2004) data sheet for "compatible" and "replacement" - no finds. Perhaps they knew better

But if using PHI2out make things worse then using an oscillator can for PHI2 for the GAL and delay that PHI2_GAL by one or two buffers and fed it into the µP should make things better - I hope. The GAL signals then are slightly earlier than the "nominal" (=PHI2_µP qualified) signals.

The more I thought about this the more it made sense to me. In essence delaying the clock to the CPU by the same amount as it is delayed in gating a qualified write signal will perfectly align Phi2 and /QW. Just as though there was no timing cost to creating a Phi-2 qualified write (/QW).

Indeed doing this resolved the problem. The board will now (even with a 120ns rated EPROM) run happily at 14MHz.

So it seems that timing with the W65C02, especially in conjunction with ultra fast RAM, is very tight. Just as with the last project where a 12nS delay to the Phi-2 feeding the ACIA was enough to throw it off the rails, in this case a mere 15ns delay in the /QW line was the culprit. I guess not so mere when you compare it to the 15ns access time of the RAM. The combination fast RAM and W65c02 seems to have no 'sense of humor'.

The previous project solution ended up with only a 6ns delay and that is good up to about 17mHz under the right conditions. This solution produces a net 0ns delay between the CPU's clock and the gating of a Phi2 qualified write and will be the solution I use going forward.

Thanks GaBuZoMeu, your intuition was right on the money.

Here is a scope shot of the resulting timing at 10MHz. Please excuse the ringing in the traces - I have verified it is a scope ground issue and does not appear on the board. As before the traces are: Yellow=Phi2 (at CPU), Blue= RAM CE, Red=/QW, Green=DB

@floobydust - There was minimal ground bounce and Vcc glitching. The worst coincided with the RAM /CE signal (as expected). Much less than I have seen in some of my successful efforts. The Vcc glitch was at most about 150mV across the RAM's bypass cap.

[BillO]

BigDumbDinosaur wrote:

BillO wrote:

I'd like to see the schematics for the system clocks of some working projects.

clock_gen_2phase.GIF

Above is what is in my POC units. I don't actually use the PHI1 output—I illustrate it for anyone who might need it.

Thanks for sharing BDD.

What do you use to qualify your write signal with Phi-2? What is the estimated timing cost?

[GaBuZoMeu]

That's really interesting: the data hold timing of the WDC65C02 (and presumably that of the 65C816) is so small that a few ns delay - the necessary gating of RWB with Phi2 - is too much. Perhaps a few pF on the data bus may help as well. This was probably not intended by the designer but with slower CMOS processes (> 0.6µ) perhaps never observed.

Glad that I could be helpful.

[BigDumbDinosaur]

BillO wrote:

BigDumbDinosaur wrote:

BillO wrote:

I'd like to see the schematics for the system clocks of some working projects.

The attachment clock_gen_2phase.GIF is no longer available

Above is what is in my POC units. I don't actually use the PHI1 output—I illustrate it for anyone who might need it.

Thanks for sharing BDD.

What do you use to qualify your write signal with Phi-2? What is the estimated timing cost?

Below is a variation of what I used in POC V1 (all discrete logic). The variation is one section of the 74AC00 is being used as an inverter—an actual inverter was used in POC V1.

Read/Write Qualification

Assuming a 5 volt circuit, each section of the 74AC00 has a propagation delay that will vary from 1.9ns to 6.6ns over the full commercial temperature range. In my design, I worked off the worst-case of 6.6ns, and could boot the unit on a 15 MHz clock, despite use of a 55ns EPROM.

As can be seen, both /RD and /WD will lag Ø2 by one gate delay. This worked out well with the 65C816. The 65C02's read-write timing is like that of the '816, so I'd expect to see similar results.

—————
EDIT: Fix gate delay reference relative to Ø2.

[BillO]

Interesting.

Actually, you have a 2 gate delay on start of the qualified write which I think is not as critical, but only a single delay at the end. Your write will end 6.6ns after Phi2 goes low. It's this back end that seems to cause the problems.

I'm guessing that the combination of a W65C02 (or other ADC CPU) slower RAM will be a bit more tolerant.

It would be a useful experiment to build up a test bed that had a continually variable delay in producing a qualified write in order to flush out what the tolerances are for various clock speeds and RAM choices.

IIRC, your RAM is running at ~60ns, right?

That gives us 4 data points

Code: Select all

Effective
  Delay          RAM        ?
  0ns            15ns      OK
  6ns            15ns      OK
 6.6ns           60ns      OK
  15ns           15ns      NG

Anybody have an idea on how to make a continually variable delay in the 6ns-20ns range?

[GaBuZoMeu]

A RC-network plus a buffer should work:

50 Ohm / 50 pF gives approx. 3ns delay:

500 Ohm / 50 pF yields 15ns:

In a real circuit this may vary due to the behaviour of the real buffer. Using a trimpot should work to adjust any desired value.

[BillO]

Hmmm, yes - that might work well. Just have to find the right buffer.

It may be a while before I can get around to this, but it might be handy for everyone to have some definitive data.

[Dr Jefyll]

read_write_qualify_alt.gif (16.76 KiB) Viewed 3724 times

I endorse the circuit BDD posted, as it's the same arrangement I often use myself. That's assuming the node marked PHI2 is the same node that attaches to the CPU clock input (PHI2, aka pin 37 on a 40-pin WDC 65C02). It should be just fine. I'm not aware of any reason a variable delay should be added, but I haven't been closely following this topic, and may've missing something.

By the way, BDD, I suspect you posted in a hurry, or failed to proofread. I think you know /RD and /WD both lag Ø2 by one gate delay. (It's RWB which incurs two gate delays to /WD -- and the extra delay is inconsequential, since it's PHI2 which will time both the falling and rising edge of the low pulses on /RD and /WD).

BigDumbDinosaur wrote:

As can be seen, /WD will lag Ø2 by two gate delays, whereas /RD will lag Ø2 by one gate delay

[BigDumbDinosaur]

Dr Jefyll wrote:

That's assuming the node marked PHI2 is the same node that attaches to the CPU clock input (PHI2, aka pin 37 on a 40-pin WDC 65C02).

Correct assumption. Per WDC guidelines, all timing in my circuits are based solely upon the clock generated by the (earlier published) Ø2 generator. As the 65C816, has no clock outputs, that is the only way an '816 design can be clocked.

Quote:

By the way, BDD, I suspect you posted in a hurry, or failed to proofread. I think you know /RD and /WD both lag Ø2 by one gate delay...

Yep! As vision in my left eye fades to unfocused blobs of light, I am finding myself making more errors of this type. I try to carefully proofread but seem to be missing a lot as of late. You can only imagine what fun it can be trying to debug a program that won't run due to nothing more than some errant typing.

[BigDumbDinosaur]

BillO wrote:

Actually, you have a 2 gate delay on start of the qualified write which I think is not as critical, but only a single delay at the end. Your write will end 6.6ns after Phi2 goes low. It's this back end that seems to cause the problems.

The two gate delay on /WD caused by the inversion of RWB should not be a significant timing factor, since during a write cycle, RWB will be driven low before Ø2 goes high. Practically speaking, the gating of /RD and /WD is slaved to the rise and fall of the clock.

Quote:

I'm guessing that the combination of a W65C02 (or other ADC CPU) slower RAM will be a bit more tolerant.

The read-write timing for the 65C02 is actually more relaxed than for the 65C816, as the latter drives D0-D7 during both clock phases. My circuit keep peripheral silicon off the data bus during the low clock phase during a read cycle, since the '816 is emitting the bank bits during that time. Here the gate delay inherent to following the rise and fall of Ø2 eliminates (in theory) a potential bus contention issue that is peculiar to the '816 during read cycles.

Quote:

IIRC, your RAM is running at ~60ns, right?

The RAM in POC V1.1 is 12ns. The RAM in POC V2 is 10ns.

[BillO]

Dr Jefyll wrote:

read_write_qualify_alt.gif

I'm not aware of any reason a variable delay should be added, but I haven't been closely following this topic, and may've missing something.

Just as n experiment Jeff. It seems that using a W65C02 with faster RAM tends to tighten up the timing constraints on the system. So I envisioned using a variable delay in qualifying the write signal as an experiment to see what boundaries were with different speed RAM and different processor speeds.

[Dr Jefyll]

Alright, I hope I'm on the same page. I like GaBuZoMeu's suggestion and your reply, BillO, about "delaying the clock to the CPU by the same amount as it is delayed in gating a qualified write signal." Here's an adaptation of BDD's circuit to accomplish this. I'm presuming your GAL uses the same very simple logic to generate /RD and /WR.

BillO, in a post elsewhere you said, "the RAM specifies that there can be 0ns between the release of /CE and /W, there can't be, say -6ns (a negative value)," and that sounds very odd to me. Is that the same RAM that's in context for this thread, and can you please post or link to the datasheet?

-- Jeff

[BillO]

Dr Jefyll wrote:

Alright, I hope I'm on the same page. I like GaBuZoMeu's suggestion and your reply, BillO, about "delaying the clock to the CPU by the same amount as it is delayed in gating a qualified write signal." Here's an adaptation of BDD's circuit to accomplish this. I'm presuming your GAL uses the same very simple logic to generate /RD and /WR.

read_write_qualify_with_delay.png

Yes, you are on the same page.

Quote:

BillO, in a post elsewhere you said, "the RAM specifies that there can be 0ns between the release of /CE and /W, there can't be, say -6ns (a negative value)," and that sounds very odd to me. Is that the same RAM that's in context for this thread, and can you please post or link to the datasheet?

Datasheet here: http://ecee.colorado.edu/~mcclurel/w24257-a16.pdf

I was referring to the timing diagrams on page 7 where they (to me anyway) clearly show that the rising edge of /CE can be coincidental with or lag /WE but not the other way around.

Before the added delay I had /WE rising after /CE by something like 4ns. The delay corrected that such that /CE rises about 8ns after /WE. This better agrees with the specified timing.

[BillO]

Here are my updated schematic and CUPL code.

Code: Select all

/* *************** INPUT PINS *********************
PIN  1  =   A12                   ; /*                                 */ 
PIN  2  =   A13                   ; /*                                 */ 
PIN  3  =   A14                   ; /*                                 */ 
PIN  4  =   A15                   ; /*                                 */ 
PIN  5  =   A11                   ; /*                                 */ 
PIN  6  =   A10                   ; /*                                 */ 
PIN  7  =   RW                    ; /*                                 */ 
PIN  8  =   A9                    ; /*                                 */ 
PIN  9 =    A8                    ; /*                                 */ 
PIN  19 =   Clk                   ; /* From Oscillator                 */ 


/* *************** OUTPUT PINS ********************/
PIN 11  =   DD                    ; /*Data Direction - off-board expansion buffer */ ***
PIN 12  =   DEV_1                 ; /*Device select 1 - active low */ ***
PIN 13  =   ROM_CE                ; /*ROM Select - active low */ ***
PIN 14  =   DEV_2                 ; /*Device select 2 - active low */ ***
PIN 15  =   DEV_3                 ; /*Device select 3 - selectable */ ***
PIN 16  =   DEV_0                 ; /*Device select 0 - active low */ ***
PIN 17  =   RQW                   ; /*High=Read, Low=Phi-2 qualified write*/ ***
PIN 18  =   Phi2                  ; /*System Clock*/  


/* Intermediate values */
a = A10 # A11 # A12 # A13 # A14;
b = !A15 # a;						/* Low = valid I/O address */
d3 = b # !A8 # !A9;

/* Output definitions */
DD = !b & RW & (A8 # A9);			/* High = read from expansion bus I/O.  Low all other times */
RQW = !(Clk & !RW);
ROM_CE = !A15 # !a;

DEV_0 = b # A8 # A9;
DEV_1 = b # !A8 # A9;
DEV_2 = b # A8 # !A9;
DEV_3 = !(b # !A8 # !A9);

Phi2 = Clk;

[Dr Jefyll]

I think your trouble arises from a simple omission -- a design error. You just need to finish implementing the widely used circuit that BDD & I prefer. You've already got half of it -- the part that drives the RAM's /WE pin low only when Phi2 is high and RWB is low. You need to add the part that drives the /OE pin of both memories low only when Phi2 is high and RWB is high.

Presently, address line A15 is attached to /CE of the RAM (okay) and also attached to /OE of the RAM -- which is not really 100% OK, and here's why.

Imagine a write to RAM (ie: a write to an address below $8000). Near the start of the cycle, shortly after PHI2 goes low, a valid address appears. A15 will be low, and so too will be the RAM /CE and /OE. The RAM begins reading from the address. In fact, RAM is fully driving the data bus. Then eventually PHI2 goes high and...

• the CPU commences to drive the data bus
• an instant later, the GAL brings the RAM's /WE pin low, and RAM ceases to drive the data bus

It should be clear this is not an elegant situation. It's unrealistic to expect a clean handover of the bus. Instead, you face a short -- or not so short! -- period of bus contention before the RAM "lets go" and allows the CPU to be undisputed boss. This contention consumes a nasty jolt of current, thus transmitting noise on the Vcc and Gnd wiring.

A vintage CPU is likely to lessen the effect. It will be slow to begin driving the data bus, thus allowing more time for RAM to let go. But a modern WDC CPU is quick to begin driving the data bus -- so quick that it grants less forgiveness to the design error. (Also, a modern CPU has more current capability on its data bus drivers, thus increasing the current which results from the contention.) I believe this explains why your project prefers older CPU's!

Edit: hm, I overlooked the fact that the ROM is presently allowed to drive the data bus during PHI2 low. That too could cause trouble, but it's my #2 suspicion, not #1. Luckily the same prescription treats both! Drive the /OE pin of both memories low only when Phi2 is high and RWB is high.

BTW, I don't find that the timing diagram in the data sheet (pg 6) implies that the rising edge of /CE can be coincidental with or lag /WE but not the other way around. I can kinda see how you might infer that. But it just seems wrong to me -- not how RAM's work. Plus, I think they'd be a lot fussier about specifying such an odd restriction (odd in the sense that it contradicts the Truth Table, which says /OE and /WE are don't-care anytime /CE is high).

-- Jeff