Topic: Application FMC110App crashes on DAC init  (Read 15259 times)

MT5555 December 17, 2012, 05:48 PM

  • Member
  • *
  • Posts: 3
Hello,
 
I've got a problem.  I've got a FMC110 board with an FM680 digitizer board plugged in. 

I install the 4dsp FPGA firmware on Windows 7 using the 4dsp application.  I then try to compile it in Xilinx ISE (the latest version).

 
Everything compiles fine but when I run :
 
FMC110App 0 FM680 0 0
 
It crashes with the message :
 
"Could not initialize FMC110.DAC"
 
I've tried reinstalling the fpga firmware into its directories and recompiling.  I managed to get an installation where if I set the FPGA's Speed Grade to -3 it works (does not crash).  And if i set the Speed Grade to -1, it crashes.  I can't figure out why it works with that installation but not others. 
 
Could you tell me what I'm doing incorrectly?  I have a feeling it has to do with the way I install the 4dsp firmware or perhaps the way its being compiled in Xilinx ISE. 
 
If you need any further info to diagnose the problem please let me know.
 
Thank you.
 
  • « Last Edit: December 17, 2012, 07:49 PM by MT5555 »

arnaudNL December 18, 2012, 05:12 AM (#1)

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


Can you let me know if the default (recovery file .bit) is operating well?


Thank you,
Arnaud

MT5555 December 18, 2012, 05:25 AM (#2)

  • Member
  • *
  • Posts: 3
Can you let me know if the default (recovery file .bit) is operating well?
Hi Arnaud,
Yes the default .bit file does operate well. 

 I have tried using 4dsp install tool to install the fpga firmware and compile it in the latest Xilinx ISE.  Sometimes it works consistently if Speed Grade setting in the compiler is set to -3 instead of the default -1. 
At other times when I try a fresh install into another directory using the install tool with the exact same settings as above, it mysteriously does not work.  It crashes at the DAC initialization.
I do not understand why it works on some installation & compilations but not on others.  i.e. why it crashes at DAC initialization.
I notice the .bit file generated by the compilers are of different sizes too on each compile - between 4.3 MB to about 5 MB.
Its being compiled on a Windows based system with the latest Xilinx ISE as mentioned.  No errors during compile. 
Perhaps I could send you a bit file where it works in one case and crashes in another.  You could see very quickly what the problem is I am describing.  Please let me know how I could email you the files if so.

arnaudNL December 18, 2012, 05:35 AM (#3)

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


The problem is clearly about ISE not always generating correct bit stream for some reason. I don't think this is related to StellarIP or anything like that but more into a difference around ISE version between what we used (14.1) and what you use (?). The DAC initialization is actually checking for coherency between clock and data and it looks like ISE is doing better job when you set speed grade to -3.


Our bit files are compiled using StellarIP with the same settings, nothing different. Maybe try using ISE 14.1? There are often weird things between ISE versions.


Best Regards,
Arnaud

MT5555 December 18, 2012, 05:50 AM (#4)

  • Member
  • *
  • Posts: 3
Hi Arnaud,
we are using the latest Xilinx ISE 14.3 I believe.  How different can it be from 14.1.
In the application code 4dsp provides, I can see the DAC routine among other things checks for some DDR clock to lock to some frequency..etc.  None of this really means anything to me but I suspect that the DDR clock is not locking to the frequency in the compilations that don't work.  i.e. As you said the clock and data might not be coherent.
Can I please send you the .bit files where one works and the other does not (both compiled with the same speed grade setting).  We are using FMC110 with FMS680.  I did not modify the fpga code in any way.  Its a straight install & compile job on the same machine with the same compiler - with one installation working and the other not.
We need to get this working consistently as we aim to modify the fpga code slightly to send the ADC data to a hard drive.  But if we can't even compile & have it running with any stability, we won't be able to do anything with this. 

Any help you can give us at this point would be great.
 

arnaudNL December 19, 2012, 02:45 PM (#5)

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


Please check your release_notes.txt. This file is part of the firmware source code. There we indicate which ISE version the firmware was compiled/tested with. I believe your version was compiled with ISE 12.3 but please double check.


Many things can be different between ISE versions (even between minor updates) it is difficult to formulate an answer about that. Try to compile the firmware with the same ISE version as the one we have used and this should normally work just fine.


Let me know if this is not the case. Also let me know if I can delete/mode this topic to your company's private section as one of your colleagues did a duplicate and this was also answered there with more details.


Best Regards,
Arnaud

kmg February 06, 2013, 11:22 AM (#6)

  • Member
  • *
  • Posts: 19
This has nothing to do with Xilinx ISE software versions.

The FMC110 software/hardware combination is very "sensitive" to mismatches in DAC clocking. As soon as you change the DAC clock from the defaults you need to do a lot of changes in other places as well. If you don't, you get the dreaded "could not initialize DAC" errors.

Even a simple mismatch between firmware and software versions can cause this. If you see it works with the "default" bitfile that comes with the tools, you probably want to make sure you're compiling the SAME code that led to that default bitstream.

There's a MUCH bigger chance that you have been compiling different FPGA code rather than that using a different version of FPGA tools would be the cause.

I suggest you look into DAC clocking: make sure all clocks are at the same defaults that 4DSP is assuming.

On a working system you can easily trigger this error by reprogramming the clock generator (in the FMC110 app) to something else than the default 1GHz, or by programming the wrong DLL tuning words in the DAC. Or by using an external clock.

Koen.

arnaudNL February 06, 2013, 12:19 PM (#7)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Dear Koen,
We have seen many times same software svn revision with same firmware svn revision showing different results on different ISE versions, there are also many Xilinx support posts confirming that.
Best Regards,
Arnaud

kmg February 06, 2013, 01:26 PM (#8)

  • Member
  • *
  • Posts: 19
In almost all cases where newer FPGA tool versions cause this type of "errors", it turns out that it is NOT a bug in the FPGA software, but rather due to inadequate design constraints.

If you do not constrain all the relevant paths in an FPGA design, any change in the FPGA software (eg a better synthesis or mapping or routing) may result in unexpected timing changes on unconstrained paths.

It is very easy to blame "the other guy" in such a case (it's like the software guys always blaming hardware for their bugs and vice versa).

The 4DSP example design is very sensitive to missing constraints because it has lots of clock domains (and clock domain transitions).
I spent quite some time adding proper constraints to the 4DSP example FPGA code (for our ML605+FMC110 platform). Before that I was running into failing designs many times -- sometimes when I upgraded Xilinx tools, sometimes when I added features to the basic demo design -- in both cases this caused the tools to do a different synth/map/routing, exposing problems in unconstrained paths.

I haven't seen any more of these issues since we fixed the constraints. I've used all Xilinx ISE versions between 13.4 and 14.4 without problems.

Koen.

arnaudNL April 10, 2014, 05:21 AM (#9)

  • 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.