Topic: FMC125 Initial Configuration?  (Read 5673 times)

jchang March 27, 2013, 03:21 PM

  • Member
  • *
  • Posts: 18
I'm trying to get the FMC125 to capture data using my FPGA design, but it seems to be data values being sampled don't match the input that it is connected to.  What I did was replicate the commands that are executed from sip_cmd.sip provided in the reference design.  However, this does not appear to be sufficient to configure the FMC125 properly.

I am able to get it to capture good data if I first load the reference design FPGA, run Fmc12xApp.exe, then load my FPGA.  Based on this, Fmc12xApp.exe is performing some configuration that is persistent across FPGA downloads (configuring the CPLD, clock tree, etc.?), but is not being simulated from sip_cmd.sip.  What configuration is it doing?

I also noticed some commands are commented out in sip_cmd.sip.  Are any of these necessary configuration for the FMC125 prior to capturing data?  Since they were commented out, I assumed that they weren't.

arnaudNL March 28, 2013, 07:37 AM (#1)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Dear Sir,
The simulation is using a model of the A/D chip only. The simulation is not about obtaining decent samples out but more about validating databuses, etc.
The firmware is in an undefined state before the software application has run. The software application actually obtain base addresses of IP cores in the firmware and configure the whole chipset during runtime. The firmware maps chips to a given address the software can read/write. Generally these read/write translates to I2C/SPI transaction.
The software application is documented using doxygen, a .chm document. You can find its source code under C:\Program Files (x86)\4dsp\FMC Board Support Package\Refs\Software\. The Visual Studio solution contains a link to the doxygen documentation. Typically the module called fmc12x_clocktree.cpp is in charge of configuring the clock tree device on the board.
What I would be doing if I would be you is probably to wraps all the calls to sipif_writesipreg() in a way I can write address written and data written to. Then you could replace this configuration with a state machine in your firmware.
There is also some initialization done by the firmware via ROM Init, this is generally configuring the communication buses in a way it can be post configured by the software.
I hope that helps!

jchang June 25, 2013, 07:08 PM (#2)

  • Member
  • *
  • Posts: 18
Thanks for the info.  We were able to use the reference design C code as a template for getting initialization working.