Sonic 1 Bus-Cycle Tracing Example

[HardWareMan]

How about PLL jitter?

[prophet36]

Yep, another complexity to take into account.

Let's step back a bit. The ultimate objective is to switch the timestamp for each bus transaction in the trace-log from a 48MHz counter to the 7.6MHz VCLK. There are two proposed solutions, both of which are functionally identical (i.e from a user's perspective, assuming they both actually work, there'll be no discernible difference between them):

-------------------------------
System-Synchronous Solution
Lift a couple of legs of U2 on the bridge-board to allow the VCLK signal from the MD to be routed through U2 to the FPGA channel currently unused (earmarked for DTACK-generation).

Then inside the FPGA, two register stages, generating vclk_old and vclk_new, and only increment the timestamp counter when vclk_old = '0' and vclk_new = '1'.

Risks: none.
Estimated time to get working: 1 hour.

Dual Clock-Domain Solution
Find a suitable GCLK site on the FPGA. Cut tracks and swap with the I/O for DTACK. Do the same hardware mods to the bridge as in (1).

Then inside the FPGA, add a multiplier DCM unit to the newly-routed VCLK, generating a 53MHz clock. Use that to clock all the MD-facing logic. Add hardware FIFOs for crossing the 48MHz/53MHz clock-domains to the host trace pipe and the host memory request & response pipes.

Risks: Signal-integrity of the flying VCLK wire may not meet minimum jitter requirements of the DCM. The SDRAM may not work at 53MHz.
Estimated time to get working: 1 week?
-------------------------------

Ultimately it's Nemesis's decision, but I know which one I'd choose!

[Jorge Nuno]

SDRAM may not work at 53MHz? really? lol


Also the comparison isn't fair as the MD isn't system synchronous with your FPGA logic. You had to put dual DFFs to prevent metastability on MD's lines, probably not on all, just on the read/write strobes (which is what triggers your internal state machines anyways). So the resynchronization stage is already in place, it would just be crossing to a different clock.

The biggest issue about using the VCLK directly (after a dual DFF stage to 48M) is that DMA and Z80 accesses will be mis-measured.

DCM jitter isn't really an issue on this application. But yeah, counting on Vclk is easy

[prophet36]

SDRAM may not work at 53MHz? really? lol

As I've mentioned before, SDRAM is optimised for throughput, not latency. Achieving tight latency requirements, even those of the lowly MegaDrive, is non-trivial. It always comes down to a delicate balance between clock-speed and the timings in the SDRAM datasheet. KRIKzz too has mentioned that it is not easy to hit the MD latency requirements with SDRAM:

prophet36 i wonder if your memory controller enough fast for 32x? while ago i used altera DE1 for build similar thing, genesis games works fine, but 32x unfortunately not. i tried to count write/read period for 32x and looks like 32x has twice more fast r/w timings than genesis dma. my first sdram controller was too slow even for genesis dma, so any attempts to use dma was failed (just glitches on the screen instead of graphics). currently my controller enough fast for genny dma, but just bit more fast than req by dma, so if so if few Mhz down, then i will back to glitches world

Much of the UMDK hardware design is tightly-coupled, with decisions in one area affecting decisions in others. Several times I had to abandon promising avenues of development. It would have been great to have someone else like you to collaborate with when I first posted here asking for help, five years ago:

My problem is that I work full-time so I can only afford to spend a few hours per week on this thing, so I'm thinking of releasing the whole lot (Eagle schematics & layout, PAL design, firmware source etc) with an open-source licence, in the hope that someone out there is interested in contributing. So...any volunteers?

...but that didn't happen. Beyond a few very helpful hints from Graz about getting into FPGA development, and a few very helpful hints from people like Chilly Willy about MD internals, and a lot of moral support from people like KanedaFr & MintyTheCat, I had to build this project entirely on my own. And that's fine, I learned a lot doing it. But right now as far as I'm concerned it works perfectly well, so I'm not too interested in re-engineering efforts. Besides, I've moved on to other unrelated projects (spacecraft engineering FTW).

That said, of course you're free to take this project in any direction you wish, and within reason I'm ready to help you do it. But in my opinion you're proposing a lot of extra work that has significant risks and no tangible benefits. But that's just my opinion: I will be the very first to congratulate you when you prove me wrong.

[Jorge Nuno]

I forgot to say something.

Only the counter would be running from 53M. The rest of the system would stay the same. No need to reinvent *everything*

I know SDRAM and boy does it suck... Well, yes it's true that it's made for burst accesses and sucks for random accessing. The same can be said for all successors. Thing is that CPUs have caches and request loads of data from memory on a miss, and it fits this task perfectly. This is why you see memories going up and up on the MHz while the burden of requesting the first data is still the same.

Either way if you moved on.. there's no use beating on this. As I said, this is awesome, but myself (if I would be doing it) I'd do it differently: using MD's timebase, an altera chip and 2 layer board. As for the DMA timing, the worst case (CRAM/VSRAM) is a 150ns low pulse and a 150ns high pulse, so data has to be ready before 150ns, excluding synchronization stages. Naturally bigger clocks help here to minimize the access awareness, as the incoming R/W signals are "sampled" faster. I also got my ass handed over to me on developing MD carts due to this. At 50MHz you lose 40ns (worst case) just to make the signal go through the "syncronizator"