Slow progress, but progress nonetheless!

I’ve recently pushed some changed to the TG68MiniSOC Github repo at https://github.com/robinsonb5/TG68_MiniSOC.  Changes this time round include:

  • increasing the system clock frequency to 133MHz.  In order to do this I had to add some wait states to the processor, but the increase in RAM bandwidth makes it worthwhile.
  • Adding some more robust filtering to the PS/2 clock signals.  At the faster clock speed I was finding that the mouse and keyboard were misbehaving – it appeared as though there were spurious clock edges causing the receiver to get a bit or two out of sync with the keyboard and mouse.  After trying various tweaks to the PS/2 module’s parameters with no success, I tried running the PS/2 clock signals through the debouncer I mentioned in the post about latching power circuits – and that seems to work like a charm.
  • Since two of the target platforms have 32 meg of RAM, and since I now have a Platform Specific register the firmware can read to query how much RAM is present, I’ve moved the base address of the hardware registers.  Previously they were at 0x800000, which is 8 megabytes into the address space.  This works out nicely on the DE1 which only has 8 meg of RAM, but on the Chameleon and CIII board the base address needs to be above 32 meg.  So I’ve changed it to 0x80000000 – or 2GB.  Chances are I’m not going to encounter an FPGA dev board with more than 2 gig of RAM!No binaries as yet – and I’ve only tested on one of the three target platforms so far, but… so far so good!

The good news is that in getting things working at 133Mhz, I *finally* found the root cause of the build-to-build stability problem that’s been plaguing the Chameleon’s Minimig core for some months: the CPU’s address goes through some complex combinationals on the way to the SDRAM controller, and takes more than a single cycle to settle; just occasionally the SDRAM controller was latching and processing the address too soon.

Since adding a wait state at the appropriate point I haven’t had a bad build.

8 thoughts on “Slow progress, but progress nonetheless!

  1. OK, still didn’t work. Is there a chance, there is something out of sync on the GIT?
    I got:
    m68k-elf-objcopy -O srec memcheck.elf memcheck.sre
    make: *** No rule to make target ‘BUILD/gfxtest.o’, needed by ‘gfxtest.elf’. Stop.

    Are you actually planing on continuing on the tg68 series?

    Cheers & thanks again …

    • OK I see what’s going on – for some reason a freshly-cloned copy of the repo ends up on the “m4k” branch, not the “master” branch, so if you clone it afresh, and then type “git checkout master” it should start working…

      And yes, I do plan to continue the series at some point, but unfortunately my time is currently quite limited, so I cant promise when it will be. I do plan to add sound capabilities at some point, and to tidy up the code, and make the peripherals far more modular.

      Edit: I’ve just built and tested the master branch of the repo for both the C3 board and DE1 board, and added a few more missing files in the process, so hopefully it will now be in working order. Not sure why it’s defaulting to the “m4k” branch though.

        • I only have one Xilinx-based board here at the moment, which is a Minimig. The FPGA on that isn’t very big, so I’m not sure how much of a squeeze it would be to get this project up and running. The ZPU Demos should be easy enough to port, though – at least those that don’t directly use the SD card.

Leave a Reply

Your email address will not be published. Required fields are marked *