Adhere to industry standards

[sy2002]

This issue is spawned from issue #41. There, @MJoergen proposed in #41 (comment) to adhere to the Avalon-MM interface. @sy2002 answered in #41 (comment) that also WishBone might be something we could look at.

This issue is about the general discussion of industry standards and about the transformation of the QNICE-FPGA project to adhere to such.

At this very moment, my proposal is V1.8

[MJoergen]

This is a tough call.

First of all, I think we SHOULD adhere to SOME industry standard. What we have now is a proprietary bus, and that puts extra burden on users who want to modify the system either with a block they write themselves, or with an open-source block.

However, which system bus to choose is not clear. I mentioned Avalon MM, because that is what Intel provides in their ready-to-use blocks. On the other hand Xilinx uses AXI-Lite, but that bus is considerably more complex (roughly twice as many signals and much more asynchronous). And then you mention Wishbone. I don't have any personal experience with that bus, but it is widely used on the https://opencores.org/ website. There is also yet another bus protocol called AMBA, but I know even less about that one.

I guess the only negative thing I have to say about Wishbone is that I find the specification is hard to read and very long (128 pages!).

But according to the Wikipedia page, the Avalon MM and Wishbone busses are very similar, so any technical differences are negligible (at least for the QNICE system).

I do see a value in being compatible with OpenCores.

Regarding timeline, I still think the change (once we agree on which bus to use) is easy to implement and I see no reason for postponing to V1.8.

[sy2002]

I would tend to Wishbone because of OpenCores and the Open Source nature of our project but I need to admit that I neither read any of these specs and have really no idea... :-)

@bernd-ulmann Adding you to the discussion - please read Michael's comment #158 (comment)

@MJoergen The only argument I am having for moving this whole topic to V1.8 is that my TODO stack for making MEGA65 work again is already growing pretty large and my "Christmas break" is not endlessly long, so doing this one here in V1.7 adds one more piece to my personal stack ;-) But if you truly want to do this for some reasin in V1.7, then I am not opposing.

EDIT: And maybe the second argument for V1.8 is that I fear changes in SEMANTICS and that the past has shown us: Every little change in semantics turns this project into a pretty unstable state and it takes quite some effort to restabilize all the 1001 situations...

[MJoergen]

We can leave it in V1.8, that suits me fine. It's certainly not urgent.

[bernd-ulmann]

That is an interesting topic. To be honest, I have no idea of modern bus systems - the last "standard" bus system I really had hands-on-experience was the VME bus which was decades ago...

You are definitely right that we should adhere to a standard bus system. Is one of those you suggested more common than another one?

Are two distinct data busses, one for input, one for output, state of the art? I am so old :-), I still think in terms of bidirectional data lines... :-)

[MJoergen]

I'm currently looking at the Wishbone standard. Here are some notes and thoughts.

The wishbone protocol does offer possibility of high bandwidth, and supports pipelined accesses, see e.g. section 3.1.3.2 "Pipelined wishbone protocol" in the wishbone B4 specification. And has widespread support on the opencores website.

The wishbone protocol allows the Slave to answer whenever it can, however no earlier than the next clock cycle. In other words, this protocol does NOT allow for combinatorial reads. This is a good thing, because combinatorial reads lead to very low clock rates.

The latency in the wishbone protocol is not specified, other than it is minimum one clock cycle. So the protocol is generic in that it allows some slaves to respond on the next clock cycle, while others may respond many clock cycles later. This could be useful when we add the DDR memory with its 20-cycle latency. The CPU will have to be (re)-written in a way to accommodate this. Therefore, changing the bus interface to wishbone should probably be done simultaneously with the pipelined CPU implementation.

With all that said, I still have some problems understanding the protocol. For instance, illustration 3-6 in the specification

shows that a simple read takes two clock cycles. Notice in particular the signal CYC_O is asserted for both clock cycles, indicating that no other transactions may take place. Pipelining is only relevant (if I understand correctly) when accessing the same device. This is shown in illustration 3-11:

On the other hand, PERMISSION 3.05 in the standard says:

MASTER interfaces MAY assert [CYC_O] indefinitely.

So the way I interpret this is that the CYC_O signal is useful, if the system allows for multiple masters, e.g. if a DMA wants to write to memory. In this case the CPU will deassert CYC_O and then the DMA, which also is a wishbone master, will assert its CYC_O signal, while it is in control of the bus. I assume we want to allow a DMA in the future at some time, so the CYC_O signal is important, but perhaps for now the CPU can just assert that signal indefinitely, in accordance with PERMISSION 3.05 above.

But does this then allow single cycle reads, i.e. sending read requests back-to-back? Well, looking at illustration 3-11 it would seem so. So this is my understanding at the moment:
When issuing a read or write the CPU asserts ADR_O, DAT_O, WE_O, and STB_O. If the input STALL_I is not asserted then the CPU assumes the slave has accepted the transfer, and may therefore already on the next cycle issue a new transaction. In case of read, the response back is indicated by ACK_I and DAT_I. In the case of write, I guess the ACK_I signal can be ignored, because the de-asserted STALL_I already indicates that the slave has accepted the request.

All-in-all the CPU would need to support the following signals:

stall_i : Stall input (asynchronous input).
cyc_o   : Cycle output (always asserted).
stb_o   : Strobe output (asserted for one clock cycle).
adr_o   : Address output (16 bit).
we_o    : Write enable output.
dat_o   : Data output (16 bit).
ack_i   : Acknowledge input.
dat_i   : Data input (16 bit).

[MJoergen]

Here is a nice link describing how the wishbone protocol works.