Embedded Peripherals IP User Guide

RSS

UG-01085 | 2020.01.22

Version Information

Updated for:
Intel® Quartus® Prime Design Suite 19.4

1. Introduction

This user guide describes the IP cores provided by Intel^® Quartus^® Prime design software.

The IP cores are optimized for Intel^® FPGA devices and can be easily implemented to reduce design and test time. You can use the IP parameter editor from Platform Designer to add the IP cores to your system, configure the cores, and specify their connectivity.

Before using Platform Designer, review the Intel^® Quartus^® Prime software Release Notes for known issues and limitations. To submit general feedback or technical support, click Feedback on the Intel^® Quartus^® Prime software Help menu and also on all Intel^® FPGA technical documentation.

1.1. Tool Support

Platform Designer is a system-level integration tool which is included as part of the Intel^® Quartus^® Prime software. Platform Designer saves significant time and effort in the FPGA design process by automatically generating interconnect logic to connect intellectual property (IP) functions and subsystems. You can implement a design using the IP cores from the Platform Designer component library.

All the IP cores described in this user guide are supported by both Intel^® Quartus^® Prime Pro Edition and Intel^® Quartus^® Prime Standard Edition except for the following cores which are only supported by Intel^® Quartus^® Prime Standard Edition.

SDRAM Controller Core
Tri-State SDRAM Core
Compact Flash Core
EPCS Serial Flash Controller Core
16207 LCD Controller Core
Scatter-Gather DMA Controller Core
Video Sync Generator and Pixel Converter Cores
Avalon^® -ST Test Pattern Generator and Checker Cores
Avalon^® -MM DDR Memory Half Rate Bridge Core
Modular ADC Core
Modular Dual ADC Core

Note: Intel^® Quartus^® Prime Pro Edition only supports Intel^® Agilex™ , Intel^® Stratix^® 10, Intel^® Arria^® 10, and Intel^® Cyclone^® 10 GX device families.

1.2. Device Support

The following IP cores are only supported in Intel^® Quartus^® Prime Standard Edition:

EPCS Serial Flash Controller Core
SDRAM Controller Core
Tri-State SDRAM Core
Compact Flash Core
16207 LCD Controller Core
Scatter-Gather DMA Controller Core
Video Sync Generator and Pixel Converter Cores
Avalon-ST Test Pattern Generator and Checker Cores
Avalon-MM DDR Memory Half Rate Bridge Core
Modular ADC Core (only for Intel^® MAX^® 10 devices)
Modular Dual ADC Core (only for Intel^® MAX^® 10 devices)

Note: Intel^® Quartus^® Prime Standard Edition supports older FPGA devices: Stratix^® V and below, Arria^® V and below, Cyclone^® V and below. For more information, refer to Intel^® Quartus^® Prime Standard Edition Software and Device Support Release Notes.

Other IP cores described in this user guide support all Intel^® FPGA device families.

Different device families support different I/O standards, which may affect the ability of the core to interface to certain components. For details about supported I/O types, refer to the device handbook for the target device family.

1.3. Document Revision History for Embedded Peripherals IP User Guide

This section covers the revision history of the entire volume. For details regarding changes to a specific chapter refer to their respective chapter revision history.

Document Version	Intel^® Quartus^® Prime Version	Changes
2020.01.22	19.4	Updated the following chapter: UART Core
2019.12.16	19.4	Updated the following chapter: Avalon^® -ST Single-Clock and Dual-Clock FIFO Core SPI Core SDRAM Controller Core Intel FPGA Serial Flash Controller II Core Intel FPGA Generic QUAD SPI Controller II Core Added a new chapter: Intel FPGA MII to RMII Converter Core.
2019.08.16	19.2	Updated the following chapter: Intel FPGA GMII to RGMII Converter Core
2019.07.16	19.1	Updated the following chapters: Avalon^® -ST Serial Peripheral Interface Core Intel FPGA 16550 Compatible UART Core Intel FPGA Avalon FIFO Memory Core
2019.04.01	19.1	Added a new chapter: Intel FPGA HPS EMAC to Multi-rate PHY GMII Adapter Core. Updated the following chapters: SPI Slave/JTAG to Avalon^® Master Bridge Cores Intel FPGA Serial Flash Controller II Core Intel FPGA Generic QUAD SPI Controller Core Intel FPGA Generic QUAD SPI Controller II Core Modular Scatter-Gather DMA Core
2018.09.24	18.1	Added a new chapter: eSPI to LPC Bridge Core. Updated the following chapters: SPI Core eSPI Core UART Core Intel FPGA Avalon^® I²C (Master) Core EPCS/EPCQA Serial Flash Controller Core Intel FPGA Serial Flash Controller Core Intel FPGA Serial Flash Controller II Core Intel FPGA Generic QUAD SPI Controller Core Intel FPGA Generic QUAD SPI Controller II Core Interval Timer Core On-Chip FIFO Memory Core Modular Scatter-Gather DMA Core
2018.05.07	18.0	Added new chapter eSPI Core. Implemented editorial enhancement for all chapters.

Date	Version	Changes
November 2017	2017.11.06	Removed the Supported Devices topic from various cores. Refer to Device Support.
December 2016	2016.12.19	Maintenance release.
October 2016	2016.10.28	New chapters: Altera Avalon^® I²C (Master) Core Updated: 16550 UART Core Altera I²C Slave to Avalon^® -MM Master Bridge Core
June 2016	2016.06.17	New chapters: Avalon^® -MM DDR Memory Half Rate Bridge Core Updated chapters: UART Core SPI Core Altera Interrupt Latency Counter Core Altera I²C Slave to Avalon^® -MM Master Bridge Core
May 2016	2016.05.03	New chapters: Altera I²C Slave to Avalon^® -MM Master Bridge Core Updated chapters: Vectored Interrupt Controller Core
December 2015	2015.12.16	Removed chapters: PCI Lite Core Avalon^® -ST JTAG Interface Core Updated chapters: 16550 UART Core PIO Core Altera Modular Scatter-Gather DMA Core
November 2015	2015.11.06	Removed chapters: Mailbox Core-Replaced with Intel FPGA Avalon Mailbox Core Updated chapters: 16550 UART Core Avalon^® -ST Bytes to Packets and Packets to Bytes Converter Cores Altera Modular Scatter-Gather DMA Core Vectored Interrupt Controller Core Altera GMII to RGMII Adapter Core Altera Avalon^® Mailbox (simple) Core
June 2015	2015.06.12	New chapters: Altera Quad SPI Controller Core Altera Serial Flash Controller Core Altera Avalon^® Mailbox Core Altera GMII to RGMII Adapter Core Updated chapters: 16550 UART Core Performance Counter Core DMA Controller Core PIO Core Interval Timer Core The following chapters have been reinserted: Avalon^® -ST Single-Clock and Dual-Clock FIFO Cores Avalon^® Streaming Channel Multiplexer and Demultiplexer Cores Avalon^® -ST Round Robin Scheduler Core Avalon^® -ST Delay Core Avalon^® -ST Splitter Core Avalon^® Streaming Test Pattern Generator and Checker Cores Avalon^® Streaming Data Pattern Generator and Checker Cores The following chapters have been removed: Common Flash Interface Controller Core Cyclone^® III Remote Update Controller Core (No longer available starting from V14.0)

2. Avalon -ST Multi-Channel Shared Memory FIFO Core

2.1. Core Overview

The Avalon^® Streaming ( Avalon^® -ST) Multi-Channel Shared Memory FIFO core is a FIFO buffer with Avalon^® -ST data interfaces. The core, which supports up to 16 channels, is a contiguous memory space with dedicated segments of memory allocated for each channel. Data is delivered to the output interface in the same order it was received on the input interface for a given channel.

The example below shows an example of how the core is used in a system. In this example, the core is used to buffer data going into and coming from a four-port Triple Speed Ethernet IP Core. A processor, if used, can request data for a particular channel to be delivered to the Triple Speed Ethernet IP Core.

Figure 1. Multi-Channel Shared Memory FIFO in a System—An Example

2.2. Performance and Resource Utilization

This section lists the resource utilization and performance data for various Intel FPGA device families. The estimates are obtained by compiling the core using the Intel^® Quartus^® Prime software.

The table below shows the resource utilization and performance data for a Stratix^® II GX device (EP2SGX130GF1508I4).

Table 1. Memory Utilization and Performance Data for Stratix^® II GX Devices
Channels	ALUTs	Logic Registers	Memory Blocks			f_MAX (MHz)
Channels	ALUTs	Logic Registers	M512	M4K	M-RAM	f_MAX (MHz)
4	559	382	0	0	1	> 125
12	1617	1028	0	0	6	> 125

The table below shows the resource utilization and performance data for a Stratix^® III device (EP3SL340F1760C3). The performance of the IP Core in Stratix^® IV devices is similar to Stratix^® III devices.

Table 2. Memory Utilization and Performance Data for Stratix^® III Devices
Channels	ALUTs	Logic Registers	Memory Blocks			f_MAX (MHz)
Channels	ALUTs	Logic Registers	M9K	M144K	MLAB	f_MAX (MHz)
4	557	345	37	0	0	> 125
12	1741	1028	0	24	0	> 125

The table below shows the resource utilization and performance data for a Cyclone^® III device (EP3C120F780I7).

Table 3. Memory Utilization and Performance Data for Cyclone^® III Devices
Channels	Total Logic Elements	Total Registers	Memory M9K	f_MAX (MHz)
4	711	346	37	> 125
12	2284	1029	412	> 125

2.3. Functional Description

Figure 2. Avalon^® -ST Multi-Channel Shared Memory FIFO Core

2.3.1. Interfaces

This section describes the core's interfaces.

Avalon^® -ST Interfaces

The core includes Avalon^® -ST interfaces for transferring data and almost-full status.

Table 4. Properties of Avalon^® -ST Interfaces
Feature	Property
Feature	Data Interfaces	Status Interfaces
Backpressure	Ready latency = 0.	Not supported.
Data Width	Configurable.	Data width = 2 bits. Symbols per beat = 1.
Channel	Supported, up to 16 channels.	Supported, up to 16 channels.
Error	Configurable.	Not used.
Packet	Supported.	Not supported.

Avalon^® -MM Interfaces

The core can have up to three Avalon^® -MM interfaces:

Avalon^® -MM control interface—Allows master peripherals to set and access almost-full and almost-empty thresholds. The same set of thresholds is used by all channels. See Control Interface Register Map figure for the description of the threshold registers.
Avalon^® -MM fill-level interface—Allows master peripherals to retrieve the fill level of the FIFO buffer for a given channel. The fill level represents the amount of data in the FIFO buffer at any given time. The read latency on this interface is one. See the Fill-level Interface Register Map table for the description of the fill-level registers.
Avalon^® -MM request interface—Allows master peripherals to request data for a given channel. This interface is implemented only when the Use Request parameter is turned on. The request_address signal contains the channel number. Only one word of data is returned for each request.
For more information about Avalon^® interfaces, refer to the Avalon^® Interface Specifications.

2.3.2. Operation

The Avalon^® -ST Multi-Channel Shared FIFO core allocates dedicated memory segments within the core for each channel, and is implemented such that the memory segments occupy a single memory block. The parameter FIFO depth determines the depth of each memory segment.

The core receives data on its in interface ( Avalon^® -ST sink) and stores the data in the allocated memory segments. If a packet contains any error (in_error signal is asserted), the core drops the packet.

When the core receives a request on its request interface ( Avalon^® -MM slave), it forwards the requested data to its out interface ( Avalon^® -ST source) only when it has received a full packet on its in interface. If the core has not received a full packet or has no data for the requested channel, it deasserts the valid signal on its out interface to indicate that data is not available for the channel. The output latency is three and only one word of data can be requested at a time.

When the Avalon^® -MM request interface is not in use, the request_write signal is kept asserted and the request_address signal is set to 0. Hence, if you configure the core to support more than one channel, you must also ensure that the Use request parameter is turned on. Otherwise, only channel 0 is accessible.

You can configure almost-full thresholds to manage FIFO overflow. The current threshold status for each channel is available from the core's Avalon^® -ST status interfaces in a round-robin fashion. For example, if the threshold status for channel 0 is available on the interface in clock cycle n, the threshold status for channel 1 is available in clock cycle n+1 and so forth.

2.4. Parameters

Table 5. Configurable Parameters
Parameter	Legal Values	Description
Number of channels	1, 2, 4, 8, and 16	The total number of channels supported on the Avalon^® -ST data interfaces.
Symbols per beat	1–32	The number of symbols transferred in a beat on the Avalon^® -ST data interfaces
Bits per symbol	1–32	The symbol width in bits on the Avalon^® -ST data interfaces.
Error width	0–32	The width of the `error` signal on the Avalon^® -ST data interfaces.
FIFO depth	2–2³²	The depth of each memory segment allocated for a channel. The value must be a multiple of 2.
Use packets	0 or 1	Setting this parameter to 1 enables packet support on the Avalon^® -ST data interfaces.
Use fill level	0 or 1	Setting this parameter to 1 enables the Avalon^® -MM status interface.
Number of almost-full thresholds	0 to 2	The number of almost-full thresholds to enable. Setting this parameter to 1 enables Use almost-full threshold 1. Setting it to 2 enables both Use almost-full threshold 1 and Use almost-full threshold 2.
Number of almost-empty thresholds	0 to 2	The number of almost-empty thresholds to enable. Setting this parameter to 1 enables Use almost-empty threshold 1. Setting it to 2 enables both Use almost-empty threshold 1 and Use almost-empty threshold 2.
Section available threshold	0 to 2 ^{Address Width}	Specify the amount of data to be delivered to the output interface. This parameter applies only when packet support is disabled.
Packet buffer mode	0 or 1	Setting this parameter to 1 causes the core to deliver only full packets to the output interface. This parameter applies only when Use packets is set to 1.
Drop on error	0 or 1	Setting this parameter to 1 causes the core to drop packets at the Avalon^® -ST data sink interface if the `error` signal on that interface is asserted. Otherwise, the core accepts the packet and sends it out on the Avalon^® -ST data source interface with the same error. This parameter applies only when packet buffer mode is enabled.
Address width	1–32	The width of the FIFO address. This parameter is determined by the parameter FIFO depth; FIFO depth = 2 ^{Address Width}.
Use request	—	Turn on this parameter to implement the Avalon^® -MM request interface. If the core is configured to support more than one channel and the request interface is disabled, only channel 0 is accessible.
Use almost-full threshold 1	—	Turn on these parameters to implement the optional Avalon^® -ST almost-full and almost-empty interfaces and their corresponding registers. See Control Interface Register Map for the description of the threshold registers.
Use almost-full threshold 2	—
Use almost-empty threshold 1	—
Use almost-empty threshold 2	—
Use almost-full threshold 1	0 or 1	This threshold indicates that the FIFO is almost full. It is enabled when the parameter Number of almost-full threshold is set to 1 or 2.
Use almost-full threshold 2	0 or 1	This threshold is an initial indication that the FIFO is getting full. It is enabled when the parameter Number of almost-full threshold is set to 2.
Use almost-empty threshold 1	0 or 1	This threshold indicates that the FIFO is almost empty. It is enabled when the parameter Number of almost-empty threshold is set to 1 or 2.
Use almost-empty threshold 2	0 or 1	This threshold is an initial indication that the FIFO is getting empty. It is enabled when the parameter Number of almost-empty threshold is set to 2.

2.5. Software Programming Model

The following sections describe the software programming model for the Avalon^® -ST Multi-Channel Shared FIFO core.

2.5.1. HAL System Library Support

The Intel-provided driver implements a HAL device driver that integrates into the HAL system library for Nios^® II systems. HAL users should access the Avalon^® -ST Multi-Channel Shared FIFO core via the familiar HAL API and the ANSI C standard library.

2.5.2. Register Map

You can configure the thresholds and retrieve the fill-level for each channel via the Avalon^® -MM control and fill-level interfaces respectively. Subsequent sections describe the registers accessible via each interface.

Control Register Interface

Table 6. Control Interface Register Map
Byte Offset	Name	Access	Reset Value	Description
0	`ALMOST_FULL_THRESHOLD`	RW	0	Primary almost-full threshold. The bit `Almost_full_data[0]` on the Avalon^® -ST almost-full status interface is set to 1 when the FIFO level is equal to or greater than this threshold.
4	ALMOST_EMPTY_THRESHOLD	RW	0	Primary almost-empty threshold. The bit `Almost_empty_data[0]` on the Avalon^® -ST almost-empty status interface is set to 1 when the FIFO level is equal to or less than this threshold.
8	`ALMOST_FULL2_THRESHOLD`	RW	0	Secondary almost-full threshold. The bit `Almost_full_data[1]` on the Avalon^® -ST almost-full status interface is set to 1 when the FIFO level is equal to or greater than this threshold.
12	ALMOST_EMPTY2_THRESHOLD	RW	0	Secondary almost-empty threshold. The bit `Almost_empty_data[1]` on the Avalon^® -ST almost-empty status interface is set to 1 when the FIFO level is equal to or less than this threshold.
Base + 8	`Almost_Empty_Threshold`	RW		The value of the primary almost-empty threshold. The bit `Almost_empty_data`[0] on the Avalon^® -ST almost-empty status interface is set to 1 when the FIFO level is greater than or equal to this threshold.
Base + 12	`Almost_Empty2_Threshold`	RW		The value of the secondary almost-empty threshold. The bit `Almost_empty_data`[1] Avalon^® -ST almost-empty status interface is set to 1 when the FIFO level is greater than or equal to this threshold.

Fill-Level Register Interface

The table below shows the register map for the fill-level interface.

Table 7. Fill-level Interface Register Map
Byte Offset	Name	Access	Description
0	fill_level_0	RO	Fill level for each channel. Each register is defined for each channel. For example, if the core is configured to support four channel, four fill-level registers are defined.
4	fill_level_1	RO
8	fill_level_2	RO
(n*4)	fill_level_n	RO

2.6. Avalon -ST Multi-Channel Shared Memory FIFO Core Revision History

Document Version	Intel^® Quartus^® Prime Version	Changes
2018.05.07	18.0	Implemented editorial enhancements.

Date	Version	Changes
December 2010	v10.1.0	Removed the “Device Support”, “Instantiating the Core in SOPC Builder”, and “Referenced Documents” sections.
July 2010	v10.0.0	Added the description of almost-empty thresholds and fill-level registers. Revised the Operation section.
November 2009	v9.1.0	No change from previous release.
March 2009	v9.0.0	No change from previous release.
November 2008	v8.1.0	Changed to 8-1/2 x 11 page size. No change to content.
May 2008	v8.0.0	Initial release.

3. Avalon-ST Single-Clock and Dual-Clock FIFO Cores

3.1. Core Overview

The Avalon^® Streaming ( Avalon^® -ST) Single-Clock and Avalon^® -ST Dual-Clock FIFO cores are FIFO buffers which operate with a common clock and independent clocks for input and output ports respectively. The FIFO cores are configurable, Platform Designer-ready, and integrate easily into any Platform Designer-generated systems.

3.2. Functional Description

The following two figures show block diagrams of the Avalon^® -ST Single-Clock FIFO and Avalon^® -ST Dual-Clock FIFO cores.

Figure 3. Avalon^® -ST Single Clock FIFO Core

Figure 4. Avalon^® -ST Dual Clock FIFO Core

3.2.1. Interfaces

This section describes the interfaces implemented in the FIFO cores.

Avalon^® -ST Data Interface

Each FIFO core has an Avalon^® -ST data sink and source interfaces. The data sink and source interfaces in the dual-clock FIFO core are driven by different clocks.

Table 8. Properties of Avalon^® -ST Interfaces
Feature	Property
Backpressure	Ready latency = 0.
Data Width	Configurable.
Channel	Supported, up to 255 channels.
Error	Configurable.
Packet	Configurable.

Avalon^® -MM Control and Status Register Interface

You can configure the single-clock FIFO core to include an optional Avalon^® -MM interface, and the dual-clock FIFO core to include an Avalon^® -MM interface in each clock domain. The Avalon^® -MM interface provides access to 32-bit registers, which allows you to retrieve the FIFO buffer fill level and configure the almost-empty and almost-full thresholds. In the single-clock FIFO core, you can also configure the packet and error handling modes.

Avalon^® -ST Status Interface

The single-clock FIFO core has two optional Avalon^® -ST status source interfaces from which you can obtain the FIFO buffer almost-full and almost empty statuses.

3.2.2. Operating Modes

The following lists the FIFO operating modes:

