Description
We used to use so-called "GNU hostlink" for interaction between simulated ARC target & nSIM, see https://github.com/foss-for-synopsys-dwc-arc-processors/newlib/blob/arc-2020.09/libgloss/arc/nsim-syscalls.c. While it does work quite OK-insh with nSIM there're some annoying limitations of that implementation. That's due to the usage of "syscall"-based interface very similar to how user-space application calls for Linux kernel services: we put data in registers and execute trap0 (on ARCompat cores) or swi (on ARCv2 cores) instruction to inform the debug host about pending request from the target (see https://github.com/foss-for-synopsys-dwc-arc-processors/newlib/blob/arc-2020.09/libgloss/arc/nsim-syscall.h#L269).
- It only works with nSIM, but not with real HW target, because real HW doesn't know anything about "tricks" it needs to to when
trap0/swigenerates an exception. - In case of ARC core configured with reduced register file (
-rgf_num_regs=16in ARChitect tool parlance) some of the basic registers are missing (R4-R10 are not implemented in that configuration) so we just cannot pass all the parameters as with complete register file. See [newlib/libgloss] Add support for RF16 configurations #231.
Solution is in use of a so-called "MetaWare Hostlink" interface (used by default by MetaWare tools, thus the name) which is implemented via mail-box in target's memory which is then accessed by debug host either directly in case of simulation or via JTAG in case of execution on FPGA, real silicone or even in RTL simulation (in xCAM or VCS).
Sources of that library are distributed as a part of MetaWare tools (see MetaWare/arc/lib/src/hl/hl_g) but to make sure there're no license problems and we do like how it is done (see https://en.wikipedia.org/wiki/Not_invented_here) it might want to come up with our own implementation as a part of libgloss under BSD-like license and then even substitute with it original MW's implementation to save time on maintenance.