You can use the Platform Designer GUI to quickly create and customize a Platform Designer system for integration with an Intel^® Quartus^® Prime project. Alternatively, you can perform many of the functions available in the Platform Designer GUI at the command-line, as Platform Designer Command-Line Utilities describes.

When you create a system in the GUI, Platform Designer creates a .qsys or .qip file that represents the system in your Intel^® Quartus^® Prime software project.

The circled numbers in the diagram correspond with the following topics in this chapter:

1. Starting or Opening a Project in Platform Designer
2. Adding IP Components to a System
3. Connecting System Components
4. Specifying Interconnect Requirements
5. Synchronizing System Component Information
6. Generating a Platform Designer System
7. Simulating a Platform Designer System
8. Integrating a Platform Designer System with the Intel Quartus Prime Software

Click the View menu to interact with the elements of your system in various tabs.

The Platform Designer GUI is fully customizable. You can arrange and display Platform Designer GUI elements that you most commonly use, and then save and reuse useful GUI layouts.

The IP Catalog and Hierarchy tabs display to the left of the main frame by default. The System Contents , Address Map, Interconnect Requirements, and Device Family tabs display in the main frame.

The Messages tab displays in the lower portion of Platform Designer. Double-clicking a message in the Messages tab changes focus to the associated element in the relevant tab to facilitate debugging. When the Messages tab is closed or not open in your workspace, error and warning message counts continue to display in the status bar of the Platform Designer window.

Figure 1. View a Platform Designer System

For example, you can click the Filter button to display only instances that include memory-mapped interfaces, or display only instances that connect to a particular Nios^® II processor. Conversely, you can temporarily hide clock and reset interfaces to further simplify the display.

Platform Designer determines clock and reset domains by the associated clocks and resets. This information displays when you hover over interfaces in your system.

The Clock Domains and Reset Domains tabs also allow you to locate system performance bottlenecks. The tabs indicate connection points where Platform Designer automatically inserts clock-crossing adapters and reset synchronizers during system generation. View the following information on these tabs to create optimal connections between interfaces:

• The number of clock and reset domains in the system
• The interfaces and modules that each clock or reset domain contains
• The locations of clock or reset crossings
• The connection point of automatically inserted clock or reset adapters
• The proper location for manual insertion of a clock or reset adapter

• Filter the System Contents tab to display a single Avalon domain, or multiple domains. Further filter your view with selections in the Filters dialog box.
• To rename an Avalon memory-mapped domain, double-click the domain name. Detailed information for the current selection appears in the Avalon domain details pane.

• To enable and disable the highlighting of the Avalon domains in the System Contents tab, click the domain control tool at the bottom of the System Contents tab.

  Figure 8. Avalon Memory Mapped Domains Control Tool

If your selection is a subsystem, You can use the Move to the top of the hierarchy Move up one level of hierarchy, and Drill into a subsystem to explore its contents buttons to traverse the schematic of a hierarchical system.

Figure 9.  Platform Designer Schematic Tab

The Parameters tab provides the following functionality:

• Parameters field—adjust the parameters to align with your design requirements, including changing the name of the top-level instance.
• Component Banner—displays the hierarchical path for the component and allows you to enable display of internal names. Below the hierarchical path, the parameter editor shows the HDL entity name and the IP file path for the selected IP component. Right-click in the banner to display internal parameter names for use with scripted flows.
• Read/Write Waveforms—displays the interface timing and the corresponding read and write waveforms.
• Details—displays links to detailed information about the component.
• Parameterization Messages—displays parameter warning and error messages about the IP component.

Changes that you make in the Parameters tab affect your entire system, and dynamically update other open tabs in Platform Designer. Any change that you make on the Parameters tab, automatically updates the corresponding .ip file that stores the component's parameterization.

If you create your own custom IP components, you can use the Hardware Component Description File (_hw.tcl) to specify configurable parameters.

To view a component's details:

1. Click the parameters for a component in the parameter editor, Platform Designer displays the description of the parameter in the Details tab.
2. To return to the complete description for the component, click the header in the Parameters tab.

The Block Symbol tab displays a symbolic representation of any component you select in the Hierarchy or System Contents tabs. The block symbol shows the component's port interfaces and signals. The Show signals option allows you to turn on or off signal graphics.

The Block Symbol tab appears by default in the parameter editor when you add a component to your system. When the Block Symbol tab is open in your workspace, it reflects changes that you make in other tabs.

You can specify a search path in the user_components.ipx file in either in Platform Designer (Tools > Options) or the Intel^® Quartus^® Prime software (Tools > Options > IP Catalog Search Locations). This method of discovering IP components allows you to add a locations dependent of the default search path. The user_components.ipx file directs Platform Designer to the location of an IP component or directory to search.

A <path> element in a .ipx file specifies a directory where Platform Designer can search for IP components. A <component> entry specifies the path to a single component. <path> elements allow wildcards in definitions. An asterisk matches any file name. If you use an asterisk as a directory name, it matches any number of subdirectories.

<library>
		<path path="…<user directory>" />
		<path path="…<user directory>" />
		…
		<component … file="…<user directory>" />
		…
</library>

<library>
  <component
    name="A Platform Designer Component"
    displayName="Platform Designer FIR Filter Component"
    version="2.1"
    file="./components/qsys_filters/fir_hw.tcl"
   />
  <component
    name="rgb2cmyk_component"
    displayName="RGB2CMYK Converter(Color Conversion Category!)"
    version="0.9"
    file="./components/qsys_converters/color/rgb2cmyk_hw.tcl"
   />
</library>

Potential connections between interfaces appear as gray interconnect lines with an open circle icon at the intersection of the potential connection.

To implement a connection, follow these steps:

1. Click inside an open connection circle to implement the connection between the interfaces. When you make a connection, Platform Designer changes the connection line to black, and fills the connection circle. Clicking a filled-in circle removes the connection.
2. to display the list of current and possible connections for interfaces in the Hierarchy or System Contents tabs, click View > Connections.
   Figure 20. Connection Display for Exported Interfaces
3. Perform any of the following to modify connections:
   • On the Connections tab, enable or disable the Connected column to enable or disable any connection. The Clock Crossing, Data Width, and Burst columns provide interconnect information about added adapters that can result in slower f_MAX or increased area utilization.
   • On the System Contents tab, right-click in the Connection column and disable or enable Allow Connection Editing.
   • On the Connections tab view and make connections for exported interfaces. Double-click an interface in the Export column to view all possible connections in the Connections column as pins. To restore the representation of the connections, and remove the interface from the Export column, click the pin.

The address parameters appear in the Base and End columns in the System Contents tab, on the Address Map tab, in the parameter editor, and in validation messages. Platform Designer displays as many digits as needed in order to display the top-most set bit, for example, 12 hex digits for a 48-bit address.

A Platform Designer system can have multiple 64-bit masters, with each master having its own address space. You can share slaves between masters, and masters can map slaves to different addresses. For example, one master can interact with slave 0 at base address 0000_0000_0000, and another master can see the same slave at base address c000_000_000.

Intel^® Quartus^® Prime debugging tools provide access to the state of an addressable system via the Avalon^® -MM interconnect. These tools are also 64-bit compatible, and process within a 64-bit address space, including a JTAG to Avalon^® master bridge.

Platform Designer supports auto base address assignment for Avalon^® -MM components. In the Address Map tab, click Auto Assign Base Address.

Platform Designer issues a validation error if an Avalon^® -MM master or slave interface on a multi point connection is parameterized with a non-power of two data width.

To open the System with Platform Designer Interconnect window, click System > Show System With Platform Designer Interconnect.

The System with Platform Designer Interconnect window has the following tabs:

• System Contents—displays the original instances in your system, as well as the inserted interconnect instances. Connections between interfaces are replaced by connections to interconnect where applicable.
• Hierarchy—displays a system hierarchical navigator, expanding the system contents to show modules, interfaces, signals, contents of subsystems, and connections.
• Parameters—displays the parameters for the selected element in the Hierarchy tab.
• Memory-Mapped Interconnect—allows you to select a memory-mapped interconnect module and view its internal command and response networks. You can also insert pipeline stages to achieve timing closure.

The System Contents, Hierarchy, and Parameters tabs are read-only. Edits that you apply on the Memory-Mapped Interconnect tab are automatically reflected on the Interconnect Requirements tab.

