Generating the Design

Specify a top-level name and the folder for your custom IP
variation, and the target device. Click OK.

Select a design from the Presets
library
by double-clicking the desired preset. When you select a
design, the system automatically populates the IP parameters for the
design.

Note: If you
select another design, the settings of the IP parameters change
accordingly.

You can customize the preset parameter values according to your specifications.
Under the IP tab, specify the JESD204B IP core parameters
for your design.

Note: Only a limited range
of parameter combinations are allowed for design generation. Please refer to
the Supported Configurations
section for more details. Parameter combinations that are not supported
results in the Available Example
Designs drop down box to display only None as the default.

Under the Example
Design tab, specify the design example parameters as described
in Design Example Parameters.

Note: To
generate the design example for hardware testing on selected Intel
development kits, select the appropriate target development kit from the
Target Development Kit drop down
box.

Click the Generate Example
Design button.

The software generates all design files in the
sub-directories. These files are required to run simulation, compilation, and hardware
testing.

Simulating the Design

These general steps describe how to run the design example
simulation. For specific commands for each design example variant, refer to its
respective section.

To simulate the design, perform the following steps:

Change the working directory to
<example_design_directory>/ed_sim/testbench/<Simulator>.

Run the simulation script for the simulator of your
choice
shown in the following
table

Simulator

Command

Riviera

do run_tb_top.tcl

NCSim

sh run_tb_top.sh

Modelsim

do
run_tb_top.tcl

VCS/VSCMX

sh
run_tb_top.sh

The simulation ends with messages that indicate whether
the run was successful or not. Refer to Simulation Message
and Description table in Testbench for more
information on messages reported by the simulation
flow.

Compiling and Testing the Design

The JESD204B IP Core parameter editor allows you to run the
design example on a target development kit.

If you are performing hardware testing on the selected Intel development kits, generate the design
example with the appropriate target development kit selected. Refer to the
instructions in Generating the Design.

Note: Running the hardware test
with the design generated as-is is only possible when the JESD204B IP core is
configured in duplex data path mode (i.e with both TX and RX data paths present).
Make your own modifications to the design to run the hardware test if generating a
simplex data path design.

The generated design has pre-assigned pins that target the relevant
boards. The following table describe the board connectivity of key design ports for
all supported target development kits.

The timing constraints and pin assignments for the design
example and the design components are automatically loaded during design example
compilation.

Connect the development board to the host computer either by
connecting a USB cable to the on-board Intel FPGA
Intel® FPGA Download Cable
II component or using an external Intel FPGA
Intel® FPGA Download Cable II module to connect to
the external JTAG connector.

Launch the Clock
Control application that is included with the development board
and set the clock settings according to the selected data rate.

Note: Refer to the
Intel®
Arria® 10 GX FPGA Development Kit documentation for more
information on using the Clock
Control application.

Table 4. Clock Setting

Clock Name

Clock Frequency

device_clk

Select
the frequencies in the PLL/CDR
Reference Clock Frequency drop down menu of
the IP Parameter Editor.3

In the TCL Console
command prompt, type get_service_paths
master to print a list of devices connected to your JTAG
chain.

Open the main.tcl Tcl script located in
the System Console directory in any text
editor of your choice and locate the following line.

set master_index [expr {$master_list_length - <your offset>}]

Adjust the master_index
offset as necessary to reflect your JTAG chain configuration such that the
master_index always points to the
Intel®
Arria® 10 device and save the file.

In the TCL Console
command prompt, navigate to the system_console directory (cd
system_console) and execute the main.tcl script (source
main.tcl). Your TCL
Console window should resemble the following figure.

Figure 5. Source main.tcl

Type start_basic_test
at the command prompt to execute the link setup and test procedure.

This procedure executes a set of instructions to set up the
pattern generator and checker to transmit and check PRBS pattern, configure the
JESD204B IP PHY internal serial loopback mode and report link status.

The following figure illustrates the expected result from a
successful link setup and test.

Figure 6. Successful Test in the System Console

In the event that the test failed due to a lane deskew error,
use the rbd_offset procedure (described
in the following table) to offset the default RBD setting. Refer to the JESD204B
IP User Guide for more details on using the RBD offset.

