Products > FMC112, FMC116

FMC116 Initialization Problem

(1/4) > >>

vicmarher:

Hi again.
I've used your FMC116 Reference Design as a base for my design.
I've replaced your SIP_MAC_ENGINE with a custom star accessed through an embedded app running on a LEON3 Soft-Core in my FPGA.
Anyway, the initialization source code is exactly the same as in your Reference Design "C" code, changing the functions that send the SIP Commands through ethernet, by functions that access I/O Registers with the Soft-Core, and re-route SIP_COMMANDS to ADC.


I've also updated fmc116 vhdl to avoid bursts and work in a continuos mode, using a double buffer that generates an IRQ when one of the two buffers is full. The App running in Soft-Core catches the IRQ and reads the content of the buffer.


The buffer in the output of each channel has also been changed from a 16 to 64 buffer to a 16x16 buffer with different clocks for read and write, which samples go directly to the just described double buffer. This buffer is used for the clock-domain change between ADC clock and Soft-Core clock.


When I power on FPGA and test a sinus signal in the FMC116, I read it correctly.
But when I interrupt (ctrl+C) execution and start it again withow powering off/on my FPGA (Xilinx Virtex ML605), the results are really strange, as you can see in the attached picture.


I've also created a simple sequence generator and plug it just before the 16x16 buffer. This way, I replace the ADC output by the sequence output., but the data path is still the same. The sequence can be enabled in real time with a switch in the FPGA Board. When I do that, the sequence is correctly read, but the sinus is still wrong read, showing in my opinion that my problem is in ADC initialization.


Attached figure shows the effects.
So the questions are :


1.- Is there any initialization needed for the FMC116 that is not taken into account in the Reference Software?


2.- The VCO calibration from clock-tree is treated diferently from power up and for subsequent executions (page 40 of clock-tree pdf AD9517-3). I've tried to reset 0x18 register and update registers with 0x232 reg before updating registers, but the behaviour is the same. How exactly must be treated VCO calibration for not the first time after power up? may it be my problem?


3.- I use the clock from LEON Soft-Core as master clock to be distributed for clock and command clock. It's a 125Mhz single-ended clock generated by a LEON PLL using the  200Mhz differential clock from FPGA. Is there any difference between this clock and the one that generates SIP_MAC_EMGINE in Reference Software?


I hope you can help me.


Thanks a lot!


Víctor Martín, IEEC

arnaudNL:
Dear Victor,


1. Not as far as I know, no
2. I think the problem is not there, we can run our reference design several times.
3. The stellarIP clock is indeed generally 125MHz.


I would check the following:


1. Data stuck in a queue somewhere? Your ctrl-c is going to interrupt a process and there for you should flush all the FIFOs. In the ETHAPI we do the follow sequence:


- Write twice to address 0, we write a 1 there. This causes the mac engine to reset the FPGA fabric. The software FIFO part of NDIS protocol are automatically flushed by the OS.
- Send the host's mac address.


2. Its quite a work around but, generally you would not want to interrupt the process, you would intercept the ctrl-c event, prepare the system to bail out (ie wait for data transfer to finish, etc..) and then finally exit. Check the following, http://stackoverflow.com/questions/4217037/catch-ctrl-c-in-c


I hope that helps,
Arnaud

vicmarher:
Hi Arnaud,
thanks for your reply.


I will try what you say, although I already do something similar. In fact, at startup, I disable all FMC116 channels, force all the buffers to be empty by setting read_enable to '1' untill they are empty, and only then I re-enable the channels and set IRQ handlers to read my buffers.


And in fact, even if buffers weren't empty in a second execution after ctrl+c, what i'd expect to receive would be samples from previous execution, in a perfect sinus wave, not an strange and noisy signal as the one you could watch in the attached figure.


Thanks!


Víctor

arnaudNL:
Dear Victor,


I was following up on topic inactive for a couple of days.


Any breakthrough on your side?


Thanks,
Arnaud

vicmarher:
Hi Arnaud,
unlucky this week it has been impossible for me to keep working on that.
But I insist in the fact that the clean up of the buffers is already done at the beggining, and in case it wasn't done, the results would have samples from the previous executions already in the buffers, so the plot would show a sinus that suddenly restarts in a new phase, not the strange noise image that you can see in the pictures.


Anyway, as soon as i can i will try capturing SIGINT and call the cleanup functions I call at the beginning, and I will tell you the results. Thanks for your interest! and off course, if you or anybody has any idea,  please let me know.




Many thanks!


Víctor

Navigation

[0] Message Index

[#] Next page