Default mode—The core accepts incoming data on the in interface (Avalon-ST data sink) and forwards it to the out interface (Avalon-ST data source). The core asserts the valid signal on the Avalon-ST source interface to indicate that data is available at the interface.
Store and forward mode—This mode only applies to the single-clock FIFO core. The core asserts the valid signal on the out interface only when a full packet of data is available at the interface.
In this mode, you can also enable the drop-on-error feature by setting the drop_on_error register to 1. When this feature is enabled, the core drops all packets received with the in_error signal asserted.
Cut-through mode— This mode only applies to the single-clock FIFO core. The core asserts the valid signal on the out interface to indicate that data is available for consumption when the number of entries specified in the cut_through_threshold register are available in the FIFO buffer.
To use the store and forward or cut-through mode, turn on the Use store and forward parameter to include the csr interface (Avalon-MM slave). Set the cut_through_threshold register to 0 to enable the store and forward mode; set the register to any value greater than 0 to enable the cut-through mode. The non-zero value specifies the minimum number of FIFO entries that must be available before the data is ready for consumption. Setting the register to 1 provides you with the default mode.

3.2.3. Fill Level

You can obtain the fill level of the FIFO buffer via the optional Avalon-MM control and status interface. Turn on the Use fill level parameter (Use sink fill level and Use source fill level in the dual-clock FIFO core) and read the fill_level register.

The dual-clock FIFO core has two fill levels, one in each clock domain. Due to the latency of the clock crossing logic, the fill levels reported in the input and output clock domains may be different at any given instance. In both cases, the fill level is pessimistic for the clock domain; the fill level is reported high in the input clock domain and low in the output clock domain.

The dual-clock FIFO has an output pipeline stage to improve f_MAX. This output stage is accounted for when calculating the output fill level, but not when calculating the input fill level. Hence, the best measure of the amount of data in the FIFO is given by the fill level in the output clock domain, while the fill level in the input clock domain represents the amount of space available in the FIFO (Available space = FIFO depth – input fill level).

3.2.4. Thresholds

You can use almost-full and almost-empty thresholds as a mechanism to prevent FIFO overflow and underflow. This feature is only available in the single-clock FIFO core.

To use the thresholds, turn on the Use fill level, Use almost-full status, and Use almost-empty status parameters. You can access the almost_full_threshold and almost_full_threshold registers via the csr interface and set the registers to an optimal value for your application.

You can obtain the almost-full and almost-empty statuses from almost_full and almost_empty interfaces (Avalon-ST status source). The core asserts the almost_full signal when the fill level is equal to or higher than the almost-full threshold. Likewise, the core asserts the almost_empty signal when the fill level is equal to or lower than the almost-empty threshold.

3.3. Parameters

Table 9. Configurable Parameters
Parameter	Legal Values	Description
Bits per symbol	1–32	These parameters determine the width of the FIFO. FIFO width = Bits per symbol * Symbols per beat, where: Bits per symbol is the number of bits in a symbol, and Symbols per beat is the number of symbols transferred in a beat.
Symbols per beat	1–32
Error width	0–32	The width of the `error` signal.
FIFO depth	1–32	The FIFO depth. An output pipeline stage is added to the FIFO to increase performance, which increases the FIFO depth by one.
Use packets	—	Turn on this parameter to enable packet support on the Avalon^® -ST data interfaces.
Channel width	1–32	The width of the `channel` signal.
Avalon^® -ST Single Clock FIFO Only
Use fill level	—	Turn on this parameter to include the Avalon^® -MM control and status register interface.
Avalon^® -ST Dual Clock FIFO Only
Use sink fill level	—	Turn on this parameter to include the Avalon^® -MM control and status register interface in the input clock domain.
Use source fill level	—	Turn on this parameter to include the Avalon^® -MM control and status register interface in the output clock domain.
Write pointer synchronizer length	2–8	The length of the write pointer synchronizer chain. Setting this parameter to a higher value leads to better metastability while increasing the latency of the core.
Read pointer synchronizer length	2–8	The length of the read pointer synchronizer chain. Setting this parameter to a higher value leads to better metastability.
Use Max Channel	—	Turn on this parameter to specify the maximum channel number.
Max Channel	1–255	Maximum channel number.

For more information on metastability in Intel FPGA devices, refer to AN 42: Metastability in Intel FPGA devices.

For more information on metastability analysis and synchronization register chains, refer to the Area and Timing Optimization chapter in volume 2 of the Intel^® Quartus^® Prime Handbook.

3.4. Register Description

The csr interface in the Avalon^® -ST Single Clock FIFO core provides access to registers. The table below describes the registers.

Table 10. Register Description for Avalon^® -ST Single-Clock FIFO
32-Bit Word Offset	Name	Access	Reset	Description
0	`fill_level`	R	0	24-bit FIFO fill level. Bits 24 to 31 are unused.
1	Reserved	—	—	Reserved for future use.
2	almost_full_threshold	RW	FIFO depth–1	Set this register to a value that indicates the FIFO buffer is getting full.
3	almost_empty_threshold	RW	0	Set this register to a value that indicates the FIFO buffer is getting empty.
4	cut_through_threshold	RW	0	0—Enables store and forward mode. >0—Enables cut-through mode and specifies the minimum of entries in the FIFO buffer before the `valid` signal on the Avalon^® -ST source interface is asserted. Once the FIFO core starts sending the data to the downstream component, it continues to do so until the end of the packet. This register applies only when the Use store and forward parameter is turned on.
5	drop_on_error	RW	0	0—Disables drop-on error. 1—Enables drop-on error. This register applies only when the Use packet and Use store and forward parameters are turned on.

The in_csr and out_csr interfaces in the Avalon^® -ST Dual Clock FIFO core reports the FIFO fill level. The table below describes the fill level.

Table 11. Register Description for Avalon^® -ST Dual-Clock FIFO
32-Bit Word Offset	Name	Access	Reset Value	Description
0	`fill_level`	R	0	24-bit FIFO fill level. Bits 24 to 31 are unused.

3.5. Document Revision History

Document Version	Intel^® Quartus^® Prime Version	Changes
2019.12.16	19.4	Corrected the Register Description for Avalon^® -ST Dual-Clock FIFO.
2018.05.07	18.0	Implemented editorial enhancements.

Date	Version	Changes
December 2010	v10.1.0	Removed the “Device Support”, “Instantiating the Core in SOPC Builder”, and “Referenced Documents” sections.
July 2010	v10.0.0	Added description of the new features of the single-clock FIFO: store and forward mode, cut-through mode, and drop on error. Added parameters and registers.
November 2009	v9.1.0	No change from previous release.
March 2009	v9.0.0	Added description of new parameters, Write pointer synchronizer length and Read pointer synchronizer length.
November 2008	v8.1.0	Changed to 8-1/2 x 11 page size. No change to content.
May 2008	v8.0.0	Initial release.

4. Avalon -ST Serial Peripheral Interface Core

4.1. Core Overview

The Avalon^® Streaming ( Avalon^® -ST) Serial Peripheral Interface (SPI) core is an SPI slave that allows data transfers between Platform Designer systems and off-chip SPI devices via Avalon^® -ST interfaces. Data is serially transferred on the SPI, and sent to and received from the Avalon^® -ST interface in bytes.

The SPI Slave to Avalon^® Master Bridge is an example of how this core is used.

For more information on the bridge, refer to SPI Slave/JTAG to Avalon Master Bridge Cores.

4.2. Functional Description

Figure 5. System with an Avalon^® -ST SPI Core

4.2.1. Interfaces

The serial peripheral interface is full-duplex and does not support backpressure. It supports SPI clock phase bit, CPHA = 1, and SPI clock polarity bit, CPOL = 0.

Table 12. Properties of Avalon^® -ST Interfaces
Feature	Property
Backpressure	Not supported.
Data Width	Data width = 8 bits; Bits per symbol = 8.
Channel	Not supported.
Error	Not used.
Packet	Not supported.

For more information about Avalon^® -ST interfaces, refer to the Avalon^® Interface Specifications.

4.2.2. Operation

The Avalon^® -ST SPI core waits for the nSS signal to be asserted low, signifying that the SPI master is initiating a transaction. The core then starts shifting in bits from the input signal mosi. The core packs the bits received on the SPI to bytes and checks for the following special characters:

0x4a—Idle character. The core drops the idle character.
0x4d—Escape character. The core drops the escape character, and XORs the following byte with 0x20.
For each valid byte of data received, the core asserts the valid signal on its Avalon^® -ST source interface and presents the byte on the interface for a clock cycle.

At the same time, the core shifts data out from the Avalon^® -ST sink to the output signal miso beginning with from the most significant bit. If there is no data to shift out, the core shifts out idle characters (0x4a). If the data is a special character, the core inserts an escape character (0x4d) and XORs the data with 0x20.

The data shifts into and out of the core in the direction of MSB first.

Figure 6. SPI Transfer Protocol

Table 13. SPI Transfer Protocol Specification
Symbol	Description	Minimum	Maximum	Unit
TL	The worst recovery time of `sclk` with respect with `nSS`.	½ SPI clock	-	Clock cycle
TT	The worst hold time for `MOSI` and `MISO` data.	½ SPI clock	-
TI	The minimum width of a reset pulse required by Intel FPGA families.	1 SPI clock	-

4.2.3. Timing

The core requires a lead time (TL) between asserting the nSS signal and the SPI clock, and a lag time (TT) between the last edge of the SPI clock and deasserting the nSS signal. The nSS signal must be deasserted for a minimum idling time (TI) of one SPI clock between byte transfers. A Timing Analyzer SDC file (.sdc) is provided to remove false timing paths. The frequency of the SPI master’s clock must be equal to or lower than the frequency of the core’s clock.

4.2.4. Limitations

Daisy-chain configuration, where the output line miso of an instance of the core is connected to the input line mosi of another instance, is not supported.

4.3. Configuration

The parameter Number of synchronizer stages: Depth allows you to specify the length of synchronization register chains. These register chains are used when a metastable event is likely to occur and the length specified determines the meantime before failure. The register chain length, however, affects the latency of the core.

For more information on metastability in Intel FPGA devices, refer to AN 42: Metastability in Intel FPGA devices.

For more information on metastability analysis and synchronization register chains, refer to the Area and Timing Optimization chapter in volume 2 of the Intel^® Quartus^® Prime Handbook.

4.4. Avalon -ST Serial Peripheral Interface Core Revision History

Document Version	Intel^® Quartus^® Prime Version	Changes
2019.07.16	19.1	Add the SPI Transfer Protocol Specification in Operation section.
2018.05.07	18.0	Implemented editorial enhancements.

Date	Version	Changes
July 2014	2014.07.24	Removed mention of SOPC Builder, updated to Platform Designer
December 2010	v10.1.0	Removed the “Device Support”, “Instantiating the Core in SOPC Builder”, and “Referenced Documents” sections.
July 2010	v10.0.0	No change from previous release.
November 2009	v9.1.0	Added a description to specify the shift direction.
March 2009	v9.0.0	Added description of a new parameter, Number of synchronizer stages: Depth.
November 2008	v8.1.0	Changed to 8-1/2 x 11 page size. No change to content.
May 2008	v8.0.0	Initial release.

5. SPI Core

5.1. Core Overview

SPI is an industry-standard serial protocol commonly used in embedded systems to connect microprocessors to a variety of off-chip sensor, conversion, memory, and control devices. The SPI core with Avalon^® interface implements the SPI protocol and provides an Avalon^® Memory-Mapped ( Avalon^® -MM) interface on the back end.

The SPI core can implement either the master or slave protocol. When configured as a master, the core can control up to 32 independent SPI slaves. The width of the receive and transmit registers are configurable between 1 and 32 bits. Longer transfer lengths can be supported with software routines. The core provides an interrupt output that can flag an interrupt whenever a transfer completes.

5.2. Functional Description

The SPI core communicates using two data lines, a control line, and a synchronization clock:

Master Out Slave In (mosi)—Output data from the master to the inputs of the slaves
Master In Slave Out (miso)—Output data from a slave to the input of the master
Serial Clock (sclk)—Clock driven by the master to slaves, used to synchronize the data bits
Slave Select (ss_n)— Select signal (active low) driven by the master to individual slaves, used to select the target slave
The SPI core has the following user-visible features:
A memory-mapped register space comprised of five registers: rxdata, txdata, status, control, and slaveselect
Four SPI interface ports: sclk, ss_n, mosi, and miso
The registers provide an interface to the SPI core and are visible via the Avalon^® -MM slave port. The sclk, ss_n, mosi, and miso ports provide the hardware interface to other SPI devices. The behavior of sclk, ss_n, mosi, and miso depends on whether the SPI core is configured as a master or slave.

Figure 7. SPI Core Block Diagram (Master Mode)

The SPI core logic is synchronous to the clock input provided by the Avalon^® -MM interface. When configured as a master, the core divides the Avalon^® -MM clock to generate the SCLK output. When configured as a slave, the core's receive logic is synchronized to SCLK input.

For more details, refer to the "Interval Timer Core" chapter.

5.2.1. Example Configurations

The core block diagram and the SPI core configured as a slave diagram show two possible configurations. In Figure 8 the core provides a slave interface to an off-chip SPI master.

Figure 8. SPI Core Configured as a Slave

In the SPI core block diagram, the SPI core provides a master interface driving multiple off-chip slave devices. Each slave device in Figure 8 must tristate its miso output whenever its select signal is not asserted.

The ss_n signal is active-low. However, any signal can be inverted inside the FPGA, allowing the slave-select signals to be either active high or active low.

5.2.2. Transmitter Logic

The core transmitter logic consists of a transmit holding register (txdata) and transmit shift register, each n bits wide. The register width n is specified at system generation time, and can be any integer value from 8 to 32. After a master peripheral writes a value to the txdata register, the value is copied to the shift register and then transmitted when the next operation starts.

The shift register and the txdata register provide double buffering during data transmission. A new value can be written into the txdata register while the previous data is being shifted out of the shift register. The transmitter logic automatically transfers the txdata register to the shift register whenever a serial shift operation is not currently in process.

In master mode, the transmit shift register directly feeds the mosi output. In slave mode, the transmit shift register directly feeds the miso output. Data shifts out LSB first or MSB first, depending on the configuration of the SPI core.

5.2.3. Receiver Logic

The core receive logic consists of a receive holding register (rxdata) and receive shift register, each n bits wide. The register width n is specified at system generation time, and can be any integer value from 8 to 32. A master peripheral reads received data from the rxdata register after the shift register has captured a full n-bit value of data.

The shift register and the rxdata register provide double buffering while receiving data. The rxdata register can hold a previously received data value while subsequent new data is shifting into the shift register. The receiver logic automatically transfers the shift register content to the rxdata register when a serial shift operation completes.

In master mode, the shift register is fed directly by the miso input. In slave mode, the shift register is fed directly by the mosi input. The receiver logic expects input data to arrive LSB first or MSB first, depending on the configuration of the SPI core.

5.2.4. Master and Slave Modes

At system generation time, the designer configures the SPI core in either master mode or slave mode. The mode cannot be switched at runtime.

5.2.4.1. Master Mode Operation

In master mode, the SPI ports behave as shown in the table below.

Table 14. Master Mode Port Configurations
Name	Direction	Description
`mosi`	output	Data output to slave(s)
`miso`	input	Data input from slave(s)
`sclk`	output	Synchronization clock to all slaves
`ss_n`M	output	Slave select signal to slave M, where M is a number between 0 and 31.

In master mode, an intelligent host (for example, a microprocessor) configures the SPI core using the control and slaveselect registers, and then writes data to the txdata buffer to initiate a transaction. A master peripheral can monitor the status of the transaction by reading the status register. A master peripheral can enable interrupts to notify the host whenever new data is received (for example, a transfer has completed), or whenever the transmit buffer is ready for new data.

The SPI protocol is full duplex, so for every transaction both sends and receives data at the same time. The master transmits a new data bit on the mosi output and the slave drives a new data bit on the miso input for each active edge of sclk. The SPI core divides the Avalon^® -MM system clock using a clock divider to generate the sclk signal.

When the SPI core is configured to interface with multiple slaves, the core has one ss_n signal for each slave. During a transfer, the master asserts ss_n to each slave specified in the slaveselect register. Note that there can be no more than one slave transmitting data during any particular transfer, or else there will be a contention on the miso input. The number of slave devices is specified at system generation time.

5.2.4.2. Slave Mode Operation

In slave mode, the SPI ports behave as shown in the table below.

Table 15. Slave Mode Port Configurations
Name	Direction	Description
`mosi`	input	Data input from the master
`miso`	output	Data output to the master
`sclk`	input	Synchronization clock
`ss_n`	input	Select signal

In slave mode, the SPI core simply waits for the master to initiate transactions. Before a transaction begins, the slave logic continuously polls the ss_n input. When the master asserts ss_n, the slave logic immediately begins sending the transmit shift register contents to the miso output. The slave logic also captures data on the mosi input, and fills the receive shift register simultaneously. After a word is received by the slave, the master must de-assert the ss_n signal and reasserts the signal again when the next word is ready to be sent.

An intelligent host such as a microprocessor writes data to the txdata registers, so that it is transmitted the next time the master initiates an operation. A master peripheral reads received data from the rxdata register. A master peripheral can enable interrupts to notify the host whenever new data is received, or whenever the transmit buffer is ready for new data.

5.2.4.3. Multi-Slave Environments

When ss_n is not asserted, typical SPI cores set their miso output pins to high impedance. The provided SPI slave core drives an undefined high or low value on its miso output when not selected. Special consideration is necessary to avoid signal contention on the miso output, if the SPI core in slave mode is connected to an off-chip SPI master device with multiple slaves. In this case, the ss_n input should be used to control a tristate buffer on the miso signal.

Figure 9. SPI Core in a Multi-Slave Environment

5.3. Configuration

The following sections describe the available configuration options.

5.3.1. Master/Slave Settings

The designer can select either master mode or slave mode to determine the role of the SPI core. When master mode is selected, the following options are available: Number of select (SS_n) signals , SPI clock rate, and Specify delay.

5.3.1.1. Number of Select (SS_n) Signals

This setting specifies the number of slaves the SPI master connects to. The range is 1 to 32. The SPI master core presents a unique ss_n signal for each slave.

5.3.1.2. SPI Clock (sclk) Rate

This setting determines the rate of the sclk signal that synchronizes data between master and slaves. The target clock rate can be specified in units of Hz, kHz or MHz. The SPI master core uses the Avalon^® -MM system clock and a clock divisor to generate sclk.

The actual frequency of sclk may not exactly match the desired target clock rate. The achievable clock values are:

< Avalon^® -MM system clock frequency> / [2, 4, 6, 8, ...]

The actual frequency achieved will not be greater than the specified target value.

When the SPI core is turned on with a synchronizer, the IP clock frequency must be at least six times the SPI clock frequency.

5.3.1.3. Specify Delay

Turning on this option causes the SPI master to add a time delay between asserting the ss_n signal and shifting the first bit of data. This delay is required by certain SPI slave devices. If the delay option is on, you must also specify the delay time in units of ns, µs or ms. An example is shown in below.

Figure 10. Time Delay Between Asserting ss_n and Toggling sclk

The delay generation logic uses a granularity of half the period of sclk. The actual delay achieved is the desired target delay rounded up to the nearest multiple of half the sclk period, as shown in the follow two equations.

Table 16.
p = 1/2 x (period of `sclk`)

Table 17.
Actual delay = ceiling x (desired delay/ p)

5.3.2. Data Register Settings

The data register settings affect the size and behavior of the data registers in the SPI core. There are two data register settings:

Width—This setting specifies the width of rxdata, txdata, and the receive and transmit shift registers. The range is from 1 to 32.
Shift direction—This setting determines the direction that data shifts (MSB first or LSB first) into and out of the shift registers.

5.3.3. Timing Settings

The timing settings affect the timing relationship between the ss_n, sclk, mosi and miso signals. In this discussion the mosi and miso signals are referred to generically as data. There are two timing settings:

Clock polarity—This setting can be 0 or 1. When clock polarity is set to 0, the idle state for sclk is low. When clock polarity is set to 1, the idle state for sclk is high.
Clock phase—This setting can be 0 or 1. When clock phase is 0, data is latched on the leading edge of sclk, and data changes on trailing edge. When clock phase is 1, data is latched on the trailing edge of sclk, and data changes on the leading edge.
The following four clock polarity figures demonstrate the behavior of signals in all possible cases of clock polarity and clock phase.

Figure 11. Clock Polarity = 0, Clock Phase = 0

Figure 12. Clock Polarity = 0, Clock Phase = 1

Figure 13. Clock Polarity = 1, Clock Phase = 0

Figure 14. Clock Polarity = 1, Clock Phase = 1

5.3.4. Synchronizer Stages

This setting enables a synchronizer on the SPI interface input. When slave mode is used, you must turn on the synchronizer.

5.4. Software Programming Model