Table 5. Procedures in the main.tcl System Console Script . Table describes useful procedures in the main.tcl that may be helpful in
debugging.

Procedure

Values

Description

get_service_paths

{master}

Reports all devices that are connected
to the JTAG chain. Use this information to set the master
index to point to the
Intel®
Arria® 10 device

get_master_index

N/A

Set the targeted device master index. Use
get_service_paths master to determine the offset of the
Intel®
Arria® 10 device in the JTAG
chain, and edit the offset in this procedure
accordingly.

Click Next. Verify that the default BSP name is
<software project>_bsp, then click
Finish. The Nios II application project and BSP
appears in the Project Explorer window.

In the Project Explorer window, right-click the
<software project>_bsp project, navigate to Nios II
and click Generate. This regenerates the BSP files based
on your most current compiled
Intel®
Quartus® Prime project
settings.

Note: Whenever you
modify and recompile the
Intel®
Quartus® Prime
project, you must regenerate the BSP files.

Import the design example source (*.c) and header
(*.h) files into the application directory. In the
Project Explorer window, right click on the
<software project> project and click
Import.

In the Import window, select General > File System as the import source and click Next.

Browse to the <design example>/software/source
directory. Check the source box on the left panel. This selects all the source
and header files in the source directory. Verify that the list of source and
header files are as follows:

altera_jesd204_regs.h

functions.h

macros.h

main.h

macros.c

main.c

Verify that the destination folder is <software
project>. Click Finish.

All the source and header files should be imported into the <software
project> project directory.

Right-click the <software project>_bsp project,
navigate to Nios II > BSP Editor . Under the Drivers tab, check the
enable_small_driver box of the
altera_avalon_jtag_uart_driver group and click
Generate. This setting allows the compilation to
proceed without connecting the interrupt ports of the JTAG UART module. After
the BSP files have been generated, click Exit.

Expand the <software project> application project in
the Project Explorer window and verify that the folder
contains all the source and header files.

To compile the C code, navigate to Project > Build All.

The compiler now compiles the C code into executable code.

To download the executable code to the development board, navigate to the Run > Run Configurations. In the Run Configurations window,
double-click Nios II Hardware on the left panel.

Verify that all run configurations are correct, then click
Run.

The
Intel®
Quartus® Prime software downloads
the executable code onto the board and the Nios II processor executes the code. The
code performs the JESD204B link initialization sequence and exits. You can view the
code execution results on the Nios II
Console tab. The Nios II
Console is the standard input/output for the executable code. At the
end of the initialization sequence, the code prints the JESD204B link status to the
console. The following figure illustrates the expected result from a successful link
initialization.

The following tables list the expected values of the link status
register report.

Hardware and Software Requirements

Intel uses the following hardware and software to test the example
designs:

Intel®
Quartus® Prime software

Intel®
Arria® 10 GX FPGA Development
Kit

Supported Configurations

The design examples only support a
limited set of JESD204B IP core parameter configurations. The IP
parameter
editor allows you to generate a design example only if the parameter configurations matches
the following table.

Note: If you are
not able to generate a design example that fully matches your desired parameter settings,
choose the closest allowable parameter values for generation. Modify the post-generated
design parameters manually in the
Intel®
Quartus® Prime software to
match your desire parameter settings. Refer to the JESD204B IP Core
User Guide for more details on the rules and ranges that govern each IP core and
transport layer parameter.
Refer to
Customizing the Design Example for more information about customizing the
design example.

Table 8. Supported JESD204B IP Core Parameter Configurations. Table lists the parameters for the JESD204B IP core. The JESD204B IP
core parameters are governed by various rules and ranges that are described in the JESD204B IP Core User Guide. Please refer to the JESD204B IP Core User Guide for more details on the legal
parameter values. The value ranges given below should be considered as a subset of the
allowable values described in the JESD204B IP Core User
Guide.

Presets

Standard presets allow instant entry of pre-selected parameter values in the
IP and Example
Design tabs. Select the presets at the lower right window in the parameter
editor shown in Figure 1.

