6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Nov 22, 2024 3:59 am

All times are UTC




Post new topic Reply to topic  [ 50 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Tue Jun 19, 2018 5:02 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8505
Location: Midwestern USA
BillO wrote:
Dr Jefyll wrote:
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

That's a 70ns SRAM that generates TTL-compatible outputs, not CMOS levels. In theory, the Voh minimum of 2.4 would not represent a valid logic 1 to the 65C02. We've had discussion in the past as to whether the WDC MPUs in fact recognize a TTL logic 1 as valid.

Quote:
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.

I'm confused. Page 7 only illustrates the data retention characteristics. The write timing diagrams are on page 6.

Turning to page 6, of interest (to me) is the SRAM's Tdw specification, which is the amount of time the data bus must be stable after the rise of /WE. The corresponding 'C02 spec would be Tdh, the MPU's data hold time at the end of a write cycle. WDC says that is 10ns after the fall of Ø2. Tdw is 30ns minimum.

Going by those numbers and the SRAM's write timing diagram, it would seem that the SRAM is too slow for the 65C02 at any Ø2 frequency—Tdh is generally not a function of clock rate. If my theorizing is correct, the 'C02 will stop driving the data bus 20ns before the SRAM is finished sampling it.

Incidentally, in the ISSI IS61C1024AL 128KB SRAM I used in POC V1, the equivalent spec to Tdw is 0ns—which implies the SRAM's internal data sampling timing is anchored to when /WE is driven low. That is a lot friendlier when combined with the 65C02 than the Tdw spec of the SRAM you are using.

Quote:
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.

Again, if my theorizing is in the ballpark, the deliberate timing sandbagging is compensating for the discrepancy between the SRAM's Tdw and the MPU's Tdh specs, thus achieving operation.

With the WDC MPUs, the best results are going to be obtained by not qualifying device selection with Ø2. That is, device selection should occur as soon as an address that is understood by the decoding logic is present on A0-A15. Reading and writing should be separately controlled as illustrated in the circuits earlier published by Jeff and me. You shouldn't have to be doing funky things with Ø2 just to get an SRAM to work. :shock:

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 5:24 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8505
Location: Midwestern USA
Dr Jefyll wrote:
...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.

I think your analysis is exactly what is happening. Aside from the brief period of bus contention that you described, the SRAM will take some time to "turn around" once /WE is driven low. The SRAM's performance under such a scenario is not described in the data sheet, but could be implied by chaining the tail end of the read (/OE is low) timing to the head end of the write (/WE is low) timing. I could foresee that by the time the SRAM has gone from being a "talker" to becoming a "listener," the MPU may have completed the write cycle...and who knows what the SRAM will be hearing.

A situation similar to what Jeff described could arise when accessing I/O hardware. This could be even more problematic, since it's not uncommon for a read of a given I/O device address to access a different function in the device than a write to the same address. This is all the more reason to gate /OE inputs only when the device has been selected and the expression RWB && Ø2 is true.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 10:37 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
BigDumbDinosaur wrote:
Incidentally, in the ISSI IS61C1024AL 128KB SRAM I used in POC V1, the equivalent spec to Tdw is 0ns—which implies the SRAM's internal data sampling timing is anchored to when /WE is driven low. That is a lot friendlier when combined with the 65C02 than the Tdw spec of the SRAM you are using.

This has made me curious, a RAM that does not need any setup time? I downloaded the datasheet and found the corresponding parameter tSD ("Data Setup to Write End") to be 7 ns minimum.
Attachment:
61-64C1024AL.pdf [883.64 KiB]
Downloaded 122 times

I think this setup time is a sort of propagation delay including a safety margin. And this means simply it takes 7 ns (worst) for a level change to travel down into the memory cell. But it might travel faster. If you assume 50% safety margin due to 50% fabrication process tolerances then (7 ns / 1.5) * 0.5 = 2.33 ns could be possible (same temperature, same voltage).

This means it is very necessary to have precisely timed /OE and /WE signals. The CPUs data hold time after write add a little "headroom" so a single gate (a fast one of course) delay would be compensated but not much more.

Knowing this I would recommend to use your clock generator
Attachment:
Two_Phase_Sysstem_Clock_Generator.png
Two_Phase_Sysstem_Clock_Generator.png [ 16.53 KiB | Viewed 2555 times ]

combined with Dr Jefylls suggestion
Attachment:
read_write_qualify_with_delay.png
read_write_qualify_with_delay.png [ 65.64 KiB | Viewed 2555 times ]

(One could use the Phi1 output and the fourth AC00 gate to generate the Phi2.)

my 2 cents


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 2:32 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
Dr Jefyll wrote:
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.


I had thought of that before Jeff. I had done exactly that, using the inverse of /QW to drive the OE on the RAM and ROM. It was the original configuration and it didn't work. In fact it was a bit worse as, while I was still able to cold boot to BASIC, I was not able to run any commands like LIST or PRINT without parameters.

The only difference at that time was in using the crystal based clock rather than an oscillator.

Not that I don't see your logic, but I'm fairly sure the 15ns delay in the GAL is a killer one way or another.

Let me see what I can do with what I have and try another test to make sure, but I can either have the delay in the clock going to the CPU or I can have the /RD signal - not both without physically expanding the board.

_________________
Bill


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 2:59 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
BigDumbDinosaur wrote:
That's a 70ns SRAM that generates TTL-compatible outputs, not CMOS levels. In theory, the Voh minimum of 2.4 would not represent a valid logic 1 to the 65C02. We've had discussion in the past as to whether the WDC MPUs in fact recognize a TTL logic 1 as valid.


Sorry folks - I directed you to the wrong datatsheet. The memory I am using is W24257A : https://courses.cs.washington.edu/courses/cse477/99sp/docs/W24257A.pdf

You will find the speed I quote and the correct page are there.

Again, sorry ... :oops:

I know it states minimum Voh as 2.4v, but I have never seen these chips output less than 4.2v in practice. It is, after all a CMOS chip and a Voh of 4.2v will certainly meet TTL input specs so there would be no need to cripple the output drive of them to reduce them to 2.4v.


Quote:
Turning to page 6, of interest (to me) is the SRAM's Tdw specification, which is the amount of time the data bus must be stable after the rise of /WE. The corresponding 'C02 spec would be Tdh, the MPU's data hold time at the end of a write cycle. WDC says that is 10ns after the fall of Ø2. Tdw is 30ns minimum.

Going by those numbers and the SRAM's write timing diagram, it would seem that the SRAM is too slow for the 65C02 at any Ø2 frequency—Tdh is generally not a function of clock rate. If my theorizing is correct, the 'C02 will stop driving the data bus 20ns before the SRAM is finished sampling it.

Incidentally, in the ISSI IS61C1024AL 128KB SRAM I used in POC V1, the equivalent spec to Tdw is 0ns—which implies the SRAM's internal data sampling timing is anchored to when /WE is driven low. That is a lot friendlier when combined with the 65C02 than the Tdw spec of the SRAM you are using.

Quote:
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.

Again, if my theorizing is in the ballpark, the deliberate timing sandbagging is compensating for the discrepancy between the SRAM's Tdw and the MPU's Tdh specs, thus achieving operation.


Surely Tdw is only valid while the chip is selected? As I said, the chip select was going high before the end of the write cycle - that can't be correct either.

Quote:
With the WDC MPUs, the best results are going to be obtained by not qualifying device selection with Ø2.

Agreed - however I am not doing that so I'm not sure why the mention.

Quote:
That is, device selection should occur as soon as an address that is understood by the decoding logic is present on A0-A15. Reading and writing should be separately controlled as illustrated in the circuits earlier published by Jeff and me. You shouldn't have to be doing funky things with Ø2 just to get an SRAM to work. :shock:

I don't think taking the propagation delay out of creating a qualified write is doing anything funky. If that were the case then using 0 propagation delay logic (if such a thing were available) would be doing something funky. :twisted:

IN any case - I'm going to try again to use the original configuration with the oscillator to see if that fixes the problem, however I still think 15ns delay is just too much.

_________________
Bill


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 4:32 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
BillO wrote:
Dr Jefyll wrote:
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.


I had thought of that before Jeff. I had done exactly that, using the inverse of /QW to drive the OE on the RAM and ROM.
The inverse of /QW isn't satisfactory, I'm afraid, or else I'm missing something. During the first half of a write cycle /QW will be high because it's qualified by PHI2 -- isn't that right? So, inverting that, you're putting a low on the /OE -- which leaves us with the scenario I described, or something slightly gnarlier (because /OE does eventually go high, but the damage is already done). What you want is to drive the /OE pins low only when Phi2 is high and RWB is high.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 5:13 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
Dr Jefyll wrote:
The inverse of /QW isn't satisfactory, I'm afraid, or else I'm missing something. During the first half of a write cycle /QW will be high because it's qualified by PHI2 -- isn't that right? So, inverting that, you're putting a low on the /OE -- which leaves us with the scenario I described, or something slightly gnarlier (because /OE does eventually go high, but the damage is already done). What you want is to drive the /OE pins low only when Phi2 is high and RWB is high.

-- Jeff


OK ... so you want /QW to be !(phi2 & !RWB) and /QR t be !(Phi2 & RWB) as per the accepted logic. That should be easy to test and I can do it now.

Be right back....

Update:

Ahhh, the sweet feeling of egg on my face. Well, that works just dandy at 14MHz with or without the delay to the CPU (even with a 120ns ROM!!).

Thanks everyone. This has been a good experience.

What is the opinion on the delay to the CPU? The timings look a lot better that way.

_________________
Bill


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 5:26 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
edit: oops, your update makes this post semi-obsolete. I was going to ask for a drum roll to help build suspense! :)

