Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Transceiver Hello World!

Transceiver Hello World!



Dedicated on-chip transceivers can seem daunting to work with, but some simple hands-on experience can help explain how they work and how to begin designing with them. This page is intended to be the transceiver-equivalent of the common 'Hello World!' program that is used when first working with a new programming language, processor, compiler, etc.. Included is a zip-file that contains all source code, simulation compilation scripts, and a Quartus II project that together allow you to simulate the design and also generate a programming file that is ready to be loaded onto an Altera Stratix V Development Kit.

The Quartus II project also includes a SignalTap II file to inspect the functionality of the transceivers similar to the waveform result available in simulation. Taken together this design and page will introduct you to a simple transceiver implementation that you can use as a starting point to build more complex transeiver designs.


Example Design

The link below can be used to download the compressed zip-file containing all files needed from both simulation and the Quartus II v12.1 project:

simple_xcvr_top.zip

The files contained in the zip-file make use of relative paths so that it can be uncompressed in an root folder on your PC or Linux/UNIX system. There is a single variable in the top-level compilation script which should be tailored to the installation path for your version of Quartus II v12.1 (build 177), but this will be explained in more detail later on this page. Below is an explanation of the 4 subdirectories/folders that are created once you have uncompressed this zip-file:

DirectoryDescription
\QuartusII_v121_b177Contains all files related to the Quartus II v12.1 (build 177) project
\SimContains the top-level simulation compilation/invokation script as well as the testbench that instantiates the FPGA
\Source_HDLAll non-MegaWizard-generated files including the FPGA top-level
\Source_MegaCoresAll MegaWizard-generated files including the transceiver instance


Simulation

The simulation platform for this example design is ModelSim-Altera v10.1b that comes with Quartus II v12.1. Other simulation platforms can be used, but will require some work to tailor the compilation scripts and environment for that platform. If you have either ModelSim-Altera or the full version of ModelSim PE/SE, you will be able to perform simulation easily and quickly without and modifications to the files contained here.

Once you have uncompressed the zip-file within this page, follow these steps to perform simulation:

  1. In any text editor, open the top-level compilation script "compile_and_run_sim.tcl" that is within the \Sim directory
  2. If necessary, modify the "QII_LOCALLIB_SIM_PATH" variable to point to the same path (/quartus/eda/sim_lib) that corresponds to your local installation either on your local PC/system or your network. Note that this can be either a relative path or absolute path.
  3. Open ModelSim, and change to the \Sim directory
  4. Type "do compile_and_run_sim.tcl" within the Transcript window of ModelSim

This last step #4 directs ModelSim to begin executing the commands contained within the .tcl script. These will setup the simulation libraries, call Quartus-generated compilation scripts for each MegaCore (within the \Source_MegaCores directory) and also compile the non-MegaCore HDL files (within \Source_HDL), invoke the testbench, call a predefined waveform file of signals to inspect within ModelSim, 'force' a shorter reset duration for the simulation, and then run the simulation for 75 microseconds. The top-level simulation compilation script (compile_and_run_sim.tcl) is a good set of steps to inspect and modify to change how simulation is performed and also to understand what is happening at each step of the .tcl script from start to finish.

DEBUG TIP: If for any reason the simulation does not compile and complete as expected, comment-out all lines of the "compile_and_run_sim.tcl" script, and re-do step #4 above again. Because all portions of the .tcl script are commented-out, nothing should happen within ModelSim (because there are no executable commands within the .tcl script). At this point you can then begin un-commenting each line, one-by-one from top-to-bottom, and re-doing step #4 above again. This line-by-line iterative approach will allow you to easily debug what is happening that is not expected so you can change or correct that portion of the .tcl script. Below is a screenshot of the resulting waveform window:


6/6a/Sim_screenshot.jpg


