Hybrid Memory Cube Controller IP Core User Guide - Intel Stratix 10 Beta Version

Download PDF
ID 683854
Date 8/08/2016
Public
Document Table of Contents
Document Table of Contents x
1. About the Hybrid Memory Cube Controller IP Core 2. Getting Started with the HMC Controller IP Core 3. Functional Description 4. HMC Controller IP Core Signals 5. HMC Controller IP Core Register Map 6. HMC Controller IP Core Stratix 10 Design Example A. HMC Controller IP Core User Guide Archives B. Additional Information
1. About the Hybrid Memory Cube Controller IP Core x
1.1. HMC Controller IP Core Supported Features 1.2. HMC Controller IP Core Supported HMC Transaction Types 1.3. Device Family Support 1.4. IP Core Verification 1.5. Performance and Resource Utilization 1.6. Device Speed Grade Support 1.7. Release Information
1.4. IP Core Verification x
1.4.1. Simulation
2. Getting Started with the HMC Controller IP Core x
2.1. Installing and Licensing Intel® FPGA IP Cores 2.2. Specifying IP Core Parameters and Options 2.3. HMC Controller IP Core Parameters 2.4. Files Generated for Intel FPGA IP Cores 2.5. Integrating Your IP Core in Your Design 2.6. Simulating Intel FPGA IP Cores
2.1. Installing and Licensing Intel® FPGA IP Cores x
2.1.1. Intel® FPGA IP Evaluation Mode
2.3. HMC Controller IP Core Parameters x
2.3.1. RX Mapping and TX Mapping Parameters
2.5. Integrating Your IP Core in Your Design x
2.5.1. Pin Constraints 2.5.2. Required External Blocks
2.5.2. Required External Blocks x
2.5.2.1. Adding the External PLL 2.5.2.2. Adding the External I2C Master Module
3. Functional Description x
3.1. High Level Block Diagram 3.2. Interfaces Overview 3.3. Clocking Structure 3.4. Initialization and Reset 3.5. M20K ECC Support 3.6. Flow Control 3.7. Error Detection and Management 3.8. Testing Features
3.2. Interfaces Overview x
3.2.1. Application Interfaces 3.2.2. HMC Interface 3.2.3. Interface to External I2C Master 3.2.4. Control and Status Register Interface 3.2.5. Status and Debug Interface 3.2.6. Transceiver Control Interfaces
3.2.6. Transceiver Control Interfaces x
3.2.6.1. External PLL Interface 3.2.6.2. Transceiver Reconfiguration Interface
4. HMC Controller IP Core Signals x
4.1. Application Interface Signals 4.2. HMC Interface Signals 4.3. Signals on the Interface to the I2C Master 4.4. Control and Status Register Interface Signals 4.5. Status and Debug Signals 4.6. Clock and Reset Signals 4.7. Transceiver Reconfiguration Signals 4.8. Signals on the Interface to the External PLL
4.1. Application Interface Signals x
4.1.1. Application Request Interface 4.1.2. Application Response Interface 4.1.3. HMC Controller IP Core Data Path Example
5. HMC Controller IP Core Register Map x
5.1. CONTROL Register 5.2. XCVR_STATUS Register 5.3. LANE_STATUS Register 5.4. LINK_STATUS Register 5.5. ERROR_RESPONSE Register 5.6. LIMIT_OUTSTANDING_PACKETS Register 5.7. Interrupt Related Registers 5.8. Error and Retry Statistics Registers
B. Additional Information x
B.1. HMC Controller IP Core User Guide Revision History
1. About the Hybrid Memory Cube Controller IP Core
2. Getting Started with the HMC Controller IP Core
3. Functional Description
4. HMC Controller IP Core Signals
5. HMC Controller IP Core Register Map
6. HMC Controller IP Core Stratix 10 Design Example
A. HMC Controller IP Core User Guide Archives
B. Additional Information

4.1.1. Application Request Interface

The data path request interface, or application request interface, provides a 512-bit data bus and dedicated signals for the application to provide HMC request packet field values to the HMC Controller IP core. The interface supports Write requests with payload sizes up to 128 bytes. The maximum payload size limits the interface to data bursts of 2 or fewer core_clk clock cycles. Write requests and read responses with a payload size that is not a multiple of the bus size carry the end of the payload in the lower order bits of the data bus in the final clock cycle.

Your IP core can have one, two, three, or four data path request interfaces. The interfaces are numbered and if you turn off the Response re-ordering parameter, each is restricted to a set range of tags. If you violate this restriction, the results are undefined.