The following sections describe the software programming model for the SPI core, including the register map and software constructs used to access the hardware. For Nios^® II processor users, Intel provides the HAL system library header file that defines the SPI core registers. The SPI core does not match the generic device model categories supported by the HAL, so it cannot be accessed via the HAL API or the ANSI C standard library. Intel provides a routine to access the SPI hardware that is specific to the SPI core.

5.4.1. Hardware Access Routines

Intel provides one access routine, alt_avalon_spi_command(), that provides general-purpose access to the SPI core that is configured as a master.

5.4.1.1. alt_avalon_spi_command()

Prototype:	`int alt_avalon_spi_command(alt_u32 base, alt_u32 slave,` `alt_u32 write_length, const alt_u8* wdata,` `alt_u32 read_length,` `alt_u8* read_data,` `alt_u32 flags)`
Thread-safe:	No.
Available from ISR:	No.
Include:	<altera_avalon_spi.h>
Description:	This function performs a control sequence on the SPI bus. It supports only SPI masters with data width less than or equal to 8 bits. A single call to this function writes a data buffer of arbitrary length to the `mosi` port, and then reads back an arbitrary amount of data from the `miso` port. The function performs the following actions: (1) Asserts the slave select output for the specified slave. The first slave select output is 0. (2) Transmits write_length bytes of data from wdata through the SPI interface, discarding the incoming data on the `miso` port. (3) Reads read_length bytes of data and stores the data into the buffer pointed to by read_data. The `mosi` port is set to zero during the read transaction. (4) De-asserts the slave select output, unless the flags field contains the value ALT_AVALON_SPI_COMMAND_MERGE. If you want to transmit from scattered buffers, call the function multiple times and specify the merge flag on all the accesses except the last. To access the SPI bus from more than one thread, you must use a semaphore or mutex to ensure that only one thread is executing within this function at any time.
Returns:	The number of bytes stored in the read_data buffer.

5.4.2. Software Files

The core is accompanied by the following software files. These files provide a low-level interface to the hardware.

altera_avalon_spi.h—This file defines the core's register map, providing symbolic constants to access the low-level hardware.
altera_avalon_spi.c—This file implements low-level routines to access the hardware.

5.4.3. Register Map

An Avalon^® -MM master peripheral controls and communicates with the core via the six 32-bit registers, shown in below in the Register Map for SPI Master Device figure. The table assumes an n-bit data width for rxdata and txdata.

Table 18. Register Map for SPI Master Device
Internal Address	Register Name	Type [R/W]	32-11	10	9	8	7	6	5	4	3
0	`rxdata` ³	R	`RXDATA` (n-1..0)
1	`txdata` ³	W	`TXDATA` (n-1..0)
2	`status` ¹	R/W			`EOP`	`E`	`RRDY`	`TRDY`	`TMT`	`TOE`	`ROE`
3	`control`	R/W		`SSO` ²	`IEOP`	`IE`	`IRRDY`	`ITRDY`		`ITOE`	`IROE`
4	Reserved	—
5	`slaveselect` ²	R/W	Slave Select Mask
6	`eop_value` ³	R/W	End of Packet Value (n-1..0)

Reading undefined bits returns an undefined value. Writing to undefined bits has no effect.

¹ A write operation to the status register clears the ROE, TOE, and E bits.

² Present only in master mode.

³ Bits 31 to n are undefined when n is less than 32.

5.4.3.1. rxdata Register

A master peripheral reads received data from the rxdata register. When the receive shift register receives a full n bits of data, the status register's RRDY bit is set to 1 and the data is transferred into the rxdata register. Reading the rxdata register clears the RRDY bit. Writing to the rxdata register has no effect.

New data is always transferred into the rxdata register, whether or not the previous data was retrieved. If RRDY is 1 when data is transferred into the rxdata register (that is, the previous data was not retrieved), a receive-overrun error occurs and the status register's ROE bit is set to 1. In this case, the contents of rxdata are undefined.

5.4.3.2. txdata Register

A master peripheral writes data to be transmitted into the txdata register. When the status register's TRDY bit is 1, it indicates that the txdata register is ready for new data. The TRDY bit is set to 0 whenever the txdata register is written. The TRDY bit is set to 1 after data is transferred from the txdata register into the transmitter shift register, which readies the txdata holding register to receive new data.

A master peripheral should not write to the txdata register until the transmitter is ready for new data. If TRDY is 0 and a master peripheral writes new data to the txdata register, a transmit-overrun error occurs and the status register's TOE bit is set to 1. In this case, the new data is ignored, and the content of txdata remains unchanged.

As an example, assume that the SPI core is idle (that is, the txdata register and transmit shift register are empty), when a CPU writes a data value into the txdata holding register. The TRDY bit is set to 0 momentarily, but after the data in txdata is transferred into the transmitter shift register, TRDY returns to 1. The CPU writes a second data value into the txdata register, and again the TRDY bit is set to 0. This time the shift register is still busy transferring the original data value, so the TRDY bit remains at 0 until the shift operation completes. When the operation completes, the second data value is transferred into the transmitter shift register and the TRDY bit is again set to 1.

5.4.3.3. status Register

The status register consists of bits that indicate status conditions in the SPI core. Each bit is associated with a corresponding interrupt-enable bit in the control register, as discussed in the Control Register section. A master peripheral can read status at any time without changing the value of any bits. Writing status does clear the ROE, TOE and E bits.

Table 19. status Register Bits
#	Name	Description
3	`ROE`	Receive-overrun error The `ROE` bit is set to 1 if new data is received while the `rxdata` register is full (that is, while the `RRDY` bit is 1). In this case, the new data overwrites the old. Writing to the `status` register clears the `ROE` bit to 0.
4	`TOE`	Transmitter-overrun error The `TOE` bit is set to 1 if new data is written to the `txdata` register while it is still full (that is, while the `TRDY` bit is 0). In this case, the new data is ignored. Writing to the `status` register clears the `TOE` bit to 0.
5	`TMT`	Transmitter shift-register empty In master mode, the `TMT` bit is set to 0 when a transaction is in progress and set to 1 when the shift register is empty. In slave mode, the `TMT` bit is set to 0 when the slave is selected (`SS_n` is low) or when the SPI Slave register interface is not ready to receive data.
6	`TRDY`	Transmitter ready The `TRDY` bit is set to 1 when the `txdata` register is empty.
7	`RRDY`	Receiver ready The `RRDY` bit is set to 1 when the `rxdata` register is full.
8	`E`	Error The `E` bit is the logical OR of the `TOE` and `ROE` bits. This is a convenience for the programmer to detect error conditions. Writing to the `status` register clears the `E` bit to 0.
9	`EOP`	End of Packet The `EOP` bit is set when the End of Packet condition is detected. The End of Packet condition is detected when either the read data of the `rxdata` register or the write data to the `txdata` register is matching the content of the `eop_value` register.

5.4.3.4. control Register

The control register consists of data bits to control the SPI core's operation. A master peripheral can read control at any time without changing the value of any bits.

Most bits (IROE, ITOE, ITRDY, IRRDY, and IE) in the control register control interrupts for status conditions represented in the status register. For example, bit 1 of status is ROE (receiver-overrun error), and bit 1 of control is IROE, which enables interrupts for the ROE condition. The SPI core asserts an interrupt request when the corresponding bits in status and control are both 1.

Table 20. control Register Bits
#	Name	Description
3	`IROE`	Setting `IROE` to 1 enables interrupts for receive-overrun errors.
4	`ITOE`	Setting `ITOE` to 1 enables interrupts for transmitter-overrun errors.
6	`ITRDY`	Setting `ITRDY` to 1 enables interrupts for the transmitter ready condition.
7	`IRRDY`	Setting `IRRDY` to 1 enables interrupts for the receiver ready condition.
8	`IE`	Setting `IE` to 1 enables interrupts for any error condition.
9	`IEOP`	Setting `IEOP` to 1 enables interrupts for the End of Packet condition.
10	`SSO`	Setting `SSO` to 1 forces the SPI core to drive its `ss_n` outputs, regardless of whether a serial shift operation is in progress or not. The slaveselect register controls which ss_n outputs are asserted. `SSO` can be used to transmit or receive data of arbitrary size, for example, greater than 32 bits.

After reset, all bits of the control register are set to 0. All interrupts are disabled and no ss_n signals are asserted.

5.4.3.5. slaveselect Register

The slaveselect register is a bit mask for the ss_n signals driven by an SPI master. During a serial shift operation, the SPI master selects only the slave device(s) specified in the slaveselect register.

The slaveselect register is only present when the SPI core is configured in master mode. There is one bit in slaveselect for each ss_n output, as specified by the designer at system generation time. The slaveselect register value is only updated either at the beginning of the actual SPI transmission or when the SSO bit is set from 0 to 1.

A master peripheral can set multiple bits of slaveselect simultaneously, causing the SPI master to simultaneously select multiple slave devices as it performs a transaction. For example, to enable communication with slave devices 1, 5, and 6, set bits 1, 5, and 6 of slaveselect. However, consideration is necessary to avoid signal contention between multiple slaves on their miso outputs.

Upon reset, bit 0 is set to 1, and all other bits are cleared to 0. Thus, after a device reset, slave device 0 is automatically selected.

5.4.3.6. end of packet value Register

The end of packet value register allows you to specify the value of the SPI data word. The SPI data word acts as the end of packet word.

5.5. Example Test Code

#include "alt_types.h"
#include "sys/alt_stdio.h"
#include "io.h"
#include "system.h"
#include "sys/alt_cache.h"
#include "altera_avalon_spi.h"
#include "altera_avalon_spi_regs.h"
#include "sys/alt_irq.h"

//This is the ISR that runs when the SPI Slave receives data

static void spi_rx_isr(void* isr_context){

        alt_printf("ISR :) %x \n" ,  IORD_ALTERA_AVALON_SPI_RXDATA(SPI_SLAVE_BASE));

        //This resets the IRQ flag. Otherwise the IRQ will continuously run.
        IOWR_ALTERA_AVALON_SPI_STATUS(SPI_SLAVE_BASE, 0x0);
}

int main()
{
  alt_printf("Hello from Nios II!\n");

  int return_code,ret;
  char spi_command_string_tx[10] = "$HELLOABC*";

  char spi_command_string_rx[10] = "$HELLOABC*";

  //This registers the Slave IRQ with NIOS

  ret = alt_ic_isr_register(SPI_SLAVE_IRQ_INTERRUPT_CONTROLLER_ID,SPI_SLAVE_IRQ,spi_rx_isr,(void *)spi_command_string_tx,0x0);
  alt_printf("IRQ register return %x \n", ret);

  //You need to enable the IRQ in the IP core control register as well.
  IOWR_ALTERA_AVALON_SPI_CONTROL(SPI_SLAVE_BASE,ALTERA_AVALON_SPI_CONTROL_SSO_MSK | ALTERA_AVALON_SPI_CONTROL_IRRDY_MSK);

  //Just calling the ISR to see if the function is OK.
  spi_rx_isr(NULL);

  return_code = alt_avalon_spi_command(SPI_MASTER_BASE,0 ,
                              1, spi_command_string_tx,
                              0, spi_command_string_rx,
                              0);

  return_code = alt_avalon_spi_command(SPI_MASTER_BASE,0 ,
                                1, &spi_command_string_tx[1],
                                0, spi_command_string_rx,
                                0);

  return_code = alt_avalon_spi_command(SPI_MASTER_BASE,0 ,
                                1, &spi_command_string_tx[2],
                                0, spi_command_string_rx,
                                0);

  return_code = alt_avalon_spi_command(SPI_MASTER_BASE,0 ,
                                1, &spi_command_string_tx[3],
                                0, spi_command_string_rx,
                                0);

  if(return_code < 0)
                 alt_printf("ERROR SPI TX RET = %x \n" , return_code);

  alt_printf("Transmit done. RET = %x spi_rx %x\n",return_code,spi_command_string_rx[0]);

  //RX is done via interrupts.
  alt_printf("Rx done \n");
  return 0;

}

5.6. SPI Core Revision History

Document Version	Intel^® Quartus^® Prime Version	Changes
2019.12.16	19.4	Added the following new sections: Synchronizer Stages Example Test Code
2018.05.07	18.0	Implemented editorial enhancements.

Date	Version	Changes
June 2016	2016.06.17	Updates: Removed content regarding Avalon^® -MM flow control Table 18: `eop_value` added Table 19: `EOP` added Table 20: `IEOP` added end of packet value Register: New topic
December 2010	v10.1.0	Removed the “Device Support”, “Instantiating the Core in SOPC Builder”, and “Referenced Documents” sections.
July 2010	v10.0.0	No change from previous release.
November 2009	v9.1.0	Revised register width in transmitter logic and receiver logic. Added description on the disable flow control option. Added R/W column in Table 8–3 .
March 2009	v9.0.0	No change from previous release.
November 2008	v8.1.0	Changed to 8-1/2 x 11 page size. Updated the width of the parameters and signals from 16 to 32.
May 2008	v8.0.0	Updated the description of the `TMT` bit.

6. SPI Slave/JTAG to Avalon Master Bridge Cores

6.1. Core Overview

The SPI Slave to Avalon^® Master Bridge and the JTAG to Avalon^® Master Bridge cores provide a connection between host systems and Platform Designer systems via the respective physical interfaces. Host systems can initiate Avalon^® Memory-Mapped ( Avalon^® -MM) transactions by sending encoded streams of bytes via the cores’ physical interfaces. The cores support reads and writes, but not burst transactions.

This IP core supports the Motorola SPI Protocol, using the SPI clock phase bit, CPHA = 1, and SPI clock polarity bit, CPOL = 0 mode.

6.2. Functional Description

Figure 15. System with a SPI Slave to Avalon^® Master Bridge Core

Figure 16. System with a JTAG to Avalon^® Master Bridge Core

Note: System clock must be at least 2X faster than the JTAG clock.

The SPI Slave to Avalon^® Master Bridge and the JTAG to Avalon^® Master Bridge cores accept encoded streams of bytes with transaction data on their respective physical interfaces and initiate Avalon^® -MM transactions on their Avalon^® -MM interfaces. Each bridge consists of the following cores, which are available as stand-alone components in Platform Designer:

Avalon^® -ST Serial Peripheral Interface and Avalon^® -ST JTAG Interface—Accepts incoming data in bits and packs them into bytes.
Avalon^® -ST Bytes to Packets Converter—Transforms packets into encoded stream of bytes, and a likewise encoded stream of bytes into packets.
Avalon^® -ST Packets to Transactions Converter—Transforms packets with data encoded according to a specific protocol into Avalon^® -MM transactions, and encodes the responses into packets using the same protocol.
Avalon^® -ST Single Clock FIFO—Buffers data from the Avalon^® -ST JTAG Interface core. The FIFO is only used in the JTAG to Avalon^® Master Bridge.
For the bridges to successfully transform the incoming streams of bytes to Avalon^® -MM transactions, the streams of bytes must be constructed according to the protocols used by the cores.

Note: When you connect the JTAG Avalon Master Bridge component to a slave that back-pressures the master interface on this component, then using the System Console master_write_from_file command may result in data loss at the master interface or hung command in System Console.

Figure 17. Bits to Avalon^® -MM Transaction (Write)The following example shows how a bytestream changes as it is transferred through the different layers in the bridges for write transaction.

Figure 18. Write ResponseAfter sending a write transaction packet through MOSI bus, the master has to initiate 8 bytes of IDLE transaction on the MOSI bus in order to get the write response from the MISO bus. The following figure shows the write response transaction that constructed by the bridge in the MISO bus. The most significant bit of the command is inversed.

Figure 19. Bits to Avalon^® -MM Transaction (Read)The following figure shows how a bytestream changes as it is transferred through the different layers in the bridges for a read transaction.

Figure 20. Read ResponseAfter sending a read transaction through MOSI bus, the master has to initiate IDLE transaction on the MOSI bus to get the read response from the MISO bus. There is a possibility that the Avalon slave device is yet to return the read data, therefore the bridge returns 0x4A until read data is received. When read data is received by the bridge, it sends channel byte as the first byte followed by the SOP and data byte. The following figure shows the read response transaction that constructed by the bridge in the MISO bus.

6.3. Parameters

For the SPI Slave to Avalon^® Master Bridge core, the parameter Number of synchronizer stages: Depth allows you to specify the length of synchronization register chains. These register chains are used when a metastable event is likely to occur and the length specified determines the meantime before failure. The register chain length, however, affects the latency of the core.

For more information on metastability in Intel FPGA devices, refer to AN 42: Metastability in Intel FPGA devices.

For more information on metastability analysis and synchronization register chains, refer to the Area and Timing Optimization chapter in volume 2 of the Intel^® Quartus^® Prime Handbook.

6.4. SPI Slave/JTAG to Avalon Master Bridge Cores Revision History

Document Version	Intel^® Quartus^® Prime Version	Changes
2019.04.01	19.1	Updated information about read and write transactions in Functional Description.
2018.05.07	18.0	Corrected the Figure: Bits to Avalon-MM Transaction (Read). Implemented editorial enhancements.

Date	Version	Changes
May 2017	2017.05.08	Read operation added: Figure 19
July 2014	2014.07.24	Removed mention of SOPC Builder, updated to Platform Designer
December 2010	v10.1.0	Removed the “Device Support”, “Instantiating the Core in SOPC Builder”, and “Referenced Documents” sections.
July 2010	v10.0.0	No change from previous release.
November 2009	v9.1.0	No change from previous release.
March 2009	v9.0.0	Added description of a new parameter Number of synchronizer stages: Depth.
November 2008	v8.1.0	Changed to 8-1/2 x 11 page size. No change to content.
May 2008	v8.0.0	Initial release.

7. Intel eSPI Slave Core

The Intel Enhanced SPI (eSPI) slave core allows you to communicate with an eSPI master such as the Platform Controller Hub (PCH) on a mother board using Intel^® MAX^® 10 device.

7.1. Functional Description

Figure 21. Block Diagram

7.1.1. Link Layer

In the Link Layer, the Condition Detector block shifts the serial data bus in (receive) and out (transmit) in eSPI clock domain. The input serial data is translated into parallel form and sent to transaction layer. The parallel data bus from the transaction layer is translated into serial form in the condition detector and sent out as the eSPI output data.

During the single I/O mode, the I/O pins [1:0] are unidirectional to form an unidirectional data bus. Data is driven using I/O [0] during the command phase, and I/O [1] the during response phase. The eSPI slave is required to tri-state I/O[1] during command phase as I/O[1] can be driven by eSPI master such as when initiating an In-Band Reset command.

During the dual I/O mode, the I/O pins [1:0] are bi-directional to form a bi-directional data bus. All the command and response phases are transferred over the two bidirectional pins at the same time, which effectively doubles the transfer rate than that of the single I/O mode.

During the quad I/O mode, the I/O pins [3:0] are bi-directional data bus. All the command and response phases are transferred over the four bi-directional pins at the same time, which effectively doubles the transfer rate than that of the dual I/O mode.

During eSPI transaction, each field is shifted in a defined order. For multi-bytes field, the shifting order is as following:

Header (length and address): Most Significant Byte (MSB) to Least Significant Byte (LSB)
Data: LSB to MSB
Status: LSB to MSB

Figure 22. Byte Ordering on the eSPI BusThis is an example of a master initiated a peripheral channel memory read.

7.1.2. Transaction Layer

The RX Shifter block in the transaction layer gets the parallel data bus from the link layer. It identifies the fields of an eSPI transaction such as Header, Data, or Status and sends it to the Command Detector block for decoding. On the transmit side, the Response Generator block gathers information about the eSPI transaction. Thereafter, the TX shifter block sends out the transaction as per the field order to the link layer.

The transaction layer also contains an Error Detection and Handling block. There is no error correction capability or hardware recovery mechanism defined for the eSPI bus. The eSPI slave core categorize and handles the errors detected on the eSPI bus as following:

Table 21. Error Detection and Handling Categories
Error Condition	eSPI Slave Core Response and Handling
Invalid command opcode	Command is discarded. eSPI slave core response with `NO_RESPONSE` opcode.
Invalid cycle type	Command is discarded. eSPI slave core response with `NO_RESPONSE` opcode.
Command phase CRC error	Command is discarded. eSPI slave core response with `NO_RESPONSE` opcode.
Unexpected `espi_cs_n` de-assertion	eSPI slave core tri-state the data bus after `espi_cs_n` is deasserted and follows `tSHQZ` rule. It also triggers CRC error during response phase only if CRC checking is enabled.
Protocol error: PUT without FREE GET without AVAILABLE	Command is discarded. eSPI slave core response with `FATAL_ERROR` opcode.
Malformed packet during command phase: Peripheral Channel: Payload length > Maximum Payload Size Read Request Size > Maximum Read Request Size (Address + Length) > 4Kb Virtual Wire Channel: Count > Maximum Virtual Wire Count	Command is discarded. eSPI slave core response with `FATAL_ERROR` opcode.
When PORT `00h` to PORT `100h` only supports `PC_CHANNEL IO SHORT` command and the master issues `IO READ/WRITE SHORT` command to address outside of `00h` to `100h`.	Command is discarded. eSPI slave core response with `NON_FATAL_ERROR` opcode.

