C2H acceleration tutorial Quartus compilation issue

[Altera_Forum]

Hello, 

 I have been going through the C2H fft tutorial and also inputted the fft accelerator to my own project. Both of these projects compile fine and the SOPC builder generate the systems. However, Quartus II compilation fails in both cases. The Quartus shell is started, but the compile command seems to be out-of-date.   Here's the Nios2ide console output.  Info: Command: quartus_sh --flow compile Info: Quartus(args): compile Error: Expected arguments are --flow <flow_name> <project_name> [-c <revision>] Error:  Error: Quartus II compilation of project failed.  Is there some way to update the script? Or do I have to go through the entire design flow in command shell and if so is there an example flow for this. Another thing is that on my own project the c2h fft is not on the top level and therefore the nios2ide doesn't compile the top project, but only the nios cpu. Is there some way around this issue?  Thanks beforehand.  PS. I am using Quartus II 10.1 SP1 and the Nios2ide 10.1 SP1.

[Altera_Forum]

I'm not sure why that is happening but I recommend switching the C2H settings over to generate only and compiling the Quartus II project manually. I always found myself recompiling the hardware unintentionally when I had C2H setup to automatically compile the hardware so I stopped using it.

[Altera_Forum]

I forgot to mention that I did the manual compilation before. Manually compiling the Quartus II works properly after C2H acceleration and SOPC builder generation only. And after programming the device, the intended application runs properly with the two nios cpus. However, when trying to start a debug session it leads to the device ID and timestamp mismatch. (ID 0xFFFFFFFF and timestamp 0:59:59 1970/01/01) If the device ID and timestamp validation is disabled, the debug session only starts the other one of my two processors. Any ideas for a workaround or to the cause of this?

[Altera_Forum]

Did you connect the data master of each CPU to the system ID component? Reading back 0xFFFFFFFF sounds like one of the CPUs isn't connected or it thinks the system ID lives at a different locating in the memory space.

[Altera_Forum]

Yes, the data masters of both cpus are connected to the sysid component. This problem didn't exist with the normal SOPC -> Nios2ide -> Quartus II flow.

[Altera_Forum]

Does this only happen when you attempt to debug? i.e. if you download the software to both processors using a multiprocessor collection or manually downloading to each one you don't see this issue? If so that might be an issue with the IDE and not so much with the fact that you are using C2H.

[Altera_Forum]

After a while of trying different combinations, it seems that I can't debug or run the processor including the accelerated function. The other processor runs properly on its own. When running the multiprocessor configuration the other runs and other doesn't. Before adding the C2H tutorial fft and running the C2H compilation I was able to run and debug both processors either separately or in a multiprocessor configuration (when running the multiprocessor system, the other processor is in debug mode and the other in release mode). Could there also be a memory issue? 

 So if the timestamp and device ID are not read correctly could there be an issue at some point of the compilation. Most likely the C2H generation running the SOPC doesn't update some flag in the system. Any ideas where to look at?

[Altera_Forum]

It could be that the other CPU is running but the hardware accelerator might be stuck. For that issue I would try to debug it separate from the system ID problem. I would also debug it by keeping the non-C2H CPU idle while you are trying to figure out what is happening. 

 For the system ID issue I would compare the base address in system.h for the sysID component to what you see in the SOPC Builder UI. Reading back 0xFFFFFFFF normally means that the wrong location is being accessed during the system ID check. So your system might not be built with the same system ID base address as the tools are expecting to find it.