Jiuyang Liu
Jiuyang Liu
cc @SpriteOvO, I wonder if it's possible for layer to have their own `filelist.f`, e.g. `filelist.Verification.Assert.f`.
I personally would not accept this. This feature should be resolved by Probe API which natively supported by Chisel. Boring will affect the RTL, which is always a bad idea...
See https://github.com/riscv/riscv-opcodes/blob/07b21cc5143a15959eda12e30aa40cea0971efe0/arg_lut.csv#L45
`nf` is already encoded in `arg_lut`, explicit using them in the table is strange, and may break the backward compatibility.
I see, adding seg load store instruction explicitly look good to me. If this is merged, we can follow it.
Removing support to `xtheadvector` might speed up this PR? `xtheadvector` is well-known for its [ghost write](https://ghostwriteattack.com/) bug, and community already has K1 as the alternative to RVV 1.0, maybe there...
Thanks @SpriteOvO and @CircuitCoder for doing this job! That's a really important job, T1 is counting on this PR to remove the verilator emulation backend. Here is my two cents...
I personally like the idea of removing the entire `filelist.f`. because of the lack of consistent ABI for it. random user will get trap because of issue like this. Maybe...
I think we can add more documentation for the unittest for [`firrtl.c`](https://github.com/llvm/circt/blob/09f07f5a601a264d69bf6d1c65fcd9a6b067497e/test/CAPI/firrtl.c#L86)? and provide a link to the panamaconverter usage from chisel.
My question is if there are multiple modules open a same `fd`, and try to write to it, would that be an issue? If not, I'm proposing this: add fd...