| Summary: | create cycle-accurate JIT-compiler-based processor simulator | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Jacob Lifshay <programmerjake> |
| Component: | Source Code | Assignee: | Jacob Lifshay <programmerjake> |
| Status: | CONFIRMED --- | ||
| Severity: | enhancement | CC: | libre-soc-bugs, lkcl, programmerjake |
| Priority: | Low | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| NLnet milestone: | --- | total budget (EUR) for completion of task and all subtasks: | 0 |
| budget (EUR) for this task, excluding subtasks' budget: | 0 | parent task for budget allocation: | |
| child tasks for budget allocation: | The table of payments (in EUR) for this task; TOML format: | ||
|
Description
Jacob Lifshay
2020-06-09 23:43:36 BST
this will likely need to happen after the october tapeout, if at all. (In reply to Jacob Lifshay from comment #0) > This could allow simulating our processor model much faster than most other > methods. pearpc already contains both a JIT and a cycle-accurate mode. there is also power-gem5 which was recently updated to be capable of running a linux kernel (and the 500mb/sec memory leak fixed). both of these are written in c / c++ and are extremely fast. is there a compelling reason to, using an appropriate colloquialism, "reinvent the wheel?" (the main purpose of deliberately writing the simulator in python was to get "working knowledge" handle on POWER9 internals: it's served that purpose extremely well, and also very deliberately uses the exact same POWER instruction decoder as used in the hardware) (In reply to Luke Kenneth Casson Leighton from comment #2) > (In reply to Jacob Lifshay from comment #0) > > This could allow simulating our processor model much faster than most other > > methods. > > pearpc already contains both a JIT and a cycle-accurate mode. > there is also power-gem5 which was recently updated to be capable of > running a linux kernel (and the 500mb/sec memory leak fixed). > > both of these are written in c / c++ and are extremely fast. > > is there a compelling reason to, using an appropriate colloquialism, > "reinvent the wheel?" I haven't heard of a simulator that is cycle-accurate and JIT-compiled at the same time, all the ones I've seen before are one or the other (perhaps dynamically switchable) but not both simultaneously. This bug report was mostly just to record my idea since it would be useful, rather than a strict requirement. This could be used to do things like run a few tens or hundreds of billions of cycles on a fpga and check that the entire pipeline state matches the simulator exactly -- unless the simulator is quite fast, that isn't very practical simply because the existing simulators are too slow or not cycle-accurate. This is like a bounded-cycle-count formal proof (icr the right term) except that we can run it for millions or billions of times as many cycles. |