TMO IP Interfaces
The IP has three functional interfaces, three clock domains, and three resets.
Functional Interfaces
The TMO IP has three functional interfaces
- Intel FPGA video stream input interface (axi4s_vid_in)
- Intel FPGA video stream output interface (axi4s_vid_out)
- External Avalon memory-mapped compatible CPU interface (av_mm_cpu_agent)
The Intel FPGA video streaming protocol is a standard interface to connect components that exchange data.
Avalon memory-mapped interface
The IP external CPU interface is an Avalon memory-mapped interface that accesses the control and status registers.
For CPU control interfaces, the TMO IP uses the Avalon memory-mapped protocol. AXI4 protocols are natively supported in Platform Designer. You can automatically adapt to and from Avalon memory mapped interfaces.
The Avalon memory-mapped interface is an address-based read and write interface typical of host and agent connections. A host is the interface that initiates a transfer request, and an agent is the interface that receives the transfer request. The Avalon memory-mapped interface allows you to dynamically control parameters within the TMO IP by connecting the TMO IP Avalon-MM interface (Avalon memory-mapped agent) to an embedded ARM processor or soft system processor such as a Nios™ II processor (Avalon memory-mapped host).
You can control the TMO IP through the Avalon memory-mapped inteface with the IP drivers and API functions.
| Signal Name |
Avalon Specification Name | Direction |
Width (Bits) | Description |
|---|---|---|---|---|
| av_mm_cpu_agent_address |
address | Host to Agent |
7 | For a host, by default, the address signal represents a byte address. The value of the address must align to the data width. To write to specific bytes within a data word, the host must use the byteenable signal. For an agent, by default, the interconnect translates the byte address into a word address in the agent’s address space. From the perspective of the agent, each agent access is for a word of data. |
| av_mm_cpu_agent_byteenable |
byteenable | Host to Agent
|
4 | Enables one or more specific byte lanes during transfers on interfaces of width greater than 8 bits. Each bit in byteenable corresponds to a byte in writedata and readdata. The host bit <n> of byteenable indicates whether the IP is writing to byte <n>. During writes, byteenable specify which bytes the IP is writing to. Other bytes should be ignored by the agent. During reads, byteenable indicate which bytes the host is reading. Agents that return read data with no side effects are free to ignore byteenable signals during reads. If an interface does not have a byteenable signal, the transfer proceeds as if all byteenable signals are asserted. When more than one bit of the byteenable signal is asserted, all asserted lanes are adjacent. TMO IP ignores the byteenable signal. |
| av_mm_cpu_agent_write |
write | Host to Agent
|
1 | Asserted to indicate a write transfer. If present, writedata is required. Required for interfaces that support writes. |
| av_mm_cpu_agent_writedata |
writedata | Host to Agent
|
32 | Data for write transfers. The width must be the same as the width of readdata if both are present. Required for interfaces that support writes. |
| av_mm_cpu_agent_read |
read | Host to Agent
|
1 | Asserted to indicate a read transfer. If present, readdata is required. Required for interfaces that support reads. |
| av_mm_cpu_agent_readdata |
readdata | Agent to Host
|
32 | You dirve the readdata from the agent to the host in response to a read transfer. Required for interfaces that support reads. |
| av_mm_cpu_agent_readdatavalid |
readdatavalid | Agent to Host
|
1 | Use for variable-latency, pipelined read transfers. When asserted, indicates that the readdata signal contains valid data. For a read burst with burstcount value <n>, the readdatavalid signal must be asserted <n> times, once for each read data item. Ensure at least one cycle of latency between acceptance of the read and assertion of readdatavalid. An agent may assert read data valid to transfer data to the host independently of whether the agent is stalling a new command with waitrequest. Required if the host supports pipelined reads. Bursting hosts with read functionality must include the readdatavalid signal. |
| av_mm_cpu_agent_waitrequest |
waitrequest | Agent to Host
|
1 | An agent asserts waitrequest when unable to respond to a read or write request. Forces the host to wait until the interconnect is ready to proceed with the transfer. At the start of all transfers, a host initiates the transfer and waits until waitrequest is deasserted. A host must make no assumption about the assertion state of waitrequest when the host is idle: wait request may be high or low, depending on system properties. When wait request is asserted, host control signals to the agent must remain constant except for begin burst transfer. An Avalon memory mapped agent may assert waitrequest during idle cycles. An Avalon memory mapped host may initiate a transaction when waitrequest is asserted and wait for that signal to be deasserted. To avoid system lockup, an agent device should assert waitrequest when in reset. |
Clocks
| Signal Name | Direction |
Width (Bits) | Associated Interface | Description |
|---|---|---|---|---|
| internal_cpu_clock_clk | Input |
1 | N.A | Input clock for the soft-processor-based mapping LUT |
| external_cpu_clock_clk | Input | 1 | CPU control interface | Input clock for the external CPU control interface |
| video_clock_clk | Input | 1 | Video input and output interfaces | Input clock for the video and processing datapath |
| Device Family | Frequency range (MHz) |
|---|---|
| Intel Cyclone 10 GX | 150 to 300 |
| Intel Arria 10 | 150 to 300 |
| Intel Stratix 10 | 150 to 400 |
| Intel Agilex | 150 to 600 |
Frequency depends on:
- Number of pixels in parallel
- Maximum video resolution
- Device family
All three input clocks are asynchronous from each other. Internally, the TMO IP includes clock domain crossing (CDC) circuits for both single bit and data bus signal cases, which safely allows data exchange between any of the three asynchronous clock domains. The TMO IP also includes an embedded .sdc file, which provides all the necessary information to the Timing Analyzer. For system integration , when you instantiate the TMO IP in a design, the only constraints required are:
- Cock frequency constraints for the video clock (video_clock_clk)
- CPU clock (external_cpu_clock_clk)
- Soft-processor-based mapping LUT generator clock (internal_cpu_clock_clk)
Resets
| Name | Direction | Width (Bits) | Type | Associated Interface | Description |
|---|---|---|---|---|---|
| internal_cpu_reset_reset | Input | 1 | Active-high | N.A | Input reset for the soft-processor-based mapping LUT generator |
| external_cpu_reset_reset | Input | 1 | Active-high | CPU control | Input reset for the external CPU control interface |
| video_reset_reset | Input | 1 | Active-high | Video input and output | Input reset for the video and processing datapath |
Ensure before connecting the reset signals to the TMO IP, they are synchronized with their respective associated clock domain. Platform Designer provides a Reset Bridge IP for this task.