Placement of okHostMicrocode.hex

Hi,

I’m trying to use a pipe from the FPGA to a PC, but all I get is 0xdeadf00d. Reading RAMTester is failed with the recompiled ramtest.rbf , it seems like there are issues reading okHostMicrocode.hex. Looking through the log files, I can confirm that Quartus can’t find the file. I also see that the encrypted HDL seems to be hardcoded to read from …/okHostMicrocode.hex, which is a bit strange since the documentation tells me to drop the file into quartus work directory. As a side-note, relative paths are always tricky with verilog. It’s better to just use okHostMicrocode.hex, since that gives us the option to put the file in any of the include directories or in the working directory.

I also read something about a known issue with 14.0 (can’t find any info on the actual issue though), so I tried this in 13.1 and 16.0 as well. In 16.0 I can make quartus find the file by placing it one level above the quartus working directory, but I’m not getting a programming file this way. Instead I get an error saying that the microcode file isn’t the same as the one in Analysis & Synthesis.

This is with frontpanel 4.5.5. Thankful for any help

//Olof

Have you tried cleaning the project since your initial builds? The error you mention about the microcode being different than that used in Analysis & Synthesis may indicate that Quartus did not find the file previously and is stuck believing that it does not exist.

With the okHostMicrocode.hex file placed in the Quartus project directory (the directory containing the *.qpf file), clean the project (from the project menu select clean and then click OK on the window that pops up), then try to build again. You may get two warnings about missing .mif files but those should be able to be safely ignored. Back up any logs that you want to keep from previous runs as the project cleaning will remove them.

It turns out that putting the file in Quartus working directory and running with 16.0 solved the problem

I still get the warning that the file couldn’t be found during synthesis, but perhaps the memory contents is being initialied during bitstrema generation?