The Memory-Mapped Interconnect tab in the System with Platform Designer Interconnect window displays a graphical representation of command and response datapaths in your system. Datapaths allow you precise control over pipelining in the interconnect. Platform Designer displays separate figures for the command and response datapaths. You can access the datapaths by clicking their respective tabs in the Memory-Mapped Interconnect tab.

Each node element in a figure represents either a master or slave that communicates over the interconnect, or an interconnect sub-module. Each edge is an abstraction of connectivity between elements, and its direction represents the flow of the commands or responses.

Click Highlight Mode (Path, Successors, Predecessors) to identify edges and datapaths between modules. Turn on Show Pipelinable Locations to add greyed-out registers on edges where pipelining is allowed in the interconnect.

You can use the Instance Parameters tab to define how the specified values for the instance parameters affect the sub-components in the Platform Designer system. You define an Instance Script that creates queries for the instance parameters, and sets the values of the parameters for the lower-level system components.

When you click Preview Instance, Platform Designer creates a preview of the current Platform Designer system with the specified parameters and instance script and opens the parameter editor. This command allows you to see how an instance of a system appears when you use it in another system. The preview instance does not affect your saved system.

To use instance parameters, the IP components or subsystems in your Platform Designer system must have parameters that can be set when they are instantiated in a higher-level system.

If you create hierarchical Platform Designer systems, each Platform Designer system in the hierarchy can include instance parameters to pass parameter values through multiple levels of hierarchy.

package require -exact qsys <version>

To use Tcl commands that work with instance parameters in the instance script, you must specify the commands within a Tcl composition callback. In the instance script, you specify the name for the composition callback with the following command:

set_module_property COMPOSITION_CALLBACK <name of callback procedure>

Specify the appropriate Tcl commands inside the Tcl procedure with the following syntax:

