Cyclone 10 LP Remote Update Simulation

Digging through the code I have traced the source of the X's in the data to the cyclone10lp_rublock instantiated as sd4 within the altera_remote_update_core.v file. The regout port of this block connected to signal wire_sd4_regout is always hiZ, which I believe is causing the read data to eventually become X. The cyclone10lp_rublock seems to be a black box as far as I can see so I can't trace this back any further.

Hi,

Thank you for contacting Intel community.

By setting up simulation, does it mean you run the design using your own board?

Can you run the design using evaluation board by following the userguide? And see if it works fine?

Regards,

Aiman

No I am running a function simulation in Questa. I'm not using it on a board as I assume this will work just fine. What I am trying to do is gain some insight into the process by simulating it in Questa so I can see the details, rather than just that the board reconfigures as indicated by the LEDs.

Thanks

Brad

Hi,

Thanks for the update.

Quick check, did you follow the document below when using Questa?

Regards,

Aiman

Aiman,

I'm not sure which document you are referring to. I don't see anything attached to your message...

Brad

Hi,

Apologize for the delay in response and also the missing link.

Below are the Userguide when using Questa:

https://www.intel.com/content/www/us/en/docs/programmable/703090/21-1/simulation-quick-start.html

https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/questa-edition.html

Regards,

Aiman

Aimen,

I don't see any reference to the remote update core in these docs. I am able to get the simulation to run as you can see from the file attached to my original message. My issue isn't in the running of the simulation itself or with using Questa but rather that the remote update core doesn't respond to reads with correct data. It appears to me that the regout output of the cyclone10lp_rublock instantiated as sd4 within the altera_remote_update_core.v file remains HiZ during the read operation, which then causes the X's to be reported at the top level of the remote update core. I don't have any visibility into the cyclone10lp_rublock black box so I can't tell why this is happening.

Brad

Hi,

Just to confirm, are you using this design example?

https://www.intel.com/content/www/us/en/design-example/714978/intel-cyclone-10-lp-fpga-remote-system-update-design-example.html

Regards,

Aiman

Hi,

I have check this with our internal team, unfortunately, the design example requires the C10 LP evaluation kit, which is the hardware. The RSU IP works with the remote update hard block in the device to provide the expected outputs. Meaning, the design example does not work by simulation.

Regards,

Aiman

Aiman,

So am I understanding correctly that the IP library files that Questa uses to compile the remote update core don't support simulation? I don't understand why Intel would include a remote update core in its simulation library that isn't intended to be simulated??? I understand the intent of the example is to demonstrate the functionality on hardware, but what stops it from working in simulation? I believe I have provided the required testbench and stimulus for the design to simulate properly. The output waveform I provided in my original post seems to work fine with the exception of the read data being returned by the remote update core.

Thanks

Brad