Glue questions

[GARTHWILSON]

barnacle wrote:

The 6502 won't care what order things happen in at the memory. If the 6502 is running a read cycle, it will expect data to be available at the rising edge of the ph2 clock

Correction:  It only needs the read data to be valid and stable tDSR time before the fall of φ2.

Quote:

if it's a write cycle, then the 6502 will put data to be stored.

There it will put out the data to write no more than tMDS time after the rise of φ2.

[barnacle]

Oops, my bad; thanks for the correction. And I was looking at Jeff's magic moving diagrams while I typed that...

Neil

[BigDumbDinosaur]

L0uis.m wrote:

How does a 6502/65x02 µp reacts if /CS goes active low when /OE or /WE (or both) already low ?

As previously noted, the MPU doesn’t care how you control the device, as long as you meet required setup and hold times.  The question is how the affected device will react when /CS is asserted after /OE and/or /WE have been asserted.  That sort of information is/should be in the data sheet.  None of the devices I use will malfunction with that sort of reversed access, but they all will be slower than if /CS is asserted first—more on that below.

Quote:

Will it cause some kind of glitching or other distortion ?

That would depend on how you have implemented your glue logic.  It all comes down to timing and making sure events occur in the right order and at the right time.  It isn’t rocket science—it’s mostly an exercise in reading data sheets, looking at timing diagrams and doing some basic arithmetic to predict when things will happen during a machine cycle.  BTW, when working out your timing, keep in mind that for the 65xx family, a machine cycle commences at the fall of the clock.

Quote:

Can I expect any problems from RAM/ROM memory or peripherals, or any other odd behaviour?

Again, that is information to be found in the data sheet.  Timing diagrams, in particular, will illustrate how the device will behave with different sequences of asserting /CS, /OE and /WE.  You do not want to make assumptions in that regard, as devices do vary.

In adapting non-65xx hardware to a 65xx-family bus, your main concern is to prevent a write to a device from occurring during Ø2 low.  I already explained why, so I won’t recapitulate.  Suffice to say if you don’t heed that requirement, random data corruption or device malfunction may occur.  65xx hardware, e.g., the 65C22, implicitly “understands” the 65xx bus cycle and “knows” to not read/write the data bus during Ø2 low.

In many cases, best device performance will be achieved by asserting /CS as soon as an address is formed by the MPU—which occurs during Ø2 low, and asserting /OE or /WE when Ø2 goes high.  In other words, don’t qualify chip selects with Ø2; use the clock to qualify /OE and /WE.  The reason for this is many devices respond more quickly to /OE or /WE than they do to /CS—this behavior is usually illustrated in the data sheet timing diagrams.  The explanation for why response to /CS is slower than to /OE or /WE lies in the fact that many devices go into a semi-catatonic state when /CS is deasserted (high), which among other things, greatly reduces the idling current draw.  Asserting /CS “awakens” the device and tells it to read its address inputs, steps which usually consume the bulk of the time required for the device to respond when accessed.

Once the device is “awake” and has reacted to its address inputs, asserting /OE or /WE causes the device’s data pins to go from the high-Z state to active and access to the cell (memory) or register (I/O) that is being addressed occurs.  This transition from high-Z to active to cell/register access is usually quite rapid when compared to the time required to transition from “sleeping” to “awake” when /CS is asserted.  If you first assert /OE or /WE, followed by /CS, the “wake up and talk/listen” sequence usually becomes a serial event, with the time required for a response to /CS often being added to the time required for a response to /OE or /WE.  Again, timing diagrams should illustrate what happens when /CS is used to gate output/input instead of /OE or /WE.

[jgharston]

Yuri wrote:

In the case of the 6522 the pins are CS1 and CS2#, note however in the 6522's case (as is the case for many non RAM/ROM type devices, see the wonderful notes above from others about RAM/ROM), there is no requirement that both of these pins be connected to complicated decode logic. The device is perfectly happy to have one of the pins wired directly to VCC or GND and let the other remaining pin be the one that is used for decoding.

For example, most often the chip enable outputs are active low inputs, so I usually wire my 6522's CS1 pin directly to VCC, and then hook the CS2# up to my decoding logic.

