any help in understanding FESVR and HTIF

[Shubham Roy]

hi,
I am trying to use the htif in my core with minimal changes to the src code and have a smooth integration of the HTIF, but I find that I need to understand the code in great detail to do so, can someone suggest some resources to understand the FESVR(its working and code) in great details or has anyone tried the above and would like to share some insights and how to go about it.

My desired result is to use HTIF in Chromite core and proxy the system calls and use the host machine for system calls and write back the results.

Any sort of help is appreciated 

Regards
Shubham Roy

[Bruce Hoult]

This is some kind of black magic.

If you have a test core in an FPGA or on an experimental chip without any I/O facilities then HTIF's "tohost" and "fromhost" are physical registers connected to the outside world somehow (UART, whatever). PK catches system calls and wraps them up in some kind of packet and sends them out via tohost and gets a respose back via fromhost. On the other end of that link is FESVR, which executes your system calls on the host system. So your little core running in an FPGA or whatever can execute syscalls on the host system via a cable. I think you use a linker script to assign the correct register addresses to the tohost and fromhost globals, but I've never used HTIF with physical hardware.

If you have a program binary that is being emulated in Spike (or qemu did have this functionality, I'm not sure if it still does) then tohost and fromhost are just arbitrary global variables. Spike looks inside the elf file to find out where in memory they are. FESVR is built into Spike (host computer code). PK (RISC-V code) is run by Spike and acts as the OS for your user-mode program.

See also:

https://github.com/riscv-software-src/riscv-isa-sim/issues/364#issuecomment-607657754

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/c21245ad-1a35-4596-9ab4-df36b161d502n%40groups.riscv.org.

[Shubham Roy]

First of all thanks for the response it gave me a overview of what's happening, and linking the GitHub issue really help.

i still have some doubts and thought I should run by you 
1. I understood the PK catches the syscall and wraps them and sends a kind of packet, the packet here does it refer to the DTM(debug transfer module)  packet?if so is this the responsibility of the PK to encapsulate all the details inside a DTM packet? or does PK just write to the memory location and the Debug module picks up the location and then encapsulates the thing into a DTM packet
2. while going through the code of FESVR I figured that the FESVR running at the host machine captures the DTM packet9SENT OUT BY THE RISCV SIDE DEBUG MODULE) and decouples the information then finds the syscall and uses the host machine to execute the operation of that syscall finally returning a DTM response packet to the Debug module to the RISCV side and upon receiving the response the debug module decouples the response packet and write that response to the fromHost memory location and pk pick up the response form there on...... is my understanding correct?
3. would it be possible to eliminate the debug part and directly let the FESVR interact with the memory in the RISCV side