I am trying to use the "Direct Reconfiguration" flow with a self-coded controller/state machine using the reconfig_* signal interface as referenced in chapter 6.7 of the "L- and H-Tile Transceiver PHY User Guide".
For a first trial I want to re-configure the pre/post-tap pre-emphasis and the Vod amplitude settings of two transceiver channels' TX drivers.
I can read, modify, write the related registers (read adresses 0x105, 0x107 and 0x109, modify some of the bits and write back to PHY), the reconfig_* signals seem to behave as expected and especially when I read those registers again the newly written values are visible.
I can see that the PHY's are put into reset during the reconfig operation and return to normal operation afterwards, TX_ready is asserted and data are appearing at the serial outputs at the expected data rate.
BUT: there is absolutely no change at all of the signal characteristic at the PHYs' serial outputs. No changed amplitude, no pre-emphasis behavior visible.
Is there any hint what could be missing or what part of the operation I don't understand correctly.
Please don't hint to using another way to access the reconfiguration interface, for the moment the self-coded controller is my only viable option.
Thanks a lot for any helpful comment in advance!
- Do you performed recalibration at the end of reconfiguration process ?
- Also, what pre-emphasis value that you change on the fly ? Did you try out few value or compare min, middle and max value to see if there is a difference ?
- For the sake of experiment, you may want to start with VOD setting to see more obvious signal eye changes
- Are you using oscilloscope to measure the signal eye ? Have you double check to ensure you have setup the eye diagram measurement setting correctly ?
Thanks for your answer and suggestions.
1. No, I don't perform re-calibration. The documentation says that re-calibration is necessary when the data rate or protocol mode is changed. So I thought that this isn't necessary when "only" the analog PMA settings are changed. Anyway, I will try to add this to my control sequence.
2. We changed through pretty much the complete valid value range in the lab. Of course, especially we tried a few changes from min to max values. But there is absolutely no visible difference, so I really guess that the change is not "propagated" to the actual high-speed driver stage although the changed values can be read back from the reconfiguration interface.
3. Also here, we tried changing from min to max VOD setting only. And there is no visible difference in the eye of the output signal.
4. Yes, we use an oscilloscope. The setup is definitely fine. We have used the "Board Test System" software initially with the "qts_fmca" design to verify that the programming and control of the FPGA from the PC side works as expected. Here we can see changes on pre-emphasis and VOD propagating directly to the signal eye.
My answers to points 2-4 aren't 100% true. We actually have the "Stratix 10 GX FPGA Development Kit" board and use the following signal chain:
Stratix 10 Transceiver PHY TX -> FMC-A -> Electrical-2-Optical Board from another supplier -> Optical cable -> Optical-2-Electrical Board from the other supplier -> SMA connector -> Oscilloscope
With the oscilloscope we look at the actual waveform of the received signal AND we measure the eye diagram.
So we can't see the Transceiver PHY TX output directly at all. At the moment we don't have an FMC->SMA adapter board, so there is no possibility to probe the TX output signals directly.
BUT: as I wrote, we have used the related "Board Test System" example design as a first shot and could see direct influence of the analog TX settings to the eye measurement results. As of now we can't see any (even slight) influence of any setting changes that I do via my self-coded reconfiguration controller.
Again, I appreciate any comments/helpful tipps very much.
Another isolation method that I can think of is using transceiver toolkit to modify the PMA analog setting then checkout your scope result to see the problem is with your hardware setup or your Quartus design
I presume you are using NativePHY design so you can
- enable dynamic reconfig setting
- enable NativePHY debug master endpoint
- ensure you have supply reconfig_clk and reconfig_reset is release from reset
- recompile design and program sof and launch transceiver toolkit
Change the toolkit PMA setting like VOD on the fly and observe your scope eye
- toolkit setting definitely works
- if you don't see changes on your scope then likely there is hardware setup issue
- Else if you see eye changes then you know your Quartus design state machine has some issue
thanks for your answer and suggestions. Transceiver Toolkit is unfortunately not an option for the moment. We only have one license available and the lab PC is not very capable. So for synthesizing/generating the .sof files I use a powerful Linux workstation which can't be directly connected to the Hardware.
I have found a workaround for the moment: I found the tcl script template
This works in combination with a slightly modified qts_fmca.sof design from the Board Test System examples. I finally managed to control data types and analog settings for each channel individually from the tcl System Console and I can now put together some scripts for the lab engineer to easily modify the individual settings with single tcl commands.
This is OK for the moment, the initial signal quality evaluation.
But as the qts_fmca design isn't exactly what we need for the final FPGA implementation, I am still struggling to implement a self-coded design making use of the dynamic reconfiguration flow. I had a look at the Transceiver Toolkit for Intel Stratix 10 devices presentation from the Intel Training Catalogue. It states that by just enabling the dynamic reconfiguration and the "ADME" features in the Native PHY parameter editor, the access from Quartus Prime should be made available. My understanding is from that training that no Platform Designer action is necessary for that and that the System Console access should also be possible (because, as stated above, we can't use the Transceiver Toolkit at the moment).
In my initial trial this doesn't work, I load the tcl procedures into the System Console, but other than for the qts_fmca design, the initial check of the tcl script states that it couldn't find any PHY instances on the design.
I tried to do a top level RTL code which instantiates the PHY instance (one PHY with 2 channels), the related ATX PLL and reset controller instances and some simple top level low speed logic. But when the ADME is used, I have not yet understood how to connect the reconfig_* inputs/outputs to the PHY instance. There are no top level signals that drive this interface. Do I leave them open/unconnected? Or do I have to connect at least clock and reset?
If you prefer that I open another/separate request to this topic as we are iterating over several approaches in this thread, please let me know.
Again, thanks in advance for any hints or suggestions.
Sorry I don't fully follow what you are explaining in the post here.
Let me try my best to answer your enquiry.
- Regarding design connection and how to build simple transceiver toolkit design (although you mentioned you lack of toolkit license ?)
- I have attached simple NativePHY design with toolkit enabled for your reference in previous post
- Regarding dynamic reconfig process flow example design
- Above link contains a lot of example design created by Intel FAE
- Perhaps you can download designs from 6. Transceiver Toolkit Designs and Soft PRBS Test designs (inc. Dynamic Reconfiguration) to see if you are able to port over to test on your board ?
thanks a lot for your answers. I will check all the suggestions and see how far I will get.
Regarding item 1: the downloaded file "S10_GX_devkit_ttk.qar" is only 590kB in size and when I try to open it in Quartus (I am using version 18.104.22.168) it gives me an error message:
"Failed to restore S10_GX_devkit.TTK.qar
Evaluation of Tcl script /teetools/misc/intel/qpp/22.214.171.124/quartus/common/tcl/apps/qpm/qar.tcl unsuccessful"
Maybe I am trying to open it in the wrong way. Can you check the file again?
Thanks a lot in advance. Best regards,
The toolkit is just a small design and build with Quartus Pro v20.2.
- Sorry I forgot to mention about Quartus version
- v18.1 Pro is too old. Pls consider to upgrade your Quartus version
Sorry for not replying for some time. It's a little bit complicated. I didn't have time to follow up on this for last 1,5 weeks. And won't be able to do so for another week or so.
I will try again after that and let you know if there is progress. If you need to close this thread, let me know, I think some of your hints/links will be helpful to solve this in the end.
Np, understood sometime we all have other higher priority task to work on.
Also appreciate your understanding to let me close case first as I can't let the case idle for too long.
Alright, setting this case to closure.
Feel free to file new forum post if you still need help from Intel support agent in future.