Besides the Error Detection and Handling block, there is a CRC-8 Generator block to protect the eSPI transaction packets. The command phase and response phase contain their respective CRC byte. For command phase, the CRC calculation includes all the bytes during the command phase such as the Command Opcode, Header and Data. For response phase, the CRC calculation includes all the bytes during the response phase such as the Response Opcode (except WAIT_STATE), Header, Data and Status. The CRC checking is disabled by default. To enable CRC checking, set the CRC Checking Enable bit using the SET_CONFIGURATION command.

7.1.3. Channel Specific Layer

Currently, the eSPI slave core only supports Channel 0 and Channel 1. However, the eSPI slave core is designed to support future expansion for other channel specification such as OOB and Flash Access Channel.

7.1.3.1. Peripheral Channel

The peripheral channel allows you to communicate between the eSPI master and the eSPI endpoints located at the slave side (example: PORT80). To reset the channel, use the platform reset (PLTRST_n VW).

You can enable the peripheral IO access and configure the port width and direction using the Platform Designer. The eSPI slave core allocates address range from 00h to A0h to excess the peripheral IO. See Table: Peripheral IO Port Configuration for more details. By default, the pc_port80 has 8-bit data width. Each address location can be configured as 8-bit wide, 16-bit wide or 32-bit wide.

When you set a a IO port to 8-bit wide, you must access the port using PUT_IORD_SHORT 1 byte/PUT_IOWR_SHORT 1 byte command. When you set a a IO port to 16-bit wide, you must access the port using PUT_IORD_SHORT 2 byte/PUT_IOWR_SHORT 2 byte command. When you set a a IO port to 32-bit wide, you must access the port using PUT_IORD_SHORT 4 byte/PUT_IOWR_SHORT 4 byte command.

PUT_PC or PUT_NP loads packets into the FIFO while GET_PC or GET_NP flushes out packets from the FIFO. Decoder decodes address bytes from the header and sends data out to the corresponding output port.

Table 22. Peripheral IO Port Configuration
Address	Data Width	Port Name	Port Direction	Enable
00h	8/16/32	`pc_port00`	Input/Output	Yes/No
10h	8/16/32	`pc_port10`	Input/Output	Yes/No
20h	8/16/32	`pc_port20`	Input/Output	Yes/No
30h	8/16/32	`pc_port30`	Input/Output	Yes/No
40h	8/16/32	`pc_port40`	Input/Output	Yes/No
50h	8/16/32	`pc_port50`	Input/Output	Yes/No
60h	8/16/32	`pc_port60`	Input/Output	Yes/No
70h	8/16/32	`pc_port70`	Input/Output	Yes/No
80h	8/16/32	`pc_port80`	Input/Output	Yes/No
90h	8/16/32	`pc_port90`	Input/Output	Yes/No
A0h	8/16/32	`pc_portA0`	Input/Output	Yes/No

7.1.3.2. Virtual Wire Channel

The virtual wire (VW) channel allows you to communicate the state of the GPIO tunneled through eSPI bus as in-band messages. The command phase consists of a command opcode, virtual wire count, virtual wire index, virtual wire data and CRC.

Figure 23. Virtual Wire Packet

The virtual wire count indicates the number of virtual wire groups communicated by the packet. It is followed by one or more virtual wire groups. Each virtual wire group consists of 2 bytes, namely the virtual wire index and the virtual wire data. The eSPI slave core supports System Event, and Server Platform Specific virtual wire index.

Table 23. System Event Virtual Wire Index
Virtual Wire Index	Direction	Virtual Wire Data Byte								Reset
Virtual Wire Index	Direction	Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0	Reset
2h	Master to Slave	Valid bit for Bit 3- Bit 0				Reserved	`SLP_S5_n`	`SLP_S4_n`	`SLP_S3_n`	`rsmrst_n`
3h	Master to Slave	Valid bit for Bit 3- Bit 0				Reserved	`OOB_RST_WARN`	`PLTRST_n`	`SUS_STAT_n`	`espi_reset_n`
4h	Slave to Master	Valid bit for Bit 3- Bit 0				`PME_n`	`WAKE_n`	Reserved	`OOB_RST_ACK`	`espi_reset_n`
5h	Slave to Master	Valid bit for Bit 3- Bit 0				`SLAVE_BOOT_LOAD_STATUS`	-	-	`SLAVE_BOOT_LOAD_DONE`	`espi_reset_n`
6h	Slave to Master	Valid bit for Bit 3- Bit 0				`HOST_RST_ACK`	`RCIN_n`	`SMI_n`	`SCI_n`	`PLTRST_n VW`
7h	Master to Slave	Valid bit for Bit 3- Bit 0				Reserved	`NMIOUT_n`	`SMIOUT_n`	`HOST_RST_WARN`	`PLTRST_n VW`

Table 24. Server Platform Specific Virtual Wire Index
Virtual Wire Index	Direction	Virtual Wire Data Byte								Reset
Virtual Wire Index	Direction	Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0	Reset
40h	Slave to Master	Valid bit for Bit 3- Bit 0				Reserved	Reserved	Reserved	`SUS_ACK_n`	`espi_reset_n`
41h	Master to Slave	Valid bit for Bit 3- Bit 0				`SLP_A_n`	Reserved	`SUS_PWRDN_ACK`	`SUS_WARN_n`	`espi_reset_n`
42h	Master to Slave	Valid bit for Bit 3- Bit 0				Reserved	Reserved	`SLP_WLAN_n`	`SLP_LAN_n`	`rsmrst_n`
43h	Master to Slave	Valid bit for Bit 3- Bit 0				`PCH_TO_EC_3`	`PCH_TO_EC_2`	`PCH_TO_EC_1`	`PCH_TO_EC_0`	`espi_reset_n`
44h	Master to Slave	Valid bit for Bit 3- Bit 0				`PCH_TO_EC_7`	`PCH_TO_EC_6`	`PCH_TO_EC_5`	`PCH_TO_EC_4`	`espi_reset_n`
45h	Slave to Master	Valid bit for Bit 3- Bit 0				`EC_TO_PCH_3`	`EC_TO_PCH_2`	`EC_TO_PCH_1`	`EC_TO_PCH_0`	`espi_reset_n`
46h	Slave to Master	Valid bit for Bit 3- Bit 0				`EC_TO_PCH_7`	`EC_TO_PCH_6`	`EC_TO_PCH_5`	`EC_TO_PCH_4`	`espi_reset_n`
47h	Master to Slave	Valid bit for Bit 3- Bit 0				Reserved	Reserved	Reserved	`HOST_C10`	`PLTRST_n VW`

7.1.4. Port80 Implementation

To send a Port80 message, the eSPI master:

sends PUT_IOWR_SHORT 1 byte as the command
80h as the address bytes in header
followed by a byte of data and CRC

The port80[7:0] gets 8-bit data. After, 2 clock cycles of turn around time, the eSPI slave core sends back ACCEPT as the response code, and followed by the status register value and CRC.

Figure 24. eSPI Master Initiated Short IO Write Transaction

7.1.5. VW message to Physical Port Implementation

To assert the output ports that connect to the Virtual Wire channel, the eSPI master:

sends PUT_VWIRE as the command
assign a virtual wire count value
assign the virtual wire index of the corresponding output port
followed by a byte of data and CRC

For example, when the eSPI master is asserting SLP_S3_n, the virtual wire index is 2h and data byte is 8‘b00010110. The virtual wire tunneled through eSPI takes effect at the receiver only when the espi_cs_n is deasserted.

Figure 25. Virtual Wire Transaction

When the logical state of the output ports which connect to the Virtual Wire channel changes, the new state must be communicated to the eSPI master. In this case, the eSPI slave core initiates an Alert event to the eSPI master. Then, eSPI master triggers a GET_STATUS transaction, followed by a GET_VWIRE transaction.

7.1.6. Avalon-MM Interface Settings

Table 25. Avalon-MM Interface Settings
Setting Field	Value
readLatency	2
readWaitTime	0
writeWaitTime	0
addressUnits	WORDS
bitsPerSymbol	8
maximumPendingReadTransactions	0
maximumPendingWriteTransactions	0
burstOnBurstBoundariesOnly	false

7.2. Resource Utilization

Table 26. eSPI Slave Core Resource Utilization
Device	Resource	Value
Intel^® MAX^® 10	F_MAX	150 MHz⁴
	Logic cells	1586
	Dedicated logic registers	813
	M9Ks	5

⁴ The clock ratio between eSPI clock and the IP clock must be x3. Intel recommends to run eSPI clock of 66MHz in Intel^® Arria^® 10 device and with IP clock above 200MHz. Currently, the eSPI clock of 66MHz is not supported in Intel^® MAX^® 10 devices.

7.3. IP Parameters

Table 27. Parameter ListYou can configure these parameter using the Platform Designer.
Parameter Name	Default Value	Description
eSPI Mode of Operation	Single I/O	Allows you to set I/O configuration. Available options: Single I/O Single and Dual I/O Single and Quad I/O Signal, Dual and Quad I/O
Frequency of Operation	20MHz	Allows you to set the operational frequency. Available options: 20MHz 25MHz 33MHz 50MHz 66MHz
Channel Supported	Peripheral Channel	Allows you to set the channel support. Available option: Virtual Wire Channel Peripheral Channel All Channel
Peripheral Channel Maximum Payload Size Supported	64 bytes	Allows you to set the maximum payload size for peripheral channel. Available options: 64 bytes
Peripheral Channel Maximum Read Request Size Supported	64 bytes	Allows you to set the maximum read request size for peripheral channel. Available options: 64 bytes
Maximum Virtual Wire Count Supported (0-based)	0x07	Allows you to set the maximum virtual wire count. Legal values: 0x07: 8 count 0x08: 9 count 0x09: 10 count 0x0A: 11 count 0x0B: 12 count 0x0C: 13 count 0x0D: 14 count 0x0E: 15 count 0x0F: 16 count

7.4. Interface Signals

Table 28. Interface Signals
Signal Names	Width (bit)	Direction	Description
Clock Interface
`clk`	1	Input	Input clock signal.
Reset Interface
`reset_n`	1	Input	Synchronous reset signal.
Avalon^® -MM Slave Interface ⁵
`avmm_read`	1	Input	Use this signal to enable read from the status register, error register, posted RX fifo or non-posted RX fifo.
`avmm_readdata`	32	Output	Use this signal to read data from the status register , error register, posted RX fifo or non-posted RX fifo.
`avmm_write`	1	Input	Use this signal to enable write to posted TX fifo or non-posted TX fifo.
`avmm_writedata`	32	Input	Use this signal to write data to posted TX fifo or non-posted TX fifo.
`avmm_address`	5	Input	Avalon address determines address to access the respective register/fifo.
Interrupt Signal
`irq`	1	Output	Interrupt signal reflects update to status register. It is also triggered when the error register bit is asserted.
eSPI Interface
`espi_clk`	1	Input	eSPI serial clock signal. Frequency range: 20MHz to 66 MHz.
`espi_reset_n`	1	Input	eSPI reset signal.
`espi_cs_n`	1	Input	eSPI chip select signal.
`espi_data`	2 or 4	Input/Output	eSPI bi-directional data bus. Data bus configuration is determined by the eSPI Mode of Operation parameter.
`espi_alert_n`	1	Output	eSPI alert signal.
Conduit
`slp_s5_n`	1	Output	S5 sleep control signal is sent when the power to non-critical systems should be shut off in S5.
`slp_s4_n`	1	Output	S4 sleep control signal is sent when the power to non-critical systems should be shut off in S4.
`slp_s3_n`	1	Output	S3 sleep control signal is sent when the power to non-critical systems should be shut off in S3.
`slp_a_n`	1	Output	Use sleep A signal to support ASW devices that needs power in the SX platform when the Intel^® ME is on.
`slp_lan_n`	1	Output	LAN sub-system sleep control signal is sent when the power to external wired LAN PHY can be shut off.
`slp_wlan_n`	1	Output	Wireless LAN sub-system sleep control signal is sent when the power to external wireless LAN PHY can be shut off.
`sus_stat_n`	1	Output	Suspend status signal is sent when the system is about to enter a low power state.
`sus_pwrdn_ack`	1	Output	Suspend power down acknowledgement signal.
`sus_warn_n`	1	Output	Suspend warning signal.
`oob_rst_warn`	1	Output	Master sends this signal before the OOB processor is about to reset.
`host_rst_warn`	1	Output	Master sends this signal before the host is about to reset.
`smiout_n`	1	Output	Master sends this signal indicating the occurrence of SMI event.
`nmiout_n`	1	Output	Master sends this signal indicating the occurrence of NMI event.
`host_c10`	1	Output	Indicates that the host CPU has entered deep power down state C10 or deeper.
`pch_to_ec`	8	Input	8 independent virtual wire placeholder from the platform controller hub (eSPI master) to the eSPI slave IP.
`ec_to_pch`	8	Input	8 independent virtual wire placeholder from eSPI slave IP to the platform controller hub (eSPI master).
`sus_ack_n`	1	Input	Suspend acknowledgement signal.
`oob_rst_ack`	1	Input	OOB reset acknowledgement signal.
`wake_n`	1	Input	This signal wakes up host from Sx on any event. It can also wake up on LID switch or AC insertion event.
`pme_n`	1	Input	This signal wakes up host from Sx through PCI defined PME.
`sci_n`	1	Input	General purpose alert signal which results in OS invoking ACPI method.
`smi_n`	1	Input	General purpose alert signal which results in BIOS invoking SMI code.
`rcin_n`	1	Input	To request CPU reset on behalf of the keyboard controller.
`host_rst_ack`			Host reset acknowledgement signal.
`slave_boot_load_done`	1	Input	Indicates the boot load completion.
`slave_boot_load_status`	1	Input	Indicates the boot load status.
`pc_port80`	8, 16 or 32	Output	Output port that redirects with Port80 message
`rsmrst_n`	1	Input	This signal provides input reset to some of the virtual wire index.

⁵ Use Avalon^® -MM interface to access the status register with Avalon address set to 00h and also the FIFO in the PC channel with Avalon address set to 04h.

7.5. Registers

7.5.1. Avalon -MM Interface Accessible Registers

Table 29. Avalon^® -MM Interface Accessible Register Map
Offset Address	Register Name	Access Type	Width (bits)
0x0h	Status Register	R	32
0x4h	Control Register	W	32
0x8h	Posted RX FIFO⁶	R	8
0xCh	Posted TX FIFO ⁷	W	8
0x10h	Non-posted RX FIFO⁸	R	8
0x14h	Non-posted TX FIFO⁷	W	8
0x18h	Error Register	R/W1C	32

⁶ eSPI master issue command such as PUT_PC , or PUT_MEMWR_SHORT to write data byte into this FIFO. To retrieve data from this FIFO, use Avalon read signal.

⁷ Issue Avalon Write command to write response data into this FIFO.

⁸ eSPI master issue command such as PUT_NP, PUT_MEMRD_SHORT, PUT_IORD_SHORT, or PUT_IOWR_SHORT to write data byte into this FIFO. To retrieve data from this FIFO, use Avalon read signal.

7.5.1.1. Status Register

Table 30. Status Register Bit Description
Bit	Type	Status Field	Description
0	R	`PCRXFIFO_AVAIL`	The following values indicates: 1: Channel 0 Posted RXFIFO has a peripheral posted or completion header. And data up to maximum payload size is available for read. 0: Channel 0 Posted RXFIFO is empty.
1	R	`NPRXFIFO_AVAIL`	The following values indicates: 1: Channel 0 Non-posted RXFIFO has a peripheral non-posted header available for read. 0: Channel 0 Non-posted RXFIFO is empty.
31:2	-	-	Reserved.

7.5.1.2. Control Register

Table 31. Control Register Bit Description
Bit	Type	Control Field	Description
0	W	`PCTXFIFO_AVAIL`	Write the following values: 1: To indicate that the Channel 0 Posted TXFIFO has a peripheral posted or completion header. And data up to maximum payload size is available. 0: Clear by hardware.
1	W	`NPTXFIFO_AVAIL`	Write the following values: 1: To indicate that the Channel 0 Non-posted TXFIFO has a complete peripheral non-posted header available. 0: Clear by hardware.
31:2	-	-	Reserved.

7.5.1.3. Error Register

Table 32. Error Register Bit DefinitionTo clear any of the following register bits, write 1 to that respective bit.
Bit	Type	Error Field
0	R/W1C	Invalid Command Opcode
1	R/W1C	Invalid Cycle Type
2	R/W1C	Command Phase CRC Error
3	R/W1C	Unexpected de-assertion of `espi_cs_n`
4	R/W1C	Put without Free
5	R/W1C	Get without Available
6	R/W1C	Malformed packed in Peripheral Channel
7	R/W1C	Malformed packed in Virtual Wire Channel
31:8	-	Reserved

7.5.2. eSPI Interface Accessible Registers

7.5.2.1. eSPI Status Register

This status register reflects the status of the eSPI slave IP. You can access this register using the GET_STATUS command through eSPI interface. You can also access this register via Avalon^® -MM by asserting the read request with Avalon^® -MM address 00h.

During the response phase, the status field is always returned to the eSPI master. The received command is only decoded after the deassertion of espi_cs_n signal. Therefore, the implementation effect of a queued command is reflected in the status of the subsequent transaction.

The eSPI status register bits are read-only and cleared by espi_reset_n.

Table 33. eSPI Status Register Bit Description
Bit	Status Field	Description
0	`PC_FREE`	The following values indicates: 1: Channel 0 Posted FIFO is empty to accept peripheral posted or completion header and data up to maximum payload size. 0: Channel 0 Posted FIFO has one complete peripheral posted or completion header & data packet.
1	`NP_FREE`	The following values indicates: 1: Channel 0 Non-posted FIFO is empty to accept peripheral posted or completion header and data up to maximum payload size. 0: Channel 0 Non-posted FIFO has one complete peripheral posted or completion header & data packet.
2	`VWIRE_FREE`	The value is always 1.
3	`OOB_FREE`	The value is always 1.
4	`PC_AVAIL`	The following values indicates: 1: Channel 0 Posted FIFO has a peripheral posted or completion header. And data up to maximum payload size is available to send. 0: Channel 0 Posted FIFO is empty.
5	`NP_AVAIL`	The following values indicates: 1: Channel 0 Non-posted FIFO has a peripheral posted or completion header. And data up to maximum payload size is available to send. 0: Channel 0 Non-posted FIFO is empty.
6	`VWIRE_AVAIL`	The following values indicates: 1: Channel 1 has a tunneled virtual wire available to send. 0: Channel 1 is empty.
7	`OOB_AVAIL`	The value is always 0.
8	`FLASH_C_FREE`	The value is always 1.
9	`FLASH_NP_FREE`	The value is always 1.
10	Reserved	-
11	Reserved	-
12	`FLASH_C_AVAIL`	The value is always 0.
13	`FLASH_NP_AVAIL`	The value is always 0.
14	Reserved	-
15	Reserved	-

7.5.2.2. Capabilities and Configuration Registers

You can access these register using the GET_CONFIGURATION and SET_CONFIGURATION commands. When you configure the registers using the SET_CONFIGURATION command, the new register value takes affect only at the deassertion edge of espi_cs_n.

The capabilities and configuration register bits are reset by espi_reset_n.

Table 34. Capabilities and Configuration Register Map
Offset	Register Name
0x4	Device Identification
0x8	General Capabilities and Configurations
0x10	Channel 0 Capabilities and Configurations
0x20	Channel 1 Capabilities and Configurations
0x30	Channel 2 Capabilities and Configurations
0x40	Channel 3 Capabilities and Configurations

Table 35. Device Identification Register Description
Bit	Access Type	Default Value	Description
31:8	-	-	Reserved.
7:0	R	0x01	Indicates the Version ID that is compliant to the specific eSPI specification revision.