Having multiple CS lines gives you the flexibility to simplify the selection logic, and some of the decoding can be done by the device itself. For instance, with the 6850 with CS0, CS1, ~CS2 I can send my "IO Block &XX--" line to ~CS2, A7 to CS1 and A6 to CS0 and it automatically decodes to &XXC0-&XXFF. With a MIDI interface I built, having the option of a high CS or a low CS allowed me to remove an inverter.

As Yuri says, you don't need to use all the CS lines, tie the ones you don't need and just use the ones you do.

[L0uis.m]

Hello BDD,

BigDumbDinosaur wrote:

As previously noted, . . .

Thanks for the crystal-clear explanation
(Sorry, for me making you repeating things.)

The summarisation you wrote in answer to my questions, is much more comprehensible than all those different timing diagrams from all those different manufacturers; it bridges between those and explains not only WHAT happens WHEN, but also WHY.

[Niek6502]

(My apologies in advance for my rather unprecise terminology)

To me it looks like the timing diagram in the W65C02S datasheet could be made more clear. If I see such a diagram and try to understand it, I try to figure out the durations by matching up left and right arrows. It looks like the left arrow for tDSR, tDHR and tDHW are missing. From the (excellent) post and diagrams by Jeff the left arrow for tDSR should be the end of tACC, and the left arrows for tDHR and tDHW should be at the falling edge of PHI2. In the case of tDSR, you could argue that the left arrow is at the same time as the right arrow for tACC, but it would be more clear if drawn like tAH. (see attached)

For a newbie trying to grok this all by reading datasheets (which should be the way to do it), this is somewhat annoying.

Another thing (not an issue with the timing diagram, but just a complete lack of understanding on my part) is that the diagram shows tMDS (write data delay time). This should be the maximum time it takes the MPU to produce valid data to write to some peripheral and the datasheet I have says 25ns. If I use φ2 in my glue to qualify the SRAM, and both glue and SRAM are fast enough, it could be that invalid data is initially presented to SRAM. Am I correct in assuming that if the data is still in flux before tMDS is reached, the "new" data after tMDS will be what is ultimately written to SRAM? If so, I assume the SRAM will "commit" the data after some set time or signal. If that cut-off is forced by φ2 going low, the glue logic would signal that to the SRAM. Isn't there a timing issue there as well? Should the glue be faster than tDHW (write data hold time - set at minimum of 10ns)? Or is there another signal (or time limit) that tells the SRAM the write should be committed and stop paying attention to the data bus? Maybe /WE?

Thanks as always for looking into these (likely trivial) questions.

-Niek.

[GARTHWILSON]

The data can be in flux after the SRAM's write cycle starts; but if things are designed right, the data will be valid and stable in time for the SRAM to lock it in when you "close its door," so to speak.

It looks like the corresponding left arrow (pointing right) for tDHR and tDHW is supposed to be the same one as for tAH.

[Niek6502]

GARTHWILSON wrote:

The data can be in flux after the SRAM's write cycle starts; but if things are designed right, the data will be valid and stable in time for the SRAM to lock it in when you "close its door," so to speak.

Yah, but what exactly initiate the "close the door"? If it is φ2 going low, there will be a delay of the glue signalling the SRAM. If that delay is greater than tDHW, the data bus might show invalid data before the SRAM is signalled.

GARTHWILSON wrote:

It looks like the corresponding left arrow (pointing right) for tDHR and tDHW is supposed to be the same one as for tAH.

I agree, but a datasheet should not need to be read with any "it looks like ... supposed to be" thoughts, especially for someone like me who is advised to "read the datasheets for all the info you need" (of course this is by no means directed at you or anyone here, it is just a bit of frustration with some of these datasheets trying to figure it out by myself without having to ask these basic questions - I truly appreciate all replies and advice).

-Niek.

[GARTHWILSON]

Niek6502 wrote:

GARTHWILSON wrote:

The data can be in flux after the SRAM's write cycle starts; but if things are designed right, the data will be valid and stable in time for the SRAM to lock it in when you "close its door," so to speak.

Yah, but what exactly initiate the "close the door"? If it is φ2 going low, there will be a delay of the glue signalling the SRAM. If that delay is greater than tDHW, the data bus might show invalid data before the SRAM is signalled.

On the '02 (but not the '816), the data bus goes high-impedance during φ1, and bus capacitance, small as it is (like 20pF per line), multiplied by the negligible leakage of CMOS inputs, makes for a time constant that will hold the data for even milliseconds (not just nanoseconds or even microseconds) while nothing is driving the bus.  You don't have to worry about the data going invalid in that time.

