Forum Discussion
Transceiver Toolkit Design Example
Hi, I've recently purchased a Stratix V GX Transceiver Signal Integrity Development Kit and I want to use it to transmit and receive data at 10 Gbps so I can study how our optical circuit affects the BER.
To this end I've downloaded the Transceiver Toolkit Design Examples from the 'On-chip Debugging Design Examples' webpage. I want to implement the one in the 'sv_1ch_40b_10312mbps' folder, but I ran into some problems. Firstly the example is for a 5SGTC7 device, and my device is 5SGXA7. But the AN644 document (Migration Between Stratix V GX and Stratix V GT Devices) has led me to believe that I can safely migrate the design just by changing the device name and recompiling. After I programmed the board and loaded the design in the Transceiver Toolkit, I attempted to control the Transmitter Channel but I'm unable to get the board to transmit data. Pressing the Start button on that screen has no effect, and the Stop and Inject Error buttons remain permanently grayed out. I ran the link_test.tcl script included with the design and got this error: "Test stopped because checker cannot lock to incoming data pattern". Then I tried using data_pattern_generator_start and data_pattern_generator_is_generating commands to see if the generator is actually working, and I always got a negative result. Any suggestions?14 Replies
- Altera_Forum
Honored Contributor
First check that the transmitter and receiver are being enabled. There is a very specific reset sequence required on the Stratix IV devices, and I assume there is a similar requirement for the Stratix V devices. For example, check the PLLs are locked. Use SignalTap to probe the enables, status bits, lock bits etc. Use it to become familiar with the IP.
You can then use SignalTap to probe the transmitter parallel output data (with respect to the parallel output data clock), and then another instance to probe the receiver parallel input data. At least then you can see whether you have sane data leaving the transmitter and nothing or something coming in the receiver. Cheers, Dave - Altera_Forum
Honored Contributor
Thanks for the tip, I used SignalTap to analyze the test example and found that the system is being held in reset. But I don't understand the purpose of the code that does so:
What does the line 'Reset Counter to give active high reset to enable offset cancellation' mean?wire system_reset_cnt; reg system_reset=1'b0; // Reset Counter to give active high reset to enable offset cancellation counter_128 cnt_128_isnt ( .clock (C100mhz), .q (system_reset_cnt) ); always @ (posedge C100mhz) begin if (system_reset_cnt >= 8'd128) begin system_reset <= 1'b1; end end - Altera_Forum
Honored Contributor
--- Quote Start --- What does the line 'Reset Counter to give active high reset to enable offset cancellation' mean? --- Quote End --- The Stratix IV handbook, and I would guess the Stratix V handbook, discuss the initialization sequence for the transceiver blocks. Enabling the transceivers involves allowing for the input offset voltage calibration to complete, PLLs to lock, and the sequencing of analog and digital reset controls. Your only solution is to sit down and read the handbook. However, while you do this, you can cheat a little. Create a simple system with a few GPIOs and connect those GPIOs to the transceiver block controls (eg., an SOPC system with a JTAG-to-Avalon-MM bridge and a PIO). Then in software toggle each signal while using SignalTap to capture the status bits from the transceiver block. Use that to understand what happens in the hardware. Then in parallel, create a Modelsim testbench and implement similar control signal sequences. You will see that the Modelsim model produces a different result - usually a much faster time for a status bit to change state - but overall the same sequence will occur. Write your own reset controller to implement the appropriate sequence; use a counter to wait for the 'expected' status signal assertions, use generics to change the values for simulation via hardware, use timeout counts, so that you can generate your own status outputs (eg., PLL did not lock due to missing clock, or missing input cable). I'm kind-of surprised that Altera just doesn't supply an IP block to implement the correct reset sequencer. But, they don't, and their example code is not always that great, so shrug your shoulders, roll up your sleeves, and write it yourself. This is probably not what you wanted to hear, but it'll help you get things working. Cheers, Dave - Altera_Forum
Honored Contributor
Thanks for the help, Dave.
I tried implementing the second Stratix V example (4-channel 6.443 Gbps links) and this one is transmitting, but the PLL isn't locking. Based on what I read in the "Transceiver Reset Control in Stratix V Devices" handbook, the transceiver block is being reset properly, and the tx_ready and reconfig_busy status pins are showing 1 and 0 respectively as expected. But pll_locked and rx_ready are both 0. The PLL clock appears to be working according to Signal Tap, and I'm able to measure its frequency by connecting a scope to the associated trigger, and it appears to be 644.53 MHz, as expected. I tries simulating the file in Modelsim, but I ran into this fatal error - http://www.altera.com/support/kdb/solutions/spr376737.html Sadly there doesn't seem to be any workarounds Any other ways I can figure out why the PLL isn't locking? - Altera_Forum
Honored Contributor
--- Quote Start --- I tried implementing the second Stratix V example (4-channel 6.443 Gbps links) and this one is transmitting, but the PLL isn't locking. --- Quote End --- Be a little more specific please. If its transmitting, then the TX PLL must be working. So its the receiver PLL that is not locking? --- Quote Start --- Based on what I read in the "Transceiver Reset Control in Stratix V Devices" handbook, the transceiver block is being reset properly, and the tx_ready and reconfig_busy status pins are showing 1 and 0 respectively as expected. But pll_locked and rx_ready are both 0. --- Quote End --- Study the document carefully. Some of the signals are for the transmitter block, other are for the receiver block. There are also reset controls that you might need to deassert. --- Quote Start --- I tries simulating the file in Modelsim, but I ran into this fatal error - http://www.altera.com/support/kdb/solutions/spr376737.html Sadly there doesn't seem to be any workarounds --- Quote End --- Try creating the component in Verilog rather than VHDL. Perhaps that works? Or use Modelsim-SE full edition if you have access to a license. --- Quote Start --- Any other ways I can figure out why the PLL isn't locking? --- Quote End --- Which PLL first? The receiver PLLs need to be connected to a reference clock and started in lock-to-reference mode. Then once data is present on the input and toggling, the receiver PLL can transition to lock-to-data mode. This transition can be configured to be automatic. Cheers, Dave - Altera_Forum
Honored Contributor
When I configure the device the GXB_TX11 SMA connector has a jittery 50 MHz clock output. Then when I choose a PRBS sequence and hit Start in the Transceiver Toolkit to control the Tx channel the output shows PRBS data, but it's also just as slow (instead of the 6.4453 Gbps it's supposed to be), and there's occasional "bursts" of voltage on the scope.
In the Transceiver Toolkit the TX/CMU PLL status and RX CDR PLL status both show 'PLL not locked'. The TCL console command alt_xcvr_custom_is_tx_pll_locked returns 0. In SignalTap the pll_locked signal (which the handbook refers to as 'A high on this signal indicates that the TX PLL is locked') is always 0. So the transmitter is transmitting something, even if it's not what I expect, and the PLL is not locked. - Altera_Forum
Honored Contributor
--- Quote Start --- So the transmitter is transmitting something, even if it's not what I expect, and the PLL is not locked. --- Quote End --- Ok, thanks for clarifying things. Clearly your transmitter is not doing what it is supposed to. The problem with PLLs is that their VCOs will oscillate whether they're locked or not. I much prefer debugging my own code. I would recommend starting from scratch. Create an ALTGX transmitter-only block, and get it to work. Then create an ALTGX_RECONFIG and get the output voltage (VOD) controls to work. Write your own logic to drive the transceiver, eg., a stream of data from RAM, data from a PRBS, a static parallel pattern (that becomes a dynamic serial pattern). Its only when you do this that you'll really understand things. At that point, you could probably go back to the transceiver toolkit example and figure out what is not working with it. But at then, you probably won't care. Cheers, Dave - Altera_Forum
Honored Contributor
A few clarifying notes ...
1 - altgx does not exist for Stratix V. Transceiver usage in the example design is through Custom PHY IP. 2 - ALTGX_RECONFIG doe snot exist for Stratix V. The new IP block is "alt_xcvr_reconfig" or "Transceiver Reconfiguration Controller". 3 - The PHY IP does contain an embedded reset controller. The user does not manually control the reset sequence of the transceiver. It sounds like the PLL is not locking. Your first objective would be to ensure that the PLL is getting a proper reference clock. Check your pin assignments and refclk frequency inputs. Jake - Altera_Forum
Honored Contributor
Hi fpuser,
You seemed to be having a lot of issues getting the transceiver design to work, and after a while you stopped posting. I was wondering: did you ever get it to work? I'm thinking of buying the same board, and have very little experience with Altera, so I'm somewhat nervous about it. Thanks in advance for any advice/tips! Cheers, Peter - Altera_Forum
Honored Contributor
--- Quote Start --- I'm thinking of buying the same board, and have very little experience with Altera, so I'm somewhat nervous about it. --- Quote End --- The Stratix V board is loaded with Engineering Samples. Check the errata before you buy. Also note that most of the interested features on the Stratix V device, such as partial reconfiguration and (I think) reconfiguration via PCIe are not yet supported by Quartus. You'll have to wait until Quartus 12.0. I'd be nervous too. What do you need to do with the transceivers? Perhaps you can start with the Stratix IV GX or GT devices, and then move onto the Stratix V when they are in production and supported in the software. Cheers, Dave