Programmable Low-latency IO

From Ubicom Developer

Contents 1 Overview and Benefits 2 Introduction 3 Interface Categories 4 High-Level Functionality 5 PLIO state machinePLIO Signals

Overview and Benefits

PLIO, Programmable Low-Latency Input Output, is a new interface introduced in the Ubicom line of processors. The purpose of PLIO is to provide a cost-effective, programmable solution for many different device communication protocols. This allows for the reduction or even elimination of external discrete controllers for bus interfaces. Due to PLIO’s lower frequency clock domain, programmable state machine and flexible IO, you may implement custom bus interfaces at a fraction of the power required to run it solely in software while providing the flexibility to change the behavior of the hardware IO.

Introduction

The world of inter-integrated circuit communication is made up of interfaces and protocols. In order for a processor to talk to a peripheral, be it a chip or device, there must be a commonly understood language for any system-wide functionality. This interface between two devices is accomplished in software drivers, hardware blocks, configurable logic, or a combination of these three. Each has its own inherent advantages and disadvantages which the system architect must weigh for his or her particular application. IO implemented solely in software may allow for a faster time-to-market, lower cost, and greater flexibility at the expense of lower performance. Hardware IO blocks, while providing the greatest performance, require a greater cost with little flexibility. Configurable IO allows for flexibility at reasonable performance but can be costly and power hungry. This is why we have created Programmable Low-Latency IO (PLIO). We have taken a hybrid approach to the chip interfacing problem in an attempt to minimize the disadvantages of the former approaches and at the same time maximizing their benefits.

Interface Categories

The PLIO module attempts to support both transaction type and stream type interfaces. A transaction type interface is an interface where an initiator device starts a bus cycle to a target device by asserting certain control signals, and the cycle completes with de-assertion of the control signals after some amount of data is transferred between the target and the initiator. A stream type interface is an interface where data is sent from one device to another device in a continuous data stream.

In case of transaction type interface, if the PLIO module is the initiator, the processor should perform the following to start a bus cycle:

1. The processor writes the transaction address, and data if it is a write request to the IO port transmit FIFO.
2. The processor writes the transaction command and set a transaction start bit to start the transaction.
3. The processor can either poll or get an interrupt upon completion of the transaction.
4. If it is a read request, the requested data is in the IO port receive FIFO.

In order to facilitate a greater number of interfaces, PLIO incorporates a Local Register Map (LREG) containing thirty-two 8-bit registers, accessible from the external bus. These registers are particularly useful for protocols, such as IDE PIO, where the required access times to configuration or status registers are much less than what the software interface to PLIO can provide.

If the PLIO module is the target device of a transaction type interface, upon detection of a bus cycle, the PLIO module latches the transaction address and data, and asserts, if necessary, a wait signal to the initiator of the transaction (if the interface supports wait state). The data phase of this transaction can proceed in either of two possible ways. The first is if the LREG (Local Register Map) is accessed, which acts as a cache to prevent interrupts to the processor, and the second is if the request must be serviced by the processor:

• Case 1: The address falls within the range defined by the LREG BAR (the base address of the Local Register Block in the PLIO configuration registers). In case of read, the data is fetched from the Local Register Map and made available to continue the transaction. In case of write, the data is written to the LREG map.
• Case 2: The address does not fall within the range defined by the LREG BAR. The processor reads from the IO port receive FIFO for the transaction address and/or data after it is woken up by the interrupt. In case of read, the processor writes the requested data to the IO port transmit FIFO. In case of write, the processor stores the data. It then writes to the PLIO module to continue the transaction.

The PLIO module then finally de-asserts the wait signal and completes the transaction. If the interface protocol does not allow wait state and the request is a read request from the initiator, the processor must complete the above the entire transaction within the time allowed as specified by the protocol if an LREG access has not occurred. For LREG accesses, this latency is minimized since no processor activity is necessary.

For stream type interfaces, a typical operating sequence is the following:

1. The processor writes the stream output data into the IO port transmit FIFO.
2. The PLIO module state machine transmit the data out onto the external interface, while writes the received data into the receive FIFO.
3. The processor pull the data out of the receive FIFO.

An interface can also be categorized as either an asynchronous interface or a synchronous interface. For synchronous interfaces, most of logic in the PLIO module is driven by the interface clock. For asynchronous interfaces, the PLIO module operates at a clock frequency that is fast enough to meet the shortest latency required by the interface.

For most buses, interface signals can be divided into two different groups. One group consists of all of the control signals that are responsible for generating the bus transaction. The other group of signals consists of all the data signals. For asynchronous type interface, the control signal group includes the address and data strobes, read and write signals and other signals that are used to qualify certain interface events. The data signal group contains the address and data bus. The similar grouping can be applied to synchronous bus as well. While the data signal group includes the address and data bus, the interface handshake signals belong to the control signal group.

The input control signals from control signal group are used to drive the programmable state machine inside the PLIO module. The output of the state machine drives the output control signals and the logic block that process the data signal group.

