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.