Table 36. General Capabilities and Configurations Register Description
Bit	Access Type	Default Value	Description
31	RW	0	CRC Checking: 1: CRC checking is enabled 0: CRC checking is disabled
30:29	-	-	Reserved.
28	RW	0	Alert Mode: 1: `espi_alert_n` is used to signal the Alert event 0: `espi_data[1]` is used to signal the Alert event
27:26	RW	2'b00	I/O Mode Select: 2'b00: Single I/O 2'b01: Dual I/O 2'b10: Quad I/O 2'b11: Reserved
25:24	R	-	Indicates value set for eSPI Mode of Operation parameter.
23	-	-	Reserved.
22:20	RW	3'b000	Operating Frequency: 3'b000: 20MHz 3'b001: 25MHz 3'b010: 33MHz 3'b011: 50MHz 3'b100: 66MHz
19	-	-	Reserved.
18:16	R	-	Indicates value set for Frequency of Operation parameter.
15: 12	RW	4'b0000	The maximum Wait State allowed before responding with an `ACCEPT`, `DEFER`, `NON_FATAL ERROR` or `FATAL ERROR` response code: 4'b0000: 16 byte time 4'b0001: 1 byte time 4'b0010: 2 byte time 4'b0011: 3 byte time ..... 4'b1111: 15 byte time
11:8	-	-	Reserved.
7:0	R	-	Indicates value set for Channel Supported parameter.

Table 37. Channel 0 Capabilities and Configurations Register Description
Bit	Access Type	Default Value	Description
31:15	-	-	Reserved.
14:12	RW	3'b001	Peripheral Channel Address Aligned Maximum Read Request Size: 3'b000: Reserved 3'b001: 64 bytes The length of the read request must not cross the naturally aligned address boundary of the corresponding Maximum Read Request Size.
11	-	-	Reserved.
10:8	RW	3'b001	Peripheral Channel Address Aligned Maximum Payload Size Selected: 3'b000: Reserved 3'b001: 64 bytes It must never be more than the value stated in the Peripheral Channel Maximum Payload Size Supported field.The payload of the transaction must not cross the naturally aligned address boundary of the corresponding Maximum Payload Size.
7	-	-	Reserved.
6:4	R	-	Indicates value set for Peripheral Channel Maximum Payload Size Supported parameter.
3:2	-	-	Reserved.
1	R	0	Peripheral Channel Ready: 1: Channel is ready 0: Channel is not ready
0	RW	1	Peripheral Channel Enable: 1: Channel is enabled 0: Channel is disabled While you clear this bit from 1 to 0, this triggers a reset to the Peripheral Channel.

Table 38. Channel 1 Capabilities and Configurations Register Description
Bit	Access Type	Default Value	Description
31:22	-	-	Reserved.
21:16	RW	0	Operating Maximum Virtual Wire Count - The maximum number of Virtual Wire groups that can be sent in a single Virtual Wire packet. The value configured in this field must never be more than the value stated in MAX_VW_COUNT. The default value 0 indicates count of 1. Other legal values: 6'b000111: 8 count 6'b001000: 9 count 6'b001001: 10 count 6'b001010: 11 count 6'b001011: 12 count 6'b001100: 13 count 6'b001101: 14 count 6'b001110: 15 count 6'b001111: 16 count
15:14	-	-	Reserved.
13:8	R	-	Indicates value set for MAX_VW_COUNT parameter.
7:2	-	-	Reserved.
1	R	0	Virtual Wire Channel Ready: 1: Channel is ready 0: Channel is not ready
0	RW	0	Virtual Wire Channel Enable: 1: Channel is enabled 0: Channel is disabled When you clear this bit, it does not reset the Virtual Wire Channel. Therefore, the state of all the Virtual Wires must be maintained.

7.6. Peripheral Channel Avalon Interface Use Model

Each Avalon read command reads back only 8-bit data. Even though the Avalon-MM read data is 32-bit wide, but only 8-bits (LSB) are used. This behavior applies to Avalon write command too.

When eSPI master sends PUT_IORD_SHORT or PUT_IOWR_SHORT command, these packets are not stored inside the FIFOs. The packet’s data is directly send to pc_port**_in port or pick from /pc_port**_out port.

You must use the following format while sending the response packet to PCTXFIFO:

cycletype (SUCCESSFUL_COMPLETION_WITH_DATA/UNSUCCESSFUL_COMPLETION) -> MSB length -> LSB length -> DATA (optional)

After writing a response packet to PCTXFIFO, you must write 1 to Avalon Control Register (0x4h), indicating that the PCTXFIFO has a complete payload available. Once this flag is triggered, the eSPI master is acknowledged (thru espi status information) and fetchs the packet accordingly using the GET_PC command. Each FIFO can only store one packet.

Use Avalon Status Register (0x0h) to verify that the eSPI master sent a complete packet to PCRXFIFO (using PUT_PC/ PUT_MEMWR32_SHORT command) or NPRXFIFO (using PUT_NP/ PUT_MEMRD32_SHORT command).

In the event of the following errors, the FIFO in the peripheral channel is flushed:

Invalid cycle type
Invalid command
CRC mismatch
Put FIFO without FIFO Free asserted
Get FIFO without FIFO Available asserted

7.7. Intel eSPI Slave Core Revision History

Document Version	Intel^® Quartus^® Prime Version	Changes
2018.09.24	18.1	Corrected signal names (`spi_` to `espi_`). Updated on IP clock frequency in Table: eSPI Slave Core Resource Utilization. Updated Avalon interface registers. Added a new section: Peripheral Channel Avalon Interface Use Model,
2018.05.07	18.0	Initial release.

8. eSPI to LPC Bridge Core

The eSPI to LPC Bridge core allows interaction between the eSPI master as the upstream device and LPC slave as the downstream device. This core primarily uses the eSPI slave IP core with some additional blocks to convert the eSPI packets into LPC transactions. This bridge does not use the Avalon interface to access the FIFOs in the peripheral channel. However, the LPC interface signals allow you to connect the bridge with downstream LPC device.

8.1. Unsupported LPC Features

This IP core does not support the following LPC features:

DMA Read/Write cycle
Bus Master Memory Read/Write cycle
Bus Master IO Read/Write cycle
LPC clock enable/disable

8.2. IP Parameters

Table 39. Parameter ListYou can configure these parameters using the Platform Designer.
Parameter Name	Default Value	Description
eSPI Mode of Operation	Single I/O	Allows you to set I/O configuration. Available options: Single I/O Single and Dual I/O Single and Quad I/O Signal, Dual and Quad I/O
Frequency of Operation	20MHz	Allows you to set the operational frequency. Available options: 20MHz 25MHz 33MHz 50MHz 66MHz
Channel Supported	Peripheral Channel	Allows you to set the channel support. Available option: Virtual Wire Channel Peripheral Channel All Channel
Peripheral Channel Maximum Payload Size Supported	64 bytes	Allows you to set the maximum payload size for peripheral channel. Available options: 64 bytes
Peripheral Channel Maximum Read Request Size Supported	64 bytes	Allows you to set the maximum read request size for peripheral channel. Available options: 64 bytes
Maximum Virtual Wire Count Supported (0-based)	0x07	Allows you to set the maximum virtual wire count. Legal values: 0x07: 8 count 0x08: 9 count 0x09: 10 count 0x0A: 11 count 0x0B: 12 count 0x0C: 13 count 0x0D: 14 count 0x0E: 15 count 0x0F: 16 count

8.3. Supported IP Clock Frequency

Table 40. IP Clock Frequency Support
Device Family	eSPI Clock Frequency (MHz)	Minimum IP Clock Frequency (MHz)	Maximum IP Clock Frequency (MHz)
Intel^® MAX^® 10	20	60	150
	25	80	150
	33	100	150
	50	150	150
Intel^® Arria^® 10	66	200	-

8.4. Functional Description

Figure 26. Block DigramThe figure depicts the eSPI slave IP core integrated with the eSPI-to-LPC bridge module.

The lpc_bridge block must be used together with the peripheral_channel block. Therefore, you must set the Channel Supported parameter bit 0 to 1 while using the lpc_bridge.

The SERIRQ interrupt event is sampled and translated into VW index group. Therefore, you must set the Channel Supported parameter bit 1 to 1 while using the SERIRQ interrupt.

8.4.1. FIFO Implementation

All FIFOs are used in peripheral channel to buffer up the incoming transactions. When the eSPI-to-LPC bridge is busy transferring data down the LPC interface, the transactions from the eSPI master are stored using the PC_RXFIFO or NP_RXFIFO until the bridge is idle. The PC_RXFIFO stores posted transactions while the NP_RXFIFO stores non-posted transactions.

The RXFIFOs can store more than one eSPI transaction (command byte, header byte and write data byte) until it is full. When the FIFO depth is less than MAX_PC_PAYLOAD_SIZE + 1 complete header + 1 command byte or 1 complete header + 1 command byte for NP_RXFIFO , the PC_FREE/NP_FREE status register bit is de-asserted.

The Pre_RXFIFO stores an incoming eSPI transaction for CRC error checking purposes. CRC error check is performed after pushing the last byte of a eSPI transaction into Pre_RXFIFO. If CRC error is high, then the eSPI transaction is dropped to avoid translation into a LPC transaction. If CRC error is low, the eSPI transaction is pushed into NP_RXFIFO or PC_RXFIFO for translating into a LPC transaction.

The PC_TXFIFO stores response transaction from the downstream LPC devices. ThePC_ AVAIL status register bit goes high only when a complete response transaction is stored in the PC_TXFIFO.

The Pre_TXFIFO stores an incoming LPC transaction for error checking purposes. In the event of LPC transaction abort or LPC transaction sync error, the transaction is dropped from the Pre_TXFIFO. The transaction is pushed into PC_TXFIFO provided that there is no error, then to eSPI master.

All the FIFOs are 8-bit wide. The figure below shows the content of the RXFIFO which can store one complete eSPI transaction.

Figure 27. RXFIFO Contents

8.4.2. Transaction Ordering Rule

When the LPC bridge is ready to fetch the transaction from the RXFIFOs, it always pops the transaction from PC_RXFIFO (write transaction) first, then the transaction from NP_RXFIFO (read transaction). This rule prevents any reading of old data.

8.4.3. eSPI Command to LPC Cycle Type Conversion

Table 41. Conversion List
eSPI Command	Supported Sizes (in bytes)	LPC Cycle Type
`PUT_NP`	1 to 64	Memory Read
`PUT_MEMRD32_SHORT_1B`	1
`PUT_MEMRD32_SHORT_2B`	2
`PUT_MEMRD32_SHORT_4B`	4
`PUT_PC`	1 to 64	Memory Write
`PUT_MEMWR32_SHORT_1B`	1
`PUT_MEMWR32_SHORT_2B`	2
`PUT_MEMWR32_SHORT_4B`	4
`PUT_IORD_SHORT_1B`	1	IO Read
`PUT_IORD_SHORT_2B`	2
`PUT_IORD_SHORT_4B`	4
`PUT_IOWR_SHORT_1B`	1	IO Write
`PUT_IOWR_SHORT_2B`	2
`PUT_IOWR_SHORT_4B`	4

8.4.4. SERIRQ Interrupt Event

The LPC bridge supports 16 lines IRQ/Data serializer by sampling the event of SERIRQ signal from the LPC interface. A SERIRQ cycle transfer consists of three frame types:

Start Frame: The slave device drives the SERIRQ line low to indicate the start of IRQ transmission.
IRQ/Data Frames (several): Peripherals transmit the IRQ information. The eSPI bridge master supports 16 IRQ data frames. During the sample phase, the SERIRQ device must drive the SERIRQ low, if and only if, its detected IRQ/Data value is low. And if its detected IRQ/Data value is high, SERIRQ must be left tri-stated. During the recovery phase, the device must drive the SERIRQ high, if and only if, it had driven the SERIRQ low during the sample phase.
Stop Frame: The Host Controller initiates a Stop frame to terminate SERIRQ activity after all IRQ/Data Frames have completed. A Stop Frame is indicated when the SERIRQ is low for two clock cycles. Stop frame occurs at 53-54 clock cycles past the Start frame.

Figure 28. SERIRQ Event Timing Diagram

The start frame is 4 clock cycles, stop frame is 2 clock cycles, and the IRQ/Data frames clock cycles are stated below:

Table 42. IRQ/Data Frame Clock Period
IRQ/Data Frame	Sampled Signal	Number of Clocks after Start Frame
1	IRQ0	2
2	IRQ1	5
3	SMI#	8
4	IRQ3	11
5	IRQ4	14
6	IRQ5	17
7	IRQ6	20
8	IRQ7	23
9	IRQ8	26
10	IRQ9	29
11	IRQ10	32
12	IRQ11	35
13	IRQ12	38
14	IRQ13	41
15	IRQ14	44
16	IRQ15	47
17	Reserved	-

Once the LPC bridge samples and derives the SERIRQ event, it translates the IRQ/Data Frame into VW index bit as below:

Table 43. SERIRQ IRQ/Data Frame to VW Index Group Mapping
SERIRQ Sampled Signal	VW Index Group	VW Data Bit
SMI#	6h	Bit 2
IRQ0 to IRQ15	00h	Bit 0 - Bit 15

IRQ VW information can be sent to the eSPI master only through GET_VWIRE command during transition period.

Table 44. VW Information via Transition Period
Interrupt Source Type	Interrupt Source Level	Slave to Master IRQ Virtual Wire (Active High)
Active low	0 → 1	De-assertion. IRQ VW (Level=’0’) sent.
Active low	1 → 0	Assertion. IRQ VW (Level=’1’) sent.

8.5. Interface Signals

Table 45. Interface Signals
Signal Name	Width	Direction	Description
Clock Interface
`clk`	1	Input	Input clock used to clock the IP core.
Reset Interface
`reset_n`	1	Input	Synchronous reset used to reset the IP core.
LPC Interface to LPC Slave Component
`lad`	4	Input/Output	Multiplexed Command, Address, and Data signal.
`lframe_n`	1	Output	Indicates start of a new cycle, or termination of broken cycle.
`lreset_n`	1	Output	Reset signal to LPC slave.
`lclk`	1	Output	33Mhz clock that drives the LPC slave.
`serirq`	1	Input/Output	Serialized IRQ interrupt signal.
Avalon Interface
`avmm_write`	1	Input	Avalon write control signal for register access.
`avmm_read`	1	Input	Avalon read control signal for register access.
`avmm_writedata`	32	Input	Avalon write data bus for register access.
`avmm_address`	5	Input	Avalon address bus for register access.
`avmm_readdata`	32	Output	Avalon read data bus for register access.
eSPI Interface
`espi_clk`	1	Input	eSPI serial clock. Frequency range from 20Mhz to 66Mhz.
`espi_reset_n`	1	Input	eSPI reset. Assertion of this reset signal does not reset the channel’s FIFO.
`espi_cs_n`	1	Input	eSPI chip select.
`espi_data`	2/4	Input/Output	eSPI bidirectional data bus. Data bus lane depending on parameter IO_MODE.
`espi_alert_n`	1	Output	eSPI alert.
Conduit Ports
`slp_s5_n`	1	Output	Server platform related signal.
`slp_s4_n`	1	Output
`slp_s3_n`	1	Output
`slp_a_n`	1	Output
`slp_lan_n`	1	Output
`slp_wlan_n`	1	Output
`sus_stat_n`	1	Output
`sus_pwrdn_ack`	1	Output
`sus_warn_n`	1	Output
`pch_to_ec`	8	Output
`Oob_rst_warn`	1	Output
`Host_rst_warn`	1	Output
`Smiout_n`	1	Output
`Nmiout_n`	1	Output
`Host_c10`	1	Output
`Pltrst_n`	1	Output
`ec_to_pch`	8	Input
`sus_ack_n`	1	Input
`slave_boot_load_done`	1	Input
`slave_boot_load_status`	1	Input
`Oob_rst_ack`	1	Input
`Wake_n`	1	Input
`Pme_n`	1	Input
`Sci_n`	1	Input
`Rcin_n`	1	Input
`Host_rst_ack`	1	Input
`Rsmrst_n`	1	Input

8.6. Registers

Table 46. Avalon^® -MM Interface Accessible Register Map
Offset Address	Register Name	Access Type	Width (bits)
0x0h	Status Register	R	32
0x4h	Error Register	R/W1C	32

8.6.1. Status Register

Table 47. Status Register Bit Definition
Bit	Type	Status Field
0	`PC_FREE`	1: Channel 0 Posted FIFO is empty to accept peripheral posted or completion header and data up to maximum payload size. 0: Channel 0 Posted FIFO has one complete peripheral posted or completion header & data packet.
1	`NP_FREE`	1: Channel 0 Non-posted FIFO is empty to accept peripheral non-posted or completion header and data up to maximum payload size. 0: Channel 0 Non-posted FIFO has one complete peripheral non-posted or completion header & data packet.
2	`VWIRE_FREE`	Always 1
3	`OOB_FREE`	Always 1
4	`PC_AVAIL`	1: Channel 0 Posted FIFO has a peripheral posted or completion header and data up to maximum payload size available to send. 0: Channel 0 Posted FIFO is empty.
5	`NP_AVAIL`	Always 0
6	`VWIRE_AVAIL`	1: Channel 1 has a tunneled virtual wire available to send (after the logical state of a virtual wire changes, this VW index and data is stored in the Channel 1 TX FIFO) 0: Channel 1 is empty.
7	`OOB_AVAIL`	Always 0
8	`FLASH_C_FREE`	Always 1
9	`FLASH_NP_FREE`	Always 1
11:10	Reserved	-
12	`FLASH_C_AVAIL`	Always 0
13	`FLASH_NP_AVAIL`	Always 0

8.6.2. Error Register

Table 48. Error Register Bit DefinitionTo clear any of the following register bits, write 1 to that respective bit.
Bit	Type	Error Field
0	R/W1C	Invalid Command Opcode
1	R/W1C	Invalid Cycle Type
2	R/W1C	Command Phase CRC Error
3	R/W1C	Unexpected de-assertion of `espi_cs_n`
4	R/W1C	Put without Free
5	R/W1C	Get without Available
6	R/W1C	Malformed packed in Peripheral Channel
7	R/W1C	Malformed packed in Virtual Wire Channel
31:8	-	Reserved

8.7. eSPI to LPC Bridge Core Revision History

Document Version	Intel^® Quartus^® Prime Version	Changes
2018.09.24	18.1	Initial release.

9. Ethernet MDIO Core

9.1. Core Overview

The Intel^® Management Data Input/Output (MDIO) IP core is a two-wire standard management interface that implements a standardized method to access the external Ethernet PHY device management registers for configuration and management purposes. The MDIO IP core is IEEE 802.3 standard compliant.

To access each PHY device, the PHY register address must be written to the register space followed by the transaction data. The PHY register addresses are mapped in the MDIO core’s register space and can be accessed by the host processor via the Avalon^® Memory-Mapped ( Avalon^® -MM) interface. This IP core can also be used with the Intel FPGA 10-Gbps Ethernet MAC and Intel FPGA Triple Speed Ethernet IP Core to realize a fully manageable system.

9.2. Functional Description

The core provides an Avalon^® Memory-Mapped ( Avalon^® -MM) slave interface that allows Avalon^® -MM master peripherals (such as a CPU) to communicate with the core and access the external PHY by reading and writing the control and data registers. The system interconnect fabric connects the Avalon^® -MM master and slave interface while a buffer connects the MDIO interface signals to the external PHY.

For more information about system interconnect fabric for Avalon^® -MM interfaces, refer to the System Interconnect Fabric for Memory-Mapped Interfaces.

Figure 29. MDIO Core Block Diagram

9.2.1. MDIO Frame Format (Clause 45)

The MDIO core communicates with the external PHY device using frames. A complete frame is 64 bits long and consists of 32-bit preamble, 14-bit command, 2-bit bus direction change, and 16-bit data. Each bit is transferred on the rising edge of the management data clock (MDC). The PHY management interface supports the standard MDIO specification (IEEE802.3 Ethernet Standard Clause 45).

Figure 30. MDIO Frame Format (Clause 45)

Table 49. MDIO Frame Field Descriptions—Clause 45
Field Name	Description
`PRE`	Preamble. 32 bits of logical 1 sent prior to every transaction.
`ST`	The start of frame for indirect access cycles is indicated by the <00> pattern. This pattern assures a transition from the default one and identifies the frame as an indirect access.
`OP`	The operation code field indicates the following transaction types: 00 indicates that the frame payload contains the address of the register to access. 01 indicates that the frame payload contains data to be written to the register whose address was provided in the previous address frame. 11 indicates that the frame is a read operation. The post-read-increment-address operation <10> is not supported in this frame.
`PRTAD`	The port address (`PRTAD`) is 5 bits, allowing 32 unique port addresses. Transmission is MSB to LSB. A station management entity (STA)⁹ must have a prior knowledge of the appropriate port address for each port to which it is attached, whether connected to a single port or to multiple ports.
`DEVAD`	The device address (`DEVAD`) is 5 bits, allowing 32 unique MDIO manageable devices (MMDs)¹⁰ per port. Transmission is MSB to LSB.
`TA`	The turnaround time is a 2-bit time spacing between the device address field and the data field of a management frame to avoid contention during a read transaction. For a read transaction, both the STA and the MMD remain in a high-impedance state (Z) for the first bit time of the turnaround. The MMD drives a 0 during the second bit time of the turnaround of a read or postread-increment-address transaction. For a write or address transaction, the STA drives a 1 for the first bit time of the turnaround and a 0 for the second bit time of the turnaround.
`REGAD/` `Data`	The register address (`REGAD`) or data field is 16 bits. For an address cycle, it contains the address of the register to be accessed on the next cycle. For the data cycle of a write frame, the field contains the data to be written to the register. For a read frame, the field contains the contents of the register. The first bit transmitted and received is bit 15.
`Idle`	The idle condition on MDIO is a high-impedance state. All tri-state drivers are disabled and the MMDs pullup resistor pulls the MDIO line to a one.

