6502.org http://forum.6502.org/ |
|
Verilog 6502 core problems specific to Lattice http://forum.6502.org/viewtopic.php?f=10&t=4535 |
Page 1 of 1 |
Author: | kakemoms [ Tue May 09, 2017 2:11 pm ] |
Post subject: | Verilog 6502 core problems specific to Lattice |
I started a new tread as this didn´t belong under announcement. I was discussing 65C02/Arlets core implementation in a Lattice MachXO3L using Lattice Diamond package. BigEd wrote: I've checked on FPGA, and the core is working as expected - I put an INC $3000 in the JMP loop so I could see if it had gone around. (I needed that because I have to reset the 6502 to get out of the JMP loop.) (Might be worth noting: you're not copying the zeroth element of the string, so need to tweak your loop a bit.) Ok. Yea, its just for testing; it might not be a bug, but an interpreter problem specific to Lattice. In my simulator it crashes every time on loop exit (e.g. after 41 branches) with Clock at 33.25MHz. I use an internal memory module that is part of the package. It preloads the assembly code. I have also tried to vary the Clock phase for memory access so that Data gets loaded from memory about 7.5ns earlier or later which always causes the CPU core to miss the reset vector (and then crash). So it does look like these core need the timing to be spot on - at least in the Lattice Diamond suite. Is this true for other FPGA´s too? The question then becomes if I am driving it too fast. The worst slack is positive, so signal timing "should" be ok. But if some of the internal components of the core are timing critical I might need to look into that (if I know were to look). Any suggestions? |
Author: | BigEd [ Tue May 09, 2017 2:41 pm ] |
Post subject: | Re: Verilog 6502 core problems specific to Lattice |
So, you don't mean the CPU goes into an illegal state, you mean the verilog simulator crashes? If you do mean the CPU gets stuck, then it would be useful to see traces. (Thanks for starting a new thread!) |
Author: | Arlet [ Tue May 09, 2017 3:41 pm ] |
Post subject: | Re: Verilog 6502 core problems specific to Lattice |
I'm confused. It sounds like you're running on real hardware, but you speak about simulation. |
Author: | Arlet [ Tue May 09, 2017 6:20 pm ] |
Post subject: | Re: Verilog 6502 core problems specific to Lattice |
The one with 7.5ns too early won't work, because it's already picking up the next byte. The one with 7.5ns late is actually a whole cycle early, so it won't work either. |
Author: | kakemoms [ Wed May 10, 2017 6:22 am ] |
Post subject: | Re: Verilog 6502 core problems specific to Lattice |
Ok. I did some more analysis (e.g. simulation) and it may be related to the way I clock and start the cpu. It may also be related to timing slack of the general system (Lattice & CPLD). If I run the internal oscillator at 133MHz and divide that by some arbitrary number to get the cpu clock, it will require a timing constrain that corresponds to 133MHz. Even if the cpu itself runs at a lower frequency. So the obvious solution is to use an internal oscillator frequency that is lower. Then it works better, but not always. When I start the MachXO3L I do not start the cpu. As reported elsewhere, setting RDY to 0 and starting it later by setting RDY to 1 does not work (some problem in the core model). So I set RDY to 1 and hold the cpu clock HIGH. If I then start it later it works, but ONLY if the cpu clock is the same as the internal oscillator. Thus, I have to set the internal oscillator to 33.25MHz or lower (I found that this was the highest possible value of the core in my interpretation). I did some more analysis of this and even the simulator shows that if I start the core at an arbitrary time, it will crash unless I start it at specific time intervals. I am not 100% sure, but my guess is that there has to be something in the interpreter that ends up wiring the core in a specific way that applies these strange timing-related problems. I know that there are special wiring for the oscillator, so using a divisor may break this constrain and the design ends up with poor clock quality (internally). The cpu will run for a certain number of cycles and stop in an arbitrary state. The strange thing is that the simulator shows the cpu stopping, but I have found no obvious system to when it stops. The first observed stop (on loop exit at BNE) might have been chance. If I used Dual Port memory for the CPU, it would not stop in the simulator. Thus, it may be related to how the simulator models the Single Port memory, or it may be completely unrelated. Just to get further I will test Holmes 6502 core that is based on the actual transistor wiring. My guess is that this will allow for more slack as it cycles through the instruction in several steps, thus each step requires less active area. |
Author: | BigEd [ Wed May 10, 2017 7:39 am ] |
Post subject: | Re: Verilog 6502 core problems specific to Lattice |
You may have missed a very important detail: Arlet's core is designed for clocked RAM, such as you'll find on an FPGA. If using an off-chip SRAM, you'll need to add the pipeline stage to make it work. Every other core I know of is designed for SRAM as-is (and needs adjustment to run with an FPGA's clocked RAM.) So, generally, you can't swap Arlet's core with another core. If you've added a shim to Arlet's core, then you can. |
Author: | Arlet [ Wed May 10, 2017 8:07 am ] |
Post subject: | Re: Verilog 6502 core problems specific to Lattice |
I think it's best not to switch the clock, and instead use the RDY signal if you want to interface with slow memory. FPGAs have special clock distribution nets, separate from normal logic. When you pass clock through logic blocks, the clock timing becomes unreliable. Some FPGAs may support clock switching, but only through specialized blocks. Best first step would be to tie RDY=1 and use clean low clock frequency and make sure everything works. Then start experimenting with RDY signal, and figure out where it goes wrong. Then increase clock. |
Author: | kakemoms [ Wed May 10, 2017 8:35 pm ] |
Post subject: | Re: Verilog 6502 core problems specific to Lattice |
I have redesigned the clock and pushed it through an internal PLL module to make sure it goes on the correct internal clock wiring. It helped with the simulator; the simulated core does not seem to stop anymore. As for the HW, still no luck. I connected the True Dual port memory (internal module for EBR blocks) and it runs fine with the external mos 6502 (through my own logic). But the verilog core does not start in real life. Tomorrow I will test with binding RDY high from the start. I may test delayed start using the Reset line. All internal memory is clocked. That is fine for the 6502 core, but to use it with the external 6502 I need to time the output data correctly to prevent bus contention. At least that part is ok. |
Page 1 of 1 | All times are UTC |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |