Piotr Binkowski

I did some initial tests using this code https://github.com/antmicro/CFU-Playground/tree/hps (this uses #280 as a base and uses updated LiteSPI core) From my tests it looks like Vex Slim and Vex...

I did some more builds and it looks like `hps_accel` has its critical path inside VexRiscV ``` Info: Critical path report for clock 'por_clk$glb_clk' (posedge -> posedge): Info: curr total...

I've generated JSON timing reports and with help of a simple python script (Currently it is located on this branch https://github.com/antmicro/CFU-Playground/tree/hps-fmax) It can be used to extract list of n...

And for comparison `example_cfu` report looks like this ``` VexRiscv.IBusCachedPlugin_cache._zz_10_FD1P3IX_Q_D_WIDEFN9_Z_1$widefn_comb[0]$ -> VexRiscv.IBusCachedPlugin_cache._zz_10_FD1P3IX_Q : 12.696999549865723 VexRiscv.IBusCachedPlugin_cache._zz_10_FD1P3IX_Q_D_WIDEFN9_Z$widefn_comb[0]$ -> VexRiscv.IBusCachedPlugin_cache._zz_14_FD1P3IX_Q : 12.633999824523926 VexRiscv.IBusCachedPlugin_cache._zz_10_FD1P3IX_Q_17_D_WIDEFN9_Z_1$widefn_comb[0]$ -> VexRiscv.IBusCachedPlugin_cache._zz_10_FD1P3IX_Q_16 : 12.597000122070312 VexRiscv.IBusCachedPlugin_cache._zz_10_FD1P3IX_Q_17_D_WIDEFN9_Z_3$widefn_comb[0]$ -> VexRiscv.IBusCachedPlugin_cache._zz_10_FD1P3IX_Q_14 : 12.583000183105469 VexRiscv.IBusCachedPlugin_cache._zz_10_FD1P3IX_Q_D_WIDEFN9_Z_2$widefn_comb[0]$...

If you want to do some tests on your side, you can use this script is located here https://github.com/antmicro/CFU-Playground/blob/hps-fmax/scripts/nextpnr-timing.py and to get JSON outputs with you will need this https://github.com/YosysHQ/nextpnr/pull/810...

I did another test with `SlimCfu` variant of the VexRiscV and it looks like it can reach 64MHz on some runs (around 65MHz in this one but only 60MHz in...

And I think removal of those CSRs might have helped to simplify instruction decoding and register access logic so in theory we could look into simplifying that even more by...

I did some more tests and I've noticed that in the CFU `rsp_valid` uses `cmd_valid` input from the Vex directly which creates a fairly long path which in the end...

With some more tinkering I've managed to get safely above 70MHz (This run used seed `3107`) ``` Info: Max frequency for clock 'por_clk$glb_clk': 76.13 MHz (PASS at 70.72 MHz) ```...

And on top of that I've managed to fix the issue I had earlier with the modified Cfu so this is passing `hps_accel` golden tests on real hardware.