The application must provide the following routing and control information for every request it sends on the TX data path interface:

  • A well-formed HMC destination address.
  • A unique 9-bit in-flight tag (if you turn off Response re-ordering). This requirement does not apply to posted transaction requests. In the case of multiple ports, each port is assigned a range of tags for its exclusive use. The application can reuse a tag only after the previous transaction with that tag is completely resolved.
  • A correct 3-bit cube ID.

In addition, the application must ensure that it sends a request only when it is able to receive the response to the request as soon as that response arrives.

Figure 16. Application to HMC Controller IP Core With Single PortThe client acts as a source and the HMC Controller acts as a sink in the transmit direction.
Figure 17. Application to HMC Controller IP Core With Multiple Ports

The client acts as a source and the HMC Controller acts as a sink in the transmit direction. N is the number of ports you specify with the Ports parameter.

Table 11.  Signals of Each Data Path Request InterfaceAll interface signals are synchronous with the core_clk clock. If the IP core has multiple ports, the port number is part of the signal name, as shown. If the IP core has a single port, the port number is not included in the signal name, for backward compatibility with previous releases of the IP core. If the IP core has two ports, it has two sets of signals, one with n=0 and one with n=1. If the IP core has four ports, it has four sets of signals, with n=0,1,2,and 3.

Signal Name

Direction

Description

dp<n>_req_ready

Output

When the HMC Controller IP core asserts this signal, the IP core is ready to receive data. The HMC Controller IP core accepts data when both dp<n>_req_ready and dp<n>_req_valid are asserted in the same cycle.

The IP core deasserts this signal to back-pressure the application when it cannot currently process any incoming requests.

The IP core does not deassert this signal between the cycles of a multi-cycle write data transfer.

dp<n>_req_valid

Input

Indicates that the transaction is valid—all input signals have valid values. The HMC Controller IP core accepts data on the rising edge of core_clk when both dp<n>_req_ready and dp<n>_req_valid are asserted.

The application must maintain this signal asserted during a multi-cycle write data transfer.

The application can send back-to-back requests by maintaining the dp<n>_req_valid signal asserted.

Note: For requests that require a response, the application must update the value it drives on dp<n>_req_tag for the new request. If the application continues to drive the old values on the input signals, that new request has the same tag as the previous request.
dp<n>_req_tag[8:0]

Input

The user-generated tag associated with this request. The corresponding response returns with the identical tag.

This signal is not available if you turn on Response re-ordering. In that case the IP core manages tags internally.

The value of this signal is a Don't Care for posted transaction requests. Because these requests have no corresponding response that must be identified, they do not require meaningful tag values.

You must ensure every tag in use at any given time by a non-posted transaction is unique. After a response returns, the tag is available for re-use.

If your IP core has multiple ports, each port is restricted to a specific range of tags:
  • Two ports: port 0 tag range is 0 to 255, and port 1 tag range is 256 to 511.
  • Three ports: port 0 tag range is 0 to 175, port 1 tag range is 176 to 351, port 2 tag range is 352 to 511,
  • Four ports: port 0 tag range is 0 to 127, port 1 tag range is 128 to 255, port 2 tag range is 256 to 383, and port 3 tag range is 384 to 511.
Results are undefined if this restriction is violated.

The application must maintain the value on this signal during a multi-cycle write data transfer.

dp<n>_req_cmd[5:0]

Input

Indicates the packet command associated with this request. Refer to Table 17 in the HMC Specification v1.1 for the command encodings.

The application must maintain the value on this signal during a multi-cycle write data transfer.

dp<n>_req_cube[2:0]

Input

The CUB ID of the cube to which the request is directed.

The application must maintain the value on this signal during a multi-cycle write data transfer.

dp<n>_req_addr[33:0]

Input

Target address in the external HMC device. Current HMC devices ignore the four least significant bits of the address (and assumes they have the value of 4'b0000) in all requests the HMC Controller IP core generates, except for the BIT WRITE request.

The application must maintain the value on this signal during a multi-cycle write data transfer.

dp<n>_req_data[511:0]

Input

Write data.

The application must transfer the least significant bytes of the write payload in the first cycle.

If the size of the payload is not an integer multiple of the data bus width, then in the final data transfer cycle, the application must transfer the remaining write payload in the least significant bytes of dp<n>_req_data or dp_req_data. For example, the application must:

  • Transfer a 16-byte payload in dp_req_data[127:0].
  • Transfer a 32-byte payload in dp_req_data[255:0].
  • Transfer the final (most significant) 48 bytes of a 112-byte payload in dp_req_data[383:0] in the second data transfer clock cycle.

During a read request, the value on this data bus does not matter.

dp<n>_req_sop Input Start of packet. The application must assert this signal in the first cycle of all transactions.
dp<n>_req_eop Input End of packet. The application must assert this signal in the final cycle of all transactions.
Level Two Title