Quote:

GARTHWILSON wrote:

It looks like the corresponding left arrow (pointing right) for tDHR and tDHW is supposed to be the same one as for tAH.

I agree, but a datasheet should not need to be read with any "it looks like ... supposed to be" thoughts, especially for someone like me who is advised to "read the datasheets for all the info you need" (of course this is by no means directed at you or anyone here, it is just a bit of frustration with some of these datasheets trying to figure it out by myself without having to ask these basic questions - I truly appreciate all replies and advice).

WDC's data sheets have had quite a lot of problems over the decades, but gradually most (not all) of them have gotten fixed as we have pointed them out to WDC, which is why there have been so many, many versions.  It's not that the hardware has changed that much, but rather only that WDC puts out a new data sheet every time another bug is pointed out and fixed.

[Niek6502]

GARTHWILSON wrote:

On the '02 (but not the '816), the data bus goes high-impedance during φ1, and bus capacitance, small as it is (like 20pF per line), multiplied by the negligible leakage of CMOS inputs, makes for a time constant that will hold the data for even milliseconds (not just nanoseconds or even microseconds) while nothing is driving the bus.  You don't have to worry about the data going invalid in that time.

I'm sorry, I don't want to be argumentative, but in reading a lot of the primer and the posts by Jeff, people keep hammering on the fact one should design a setup with all these timing constraints in mind. It is not that I am worrying, but from what I am reading and what you are implying, a situation where the SRAM would be deselected after tDHW could technically be out of spec. I do understand that it won't be a problem (and in my case my setup is running at 1MHz, so even more leeway), but I am getting mixed signals here. Should I just ignore this (theoretical?) issue, or am I missing something else that prevents the SRAM from seeing bad data?

(I am trying to get from "Johnny Gunslinger with his badly out-of-spec 555 clock and Arduino monitoring" in my first thread to someone who can understand and build a 65C02 setup that is technically sound. This stuff is confusing the heck out of me.)

-Niek.

[BigDumbDinosaur]

Niek6502 wrote:

To me it looks like the timing diagram in the W65C02S datasheet could be made more clear.

No kidding!  First time I saw a WDC 65C02 timing diagram, my reaction was what in Sam Hill am I looking at?    Jeff’s “re-imagining” of the timing diagram puts it into scale, which does simplify understanding it.  However, in scale or not, the timing diagram and WDC data sheet together tell “lies.”

Several forumites, notably Bill Chen (plasmo), have greatly overclocked the 65C02 (the 0.6µ TSMC versions) into the 30 MHz range (I think Bill got one running at ~36 MHz).  The fact that the C02 can be cranked up to that speed, especially when what is inferred by the FMAX vs VDD curve published on page 24 of the current data sheet is considered, implies that some of what is depicted in the timing diagram, as well as some of the specs listed in the AC characteristics table on page 24 in the data sheet, is mostly malarkey.

For example, the tADS spec is listed as 30ns maximum when VDD is 5 volts.  If that were the case, the C02 would die above 14 MHz.  I dunno about the C02, but testing I’ve done on several 0.6µ 65C816s indicates that tADS is 12ns—that was very consistent from one MPU to another.  I suspect that tADS for the C02 is a little faster, as it has less stuff to do to get set up for the next cycle.

In fact, all of those numbers are suspect when one considers that if one extrapolates the FMAX vs VDD curve to intersect with 5 volts, FMAX works out to 24-25 MHz.  Also, WDC tests all production parts at 20 MHz on 5 volts.  So their own test regimen is at odds with what the data sheet says. 

Quote:

For a newbie trying to grok this all by reading datasheets (which should be the way to do it), this is somewhat annoying.

We all feel your pain on this.  WDC’s less-than-stellar documentation has resulted in a lot of discussion around here about how things work.  Fortunately, their MPUs perform significantly better than the data sheets suggest, which says to me the timing details in their data sheets have not kept up with the gains in fabrication technology that have been realized in the last 25-or-so years (also, there is an undocumented hardware bug in the 65C02).  It’s pretty clear that TSMC’s 0.6µ fabrication performs significantly better than Sanyo’s 0.8µ did (I have 65C816s of both types and cannot get the Sanyo ones past 15 MHz).