If you'd still had trouble then the next step would've been this (or the equivalent):
Attachment:
read_write_qualify_with_delay.png
read_write_qualify_with_delay.png [ 65.64 KiB | Viewed 2544 times ]
But it won't be necessary unless the GAL is pretty darn slow. I agree with BDD's remark somewhere upthread. Generally speaking, getting a RAM to work shouldn't require extraordinary measures.

Quote:
What is the opinion on the delay to the CPU? The timings look a lot better that way.
I presume you mean a delay like what's in the diagram above (right?). And I don't have an answer. Looks can be deceiving. What's more credible is an actual test. (Example: max achievable speed. Or, spikiness on the supply rails.) But if there's no demonstrable downside then yeah, go for the nice looking waveforms! :D

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 6:21 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
Dr Jefyll wrote:
Quote:
What is the opinion on the delay to the CPU? The timings look a lot better that way.
I presume you mean a delay like what's in the diagram above (right?). And I don't have an answer. Looks can be deceiving. What's more credible is an actual test. (Example: max achievable speed. Or, spikiness on the supply rails.) But if there's no demonstrable downside then yeah, go for the nice looking waveforms! :D


Yes, I mean a delay as in that diagram.

Max speed is 14MHz, but I suspect that 120ns ROM is the limiting factor as I can get to that speed with or without the delay. Unfortunately I do not have a faster ROM to fit this board. I'll test for spikiness both ways although this fast RAM draws a lot of current and is usually the source of any spikes when it's selected or deselected. However, other duties call right now.

