Page 2 of 2
Re: Nano '816 system
Posted: Thu Apr 10, 2025 1:12 pm
by hoglet
Most of my experience is with Arlet's core -- any my own... Never had that issue.
The 65c02 system is fine with everything on posedge, and Arlet's core puts the signals on the bus and expects a reply next cycle, and other inputs are timed accordingly.
Arlet's core is fairly unique in that respect, as the memory signals are designed specifically for synchronous block RAM (i.e. they are not registered by the core). I don't know of any other core that is designed that way. Most FPGA CPU cores are designed for external asynchronous static RAM, which doesn't contain any registers in the address/data path.
The only alternative to using both edges of the clock is to arrange for the CPU to be clocked on every other cycle, using the clock enable signal. Obviously this halves the effective clock rate.
Dave
Re: Nano '816 system
Posted: Thu Apr 10, 2025 2:03 pm
by enso1
I suppose I should really drive the BRAMs at double the CPU clock, skipping every other cycle.
I am still hazy about the timing, as in what should trigger the BRAM flopping data, or more importantly, the input latch into CPU's Data In lines...
Re: Nano '816 system
Posted: Thu Apr 10, 2025 3:27 pm
by enso1
Somehow I am thinking of it incorrectly, in terms of a clocked memory cycle. I think the best way to envision it is that the address bus (manipulated asynchronously) does what it does and hopefuly holds long enough by the time that the active edge happens, at which point data is flopped.
So if BRAMs are clocked on negedge and it works, it means that the address bus hold is good and I should not be concerned. But I am anyway, because the core logic seems to be all posedged, meaning that the address logic has less than half a clock, which seems strange as the core does quite a bit of decoding and adjustment...
Clocking BRAMs on negedge implies that the CPU needs data held before the posedge.
I could mess with the phase of the BRAM clock to push it to just before the CPU clock, but I am not sure the rest of the CPU can go faster anyway. A 40MHz '09 is not too bad.
Re: Nano '816 system
Posted: Sat Apr 12, 2025 4:06 pm
by enso1
I think I will put this effort on hold until I get back to my lair as it's too painful without a scope. I need to at least see if the Gowin documentation about phase adjustment vs. duty cycle is correct, as the examples in the wild (e.g. NESTang SDRAM controller etc) don't quite match up.
In the meantime I have a stable 6809 system, which is awesome! I haven't coded in assembly for the '09 before, and always wanted to. the '03 looks even more amazing, and I will have to find an '03 core at some point.
Re: Nano '816 system
Posted: Sat Apr 12, 2025 4:09 pm
by BigEd
You might be interested in beeb6809 which includes a bbc basic for 6809
https://github.com/dominicbeesley/beeb6809/tree/master
Also you might be interested in Mike Kohn's recently developed 65832 (as found by Jeff) which of course also includes a 65816 mode as well as a 65c02 mode.
https://www.mikekohn.net/micro/w65c832_fpga.php
Re: Nano '816 system
Posted: Sun May 04, 2025 1:26 am
by Jmstein7
I think I will put this effort on hold until I get back to my lair as it's too painful without a scope. I need to at least see if the Gowin documentation about phase adjustment vs. duty cycle is correct, as the examples in the wild (e.g. NESTang SDRAM controller etc) don't quite match up.
In the meantime I have a stable 6809 system, which is awesome! I haven't coded in assembly for the '09 before, and always wanted to. the '03 looks even more amazing, and I will have to find an '03 core at some point.
I have a working SNES 65C816 core you can port to your SIPEED:
https://github.com/jmstein7/soft_65c816 ... oC_23LC512
Take a look.
Jonathan