I am trying to run GL simulation on the openram testchip and facing the X propagation for the clock and reset on the entire chip. The top waveform view is from the openram test and the bottom waveform view is the

io_ports

test from the fresh caravel_user_project. The

pll_clk

from caravel clocking is getting X which then causes the entire chip to get X. I have already diff between the caravel GL netlist from the caravel_user_project and the openram testchip design directory, both are identical. Has anybody else faced similar issues when doing GL simulations of their designs?

@User My standalone Gate level simulation with my project, i.e directly driving wishbone was passing and never tried along with caravel - I assumed caravel gl environment is validated by efabless team .. But when i tried GL sim along with Caravel netlist, I see reset/clock unknow at user wishbone interface and reason looks to be la_data_in is tri-stated .. Any one from caravel team can cross-check this issue ?

Yes this is true. If you see in the waveform above the reset/clock provided to user_project_wrapper through wishbone is X

@User @User Who is in charge of design verification of caravel? We are having problems with gate level simulation of caravel (not our project)

@User: I used to be in charge of it before they switched the processor to LiteX, but maybe I can help.

@User I see in gatesim after couple of SPI transaction pass_thru_mgmt (File: housekeeping_spi.v) signal is going unknown. In both the RTL and gate level simulation csclk is going unknown at falling location. I feel like issue related to how simulator behaves RTL vs GL for clock transition unknown value. Please cross-check the gatelevel simulator for wb_host test as this issue may impact all the user project.

@User: The

spi_is_enabled

bit is a register memory-mapped to the management SoC; its purpose is to decouple the housekeeping SPI from GPIO pins 1 to 4 so that those pins can be used by a user project. Otherwise, the housekeeping SPI will be responding to events on pins 1 to 3, especially 3 which is the CSB, which is tied into the chip's reset network. When the housekeeping SPI is enabled and the CSB line goes undefined, the undefined values propagate through the entire chip.

@User wb_port test with

spi_is_enabled = 0

+ without any pull-down to mprj_io[3] RTL simulation passes, But gate level simulation fails. Gatesim passes only with mprj_io[3] pull high. I see there are additional logic uses mprj_io[3] assign pad_flash_csb = (pass_thru_mgmt_delay) ? mgmt_gpio_in[3] : spimemio_flash_csb; In the failure gatesim waveform even through spi_is_enable=0, pass_thru_mgmt_delay goes unknown which makes flash interface to go unknown.

Try

spi_is_enabled = 1

? I'm not sure how the register is implemented in the Litex version of the management SoC, but while the register is named

spi_is_enabled

, the actual signal is

spi_disable

, and I think that is mapped to the low bit of the register.

@User Default wb_port test is with

spi_is_enabled = 1

which fails without pull-up in mgmt_gpio_in[3] in gatelevel sim.

There may be only one way to get around it in simulation, which I've used in several of the testbenches, which is to force a signal onto GPIO 3 in the testbench until the management SoC has disabled the SPI, and then release it. It's a hack, but it works.

@User yes I used this statement inside the testbench to make the GL simulation work

assign  mprj_io[3] = 1'b1;

I have noticed their testbenches doing the same: https://github.com/efabless/caravel_user_project/commit/d99dcd5f8a7d6397ae243020a7f143fdc7ad21d9#diff-bb39a373b9f69e0dea0[…]3c0e9d0e37192f8f372dfL42

You can just assign it to value 1 for the entire simulation period if you are not using that channel as an output or bidirectional pin.

As issue is related to tri-state port, instead of assign or force and release statement, Pull-ups are better option as they are weak pull-up values and does not impact any other driver action on the same ports.