fossi-foundation / wishbone Goto Github PK

The spec. refers to the “Wishbone Public Domain Library for VHDL”, this document and related code that is referenced is hard to find.

Should probably be included here, or as an appendix in a future version of the spec.

I propose the next revision based on Wishbone B4 provide that a Wishbone Pipeline protocol MAY qualify all of certain signals as DDR to reduce pin count and increase transmission rate:

• ADDR - An 8-signal ADDR bus transfers 16 bits of ADDR in one clock cycle (transaction)
• DAT_I, DAT_O - An 8-signal DAT transfers 16 bits in one transaction
• SEL - Half as many signals for the same number of SEL bits
• TGD
• TGA

The following signals are always one full clock cycle (transaction):

• STB
• STALL
• WE
• ACK
• ERR
• RTY
• LOCK

The CYC signal asserts and deasserts on rising edge. TGC is SDR and applies for the entire bus cycle.

Alternately, as Rule 3.45 prohibits asserting more than one of ACK, ERR, and RTY simultaneously, it is possible to reduce those to a single signal at DDR:

• 00 = nothing
• 11 = ACK
• 01 = ERR
• 10 = RTY

Altogether this allows 29 pins plus CLK and RST for a 16-bit ADDR and DAT bus with 8-bit granularity, rather than 54 pins.

Operand size description within the specification is vague. How does it relate with the port size? What is the point of the operand size? Why having both operand size and port size? I doubt anyone can answer these questions solely after reading the specification and not referring back to the history.

All snippets come from the current B3.1 if not specified otherwise.

Page 15

Page 15

Page 16

Page 22

Page 47

Revision B4, page 101:

1. All snippets except the one from the page 22 suggest that: operand size >= port size >= granularity. The one from page 22 suggests that the operand size can be smaller than the port size.
2. Nowhere in the specification one can find what is the point of the operand size? Why having both the operand size and the port size? I can think of an architecture 20 years ago where the operand size was indeed greater than the port size and transferring single operand required more than one transfer. However, do we still have such use cases today? I think it is rather the other way. Today the operand size is rather smaller than the port size, and such case is already handled by the granularity and SEL_O().
3. Operand size definition. "largest single unit of data" defined by who/what? One can always do one transfer more and have "largest single unit of data + 1".

I think the operand size concept should be reworked. It either should be improved to leave no room for guesses or it should be removed.

Personally I would try to remove the concept of the operand from the specification. The operand has nothing to do with the bus itself (except the fact that it is transferred via it). How long is the operand is always determined by the entity capable of doing an operation on the operand. Whether it is longer or shorter than the port size is irrelevant as long as the bus supports multiple transfers or selection. Even if the selection is not supported, the operating entity can always mask.

I created a sphinx extension to make it easy to embed cool diagrams generated with Yosys + netlistsvg into your Sphinx docs. Look at this pretty example below;

I think the spec could probably use such diagrams!

Find out more below;

• https://github.com/SymbiFlow/sphinxcontrib-verilog-diagrams
• https://sphinxcontrib-verilog-diagrams.readthedocs.io/en/latest/

To get the extension to work on readthedocs, you can see my configuration @ https://github.com/SymbiFlow/sphinxcontrib-verilog-diagrams/blob/master/.readthedocs.yml

wishbone-interconnect.org seems to de down. Moreover, fossi-foundation.github.io/wishbone seems to be redirected. Fortunately, the site is available at wishbone-interconnect.rtfd.io.

Etherbone is very cool extension that allows wishbone over Ethernet.

• https://www.ohwr.org/projects/etherbone-core
• https://www.ohwr.org/project/etherbone-core/tree/master/spec

Rule 3.55 says: [...] when the SLAVE interface holds [ACK_I] in the asserted state.

But the slave signal is [ACK_O], not [ACK_I]. This seems to be used correctly in other places (like permission 3.35 just above).

Should we keep the tutorial appendix ? It is not part of the specifications, has a lot of drawings...

I create a single issue for all points to be discussed before release:

• Name of the document. I think wishbone-b3 would be slightly confusing as the name is very similar to the original wbspec_b3 document. May I suggest wishbone-c3 (so cX would be almost the same as bX) ?

• Section 1.4: The first figure referenced is 1.2, and later figure 1.1 is referenced. Nothing wrong but also confusing.

• Italics parts in the original document are in normal font

• Figure 3.1 (Section 3.1.1): missing gap for the clock.

• Section 3.1.3: the first figure is referenced as 'hanshaking' (typo) but the caption mentions 3.2

• Section 3.1.3 typo: what the eMaster

• Section 3.1.3: Observation 3.35 is not correctly indented.

• Section 3.2.1 figure 3.3: clock edge 1 correspond to the original
  clock edge 0. Likewise for figure 3.4

• Section 3.2.2: typo: [ACK_I[ (also present in the original doc).

• Section 3.3.1: Cycles are shifted in figure 3.6

• Section 3.3.2: Cycles are shifted in figure 3.7. CYC_O signal is not at the bottom of Master Signals.

• Section 3.4: Cycles are shifted in figure 3.8. CYC_O signal is not at the bottom of Master Signals.

• Section 3.5.1 typo: the 64-bit value of 0x0123456789ABC. DEF is missing (also present in the original doc).

• Section 3.5.6 typo: RULE 3.1010. Should be 3.110 (also present in the original doc).

• Figure 3.12 Typo in address range for QWORD granularity (should be 63..00); typo in DAT_O range (15..08) instead of (15..00) for WORD granularity.

• Section 4.2 typo: [CTI_()] (also in the original doc) instead of [CTI_I()].

• Section 4.3 typo in table 4.2: CTI_IO instead of CTI_O.

• Section 4.4.1: cycles are shifted on figure 4.4

• Section 4.4.2: cycles are shifted on figure 4.5

• Section 4.4.2: "Clock, edge5" and "setup, edge6" are mis-aligned.

• Section 4.4.3: cycles are shifted on figure 4.6

• Section 4.4.4: cycles are shifted on figure 4.7

• Chapter 5, first paragraph: de-lay.

• Chapter 5: con-straints (obs 5.05)

• Chapter 5: re-quirements (perm 5.05)

• Chapter 5: ac-quire (sugg 5.00)

I am wondering if it makes sense to consider putting a proper license on the document. In many jurisdictions it is impossible to waiver copyrights and the concept of public domain is defined differently.

CC0 seems like a good candidate but the question is what all authors intended and if we want/must track them down for consent. @rherveille what do you think?

Which tool should we use to re-create drawings in reST ? Any recommendation ?

The Wishbone B3 specification doesn't have any copyright, Wishbone B4 has copyright. However, what about the whole Wishbone idea and the design concept? Is it protected by any license or patent? I am wondering how much can one be inspired by Wishbone when designing his own bus.

3.4.0 lists rst_i as a required signal for masters and slaves. In practice, the rst_i signal should not always be needed. Even the example in A.7.2 does not include rst_i

(discovered by Alfred M. Szmidt)