Introduction (part of MOU) Developing an ASIC costs millions of dollars but there could be subtle design mistakes. A much lower-cost and faster turn-around is to have a high-performance Hardware-Cycle-Accurate simulator. Normal simulators are too slow to be able to have real-time user interaction. cavatools is therefore specifically designed to give high performance simulation of actual hardware, allowing Hardware Architects to guage whether their Micro-Architecture will meet the end-user requirements, long before money is spent on Mask Charges. ---- (Note: bug #1039 is not part of this grant but was added after 2022-08-071 was signed, instead added to ongoing #961) Task list # Support missing instructions Besides introducing prefixed instructions, SVP64 extensions also introduce many word instructions. Some simply extend vanilla PPC with the new functionality and can be used even outside of SVP64 extensions (for example, a new set of math functions). Others manipulate on SVP64 context and manipulate control flow. The support for all these instructions must also be present in binutils. Budget: 3000 EUR URL: https://bugs.libre-soc.org/show_bug.cgi?id=958 --------- # Switch reference assembler to machine-readable specs We already have various machine-readable files which describe the instructions, the prefixing rules and other essential important parts. However, the current assembly code does not consider all this information, and instead duplicates some parts of it in the code, or implements some bits of the logic which should have relied on the generation. The current approach leads to code duplication and software rot; what's worse, there's a need to keep track of instructions in the code whenever these are changed in the specifications. This task intends to build the essential parts needed to make most of the assembly to be generated automatically. Budget: 5500 EUR URL: https://bugs.libre-soc.org/show_bug.cgi?id=947 --------- # Support missing specifiers By the time the initial binutils support was implemented, we had no real handling for many of the branch specifiers. It was decided that we should postpone these for a while. The real support for Python assembly was implemented only in September 2022, and has not been merged into binutils since then yet. Budget: 1500 EUR URL: https://bugs.libre-soc.org/show_bug.cgi?id=976 --------- In scope of supporting cavatools, one of crucial pieces is instruction decoder for Power ISA. This task can re-use some of existing infrastructure of the project, relying on nMigen and insndb. It is critically important to provide the code which can be used as a standalone entity: we can and should generate some bits for this code, but it should not rely on external components other than cavatools itself. Budget: 5500 EUR URL: https://bugs.libre-soc.org/show_bug.cgi?id=979 --------- # Implement C-based Power ISA pseudocode compiler Besides the actual decoding to understand which instruction we're going to simulate, we also need a way to specify the actual logic behind the instruction to be executed. We already have human-readable specification in Markdown format, and successfully used it for our reference Python-based simulator. We need to follow the same approach for cavatools, and generate the code for all PowerISA instructions. Budget: 5500 EUR URL: https://bugs.libre-soc.org/show_bug.cgi?id=980 --------- # Support PowerPC ABI in cavatools Besides being able to execute PowerPC instructions in cavatools, we also need to support the PowerPC ABI to execute the real code interacting with the OS. Budget: 4500 EUR URL: https://bugs.libre-soc.org/show_bug.cgi?id=981 --------- # Support PowerPC ABI in ISACaller We need to maintain the reference Python simulator, which also lacks proper userspace ABI support. The ABI support is essential for running real userspace applications. Budget: 4500 EUR URL: https://bugs.libre-soc.org/show_bug.cgi?id=982 --------- # Support PowerPC SFFS compliance XXXX MUST NOT DUPLICATE WITH bug #999 ! XXXX (resolved by focussing on cavatools having ELF dynamic library loading) We need to continue works on Scalar Fixed-Point + Floating-Point Compliancy Subset (SFFS). The Linux distribution must be compiled and be able to run; this might be a multi-phase work due to the huge amount of packages to support. In particular this stage should focus more on what has to be done to cavatools to get it to run SFFS binaries: ELF linker loading of dynamic libraries. Budget: 6000 EUR URL: https://bugs.libre-soc.org/show_bug.cgi?id=983 --------- # Support SVP64 in cavatools Once we've reached the stage when we're capable of executing vanilla PowerPC instructions with cavatools, we need to extend this support with SVP64 extensions. Budget: 8000 EUR URL: https://bugs.libre-soc.org/show_bug.cgi?id=984 --------- # Integrate cavatools into test API We already have a solid infrastructure for testing purposes. However, it does not support cavatools yet. In scope of these tasks, we need to integrate cavatools into our test infrastructure via pygdbmi. Budget: 3000 EUR URL: https://bugs.libre-soc.org/show_bug.cgi?id=985 --------- # cavatools-related administrative activities Any task includes activities related to issue tracking and monitoring. This includes not only organizing the tasks, but also providing comments to all subtasks, participating in dicussions, budget synchronization and similar activities which rather fit the main task than any of the standalone subtasks. Budget: 3000 EUR URL: https://bugs.libre-soc.org/show_bug.cgi?id=987
system calls in power-gem5: https://github.com/gem5/gem5/blob/stable/src/sim/syscall_emul.cc https://github.com/gem5/gem5/blob/stable/src/arch/power/linux/se_workload.cc#L109 there will be similar in both qemu and cavatools.
qemu system calls: https://github.com/qemu/qemu/blob/master/linux-user/ppc/syscall.tbl here's how they are called: https://github.com/qemu/qemu/blob/master/linux-user/ppc/cpu_loop.c#L336
very interesting! cavatools simply passes the syscall directly to the host operating system, in assembler https://www.felixcloutier.com/x86/syscall.html https://github.com/phaa-eu/cavatools/blob/main/uspike/proxy_syscall.cc#L57
scary! https://stackoverflow.com/questions/37032203/make-syscall-in-python
Well, good news is, I did this a lot, there's nothing new here. :-)
(In reply to Dmitry Selyutin from comment #5) > Well, good news is, I did this a lot, there's nothing new here. :-) i think the python version should do full syscall emulation rather than attempt to proxy to real ones. the only reason proxy works in cavatools is because it is using *actual* userspace memory (!) for ISACaller any "memory" is entirely emulated.
(In reply to Luke Kenneth Casson Leighton from comment #6) > the only reason proxy works in cavatools is because it is using > *actual* userspace memory (!) This sounds really creepy. > for ISACaller any "memory" is entirely emulated. This is the way to go.
imho eur 6000 for the pseudocode to C compiler is fine, don't let our discussion about what exactly we should do for that task block submitting to nlnet.
(In reply to Dmitry Selyutin from comment #7) > (In reply to Luke Kenneth Casson Leighton from comment #6) > > the only reason proxy works in cavatools is because it is using > > *actual* userspace memory (!) > > This sounds really creepy. it's how cavatools gets 250 million instructions per second per process per host core, where other emulators are a minimum of 20x slower and flat-out incapable of multi-core support! peter hsu did not design cavatools to be "pretty and nicey-nicey", he designed it to give developers of applications a good chance at *real-time* high-performance computationally-extreme emulation, so that you can test an application *in full*, iteratiely adding new instructions and new micro-architectures, getting the design right before dropping 16 to 32 ***MILLION*** dollars on Mask Charges, only to find that you utterly screwed up. this is not qemu. we are not in kansas no more. > > for ISACaller any "memory" is entirely emulated. > > This is the way to go. in ISACaller yes. and we can expect performance to degrade even further than it already is. however, we get readable code.
I dropped all the links from the overall task description to keep it reduced to a task list. Any reader should carefully check the entire task discussion anyway, so here these links are: https://libre-soc.org/nlnet_2021_3mdeb_cavatools/ https://github.com/phaa-eu/cavatools https://www.bsc.es/research-and-development/software-and-apps/software-list/cavatools
Updated the milestones for the subtasks. What should be the next step?
Ping to all interested parties.
(In reply to Dmitry Selyutin from comment #11) > Updated the milestones for the subtasks. What should be the next step? i thought it might be sensible to put a "management" budget on here, part for you writing the mou, part for me, and part for future updates to budget-sync and other odds. my feeling is that cavatools eabi is going to be near-trivial, it can come down to EUR 4000. management can be EUR 3000, that leaves EUR 1000 which can go into one or more other tasks which are abit low. #976 and #958?
(In reply to Luke Kenneth Casson Leighton from comment #13) > (In reply to Dmitry Selyutin from comment #11) > > Updated the milestones for the subtasks. What should be the next step? > > i thought it might be sensible to put a "management" budget on here, > part for you writing the mou, part for me, and part for future > updates to budget-sync and other odds. Fair enough, I agree, but with a remark below. > my feeling is that cavatools eabi is going to be near-trivial, > it can come down to EUR 4000. management can be EUR 3000, that > leaves EUR 1000 which can go into one or more other tasks which > are abit low. #976 and #958? I also have a strange feeling that works around integration will need more resources, too. I'm not the one to judge, since I haven't checked this part yet, but I'd be really surprised if integrating cavatools to our testing API would be trivial. But I'm afraid this is to be discovered yet. I'm unlikely to do it due to time constraints, but others will almost certainly handle it. How about the scheme below? 1. Cut ABI tasks to 4500 EUR each (#981, #982). 2. Since we now have 5000 EUR, we can assign 3000 EUR to management, 500 EUR to #976, 500 EUR to #958, and 1000 EUR for wrapup which can migrate to #985 if possible? Or we can assign 1000 EUR #985 immediately if you can confirm this is a difficult one. I'm not sure of the level of gdb support we have now. If OK, I will raise the management task with 3000 EUR, will assign 500 EUR to each #976 and #958, and will move the 1000 EUR to either wrapup or #985, depending on our conclusions.
TL;DR: I feel that #985 is underestimated too; please let me know your opinion.
(In reply to Dmitry Selyutin from comment #14) > Fair enough, I agree, but with a remark below. ack > > my feeling is that cavatools eabi is going to be near-trivial, > > it can come down to EUR 4000. management can be EUR 3000, that > > leaves EUR 1000 which can go into one or more other tasks which > > are abit low. #976 and #958? > > I also have a strange feeling that works around integration will need more > resources, too. I'm not the one to judge, since I haven't checked this part > yet, but I'd be really surprised if integrating cavatools to our testing API > would be trivial. yes, very. cavatools already supports gdbmi - gdb remote machine interface. a new register-set-definition is needed, but that's needed anyway. > But I'm afraid this is to be discovered yet. I'm unlikely > to do it due to time constraints, but others will almost certainly handle > it. How about the scheme below? > > 1. Cut ABI tasks to 4500 EUR each (#981, #982). ahh ISACaller ABI is *not* trivial: unlike cavatools which thunks directly onto existing EABIs with a trivial shim (so as to get absolute max performance) ISACaller has to implement a **FULL** and **TOTAL** implementation... in python. there _may_ be an existing implementation out there but finding it will be a pig: try searching "linux abi implementation in python" > 2. Since we now have 5000 EUR, we can assign 3000 EUR to management, 500 EUR > to #976, 500 EUR to #958, and 1000 EUR for wrapup which can migrate to #985 > if possible? sure. > Or we can assign 1000 EUR #985 immediately if you can confirm this is a > difficult one. I'm not sure of the level of gdb support we have now. full remote gdb machine interface is in cavatools. but only RV. not ppc64le. > If OK, I will raise the management task with 3000 EUR, will assign 500 EUR > to each #976 and #958, and will move the 1000 EUR to either wrapup or #985, > depending on our conclusions.
Updated: https://bugs.libre-soc.org/show_bug.cgi?id=981: 8000 => 4500 https://bugs.libre-soc.org/show_bug.cgi?id=982: 6000 => 4500 https://bugs.libre-soc.org/show_bug.cgi?id=958: 2500 => 3000 https://bugs.libre-soc.org/show_bug.cgi?id=976: 1000 => 1500 https://bugs.libre-soc.org/show_bug.cgi?id=987: 0 => 3000 (management task) https://bugs.libre-soc.org/show_bug.cgi?id=939: 0 => 1000 (this task)
Upd: comment #17
Upd: assigned 1000 from wrapup to cavatools test API support (1000 EUR from #939 => #985)
(In reply to Dmitry Selyutin from comment #17) > https://bugs.libre-soc.org/show_bug.cgi?id=939: 0 => 1000 (this task) really, that EUR 1000 should be in the management task. but you've not put a subtask budget for it. i'm re-running budget-sync to check things. ERROR:root:Total budget assigned to payees (cf_payees_list) doesn't match expected value: bug #987, calculated total 500, expected value 3000 ERROR:root:Bug's assigned milestone doesn't match the milestone assigned to the root bug: descendant bug #988, root bug #961 yep you've assigned EUR 500 to yourself but the remaining EUR 2500 is unassigned *within* that task. what instead must be done is to create a sub-task of #987.
(In reply to Luke Kenneth Casson Leighton from comment #20) > what instead must be done is to create a sub-task of #987. done, sorted. i double-checked the comment #0 totals, they're EUR 50,000. i'll send comment #0 as the Schedule A to Michiel, along with a JSON file.
andrey you added two extra tasks, remember to let people know by putting the commit diff link here https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=a3f5eea083