I am using the ZEM4310 board and the FrontPanel SDK v4.4.1-2014-06-19 on Win32.
When I execute the downloaded original …/Samples/RAMTester.exe, I get an error message as follows.
“Can not find the procedure start entry of okFrontPanle_GetSerialNumber in okFrontPanel.dll”
(I was translated korean error message in english, so maybe different from original message)
So, I have re-compiled the …/Samples/RAMTester/Cxx/RAMTest.sln with Visual Studio 2012.
When I execute the recompiled RAMTester.exe with the original ramtest.rbf file, it is O.K.(all passed)
Next, I have recompiled the …/Samples/RAMTester/ZEM4310-Verilog/RAMTestter/ramtest.v with the Quartue Web Ed. 13.1, and I get recompiled ramtest.rbf.
But when I execute the RAMTester.exe with the recompiled ramtest.rbf file, it is failed.
shjung2,
This looks like a security authentication error, i.e. the regenerated .rbf file is not passing the security tests on the board. This is a known issue with Quartus II 14.0, but it is possible to generate a functional bitfile in Quartus II 13.1. The most common cause of this error is that Quartus is not reading from the okHostMicrocode.hex file. Is that .hex file in the working directory of your project?
okAlex,
I am using Quartus II 13.1 Web edition, and I copied the okHostMicrocode.hex file in the working directory of my project.
I have tested another example, the PipeTest.
When I have recompiled the PipeTest.v, and execute the PipeTest.exe with the regenerated PipeTest.rbf file, then it is O.K.
I think the problem is not a security authentication.
The output listed includes hard-coded errors that are used to identify authentication failures (DEADF00D, in this case). That the design passed one test and failed the rest also indicates that the issue appeared after the board security kicked in.
To further investigate what is going wrong here, try this:
In Quartus, go to Processing->Update Memory Initialization File
If the process completes without errors, then try rebuilding the bitfile and running RAMTester with the new version. If you get an error, it’s a bit more difficult but it is entirely possible to get RAMTester to run properly.
Let us know how it goes. If you are still getting errors, we can proceed from there but this is our go-to solution for this issue.
( I recently update the FrontPanel SDK from 4.1 to v4.2. )
When I checked , I got errors as follows;
(This error messages are from the Quartus II 32-bit Web edition v13.1.4.)
Info: Running Quartus II 32-bit MIF/HEX Update
Info: Version 13.1.4 Build 182 03/12/2014 SJ Web Edition
Info: Processing started: Wed Sep 24 22:39:16 2014
Info: Command: quartus_cdb ramtest -c ramtest --update_mif
Warning (39023): Can’t find Memory Initialization File okNios_small_nios2_qsys_0_rf_ram_a.mif – skipped updates for this file
Warning (39023): Can’t find Memory Initialization File okNios_small_nios2_qsys_0_rf_ram_b.mif – skipped updates for this file
Critical Warning (127002): Can’t read Memory Initialization File or Hexadecimal (Intel-Format) File E:/My HW/Samples/RAMTester/ZEM4310-Verilog/okHostMicrocode.hex – setting all initial values to 0
Error (39022): Found no valid Memory Initialization File to process
Error: Quartus II 32-bit MIF/HEX Update was unsuccessful. 1 error, 3 warnings
Error: Peak virtual memory: 432 megabytes
Error: Processing ended: Wed Sep 24 22:39:19 2014
Error: Elapsed time: 00:00:03
Error: Total CPU time (on all processors): 00:00:03
And I have another problems.
When I recompile the ramtest sample with the Quartus II subscription edition (64bit) v13.1.4, I get some errors at timing analysis.
When I recompile it with the Quartus II Web edition (32bit) v13.1.4, there are no compilatrion errors. (But there are execution errors)
I don’t understand the reason.
Is the reason that the version of Altera’s DDR2 memory controller is different?
The error messages are :
<TimeQuest Timing Analyzer / Slow 1200mV 85C Model >
Timing Closure Recommendations
Slack From To Recommendations
1 -0.385 fifo_w32_1024_r32…s_brp|dffe13a[0] ddr2_test:ddr2_tb|local_address[12] Report recommendations for this path
2 -0.385 fifo_w32_1024_r32…s_brp|dffe13a[0] ddr2_test:ddr2_tb|local_address[11] Report recommendations for this path
3 -0.385 fifo_w32_1024_r32…s_brp|dffe13a[0] ddr2_test:ddr2_tb|local_address[20] Report recommendations for this path
4 -0.349 fifo_w32_1024_r32…s_brp|dffe13a[0] ddr2_test:ddr2_tb|local_addr_rd[10] Report recommendations for this path
5 -0.349 fifo_w32_1024_r32…s_brp|dffe13a[0] ddr2_test:ddr2_tb|local_addr_rd[11] Report recommendations for this path
Slow 1200mV 85C Model / Setup Summary
ddr2_interface_inst|ddr2_interface_controller_phy_inst|ddr2_interface_phy_inst|ddr2_interface_phy_alt_mem_phy_inst|clk|pll|altpll_component|auto_generated|pll1|clk[1]
How could I solve this errors?
I must use the ZEM4310’s DDR2 memory, so I need your help.
Thanks in advance.
When I recompile the ramtest sample with the Quartus II subscription edition (64bit) v13.1.4, I got message “Timing requirements not meet”.
But the RamTester is O.K. with the regenerated ramtest.rbf file.
And the ‘Update Memory Initialzation File’ test is O.K.
For using ZEM4310 DDR2 ram, do I have to use the Quartus II subscription edition?
And why does the Quartus II subscription edition generates the message “Timing requirements not meet”?
I’m glad you got something! When we do our tests, we use the web edition of Quartus II, not the Subscription edition. I’m interested to find out more about what may have been done differently between the Web edition and the Subscription edition. You should not have to use the Subscription edition to use the DDR2 RAM. I have recently tested this extensively and shown that it does work. The most likely cause of this error in 13.1 is that something is in the wrong directory, or a setting is wrong. Did you try a simpler example, like Counters or First, to make sure you knew which settings to change and that everything was going where it was supposed to go? In my experience, it only takes a small settings or location error to throw Quartus off.
At this point, my best recommendation is to try building a bitfile for Counters or First, following the README directions for Quartus exactly. There are fewer things that can go wrong with the simpler examples, so if you still have problems with them it will be easier to debug.
The recompilaion of all other samples, such as First, Control, Counters, PipeTess, are O.K. with Quartus-II subscription edition. and Web edition.
And the execution with the regenerated bitfiles are O.K.
Only the ramtest sample has problems.
Maybe, I think the DDR2 memory controller of the RamTest sample is conflict with Quartus-II v13.1.4. But I am not sure.
I will study thoroughly the DDR2 memory controller and its interface.