C_OE minimum high/low periods
12 views
Skip to first unread message
Chris McClelland
Apr 6, 2012, 1:03:18 PM4/6/12
to UMDKv2 Developers
In an effort to understand the various cart read cycles better, I
tried connecting my FPGA via a short wire to C_OE of a commercial game
(with a 220R resistor to ground which pulls the high level down to a
safe level for my FPGA).
http://www.swaton.ukfsn.org/temp/toplevel_vhdl.txt
The VHDL has a 100MHz clock (clock-doubled from the 50MHz onboard
crystal). It displays a count of the minimum number of consecutive
10ns cycles that the C_OE line has been low, and a similar minimum
count for the C_OE high.
First the good news - the minimum C_OE *high* time (i.e the interval
between consecutive reads) appears to be 140ns. Note that I have no
address decoding, so that figure does not necessarily represent
cartridge reads. Similarly I have made no distinction between 68K vs
Z80 vs VDP cycles.
The bad news - the C_OE *low* time seems to very regularly hit 120ns,
but there are times when it glitches low for shorter periods, right
down to 10ns.
Maybe this is due to the FPGA picking up oscillations during
switching, but I doubt it, otherwise I would have seen very short
*high* periods in addition to the very short low periods.
Right now I'm kinda stumped. Such short glitches on the C_OE line
obviously don't matter for the asynchronous memories found in
commercial carts and flash-carts, but they will cause havoc with the
synchronous memories we're hoping to use.
I guess another approach would be to trigger a read when the address
lines have been stable for more than 30ns or something. C_OE would
then be used only as input to the decision about whether to drive the
databus. The decision about whether to begin a memory read would only
consider the address lines, not C_OE. It would be wasteful, because
there's no guarantee the cycle won't turn out to be a write cycle, in
which point we've done a read for no reason.
What a mess.
Chris
tried connecting my FPGA via a short wire to C_OE of a commercial game
(with a 220R resistor to ground which pulls the high level down to a
safe level for my FPGA).
http://www.swaton.ukfsn.org/temp/toplevel_vhdl.txt
The VHDL has a 100MHz clock (clock-doubled from the 50MHz onboard
crystal). It displays a count of the minimum number of consecutive
10ns cycles that the C_OE line has been low, and a similar minimum
count for the C_OE high.
First the good news - the minimum C_OE *high* time (i.e the interval
between consecutive reads) appears to be 140ns. Note that I have no
address decoding, so that figure does not necessarily represent
cartridge reads. Similarly I have made no distinction between 68K vs
Z80 vs VDP cycles.
The bad news - the C_OE *low* time seems to very regularly hit 120ns,
but there are times when it glitches low for shorter periods, right
down to 10ns.
Maybe this is due to the FPGA picking up oscillations during
switching, but I doubt it, otherwise I would have seen very short
*high* periods in addition to the very short low periods.
Right now I'm kinda stumped. Such short glitches on the C_OE line
obviously don't matter for the asynchronous memories found in
commercial carts and flash-carts, but they will cause havoc with the
synchronous memories we're hoping to use.
I guess another approach would be to trigger a read when the address
lines have been stable for more than 30ns or something. C_OE would
then be used only as input to the decision about whether to drive the
databus. The decision about whether to begin a memory read would only
consider the address lines, not C_OE. It would be wasteful, because
there's no guarantee the cycle won't turn out to be a write cycle, in
which point we've done a read for no reason.
What a mess.
Chris
Chris McClelland
Apr 7, 2012, 3:04:47 PM4/7/12
to UMDKv2 Developers
It occurred to me that it's pretty unlikely circa-1990 chips are
capable of driving signals at the sort of speeds I was seeing. So my
new theory is a bit more believeable: the relatively slow slew rate of
C_OE is causing the non-Schmitt inputs on my FPGA to glitch during
transitions. If this is the case, there are a couple of possible
solutions - use a Schmitt buffer[1] for C_OE, or build suitable
debouncing logic into the VHDL.
Also, although I have seen the FPGA-buffered version of C_OE remain
*low* for periods of the order 10ns, I have never seen it remain
*high* for periods shorter than 100ns. That observation is not
compatible with the theory. Unfortunately I don't have an oscilloscope
fast enough to provide convincing evidence.
Chris
[1] e.g http://uk.farnell.com/fairchild-semiconductor/nc7wz17p6x/ic-buffers-drivers-receivers/dp/1651986RL
capable of driving signals at the sort of speeds I was seeing. So my
new theory is a bit more believeable: the relatively slow slew rate of
C_OE is causing the non-Schmitt inputs on my FPGA to glitch during
transitions. If this is the case, there are a couple of possible
solutions - use a Schmitt buffer[1] for C_OE, or build suitable
debouncing logic into the VHDL.
Also, although I have seen the FPGA-buffered version of C_OE remain
*low* for periods of the order 10ns, I have never seen it remain
*high* for periods shorter than 100ns. That observation is not
compatible with the theory. Unfortunately I don't have an oscilloscope
fast enough to provide convincing evidence.
Chris
[1] e.g http://uk.farnell.com/fairchild-semiconductor/nc7wz17p6x/ic-buffers-drivers-receivers/dp/1651986RL
Rafael Gama
Apr 7, 2012, 4:16:06 PM4/7/12
to umdkv...@googlegroups.com
Hello Chris.
Even with the strange low glitches, it's a great new that you had some progress measuring the behavior of C_OE.
> The bad news - the C_OE *low* time seems to very regularly hit 120ns,
> but there are times when it glitches low for shorter periods, right
> down to 10ns.
> but there are times when it glitches low for shorter periods, right
> down to 10ns.
Is it ok for your actual PSRAM controller to deal with those 120ns strobes ?
It occurred to me that it's pretty unlikely circa-1990 chips are
capable of driving signals at the sort of speeds I was seeing. So my
new theory is a bit more believeable: the relatively slow slew rate of
C_OE is causing the non-Schmitt inputs on my FPGA to glitch during
transitions. If this is the case, there are a couple of possible
solutions - use a Schmitt buffer[1] for C_OE, or build suitable
debouncing logic into the VHDL.
Also, I believe that the speed grade of ROM chips inside 1990 cartridges were something like 100ns~120ns. So, I guess that even the VDP (dma) accesses shouldn't be faster than ~100ns.
The Schmitt Trigger buffer looks like a great idea. It would be great if the FPGA device had that built-in as an option.
Also, although I have seen the FPGA-buffered version of C_OE remain
*low* for periods of the order 10ns, I have never seen it remain
*high* for periods shorter than 100ns. That observation is not
compatible with the theory. Unfortunately I don't have an oscilloscope
fast enough to provide convincing evidence.
I am still trying to build all the necessary stuff to perform the tests with C_OE and M3.
As soon as I have any result, I will post it here. Sorry for the late reply.
Rafael.
Chris McClelland
Apr 8, 2012, 5:20:27 AM4/8/12
to UMDKv2 Developers
The situation is complex. I have three PSRAM controllers:
1) The synchronous controller checked into GitHub: clocked at 96MHz,
it explicitly generates a 48MHz clock for the RAM. Arguably, it has
twice as many states as is strictly necessary.
2) A synchronous controller clocked at 48MHz. Basically the same as
(1) but with roughly half the number of states.
3) An asynchronous controller, using the MegaDrive strobes directly.
None of them are 100% well-behaved. (1) happily runs Sonic
indefinitely (weeks), but on Street Fighter 2, it gives the weird
vertical-bar swapping I posted earlier. The (2) & (3) controllers both
appear to work nicely with Street Fighter 2, without any visual
artifacts. But sooner or later, both will crash the 68000 (illegal
instruction, line f emulation, etc). My theory is that even though the
PSRAM ostensibly behaves like an SRAM, it's architecturally
fundamentally different, and short glitches on its control inputs
cause havoc. And for some reason I don't understand, (1) is somehow
not susceptible to the glitches.
Chris
1) The synchronous controller checked into GitHub: clocked at 96MHz,
it explicitly generates a 48MHz clock for the RAM. Arguably, it has
twice as many states as is strictly necessary.
2) A synchronous controller clocked at 48MHz. Basically the same as
(1) but with roughly half the number of states.
3) An asynchronous controller, using the MegaDrive strobes directly.
None of them are 100% well-behaved. (1) happily runs Sonic
indefinitely (weeks), but on Street Fighter 2, it gives the weird
vertical-bar swapping I posted earlier. The (2) & (3) controllers both
appear to work nicely with Street Fighter 2, without any visual
artifacts. But sooner or later, both will crash the 68000 (illegal
instruction, line f emulation, etc). My theory is that even though the
PSRAM ostensibly behaves like an SRAM, it's architecturally
fundamentally different, and short glitches on its control inputs
cause havoc. And for some reason I don't understand, (1) is somehow
not susceptible to the glitches.
Chris
Rafael Gama
Apr 8, 2012, 8:57:19 PM4/8/12
to umdkv...@googlegroups.com
I see...
It all seems really intriguing.
Have you noticed the 10ns glitches running both games (Street Fighter II and Sonic) ?
What is the hardware method to ensure that when C_OE is low, it is really a cartridge ROM read ? Are you relying on the address lines or on the chip enable signal ?
Chris McClelland
Apr 9, 2012, 7:48:51 AM4/9/12
to UMDKv2 Developers
> Have you noticed the 10ns glitches running both games (Street Fighter II
> and Sonic) ?
I think so, yes. I have seen the glitches when the FPGA is emulating
> and Sonic) ?
the game ROM, and also when the FPGA is just looking at C_OE on a real
game cartridge (a pinball thing with incredibly annoying music).
> What is the hardware method to ensure that when C_OE is low, it is really a
> cartridge ROM read ? Are you relying on the address lines or on the chip
> enable signal ?
not strictly correct because /C_CE only asserts in the first 4MiB (or
in the second 4MiB if /CART_IN is not asserted), but there is
definitely no contention from other devices in the system in the
bottom 8MiB (i.e bottom half of the address space).
I'll try to implement some debounce logic to filter out the glitches,
but it's hard because I don't know how short the /C_OE asserts can
legitimately be; I'm assuming they won't be shorter than 100ns because
then the mask ROMs in commercial games would presumably fail.
Chris
Chris McClelland
Apr 11, 2012, 2:53:11 PM4/11/12
to UMDKv2 Developers
OK, I made some progress.
I built a simple logic-analyzer that samples two signals at 48MHz and
sends the data over USB back to the PC. I can sample two signals at
48MHz for up to 20mins, but that would result in a 14GiB log file!
I have just sampled /C_OE for half a minute (30sec) and analyzed the
log file. The results are rather interesting.
Firstly, I have stripped the test rig down to bare bones: I have a
commercial game cartridge (Crue Ball), to which I've added a resistor
between /C_OE and ground, which drags the /C_OE high level down to
about 3.3V. At this level the game still works fine, but it's safe to
connect directly to an FPGA input without the need for a level-
converter chip. The analyzer generates a big (340MiB) datafile, and I
wrote a conversion program to allow me to view the results in GTKWave.
Here's a small sample of what the /C_OE data looks like:
http://www.swaton.ukfsn.org/temp/oeSample.jpg
Further analysis gives some useful statistics:
http://www.swaton.ukfsn.org/temp/stats.txt
First the shortest /C_OE low and high periods:
Shortest low period was 7 cycles (146 ns)
Shortest high period was 7 cycles (146 ns)
Now the longest /C_OE low and high periods, which are surprising:
Longest low period was 105 cycles (2188 ns)
Longest high period was 844 cycles (17583 ns)
It seems to me like 17.5us is a long time to be sitting there not
accessing any memory or registers!
Then you get some data giving an indication of how common /C_OE
asserted periods of each length are:
Low period cycle distribution:
7 cycles: 264865
8 cycles: 89440
9 cycles: 12841
10 cycles: 582
15 cycles: 8528007
16 cycles: 26985259
21 cycles: 1919
This means that in my 30sec sample, there were nearly 27 million
occasions when /C_OE asserted for 16 cycles (~333ns). This is by far
the most common assert duration, but there are comparatively rare
occasions when it asserts for only 7 cycles (~146ns). By "rare" I mean
there were "only" 264,865 occasions in my 30sec sample where this
happened. Notice I have filtered out zeros in the data: there were
ZERO occurrences of /C_OE asserting for 11, 12, 13, 14, 17, 18, 19, 20
cycles.
Finally you get similar data for the gaps between /C_OE asserts:
High period cycle distribution:
7 cycles: 117671
8 cycles: 27830
9 cycles: 10543899
10 cycles: 10861566
15 cycles: 18998
So, in my 30sec sample, there were over 10 million occasions when /
C_OE deasserted for 9 cycles (~187ns) and a similar number of
occasions where it deasserted for 10 cycles (~208ns). These two
represent by far the most common deassert duration. Again, there are
comparatively rare occasions (117,671 in my 30sec sample) when it
deasserts for only 7 cycles (~146ns).
In summary:
/C_OE asserts have a typical duration of 333ns and a minimum
duration of 146ns.
/C_OE deasserts have a typical duration of 187-208ns and a minimum
duration of 146ns.
I can now try similar tests including other signals in the sampling,
so for example I can determine the minimum setup time for the address
lines before /C_OE asserts, and verify that the address lines never
change whilst /C_OE is asserted. I can also run similar tests with the
FPGA doing ROM emulation, and hopefully thereby determine the exact
cause of the crashes I was seeing. I also got some fast Schmitt
trigger inverters, so I can see what effect they have on the signals
too.
Chris
I built a simple logic-analyzer that samples two signals at 48MHz and
sends the data over USB back to the PC. I can sample two signals at
48MHz for up to 20mins, but that would result in a 14GiB log file!
I have just sampled /C_OE for half a minute (30sec) and analyzed the
log file. The results are rather interesting.
Firstly, I have stripped the test rig down to bare bones: I have a
commercial game cartridge (Crue Ball), to which I've added a resistor
between /C_OE and ground, which drags the /C_OE high level down to
about 3.3V. At this level the game still works fine, but it's safe to
connect directly to an FPGA input without the need for a level-
converter chip. The analyzer generates a big (340MiB) datafile, and I
wrote a conversion program to allow me to view the results in GTKWave.
Here's a small sample of what the /C_OE data looks like:
http://www.swaton.ukfsn.org/temp/oeSample.jpg
Further analysis gives some useful statistics:
http://www.swaton.ukfsn.org/temp/stats.txt
First the shortest /C_OE low and high periods:
Shortest low period was 7 cycles (146 ns)
Shortest high period was 7 cycles (146 ns)
Now the longest /C_OE low and high periods, which are surprising:
Longest low period was 105 cycles (2188 ns)
Longest high period was 844 cycles (17583 ns)
It seems to me like 17.5us is a long time to be sitting there not
accessing any memory or registers!
Then you get some data giving an indication of how common /C_OE
asserted periods of each length are:
Low period cycle distribution:
7 cycles: 264865
8 cycles: 89440
9 cycles: 12841
10 cycles: 582
15 cycles: 8528007
16 cycles: 26985259
21 cycles: 1919
This means that in my 30sec sample, there were nearly 27 million
occasions when /C_OE asserted for 16 cycles (~333ns). This is by far
the most common assert duration, but there are comparatively rare
occasions when it asserts for only 7 cycles (~146ns). By "rare" I mean
there were "only" 264,865 occasions in my 30sec sample where this
happened. Notice I have filtered out zeros in the data: there were
ZERO occurrences of /C_OE asserting for 11, 12, 13, 14, 17, 18, 19, 20
cycles.
Finally you get similar data for the gaps between /C_OE asserts:
High period cycle distribution:
7 cycles: 117671
8 cycles: 27830
9 cycles: 10543899
10 cycles: 10861566
15 cycles: 18998
So, in my 30sec sample, there were over 10 million occasions when /
C_OE deasserted for 9 cycles (~187ns) and a similar number of
occasions where it deasserted for 10 cycles (~208ns). These two
represent by far the most common deassert duration. Again, there are
comparatively rare occasions (117,671 in my 30sec sample) when it
deasserts for only 7 cycles (~146ns).
In summary:
/C_OE asserts have a typical duration of 333ns and a minimum
duration of 146ns.
/C_OE deasserts have a typical duration of 187-208ns and a minimum
duration of 146ns.
I can now try similar tests including other signals in the sampling,
so for example I can determine the minimum setup time for the address
lines before /C_OE asserts, and verify that the address lines never
change whilst /C_OE is asserted. I can also run similar tests with the
FPGA doing ROM emulation, and hopefully thereby determine the exact
cause of the crashes I was seeing. I also got some fast Schmitt
trigger inverters, so I can see what effect they have on the signals
too.
Chris
Rafael Gama
Apr 11, 2012, 5:25:44 PM4/11/12
to umdkv...@googlegroups.com
That is a huge progress!
I've made some tests with an oscilloscope that confirm the shortest cycles (~146ns) that you've observed. I will post the results and the methodology as soon as I have some free time.
The low/high period histograms that you've made are just wonderful!
I am really excited with those results, as I am starting to think that timing won't be a problem for the SDRAM controller to work. Also, those results made me think in some theories to explain why my CPLD/ADRAM project failed. In fact, in the last days I took that project out of the closet. It was really dusty and with some broken wires. So, I've spent some time to get it back working as it was my only hope to run some test code on the Megadrive. These test programs allowed me to do the mentioned measurements with /OE and /CE signals.
I am really hopeful that you're going to be able to determine the cause of the UMDKv2 crashes.
Rafael.
2012/4/11 Chris McClelland <proph...@gmail.com>
Reply all
Reply to author
Forward
0 new messages