Quote:

Another thing...the diagram shows tMDS (write data delay time)....If I use φ2 in my glue to qualify the SRAM, and both glue and SRAM are fast enough, it could be that invalid data is initially presented to SRAM.

You need to qualify(!) what you mean by “If I use φ2 in my glue to qualify the SRAM”.  Qualify what: /CS or /WE?

Quote:

Am I correct in assuming that if the data is still in flux before tMDS is reached, the "new" data after tMDS will be what is ultimately written to SRAM?  If so, I assume the SRAM will "commit" the data after some set time or signal.  If that cut-off is forced by φ2 going low, the glue logic would signal that to the SRAM. Isn't there a timing issue there as well?

Let’s start off by making it clear the SRAM knows nothing about clocks—it has no clock input.  The SRAM is an asynchronous device.  What it knows about is how long it takes for it to react to changes to /CS, /OE and /WE.  That the SRAM is asynchronous is one of the reasons why you need to qualify /WE with Ø2.  As the MPU always controls the bus (it is a “bus master”), it is necessary to tell the SRAM when it is okay to connect to the data bus.

As Garth notes, during Ø2 low, the MPU floats the data bus, but parasitic capacitance tends to keep the bus in the state it was in while the MPU or a device was driving it.  The SRAM will latch whatever is on the data bus when /WE makes the transition from asserted to de-asserted.  There may be a refractory period after /WE is de-asserted in which the SRAM’s data pins must remain stable.  That period of time is customarily referred to as tDH (data hold time) on timing diagrams and on the faster SRAMs, may be zero.  If not zero and the data pins change before tDH expires, the SRAM may latch incorrect data.  Given the nature of the 65C02’s bus cycle and the fact that it floats the bus during Ø2 low, if you use /WE to gate writes to the SRAM and qualify /WE so it is asserted only when Ø2 is high, things will work out without you having to obsess over it.

Quote:

Should the glue be faster than tDHW (write data hold time - set at minimum of 10ns)? Or is there another signal (or time limit) that tells the SRAM the write should be committed and stop paying attention to the data bus? Maybe /WE?

See above and please be clear about what you mean when you say “glue.”  Are you referring to address decoding, read/write control, or what?

BTW, there is a reason /WE is called “Write Enable.” 

[Niek6502]

First off, my apologies if my incorrect terminology is messing things up. My question resulted from me trying to digest the 65C02 datasheet, I tried to go through every parameter in the timing sheet, and I saw tDHW which appears to be the time the data is held on the bus after the MPU brings φ2 low.

BigDumbDinosaur wrote:

Let’s start off by making it clear the SRAM knows nothing about clocks—it has no clock input.  The SRAM is an asynchronous device.  What it knows about is how long it takes for it to react to changes to /CS, /OE and /WE.  That the SRAM is asynchronous is one of the reasons why you need to qualify /WE with Ø2.

OK, so that "links" /WE to φ2 (again, not a correct technical term, but it conveys my meaning hopefully).

BigDumbDinosaur wrote:

As Garth notes, during Ø2 low, the MPU floats the data bus, but parasitic capacitance tends to keep the bus in the state it was in while the MPU or a device was driving it.  The SRAM will latch whatever is on the data bus when /WE makes the transition from asserted to de-asserted.  There may be a refractory period after /WE is de-asserted in which the SRAM’s data pins must remain stable.  That period of time is customarily referred to as tDH (data hold time) on timing diagrams and on the faster SRAMs, may be zero.  If not zero and the data pins change before tDH expires, the SRAM may latch incorrect data.  Given the nature of the 65C02’s bus cycle and the fact that it floats the bus during Ø2 low, if you use /WE to gate writes to the SRAM and qualify /WE so it is asserted only when Ø2 is high, things will work out without you having to obsess over it.

Please be aware that I am not obsessing over anything. I am trying to figure things out (with excellent help from all of you). I don't have the advantage of having worked in this field for years, so things that seem natural to others on the form are new to me. Several people (also off-forum) have pointed out to me that I need to read the datasheets, so I do. Both you and Garth basically say that yes, it is possible that the SRAM could theoretically latch data after tDHW expires, but in real life that won't be an issue. If that assessment from me of both of your replies is correct, that is fine. I am trying to work out the timing of the various gates and components on my setup to make sure all is OK, and it looked like I needed to make sure I wasn't going out-of-spec on tDHW (and yes, I know, my setup runs at 1MHz so pretty much everything would work, but I wanted to do it correctly and get some experience with this matter).

