Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20641 Discussions

Question regarding loading the SRAM with .ram files and additional .sof file

Altera_Forum
Honored Contributor II
1,412 Views

Greetings, 

 

In one of our course project, we are to design a small processor which requires instructions to be fetched from the SRAM memory. The procedure given is as follows: 

 

1. We open the "DE2_115_ControlPanel.sof" with Quartus, and select the option to open a new programmer configuration. We then program this file onto our FPGA board. 

 

2. We open "DE2_115_ControlPanel.exe" and load the .ram file, which contains our instruction into our FPGA board. 

 

3. We open up a new programmer and select our processor.sof file and program it into our FPGA board. 

 

Later we realized that this procedure is faulty as the second program to the board (step 3) will overwrite the .ram data (instructions) we have previously loaded onto the board. 

 

We were able to find a solution to this problem: repeating step 2 multiple times, and the memory will not be corrupted somehow. 

 

Still, I would like to ask some questions: 

1. What is the "correct" way to do this? I believe there has got to be a more reasonable solution to this problem. For instance, can we specify the address of our second loading so that it does not corrupt the memory file? 

 

2. I initially tried to fix this program by first converting the processor.sof file to a .pof file and load it onto the board. I believed this method would allow the program to stay in a different memory location. (I assume this because it has got to be some sort of non-volatile memory structure as opposed to SRAM, is it FLASH?) But then to load the .ram file I will have to load the "DE2_115_ControlPanel.sof". So how can I return to the processor code I have programmed? Is there some sort of soft-reset that preserves the SRAM data and returns me to the pof file? 

 

3. This is more of a minor question but I think it's quite interesting: why did our solution worked? What is special about writing the SRAM with the same file at the same location multiple times? 

 

Board we used: 

DE2115 CYCLONE IV DEVICE : EP4CE115F297CN 

 

 

 

Thanks in advance.
0 Kudos
2 Replies
Altera_Forum
Honored Contributor II
387 Views

The fact that the memory isn't corrupted and it goes on to work if you repeat step 2 multiple times, I think, is not sufficient to deem that it is 'working'. It certainly shouldn't be relied upon for any solution deemed reliable. 

 

1) By 'the correct way to do this' - are you hoping for a similar procedure that will guarantee that the SRAM contents isn't corrupted? Reprogramming the FPGA with a different image (.sof) won't form part of that solution. 

 

The clean way to do this is to ensure you have a means of programming the SRAM from your 'processor.sof' image. 

 

2) You could program your instructions into FLASH. Once there they will remain there. You'll clearly have to modify your processor image to retrieve the instructions from FLASH rather than SRAM. However, this solution will allow you to reprogram the FPGA as many times as you like - and power cycle the board. 

 

3) There's nothing special about writing the data multiple times. This is just a little evidence that's misleading. 

 

Cheers, 

Alex
0 Kudos
Altera_Forum
Honored Contributor II
387 Views

Hello A_X_H75, 

 

Thanks for your reply! 

 

I understand that there is probably nothing special about writing the data multiple times. However, I do want to point out that all of my classmates are able to consistently have the memory not corrupted after doing this. 

 

I was thinking of programming instruction into FLASH, but then I realize the length of word is different from what we wanted. Of course we can change the load cycle to load more for that but that would be a more complicated work. What I am hoping for is perhaps a way to load the processor.sof file "above" a specific location so that my instructions, which starts at 0x0000 to somewhere pretty much less than 0x0100 may not be affected. 

 

Thanks again for your reply!
0 Kudos
Reply