Start a new topic

FMC125 calibration package -could not send calibration data- error


I was testing the calibration firmware for the FMC125 for the ML605 board (342_ml605_fmc125_cal) and, when calibrating the gain, I got the error message: "could not send calibration data" for the ADC C (please see attached image). After that the firmware stops working.

I used the bit file and the firmware FMC125_Calibration.exe automatically provided by the installer (i.e. I did not modify anything) but copied to a different folder.

How can we solve it? :) (something related to the value >255?)


Hi Daniel,

The protocol between the ML605 and your computer is based on UDP. Other operations, running in the background, could cause a loss of data in the UDP interface. Please try to disable all items that are active in your LAN Properties dialog, except the 4DSP EthernetII Protocol Driver. Please refer to the attachment.

Best regards,
Hi Ingmar,

Thanks for your reply!
Unfortunately it did not work. I guess it is something related to the value that needs to be sent (256, more than 8 bits).  Let's see what 4dsp staff suggests.


Hi Daniel,

Actually I am employee of 4DSP, but registered on the forum as a member. The gain error from channel C is significant, maybe the data, coming from the FMC connector is erroneous. Could you run the app with the ADC mode set to 4 (4 channels, this mode skips the calibration), and see if you can capture a fundamental (something like 300MHz falls within 1st Nyquist) poperly on each channel? The real samples of each channel are stored in .bin and .txt files.

It could be that your version of the ML605 has got some timing characteristics which are on the edge for the LVDS interfaces coming from the FMC125. This could mean that the IO delay tuning settings, hardcoded in the fmc12x_adc.cpp file, have to be changed.

Best regards,
Hi Ingmar,

I tried to run it in ADC_mode=4 but could not get the real samples. It asked me to connect the 450 MHz signal to both A & C inputs and then it cannot find the fundamental frequency and the SW crashes again. It seems that if you don't select ADC_mode=1, the SW takes it as adc_mode = 2  (I could see that in the C code as well).

I tested the calibration SW & firmware in other 3 boards we have. Only one of them worked and even in this case the gain was significant. I run it twice and this is what I got (the C gain and some offset values changed "drastically", Can you tell me whether this is expected?)
                                      Test1  Test 2
CALIBDATA_GAIN_A      127        =
CALIBDATA_GAIN_B      106    109
CALIBDATA_GAIN_C      160    179
CALIBDATA_GAIN_D        81        83
CALIBDATA_PHASE_A    127      =
CALIBDATA_PHASE_B    117      97
CALIBDATA_PHASE_C    172    117
CALIBDATA_PHASE_D      97    162

I will run the reference_design (not the calibration) in one channel mode and check if there is something strange with that C channel (but the SW & firmware is different from the calibration one so I'm not sure whether this is a good test. Please advice.

1. do you think that there is something wrong with the IO delay tuning? I can see in the C code where do change it, but I assume I have to find the correct value for each channel manually?

2. Otherwise, I'll implement what is suggested in the post forum [url=,2380.0.html]FMC125 Calibration Problem[/url] Started by [url=;u=998]Fernando[/url] (Nov. 13, 2013) regarding the "bit_align_machine.vhd" but I would assume that the bit file I got from the package already includes that change?


Hi Daniel,

Although you've set the ADC_mode to 4, the software still tries to complete the calibration which fails, and therefore you won't get any data samples. Please also change in main.cpp:
const int OffsetCalibrationEnabled  = 0;
const int GainCalibrationEnabled    = 0;
const int PhaseCalibrationEnabled  = 0;

this forces the software to skip all calibration steps completely and you should just get the samples directly.

I still consider the IO delay tuning values as the possible root cause because you've also seen variations from board to board. The datasheet from E2V shows a potentially large device-to-device variation in output timing of the LVDS signals. As you've already found the source code to change these values, I would propose to do the following:
- Make sure you run the test on one FMC only
- Take the real samples and check the FFT plots, I expect a high noise floor on Channel C. Please be aware that these type of timing violations can be caused by temperature variations, and there is always a change that it works fine one out of ten times
- Assuming channel C fails, change the input delay setting of Ch C by decreasing it with 4 and run the test again. If the channel still fails, you should try to increase it with 4. If it still fails (I don't expect so), try steps of 6 and 8. A span of 6 to 10 input delay values should be error free, so you can finetune to a value the lays somewhere in the middle.
- In parallel, have a quick look at the other 3 channels, these should remain unaffected. If one of these channels is on the edge, you might notice this as well and have to perform the same steps as per Channel C

The bit_align_machine.vhd is not needed for this.

Running the reference_design (not the calibration) is not very useful because that design uses an individual LVDS clock per channel which is different from the calibration design. However it is an easy way to get confident that the hardware is doing oke (sometimes the FMC connector gets dirty and connects may become instable).

Best regards,

Dear Daniel,

Without feedback from your side we will consider this issue as resolved and proceed with locking the topic on Monday!

Best Regards,
Dear Ingmar, Arnaud

I have to mention that I saw your reply after I changed the bit_align_machine.vhd file (as suggested in the other post) and it actually worked (with the original values of IO delay)

Then, I tried the delay tuning you suggested with one board and it worked, I found the new values for the fine tuning with the old bit_align_machine.vhd. Actually the same tuning values also work with the updated version of bit_align_machine.vhd.
I still need to test other boards.

As for my application I need to change the serdes (to x10), I think I have to do the delay tuning again, thus:

1. Which version of the bit_align_machine should I actually consider ("old" provided by the installer or the one including the changes in that post)?
2. Is it advisable to lock the components in the fpga so that we don't have to change the values again (for each board)?


Dear Daniel,

It sounds good that you managed to get the board working.
The bit_align_machine.vhd is a feature that is not being used for the FMC125_Cal firmware, I'm sorry to see that you are a little bit misled by the other topic you've found on the forum, we've decided to delete that one.
To enable the bit_align_machine, a bit should be written by the software (the start_align signal in ev8aq160_quad_phy) and that is not done for the FMC125_Cal at the moment. It would have been better to delete the VHDL source code of the bit_align_machine completely out of the FMC125 design.
In addition, the ADC needs to be configured in a specific test mode to get the bit_align_machine to work. The bit_align_machine is used for the FMC126 which is another variant of this FMC board, equipped with an EV10AQ190 from E2V. The bit_align_machine is expecting another pattern from the ADC then the pattern supported by the EV8AQ160, so even if you would modify the software it is not compatible yet.
So I think the bit_align_machine that you've implemented did not improve anything, and the fact that is worked might have been a lucky shot because the synthesis tool had slightly different timing results (by running the timing analysis of both versions of FW, you should be able to observe differences in the results).

My advise would be to stick to the old bit_align_machine or remove it completely.
Regarding the locking of components in the FPGA, this could be an option, but you would have to add some tight timing constraints to the IOs with respect to the clock etcetera.
It's better and easier to determine the correct values of the input delays that work reliable on all 3 board you have, please choose the best value with some margin for temp variations. You should be able to get one correct set of values for the combination of your ML605 with each of the 3 FMCs.

Best regards,

Dear Daniel,

We believe this support topic can be closed. Without any further response we will close it by tomorrow.


This topic is being closed because the issue is considered as resolved by 4DSP. Feel free to create a new topic for any further inquiries.