David Lattimore

Using the above code with `proj/example_cfu`, the problem doesn't reproduce. However it's possible to change example_cfu to get the problem to reproduce. It seems that it depends on the behavior...

Yep, I mean functions 0x0 and 0x1. After a little more experimentation it seems as though the instruction invoked needs to be a multiple cycle instruction in order for the...

I captured a trace and confirmed that the CPU is indeed calling the requested CFU function, then when the function returns, it's immediately calling CFU function 0. In the following...

Trace files: [sim.fst.gz](https://github.com/google/CFU-Playground/files/8683857/sim.fst.gz) [sim.fst.hier.gz](https://github.com/google/CFU-Playground/files/8684050/sim.fst.hier.gz) I uploaded the code to produce the trace [here](https://github.com/davidlattimore/CFU-Playground/tree/issue-582-repro). The command to produce the trace was: ```sh (source environment; cd proj/example_cfu; make PLATFORM=sim ENABLE_TRACE_ARG=--trace-fst load) ```

Thanks @Dolu1990! I'll test the change. I'll probably need @tcal-x 's help to build the right version of VexRiscv

I still need to do more testing, but the commit "CfuPlugin now only fork when the rest of the pipeline is hazard free" does appear to fix the problem. I've...

As far as I can tell, that commit by itself solves the issue. At least my repro code no longer reproduces the problem with just that commit added.

This is an optional workaround for #582. It's off by default since it does incur a small performance penalty.

We have now submitted a proper fix for this in hps-firmware and have rolled back the equivalent of this PR. I'll wait until we've updated VexRiscv in CFU Playground and...

I needed this for a project I'm working on and have something that's working well for me. The interface looks like this: ```rust pub trait I2cPeripheral { /// Returns the...