⁹ The device driving the MDIO bus is identified as the Station Management Entity (STA).

¹⁰ The target devices managed by the MDC are referred as MDIO Manageable Devices (MMDs).

9.2.2. MDIO Clock Generation

The MDIO core’s MDC is generated from the Avalon^® -MM interface clock signal, clk. The MDC_DIVISOR parameter specifies the division parameter. For more information about the parameter, refer to the Parameter section.

The division factor must be defined such that the MDC frequency does not exceed 2.5 MHz.

9.2.3. Interfaces

The MDIO core consists of a single Avalon^® -MM slave interface. The slave interface performs Avalon^® -MM read and write transfers initiated by an Avalon^® -MM master in the client application logic. The Avalon^® -MM slave uses the waitrequest signal to implement backpressure on the Avalon^® -MM master for any read or write operation which has yet to be completed.

For more information about Avalon^® -MM interfaces, refer to the Avalon^® Interface Specifications.

9.2.4. Operation

The MDIO core has bidirectional external signals to transfer data between the external PHY and the core.

9.2.4.1. Write Operation

Follow the steps below to perform a write operation.

Issue a write to the device register at address offset 0x21 to configure the device, port, and register addresses of the PHY.
Issue a write to the MDIO_ACCESS register at address offset 0x20 to generate an MDIO frame and write the data to the selected PHY device’s register.

9.2.4.2. Read Operation

Follow the steps below to perform a read operation.

Issue a write to the device register at address offset 0x21 to configure the device, port, and register addresses of the PHY.
Issue a read to the MDIO_ACCESS register at address offset 0x20 to read the selected PHY device’s register.

9.3. Parameter

Table 50. Configurable Parameter
Parameter	Legal Values	Default Value	Description
MDC_DIVISOR	8-64	32	The host clock divisor provides the division factor for the clock on the Avalon^® -MM interface to generate the preferred MDIO clock (MDC). The division factor must be defined such that the MDC frequency does not exceed 2.5 MHz. Formula: For example, if the Avalon^® -MM interface clock source is 100 MHz and the desired MDC frequency is 2.5 MHz, specify a value of 40 for the MDC_DIVISOR.

9.4. Configuration Registers

An Avalon^® -MM master peripheral, such as a CPU, controls and communicates with the MDIO core via 32-bit registers, shown in the Register Map table.

Table 51. Register Map
Address Offset	Bit(s)	Name	Access Mode	Description
`0x00-0x1F`	31:0	Reserved	RW	Reserved for future use.
`0x20` (1)	31:0	`MDIO_ACCESS`	RW	Performs a read or write of 32-bit data to the external PHY device. The addresses of the external PHY device’s register, device, and port are specified in address offset `0x21`.
`0x21` (2)	4:0	`MDIO_DEVAD`	RW	Contains the device address of the PHY.
	7:5	Reserved	RW	Unused.
	12:8	`MDIO_PRTAD`	RW	Contains the port address of the PHY.
	15:13	Reserved	RW	Unused.
	31:16	`MDIO_REGAD`	RW	Contains the register address of the PHY.
Note : The byte address for this register is 0x80. The byte address for this register is 0x84.

9.5. Interface Signals

Table 52. Ethernet MDIO Core Signal Description
Signal	Width	Direction	Description
Clock
`clk`	1	Input	Avalon^® -MM interface clock signal.
Reset
`reset`	1	Input	Asynchronous reset for Ethernet MDIO core.
Avalon^® -MM Slave Interface for CSR
`csr_write`	1	Input	Avalon^® -MM write control signal.
`csr_read`	1	Input	Avalon^® -MM read control signal.
`csr_address`	6	Input	Avalon^® -MM address bus.
`csr_writedata`	32	Input	Avalon^® -MM write data bus.
`csr_readdata`	32	Output	Avalon^® -MM read data bus.
`csr_waitrequest`	1	Output	Avalon^® -MM wait-request control signal..
MDIO Interface
`mdio_in`	1	Input	Management data input to FPGA bidirectional I/O buffer.
`mdio_out`	1	Output	Management data output from FPGA bidirectional I/O buffer.
`mdio_oen`	1	Output	An active low management data output enable signal to FPGA bidirectional I/O buffer. It is used to enable `mdio_in` or `mdio_out`.
`mdc`	1	Output	Management data clock. This clock is generated from Avalon^® -MM interface clock signal, `clk`. Use the `MDC_DIVISOR` parameter to specify the division factor such that the frequency of this clock does not exceed 2.5MHz.

9.6. Ethernet MDIO Core Revision History

Document Version	Intel^® Quartus^® Prime Version	Changes
2018.05.07	18.0	Added the section Interface Signals.

Date	Version	Changes
July 2014	2014.07.24	Removed mention of SOPC Builder, updated to Platform Designer
December 2010	v10.1.0	Revised the register map address offset.
July 2010	v10.0.0	Initial release.

10. Intel FPGA 16550 Compatible UART Core

10.1. Core Overview

The Intel FPGA 16550 UART (Universal Asynchronous Receiver/Transmitter) soft IP core with Avalon^® interface is designed to be register space compatible with the de-facto standard 16550 found in the PC industry. The core provides RS-232 Signaling interface, False start detection, Modem control signal and registers, Receiver error detection and Break character generation/detection. The core also has an Avalon^® Memory-Mapped ( Avalon^® -MM) slave interface that allows Avalon^® -MM master peripherals (such as a Nios^® II processor) to communicate with the core simply by reading and writing control and data registers.

The 16550 UART supports all memory types depending on the device family.

Note: You must acquire license to use this core..

Table 53. Product Information
Core	Product ID
Intel FPGA 16550 UART (Universal Asynchronous Receiver/Transmitter) soft IP core	6af7 010c

10.2. Feature Description

The 16550 Soft-UART has the following features:

RS-232 signaling interface
Avalon^® -MM slave
Single clock
False start detection
Modem control signal and registers
Receiver error detection
Break character generation/detection
Supports full duplex mode by default

Table 54. UART Features and Configurability
Features	Run Time Configurable	Generate Time Configurable
FIFO/FIFO-less mode	Yes	Yes
FIFO Depth	-	Yes
5-9 bit character length	Yes	-
1, 1.5, 2 character stop bit	Yes	-
Parity enable	Yes	-
Even/Odd parity	Yes	-
Baud rate selection	Yes	-
Memory Block Type	-	Yes
Priority based interrupt with configurable enable	Yes	-
Hardware Auto Flow Control (cts_n/rts_n signals)	Yes	Yes
DMA Extra (configurable support for extra DMA sideband signal)	Yes	Yes
Stick parity/Force parity	Yes	-

Note: When a feature is both Generate time and Run time configurable, the feature must be enabled during Generate time before Run time configuration can be used. Therefore, turning ON a feature during Generate time is a prerequisite to enabling/disabling it during run time.

10.2.1. Unsupported Features

Unsupported Features vs PC16550D:

Separate receive clock
Baud clock reference output

10.2.2. Interface

The Soft UART will have the following signal interface, exposed using _hw.tcl through Platform Designer software.

Table 55. Clock and Reset Signal Interface
Pin Name	Direction	Description
`clk`	Input	Avalon^® clock sink
`rst_n`	Input	Avalon^® reset sink Asynchronous assert, Synchronous deassert active low reset. Interconnect fabric expected to perform synchronization – UART and interconnect is expected to be placed in the same reset domain to simplify system design

Table 56. Avalon^® -MM Slave
Pin Name	Width	Direction	Description
`addr`	9	Input	Avalon^® -MM Address bus Highest addressable byte address is 0x118 so a 9-bit width is required
`read`		Input	Avalon^® -MM Read indication
`readdata`	32	Output	Avalon^® -MM Read Data Response from the slave
`write`		Input	Avalon^® -MM Write indication
`writedata`	32	Input	Avalon^® -MM Write Data

Table 57. Interrupt Interface
Pin Name	Direction	Description
`intr`	Output	Interrupt signal

Table 58. Flow Control
Pin Name	Direction	Description
`sin`	Input	Serial Input from external link.
`sout`	Output	Serial Output to external link.
`sout_oe`	Output	Output enable for Serial Output to external link. `sout_oe` signal will be high when the UART is transmitting and low when the UART is IDLE.

Table 59. Modem Control and Status
Pin Name	Direction	Description
`cts_n`	Input	Clear to Send
`rts_n`	Output	Request to Send
`dsr_n`	Input	Data Set Ready
`dcd_n`	Input	Data Carrier Detect
`ri_n`	Input	Ring Indicator
`dtr_n`	Output	Data Terminal Ready
`out1_n`	Output	User Designated Output1
`out2_n`	Output	User Designated Output2

Table 60. DMA Sideband Signals
Pin Name	Direction	Description
`dma_tx_ack_n`	Input	TX DMA acknowledge
`dma_rx_ack_n`	Input	RX DMA acknowledge
`dma_tx_req_n`	Output	TX DMA request
`dma_rx_req_n`	Output	RX DMA request
`dma_tx_single_n`	Output	TX DMA single request
`dma_rx_single_n`	Output	RX DMA single request

10.2.3. General Architecture

Figure 31. Soft-UART High Level Architecture

The figure above shows the high level architecture of the UART IP. Both Transmit and Receive logic have their own dedicated control & data path. An interrupt block and clock generator block is also present to service both transmit and receive logic.

10.2.4. 16550 UART General Programming Flow Chart

The 16550 UART general programming flow chart is the recommended flow for setting up the UART for error free operation.

Note: You are free to change this flow to fit your own usage model but the changes might cause undefined results.

Figure 32. 16550 UART Configuration Flow

For more information on the register descriptions used in the flow chart, refer to the "Address Map and Register Descriptions" section.

10.2.5. Configuration Parameters

The table below shows all the parameters that can be used to configure the UART. (_hw.tcl) is the mechanism used to enforce and validate correct parameter settings.

Table 61. Configuration Parameters
Parameter Name	Description	Default
`MEM_BLOCK_TYPE`	Set memory block type of FIFO. Available memory block depend on device family used. `FIFO_MODE` must be 1	AUTO
`FIFO_MODE`	1 = FIFO mode enabled 0 = FIFO mode disabled	1
`FIFO_DEPTH`	Set depth of FIFO Values limited to 32, 64, 128, and 256 `FIFO_MODE` must be 1	128
`FIFO_HWFC`	1 = Enabled hardware flow control 0 = Disabled hardware flow control Mutually exclusive with `FIFO_SWFC` `FIFO_MODE` must be 1	1
`DMA_EXTRA`	1 = Additional DMA interface enabled 0 = Additional DMA interface disabled	0

10.2.6. DMA Support

The DMA interface (DMA_EXTRA) is disabled by default. It must be enabled in the IP to have the additional DMA_Handshaking_tx and DMA_Handshaking_rx interfaces. DMA support is only available when used with the HPS DMA controller. The HPS DMA controller has the required handshake signals to control DMA data transfers with the IP through the DMA_Handshaking_tx and DMA_Handshaking_rx interfaces. The DMA handshaking interfaces are connected to the HPS through the f2h DMA request lines.

Figure 33. Intel FPGA 16550 UART's DMA Handshaking Interfaces Connection to Arria^® V/ Cyclone^® V HPS in Platform Designer

For more information about the HPS DMA Controller handshake signals, refer to the DMA Controller chapter in the Cyclone^® V Device Handbook, Volume 3.

10.2.7. FPGA Resource Usage

In order to optimize resource usage, in terms of register counts, the UART IP design specifically targets MLABs to be used as FIFO storage element. The following table lists the FPGA resources required for one UART with 128 Byte Tx and Rx FIFO.

Table 62. UART Resource Usage
Resource	Number
ALMS needed	362
Total LABs	54
Combinational ALUT usage for logic	436
Combinational ALUT usage for route-throughs	17
Dedicated logic registers Design implementation registers (294) Routing optimization registers (17)	311
Global Signals	2
M10k blocks	0
Total MLAB memory bits	2432

10.2.8. Timing and Fmax

Figure 34. Maximum Delays on UART

The diagram above shows worst case combinatorial delays throughout the UART IP Core. These estimates are provided by Timing Analyzer under the following condition:

Device Family: Series V and above
Avalon^® Master connected to Avalon^® Slave port of the UART with outputs from the Avalon^® Master registered
RS-232 Serial Interface is exported to FPGA Pin
Clocks for entire system set at 125 MHz

Based on the conditions above the UART IP has an Fmax value of 125 MHz, with the worst delay being internal register-to-register paths.

The UART has combinatorial logic on both the Input and Output side, with system level implications on the Input side.

The Input side combinatorial logic (with 7ns delay) goes through the Avalon^® address decode logic, to the Read data output registers. It is therefore recommended that Masters connected to the UART IP register their output signals.

The Output side combinatorial logic (with 2ns delay) goes through the RS-232 Serial Output. There should not be any concern on the output side delays though – as it is not a single cycle path. Using the highest clock divider value of 1, the serial output only toggles once every 16 clocks. This naturally gives a 16 clock multi-cycle path on the output side. Furthermore, divider of 1 is an unlikely system, if the UART is clocked at 125 MHz, the resulting baud rate would be 7.81 Mbps.

10.2.9. Avalon -MM Slave

The Avalon^® -MM Slave has the following configuration:

Table 63. Avalon^® -MM Slave Configuration
Feature	Configuration
Bus Width	32-bit
Burst Support	No burst support. Interconnect is expected to handle burst conversion
Fixed read and write wait time	0 cycles
Fixed read latency	1 cycle
Fixed write latency	0 cycles
Lock support	No

Note: The Avalon^® -MM interface is intended to be a thin, low latency layer on top of the registers.

10.2.9.1. Read behavior

Figure 35. Reading UART over Avalon^® -MM

Reads are expected to have 2 types of behavior:

When status registers are being polled, Reads are expected to be done in singles
When data needs to be read out from the Rx FIFO, Reads are expected as back-to-back cycles to the same address (these back-to-back reads are likely generated as Fixed Bursts in AXI – but translated into INCR with length of 1 by FPGA interconnect)

10.2.9.2. Write behavior

Figure 36. Writing to UART over Avalon^® -MM

Writes to the UART are expected as singles during setup phase of any transaction and as back-to-back writes to the same address when the Tx FIFO needs to be filled.

10.2.10. Over-run/Under-run Conditions

Consistent with UART implementation in PC16550D, the soft UART will not implement over-run or under-run prevention on the Avalon^® -MM interface.

Preventing over-runs and under-runs on the Avalon^® -MM interface by back-pressuring a pending transaction may cause more harm than good as the interconnect can be held up by the far slower UART.

10.2.10.1. Overrun

On receive path, interrupts can be triggered (when enabled) when overrun occurs. In FIFO-less mode, overrun happens when an existing character in the receive buffer is overwritten by a new character before it can be read. In FIFO mode, overrun happens when the FIFO is full and a complete character arrives at the receive buffer.

On transmit path, software driver is expected to know the Tx FIFO depth and not overrun the UART.

10.2.10.2. Receive Overrun Behavior

When receive overrun does happen, the Soft-UART handles it differently depending on FIFO mode. With FIFO enabled, the newly receive data at the shift register is lost. With FIFO disabled, the newly received data from the shift register is written onto the Receive Buffer. The existing data in the Receive Buffer is overwritten. This is consistent with published PC16550D UART behavior.

10.2.10.3. Transmit Overrun Behavior

When the host CPU forcefully triggers a transmit Overrun, the Soft-UART handles it differently depending on FIFO mode. With FIFO enabled, the newly written data is lost. With FIFO disabled, the newly written data will overwrite the existing data in the Transmit Holding Register.

10.2.10.4. Underrun

No mechanisms exist to detect or prevent under-run.

On transmit path, an interrupts (when enabled) can be generated when the transmit holding register is empty or when the transmit FIFO is below a programmed level.

On receive path, the software driver is expected to read from the UART receive buffer (FIFO-less) or the Rx FIFO based on interrupts (when enabled) or status registers indicating presence of receive data (Data Ready bit, LSR[0]). If reads to Receive Buffer Register is triggered with data ready register being zero, undefined read data is returned.

10.2.11. Hardware Auto Flow-Control

Hardware based auto flow-control uses 2 signals (cts_n & rts_n) from the Modem Control/Status group. With Hardware auto flow-control disabled, these signals will directly drive the Modem Status register (cts_n) or be driven by the Modem Control register (rts_n).

With auto flow-control enabled, these signals perform flow-control duty with another UART at the other end.

The cts_n input is, when active (low state), will allow the Tx FIFO to send data to the transmit buffer. When cts_n is inactive (high state), the Tx FIFO stops sending data to the transmit buffer. cts_n is expected to be connected to the rts_n output of the other UART.

The rts_n output will go active (low state), when the Rx FIFO is empty, signaling to the opposite UART that it is ready for data. The rts_n output goes inactive (high state) when the Rx FIFO level is reached, signaling to the opposite UART that the FIFO is about to go full and it should stop transmitting.

Due to the delays within the UART logic, one additional character may be transmitted after cts_n is sampled active low. For the same reason, the Rx FIFO will accommodate up to 1 additional character after asserting rts_n (this is allowed because Rx FIFO trigger level is at worst, two entries from being truly full). Both are observed to prevent overflow/underflow between UARTs.

Figure 37. Hardware Auto Flow-Control Between two UARTs

10.2.12. Clock and Baud Rate Selection

The Soft-UART supports only one clock. The same clock is used on the Avalon^® -MM interface and will be used to generate the baud clock that drives the serial UART interface.

The baud rate on the serial UART interface is set using the following equation:

Baud Rate = Clock/(16 x Divisor)

The table below shows how several typical baud rates can be achieved by programming the divisor values in Divisor Latch High and Divisor Latch Low register.

Table 64. UART Clock Frequency, Divider value and Baud Rate Relationship
	18.432 MHz		24 MHz		50 MHz
Baud Rate	Divisor for 16x clock	% Error (baud)	Divisor for 16x clock	% Error (baud)	Divisor for 16x clock	% Error (baud)
9,600	120	0.00%	156	0.16%	326	-0.15%
38,400	30	0.00%	39	0.16%	81	0.47%
115,200	10	0.00%	13	0.16%	27	0.47%

10.3. Software Programming Model

10.3.1. Overview

The following describes the programming model for the Intel FPGA compatible 16550 Soft-UART.

10.3.2. Supported Features

For the following features, the 16550 Soft-UART HAL driver can be configurable in run time or generate time. For run-time configuration, users can use “altera_16550_uart_config” API . Generate time is during Platform Designer generation, that is to say once FIFO Depth is selected the depth for the FIFO can’t be change anymore.

Table 65. Supported Features
Features	Run Time	Generate Time
FIFO/ FIFO-less mode	Yes	Yes
FIFO Depth	-	Yes
Programmable Tx/Rx FIFO Threshold	Yes	-
5-9 bit character length	Yes	-
1, 1.5, 2 character stop bit	Yes	-
Parity enable	Yes	-
Even/Odd parity	Yes	-
Stick parity	Yes	-
Baud rate selection	Yes	-
Priority based interrupt with configurable enable	Yes	-
Hardware Auto Flow Control	Yes	Yes

10.3.3. Unsupported Features

The 16550 UART driver does not support Software flow control.

10.3.4. Configuration

The figure below shows the Platform Designer setup on the 16550 Soft-UART's FIFO Depth

Figure 38. Platform Designer Setting to Configure FIFO Depth

10.3.5. 16550 UART API

10.3.5.1. Public APIs

Table 66. altera_16550_uart_open
Prototype:	altera_16550_uart_state* altera_16550_uart_open (const char *name);
Include:	<altera_16550_uart.h>
Parameters:	name—the 16550 UART device name to open.
Returns:	Pointer to 16550 UART or NULL if fail to open
Description	Open 16550 UART device.

Table 67. altera_16550_uart_close
Prototype:	int altera_16550_uart_close(altera_16550_uart_state* sp, int flags);
Include:	<altera_16550_uart.h>
Parameters:	sp—the 16550 UART device name to close. flags—for indicating blocking/non-blocking access for single/multi threaded.
Returns:	None
Description:	Closes 16550 UART device.