You'll notice that different signals are grouped according to their hierarchy within the testbench and design. Some portions of the testbench to note are:

  • The top-level incoming clock and reset signals as well as the transceiver transmitter and receiver (within the "TB TOP LEVEL I/O" group). Note that the transceiver transmit output is looped-back to the receiver input within the testbench, similar to a board-level trace that could wrap this output back to the input for localized testing.
  • The Altera PLL lock signal (within the "IP - Altera PLL" group); you can zoom-in and inspect that it locks to its input clock.
  • Signal "reconfig_busy" within the "User Logic - LowLatencyPHY" group; this signal is a status output from the transceiver Reconfiguration Controller. This status pertains to the Offset Cancellation process which performs calibration of the transceiver(s) in the FPGA once immediatelly after configuration completes. Use of the transceivers to send or receive data cannot begin until after this calibration process successfully completes.
  • Signals "tx_ready" and "rx_ready"; these are the status of the transmit and receive portions of the transceiver.
  • Signals "tx_fsm" and "rx_fsm" which are the states of separate Finite State Machines (FSM's) operating on their respective recovered clock domains from the transceiver. These control both the transmission of data through the transciever, and the process of performing manual bitslip at the receive side to properly align to the incoming data.
  • Signals "tx_parallel_data" and "rx_parallel_data"; these are the data sent to the transmitter by the tx_fsm state machine as well as the received data by the rx_fsm. The rx_fsm performs bitslip to 'shift' the alignment of the transceiver's received data until it matches the expected pattern sent by the tx_fsm. Once bitslip causes the proper amount of shifting and the received pattern matches the transmitted pattern, the receiver is matched to the transmitter. At this point the rx_fsm signals to the tx_fsm to begin sending a repeating set of data (0x0A0B0A0B0A0B0A0B0A...) which is then properly received for the rest of the simulation.


Quartus II Project

The Quartus II project will perform both synthesis and place-and-route to convert the input HDL into logic gates that can be mapped into an Altera Stratix V FPGA as well as the routes between these gates that conform to the routing that exists within the Stratix V FPGA. The current FPGA and pinout specified in the project correspond to the Stratix V GX FPGA Development Kit (part number DK-DEV-5SGXEA7N0C). The HSMC loopback daughter cards should be installed on the HSMC connectors which will loop-back the transceiver TX/RX I/O so that the FPGA will receive its own transmitted data, similar to the simulation above. The project also contains a SignalTap II file (stp1.stp) which will allow you to inspect the process of bitslip similar to the simulation. Be aware that bitslip in both simulation and on the physical FPGA will stop when it aligns to the expected pattern, but the number of shifts or 'slips' will be different. This is due to the differences between the ideal simulation and the physical world. For instance, in simulation you will see the exact same number of shifts/slips each time you run the functional simulation because it does not incorporate any timing information.However, on actual hardware there are minute timing delays within the FPGA and both the transmit and receive portions of the transceiver will assert their 'tx_ready' and 'rx_ready' at slightly different times as they come out of reset. These slight timing and reset delays will cause the actual bitslip process on hardware to take a different amount of shifts/slips each time the FPGA is programmed. It is actually very instructive to to multiple sets of programming the FPGA and observing the SignalTap II file to see that the initially-received pattern and the number of bitslipts to achieve alignment change.

If you do not have the exact Altera Stratix V Development Kit mentioned here it is possible to change the project and characteristics to conform to either a different Devlopment Kit, device family (such as Arria II or Cyclone V), or your own custom hardware. If no external loopback path exists it is also possible to setup a loopback path within the FPGA ("internal serial loopback").


Possible Next Steps (Homework!)

Once you have successfully performed both simulation and a similar verification of the transceiver on hardware you can begin to make the design more complex. Suggestions include:

  • changing the transceiver data rate to perform at a higher rate
  • changing the TX PLL type between CMU and ATX PLL
  • add additional transceiver lanes either by making separate x1 instances or changing the existing x1 Low Latency PHY insance to be wider (x2, x4, etc.)
  • changing from the transceiver IP type to something other than Low Latency
  • changing the characterisitcs of the existing Low Latency PHY IP to have different interface widths on the tx_parallel_data and rx_parallel_data, or adding/removing other control/status ports and changing the user logic to accomodate these changes
  • making a more different alignment pattern to be transmitted and received
  • making a more complex repeating pattern to be transtmitted and received after bitslip
Attachments
Version history
Revision #:
1 of 1
Last update:
‎06-26-2019 01:25 AM
Updated by:
 
Contributors