Dave,

Just finished up work - I can't wait to dig into this!

Thank you!

Jon

PS I shall report back with my findings!

That's an interesting idea... I do always have problems debouncing the reset, and every time, that does cause a problem. That's why the debounce verilog unit always ends up sitting on the side, idle. I will tie reset high.

Also, the problem could be in the implementation in the first FPGA (the Cmod A7 with the cpu and sram), right? Which is strange, because when I hook the VIA up to the external bus of the first FPGA directly, it still works just fine. Only when I introduce the second FPGA between the two do I have a problem with it.

Ah, sorry if I'm being a bit slow on the update, but that was not clear to me.

Looking back at the HDL in your original post, I have a few comments, mostly on style rather than substance:

1. It's hugely confusing to introduce un-necessary wires.

For example, you have:

This could be reduced to:


2. If a signal is active low, indicate this with a suffix.

Doing this leads to madness:


3. Where you have a signal xxx that passes through (in on one side, out on the other), a better naming scheme would be xxx_i and xxx_o. Or better still, prefix the all the signals on CPU port with cpu_ (or c) and the all the signals on the peripheral port with per_ (or p_)

4. The clocking looks wrong to me. You have

Doesn't this mean your real 65C22 is being clocked with a system clock (e.g. 50MHz) rather than the divided down version?

But again, naming here makes the intent very unclear....

Stepping back, I'm a bit confused as to why you have introduced a second FPGA just to pass through all the signals.

Dave

Yeah, I've confused myself here as well. My original thought was, if I could design a little, primary fpga with a good, cycle-accurate core, along with plenty of ram, the ROM, and a soft acia core, I could lock that design into a Cmod A7 and then simply focus on peripherals and decoding issues in a second FPGA dedicated to just that (which I could therefore tinker with without disturbing the main cpu, ram, rom, or acia).

It seems like, in the single fpga solution, there is always a weird ripple effect where you make a change and then, say, vivado seems to screw up everything that was already working. For example, the random problems we had with getting the memory to load the ROM image, arbitrarily, because of the vivado optimization routines. This way, with a second FPGA for peripherals, vivado can't interfere with the core components on the primary device.

Jon

Morning!

Yup, the problem has something to do with using the first fpga using Jens's core (and/or maybe the timing I used with that).

https://github.com/jmstein7/65c02_errata/blob/main/t65_beta_done.zip

That is the only explanation, because it works fine with a real WCS65c02. I wonder why that is? I've literally tested this from every possible angle.

Jon

One possible problem with the way you are using Jens' core is the clock polarity.

On the real 65C02 the active edge of the clock is the falling edge. So it's on the falling edge that read data is sampled by the 65C02 for example.

If you look at Jens' core's VHDL implementation, you find the active clock edge is the rising edge:

This is not well documented and it's also not common knowledge because I don't know of anyone actually using this core in a project, as it's so large.

To get a roughly compatible interface you would need to invert the clock inside the FPGA. i.e. the clock fed into the core and the clock output as Phi2 need to be opposite phases.

I think this is why external VIA reads were not working in your system.

It's worth saying again that none of the 65(C)02 HDL cores are designed as a drop-in replacement for a real 65(C)02 without further work. On a real 65(C)02 the outputs change some time after the active (falling) clock edge. On an NMOS 6502 this delay is typically 50-100ns. Systems designed around such components often relied on this delay for correct operation. For example, if you drop any "raw" FPGA core into a real BBC Micro, it will not work! It needs the outputs to be appropriately skewed, like we have done in the version of your project using Arlet's core.

Dave

Given that, then, in what way is Jens’ core “accurate”? I misunderstood. I thought it was so large because it was “drop-in” accurate.

Jon

It's accurate in that the way it executes instrructions, cycle-by-cycle, is identical to a real 65C02. That is to say, the purpose of each cycle of each instruction is the same.

The sub-cycle timing (for example the time from the active clock edge to the output changing), the various setup/hold times, etc, are not guarenteed to be the same at a real 65C02. In this respect Jens' core is no different to any other FPGA core. These low level timings will depend on newness of the FPGA technology, and also on how the FPGA has routed. It's possible to pass external timing constraints to the router, but these are very difficult to work with.

The use of the rising rather than falling clock edge is more a matter of convention. The vast majority of FPGA cores will choose to use the positive edge. It makes hooking them together easier and more consistent. If the outside world needs something different, then it can be dealt with on the periphery by inverting the clock, which is trivial.

Dave

So, given that - for the purpose of what we’re doing in the subject project, there is every reason to stick with Arlet’s core, as modified by you. And there is no advantage to using Jens’ core; only a detriment - lost space.

Jon

Agreed, and the other detriment is increased routing time in Vivado.

