Cyclone 10 LP Remote Update Simulation

[BCrowell]

I am trying to figure out the details on the remote update so I downloaded the example project (Cyclone 10 LP Remote System Upgrade Design Example) and set up a simulation to run rather than just use it on the eval board. However, the remote update core doesn't seem to respond to any of the reads I added with correct data. The relevant data bits are always X's for the reads I did, one to the trigger register and one to the config address register. See the attached screen grab for the waveforms. I am wondering if there is an issue with the simulation model of the core or is there something different that needs to be done to properly read the data from the core? 

Thanks

Brad

[BCrowell]

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. 

[NurAiman_M_Intel]

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

[BCrowell]

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

[NurAiman_M_Intel]

Hi,

Thanks for the update.

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

Regards,

Aiman

[BCrowell]

Aiman,

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

Brad

[NurAiman_M_Intel]

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

[BCrowell]

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

[NurAiman_M_Intel]

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

[BCrowell]

Yes, that is the example design I started with.

Brad

[NurAiman_M_Intel]

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

[BCrowell]

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

[NurAiman_M_Intel]

Hi Brad,

Apologize for the inconveniences. Let me double check again with our internal team and I will try to get back to you the soonest.

Regards,

Aiman

[NurAiman_M_Intel]

Hi,

Sorry for the delay as we are investigating this case.

After some digging on the IP functional spec, and looking back at the simulation waveform, there are several items to possibly cause the data_out to return X’s:

The first read on 3’h7 with read_source set to 1. In this case, the IP is trying to read the past status 1 reconfiguration trigger source. This is only available if the current factory configuration comes from a previous application 1 reconfiguration. I suspect this is the reason data_out[4:0] = 5’hX.

The second read on 3’h4 with read_source set to 0. The IP is trying to read the factory boot address on the configuration device. The output is data_out[25:2] = 24’hX since there is no actual factory image available on the configuration device.

Regards,

Aiman

[BCrowell]

Aiman,

Thanks for this info. Do you know how the remote update logic obtains the data for those registers? Does it have to read the config flash memory to obtain the register data? Is there a way to simulate that process? 

What registers could I read from in the simulation and get a valid response from? What I am trying to achieve is a baseline for my factory configuration when it comes time to set that up and control the register values to initiate the proper loading of the application configuration. 

Thanks

Brad

[NurAiman_M_Intel]

Hi,

Apologize for the delay in response.

Just some update after further digging,

We do not support simulation of the remote update IP because it is not feasible to emulate how the IP can perform reconfiguration in simulation environment. This is actually due to the IP works with the hardwired remote update block in the device.

The IP can be compiled for simulation, but there is no guarantee it will work properly.

Regards,

Aiman

[BCrowell]

Aiman,

Thanks for this update. It is unfortunate that the core isn't fully simulatable, but does seem to work well enough to understand the interface and how it works. 

Thanks

Brad

[NurAiman_M_Intel]

Hi,

We are sorry if this has cause you inconveniences. I will proceed to close this case for now.

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.