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.



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?

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!)

I'm confused. It sounds like you're running on real hardware, but you speak about simulation.

Well to be specific I put it in hardware and run it through simulation. Usually I simulate it first (as it obviously wouldn't work IRL if not in simulation). So the core crashes in the simulation; meaning it goes into some undefined state.

Here is the "normal" traces in which the core starts as it should. E.g. it loads FFFC, FFFD and pushes the data on PC which then runs normally for some hundred cycles:


Then I have tested it with data arriving 7.5ns before clock edge:


And last data arriving 7.5ns after clock edge:


As you can see, the core only starts if the data arrives at the exact same time as the clock edge.

The point is that I think that the crash I experience may be related to the same issue if timing has to be precise for the core to work.

All these curves comes from the simulation program "Active-HDL 10.3". The core crashes in real HW too (MachXO3L).

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.

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.

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.

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.

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.

Short update: I have nailed down the problem to be due to the internal clock of th... blah blah blah!

Edit:
Its WORKING! Wee.

The problem must have been in some wiring of the reset signal that somehow was trying to retrigger the circuit at the same frequency of the clock signal. I have no idea why, but I could atleast remove the problem, and voilá, the 65C02 started running like a dream.

I use an old Vic-20 to control it by having its 6502 programming the MachXO3 internal memory, then starting the 65C02 core of the MachXO3 and it runs and does its thing.

The attached image isn't much, but its the 65C02 that wrote the sentence "THE SUPERVIXEN HAS STARTED!". So basically two 6502 running within the same memory.

Now, I have cheated a little since its a dual port memory module, but the single port logic is still there and I will use that to get the two 6502 multiplexed into its fast memory. Maybe I can even make room for three 6502 eventually.

Anyway, thanks for all the help here!