--- /dev/null
+ Specification for\r
+ MesaBus \r
+ Interconnection Architecture for Computers, Microcontrollers, FPGAs\r
+ Revision: DRAFT 0.01 02.20.2016 by Black Mesa Labs\r
+\r
+###############################################################################\r
+\r
+[ Legal Notices and Disclaimers ]\r
+ Copyright Notice : Notice is hereby given that this document is not \r
+ copyrighted, and has been placed into the public domain. \r
+ It may be freely copied and distributed by any means.\r
+\r
+\r
+[ Disclaimers ]\r
+ The Author has strove to be as accurate and complete as possible in the \r
+ creation of this document, notwithstanding the fact that he does not warrant \r
+ or represent at any time that the contents within are accurate due to the \r
+ rapidly changing nature of information. The Author will not be responsible \r
+ for any losses or damages of any kind incurred by the reader whether directly\r
+ or indirectly arising from the use of the information found in this document.\r
+\r
+ This document is not intended for use as a source of legal, business, \r
+ accounting, financial, or medical advice. All readers are advised to seek \r
+ services of competent professionals in the legal, business, accounting, \r
+ finance, and medical fields. \r
+\r
+ No guarantees of any kind are made. Reader assumes responsibility for use of \r
+ the information contained herein. The Author reserves the right to make \r
+ changes without notice. The Author assumes no responsibility or liability \r
+ whatsoever on the behalf of the reader of this document.\r
+\r
+ In no event shall the Author be liable for any direct, indirect, incidental, \r
+ consequential, exemplary, or special damages (including, but not limited to\r
+ procurement of substitute goods or services; loss of use, data, or profits; \r
+ or business interruption) resulting in any way from the use of this \r
+ specification. By adopting this specification, the user assumes all \r
+ responsibility for its use.\r
+\r
+###############################################################################\r
+\r
+[ Introduction ]\r
+ MesaBus is a scalable chip to chip protocol that expands a single serial\r
+ interface of any microcontroller, computer or FPGA to a full bus with \r
+ up to 250 self enumerating nodes. The purpose of MesaBus is to allow simple \r
+ low cost Internet-of-Thing type microcontrollers and FPGAs with very few pins \r
+ to be able to easily interface to many device peripherals with minimum wires .\r
+ MesaBus is scalable from simple UART connections to high performance SERDES\r
+ chip to chip communications between FPGAs approaching PCI performance.\r
+ MesaBus readily scales from 115 Kbps over bluetooth wireless to \r
+ 1 GByte/sec between high performance FPGAs over a low cost USB cable.\r
+\r
+ - Motivation\r
+ The MesaBus architect was strongly influenced by these factors: \r
+ 1) The MakerCommunity does not have access to low level computer interfaces \r
+ that existed in the 1980s era of RS232 and Parallel Printer Ports. USB \r
+ device drivers are so difficult that USB access to a modern computer is \r
+ essentially an FTDI cable that looks like a legacy RS232 port to software.\r
+ 2) Microcontroller community has no "Bus" standard for interfacing multiple \r
+ peripherals other than SPI and I2C.\r
+ 3) USB and PCIe are fantastic for consumers, but too complicated for use in\r
+ interfacing microcontrollers to custom peripherals.\r
+ 4) IC's that can be purchased and hand soldered on to low cost 2-layer PCBs\r
+ designs are limited in pin count and need a minimal wire bus that isn't I2C.\r
+ 5) Interconnecting FPGAs with each other and peripherals usually involve \r
+ one-off custom interfaces to reach simplicity and performance.\r
+ 6) Byte transfer interfaces such as SPI, I2C and SERDES are reusable across\r
+ many different applications but do not scale and require many pins.\r
+ \r
+[ Performance ]\r
+ MesaBus protocol is a streaming byte protocol bus for transferring packets \r
+ of payload bytes from a single bus MASTER to multiple bus SLAVEs.\r
+ The default protocol MODE_UART is to transfer ASCII hex nibbles "0"-"F" over \r
+ an industry standard N81 UART connection to build up a stream of binary bytes \r
+ internal to each SLAVE chip. Using this ASCII based interface increases\r
+ compatibility with operating systems, scripting languages and wireless \r
+ communication modules that otherwise may have difficulties transferring binary\r
+ data. The MODE_SYNC protocol uses the same byte streams but with a source \r
+ synchronous binary interface such as SPI or I2C. MODE_SERDES protocol uses \r
+ 8b10b SERDES to transfer the same byte streams over a 3+ Gbps SERDES link.\r
+ These three modes allow MesaBus compliant designs to easily trade off between \r
+ compatibility and performance as it readily scales from KBytes/sec between \r
+ wireless Bluetooth microcontrollers to 40 MBytes/Sec between simple FPGAs to\r
+ 1 GBytes/Sec between advanced FPGAs over a low cost USB cable.\r
+ \r
+ Connection Types: \r
+ o 1-Bit LVCMOS MODE_UART : Payload rate is 1/2 physical baud rate. \r
+ o 1-Bit LVCMOS MODE_SYNC : Payload rate is 1x physical bit rate. \r
+ o 1-Bit LVDS MODE_SYNC : Payload rate is 1x physical bit rate. \r
+ o 1-Bit SERDES MODE_SERDES : Payload rate is 8/10 physical bit rate. \r
+\r
+ Examples: Electrical Payload\r
+ o 1-Bit LVCMOS MODE_UART : 921kbps = 460kbps or 50 KBytes/s.\r
+ o 1-Bit LVCMOS MODE_SYNC : 40Mbps = 40Mbps or 5 MBytes/s.\r
+ o 1-Bit LVDS MODE_SYNC : 320Mbps = 320Mbps or 40 MBytes/s.\r
+ o 1-Bit SERDES MODE_SERDES : 10 Gbps = 8Gbps or 1 GBytes/s.\r
+\r
+[ Physical Interface ]\r
+ o Electrical Signal Levels : The physical interface is point to point with \r
+ devices interfacing nominally using 3.3V LVCMOS. High performance devices \r
+ may optionally use differential LVDS in place of single ended LVCMOS for \r
+ faster performance and/or long cable runs.\r
+ o Power : MesaBus MASTERs are able to provide +5V DC power to SLAVE devices.\r
+ Current limit of +5V is design dependent with 500mA a nominal target.\r
+ o Data Direction :\r
+ Wi : Originates from MASTER and propagates down bus chain to furthest \r
+ slave node. Carries either asynchronous UART single bit traffic or\r
+ 1 or 4 bits of synchronous traffic clocked by Woc clock.\r
+ Idles at logic-1.\r
+ Wo : Output copy of Wi to next slave downstream.\r
+ Ro : Originates from SLAVE devices and propagates back up to MASTER.\r
+ Carries either asynchronous UART readback data or interrupt.\r
+ Idles at logic-1.\r
+ Ri : Input version of Ro from downstream slave device.\r
+ o Pullups : Pullups exist on all LVCMOS signals to 3.3V.\r
+\r
+ o Mechanical Connection : Mechanical connections are recommendations only. \r
+ o Standard LVCMOS Form Factor is FTDI TTL-232R-3V3 USB to TTL cable pinout. \r
+ - LVCMOS 1-Bit : 1x6 0.100" Pitch 0.040" vias with the following pinout:\r
+ Pin-1 : Ground ( GND ) Black\r
+ Pin-2 : Wo ( CTS# ) Brown Roc clock for MODE_SYNC\r
+ Pin-3 : +5V Power ( VCC ) Red 900mA Max\r
+ Pin-4 : Wi ( TXD ) Orange\r
+ Pin-5 : Ro ( RXD ) Yellow\r
+ Pin-6 : Ri ( RTS# ) Green Wic clock for MODE_SYNC\r
+\r
+ \r
+ - LVDS : USB 3.1 Type-C Male to Male cables repurposed for LVDS and Power\r
+ GND : Ground\r
+ VCC : +5V @ 3A Max\r
+ StdA_SSTX+- : Wi Diff Pair ( MODE_UART or MODE_SYNC )\r
+ StdA_SSRX+- : Wic Diff Pair \r
+ D+- : Ro Diff Pair ( MODE_UART )\r
+\r
+ - SERDES : USB 3.1 Type-C Male to Male cables repurposed for SERDES and Power\r
+ GND : Ground\r
+ VCC : +5V @ 3A Max\r
+ StdA_SSTX+- : Wi Diff Pair ( 3-10 Gbps 8b10b )\r
+ StdA_SSRX+- : Ro Diff Pair ( 3-10 Gbps 8b10b )\r
+ D+- : Not Used\r
+\r
+ o Powerup and Wo LVCMOS TriState operation:\r
+ Wo is normally an active driven signal that parks at '1'. To prevent \r
+ Wo from potentially powering downstream CMOS devices, it is Tristated \r
+ with weak pullup on powerup and is not actively driven until the bus \r
+ segment is activated.\r
+\r
+[ MODEs ]\r
+ o Modes : MesaBus supports MODE_UART, MODE_SYNC and MODE_SERDES.\r
+ - MODE_UART : Wi and Ri are asynchronously sampled using local \r
+ >20 MHz oscillator on each slave device using UART N81 protocol. \r
+ Maximum baud rate is TBD 10 Mbps.\r
+ Minimum baud rate is TBD 9600 bps.\r
+ - MODE_SYNC : Wi and Ri are synchronously sampled using source \r
+ synchronous Wic and Ric clocks. Clocks are nominally 24 MHz for LVCMOS\r
+ and 320 MHz for LVDS interfaces. Bus sits idle at '1'. Leading 0xF0 header\r
+ provides framing reference for Byte within stream of Bits. Byte within bits\r
+ alignment remains for duration of packet.\r
+ - MODE_SERDES : 8b10b encoded clock and data at 3 to 10 Gbps. Bus is idle\r
+ sending nulls of 0xFF.\r
+ o Detection : The local 40 MHz clock is used to detect the presents of Wic \r
+ and Ric. MODE_UART is automatically used if these clocks are parked. \r
+ Devices capable of MODE_SYNC automatically switch from MODE_UART to \r
+ MODE_SYNC when Wic is detected as toggling.\r
+\r
+[ Signal Description ]\r
+ o Wi : Input signal to SLAVE from upstream MASTER or SLAVE.\r
+ o Wo : Output signal from SLAVE to downstream SLAVE.\r
+ o Ro : Output signal from SLAVE to upstream MASTER or SLAVE.\r
+ o Ri : Input signal to MASTER or SLAVE from downstream SLAVE.\r
+\r
+\r
+[ Topology ]\r
+ -- MODE_UART\r
+ MASTER SLAVE SLAVE\r
+ --------------- ------------------ ----------------- \r
+ | Wo |--->| Wi Wo |--->| Wi Wo |--> NC\r
+ | Ri |<---| Ro Ri |<---| Ro Ri |<-- NC\r
+ --------------- ------------------ ----------------- \r
+\r
+ -- MODE_SYNC \r
+ MASTER SLAVE SLAVE\r
+ --------------- ------------------ ----------------- \r
+ | Wo |--->| Wi Wo |--->| Wi Wo |--> NC\r
+ | Wco|--->| Wci Wco |--->| Wci Wco |--> NC\r
+ | Ri |<---| Ro Ri |<---| Ro Ri |<-- NC\r
+ | Rci|<---| Rco Rci |<---| Rco Rci |<-- NC\r
+ --------------- ------------------ ----------------- \r
+\r
+ -- MODE_SERDES\r
+ MASTER SLAVE SLAVE\r
+ --------------- ------------------ ----------------- \r
+ | Wo |--->| Wi Wo |--->| Wi Wo |--> NC\r
+ | Ri |<---| Ro Ri |<---| Ro Ri |<-- NC\r
+ --------------- ------------------ ----------------- \r
+\r
+[ Protocol ]\r
+ o Idle Bus : Optional for MODE_UART, required for MODE_SYNC if clocking.\r
+ The Packet_Header may optionally be preceded by 1 or more "F"s to\r
+ ensure nibble within byte alignment is maintained while in \r
+ MODE_UART. Packet processing only begins when an "F0" is \r
+ received on a byte wide lane, or a "0" on a nibble wide lane.\r
+ To guarantee packet alignment, the bus master may always send\r
+ a string of 260 0xFFs bytes.\r
+ 0xFF\r
+ o Invalid Characters : In MODE_UART, ASCII characters outside of "a-f","A-F"\r
+ and "0-9" are considered invalid and ignored. Any \r
+ invalid character >= 0x20 will result in the lock on\r
+ Autobaud being turned off. The "\n" LF character is\r
+ an exception to this rule and is used initially for\r
+ autobauding and ignored after baud lock.\r
+ o Bit and Byte Ordering\r
+ Bit ordering for MODE_UART is normal Start Bit, D0 LSB, D1,..D7,Stop Bit.\r
+ Bit ordering for MODE_SYNC is MSB D7 first and LSB D0 last.\r
+ Byte ordering for DWORD transfers is D(31:24) 1st and D(7:0) last.\r
+ Phase alignments for bit, nibble, byte and DWORD boundaries is established\r
+ using the 0xF0 packet header preamble. Bus always sits idle with 0xFFs.\r
+\r
+ o Packet Header \r
+ A packet header consists of a 4-bytes DWORD always beginning with 0xF0.\r
+ D(31:24) : 0xF0 : Header Preamble \r
+ D(23:16) : 0x00-0xFD : Destination Slot for this packet\r
+ 0xFF : Broadcast all slots\r
+ 0xFE : Nobody ( or Master on Ro Readback packets )\r
+ D(15:8) : Sub-Slot and Command\r
+ D(15:12) : Sub-Slot 0x0-0xF within Chip.\r
+ D(11:8) : Sub-Slot Command 0x0-0xF\r
+ D(7:0) : 0-255 : Number of payload bytes included in this packet.\r
+\r
+ o Sub-Slot 0x0 : 32bit Local Bus Transport\r
+ Sub-Slot 0x0 is by default used for transferring 32bit local bus address\r
+ and data cycles. <ADDR> is 32bits specific to each chip. For writes, one \r
+ or more DWORDs of data may be written. For reads, <LENGTH> specifies the \r
+ number of DWORDs to read starting at <ADDR>. For multiple DWORD transfers,\r
+ the <ADDR> is internally auto incremented by +4 for each DWORD.\r
+ Command\r
+ 0x0 : Write Cycle : Payload of <ADDR><DATA>...\r
+ 0x1 : Read Cycle : Payload of <ADDR><Length> \r
+ 0x2 : Write Repeat : Write burst data to single address : <ADDR><DATA>...\r
+ 0x3 : Read Repeat : Read burst data from single address : <ADDR><Length> \r
+\r
+ o Sub-Slot 0xF : Mesa Bus Control\r
+ Sub-Slot 0xF is reserved for low level control of the Mesa Bus pins.\r
+ Command\r
+ 0x0 : Ro pin is assigned to MesaBus Ro function. ( DEFAULT )\r
+ 0x1 : Ro pin is assigned to Wi pin as a loopback.\r
+ 0x2 : Ro pin is assigned to MesaBus Interrupt function.\r
+ 0x3 : Ro pin is assigned to user specific function.\r
+ 0x4 : Wo pin is assigned to MesaBus Wo function. ( DEFAULT )\r
+ 0x5 : Wo pin is assigned to loopback Wi pin.\r
+ 0x6 : Wo pin is assigned to MesaBus Interrupt function.\r
+ 0x7 : Wo pin is assigned to user specific function.\r
+ 0x8 : Ri pin is assigned to MesaBus Ri function. ( DEFAULT )\r
+ 0x9 : Ri pin is assigned to user specific function.\r
+ 0xA : Report device id\r
+ 0xB : Reset device\r
+ 0xC : Reset autobaud circuit\r
+ 0xD : Turn off fast clocks ( Power Save Mode )\r
+ 0xE : Reboot FPGA to Slot 1of2\r
+ 0xF : Reboot FPGA to Slot 2of2\r
+\r
+[ Addressing ]\r
+ Addressing is an 8bit field that is decremented at each node. Closest node\r
+ to Master is 0x00, next in line is 0x01, etc. 0xFF is reserved for broadcast\r
+ to all nodes. \r
+ \r
+\r
+[EOF]\r
projects / BML_sump2 / commitdiff