Topic: FMC125 calibration package -could not send calibration data- error  (Read 13027 times)

daniels March 26, 2014, 11:28 AM

  • Member
  • *
  • Posts: 10
Hi,

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?)

Thanks,
Daniel
  • « Last Edit: March 26, 2014, 11:32 AM by daniels »

iklink March 26, 2014, 01:12 PM (#1)

  • 4DSP Staff (EU)
  • Member
  • *
  • Posts: 153
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,
Ingmar

daniels March 27, 2014, 10:52 AM (#2)

  • Member
  • *
  • Posts: 10
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.

Daniel

iklink March 27, 2014, 12:16 PM (#3)

  • 4DSP Staff (EU)
  • Member
  • *
  • Posts: 153
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,
Ingmar

daniels April 05, 2014, 01:30 PM (#4)

  • Member
  • *
  • Posts: 10
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_OFFSET_A   127      =
CALIBDATA_OFFSET_B   125      =
CALIBDATA_OFFSET_C   134      =
CALIBDATA_OFFSET_D   128      =
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.

Therefore:
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 FMC125 Calibration Problem Started by Fernando (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?

Thanks,
Daniel
  • « Last Edit: April 07, 2014, 06:54 AM by daniels »

iklink April 08, 2014, 06:08 AM (#5)

  • 4DSP Staff (EU)
  • Member
  • *
  • Posts: 153


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,
Ingmar

arnaudNL April 11, 2014, 03:56 AM (#6)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Dear Daniel,


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


Best Regards,
Arnaud

daniels April 11, 2014, 07:57 AM (#7)

  • Member
  • *
  • Posts: 10
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)?

Thanks,
Daniel


iklink April 15, 2014, 11:28 AM (#8)

  • 4DSP Staff (EU)
  • Member
  • *
  • Posts: 153

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,
Ingmar


 

ebarhorst April 22, 2014, 12:01 PM (#9)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 1222
Dear Daniel,


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


Thanks,
Erik

arnaudNL June 13, 2014, 07:52 AM (#10)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
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.