It just makes sense that a 0ns effective delay would be better. No?

_________________
Bill


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 6:32 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10985
Location: England
Great result! Is there any way, or any place, where we could capture what the hazard is and the knowledge as to how to make everything work? (Indeed, now we have an answer, does it turn out that there's anything missing or misleading in the common references?)


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 7:09 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
BillO wrote:
It just makes sense that a 0ns effective delay would be better. No?
Well, I've had enough humbling experiences to become cautious about unsupported conclusions. For example, the effective delay might not be what it seems. Scoping the inputs will show you when the chips are being told to do stuff, but it doesn't reveal how promptly they respond. All that said, here's my take. (Using the CPU clock as our reference, let's speak as though it's the /RD and /WR signals which are being advanced or retarded.)

Advancing /RD and /WR means there's less time for the memories to do their job, so that places a limit on the "early" side. Delaying /RD and /WR means they may still be active after the cycle ends and CPU has begun presenting a new address, and obviously that limits how late things can be (you don't want any spurious accesses).

Another question to ask is, which set of symptoms might might be hardest to detect and thus cause the most grief? (Assuming, I mean, that you prefer "seat-of-the-pants"ing it and/or overclocking, as opposed to a rigorous study of all the propagation times.)

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 7:33 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8505
Location: Midwestern USA
BillO wrote:
BigDumbDinosaur wrote:
That's a 70ns SRAM that generates TTL-compatible outputs, not CMOS levels. In theory, the Voh minimum of 2.4 would not represent a valid logic 1 to the 65C02. We've had discussion in the past as to whether the WDC MPUs in fact recognize a TTL logic 1 as valid.