The parameter values chosen for the presets belong to the group of supported
JESD204B IP configurations for design example generation. You can select one of the presets
available for your target device to quickly generate a design example without having to
manually set each parameter in the IP tab and verifying that the parameter matches the
supported configurations set. You can manually change any of the IP and example design
parameters in the Platform Designer user interface after selecting a preset. However,
you must ensure that your parameter selection falls within the supported configuration ranges
detailed in Supported Configurations for example design generation
to be successful.

Note: Selecting a preset overwrites any
pre-existing parameter selections for the IP core under the IP tab.

Table 9. Preset Settings

JESD204B IP Parameters

Preset 1

Preset 2

Wrapper Options

Both Base and Phy

Both Base and Phy

Data Path

Duplex

Duplex

JESD204B Subclass

1

1

Data Rate

6144 Mbps

6144 Mbps

PCS Option

Enabled Hard PCS

Enabled Hard PCS

Bonding Mode

Non-bonded

Non-bonded

PLL/CDR Reference Clock Frequency

153.6 Mhz

153.6 Mhz

Enable Bit Reversal and Byte Reversal

No

No

Enable Transceiver Dynamic Reconfiguration

No

No

L

2

8

M

2

8

Enable manual F configuration

No

Yes

F

2

8

N

16

12

N’

16

12

S

1

5

K

16

32

Enable Scramble (SCR)

No

No

CS

0

0

CF

0

0

High Density User Data Format (HD)

0

0

Enable Error Code Correction (ECC_EN)

No

No

Functional Description

The design examples consist of various components. The following block diagrams show the
design components and the top-level signals of the design examples.

Transport Layer

The transport layer in the design example consists of an assembler at the TX
path and a deassembler at the RX path. The transport layer for both the TX and RX path is
instantiated in the top level RTL file, not in the Platform Designer project.

Note: When the simplex TX data path option is selected, only the assembler is instantiated in
the design example. When the simplex RX data path option is selected, only the deassembler is
instantiated in the design example. When the duplex data path option is selected, both
assembler and deassembler is instantiated in the design example.

The transport layer provides the following services to the application layer (AL) and the
data link layer (DLL):

Assembler at the TX path:

Maps the conversion samples from the AL (through the Avalon-ST interface) to a
specific format of non-scrambled octets, before streaming them to the DLL.

Reports AL error to the DLL if it encounters a specific error condition on the
Avalon-ST interface during TX data streaming.

Deassembler at the RX path:

Maps the descrambled octets from the DLL to a specific conversion sample format before
streaming them to the AL (through the Avalon-ST interface).

Reports AL error to the DLL if it encounters a specific error condition on the
Avalon-ST interface during RX data streaming.

The transport layer has many customization options and you can modify the transport layer
RTL to customize it to your specifications. Furthermore, for certain parameters like L, F, and
N, the transport layer shares the CSR values with the JESD204B IP core.

For more details on the implementation of the transport layer in RTL and
customization options, refer to the JESD204B IP Core User
Guide.

Test Pattern Generator

Note: This module is only available in the design
example when the duplex or simplex TX data path option is selected.

The test pattern generator generates either a parallel PRBS, alternate
checkerboard, or ramp wave and sends it to the transport layer during test mode. The test
pattern generator is implemented in the top level RTL file, not in the Platform Designer project.

The
test pattern generator has many customization options and you can modify the test pattern
generator RTL to customize it to your specifications. Furthermore, for parameters like M, S,
N, and test mode, the test pattern generator shares the CSR values with the JESD204B IP core.
This means that any dynamic reconfiguration operation that affects those values for the
JESD204B IP core, affects the test pattern generator in the same way. This includes the
pattern type (PRBS, alternate checkerboard, ramp) which is controlled by the test mode
CSR.

For
more details on the JESD204B IP core CSR (register map), refer to the JESD204B IP Core User Guide.

Test Pattern Checker

Note: This module is only available in the design
example when the duplex or simplex RX data path option is selected.

The test pattern checker checks either a parallel PRBS, alternate
checkerboard, or ramp wave from the transport layer during test mode and outputs an error flag
if there are any data mismatches. The test pattern checker is implemented in the top level RTL
file, not in the Platform Designer project.

