open-source-silicon.dev

<https://github.com/mattvenn/caravel/blob/fa5a67879e3076af4b1b21658a46ad25c527c4e4/verilog/dv/caravel/user_proj_example/seven-segment-counter/seven_segment_tb.v#L19>

was there an issue with using the caravel `mprj_io` instead? you get x or z bits if it's not configured for an output which would fail the test, which you'd want incase it's misconfigured right?

I think in this case the test would look fine even if the GPIO was misconfigured to be an input since it's reaching into `pad_gpio_out` which might not necessarily be output

I see what you're saying, but I'm getting a bit overwhelmed with all the signals. I thought the safest thing was to reach into the pad itself. Then if there was something wrong it would show.

I'm using a shared include with base / widths of `mprj_io` to try avoiding picking the wrong wires between user proj IO and tb test IO. Not perfect but this and the base-width syntax for part select has worked well for me so far
<https://github.com/dan-rodrigues/caravel-vdp-lite/blob/vdp-lite-clean/verilog/dv/caravel/user_proj_example/vdp_lite/gamepad/gamepad_tb.v#L139>