Table 68. altera_16550_uart_read
Prototype:	int altera_16550_uart_read(altera_16550_uart_state* sp, wchar_t* ptr, int len, int flags);
Include:	<altera_16550_uart.h>
Parameters:	sp - The UART device ptr – destination address len – maximum length of the data flags – for indicating blocking/non-blocking access for single/multi threaded
Returns:	Number of bytes read
Description:	Read data to the UART receiver buffer. UART required to be in a known settings prior executing this function

Table 69. altera_16550_uart_write
Prototype:	int altera_16550_uart_write(altera_16550_uart_state* sp, const wchar_t* ptr, int len, int flags);
Include:	<altera_16550_uart.h>
Parameters:	sp - The UART device ptr – source address len – maximum length of the data flags – for indicating blocking/non-blocking access for single/multi threaded
Returns:	Number of bytes written
Description:	Writes data to the UART transmitter buffer. UART required to be in a known settings prior executing this function

Table 70. alt_16550_uart_config
Prototype:	alt_u32 alt_16550_uart_config(altera_16550_uart_state* sp, UartConfig *setting);
Include:	<altera_16550_uart.h>
Parameters:	sp - The UART device setting – UART configuration structure to configure UART (refer to UART device structure)
Returns:	Return 0 for success otherwise fail
Description:	Configure UART per user input before initiating read or write

10.3.5.2. Private APIs

Table 71. altera_16550_uart_irq
Prototype:	static void altera_16550_uart_irq (void* context)
Include:	<altera_16550_uart.h>
Parameters:	context – device of the UART
Returns:	none
Description:	Interrupt handler to process UART interrupts to process receiver/transmit interrupts.

Table 72. altera_16550_uart_rxirq
Prototype:	void altera_16550_uart_rxirq(altera_16550_uart_state* sp)
Include:	<altera_16550_uart.h>
Parameters:	sp – UART device
Returns:	none
Description:	Process a receive interrupt. It transfers the incoming character into the receiver circular buffer, and sets the appropriate flags to indicate that there is data ready to be processed.

Table 73. altera_16550_uart_txirq
Prototype:	void altera_16550_uart_txirq(altera_16550_uart_state* sp)
Include:	<altera_16550_uart.h>
Parameters:	sp – UART device
Returns:	none
Description:	Process a transmit interrupt. It transfers data from the transmit buffer to the device, and sets the appropriate flags to indicate that there is data ready to be processed.

10.3.5.3. UART Device Structure

UART Device Structure 1

typedef enum stopbit { STOPB_1 = 0,STOPB_2 } StopBit;
typedef enum paritybit { ODD_PARITY = 0, EVEN_PARITY, MARK_PARITY, SPACE_PARITY, NO_PARITY } ParityBit;
typedef enum databit { CS_5 = 0, CS_6, CS_7, CS_8, CS_9 = 256} DataBit;
typedef enum baud
{
BR9600 = B9600,
BR19200 = B19200,
BR38400 = B38400,
BR57600 = B57600,
BR115200 = B115200
} Baud;
typedef enum rx_fifo_level_e { RXONECHAR = 0, RXQUARTER, RXHALF, RXFULL } Rx_FifoLvl;
typedef enum tx_fifo_level_e { TXEMPTY = 0, TXTWOCHAR, TXQUARTER, TXHALF } Tx_FifoLvl;
typedef struct uart_config_s
{
StopBit stop_bit;
ParityBit parity_bit;
DataBit data_bit;
Baud baudrate;
alt_u32 fifo_mode;
Rx_FifoLvl rx_fifo_level;
Tx_FifoLvl tx_fifo_level;
alt_u32 hwfc;
} UartConfig;

UART Device Structure 2

typedef struct altera_16550_uart_state_s
{ 
alt_dev dev; 
void* base; /* The base address of the device */ 
alt_u32 clock; 
alt_u32 hwfifomode; 
alt_u32 ctrl; /* Shadow value of the LSR register */ 
volatile alt_u32 rx_start; /* Start of the pending receive data */ 
volatile alt_u32 rx_end; /* End of the pending receive data */ 
volatile alt_u32 tx_start; /* Start of the pending transmit data */ 
volatile alt_u32 tx_end; /* End of the pending transmit data */ 
alt_u32 freq; /* Current clock freq rate */ 
UartConfig config; /* Uart setting */ 
#ifdef ALTERA_16550_UART_USE_IOCTL 
struct termios termios; 
#endif 
alt_u32 flags; /* Configuration flags */ 
ALT_FLAG_GRP (events) /* Event flags used for 
* foreground/background in mult-threaded 
* mode */ 
ALT_SEM (read_lock) /* Semaphore used to control access to the 
* read buffer in multi-threaded mode */ 
ALT_SEM (write_lock) /* Semaphore used to control access to the 
* write buffer in multi-threaded mode */ 
volatile wchar_t rx_buf[ALT_16550_UART_BUF_LEN]; /* The receive buffer */ 
volatile wchar_t tx_buf[ALT_16550_UART_BUF_LEN]; /* The transmit buffer */ 
line_status_reg line_status; /* line register status for the current read byte data of RBR or data at the top of FIFO*/ 
alt_u8 error_ignore; /* received data will be discarded 
for the current read byte data of RBR or data at the top of FIFO if pe, fe and bi errors detected after error_ignore is set to '0' */ 
} altera_16550_uart_state;

10.3.6. Driver Examples

Below is a simple test program to verify that the Intel FPGA 16550 UART driver support is functional.

The test reads, validates, and writes a modified baud rate, data bits, stop bits, parity bits to the UART before attempting to write a character stream to it from UART0 to UART1 and vice verse (ping pong test). This also tests the FIFO and FIFO-less mode to ensure the IP is functioning for FIFO.

Prerequisites needed before running test:

An instance of UART named "a_16550_uart_0" and another instance UART named "a_16550_uart_1".
Both UARTs need to be connected in loopback in Intel^® Quartus^® Prime software.

Additional coverage:

Non-blocking UART support
UART HAL driver
HAL open/write support

The test will print "ALL TESTS PASS" from the UART to indicate success.

Verifying Intel FPGA 16550 UART Driver Support functionality

#include <stdio.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/termios.h>
#include <fcntl.h>
#include <string.h>
#include <unistd.h>
#include <sys/time.h>
#include <time.h>
#include "system.h"
#include "altera_16550_uart.h"
#include "altera_16550_uart_regs.h"
#include <wchar.h>

#define ERROR -1
#define SUCCESS 0
#define MOCK_UART
#define BUFSIZE 512
wchar_t TXMessage[BUFSIZE] = L"Hello World";
wchar_t RXMessage[BUFSIZE] = L"";

int UARTDefaultConfig(UartConfig *Config)
{
  Config->stop_bit     = STOPB_1;
  Config->parity_bit   = NO_PARITY;
  Config->data_bit     = CS_8;
  Config->baudrate     = BR115200;
  Config->fifo_mode    = 0;
  Config->hwfc         = 0;
  Config->rx_fifo_level= RXFULL;
  Config->tx_fifo_level= TXEMPTY;
  return 0;
}

int UARTBaudRateTest()
{
  UartConfig *UART0_Config = malloc(1*sizeof(UartConfig));
  UartConfig *UART1_Config = malloc(1*sizeof(UartConfig));

  int i=0, j=0, direction=0, Match=0;
  const int nBaud = 5;
  int BaudRateCoverage[]= {BR9600, BR19200, BR38400, BR57600, BR115200};
  altera_16550_uart_state* uart_0;
  altera_16550_uart_state* uart_1;

  printf("============ UART Baud Rate Test Starts Here ===============\n");
  uart_0 = altera_16550_uart_open ("/dev/a_16550_uart_0");
  uart_1 = altera_16550_uart_open ("/dev/a_16550_uart_1");

  for (direction=0; direction<2; direction++)
  {
	  for (i=0; i<nBaud; i++)
		  {
  			UARTDefaultConfig(UART0_Config);
			UARTDefaultConfig(UART1_Config);
		    UART0_Config->baudrate=BaudRateCoverage[i];
		    UART1_Config->baudrate=BaudRateCoverage[i];
			printf("Testing Baud Rate: %d\n", UART0_Config->baudrate);
		    if(ERROR == alt_16550_uart_config (uart_0, UART0_Config)) return ERROR;
		    if(ERROR == alt_16550_uart_config (uart_1, UART1_Config)) return ERROR;

	        switch(direction)
			{
			 case 0:
			    printf("Ping Pong Baud Rate Test: UART#0 to UART#1\n");
				for(j=0; j<wcslen(TXMessage); j++)
				{
					altera_16550_uart_write(uart_0, &TXMessage[j], 1, 0);
					usleep(1000);
					if(ERROR== altera_16550_uart_read(uart_1,  RXMessage, 1, 0)) return ERROR;
					if(TXMessage[j]==RXMessage[0]) Match=1; else return ERROR;
					printf("Sent:'%c', Received:'%c', Match:%d\n", TXMessage[j], RXMessage[0], Match);
				}
				break;
			 case 1:
			    printf("Ping Pong Baud Rate Test: UART#1 to UART#0\n");
				for(j=0; j<wcslen(TXMessage); j++)
				{
					altera_16550_uart_write(uart_1, &TXMessage[j], 1, 0);
					usleep(1000);
					if(ERROR== altera_16550_uart_read(uart_0,  RXMessage, 1, 0)) return ERROR;
					if(TXMessage[j]==RXMessage[0]) Match=1; else return ERROR;
					printf("Sent:'%c', Received:'%c', Match:%d\n", TXMessage[j], RXMessage[0], Match);
				}
				break;
			 default:
			 	break;
			}
			usleep(1000);
		  }
  }
  free(UART0_Config);
  free(UART1_Config);
  return SUCCESS;
}

int UARTLineControlTest()
{
  UartConfig *UART0_Config = malloc(1*sizeof(UartConfig));
  UartConfig *UART1_Config = malloc(1*sizeof(UartConfig));

  int x=0, y=0, z=0, Match=0;
  const int nDataBit = 2, nParityBit=3, nStopBit=2;
  int DataBitCoverage[]= { /*CS_5, CS_6,*/ CS_7, CS_8};
  int ParityBitCoverage[]= {ODD_PARITY, EVEN_PARITY, NO_PARITY};
  int StopBitCoverage[]= {STOPB_1, STOPB_2};
  altera_16550_uart_state* uart_0;
  altera_16550_uart_state* uart_1;

  printf("================================ UART Line Control Test Starts Here =======================================\n");
  uart_0 = altera_16550_uart_open ("/dev/a_16550_uart_0");
  uart_1 = altera_16550_uart_open ("/dev/a_16550_uart_1");

  for(x=0; x<nStopBit; x++)
  {
	  for (y=0; y<nParityBit; y++)
	  {
		  for (z=0; z<nDataBit; z++)
			  {
	  			UARTDefaultConfig(UART0_Config);
				UARTDefaultConfig(UART1_Config);
			    UART0_Config->stop_bit=StopBitCoverage[x];
			    UART1_Config->stop_bit=StopBitCoverage[x];
			    UART0_Config->parity_bit=ParityBitCoverage[y];
			    UART1_Config->parity_bit=ParityBitCoverage[y];
			    UART0_Config->data_bit=DataBitCoverage[z];
			    UART1_Config->data_bit=DataBitCoverage[z];

				printf("Testing : Stop Bit=%d, Data Bit=%d, Parity Bit=%d\n", UART0_Config->stop_bit, UART0_Config->data_bit, UART0_Config->parity_bit);
			    if(ERROR == alt_16550_uart_config (uart_0, UART0_Config)) return ERROR;
			    if(ERROR == alt_16550_uart_config (uart_1, UART1_Config)) return ERROR;
				altera_16550_uart_write(uart_0, &TXMessage[0], 1, 0);
				usleep(1000);
				if(ERROR== altera_16550_uart_read(uart_1,  RXMessage, 1, 0)) return ERROR;
				if(TXMessage[0]==RXMessage[0]) Match=1; else
					{
					printf("Sent:'%c', Received:'%c', Match:%d\n", TXMessage[0], RXMessage[0], Match);
					return ERROR;
					}
				printf("Sent:'%c', Received:'%c', Match:%d\n", TXMessage[0], RXMessage[0], Match);
			  }
	  }
  }
  free(UART0_Config);
  free(UART1_Config);
  return SUCCESS;
}

int UARTFIFOModeTest()
{

  UartConfig *UART0_Config = malloc(1*sizeof(UartConfig));
  UartConfig *UART1_Config = malloc(1*sizeof(UartConfig));

  int i=0, direction=0, CharCounter=0, Match=0;
  const int nBaud = 2;
  int BaudRateCoverage[]= {BR115200, /*BR19200, BR38400, BR57600,*/ BR9600};
  altera_16550_uart_state* uart_0;
  altera_16550_uart_state* uart_1;

  printf("================================ UART FIFO Mode Test Starts Here =======================================\n");
  uart_0 = altera_16550_uart_open ("/dev/a_16550_uart_0");
  uart_1 = altera_16550_uart_open ("/dev/a_16550_uart_1");

  for (direction=0; direction<2; direction++)
  {
	  for (i=0; i<nBaud; i++)
		  {
  			UARTDefaultConfig(UART0_Config);
			UARTDefaultConfig(UART1_Config);
		    UART0_Config->baudrate=BaudRateCoverage[i];
		    UART1_Config->baudrate=BaudRateCoverage[i];
			UART0_Config->fifo_mode = 1;
			UART1_Config->fifo_mode = 1;
  			UART0_Config->hwfc = 0;
  			UART1_Config->hwfc = 0;
		    if(ERROR == alt_16550_uart_config (uart_0, UART0_Config)) return ERROR;
		    if(ERROR == alt_16550_uart_config (uart_1, UART1_Config)) return ERROR;
			printf("Testing Baud Rate: %d\n", UART0_Config->baudrate);

	        switch(direction)
			{
			 case 0:
			    printf("Ping Pong FIFO Test: UART#0 to UART#1\n");
				CharCounter=altera_16550_uart_write(uart_0, &TXMessage, wcslen(TXMessage), 0);
				//usleep(50000);
				if(ERROR== altera_16550_uart_read(uart_1,  RXMessage, wcslen(TXMessage), 0)) return ERROR;
				if(strcmp(TXMessage, RXMessage)==0) Match=1; else Match=0;
				printf("Sent:'%s' CharCount:%d, Received:'%s' CharCount:%d, Match:%d\n", TXMessage, CharCounter, RXMessage, wcslen(RXMessage), Match);
				if(Match==0) return ERROR;
				break;
			 case 1:
			    printf("Ping Pong FIFO Test: UART#1 to UART#0\n");
				CharCounter=altera_16550_uart_write(uart_1, &TXMessage, wcslen(TXMessage), 0);
				//usleep(50000);
				if(ERROR== altera_16550_uart_read(uart_0,  RXMessage, wcslen(TXMessage), 0)) return ERROR;
				if(strcmp(TXMessage, RXMessage)==0) Match=1; else Match=0;
				printf("Sent:'%s' CharCount:%d, Received:'%s' CharCount:%d, Match:%d\n", TXMessage, CharCounter, RXMessage, wcslen(RXMessage), Match);
				if(Match==0) return ERROR;
				break;
			 default:
			 	break;
			}
			//usleep(100000);
		  }
  }
  free(UART0_Config);
  free(UART1_Config);
  return SUCCESS;
}

int main()
{
  int result=0;

  result = UARTBaudRateTest();
  if(result==ERROR)
  {
   printf("UARTBaudRateTest FAILED\n");
   return ERROR;
  }

  result = UARTLineControlTest();
  if(result==ERROR)
  {
   printf("UARTLineControlTest FAILED\n");
   return ERROR;
  }

  result = UARTFIFOModeTest();
  if(result==ERROR)
  {
    printf("UARTFIFOModeTest FAILED\n");
	return ERROR;
  }
  printf("\n\nALL TESTS PASS\n\n");
  return 0;
}

10.4. Address Map and Register Descriptions

Table 74. altr_uart_csr Address Map
Register	Offset	Width	Access	Reset Value	Description
`rbr_thr_dll`	0x0	32	RW	0x00000000	Rx Buffer, Tx Holding, and Divisor Latch Low
`ier_dlh`	0x4	32	RW	0x00000000	Interrupt Enable and Divisor Latch High
`iir`	0x8	32	R	0x00000001	Interrupt Identity Register (when read)
`fcr`	0x8	32	W	0x00000000	FIFO Control (when written)
`lcr`	0xC	32	RW	0x00000000	Line Control Register
`mcr`	0x10	32	RW	0x00000000	Modem Control Register
`lsr`	0x14	32	R	0x00000060	Line Status Register
`msr`	0x18	32	R	0x00000000	Modem Status Register
`scr`	0x1C	32	RW	0x00000000	Scratchpad Register
`afr`	0x100	32	RW	0x00000000	Additional Features Register
`tx_low`	0x104	32	RW	0x00000000	Transmit FIFO Low Watermark Register

Note: RC-Read to Clear

10.4.1. rbr_thr_dll

Identifier	Title	Offset	Access	Reset Value	Description
`rbr_thr_dll`	Rx Buffer, Tx Holding, and Divisor Latch Low	0x0	RW	0x0000000	This is a multi-function register. This register holds receives and transmit data and controls the least-signficant 8 bits of the baud rate divisor.

Bit Fields
31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16
-
15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
-								rbr_thr_dll

Table 75. rbr_thr_dll Fields
Bit	Name/Identifier	Description	Access	Reset
[31:8]	-	Reserved	R	0x0
[7:0]	`rbr_thr_dll`	Receive Buffer Register: This register contains the data byte received on the serial input port (sin). The data in this register is valid only if the Data Ready (LSR[0] is set to 1). If FIFOs are disabled (FCR[0] is cleared to 0) the data in the RBR must be read before the next data arrives, otherwise it will be overwritten, resulting in an overrun error. If FIFOs are enabled (FCR[0] set to 1) this register accesses the head of the receive FIFO. If the receive FIFO is full, and this register is not read before the next data character arrives, then the data already in the FIFO will be preserved but any incoming data will be lost. An overrun error will also occur. Transmit Holding Register: This register contains data to be transmitted on the serial output port (sout). Data should only be written to the THR when the THR Empty bit (LSR[5] is set to 1). If FIFOs are disabled (FCR[0] is set to 0) and THRE is set to 1, writing a single character to the THR clears the THRE. Any additional writes to the THR before the THRE is set again causes the THR data to be overwritten. If FIFO's are enabled (FCR[0] is set to 1) and THRE is set, the FIFO can be filled up to a pre-configured depth (FIFO_DEPTH). Any attempt to write data when the FIFO is full results in the write data being lost. Divisor Latch Low: This register makes up the lower 8-bits of a 16-bit, Read/write, Divisor Latch register that contains the baud rate divisor for the UART. This register may only be accessed when the DLAB bit (LCR[7] is set to 1). The output baud rate is equal to the system clock (clk) frequency divided by sixteen times the value of the baud rate divisor, as follows: baud rate = (system clock freq) / (16 * divisor) Note: With the Divisor Latch Registers (DLL and DLH) set to zero, the baud clock is disabled and no serial communications will occur. Also, once the DLL is set, at least 8 system clock cycles should be allowed to pass before transmitting or receiving data.	RW	0x00

10.4.2. ier_dlh

Identifier

Title

Offset

Access

Reset Value

Description

ier_dlh

Interrupt Enable and Divisor Latch High

0x4

0x00000000

The ier_dlh (Interrupt Enable Register) may only be accessed when the DLAB bit [7] of the LCR Register is set to 0. Allows control of the Interrupt Enables for transmit and receive functions.This is a multi-function register. This register enables/disables receive and transmit interrupts and also controls the most-significant 8-bits of the baud rate divisor.

The Divisor Latch High Register is accessed when the DLAB bit (LCR[7] is set to 1). Bits[7:0] contain the high order 8-bits of the baud rate divisor. The output baud rate is equal to the system clock (clk) frequency divided by sixteen times the value of the baud rate divisor, as follows:

baud rate = (system clock freq) / (16 * divisor)

Note: With the Divisor Latch Registers (DLL and DLH) set to zero, the baud clock is disabled and no serial communications will occur. Also, once the DLL is set, at least 8 system clock cycles should be allowed to pass before transmitting or receiving data.

Bit Fields
31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16
-
15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
-								dlh7_4				edssi_dhl3	elsi_dhl2	etbei_dlh1	erbfi_dlh0