The
test pattern checker has many customization options and you may modify the test pattern
checker RTL to customize it to your specifications. Furthermore, for parameters like M, S, N,
and test mode, the test pattern checker shares the CSR values with the JESD204B IP core. This
means that any dynamic reconfiguration operation that affects those values for the JESD204B IP
core, affects the test pattern checker in the same way. This includes the pattern type (PRBS,
alternate checkerboard, ramp) which is controlled by the test mode CSR.

For
more details on the JESD204B IP core CSR (register map), refer to the JESD204B IP Core User Guide.

Clocking Scheme

The main reference clock for the design example is
device_clk. This clock must be supplied from an external source. The
device_clk is the reference clock for the core PLL, ATX PLL and the TX/RX
transceiver PHY. The core PLL generates the link_clk and
frame_clk from device_clk. The link_clk
clocks the JESD204B IP core link layer and link interface of the transport layer. The
frame_clk clocks the transport layer, test pattern generator and checker
modules, and any downstream modules. An external source supplies a clock called the
mgmt_clk to clock the Avalon-MM interfaces of Platform Designer
components.

Table 14. System Clocking for the Design Example.

Note: The IOPLL input reference
clock is sourcing from device clock through the global clock network. Sourcing reference
clock from a cascaded PLL output, global clock or core clock network
might
introduce additional jitter to the
IOPLL
and transceiver PLL output. Refer to this KDB Answer for a workaround you should apply to
the IP core in your design.

Simulation

Note: The simulation flow is only supported for System Console Control design
example only. The simulation flow is not supported for Nios Control design example.

Execute the simulation by running the relevant simulation run scripts in the
supported simulator environment. The following table shows the simulators supported along with
the relevant run scripts.

Table 15. Supported Simulators

Simulators

Simulation Directory

Run Script

Riviera

/testbench/aldec/

run_tb_top.tcl

NCSim

/testbench/cadence/

run_tb_top.sh

Modelsim

/testbench/mentor/

run_tb_top.tcl

VCS

/testbench/synopsys/vcs/

run_tb_top.sh

VCSMX

/testbench/synopsys/vcsmx/

run_tb_top.sh

The design generates the simulation results which include the transcript or
log files in the relevant simulation directory.

Testbench

The simulation design-under-test (DUT) is the generated design example which includes a
synthesizable pattern generator and checker. The figures below show the testbench block
diagram for simplex and duplex options.

Figure 14. Simulation Testbench Block Diagram (Simplex TX or RX)

Note: Both simplex TX and simplex RX design examples generate the same testbench. The testbench
instantiates two DUTs: one simplex TX DUT, one simplex RX DUT. The TX serial data output of
the simplex TX DUT is connected to the RX serial data input of the simplex RX DUT. The
testbench issues separate Avalon-MM read/write instructions to the simplex TX and simplex RX
DUTs respectively.

Figure 15. Simulation Testbench Block Diagram (Duplex)

The simulation flow replaces the JTAG to Avalon master bridge module in the
Platform Designer system of the System Console Control design example
with the Avalon-MM master bus functional model (BFM). This BFM enables a testbench to send
Avalon-MM read/write commands to the design example registers to mimic the functionality of
System Console.

The testbench provided in the simulation flow
(/testbench/models/tb_top.sv) executes the following steps:

Reset DUT

Initialize BFM

Execute Avalon-MM commands to initialize the DUT in the following mode:

Internal serial loopback mode (for duplex option only)

Pattern generator/checker set to PRBS pattern

Wait for DUT to initialize to user mode

Report JESD204B link status

When simulation ends, the following messages are shown at end.

Table 16. Simulation Messages and Description

Message

Description

Pattern Checker(s): Data error(s) found!

Pattern mismatch errors found on the pattern checker

Pattern Checker(s): OK!

No errors found on the pattern checker

Pattern Checker(s): No valid data found!

No valid data received by pattern checker

JESD204B Tx
Core(s): Tx link error(s) found!

Link errors reported by JESD204B IP TX

JESD204B Tx Core(s): OK!

No link errors reported by JESD204B IP TX

JESD204B Rx Core(s): Rx link error(s) found!

Link errors reported by JESD204B IP RX

JESD204B Rx Core(s): OK!

No link errors reported by JESD204B IP RX

TESTBENCH_PASSED: SIM PASSED!

Overall simulation passed

TESTBENCH_FAILED: SIM FAILED!

Overall simulation failed

