fossi-foundation / wishbone Goto Github PK
View Code? Open in Web Editor NEWSpecification of the Wishbone SoC Interconnect Architecture
License: Other
Specification of the Wishbone SoC Interconnect Architecture
License: Other
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.
operand size >= port size >= granularity
. The one from page 22 suggests that the operand size can be smaller than the port size.SEL_O()
.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.
Etherbone is very cool extension that allows wishbone over Ethernet.
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).
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?
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.
Should we keep the tutorial appendix ? It is not part of the specifications, has a lot of drawings...
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 transactionSEL
- Half as many signals for the same number of SEL bitsTGD
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
= nothing11
= 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.
Which tool should we use to re-create drawings in reST ? Any recommendation ?
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)
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;
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.
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.
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)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.