An interface may have some static control or status signals, such as reset or bus detection or configuration signals. They are not used to drive the state machine. Instead, they are connected to a set of register that can either be sample by the processor.

The PLIO is programmed by static configuration parameters and runtime control signals. A static configuration parameter is programmed at module initialization time, and it does not change during operation. It is responsible for data path selection and routing signals to a desired destination. A runtime control signal is generated by the programmable state machine. It is used to control output signals and behaviors of other data processing block.

High-Level Functionality

There are three main components to implementing PLIO: the software driver, the programmable state machine, and the flexible IO, see Figure 2. In order for PLIO to address the highest number of bus protocols, part of the bus interface is controlled in software while the low-latency portions of the protocol are programmed into the state machine. The software driver handles the high latency parts of the bus protocol and the supplying and receiving of data and addresses to the interface, while the programmable state machine manages the control signals and interface timing. The flexible IO of PLIO allows for pin compatibility across the control, address and data signals.

PLIO state machine

PLIO Signals

The PLIO module supports up to 39 IO signals which include up to 10 control signals and up to 32 data signals. One of the control signals can be configured as a clock output, another as a clock input. When a bus interface does not use all available signals, it is possible to use the unallocated pins as GPIO pins via the GPIO MASK register. A combination of PTIF configuration settings and GPIO pin selections provides the maximum PLIO pin configuration flexibility.

 

Table 1 - PLIO Input Signals

Signal Name	Source	Clock Domain	Description
clk_core	system	core clock	core clock from system
clk_500	system	core clock	500MHz IO clock
clk_ext (port_d_in[6])	external io	external	external clock input
fn_reset	io port	core clock	system reset, active high
fn_sel	io port	core clock	system reset, active high
iopcs_plio_rreq	iopcs	core clock	read access request
iopcs_plio_wreq	iopcs	core clock	write access request
iopcs_plio_addr[11:2]	iopcs	core clock	address for read access to the PLIO internal address space
iopcs_plio_be[3:0]	iopcs	core clock	byte enable for the transaction
iopcs_plio_wdata[31:0]	iopcs	core clock	data to be written into the PLIO internal address space
iopcs_plio_tnum[‘MP_TNUM_BITS-1:0]	iopcs	core clock	thread number for the transaction
iopcs_plio_val	iopcs	core clock	transaction valid signal
iopcs_plio sval	iopcs	core clock	speculative transaction valid signal
portd_plio_function_ctl0[31:0]	iopcs	core clock	value for the Function Ctl 0 register
portd_plio_function_ctl1[31:0]	iopcs	core clock	value for the Function Ctl 1 register
portd_plio_function_ctl2[31:0]	iopcs	core clock	value for the Function Ctl 2 register
portd_plio_function_set[12:0]	iopcs	core clock	One cycle pulse from the IOPCS module
tx_fifo_io_data[31:0]	tx fifo	core clock	data from the IO transmit FIFO
tx_fifo_io_not empty	tx fifo	core clock	status signal indicating the IO transmit FIFO is not empty
port_c_in[31:0]	external io	external	external ctl/data inputs
port_d_in[7:0]	external io	external	external ctl/data inputs
port_e_in[7:0]	external io	external	external ctl/data inputs
port_i_in[15:0]	external io	external	external ctl/data inputs

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Table 2 - PLIO Output Signals

Signal Name	Destination	Clock Domain	Description
plio_iopcs_rdata[31:0]	iopcs	core clock	response data for read transactions
plio_iopcs_halt	iopcs	core clock	when asserted, function is not accepting new transactions
plio_iopcs_req_cpl	iopcs	core clock	request completed when asserted
plio_iopcs_cpl_tnum[‘MP TNUM-1:0]	iopcs	core clock	corresponding thread number for the completed transaction
plio_iopcs_rdy	iopcs	core clock	ready for retry
plio_iopcs_rdy_tnum[‘MP TNUM-1:0]	iopcs	core clock	corresponding retry signal for the ready signal
plio_portd_func_stat 0[31:0]	iopcs	core clock	value for the Function Status 0 register
plio_portd_func_stat 1[15:0]	iopcs	core clock	value for the Function Status 1 register
plio_portd_func_stat 2[31:0]	iopcs	core clock	value for the Function Status 2 register
io_tx fifo_read	tx fifo	core clock	read command to IO transmit FIFO
io_rx fifo_data[31:0]	rx fifo	core clock	data to be written to IO receive FIFO
io_rx fifo_write	rx fifo	core clock	write command to IO receive FIFO
port_c_out[31:0]	external io	external	external ctl/data outputs
port_c_oe[31:0]	external io	external	external ctl/data outputs
port_d_out[7:0 ]	external io	external	external ctl/data outputs
port_d_oe[7:0]	external io	external	external ctl/data outputs
port_e_out[7:0]	external io	external	external ctl/data outputs
port_e_oe[7:0]	external io	external	external ctl/data outputs
port_i_out[15:0]	external io	external	external ctl/data outputs
port_i_oe[15:0]	external io	external	external ctl/data outputs