Design Example Files

There are two flows for the design example: simulation and synthesis.

Table 17. Design Example Flows and Directory

Design Example Flow

Directory

Simulation

<your project>/ed_sim

Synthesis

<your project>/ed_synth

The following tables list the important folders and files for simulation and
synthesis.

Table 18. Design Example Files for Simulation.

Note: The simulation flow is only supported for System Console Control design
example only. The simulation flow is not supported for Nios Control design
example.

The software C code included as part of the design example only performs basic JESD204B link
initialization. You can modify the code to perform some or all of the tasks above as per your
system specifications. The software C code (main.c) executes a sequence
of tasks as shown in the figure below.

Note: The software C code assumes that the Nios Control design is configured in duplex mode.
Make your own modifications if using simplex mode design.

Figure 16. Software C Code Task Sequence

The JESD204B link initialization sequence accomplishes the following tasks:

Set the pattern type for the pattern generator and checker. The default pattern type is
set to PRBS.

Set the loopback mode. The default is internal serial loopback mode.

Pulse SYSREF (required to meet Subclass 1 requirements)

Wait 10 seconds to allow for changes to take effect.

Report the link status.

Software Parameters

The software parameters defined in the main header file
(main.h) control various behaviors of the C code.

Table 21. Software Parameters

Parameter

Default Value

Description

DEBUG_MODE

0

Set to 1 to print debug messages, else set to
0.

PRINT_INTERRUPT_MESSAGES

1

Set to 1 to print JESD204B error interrupt
messages, else set to 0.

PATCHK_EN

1

Set to 1 when test pattern checker is included in
the initial design data path configuration, else set to 0.

DATAPATH

3

Set to indicate the JESD204B IP
configuration:

1 – TX data path only.

2 – RX data path only.

3 – Duplex data path (TX and RX data path).

MAX_LINKS

1

Set to indicate the number of links in the design
(for example, for dual link, set MAX_LINKS=2). See Implementing
a Multi-Link Design section for more detailed instructions on
implementing multi-link use case.

Note: When using the design as-is, the maximum value
of MAX_LINKS is 16. To increase the limit, redesign the address
map in Platform Designer.

LOOPBACK_INIT

1

Initial value of the loopback. Set to 1 for
internal serial loopback mode, else set to 0.

SOURCEDEST_INIT

PRBS

Initial value of source/destination. Set to
indicate test pattern generator or checker type or user
mode:

The error types correspond to the tx_err, rx_err0,
and rx_err1 status registers in the JESD204B IP core TX and RX
register maps respectively. Refer to the JESD204B RX Address Map and Register
Definitions and JESD204B TX Address Map and Register
Definitions for more details on the TX and RX error registers. The
PRINT_INTERRUPT_MESSAGES parameter in the main.h header file
controls the printing of interrupt error messages to the standard output. Set the
parameter to 1 (default) to print error messages, else set to 0. Refer to Software Parameters for more details. You can modify
the ISRs in the C code to customize the interrupt handling response based on your
system specifications.

Software Functions Description

The software C code generated with the design example performs basic JESD204B link
initialization and exits. This section describes the functions used in the
main.c code and also the macros library that facilitates access to the
configuration and status registers (CSR) of the JESD204B design example system. These
functions and macros provide the building blocks for you to customize the software code to
your system specifications.

Functions in main.c Source File

The function
prototypes of the functions listed in the table below can be found in the
functions.h header file located in the software
folder.

Table 22. Functions in main.c

Function Prototype

Description

int StringIsNumeric (

char *string)

Tests whether the string is numeric. Returns 1 if
true, 0 if false.

void DelayCounter(

alt_u32 count)

Delay counter. Counts up to count ticks, each
tick is roughly 1 second.

Triggers full hardware reset sequence through the
PIO control registers.

int ResetSeq (

int link,

int *held)

Performs full hardware reset sequence through the
software interface on the indicated link. Returns 0 if success, 1 if
fail.

int ResetForce (

int link,

int reset_val,

int hold_release,

int *held_resets)

Forces reset assertion or deassertion on
submodule resets indicated by reset_val for the indicated link. The function also
decides whether to assert and hold (hold_release=2), deassert
(hold_release=1), or pulse (hold_release=0) the indicated resets.
The function has mechanisms using the global
held_resets flag to ensure that held resets that are
not the target of the reset force function are not affected by it.
Returns 0 if success, 1 if fail.