So, I was thinking, earlier, about what the goal here really is; toying with the "generic ram" module, I was wondering whether it would be possible to create 65xx IP blocks for Vivado IP integrator, and Quartus Platform Designer, such that people could drop, say, a cpu block, a ram block, a rom block, and an acia block onto the canvas, wire it up, upload a rom image, and, viola! A generic system, ready to use! I know how to create custom IP blocks for Quartus and Vivado - and I've done rom and ram blocks before. I can integrate the blocks with axi and avalon, and all that good stuff. What I don't know how to do is create the requisite hdl for the processor and peripherals - the VIAs and ACIAs.

I've tried using the various cores we've discussed and used here, but I just cannot get it to work (obviously). Is it possible to integrate, e.g., Arlet's core into a ubiquitous unit, as well as a via and acia, such that we could create drag and drop ip in vivado ip integrator and have a working system? Perusing the forum, I think there would be a lot of interest in such a project. Moreover, if we can get that working, we can create blocks for other chips, like audio and video peripheral chips.

It would make 65xx hdl cores accessible to people who might, otherwise, be discouraged from dabbling in such things, because, let's face it, the barrier to entry is pretty high right now - this is pretty complex stuff. At a minimum, it would open up routes for innovation to those who otherwise might not find these avenues accessible.

Jon

I don't think it's fair to say it doesn't work. We have a basic system working that uses Arlet's CPU core, block RAM, block ROM, a VIA, an ACIA, and an external bus interface connected to an external VIA. At least, it's working for me. If that same system isn't working for you, then we need to keep digging.

I think some of your frustration is because we are using a collection of 8-bit modules that don't share a common interface, and so don't quite connect directly together. Modules that could be identical, such as different CPU cores, choose slightly different names for signals, sometimes use those signals differently, and are often not well documented. It's difficult to build a working system out of these modules without a good understanding of these the subtleties. And when the scope is extended to include external peripherials, like real VIA and ACIAs, that adds another layer of complexity.

What's needed I think to solve this problem is for each module to implement a common interface. In the FPGA world there is exactly such an interface, called the wishbone bus. It's been around for about 20 years and many of the modules on opencores support it. However, it comes with a certain amount of complexity, because it's very generic and because it's not tied to any one processor family. Some people on this forum (myself included) have used it in their own projects, but I've not seen it widely used in 8-bit systems.

[ Edit: It's also worth saying as well as Wishbone, there are many other "SoC" buses: AMBA, AXI, OCP, CoreConnect, MSBUS, etc. There is a overview/comparison here. I picked Wishbone as an example above because it's the one I am most familiar with. ]

Once you have a set of modules that implement a common interface, like wishbone, I'm honestly not sure encapsulating them as IC Blocks for use with Vivado's IP integrator adds much value. It's just another level of abstraction, it ties you into using one vendor's tool chain, and even then it only supports their more recent/higher end devices.

Personally, I avoid Xilinx's IP framework as much as I can, preferring instead to develop everything as HDL. That makes it easier to build projects that target Altera, Lattice and Xilinx devices. It makes it easier to keep projects under revision control. And it makes it easier to do system simulation with third-party tools like Icarus Verilog. But I do accept that other may view this differently, and find the block diagram tools a useful way to visualize the whole design.

It's important to realize the Xilinx's IP framework does not, itself, solve the problem of interoperability between modules. You still need to design (or leverarage) a common internal bus (like wishbone), then create a set of modules that implement this bus interface. This is a manual process and it requires a good knowledge of HDL design, and a good knowledge of the existing components you leverage. It's not at all easy to do this well, which I think is why it's not yet been done for 6502 based systems.

This is quite an interesting topic, does anyone else have a view, or any suggestions for Jon?

Dave

It works perfectly, per se. What I haven't been able to do is take what is already working and create generic, working, interchangeable blocks that work, the "common interface" you described. So, yes, you hit the nail on the head, here. What we have works fine, but once I try to mess with it, and use the components in the "generic way" you described, it’s a no go. Because, as you said, it is very complex.

Jon

I think what we're seeing here is that it's hard enough (for most of us) to get something working. It's harder still to make something reusable, or to fully document it, and so we see what we see. It's long been an observation in the semiconductor industry, that each company invents its own pieces - indeed, in a team of 20 we had three or four independently created libraries. But the business of selling IP has been very slow to take off, because you have to put in an order of magnitude more work, and then recoup your investment by selling at a price, and then the potential customer is quite likely just to think they could have built it themselves.

And it's the same in open source - things are not plug and play, because plug and play is much more difficult. (And it's easy to get discouraged when the inevitable complaints come in, that something isn't exactly as someone expected.)

Which is to say, we tend not to value each other's work, and we tend not to value our own time.

Totally agree.

I'm not so sure about that. I'm blown away by the things you veterans here can do. And, I am incredibly thankful that you guys would even deign me worthy of a significant amount of your time. That's why, I think, this forum thrives.

As to not valuing our own time - it depends. I think. I mean, I take great pleasure in reading all your replies here, seeing what you've done, or suggested, and then trying to implement and understand it. Incredibly valuable. And, on the veteran side of things, well, you're perpetuating (and improving) the state of the art. And if you value your art, then it is time well spent.

Jon