proc <name of procedure defined in previous command> {}
{#Tcl commands to query and set parameters go here}

# Request a specific version of the scripting API
package require -exact qsys 13.1

# Set the name of the procedure to manipulate parameters:
set_module_property COMPOSITION_CALLBACK compose 

proc compose {} {

# Get the pio_width parameter value from this Platform Designer system and
# pass the value to the width parameter of the pio_0 instance

set_instance_parameter_value pio_0 width \
[get_parameter_value pio_width]
}

Access to an undefined memory region occurs when a transaction from a master targets a memory region unspecified in the slave memory map. To ensure predictable response behavior when this condition occurs, you must specify a default slave, as Specifying a Default Slave describes.

You can designate any memory-mapped slave as a default slave. Have only one default slave for each interconnect domain in your system. Platform Designer then routes undefined memory region accesses to the default slave, which terminates the transaction with an error response.

Accessing undefined memory regions can occur in the following cases:

• When there are gaps within the accessible memory map region that are within the addressable range of slaves, but are not mapped.
• Accesses by a master to a region that does not belong to any slaves that is mapped to the master.
• When a non-secured transaction is accessing a secured slave. This applies to only slaves that are secured at compilation time.
• When a read-only slave is accessed with a write command, or a write-only slave is accessed with a read command.

Platform Designer generates the following testbench files.

The .svd (or CMSIS-SVD) file format is an XML schema specified as part of the Cortex Microcontroller Software Interface Standard (CMSIS) that Arm* provides. The .svd file allows HPS system debug tools (such as the DS-5 Debugger) to view the register maps of peripherals connected to HPS in a Platform Designer system.

By default, the sopc-create-header-files command creates multiple header files. There is one header file for the entire system, and one header file for each master group in each module. A master group is a set of masters in a module in the same address space. In general, a module may have multiple master groups. Addresses and available devices are a function of the master group.

Alternatively, you can use the --single option to create one header file for one master group. If there is one CPU module in the Platform Designer system with one master group, the command generates a header file for that CPU's master group. If there are no CPU modules, but there is one module with one master group, the command generates the header file for that module's master group.

You can use the --module and --master options to override these defaults. If your module has multiple master groups, use the --master option to specify the name of a master in the desired master group.

#define FOO 12

m4_define("FOO", 12)

FOO=12

FOO := 12

$macros{FOO} = 12;

You can use scripts to compile the required device libraries and system design files in the correct order and elaborate or load the top-level system for simulation.

module top();
 pattern_generator_tb tb();
 test_program pgm();
endmodule

Figure 31. Inserting an Avalon-MM Monitor Between an Avalon-MM Master and Slave InterfaceThis example demonstrates the use of a monitor with an Avalon-MM monitor between the pcie_compiler bar1_0_Prefetchable Avalon-MM master interface, and the dma_0 control_port_slave Avalon-MM slave interface.

Similarly, you can insert an Avalon-ST monitor between Avalon-ST source and sink interfaces.

You can choose to include the .qsys file automatically in your Intel^® Quartus^® Prime project when you generate your Platform Designer system by turning on the Automatically add Intel^® Quartus^® Prime IP files to all projects option in the Intel^® Quartus^® Prime software (Tools > Options > IP Settings). If this option is turned off, the Intel^® Quartus^® Prime software asks you if you want to include the .qsys file in your Intel^® Quartus^® Prime project after you exit Platform Designer.

If you want file generation to occur as part of the Intel^® Quartus^® Prime software's compilation, you should include the .qsys file in your Intel^® Quartus^® Prime project. If you want to manually control file generation outside of the Intel^® Quartus^® Prime software, you should include the .qip file in your Intel^® Quartus^® Prime project.

Follow the steps below to create a system that contains an on-chip memory IP component with instance parameters, and the instantiating higher-level Platform Designer system. With your completed system, you can vary the values of the instance parameters to review their effect within the On-Chip Memory component.

Avalon^® Streaming ( Avalon^® -ST) links connect point-to-point, unidirectional interfaces and are typically used in data stream applications. Each pair of components is connected without any requirement to arbitrate between the data source and sink.

Because Platform Designer supports multiplexed memory-mapped and streaming connections, you can implement systems that use multiplexed logic for control and streaming for data in a single design.

For example, if the component’s Avalon^® -ST output or source of streaming data is back-pressured because the ready signal is deasserted, then the component must back-pressure its input or sink interface to avoid overflow.

You can use a FIFO to back-pressure internally on the output side of the component so that the input can accept more data even if the output is back-pressured. Then, you can use the FIFO almost full flag to back-pressure the sink interface or input data when the FIFO has only enough space to satisfy the internal latency. You can drive the data valid signal of the output or source interface with the FIFO not empty flag when that data is available.

When designing with memory-mapped components, you can implement any component that contains multiple registers mapped to memory locations, for example, a set of four output registers to support software read back from logic. Components that implement read and write memory-mapped transactions require three main building blocks: an address decoder, a register file, and a read multiplexer.

The decoder enables the appropriate 32-bit or 64-bit register for writes. For reads, the address bits drive the multiplexer selection bits. The read signal registers the data from the multiplexer, adding a pipeline stage so that the component can achieve a higher clock frequency.

This slave component has four write wait states and one read wait state. Alternatively, if you want high throughput, you may set both the read and write wait states to zero, and then specify a read latency of one, because the component also supports pipelined reads.

Hierarchy can simplify verification control of slaves connected to each master in a memory-mapped system. Before you implement subsystems in your design, you should plan the system hierarchical blocks at the top-level, using the following guidelines:

• Plan shared resources—Determine the best location for shared resources in the system hierarchy. For example, if two subsystems share resources, add the components that use those resources to a higher-level system for easy access.
• Plan shared address space between subsystems—Planning the address space ensures you can set appropriate sizes for bridges between subsystems.
• Plan how much latency you may need to add to your system—When you add an Avalon^® -MM Pipeline Bridge between subsystems, you may add latency to the overall system. You can reduce the added latency by parameterizing the bridge with zero cycles of latency, and by turning off the pipeline command and response signals.
  Figure 42.  Avalon^® -MM Pipeline Bridge

  

In this example, two Nios^® II processor subsystems share resources for message passing. Bridges in each subsystem export the Nios^® II data master to the top-level system that includes the mutex (mutual exclusion component) and shared memory component (which could be another on-chip RAM, or a controller for an off-chip RAM device).

You can also design systems that process multiple data channels by instantiating the same subsystem for each channel. This approach is easier to maintain than a larger, non-hierarchical system. Additionally, such systems are easier to scale because you can calculate the required resources as a multiple of the subsystem requirements.

Implementing concurrency requires multiple masters in a Platform Designer system. Systems that include a processor contain at least two master interfaces because the processors include separate instruction and data masters. You can categorize master components as follows:

• General purpose processors, such as Nios^® II processors
• DMA (direct memory access) engines
• Communication interfaces, such as PCI Express

You can create multiple slave interfaces for a particular function to increase concurrency in your design.

In this example, there are two channel processing systems. In the first, four hosts must arbitrate for the single slave interface of the channel processor. In the second, each host drives a dedicated slave interface, allowing all master interfaces to simultaneously access the slave interfaces of the component. Arbitration is not necessary when there is a single host and slave interface.

In some systems, you can use DMA engines to increase throughput. You can use a DMA engine to transfer blocks of data between interfaces, which then frees the CPU from doing this task. A DMA engine transfers data between a programmed start and end address without intervention, and the data throughput is dictated by the components connected to the DMA. Factors that affect data throughput include data width and clock frequency.

In this example, the system can sustain more concurrent read and write operations by including more DMA engines. Accesses to the read and write buffers in the top system are split between two DMA engines, as shown in the Dual DMA Channels at the bottom of the figure.

The DMA engine operates with Avalon^® -MM write and read masters. An AXI DMA typically has only one master, because in AXI, the write and read channels on the master are independent and can process transactions simultaneously.

Platform Designer provides the Limit interconnect pipeline stages to option on the Interconnect Requirements tab to automatically add pipeline stages to the Platform Designer interconnect when you generate a system.

The Limit interconnect pipeline stages to parameter in the Interconnect Requirements tab allows you to define the maximum Avalon^® -ST pipeline stages that Platform Designer can insert during generation. You can specify between 0 to 4 pipeline stages, where 0 means that the interconnect has a combinational datapath. You can specify a unique interconnect pipeline stage value for each subsystem.

For more information, refer to Interconnect Pipelining.

An Avalon^® bridge has an Avalon^® -MM slave interface and an Avalon^® -MM master interface. You can have many components connected to the bridge slave interface, or many components connected to the bridge master interface. You can also have a single component connected to a single bridge slave or master interface.

You can configure the data width of the bridge, which can affect how Platform Designer generates bus sizing logic in the interconnect. Both interfaces support Avalon^® -MM pipelined transfers with variable latency, and can also support configurable burst lengths.

Transfers to the bridge slave interface are propagated to the master interface, which connects to components downstream from the bridge. Bridges can provide more control over interconnect pipelining than the Limit interconnect pipeline stages to option.

The Avalon^® -MM pipeline bridge component integrates into any Platform Designer system. The pipeline bridge options can increase logic utilization and read latency. The change in topology may also reduce concurrency if multiple masters arbitrate for the bridge. You can use the Avalon^® -MM pipeline bridge to control topology without adding a pipeline stage. A pipeline bridge that does not add a pipeline stage is optimal in some latency-sensitive applications. For example, a CPU may benefit from minimal latency when accessing memory.

The arbitration logic for the slave interface must multiplex the address, writedata, and burstcount signals. The multiplexer width increases proportionally with the number of masters connecting to a single slave interface. The increased multiplexer width may become a timing critical path in the system. If a single pipeline bridge does not provide enough pipelining, you can instantiate multiple instances of the bridge in a tree structure to increase the pipelining and further reduce the width of the multiplexer at the slave interface.

The interconnect inserts a multiplexer for every read datapath back to the master. As the number of slaves supporting read transfers connecting to the master increases, the width of the read data multiplexer also increases. If the performance increase is insufficient with one bridge, you can use multiple bridges in a tree structure to improve f_MAX.

The clock crossing bridge contains a pair of clock crossing FIFOs, which isolate the master and slave interfaces in separate, asynchronous clock domains. Transfers to the slave interface are propagated to the master interface.

When you use a FIFO clock crossing bridge for the clock domain crossing, you add data buffering. Buffering allows pipelined read masters to post multiple reads to the bridge, even if the slaves downstream from the bridge do not support pipelined transfers.

You can also use a clock crossing bridge to place high and low frequency components in separate clock domains. If you limit the fast clock domain to the portion of your design that requires high performance, you may achieve a higher f_MAX for this portion of the design. For example, the majority of processor peripherals in embedded designs do not need to operate at high frequencies, therefore, you do not need to use a high-frequency clock for these components. When you compile a design with the Intel^® Quartus^® Prime software, compilation may take more time when the clock frequency requirements are difficult to meet because the Fitter needs more time to place registers to achieve the required f_MAX. To reduce the amount of effort that the Fitter uses on low priority and low performance components, you can place these behind a clock crossing bridge operating at a lower frequency, allowing the Fitter to increase the effort placed on the higher priority and higher frequency datapaths.

You can add an additional pipeline stage with a pipeline bridge between masters and slaves to reduce the amount of combinational logic between registers, which can increase system performance. If you can increase the f_MAX of your design logic, you may be able to turn off the Intel^® Quartus^® Prime software optimization settings, such as the Perform register duplication setting. Register duplication creates duplicate registers in two or more physical locations in the FPGA to reduce register-to-register delays. You may also want to choose Speed for the optimization method, which typically results in higher logic utilization due to logic duplication. By making use of the registers or FIFOs available in the bridges, you can increase the design speed and avoid needless logic duplication or speed optimizations, thereby reducing the logic utilization of the design.

The amount of logic generated for the interconnect often increases as the system becomes larger because Platform Designer creates arbitration logic for every slave interface that is shared by multiple master interfaces. Platform Designer inserts multiplexer logic between master interfaces that connect to multiple slave interfaces if both support read datapaths.

Most embedded processor designs contain components that are either incapable of supporting high data throughput, or do not need to be accessed frequently. These components can contain master or slave interfaces. Because the interconnect supports concurrent accesses, you may want to limit concurrency by inserting bridges into the datapath to limit the amount of arbitration and multiplexer logic generated.

For example, if a system contains three master and three slave interfaces that are interconnected, Platform Designer generates three arbiters and three multiplexers for the read datapath. If these masters do not require a significant amount of simultaneous throughput, you can reduce the resources that your design consumes by connecting the three masters to a pipeline bridge. The bridge controls the three slave interfaces and reduces the interconnect into a bus structure. Platform Designer creates one arbitration block between the bridge and the three masters, and a single read datapath multiplexer between the bridge and three slaves, and prevents concurrency. This implementation is similar to a standard bus architecture.

You should not use this method for high throughput datapaths to ensure that you do not limit overall system performance.

Platform Designer creates burst adapters when the maximum burst length of the master is greater than the master burst length of the slave. The adapter logic creates extra logic resources, which can be substantial when your system contains master interfaces connected to many components that do not share the same characteristics. By placing bridges in your design, you can reduce the amount of adapter logic that Platform Designer generates.

To determine the effective placement of a bridge, you should initially analyze each master in your system to determine if the connected slave devices support different bursting capabilities or operate in a different clock domain. The maximum burstcount of a component is visible as the burstcount signal in the HDL file of the component. The maximum burst length is 2 ^{(width(burstcount -1))}, therefore, if the burstcount width is four bits, the maximum burst length is eight. If no burstcount signal is present, the component does not support bursting or has a burst length of 1.

To determine if the system requires a clock crossing adapter between the master and slave interfaces, check the Clock column for the master and slave interfaces. If the clock is different for the master and slave interfaces, Platform Designer inserts a clock crossing adapter between them. To avoid creating multiple adapters, you can place the components containing slave interfaces behind a bridge so that Platform Designer creates a single adapter. By placing multiple components with the same burst or clock characteristics behind a bridge, you limit concurrency and the number of adapters.

You can also use a bridge to separate AXI and Avalon domains to minimize burst adaptation logic. For example, if there are multiple Avalon slaves that are connected to an AXI master, you can consider inserting a bridge to access the adaptation logic once before the bridge, instead of once per slave. This implementation results in latency, and you would also lose concurrency between reads and writes.

When you use automatic clock-crossing adapters, Platform Designer determines the required depth of FIFO buffering based on the slave properties. If a slave has a high Maximum Pending Reads parameter, the resulting deep response buffer FIFO that Platform Designer inserts between the master and slave can consume a lot of device resources. To control the response FIFO depth, you can use a clock crossing bridge and manually adjust its FIFO depth to trade off throughput with smaller memory utilization.

For example, if you have masters that cannot saturate the slave, you do not need response buffering. Using a bridge reduces the FIFO memory depth and reduces the Maximum Pending Reads available from the slave.

Before you use pipeline or clock crossing bridges in a design, you should carefully consider their effects. Bridges can have any combination of consequences on your design, which could be positive or negative. Benchmarking your system before and after inserting bridges can help you determine the impact to the design.

Adding a bridge to a design has an effect on the read latency between the master and the slave. Depending on the system requirements and the type of master and slave, this latency increase may not be acceptable in your design.

For a pipeline bridge, Platform Designer adds a cycle of latency for each pipeline option that is enabled. The buffering in the clock crossing bridge also adds latency. If you use a pipelined or burst master that posts many read transfers, the increase in latency does not impact performance significantly because the latency increase is very small compared to the length of the data transfer.

For example, if you use a pipelined read master such as a DMA controller to read data from a component with a fixed read latency of four clock cycles, but only perform a single word transfer, the overhead is three clock cycles out of the total of four. This is true when there is no additional pipeline latency in the interconnect. The read throughput is only 25%.

However, if 100 words of data are transferred without interruptions, the overhead is three cycles out of the total of 103 clock cycles. This corresponds to a read efficiency of approximately 97% when there is no additional pipeline latency in the interconnect. Adding a pipeline bridge to this read path adds two extra clock cycles of latency. The transfer requires 105 cycles to complete, corresponding to an efficiency of approximately 94%. Although the efficiency decreased by 3%, adding the bridge may increase the f_MAX by 5%. For example, if the clock frequency can be increased, the overall throughput would improve. As the number of words transferred increases, the efficiency increases to nearly 100%, whether or not a pipeline bridge is present.

Processors are sensitive to high latency read times and typically retrieve data for use in calculations that cannot proceed until the data arrives. Before adding a bridge to the datapath of a processor instruction or data master, determine whether the clock frequency increase justifies the added latency.

A Nios^® II processor instruction master has a cache memory with a read latency of four cycles, which is eight sequential words of data return for each read. At 100 MHz, the first read takes 40 ns to complete. Each successive word takes 10 ns so that eight reads complete in 110 ns.

Adding a clock crossing bridge allows the memory to operate at 125 MHz. However, this increase in frequency is negated by the increase in latency because if the clock crossing bridge adds six clock cycles of latency at 100 MHz, then the memory continues to operate with a read latency of four clock cycles. Consequently, the first read from memory takes 100 ns, and each successive word takes 10 ns because reads arrive at the frequency of the processor, which is 100 MHz. In total, eight reads complete after 170 ns. Although the memory operates at a higher clock frequency, the frequency at which the master operates limits the throughput.

Placing a bridge between multiple master and slave interfaces limits the number of concurrent transfers your system can initiate. This limitation is the same when connecting multiple master interfaces to a single slave interface. The slave interface of the bridge is shared by all the masters and, as a result, Platform Designer creates arbitration logic. If the components placed behind a bridge are infrequently accessed, this concurrency limitation may be acceptable.

Bridges can have a negative impact on system performance if you use them inappropriately. For example, if multiple memories are used by several masters, you should not place the memory components behind a bridge. The bridge limits memory performance by preventing concurrent memory accesses. Placing multiple memory components behind a bridge can cause the separate slave interfaces to appear as one large memory to the masters accessing the bridge; all masters must access the same slave interface.

A memory subsystem with one bridge that acts as a single slave interface for the Avalon^® -MM Nios^® II and DMA masters, which results in a bottleneck architecture. The bridge acts as a bottleneck between the two masters and the memories.

If the f_MAX of your memory interfaces is low and you want to use a pipeline bridge between subsystems, you can place each memory behind its own bridge, which increases the f_MAX of the system without sacrificing concurrency.

The slave interface of a pipeline or clock crossing bridge has a base address and address span. You can set the base address, or allow Platform Designer to set it automatically. The address of the slave interface is the base offset address of all the components connected to the bridge. The address of components connected to the bridge is the sum of the base offset and the address of that component.

The master interface of the bridge drives only the address bits that represent the offset from the base address of the bridge slave interface. Any time a master accesses a slave through a bridge, both addresses must be added together, otherwise the transfer fails. The Address Map tab displays the addresses of the slaves connected to each master and includes address translations caused by system bridges.

In this example, the Nios^® II processor connects to a bridge located at base address 0x1000, a slave connects to the bridge master interface at an offset of 0x20, and the processor performs a write transfer to the fourth 32-bit or 64-bit word within the slave. Nios^® II drives the address 0x102C to interconnect, which is within the address range of the bridge. The bridge master interface drives 0x2C, which is within the address range of the slave, and the transfer completes.

To simplify the system design, all masters should access slaves at the same location. In many systems, a processor passes buffer locations to other mastering components, such as a DMA controller. If the processor and DMA controller do not access the slave at the same location, Platform Designer must compensate for the differences.

A Nios^® II processor and DMA controller access a slave interface located at address 0x20. The processor connects directly to the slave interface. The DMA controller connects to a pipeline bridge located at address 0x1000, which then connects to the slave interface. Because the DMA controller accesses the pipeline bridge first, it must drive 0x1020 to access the first location of the slave interface. Because the processor accesses the slave from a different location, you must maintain two base addresses for the slave device.

To avoid the requirement for two addresses, you can add an additional bridge to the system, set its base address to 0x1000, and then disable all the pipelining options in the second bridge so that the bridge has minimal impact on system timing and resource utilization. Because this second bridge has the same base address as the original bridge, the processor and DMA controller access the slave interface with the same address range.

Increasing the transfer efficiency of the master and slave interfaces in your system increases the throughput of your design. Designs with strict cost or power requirements benefit from increasing the transfer efficiency because you can then use less expensive, lower frequency devices. Designs requiring high performance also benefit from increased transfer efficiency because increased efficiency improves the performance of frequency–limited hardware.

Throughput is the number of symbols (such as bytes) of data that Platform Designer can transfer in a given clock cycle. Read latency is the number of clock cycles between the address and data phase of a transaction. For example, a read latency of two means that the data is valid two cycles after the address is posted. If the master must wait for one request to finish before the next begins, such as with a processor, then the read latency is very important to the overall throughput.

You can measure throughput and latency in simulation by observing the waveforms, or using the verification IP monitors.

Pipelined transfers increase the read efficiency by allowing a master to post multiple reads before data from an earlier read returns. Masters that support pipelined transfers post transfers continuously, relying on the readdatavalid signal to indicate valid data. Slaves support pipelined transfers by including the readdatavalid signal or operating with a fixed read latency.

AXI masters declare how many outstanding writes and reads it can issue with the writeIssuingCapability and readIssuingCapability parameters. In the same way, a slave can declare how many reads it can accept with the readAcceptanceCapability parameter. AXI masters with a read issuing capability greater than one are pipelined in the same way as Avalon^® masters and the readdatavalid signal.

If you create a custom component with a slave interface supporting variable-latency reads, you must specify the Maximum Pending Reads parameter in the Component Editor. Platform Designer uses this parameter to generate the appropriate interconnect and represent the maximum number of read transfers that your pipelined slave component can process. If the number of reads presented to the slave interface exceeds the Maximum Pending Reads parameter, then the slave interface must assert waitrequest.

Optimizing the value of the Maximum Pending Reads parameter requires an understanding of the latencies of your custom components. This parameter should be based on the component’s highest read latency for the various logic paths inside the component. For example, if your pipelined component has two modes, one requiring two clock cycles and the other five, set the Maximum Pending Reads parameter to 5 to allow your component to pipeline five transfers, and eliminating dead cycles after the initial five-cycle latency.

You can also determine the correct value for the Maximum Pending Reads parameter by monitoring the number of reads that are pending during system simulation or while running the hardware. To use this method, set the parameter to a high value and use a master that issues read requests on every clock. You can use a DMA for this task if the data is written to a location that does not frequently assert waitrequest. If you implement this method, you can observe your component with a logic analyzer or built-in monitoring hardware.

Choosing the correct value for the Maximum Pending Reads parameter of your custom pipelined read component is important. If you underestimate the parameter value, you may cause a master interface to stall with a waitrequest until the slave responds to an earlier read request and frees a FIFO position.

The Maximum Pending Reads parameter controls the depth of the response FIFO inserted into the interconnect for each master connected to the slave. This FIFO does not use significant hardware resources. Overestimating the Maximum Pending Reads parameter results in a slight increase in hardware utilization. For these reasons, if you are not sure of the optimal value, you should overestimate this value.

If your system includes a bridge, you must set the Maximum Pending Reads parameter on the bridge as well. To allow maximum throughput, this value should be equal to or greater than the Maximum Pending Reads value for the connected slave that has the highest value. You can limit the maximum pending reads of a slave and reduce the buffer depth by reducing the parameter value on the bridge if the high throughput is not required. If you do not know the Maximum Pending Reads value for all the slave components, you can monitor the number of reads that are pending during system simulation while running the hardware. To use this method, set the Maximum Pending Reads parameter to a high value and use a master that issues read requests on every clock, such as a DMA. Then, reduce the number of maximum pending reads of the bridge until the bridge reduces the performance of any masters accessing the bridge.

You can adjust the arbitration process by assigning a larger number of shares to masters that need greater throughput. The larger the arbitration share, the more transfers are allocated to the master to access a slave. The masters gets uninterrupted access to the slave for its number of shares, as long as the master is reading or writing.

If a master cannot post a transfer, and other masters are waiting to gain access to a particular slave, the arbiter grants access to another master. This mechanism prevents a master from wasting arbitration cycles if it cannot post back-to-back transfers. A bursting transaction contains multiple beats (or words) of data, starting from a single address. Bursts allow a master to maintain access to a slave for more than a single word transfer. If a bursting master posts a write transfer with a burst length of eight, it is guaranteed arbitration for eight write cycles.

You can assign arbitration shares to an Avalon^® -MM bursting master and AXI masters (which are always considered a bursting master). Each share consists of one burst transaction (such as multi cycle write), and allows a master to complete a number of bursts before arbitration switches to the next master.

The following three key characteristics distinguish arbitration shares and bursts:

• Arbitration Lock
• Sequential Addressing
• Burst Adapters

To avoid inefficient Avalon^® -MM transfers, custom master or slave interfaces must use the appropriate simple, pipelined, or burst interfaces.

Simple interface transfers do not support pipelining or bursting for reads or writes; consequently, their performance is limited. Simple interfaces are appropriate for transfers between masters and infrequently used slave interfaces. In Platform Designer, the PIO, UART, and Timer include slave interfaces that use simple transfers.

Pipelined read transfers allow a pipelined master interface to start multiple read transfers in succession without waiting for prior transfers to complete. Pipelined transfers allow master-slave pairs to achieve higher throughput, even though the slave port may require one or more cycles of latency to return data for each transfer.

In many systems, read throughput becomes inadequate if simple reads are used and pipelined transfers can increase throughput. If you define a component with a fixed read latency, Platform Designer automatically provides the pipelining logic necessary to support pipelined reads. You can use fixed latency pipelining as the default design starting point for slave interfaces. If your slave interface has a variable latency response time, use the readdatavalid signal to indicate when valid data is available. The interconnect implements read response FIFO buffering to handle the maximum number of pending read requests.

To use components that support pipelined read transfers, and to use a pipelined system interconnect efficiently, your system must contain pipelined masters. You can use pipelined masters as the default starting point for new master components. Use the readdatavalid signal for these master interfaces.

Because master and slaves sometimes have mismatched pipeline latency, the interconnect contains logic to reconcile the differences.

Burst transfers are commonly used for latent memories such as SDRAM and off-chip communication interfaces, such as PCI Express. To use a burst-capable slave interface efficiently, you must connect to a bursting master. Components that require bursting to operate efficiently typically have an overhead penalty associated with short bursts or non-bursting transfers.

You can use a burst-capable slave interface if you know that your component requires sequential transfers to operate efficiently. Because SDRAM memories incur a penalty when switching banks or rows, performance improves when SDRAM memories are accessed sequentially with bursts.

Architectures that use the same signals to transfer address and data also benefit from bursting. Whenever an address is transferred over shared address and data signals, the throughput of the data transfer is reduced. Because the address phase adds overhead, using large bursts increases the throughput of the connection.

The master performs word accesses and writes to sequential memory locations. When go is asserted, the start_address and transfer_length are registered. On the next clock cycle, the control logic asserts burst_begin, which synchronizes the internal control signals in addition to the master_address and master_burstcount presented to the interconnect. The timing of these two signals is important because during bursting write transfers byteenable and burstcount must be held constant for the entire burst.

To avoid inefficient writes, the master posts a burst when enough data is buffered in the FIFO. To maximize the burst efficiency, the master should stall only when a slave asserts waitrequest. In this example, the FIFO’s used signal tracks the number of words of data that are stored in the FIFO and determines when enough data has been buffered.

The address register increments after every word transfer, and the length register decrements after every word transfer. The address remains constant throughout the burst. Because a transfer is not guaranteed to complete on burst boundaries, additional logic is necessary to recognize the completion of short bursts and complete the transfer.

In Platform Designer, changes to the connections between master and slave reduce the amount of interconnect logic required in the system.

You can create a system where a master interface connects to a single slave interface. This configuration eliminates address decoding, arbitration, and return data multiplexing, which simplifies the interconnect. Dedicated master-to-slave connections attain the same clock frequencies as Avalon^® -ST connections.

Typically, these one-to-one connections include an Avalon memory-mapped bridge or hardware accelerator. For example, if you insert a pipeline bridge between a slave and all other master interfaces, the logic between the bridge master and slave interface is reduced to wires. If a hardware accelerator connects only to a dedicated memory, no system interconnect logic is generated between the master and slave pair.

The number of connections between master and slave interfaces affects the f_MAX of your system. Every master interface that you connect to a slave interface increases the width of the multiplexer width. As a multiplexer width increases, so does the logic depth and width that implements the multiplexer in the FPGA. To improve system performance, connect masters and slaves only when necessary.

When you connect a master interface to many slave interfaces, the multiplexer for the read data signal grows. Avalon typically uses a readdata signal. AXI read data signals add a response status and last indicator to the read response channel using rdata, rresp, and rlast. Additionally, bridges help control the depth of multiplexers.

If address code logic is in the critical path, you may be able to change the address map to simplify the decode logic. Experiment with different address maps, including a one-hot encoding, to see if results improve.

As the number of components in a design increases, the amount of logic required to implement the interconnect also increases. The number of arbitration blocks increases for every slave interface that is shared by multiple master interfaces. The width of the read data multiplexer increases as the number of slave interfaces supporting read transfers increases on a per master interface basis. For these reasons, consider implementing multiple blocks of logic as a single interface to reduce interconnect logic utilization.

You should consider the following trade-offs before making modifications to your system or interfaces:

• Consider the impact on concurrency that results when you consolidate components. When a system has four master components and four slave interfaces, it can initiate four concurrent accesses. If you consolidate the four slave interfaces into a single interface, then the four masters must compete for access. Consequently, you should only combine low priority interfaces such as low speed parallel I/O devices if the combination does not impact the performance.
• Determine whether consolidation introduces new decode and multiplexing logic for the slave interface that the interconnect previously included. If an interface contains multiple read and write address locations, the interface already contains the necessary decode and multiplexing logic. When you consolidate interfaces, you typically reuse the decoder and multiplexer blocks already present in one of the original interfaces; however, combining interfaces may simply move the decode and multiplexer logic, rather than eliminate duplication.
• Consider whether consolidating interfaces makes the design complicated. If so, you should not consolidate interfaces.

In this example, we have a system with a mix of components, each having different burst capabilities: a Nios^® II/e core, a Nios^® II/f core, and an external processor, which off-loads some processing tasks to the Nios^® II/f core.

The Nios^® II/f core supports a maximum burst size of eight. The external processor interface supports a maximum burst length of 64. The Nios^® II/e core does not support bursting. The memory in the system is SDRAM with an Avalon^® maximum burst length of two.

Platform Designer automatically inserts burst adapters to compensate for burst length mismatches. The adapters reduce bursts to a single transfer, or the length of two transfers. For the external processor interface connecting to DDR SDRAM, a burst of 64 words is divided into 32 burst transfers, each with a burst length of two. When you generate a system, Platform Designer inserts burst adapters based on maximum burstcount values; consequently, the interconnect logic includes burst adapters between masters and slave pairs that do not require bursting, if the master is capable of bursts.

In this example, Platform Designer inserts a burst adapter between the Nios^® II processors and the timer, system ID, and PIO peripherals. These components do not support bursting and the Nios^® II processor performs a single word read and write accesses to these components.

You specify clock domains in Platform Designer on the System Contents tab. Clock sources can be driven by external input signals to Platform Designer, or by PLLs inside Platform Designer. Clock domains are differentiated based on the name of the clock. You can create multiple asynchronous clocks with the same frequency.

Platform Designer generates Clock Domain Crossing (CDC) logic that hides the details of interfacing components operating in different clock domains. The interconnect supports the memory-mapped protocol with each port independently, and therefore masters do not need to incorporate clock adapters in order to interface to slaves on a different domain. Platform Designer interconnect logic propagates transfers across clock domain boundaries automatically.

Clock-domain adapters provide the following benefits:

• Allows component interfaces to operate at different clock frequencies.
• Eliminates the need to design CDC hardware.
• Allows each memory-mapped port to operate in only one clock domain, which reduces design complexity of components.
• Enables masters to access any slave without communication with the slave clock domain.
• Allows you to focus performance optimization efforts on components that require fast clock speed.

A clock domain adapter consists of two finite state machines (FSM), one in each clock domain, that use a hand-shaking protocol to propagate transfer control signals (read_request, write_request, and the master waitrequest signals) across the clock boundary.

This example illustrates a clock domain adapter between one master and one slave. The synchronizer blocks use multiple stages of flipflops to eliminate the propagation of meta-stable events on the control signals that enter the handshake FSMs. The CDC logic works with any clock ratio.

The typical sequence of events for a transfer across the CDC logic is as follows:

• The master asserts address, data, and control signals.
• The master handshake FSM captures the control signals and immediately forces the master to wait. The FSM uses only the control signals, not address and data. For example, the master simply holds the address signal constant until the slave side has safely captured it.
• The master handshake FSM initiates a transfer request to the slave handshake FSM.
• The transfer request is synchronized to the slave clock domain.
• The slave handshake FSM processes the request, performing the requested transfer with the slave.
• When the slave transfer completes, the slave handshake FSM sends an acknowledge back to the master handshake FSM. The acknowledge is synchronized back to the master clock domain.
• The master handshake FSM completes the transaction by releasing the master from the wait condition.

Transfers proceed as normal on the slave and the master side, without a special protocol to handle crossing clock domains. From the perspective of a slave, there is nothing different about a transfer initiated by a master in a different clock domain. From the perspective of a master, a transfer across clock domains simply requires extra clock cycles. Similar to other transfer delay cases (for example, arbitration delay or wait states on the slave side), the Platform Designer forces the master to wait until the transfer terminates. As a result, pipeline master ports do not benefit from pipelining when performing transfers to a different clock domain.

Platform Designer automatically determines where to insert CDC logic based on the system and the connections between components, and places CDC logic to maintain the highest transfer rate for all components. Platform Designer evaluates the need for CDC logic for each master and slave pair independently, and generates CDC logic wherever necessary.

CDC logic extends the duration of master transfers across clock domain boundaries. In the worst case, which is for reads, each transfer is extended by five master clock cycles and five slave clock cycles. Assuming the default value of 2 for the master domain synchronizer length and the slave domain synchronizer length, the components of this delay are the following:

• Four additional master clock cycles, due to the master-side clock synchronizer.
• Four additional slave clock cycles, due to the slave-side clock synchronizer.
• One additional clock in each direction, due to potential metastable events as the control signals cross clock domains.

When you use multiple clock domains, you should put non-critical logic in the slower clock domain. Platform Designer automatically reconciles data crossing over asynchronous clock domains by inserting clock crossing logic (handshake or FIFO).

You can use clock crossing in Platform Designer to reduce the clock frequency of the logic that does not require a high frequency clock, which allows you to reduce power consumption. You can use either handshaking clock crossing bridges or handshaking clock crossing adapters to separate clock domains.

You can use the clock crossing bridge to connect master interfaces operating at a higher frequency to slave interfaces running at a lower frequency. Only connect low throughput or low priority components to a clock crossing bridge that operates at a reduced clock frequency. The following are examples of low throughput or low priority components:

• PIOs
• UARTs (JTAG or RS-232)
• System identification (SysID)
• Timers
• PLL (instantiated within Platform Designer)
• Serial peripheral interface (SPI)
• EPCS controller
• Tristate bridge and the components connected to the bridge

By reducing the clock frequency of the components connected to the bridge, you reduce the dynamic power consumption of the design. Dynamic power is a function of toggle rates and decreasing the clock frequency decreases the toggle rate.

Platform Designer automatically inserts clock crossing adapters between master and slave interfaces that operate at different clock frequencies. You can choose the type of clock crossing adapter in the Platform Designer Project Settings tab. Adapters do not appear in the Connections column because you do not insert them. The following clock crossing adapter types are available in Platform Designer:

• Handshake—Uses a simple handshaking protocol to propagate transfer control signals and responses across the clock boundary. This adapter uses fewer hardware resources because each transfer is safely propagated to the target domain before the next transfer begins. The Handshake adapter is appropriate for systems with low throughput requirements.
• FIFO—Uses dual-clock FIFOs for synchronization. The latency of the FIFO adapter is approximately two clock cycles more than the handshake clock crossing component, but the FIFO-based adapter can sustain higher throughput because it supports multiple transactions simultaneously. The FIFO adapter requires more resources, and is appropriate for memory-mapped transfers requiring high throughput across clock domains.
• Auto—Platform Designer specifies the appropriate FIFO adapter for bursting links and the Handshake adapter for all other links.

Because the clock crossing bridge uses FIFOs to implement the clock crossing logic, it buffers transfers and data. Clock crossing adapters are not pipelined, so that each transaction is blocking until the transaction completes. Blocking transactions may lower the throughput substantially; consequently, if you want to reduce power consumption without limiting the throughput significantly, you should use the clock crossing bridge or the FIFO clock crossing adapter. However, if the design requires single read transfers, a clock crossing adapter is preferable because the latency is lower.

The clock crossing bridge requires few logic resources other than on-chip memory. The number of on-chip memory blocks used is proportional to the address span, data width, buffering depth, and bursting capabilities of the bridge. The clock crossing adapter does not use on-chip memory and requires a moderate number of logic resources. The address span, data width, and the bursting capabilities of the clock crossing adapter determine the resource utilization of the device.

When you decide to use a clock crossing bridge or clock crossing adapter, you must consider the effects of throughput and memory utilization in the design. If on-chip memory resources are limited, you may be forced to choose the clock crossing adapter. Using the clock crossing bridge to reduce the power of a single component may not justify using more resources. However, if you can place all of the low priority components behind a single clock crossing bridge, you may reduce power consumption in the design.

A Platform Designer system consumes power whenever logic transitions between on and off states. When the state is held constant between clock edges, no charging or discharging occurs. You can use the following design methodologies to reduce the toggle rates of your design:

• Registering component boundaries
• Using clock enable signals
• Inserting bridges

Platform Designer interconnect is uniquely combinational when no adapters or bridges are present and there is no interconnect pipelining. When a slave interface is not selected by a master, various signals may toggle and propagate into the component. By registering the boundary of your component at the master or slave interface, you can minimize the toggling of the interconnect and your component. In addition, registering boundaries can improve operating frequency. When you register the signals at the interface level, you must ensure that the component continues to operate within the interface standard specification.

Avalon^® -MM waitrequest is a difficult signal to synchronize when you add registers to your component. The waitrequest signal must be asserted during the same clock cycle that a master asserts read or write to in order to prolong the transfer. A master interface can read the waitrequest signal too early and post more reads and writes prematurely.

For slave interfaces, the interconnect manages the begintransfer signal, which is asserted during the first clock cycle of any read or write transfer. If the waitrequest is one clock cycle late, you can logically OR the waitrequest and the begintransfer signals to form a new waitrequest signal that is properly synchronized. Alternatively, the component can assert waitrequest before it is selected, guaranteeing that the waitrequest is already asserted during the first clock cycle of a transfer.

There are typically two types of low power modes: volatile and non-volatile. A volatile low power mode holds the component in a reset state. When the logic is reactivated, the previous operational state is lost. A non-volatile low power mode restores the previous operational state. You can use either software-controlled or hardware-controlled sleep modes to disable a component in order to reduce power consumption.

You can view the polarity status of a reset signal by selecting the signal in the Hierarchy tab, and then view its expanded definition in the open Parameters and Block Symbol tabs. When you generate your component, Platform Designer interconnect automatically inverts polarities as needed.

Figure 68. Reset Signal (Active-High)

Figure 69. Reset Signal Active-Low

Figure 70. Synchronous Edges Parameter

You can combine multiple reset sources to reset a particular component.

Figure 71. Combine Multiple Reset Sources

When you generate your component, Platform Designer inserts adapters to synchronize or invert resets if there are mismatches in polarity or synchronization between the source and destination. You can view inserted adapters on the Memory-Mapped Interconnect tab with the System > Show System with Platform Designer Interconnect command.

Figure 72.  Platform Designer Interconnect

For a high throughput system using the Avalon^® -MM standard, you can design a pipelined read master that allows a system to issue multiple read requests before data returns. Pipelined read masters hide the latency of read operations by posting reads as frequently as every clock cycle. You can use this type of master when the address logic is not dependent on the data returning.

You must carefully design the logic for the control and datapaths of pipelined read masters. The control logic must extend a read cycle whenever the waitrequest signal is asserted. This logic must also control the master address, byteenable, and read signals. To achieve maximum throughput, pipelined read masters should post reads continuously while waitrequest is deasserted. While read is asserted, the address presented to the interconnect is stored.

The datapath logic includes the readdata and readdatavalid signals. If your master can accept data on every clock cycle, you can register the data with the readdatavalid as an enable bit. If your master cannot process a continuous stream of read data, it must buffer the data in a FIFO. The control logic must stop issuing reads when the FIFO reaches a predetermined fill level to prevent FIFO overflow.

The throughput improvement that you can achieve with a pipelined read master is typically directly proportional to the pipeline depth of the interconnect and the slave interface. For example, if the total latency is two cycles, you can double the throughput by inserting a pipelined read master, assuming the slave interface also supports pipeline transfers. If either the master or slave does not support pipelined read transfers, then the interconnect asserts waitrequest until the transfer completes. You can also gain throughput when there are some cycles of overhead before a read response.

Where reads are not pipelined, the throughput is reduced. When both the master and slave interfaces support pipelined read transfers, data flows in a continuous stream after the initial latency. You can use a pipelined read master that stores data in a FIFO to implement a custom DMA, hardware accelerator, or off-chip communication interface.

This example shows a pipelined read master that stores data in a FIFO. The master performs word accesses that are word-aligned and reads from sequential memory addresses. The transfer length is a multiple of the word size.

When the go bit is asserted, the master registers the start_address and transfer_length signals. The master begins issuing reads continuously on the next clock cycle until the length register reaches zero. In this example, the word size is four bytes so that the address always increments by four, and the length decrements by four. The read signal remains asserted unless the FIFO fills to a predetermined level. The address register increments and the length register decrements if the length has not reached 0 and a read is posted.

The master posts a read transfer every time the read signal is asserted and the waitrequest is deasserted. The master issues reads until the entire buffer has been read or waitrequest is asserted. An optional tracking block monitors the done bit. When the length register reaches zero, some reads are outstanding. The tracking logic prevents assertion of done until the last read completes, and monitors the number of reads posted to the interconnect so that it does not exceed the space remaining in the readdata FIFO. This example includes a counter that verifies that the following conditions are met:

• If a read is posted and readdatavalid is deasserted, the counter increments.
• If a read is not posted and readdatavalid is asserted, the counter decrements.

When the length register and the tracking logic counter reach zero, all the reads have completed and the done bit is asserted. The done bit is important if a second master overwrites the memory locations that the pipelined read master accesses. This bit guarantees that the reads have completed before the original data is overwritten.

You can combine adapters with streaming components to create datapaths whose input and output streams have different properties. The following examples demonstrate datapaths in which the output stream exhibits higher performance than the input stream.

The diagram below illustrates a datapath that uses the dual clock version of the on-chip FIFO memory to boost the frequency of input data from 100 MHz to 110 MHz by sampling two input streams at differential rates. The on-chip FIFO memory has an input clock frequency of 100 MHz, and an output clock frequency of 110 MHz. The channel multiplexer runs at 110 MHz and samples one input stream 27.3 percent of the time, and the second 72.7 percent of the time. You must know what the typical and maximum input channel utilizations are before for this type of design. For example, if the first channel hits 50% utilization, the output stream exceeds 100% utilization.

The diagram below illustrates a datapath that uses a data format adapter and Avalon^® -ST channel multiplexer to merge the 8-bit 100 MHz input from two streaming data sources into a single 16-bit 100 MHz streaming output. This example shows an output with double the throughput of each interface with a corresponding doubling of the data width.

The diagram below illustrates a datapath that uses the dual clock version of the on-chip FIFO memory and Avalon^® -ST channel multiplexer to merge the 100 MHz input from two streaming data sources into a single 200 MHz streaming output. This example shows an output with double the throughput of each interface with a corresponding doubling of the clock frequency.

Platform Designer supports Avalon^® , AMBA* 3 AXI (version 1.0), AMBA* 4 AXI (version 2.0), AMBA* 4 AXI-Lite (version 2.0), AMBA* 4 AXI-Stream (version 1.0), and AMBA* 3 APB (version 1.0) interface specifications.

The video AMBA* AXI and Intel Avalon^® Interoperation Using Platform Designer describes seamless integration of IP components using the AMBA* AXI and the Intel Avalon^® interfaces.

The Platform Designer packet format supports Avalon^® , AXI, and APB transactions. Memory-mapped transactions between masters and slaves are encapsulated in Platform Designer packets. For Avalon^® systems without AXI or APB interfaces, some fields are ignored or removed.

The Avalon^® -MM Master translator performs the following functions:

• Translates active-low signaling to active-high signaling
• Inserts wait states to prevent an Avalon^® ‑MM master from reading invalid data
• Translates word and symbol addresses
• Translates word and symbol burst counts
• Manages re-timing and re-sequencing bursts
• Removes unnecessary address bits

The AXI translator is inserted for both AMBA* 4 AXI masters and slaves and performs the following functions:

• Matches ID widths between the master and slave in 1x1 systems.
• Drives default values as defined in the AMBA* Protocol Specifications for missing signals.
• Performs lock transaction bit conversion when an AMBA* 3 AXI master connects to an AMBA* 4 AXI slave in 1x1 systems.

The APB translator is inserted for both the master and slave and performs the following functions:

• Sets the response value default to OKAY if the APB slave does not have a pslverr signal.
• Turns on or off additional signals between the APB debug interface, which is used with HPS (Intel SoC’s Hard Processor System).

An Avalon^® -MM Slave Translator performs the following functions:

• Drives the beginbursttransfer and byteenable signals.
• Supports Avalon^® -MM slaves that operate using fixed timing and or slaves that use the readdatavalid signal to identify valid data.
• Translates the read, write, and chipselect signals into the representation that the Avalon^® ‑ST slave response network uses.
• Converts active low signals to active high signals.
• Translates word and symbol addresses and burstcounts.
• Handles burstcount timing and sequencing.
• Removes unnecessary address bits.

The AXI translator is inserted for both AMBA* 4 AXI master and slave, and performs the following functions:

• Matches ID widths between master and slave in 1x1 systems.
• Drives default values as defined in the AMBA* Protocol Specifications for missing signals.
• Performs lock transaction bit conversion when an AMBA* 3 AXI master connects to an AMBA* 4 AXI slave in 1x1 systems.

In a fairness-based arbitration protocol, each master has an integer value of transfer shares with respect to a slave. One share represents permission to perform one transfer. The default arbitration scheme is equal share round-robin that grants equal, sequential access to all requesting masters. You can change the arbitration scheme to weighted round-robin by specifying a relative number of arbitration shares to the masters that access a given slave. AXI slaves have separate arbitration for their independent read and write channels, and the Arbitration Shares setting affects both the read and write arbitration. To display arbitration settings, right-click an instance on the System Contents tab, and then click Show Arbitration Shares.

Figure 86. Arbitration Shares in the Connections Column

You can selectively apply fixed priority arbitration to any slave in a Platform Designer system. You can design Platform Designer systems where a subset of slaves use the default round-robin arbitration, and other slaves use fixed priority arbitration. Fixed priority arbitration uses a fixed priority algorithm to grant access to a slave amongst its connected masters.

To set up fixed priority arbitration, you must first designate a fixed priority slave in your Platform Designer system in the Interconnect Requirements tab. You can then assign an arbitration priority number for each master connected to a fixed priority slave in the System Contents tab, where the highest numeric value receives the highest priority. When multiple masters request access to a fixed priority arbitrated slave, the arbiter gives the master with the highest priority first access to the slave.

For example, when a fixed priority slave receives requests from three masters on the same cycle, the arbiter grants the master with highest assigned priority first access to the slave, and backpressures the other two masters.

Since AXI masters have separate read and write channels, each channel appears as two separate masters to the Avalon^® -MM slave. To support fairness between the AXI master’s read and write channels, the instantiated round-robin intermediary multiplexer arbitrates between simultaneous read and write commands from the AXI master to the fixed-priority Avalon^® -MM slave.

When an AXI master is connected to a fixed priority AXI slave, the master’s read and write channels are directly connected to the AXI slave’s fixed-priority multiplexers. In this case, there is one multiplexer for the read command, and one multiplexer for the write command and therefore an intermediary multiplexer is not required.

The red circles indicate placement of the intermediary multiplexer between the AXI master and Avalon^® -MM slave due to the separate read and write channels of the AXI master.

Figure 89. Intermediary Multiplexer Between AXI Master and Avalon^® -MM Slave

The memory-mapped width adapter accepts packets on its sink interface with one data width and produces output packets on its source interface with a different data width. The ratio of the narrow data width must be a power of two, such as 1:4, 1:8, and 1:16. The ratio of the wider data width to the narrower width must also be a power of two, such as 4:1, 8:1, and 16:1 These output packets may have a different size if the input size exceeds the output data bus width, or if data packing is enabled.

When the width adapter converts from narrow data to wide data, each input beat's data and byte enables are copied to the appropriate segment of the wider output data and byte enables signals.

The maximum burst length for each interface is a property of the interface and is independent of other interfaces in the system. Therefore, a specific master may be capable of initiating a burst longer than a slave’s maximum supported burst length. In this case, the burst adapter translates the large master burst into smaller bursts, or into individual slave transfers if the slave does not support bursting. Until the master completes the burst, arbiter logic prevents other masters from accessing the target slave. For example, if a master initiates a burst of 16 transfers to a slave with maximum burst length of 8, the burst adapter initiates 2 bursts of length 8 to the slave.

Avalon^® -MM and AXI burst transactions allow a master uninterrupted access to a slave for a specified number of transfers. The master specifies the number of transfers when it initiates the burst. Once a burst begins between a master and slave, arbiter logic is locked until the burst completes. For burst masters, the length of the burst is the number of cycles that the master has access to the slave, and the selected arbitration shares have no effect.

Avalon^® -MM masters always issue addresses that are aligned to the size of the transfer. However, when Platform Designer uses a narrow-to-wide width adaptation, the resulting address may be unaligned. For unaligned addresses, the burst adapter issues the maximum sized bursts with appropriate byte enables. This brings the burst-in-progress up to an aligned slave address. Then, it completes the burst on aligned addresses.

The burst adapter supports variable wrap or sequential burst types to accommodate different properties of memory-mapped masters. Some bursting masters can issue more than one burst type.

Burst adaptation is available for Avalon^® to Avalon^® , Avalon^® to AXI, and AXI to Avalon^® , and AXI to AXI connections. For information about AXI-to-AXI adaptation, refer to AXI Wide-to-Narrow Adaptation

To access the implementation options, you must select the Burst adapter implementation setting for the $system identifier.

• Generic converter (slower, lower area)—Default. Controls all burst conversions with a single converter that can adapt incoming burst types. This results in an adapter that has lower f_MAX, but smaller area.
• Per-burst-type converter (faster, higher area)—Controls incoming bursts with a specific converter, depending on the burst type. This results in an adapter that has higher f_MAX, but higher area. This setting is useful when you have AXI masters or slaves and you want a higher f_MAX.

The Waitrequest Allowance adapter provides the following features:

• The adapter is used in the memory-mapped domain and operates with signals on the memory-mapped interface.
• Signal widths and all properties other than waitrequestAllowance are identical on master and slave interfaces.
• The adapter does not modify any command properties such as data width, burst type, or burst count.
• The adapter is inserted by the Platform Designer interconnect software when a master and slave with different waitrequestAllowance property are connected.

When the slave has a waitrequestAllowance = n the master must deassert read or write signals after <n> transfers when waitrequest is asserted.

Platform Designer merges write responses if a write is converted (burst adapted) into multiple bursts. Platform Designer requires read response merging for a downsized (wide-to-narrow width adapted) read.

DECERR > SLVERR > OKAY > EXOKAY

Adaptation between a master with write responses and a slave without write responses can be costly, especially if there are multiple slaves, or if the slave supports bursts. To minimize the cost of logic between slaves, consider placing the slaves that do not have write responses behind a bridge so that the write response adaptation logic cost is only incurred once, at the bridge’s slave interface.

The following table describes what happens when there is a mismatch in response support between the master and slave.

For the response case where the transaction violates security settings or uses an illegal address, the interconnect routes the transactions to the default slave. For information about Platform Designer system security, refer to Manage System Security. For information about specifying a default slave, refer to Error Response Slave in Platform Designer System Design Components.

Address decoding logic simplifies component design in the following ways:

• The interconnect selects a slave whenever it is being addressed by a master. Slave components do not need to decode the address to determine when they are selected.
• Slave addresses are properly aligned to the slave interface.
• Changing the system memory map does not involve manually editing HDL.

Platform Designer controls the base addresses with the Base setting of active components on the System Contents tab. The base address of a slave component must be a multiple of the address span of the component. This restriction is part of the Platform Designer interconnect to allow the address decoding logic to be efficient, and to achieve the best possible f_MAX.

The IP Catalog includes Avalon^® -ST components that you can use to create datapaths, including datapaths whose input and output streams have different properties. Generated systems that include memory-mapped master and slave components may also use these Avalon^® -ST components because Platform Designer generation creates interconnect with a structure similar to a network topology, as described in Platform Designer Transformations. The following sections introduce the Avalon^® -ST components.

After generation, you can view the inserted adapters selecting System > Show System With Platform Designer Interconnect. For each mismatched source-sink pair, Platform Designer inserts an Avalon^® -ST Adapter. The adapter instantiates the necessary adaptation logic as sub-components. You can review the logic for each adapter instantiation in the Hierarchy view by expanding each adapter's source and sink interface and comparing the relevant ports. For example, to determine why a channel adapter is inserted, expand the channel adapter's sink and source interfaces and review the channel port properties for each interface.

You can turn off the auto-inserted adapters feature by adding the qsys_enable_avalon_streaming_transform=off command to the quartus.ini file. When you turn off the auto-inserted adapters feature, if mismatched interfaces are detected during system generation, Platform Designer does not insert adapters and reports the mismatched interface with validation error message.

You can define the interrupt sender interface as asynchronous with no associated clock or reset interfaces. You can also define the interrupt receiver interface as asynchronous with no associated clock or reset interfaces. As a result, the receiver does its own synchronization internally. Platform Designer does not insert interrupt synchronizers for such receivers.

For clock crossing adaption on interrupts, Platform Designer inserts a synchronizer, which is clocked with the interrupt end point interface clock when the corresponding starting point interrupt interface has no clock or a different clock (than the end point). Platform Designer inserts the adapter if there is any kind of mismatch between the start and end points. Platform Designer does not insert the adapter if the interrupt receiver does not have an associated clock.