Table 76. ier_dlh Fields
Bit	Name/Identifier	Description	Access	Reset
[31:8]	-	Reserved	R	0x0
[7:4]	DLH[7:4] (`dlh7_4`)	Divisor Latch High Register: Bit 4, 5, 6 and 7 of DLH value.	RW	0x0
[3]	DLH[3] and Enable Modem Status Interrupt (`edssi_dhl3`)	Divisor Latch High Register: Bit 3 of DLH value. Interrupt Enable Register: This is used to enable/disable the generation of Modem Status Interrupts. This is the fourth highest priority interrupt.	RW	0x0
[2]	DLH[2] and Enable Receiver Line Status (`elsi_dhl2`)	Divisor Latch High Register: Bit 2 of DLH value. Interrupt Enable Register: This is used to enable/disable the generation of Receiver Line Status Interrupt. This is the highest priority interrupt	RW	0x0
[1]	DLH[1] and Transmit Data Interrupt Control (`etbei_dlh1`)	Divisor Latch High Register: Bit 1 of DLH value. Interrupt Enable Register: Enable Transmit Holding Register Empty Interrupt. This is used to enable/disable the generation of Transmitter Holding Register Empty Interrupt. This is the third highest priority interrupt.	RW	0x0
[0]	DLH[0] and Receive Data Interrupt Enable (`erbfi_dlh0`)	Divisor Latch High Register: Bit 0 of DLH value. Interrupt Enable Register: This is used to enable/disable the generation of the Receive Data Available Interrupt and the Character Timeout Interrupt (if FIFO's enabled). These are the second highest priority interrupts.	RW	0x0

10.4.3. iir

Identifier	Title	Offset	Access	Reset Value	Description
`iir`	Interrupt Identity Register	0x8	R	0x00000001	Returns interrupt identification and FIFO enable/disable when read.

Bit Fields
31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16
-
15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
-								fifose		-		id

Table 77. iir Fields
Bit	Name/Identifier	Description	Access	Reset
[31:8]	-	Reserved	R	0x0
[7:6]	FIFOs Enabled (`fifose`)	The FIFOs Enabled is used to indicate whether the FIFO's are enabled or disabled.	R	0x0
[5:4]	-	Reserved	R	0x0
[3:0]	Interrupt ID (`id`)	The Interrupt ID indicates the highest priority pending interrupt. Refer to the Table 78 table below for more details.	R	0x1

Table 78. Interrupt Priority
IIR ID	Interrupt	Priority
4'b0000	Modem status	5th
4'b0001	No interrupt pending	6th
4'b0010	THR empty (reflect TX_Low empty threshold if ARF[0] is '1)	4th
4'b0100	Received data available	2nd
4'b0110	Receiver line status	1st
4'b1100	Character timeout	3rd

10.4.4. fcr

Identifier	Title	Offset	Access	Reset Value	Description
`fcr`	FIFO Control	0x8	W	0x00000000	Controls FIFO operation when written.

Bit Fields
31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16
-
15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
-								rt		-		dmam	xfifor	rfifor	fifoe

Table 79. fcr Fields
Bit	Name/Identifier	Description	Access	Reset
[31:8]	-	Reserved	R	0x0
[7:6]	Rx Trigger Level (`rt`)	This register is configured to implement FIFOs RxTrigger (or RT). This is used to select the trigger level in the receiver FIFO at which the Received Data Available Interrupt will be generated. In auto flow control mode it is used to determine when the rts_n signal will be de-asserted The following trigger levels are supported: 00 - One character in FIFO 01 - FIFO 1/4 full 10 - FIFO 1/2 ful 11 - FIFO two less than full	W	0x0
[5:4]	-	Reserved	R	0x0
[3]	DMA Mode (`dmam`)	This determines the DMA signaling mode used for the `uart_dma_tx_req_n` and `uart_dma_rx_req_n` output signals when additional DMA handshaking signals are not selected. DMA mode 0 supports single DMA data transfers at a time. In mode 0, the `uart_dma_tx_req_n` signal goes active low under the following conditions: When the Transmitter Holding Register is empty in non-FIFO mode. When the transmitter FIFO is empty in FIFO mode. It goes inactive under the following conditions: When a single character has been written into the Transmitter Holding Register or transmitter FIFO. When the transmitter FIFO is above the threshold. DMA mode 1 supports multi-DMA data transfers, where multiple transfers are made continuously until the receiver FIFO has been emptied or the transmit FIFO has been filled. In mode 1 the `uart_dma_tx_req_n` signal is asserted under the following condition: When the transmitter FIFO is empty.	W	0x0
[2]	Tx FIFO Reset (`xfifor`)	This bit resets the control portion of the transmit FIFO and treats the FIFO as empty. Note that this bit is 'self-clearing' and it is not necessary to clear this bit. Please allow for 8 clock cycles to pass after changing this register bit before reading from RBR or writing to THR.	W	0x0
[1]	Rx FIFO Reset (`rfifor`)	Resets the control portion of the receive FIFO and treats the FIFO as empty. Note that this bit is self-clearing' and it is not necessary to clear this bit. Allow for 8 clock cycles to pass after changing this register bit before reading from RBR or writing to THR.	W	0x0
[0]	FIFO Enable (`fifoe`)	This bit enables/disables the transmit (Tx) and receive (Rx ) FIFO's. Whenever the value of this bit is changed both the Tx and Rx controller portion of FIFO's will be reset. Any existing data in both Tx and Rx FIFO will be lost when this bit is changed. Please allow for 8 clock cycles to pass after changing this register bit before reading from RBR or writing to THR.	W	0x0

10.4.5. lcr

Identifier	Title	Offset	Access	Reset Value	Description
`lcr`	Line Control Register	0xC	RW	0x00000000	Formats serial data.

Bit Fields
31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16
-
15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
-							dls9	dlab	break	sp	eps	pen	stop	dls

Table 80. lcr Fields Description

Bit

Name/Identifier

Description

Access

Reset

[31:9]

Reserved

0x0

[8]

Data Length Select (dls9)

Issue 1'b1 to LCR[8] and 2'b00 to LCR[1:0] to turn on 9 data bits per character that the peripheral will transmit and receive.

0x0

[7]

Divisor Latch Access Bit (dlab)

This is used to enable reading and writing of the Divisor Latch register (DLL and DLH) to set the baud rate of the UART. This bit must be cleared after initial baud rate setup in order to access other registers.

0x0

[6]

Break Control Bit (break)

This is used to cause a break condition to be transmitted to the receiving device. If set to one the serial output is forced to the spacing (logic 0) state until the Break bit is cleared.

0x0

[5]

Stick Parity (sp)

The SP bit works in conjunction with the EPS and PEN bits. When odd parity is selected (EPS = 0), the PARITY bit is transmitted and checked as set. When even parity is selected (EPS = 1), the PARITY bit is transmitted and checked as cleared.

0x0

[4]

Even Parity Select (eps)

This is used to select between even and odd parity, when parity is enabled (PEN set to one). If set to one, an even number of logic '1's is transmitted or checked. If set to zero, an odd number of logic '1's is transmitted or checked.

0x0

[3]

Parity Enable (pen)

This bit is used to enable and disable parity generation and detection in a transmitted and received data character.

0x0

[2]

Stop Bits (stop)

Number of stop bits. This is used to select the number of stop bits per character that the peripheral will transmit and receive. Note that regardless of the number of stop bits selected the receiver will only check the first stop bit.

Data Bits	LCR[2] = 0	LCR[2] = 1
5	1	1.5
6	1	2
7	1	2
8	1	2

If bit 2 is a logic 0, one stop bit is generated in the transmitted data.
If bit 2 is a logic 1 when a 5-bit word length is selected through bits 0 and 1, one and a half stop bits are generated.
If bit 2 is a logic 1 when either a 6-, 7-, or 8-bit word length is selected, two stop bits are generated.

The Receiver checks the first stop-bit only, regardless of the number of stop bits selected.

0x0

[1:0]

Data Length Select (dls)

Selects the number of data bits per character that the peripheral will transmit and receive.

0 - 5 data bits per character
1 - 6 data bits per character
2 - 7 data bits per character
3 - 8 data bits per character

0x0

10.4.6. mcr

Identifier	Title	Offset	Access	Reset Value	Description
`mcr`	Modem Control Register	0x10	RW	0x00000000	Reports various operations of the modem signals.

Bit Fields
31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16
-
15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
-										afce	loopback	out2	out1	rts	dtr

Table 81. mcr Fields Descriptions
Bit	Name/Identifier	Description	Access	Reset
[31:6]	-	Reserved	R	0x0
[5]	Hardware Auto Flow Control Enable ( `afce`)	When FIFOs are enabled (FCR[0]), the Auto Flow Control enable bits are active. This enabled UART to dynamically assert and deassert `rts_n` based on Receive FIFO trigger level	RW	0x0
[4]	LoopBack Bit (`loopback`)	This is used to put the UART into a diagnostic mode for test purposes. If UART mode is NOT active, bit [6] of the modem control register MCR is set to zero, data on the sout line is held high, while serial data output is looped back to the sin line, internally. In this mode all the interrupts are fully functional. Also, in loopback mode, the modem control inputs (`dsr_n`, `cts_n`, `ri_n`, `dcd_n`) are disconnected and the modem control outputs (`dtr_n`, `rts_n`, `out1_n`, `out2_n`) are looped-back to the inputs, internally.	RW	0x0
[3]	Out2 (`out2`)	This is used to directly control the user-designated `out2_n` output. The value written to this location is inverted and driven out on `out2_n`	RW	0x0
[2]	Out1 (`out1`)	This is used to directly control the user-designated `out1_n`output. The value written to this location is inverted and driven out on `out1_n` pin.	RW	0x0
[1]	Request to Send (`rts`)	This is used to directly control the Request to Send (`rts_n`) output. The Request to Send (`rts_n`) output is used to inform the modem or data set that the UART is ready to exchange data. When Auto RTS Flow Control is not enabled (MCR[5] set to zero), the `rts_n` signal is set low by programming this register to a high. If Auto Flow Control is active (MCR[5] set to 1) and FIFO's enable (FCR[0] set to 1), the rts_n output is controlled in the same way, but is also gated with the receiver FIFO threshold trigger (`rts_n` is inactive high when above the threshold). The `rts_n` signal will be de-asserted when this register is set low.	RW	0x0
[0]	Data Terminal Ready (`dtr`)	This is used to directly control the Data Terminal Ready output. The value written to this location is inverted and driven out on `uart_dtr_n`. The Data Terminal Ready output is used to inform the modem or data set that the UART is ready to establish communications.	RW	0x0

10.4.7. lsr

Identifier	Title	Offset	Access	Reset Value	Description
`lsr`	Line Status Register	0x14	R	0x00000060	Reports status of transmit and receive.

Bit Fields
31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16
-
15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
-								rfe	temt	thre	bi	fe	pe	oe	dr

Table 82. lsr Fields
Bit	Name/ Identifier	Description	Access	Reset
[31:8]	-	Reserved	R	0x0
[7]	Receiver FIFO Error bit (`rfe`)	This bit is only relevant when FIFO's are enabled (FCR[0] set to one). This is used to indicate if there is at least one parity error, framing error, or break indication in the FIFO. This bit is cleared when the LSR is read and the character with the error is at the top of the receiver FIFO and there are no subsequent errors in the FIFO.	R	0x0
[6]	Transmitter Empty bit (`temt`)	If in FIFO mode and FIFO's enabled (FCR[0] set to one), this bit is set whenever the Transmitter Shift Register and the FIFO are both empty. If FIFO's are disabled, this bit is set whenever the Transmitter Holding Register and the Transmitter Shift Register are both empty. Indicator is cleared when new data is written into the THR or Transmit FIFO.	R	0x1
[5]	Transmit Holding Register Empty bit (`thre`)	This bit indicates that the THR or Tx FIFO is empty. This bit is set when data is transferred from the THR or Tx FIFO to the transmitter shift register and no new data has been written to the THR or Tx FIFO. This also causes a THRE Interrupt to execute, if the THRE Interrupt is enabled.	R	0x1
[4]	Break Interrupt (`bi`)	This is used to indicate the detection of a break sequence on the serial input data. Set whenever the serial input, sin, is held in a logic 0 state for longer than the sum of start time + data bits + parity + stop bits. A break condition on serial input causes one and only one character, consisting of all zeros, to be received by the UART. The character associated with the break condition is carried through the FIFO and is revealed when the character is at the top of the FIFO. This bit always stays in sync with the associated character in RBR. If the current associated character is read through RBR, this bit will be updated to be in sync with the next character in RBR. Reading the LSR clears the BI bit.	RC	0x0
[3]	Framing Error (`fe`)	This is used to indicate the occurrence of a framing error in the receiver. A framing error occurs when the receiver does not detect a valid STOP bit in the received data. In the FIFO mode, since the framing error is associated with a character received, it is revealed when the character with the framing error is at the top of the FIFO. When a framing error occurs the UART will try to resynchronize. It does this by assuming that the error was due to the start bit of the next character and then continues receiving the other bit data, and/or parity and stop. It should be noted that the Framing Error (FE) bit(LSR[3]) will be set if a break interrupt has occurred, as indicated by a Break Interrupt BIT bit (LSR[4]). This bit always stays in sync with the associated character in RBR. If the current associated character is read through RBR, this bit will be updated to be in sync with the next character in RBR. Reading the LSR clears the FE bit.	RC	0x0
[2]	Parity Error (`pe`)	This is used to indicate the occurrence of a parity error in the receiver if the Parity Enable (PEN) bit (LCR[3]) is set. Since the parity error is associated with a character received, it is revealed when the character with the parity error arrives at the top of the FIFO. It should be noted that the Parity Error (PE) bit (LSR[2]) will be set if a break interrupt has occurred, as indicated by Break Interrupt (BI) bit (LSR[4]). In this situation, the Parity Error bit is set depending on the combination of EPS (LCR[4]) and DLS (LCR[1:0]). This bit always stays in sync with the associated character in RBR. If the current associated character is read through RBR, this bit will be updated to be in sync with the next character in RBR. Reading the LSR clears the PE bit.	RC	0x0
[1]	Overrun error bit (`oe`)	This is used to indicate the occurrence of an overrun error. This occurs if a new data character was received before the previous data was read. In the non-FIFO mode, the OE bit is set when a new character arrives in the receiver before the previous character was read from the RBR. When this happens, the data in the RBR is overwritten. In the FIFO mode, an overrun error occurs when the FIFO is full and new character arrives at the receiver. The data in the FIFO is retained and the data in the receive shift register is lost.Reading the LSR clears the OE bit.	RC	0x0
[0]	Data Ready bit (`dr`)	This is used to indicate that the receiver contains at least one character in the RBR or the receiver FIFO. This bit is cleared when the RBR is read in the non-FIFO mode, or when the receiver FIFO is empty, in the FIFO mode.	R	0x0

10.4.8. msr

Identifier	Title	Offset	Access	Reset Value	Description
`msr`	Modem Status Register	0x18	R	0x00000000	It should be noted that whenever bits 0, 1, 2 or 3 are set to logic one, to indicate a change on the modem control inputs, a modem status interrupt will be generated if enabled via the IER regardless of when the change occurred. Since the delta bits (bits 0, 1, 3) can get set after a reset if their respective modem signals are active (see individual bits for details), a read of the MSR after reset can be performed to prevent unwanted interrupts.

Bit Fields
31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16
-
15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
-								dcd	ri	dsr	cts	ddcd	teri	ddsr	dcts

Table 83. msr Fields
Bit	Name/Identifier	Description	Access	Reset
[31:8]	-	Reserved	R	0x0
[7]	Data Carrier Detect (`dcd`)	This bit is the complement of the modem control line (`dcd_n`). This bit is used to indicate the current state of `dcd_n`. When the Data Carrier Detect input (`dcd_n`) is asserted it is an indication that the carrier has been detected by the modem or data set.	R	0x0
[6]	Ring Indicator (`ri`)	This bit is the complement of modem control line (`ri_n`). This bit is used to indicate the current state of `ri_n`. When the Ring Indicator input (`ri_n`) is asserted it is an indication that a telephone ringing signal has been received by the modem or data set.	R	0x0
[5]	Data Set Ready (`dsr`)	This bit is the complement of modem control line `dsr_n`. This bit is used to indicate the current state of `dsr_n`. When the Data Set Ready input (`dsr_n`) is asserted it is an indication that the modem or data set is ready to establish communications with the uart.	R	0x0
[4]	Clear to Send (`cts`)	This bit is the complement of modem control line `cts_n`. This bit is used to indicate the current state of `cts_n`. When the Clear to Send input (`cts_n`) is asserted it is an indication that the modem or data set is ready to exchange data with the uart.	R	0x0
[3]	Delta Data Carrier Detect (`ddcd`)	This is used to indicate that the modem control line `dcd_n` has changed since the last time the MSR was read. Reading the MSR clears the DDCD bit. Note: If the DDCD bit is not set and the `dcd_n` signal is asserted (low) and a reset occurs (software or otherwise), then the DDCD bit will get set when the reset is removed if the dcd_n signal remains asserted.	RC	0x0
[2]	Trailing Edge of Ring Indicator (`teri`)	This is used to indicate that a change on the input `ri_n` (from an active low, to an inactive high state) has occurred since the last time the MSR was read. Reading the MSR clears the TERI bit.	RC	0x0
[1]	Delta Data Set Ready (`ddsr`)	This is used to indicate that the modem control line `dsr_n` has changed since the last time the MSR was read. Reading the MSR clears the DDSR bit. Note: If the DDSR bit is not set and the dsr_n signal is asserted (low) and a reset occurs (software or otherwise), then the DDSR bit will get set when the reset is removed if the `dsr_n` signal remains asserted.	RC	0x0
[0]	Delta Clear to Send (`dcts`)	This is used to indicate that the modem control line `cts_n` has changed since the last time the MSR was read. Reading the MSR clears the DCTS bit. Note: If the DCTS bit is not set and the `cts_n` signal is asserted (low) and a reset occurs (software or otherwise), then the DCTS bit will get set when the reset is removed if the `cts_n` signal remains asserted.	RC	0x0

10.4.9. scr

Identifier	Title	Offset	Access	Reset Value	Description
`scr`	Scratchpad Register	0x1C	RW	0x0000000	Scratchpad Register

Bit Fields
31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16
-
15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
-								scr

Table 84. scr Fields
Bit	Name	Description	Access	Reset
[31:8]	-	Reserved	R	0x0
[7:0]	Scratchpad Register (`scr`)	This register is for programmers to use as a temporary storage space.	RW	0x0

10.4.10. afr

Identifier	Title	Offset	Access	Reset Value	Description
`afr`	Additional Features Register	0x100	RW	0x00000000	These registers enable additional features in the soft UART controller. These features are specific to Intel FPGA.

Bit Fields
31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16
-
15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
-															tx_low_en

Table 85. afr Fields
Bit	Name/Identifier	Description	Access	Reset
[31:1]	-	Reserved	R	0x0
[0]	Transmit FIFO Low Watermark Enable Register (`tx_low_en`)	This bit controls the Tx FIFO Low Watermark feature. This feature requires FIFO to be enabled (FCR[0]). When enabled, the UART will send a Transmit Holding Register Empty status interrupt when the Transmit FIFO level is at or below the value stored in `tx_low`. Legal values for `tx_low` can range from zero up to depth of FIFO minus two. UART behavior is undefined when `tx_low` is set to illegal values. 1 - Transmit FIFO Low Watermark is set by `tx_low` 0 - Transmit FIFO Low Watermark is unset This value must only be changed when the Transmit FIFO is empty or before FIFO is enabled (FCR[0]). This register is meant to be changed during UART initialization before active traffic is sent. The Transmit FIFO should be reset using FCR[2] after any changes to this value.	RW	0x0

10.4.11. tx_low

Identifier	Title	Offset	Access	Reset Value	Description
`tx_low`	Transmit FIFO Low Watermark Register	ox104	RW	0x00000000	This register is used to set the value of the Transmit FIFO Low Watermark.

Bit Fields
31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16
-
15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
-							value

Table 86. tx_low Fields
Bit	Name/Identifier	Description	Access	Reset
[31:9]	-	Reserved	R	0x0
[8:0]	Transmit FIFO Low Watermark (`value`)	Set the Transmit FIFO Low Watermark Value. The lowest legal value is zero The highest legal value is two less than the FIFO Depth This value must only be changed when the Transmit FIFO is empty or before FIFO is enabled (FCR[0]).	RW	0x00

10.5. Intel FPGA 16550 Compatible UART Core Revision History

Avalon® -ST Interfaces

Avalon® -MM Interfaces

Control Register Interface

Fill-Level Register Interface

Avalon® -ST Data Interface

Avalon® -MM Control and Status Register Interface

Avalon® -ST Status Interface

Avalon^® -ST Interfaces

Avalon^® -MM Interfaces

Avalon^® -ST Data Interface

Avalon^® -MM Control and Status Register Interface

Avalon^® -ST Status Interface