int Reset_X_L_F_Release (

int link,

int *held_resets)

Deassert the transceiver, link, and frame resets.
The function deasserts the TX transceiver reset first, waits until
the TX transceiver ready signal asserts, then deasserts the TX link
and TX frame resets. The function then repeats the above actions for
the RX side. Returns 0 if success, 1 if fail.

void InitISR (void)

Initializes the interrupt controllers for the
following peripherals:

JESD204B IP core TX CSR

JESD204B IP core RX CSR

SPI Master

The timer and JTAG UART interrupt
controllers are disabled. Modify the function to enable it.
Refer to the Nios II Software Developer’s Handbook for more
details on writing ISRs.

static void ISR_JESD_RX (

void * context)

JESD204B IP core RX ISR. Upon an interrupt event
(IRQ asserted), the function reads the RX JESD204B CSR rx_err0 and rx_err1 registers and reports the error code. After
that, the ISR clears all valid and active status registers in the
rx_err0 and rx_err1 registers. Refer to the Nios II
Software Developer’s Handbook for more details on writing
ISRs.

static void ISR_JESD_TX (

void * context)

JESD204B IP core TX ISR. Upon an interrupt event
(IRQ asserted), the function reads the TX JESD204B CSR tx_err registers and reports the error
code. After that, the ISR clears all the valid and active status
registers in the tx_err registers.
Refer to the Nios II Software Developer’s Handbook for more details
on writing ISRs.

Custom Peripheral Access Macros in macros.c Source File

A set of peripheral access macros are provided for you to access specific information
in the CSR of the following peripherals:

Reset sequencer

JESD204B TX

JESD204B RX

PIO control

PIO status

Transceiver Native PHY IP core

ATX PLL

Core PLL Reconfiguration

The function prototypes of the macros listed in the table below can be found in the
macros.h header file located in the software folder.

Table 23. Custom Peripheral Access Macros in macros.c

Function Prototype

Description

int CALC_BASE_ADDRESS_LINK (int base , int link)

Calculates and returns the base address based on the link provided. In the Platform Designer system (jesd204b_ed_qsys.qsys)
address map, bits 16-19 are reserved for multi-link addressing. The
address map allocation allows for up to a maximum of 16 links to be
supported using the existing address map. The number of multi-links in
the design is defined by the MAX_LINKS parameter in the main.h header file. You are responsible to set the
parameter correctly to reflect the system configuration.

int CALC_BASE_ADDRESS_XCVR_PLL (int base , int instance)

Calculates and returns the base address of the TX
transceiver PLL (ATX PLL) based on the instance
number. In the JESD204B subsystem (jesd204b_subsystem.qsys) address map, bits 12-13 are
reserved for multi ATX PLL addressing. The address map allocation allows
for up to a maximum of four ATX PLLs per link to be supported using the
existing address map. The number of ATX PLLs per link in the design is
defined by the XCVR_PLL_PER_LINK
parameter in the main.h header
file. You are responsible to set the parameter correctly to reflect the
system configuration.

Modifying the JESD204B IP Core Parameters

The Platform Designer tool allows only a
limited set of design examples to be generated based on the JESD204B IP core parameters
selected.

Perform the following instructions to modify the JESD204B IP core
parameters post-generation:

Open the generated design example project in the
Intel®
Quartus® Prime software.

Open the altera_jesd204_subsystem_<data
path>.qsys system in Platform Designer.

In the System Contents
tab, double-click the altera_jesd204_<data
path> module. This brings up the parameter
editor that shows the current parameter settings of the JESD204B IP core.

Modify the parameters of the JESD204B IP core module as per
your system specifications. When you are done, save the Platform Designer
system (File > Save).

Note: The
JESD204B IP core and transport layer imposes certain limits on the values
that can be entered as parameters. Please refer to the JESD204B IP Core User
Guide for a complete listing of the legal parameter values.

After the HDL generation is completed, click the Finish to save your settings and exit Platform Designer.

