Different okHost Ports for Simulation vs. Implementation XEM8350

I’m using the XEM8350 and see that the okHost HDL module defined in okLibrary.v has several ports that are not present in the okHost simulation (okUHs, okHUs, okUHUs, okClks, okHEs, okEHs, ok_done).

I’m accessing the okHost simulation module from the file path \Opal Kelly\FrontPanelUSB\Simulation\USB3\Verilog in the downloaded Opal Kelly files.

Is there an updated okHost.v simulation file that has these new signals? The signal ok_done, in particular, seems to be used in the RAMtest example, so I’m assuming this was simulated at some point? Where do I find this updated simulation file?

Thanks!

The additional signals within the XEM8350’s library are for the second USB 3.0 interface.

The ok_done is used to signal to the USB microcontroller that configuration has finished on the FPGA. This signal is not relevant in simulation and can be ignored.

Moving forward with simulation for the XEM8350, just instantiate two okHost modules. One for the first USB 3.0 interface and another for the second USB 3.0 interface. Then you’ll need to add a okHostCalls2.v with definition name changes to uniquely identify signals and calls for the second USB 3.0 interface.

For example task SetWireInValue() will come from okHostCalls.v directed at the first okHost.v instantiation.
and a new task SetWireInValue2() will come from okHostCalls2.v directed at the second okHost.v instantiation.
There will be a couple of tasks,regs, and wires within okHostCalls.v that will also need to be uniquely identified for the second okHost instantiation. The work required is mostly just stitching things together, nothing more.

We’ll likely rework this for the XEM8350 and provide it as a resource in our next SDK release. This should be enough information to get you going. I’d be happy to nudge you in the right direction if you get stuck, so feel free to reach back out.

signal ok_done isn’t in these examples:

Is that a necessary signal?