.rbf / .jic file problem when changing from Cyclone IV to Cyclone V

[Altera_Forum]

Hi, 

 We changed our design from a Cyclone IV (configured via an EPCS64) to a design with a Cyclone V (also configured via an EPCS64). The main parts of the rest of design remained the same. With the Cyclone IV design, we used a custom tool which directly programs a .rbf file to the correct address in an EPCS64 device, and this functions without problems. It is also possible to use a .jic file to program the EPCS64 device. With the Cyclone V design, we use the same method and program the .rbf file directly to the EPCS64 device, but then the configuration of the Cyclone V fails. However, when we use a .jic file to program the EPCS64 device via JTAG, this functions correctly.   When investigating this problem, we saw that the format of the .rbf file of the Cyclone IV seems to differ from the format of the .rbf file of the Cyclone V: 

• The .rbf file of a Cyclone IV is exactly the same (when compared bit by bit) to part of the .jic file (when you strip the .jic file from its header and footer, and only look at the address range you are interested in).  
• The .rbf file of a Cyclone V is not exactly the same as the corresponding part in the .jic file. The nibbles of the bytes in the .jic file are shifted according to a repeating pattern, compared to the same bytes in the .rbf file.  

  If we now take the .jic file of the Cyclone V, strip its header and footer, remove all the data in the addressing range we do not need, and save this data as a .rbf file, we can write this newly created .rbf file to the EPCS64 device, and this functions correctly.  We can use this workaround, but I am interested to know if this behavior is a bug (or a feature), or if there are settings to adjust this behavior. Has anybody any thoughts about this?  We use Quartus II 64-bit version 13.1.

[Altera_Forum]

I recommend you raise a support case with Altera. 

 Based on what you describe it certainly appears to be a fault that has crept in with the introduction of Cyclone V. Altera may well be able to explain why the behaviour differs to that of Cyclone IV. However, given your direct manipulation of the jic/rbf files - and subsequent success - it's hard to believe the files generated for Cyclone V should be fundamentally different to those for Cyclone IV.  Cheers, Alex

[Altera_Forum]

Hi martenv, hi everybody! 

 I found your post while browsing the internet for my problem, which is identical to yours. I am wondering if you probably have found a solution meanwhile. On my board I am able to program the serial configuration flash via Quartus II programmer with a .jic file. The Cyclone V FPGAs come up correctly. For field update I have kind of processor on the board, which is able to reprogram the configuration flash. I have found out, that an .rpd file can be generated by Quartus II programmer, that should be the right file for programming an SPI flash with a processor. But after doing so the Cyclone V FPGAs don't come up correctly. They show a configuration error via nSTATUS pin. I have compared the .rpd and the .jic file, and besides some header information, the raw configuration data is shifted by a nibble! When I strip down the .jic file to the raw configuration data and flash the data with my processor, everything works fine. So is it a feature or a bug for cyclone V? Has anyone an idea? Why is there such an nibble shift?  Best regards, Maddin

[Altera_Forum]

I encountered the same problem on our new design and found the same problem. I've used the .rbf file in the past to configure an EPCS128 and everything was fine. Switching to Cyclone V I found the same issue as above.  

 The resolution to this is to generate the .rpd file instead. It is also a raw binary file. What I found is that .rbf is for parallel configuration modes and .rpd is for serial configuration modes. The files have slightly different options for the FPGA since the configuration modes are different. Certain options are available in parallel configuration modes and vice versa. This accounts for the nibble differences that was seen.   Hope that helped  /Boris

[Altera_Forum]

Thank you very much for your reply. 

I am aware, that the .rpd file is the correct source for programming a serial device (like EPCS) in an embedded environment whereas the .rbf file is for parallel flash device. But the .rpd file didn't work in my case. Investigating the file contents, I found the same binary formatting in the .rpd file like in the .rbf file. Only the .jic file showed a a shift by a nibble and worked in my case after stripping the Quartus II header and other stuff in the beginning. Looking into the files I found the following FPGA configuration stream in hex:  .rbf --> .. FF FF FF 6A 6A 6A 6A 36 F0 FF FF 37 F8 FF ... --> does not work when flashed into EPCS .rpd --> .. FF FF FF 6A 6A 6A 6A 36 F0 FF FF 37 F8 FF ... --> does not work when flashed into EPCS .jic --> .. FF FF FF AF A6 A6 A6 66 03 FF FF 7F 83 FF ... --> works fine when flashed into EPCS after stripping Quartus II header  To my surprise (and regret) I cannot reproduce this issue today! When I generate an .rpd file today, the formatting is different from last week! Today the .rpd file contents seems to be correct: .rpd --> .. FF FF FF AF A6 A6 A6 66 03 FF FF 7F 83 FF ...  After programming this new .rpd file into my EPCS device my Cyclone V FPGAs come up properly! So my issue is fixed at the moment, but one question remains: why did my Quartus II generate several wrong .rpd files last week?  Cheers, Maddin  PS: I should mention that we use Quartus II 64-Bit Version 13.1.0 Build 162.

[Altera_Forum]

Hi, 

 I didn't notice your replies yet, sorry for that. Thank you all very much for replying. The .rpd file also works for me, it can be used to write the entire EPCS at once.  It would be even better when there would be an option to create a file like this only for the compressed image, so not for the entire EPCS device in total (for instance, the .rbf file contains only 1 image, not the entire contents of the EPCS device). Fortunately, a single image can easily be extracted from the .rpd file by using a hex editor.  Regards, martenv

[Altera_Forum]

--- Quote Start ---   If we now take the .jic file of the Cyclone V, strip its header and footer, remove all the data in the addressing range we do not need, and save this data as a .rbf file, we can write this newly created .rbf file to the EPCS64 device, and this functions correctly.   --- Quote End ---      --- Quote Start ---   The .rpd file also works for me, it can be used to write the entire EPCS at once. It would be even better when there would be an option to create a file like this only for the compressed image, so not for the entire EPCS device in total (for instance, the .rbf file contains only 1 image, not the entire contents of the EPCS device). Fortunately, a single image can easily be extracted from the .rpd file by using a hex editor.   --- Quote End ---    You can get needed file without header and footer. 1. Open Convert Programming File tab. 2. Choose Programming file type - JIC 3. Choose all needed settings 4. check create config data rpd 5. Press Generate If you do this you will get needed file with FPGA configuration.

[Altera_Forum]

Thanks andrei_hres, that works nice and easy without having to edit the file itself!

[Joakim]

Hi, I have the exact same problem so I was happy to find this after several days of debugging.

Did anyone get an official response from Altera why this was changed?

I can manually create a working rbf file from the pof file, but I'm still trying to find a good way to automate it, so any suggestions would be appreciated.

/ Joakim