You have to manually change the system parameters in the top
level RTL file to match the parameters that you set in the Platform Designer project, if applicable. Open the top
level RTL file (altera_jesd204_ed_<data
path>.sv) in any text editor of your choice.

Modify the system parameters at the top of the file to match
the new JESD204B IP core settings in the Platform Designer project, if applicable.

Take note
when changing the F1_FRAMECLK_DIV and F2_FRAMECLK_DIV frame clock division factor parameters in the
top level RTL file altera_jesd204_ed_<data
path>.sv
for cases when F=1 or F=2. These parameters further divide-down the frame clock
frequency requirement so the resulting clock frequency is within bounds of
timing closure for the FPGA core fabric.

The
frame clock and the link clock for the following cases share the same
frequency:

F=1—the default parameter value for F1_FRAMECLK_DIV=4

F=2—the default parameter value for F2_FRAMECLK_DIV=2

F=4

Perform the following instructions to modify the JESD204B IP core
parameters post-generation:

Open the generated design example project in the
Intel®
Quartus® Prime software.

Open the top level altera_jesd204_ed_qsys_<data
path>.qsys in the Platform Designer.

In the System Contents
tab, right-click the
altera_jesd204_subsystem_<data
path> module and select Drill into Subsystem. This opens the altera_jesd204_subsystem_<data
path>.qsysPlatform Designer subsystem.

Double-click the
altera_jesd204_<data
path> module. This brings up the parameter
editor that shows the current parameter settings of the JESD204B IP core.

Modify the clock frequency values of the
device_clk,
link_clk, frame_clk and mgmt_clk
clock source modules as necessary to meet your system requirements. Double-click
the clock source module to bring up the parameters editor and change the
Clock frequency value as necessary.
Ensure that the values match the clock frequency values that you have entered
for the other modules above.

Navigate back to the top level altera_jesd204_ed_qsys_<data
path>.qsys hierarchy.

Double-click the xcvr_atx_pll_0 module to bring up the parameters editor for the
ATX PLL module.

This is the module that generates the serial clock for the TX
transceiver PHY.

Under the PLL subtab,
locate the Output Frequency group and
change the PLL output frequency and
PLL integer reference clock frequency
values to meet your system requirements.

The PLL output frequency is half of the PLL output data rate.
Ensure that the data rate and PLL reference clock values match the parameters
that you entered into the JESD204B IP core module.

Double-click the core_pll
module to bring up the parameters editor for the core PLL
module.

This is the module that generates the
link_clk
and
frame_clk
clocks that clock the core components.

Under the PLL subtab,
change the Reference Clock Frequency
value in the General group to meet your
system requirements.

Ensure that the reference clock frequency value matches the ones set for
the
JESD204B
IP core and
ATX
PLL modules.

Change the
outclk0
group settings (which correspond to the
link_clk)
and
outclk1
group settings (which correspond to the
frame_clk)
where necessary.

Ensure that the
link_clk
and
frame_clk
values satisfy the frequency requirements as described in the JESD204B IP Core
User Guide.

Modify the clock frequency values of the
device_clk, , link_clk, frame_clk and mgmt_clk
clock source modules as necessary to meet your system requirements. Double-click
the clock source module to bring up the parameters editor and change the
Clock frequency value as necessary.
Ensure that the values match the clock frequency values that you have entered
for the other modules in earlier steps.

After the HDL generation is completed, click the Finish to save your Platform Designer settings and exit the Platform Designer window.

If the frame_clk settings (outclk1 of the core_pll module) are
such that F1_FRAMECLK_DIV or F2_FRAMECLK_DIV values are changed, change the
parameters in the top level design file,
altera_jesd204_ed_<data
path>.sv.

Modify the clock constraints in the SDC constraints file
(altera_jesd204_ed_<data
path>.sdc) to reflect your new clock frequency
values, if applicable. The following constraints should be modified:

Updated SDC constraint to be modified in Changing the
Data Rate or Reference Clock Frequency.

Added get_master_index procedure in
Procedures in the main.tcl System Console
Script table.

Updated document title.

Updated instances of Qsys to Platform Designer.

Added note to System Clocking for the Design
Example table about additional jitter introduced
to the ATX, fPLL, and transmit PLL output when using
reference clock from a cascaded PLL output, global clock or
core clock network.