I started my A10 work by carrying forward my earlier work using a Cyclone V. To do this I planned to migrate my code - a bit at a time - and get it working similarly on the A10 SoC Devkit board. That created a problem in getting a flat design project to start, so the info posted here is the solution I discovered. This is a rather long post so I hope I m not breaking protocol with this board with the long post. (It gets a bit wordy so read on if you are interested.)
This outline documents the steps I have used to get a flat design with an HPS loadable from an SDCard and running on the Arria 10 SoC Devkit Board starting with the projects in GHRD ver 16.1, with modification of one project setting.
I am running using Quartus Ver 17.0.2 using an Arria 10 SoC Devkit from Altera, and the rest of the tools provided by Altera with the DevKit Board (SOCEDS, and ARM DS-5 v5.26.0 with Eclipse IDE)
I was advised to use the GHRD version 16.1 (instead of the ver 17.0 GHRD) because it does not contain IP components that I was having trouble compiling in the ver17.0 GHRD since I do not have the added license for them. I had started trimming the project back but each time it adds the risk that I am adding errors to the project as I modify it if I did not make changes correctly.
There are two Quartus projects for Arria 10 in the GHRDv16.1
One is in an archive file named a10_soc_devkit_ghrd.tar.gz
The second is in an archive named a10_soc_devkit_pr.tar.gz This version is specifically using partial reconfiguration, which is what I do not want to do so I will not be following up with work on it. (Iâve tried before at peeling away the partial reconfiguration code but it does not get me any closer to my goal of loading a flat design with an HPS component.)
I am only working here with the first project (a10_soc_soc_devkit_ghrd).
The only change I made was to the âEarly Releaseâ setting found by selecting the âAssignmentsâ menu, then selecting the âDevice âŚâ item, then (in the dialog that follows) selecting the âDevice and Pin OptionsâŚâ button. This presents a new dialog where you need to select the âGeneralâ category, then scroll to the bottom of the Options list-box and turn off the checkbox titled âEnables the HPS early release of HPS IOâ
This project loads in Quartusv17 without problem or requiring IP upgrade
It runs through QSYS ok (and converted to Quartus v17, you need to do this)
The project compiled Ok and produced a SOF file which I converted to an RBF (using the Convert Programming Files menu item). I named the file Flat_HPS.rbf
The QSYS and Compile generated the handoff files in /hps_isw_handoff subdirectory which will be used to create the uboot loader file
I run the bsp-editor tool from a SOCEDS shell window to create files to make a uboot boot file I can use to start my application from the SDCard when the board powers up.
I have copied the Flat_HPS.rbf file to partition 1 of the SDCard and the uboot_w_dtb-mkpimage.bin to my /home/root directory on the SDCard in Linux
I copy the uboot_w_dtm-mkpimage.bin file into partition3 of the SDCard starting at the beginning of the partition using the command
dd if=uboot_w_dtb-mkpimage.bin of=/dev/mmcblk0p3 bs=64k seek=0
Then I shut down Linux so I can reboot to start the application I just installed, and the result is successful as shown in the next page
This shows the step I was missing was to disable the âEarly Releaseâ setting. Using âEarly Releaseâ from the âDevice and Pin OptionsâŚâ dialog makes a requirement that you use a xxx.periph.rbf and a xxx.core.rbf file. It does not cause the periph and core files to be generated, it only makes them required to boot using uboot. Since I donât plan to use partial reconfiguration I donât see why I would want to use a .periph.rbf and .core.rbf
I believe Altera states that the two RBF file method produces a faster startup time, but I think they are referring to a startup after a reconfiguration, which again I do not plan to do.
If you do want to generate a xxx.periph.rbf and a xxx.core.rbf file to support the Early release option there doesnât seem to be a way (in Quartus v17) to do that from the âConvert Programming Filesâ dialog, but you can create them using the command line command below;
quartus_cpf âc âhps -0 bitstream_compression=on output_files/ghrd_10as066n2.sof output_files/ghrd_10as066n2.rbf
This creates the following two files
ghrd_10as066n2.periph.rbf <-I/O ring configurstion file
ghrd_10as066n2.core.rbf <-FPGA fabric configuration file
I worked my GHRD design down to a (fairly) minimal size by deleting the parts I do not need so I would have a baseline to start adding my code testing. Along the way I discovered there are several elements that are not easily deleted because they have Linux â FPGA connections that need to be disconnected from the Linux side. These didnât stop me so I just kept the unneeded code since it was small anyway.
If you attempt to load a single RBF design without disabling âEarly Releaseâ as shown before you end up failing the second stage of the uboot process, as shown in the case below.
In most of my discussion of loading a flat design there are a few terminology mismatches as I began investigating the problem with some wrong assumptions. The result is that I conflate the conflict with âflat designâ and âpartial reconfigurationâ with the use of the .periph and .core programming files.
The .periph and .core files just separate the I/O definition and initialization from the main body of the FPGA code. This does not necessarily imply that the application you create would not be a flat or partial configuration design, it just separates the I/O and code portions. However if you want partial reconfiguration you need to use the .periph/.core files. And if you program using one RBF file you can only make a flat design (which as I see it is a design that uses the entire FPGA for one application â and of course is not reconfigurable). I could be mistaken in some of the details in this but it has allowed me to get this far so as long as it works it is Ok by me.
Also, there is an âEarly Releaseâ setting in the configuration dialog of the EMIF for HPS IP component in QSYS Pro, but this does not seem to have any impact on making the .periph and .core files required by uboot. I do believe the two âEarly Releaseâ selections (EMIF in QSYS_Pro and âDevice and Pin OptionsâŚâ dialog) should agree with each other.
I hope this can help someone stuck in the same loop I was in a week ago.