Sorry folks - I directed you to the wrong datatsheet. The memory I am using is W24257A : https://courses.cs.washington.edu/courses/cse477/99sp/docs/W24257A.pdf

You will find the speed I quote and the correct page are there.

Ah-hah! That's more like it. That SRAM's timing should make it a no-brainer to interface to any 65xx MPU.

Quote:
I know it states minimum Voh as 2.4v, but I have never seen these chips output less than 4.2v in practice. It is, after all a CMOS chip and a Voh of 4.2v will certainly meet TTL input specs so there would be no need to cripple the output drive of them to reduce them to 2.4v.

The problem is that you can't bank (no pun intended) on the device producing anything higher than Voh. A number of factors that are out of your control affect Voh, not the least of which is normal variances in the manufacturing process. Therefore, prudence would dictate designing to the worst-case, which would be Voh = 2.4.

Quote:
Surely Tdw is only valid while the chip is selected? As I said, the chip select was going high before the end of the write cycle - that can't be correct either.

Tdw is based on the (reasonable) assumption that the device will remain selected until the completion of the write cycle. If the order of things is reversed—/WE is still low when /CE goes high—a technically undefined condition has been created, "undefined" meaning Tdw as specified can no longer be used.

Quote:
Ahhh, the sweet feeling of egg on my face. Well, that works just dandy at 14MHz with or without the delay to the CPU (even with a 120ns ROM!!).

Were those eggs scrambled or fried? :D As I earlier said, you shouldn't have to do anything funky with the Ø2 signal just to get an SRAM working.

Dr Jefyll wrote:
But it won't be necessary unless the GAL is pretty darn slow.

He's using a 15ns GAL, which is plenty fast for this application. The cumulative prop delay in my POC V1.1 unit is around 15ns and it will boot at 15 MHz with a 45ns OTP ROM.

BillO wrote:
Dr Jefyll wrote:
Quote:
What is the opinion on the delay to the CPU? The timings look a lot better that way.
I presume you mean a delay like what's in the diagram above (right?). And I don't have an answer. Looks can be deceiving. What's more credible is an actual test. (Example: max achievable speed. Or, spikiness on the supply rails.) But if there's no demonstrable downside then yeah, go for the nice looking waveforms! :D

Yes, I mean a delay as in that diagram.

Max speed is 14MHz, but I suspect that 120ns ROM is the limiting factor as I can get to that speed with or without the delay. Unfortunately I do not have a faster ROM to fit this board.

Faster EPROMs are available if you are inclined to spend a little money. The link ROM is what I've been using.

Quote:
I'll test for spikiness both ways although this fast RAM draws a lot of current and is usually the source of any spikes when it's selected or deselected.

You may discover that the EPROM generates more noise than the SRAM.

Quote:
It just makes sense that a 0ns effective delay would be better.