BigDumbDinosaur wrote:

Niek6502 wrote:

Should the glue be faster than tDHW (write data hold time - set at minimum of 10ns)? Or is there another signal (or time limit) that tells the SRAM the write should be committed and stop paying attention to the data bus? Maybe /WE?

See above and please be clear about what you mean when you say “glue.”  Are you referring to address decoding, read/write control, or what?

I will try to be more precise, my apologies.

Thank you for your explanation.

-Niek.

[GARTHWILSON]

Niek6502 wrote:

I'm sorry, I don't want to be argumentative,

I'm not offended.  On the contrary, if there's something that needs to be made more clear in the 6502 Primer, I want to know about it and take care of it.  The Primer was written nearly 25 years ago, but I didn't have my own website until 2012, and then I posted the material, and I keep making small improvements, and once in a while someone's posts expose a need for another clarification.  I wonder how many readers were scratching their heads but never let me know.

Quote:

but in reading a lot of the primer and the posts by Jeff, people keep hammering on the fact one should design a setup with all these timing constraints in mind. It is not that I am worrying, but from what I am reading and what you are implying, a situation where the SRAM would be deselected after tDHW could technically be out of spec. I do understand that it won't be a problem (and in my case my setup is running at 1MHz, so even more leeway), but I am getting mixed signals here. Should I just ignore this (theoretical?) issue, or am I missing something else that prevents the SRAM from seeing bad data?

The main thing you have to make sure of is that the RAM doesn't get orders to write while the address is in flux, as that could result in unintended addresses getting written to.  That's why WE\ is usually qualified with φ2.  (I say "usually" because In many cases SRAM will be faster than anything else on the bus and doesn't need the advance select time before φ2 rises, so there you could qualify the CE\ with φ2 instead.  Qualifying WE\ with φ2 is probably more common and is a good way to do it.  BDD prefers it.)  The address the '02 puts out won't change until at least tAH after the fall of φ2.  Where someone might get in trouble there is if they have too many gate delays in the glue logic, or use logic that's too slow (like 4000 series).  It is common for newcomers to cascade too many gates, as if timingwise they were free.

[Niek6502]

GARTHWILSON wrote:

I'm not offended.  On the contrary, if there's something that needs to be made more clear in the 6502 Primer, I want to know about it and take care of it.  The Primer was written nearly 25 years ago, but I didn't have my own website until 2012, and then I posted the material, and I keep making small improvements, and once in a while someone's posts expose a need for another clarification.  I wonder how many readers were scratching their heads but never let me know.

GARTHWILSON wrote:

The main thing you have to make sure of is that the RAM doesn't get orders to write while the address is in flux, as that could result in unintended addresses getting written to.  That's why WE\ is usually qualified with φ2.

This actually touches on one of the things that took me a while to grok. Up in this thread, I asked why we needed to get multiple pins to assert before a peripheral is active. BBD explained that ideally the IC needs to wake up first, and then it will react faster when it is asked to do the work. You say here that /WE can be qualified with φ2 to make things work. It doesn't say why doing this guarantees a stable address. What is not spelled out here (probably because it is so obvious to the experts) is that when you examine the timing diagram, you will see that the MPU assures the address is stable after tADS, which for the 65C02 (at 5V and room temperature) is 30ns. If you use a symmetrical clock, this means that for clock cycles below roughly 14MHz, the address is guaranteed to be stable before φ2 goes high. So qualifying /WE with φ2 guarantees that /WE will only be asserted with a valid address. For me, it now makes sense. (It also implies that any setup that asserts /WE after tADS will work, so I could see other setups that don't qualify /WE with φ2.)

Thanks all for turning on the light.

-Niek.

[GARTHWILSON]

Note however that there's no guarantee that the R/W\ output will stay high until the address is valid and stable.  It could be changing at the same time, or even be interpreted as low before the address is valid and stable.  At the tail end of the write cycle, as you start into the next clock cycle, even if the data are held reliably by bus capacitance, the address could start changing before the R/W\ output is solidly in "read" land.  These possibilities are why, one way or another, writes need to be qualified with φ2.  The address is always reliable when φ2 is high.