Anlu SparkRoad Development Board Review (7) MCU Soft Core IP Trial

cruelfox

Anlu SparkRoad Development Board Review (7) MCU Soft Core IP Trial [Copy link]

 

　　Clues can be found in the information on the Internet. Anlu provides some kind of "soft core" IP for its FPGA - that is, implementing something similar to an MCU in the FPGA.

　　However, there is too little relevant information, and there is only a "user note" for reference. In that article, the author used TD 4.6.13941, and there is an MCU selection in IP Generator

　　But I didn't see the "Micro_Controller" group in the TD 4.6 I installed! I also re-downloaded several versions of 4.6, including the 4.6.13941 mentioned in the article, but it didn't appear there... And the IP core section of the TD documentation didn't mention MCU either.

　　I found this in the IP reference document on Anlu's website:

　　But I still couldn't download it after registering via email, so I asked the forum administrator for help and got this document. The software version description is as follows:

　　At least TD 4.6.1 should support it, but the one I installed does not, which makes me confused. The feedback I got from Anlu through the admin is that this is an old version of the MCU and will no longer be maintained. Could it be that the TD downloaded from the website has removed this IP?

　　I downloaded the TD 5.0.5 SP1 version again and finally saw an MCU IP

　　Click in, the configuration interface is like this:

　　Different from the IPUG103 document:

　　It may be due to the "new version". The main difference is the initialization of memory. It used to use a .mif file (common practice on FPGA), but now it has become 4 MEMFILEs. It seems that it can be directly given to the .txt file. The TD user guide introduces it like this (which is too brief):

　　I first generated an IP to see what it looked like. TD worked for a while and generated a .v file with the word _gate in the file name.

　　This is a netlist file, not a "source code", which is equivalent to a black box. There are not many external interfaces, including 32 GPIO ports, a set of UARTs, and a 32-bit bus.

　　The trouble is that there is no more information about this CPU. I only know that it is a RISC-V, but I don’t know the address mapping, and there is no SDK.

　　The program that the CPU runs must be provided by MEMFILE, because if there is only pure SRAM inside, there is no need to initialize it, so Block RAM must have the function of program storage. Because Block RAM is the IP of FPGA, the hierarchical module reference can be found in the code:

　　Pay attention to a few places:

　　The .INIT_FILE line converts the content of dummy.txt I filled in into a string of binary numbers, which means the initial value of BRAM is here.

　　This is a dual-port RAM, port a is for read-write operation, port b is for read-only operation. It can be suspected that port b is used to fetch program instructions. The address input addrb is connected to the wire al_000001F789EBC9A0, and it is suspected that it is the address of the program fetch instruction. I can lead it out of the CPU module for monitoring.

　　Each BRAM data is 8-bit wide, and the CPU uses four BRAMs to splice into 32-bit for joint operation.

　　Next, in order to make the CPU run, I will create a program space that does nothing but repeat one instruction. Looking at the RISC-V manual, opcode 0x33 corresponds to arithmetic and logical operation instructions, which will not have side effects, so I fill the CPU internal RAM with 0x33333333 (to avoid the influence of byte order), and you should be able to see the execution address sequence change.

　　In order to observe the CPU running, give it a very slow (Hz level) clock, and lead the internal BRAM address to the digital tube display driver I have written. If you can see that the address automatically increases, you can probably determine that the program is running.

　　When the CPU is reset, the program BRAM address is decimal 99. After it starts running, the address increases every few clock cycles to 100, 101, 102, and so on. However, it stays at address 6 for a long time, which is not clear. It may not have any data to read. It seems that the execution efficiency of this soft core is not high, and it takes several clock cycles to execute one instruction.

　　To test whether this soft core executes the RISC-V program, we need to write a real program to verify it later.

littleshrimp

It's very similar to early computer troubleshooting cards.

wangerxian

We still need to encourage more people to research domestic FPGAs!