I see no reason to introduce any contrived delays. You've already proved that your machine will work without them.

Using a PLD, the pin-to-pin delay is usually a fixed number that is theoretically unaffected by the complexity of the logic within. Your GAL is rated at 15ns pin-to-pin and in your application, you aren't using any pins as nodes. Hence chip selects will appear 15ns after the 'C02 has driven A0-A15 to a stable state and your /RD and /WD outputs will uniformly lag Ø2 by 15ns. Given such uniform timing, circuit behavior is quite predictable and should remain so right up to the 65C02's 14 MHz official maximum.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 7:42 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
OMG :shock:

I thought all the time the hazzle was a briefly too late rising edge of /WE (or /OE) and therefor vanishing data.

Mea culpa :oops:


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 9:08 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
BigDumbDinosaur wrote:
The problem is that you can't bank (no pun intended) on the device producing anything higher than Voh. A number of factors that are out of your control affect Voh, not the least of which is normal variances in the manufacturing process. Therefore, prudence would dictate designing to the worst-case, which would be Voh = 2.4.
Strictly speaking, of course. That spec is also for supplying 4ma. That's quite the load. Actually I know a Prudence. If I had a RAM chip that couldn't cut it Pru would dictate that I toss out the malcontented chip in favor of one more willing to play. :twisted: I do understand what your saying BDD, but I'm not designing a heart-lung machine. If I were I'd be more prudent. In this case I'm designing a toy. I've used these a lot with various different CPUs, as well as similarly spec'd AS7C256s and KM68257s and others... I've yet to find one that won't get the job done. I should point out here too that the 27CXXX series EPROMs we all use with abandon are also only rated at a Voh of 2.4V - and at a much lower 400uA. :wink:

Quote:
Quote:
Ahhh, the sweet feeling of egg on my face. Well, that works just dandy at 14MHz with or without the delay to the CPU (even with a 120ns ROM!!).

Were those eggs scrambled or fried? :D As I earlier said, you shouldn't have to do anything funky with the Ø2 signal just to get an SRAM working.
I'm partial to easy-over fried. I just find, unless I do them myself, people generally couldn't scramble eggs to save their lives. You'd think it would be easy but it seems what is easy is taking perfectly good eggs and making yellow sawdust from them. :roll:

Quote:
Dr Jefyll wrote:
But it won't be necessary unless the GAL is pretty darn slow.

He's using a 15ns GAL, which is plenty fast for this application. The cumulative prop delay in my POC V1.1 unit is around 15ns and it will boot at 15 MHz with a 45ns OTP ROM.
Yet in my other project the 15ns GAL limits the speed to below 15MHz. On that one I can get 17MHz with using a 7ns GAL.

Quote:
BillO wrote:
I'll test for spikiness both ways although this fast RAM draws a lot of current and is usually the source of any spikes when it's selected or deselected.
You may discover that the EPROM generates more noise than the SRAM.
I'll look for that too but the max draw on the SRAM 150ma (a lot less in reality - but ... 'specs') and that of the EPROM is only 20ma.

Quote:
Quote:
It just makes sense that a 0ns effective delay would be better.

I see no reason to introduce any contrived delays. You've already proved that your machine will work without them.
I'm not so sure contrived is the right word. It may seem that way as it's never been seen done before with a 6502 system, but exactly such things are done all the time in high speed electronics and experimental physics (where my training is).

As it turns out I have decided to do away with the delay for this project. It works without it and at a speed much higher than I am going to rate the project. I need the extra output pin on the GAL for something more practical.

_________________
Bill


Last edited by BillO on Tue Jun 19, 2018 9:16 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 9:10 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
GaBuZoMeu wrote:
OMG :shock:

I thought all the time the hazzle was a briefly too late rising edge of /WE (or /OE) and therefor vanishing data.

Mea culpa :oops:


Me too. But hey, in our defense, fixing that did get the thing going!

_________________
Bill


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 50 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 33 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: