Memory Map of RISC-V Angel
As my colleague started to modify the linker script, I found more problems to be solved in the simulator.
The RISC-V Angel Memory
One of my concern this week is to set or limit the memory that could be created by the simulator, which is also the size for the RAM of simulator. The default RISC-V Angel RAM is set to 8 MiB (MegaByte), which can be calculated from
Total Memory (byte) = 1 x 1024 x 1024 = 10485760 byte
Total Memory (bits) = 8 x 1024 x 1024 = 8388608 bits
Besides, I also noticed that the RISC-V Angel original source code does not actually read the most significant bits, as you can referred in here, in the
for loop of loadElf() function. Thus, which in my case, I would need to change the reading of most significant bits.
The Two Complement Issue of RISC-V Angel
As I am going to read from the address 0x80002000, I actually need to store and load these addresses from the RAM, which it would result in a negative array of -7fffxxxx. These addresses is not translated to two compliments. Loading of negative arrays would produce undefined results, which is not desirable. However, one useful tool that had been used by RISC-V Angel was the Closure Library, which contains the Long function that would translate the addresses into two complements automatically. Thus, in order to process the addresses, I have to translate the data into Long type from Closure library, to get rid of the negative array.
As the work progressed, my supervisor explained to me about the memory-mapped I/O that is going to be used by the simulator. Fortunately, RISC-V Angel actually uses memory-mapped I/O, and the work that had been done on previous week was not a waste. One biggest confusion from me and my colleague Sumia, was the addresses of the I/O and the instructions are the same, and we assumed that the processor is actually using Port-Mapped I/O, which it is not! The AEMB processor actually uses memory-mapped I/O. In order to load and store the instructions for I/O properly, the store and load instruction need to be masked to treat these addresses for the I/O, not for the instruction, so that no instructions memory would be overwrite by the load and store instructions.
Hopefully by next week, the GPIO module would be working fine with the integration that should be done.