Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
9 years ago

Couple of questions about the remote update system

Hello!

This is my first time around this forums, so greetings to all of you. I hope you can help me with the following questions.

I've been tasked with implementing the remote update functionality for our FPGAs, we are currently using Cyclone V (5CGX variants, at the moment). After using the ASMI and remote_update IPs and creating the necessary user logic, everything is working perfectly!

However, I still have some doubts I haven't been able to completely clear out by reading the corresponding documentation, handbooks and application notes. A couple are just me wanting to be certain about how they work.

1) Since the update circuitry is implemented in dedicated hardware within the FPGA there is no way this could be affected by SEU errors, is this correct? What about the registers that hold status or watchdog timer values?

2) The watchdog's documentation states that it counts based on the "watchdog timer internal oscillator" and the CycV datasheet only mentions a minimun and maximum value (5.3 to 12.5 MHz).

I'm not certain if this is an independent oscillator that needs configuring or if it's the same clock used as the "Active serial clock source" in the Device and Pin Options tab. If it's the first, where do I find this setting?

I don't think it's the same clock used for the remote update IP input clock source since this wouldn't make any sense if the configuration fails (that clock could very well disappear), is that right?

4) Is it possible for a configuration error during user application to somehow get stuck resetting the watchdog timer? I see it resets on the falling edge of the reset signal, and I believe that in a worst case configuration error the signal would remain at a constant value (if it remains as it is at all, it *is* a configuration error after all), but I have no backing up for that claim.

5) There's also the reset based on CRC configuration error check (during user application, not while configuring), I think this is not enabled by default and I can see on the Device and Pin Options tab, the Error Detection CRC category, the item "Enable Error Detection CRC_ERROR pin" describes that it needs to be turned on for the device to check the validity of the programming data. However, if that pin is being used for some other purpose (it does have a couple of alternate functions) how would I go about enabling the CRC check? What about making the remote update IP reconfigure on CRC error? I know it's reported on the status register but you can only configure the watchdog enable through this IP.

6) Is there any other usual approach to reconfiguring the device on error? As it is right now, we don't have external access to the nCONFIG pin, but if that turns out to be a better solution than using the watchdog and CRC check we might be able to change the design... it doesn't seem like it would be a better idea though.

Thank you all for your time!

Regards,

Sebastian.

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    1) No, Your hardware has not been implemented using hardcore, so they could be affected by SEUs. Even if you utilize a hardcore, its configuration can be affected by SEU.

    5) Your configuration determines the purpose of the CRC related pins. You can configure them for your requirement. You should be aware of the board, you are configuring. You cannot check which pin is used for which purpose unless you know the board connectivity.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Thank you for your response, I'm afraid I'm still not very clear on the matter so I hope you don't mind my asking some more about your answers.

    --- Quote Start ---

    1) No, Your hardware has not been implemented using hardcore, so they could be affected by SEUs. Even if you utilize a hardcore, its configuration can be affected by SEU.

    --- Quote End ---

    Do you mean that not all Cyclone V models come with the dedicated remote update hardware? The documentation doesn't mention this, as far as I could tell all of the CycV have the dedicated circuitry for this.

    --- Quote Start ---

    5) Your configuration determines the purpose of the CRC related pins. You can configure them for your requirement. You should be aware of the board, you are configuring. You cannot check which pin is used for which purpose unless you know the board connectivity.

    --- Quote End ---

    I'm aware what the pins are used for in the board, what's not clear to me is whether the pin will still be available for this other functions once I've checked the "Enable Error Detection CRC_ERROR pin" or if it'll be hardwired to the CRC function and no longer available to the application.

    Thank you.

    Regards,

    Sebastian.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    --- Quote Start ---

    Do you mean that not all Cyclone V models come with the dedicated remote update hardware? The documentation doesn't mention this, as far as I could tell all of the CycV have the dedicated circuitry for this.

    --- Quote End ---

    I don't mean that. As far as I know the Altera remote update IP core is a softcore, not hardcore; i.e. It can exist in the FPGA using some logic cells or it may not exist at all if you do not want remote update feature. This means that existence of this IP core within your FPGA depends on its current configuration, which is in turn susceptible to SEUs.

    --- Quote Start ---

    I'm aware what the pins are used for in the board, what's not clear to me is whether the pin will still be available for this other functions once I've checked the "Enable Error Detection CRC_ERROR pin" or if it'll be hardwired to the CRC function and no longer available to the application.

    --- Quote End ---

    One you enable the CRC option, that pin will be used for CRC feature. It cannot be used for any other purposes. It is available to you for error detection mechanisms & you can use it for error detection.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    --- Quote Start ---

    As far as I know the Altera remote update IP core is a softcore, not hardcore; i.e. It can exist in the FPGA using some logic cells or it may not exist at all if you do not want remote update feature.

    --- Quote End ---

    I guess I was mislead by the terminology then, Cyclone V's handbook volume 1 says the following: "Cyclone V devices contain dedicated remote system upgrade circuitry." in page 7-35, it sounds as it would be dedicated hardware rather than soft logic. I understand the remote_update IP is indeed soft logic, however, the underlying hardware would seem to be hardcore, right?

    What I'm trying to figure out is how reliable the WatchDog is, in case a SEU causes my device to stop working correctly I need to be certain a reconfiguration will be triggered.

    --- Quote Start ---

    One you enable the CRC option, that pin will be used for CRC feature. It cannot be used for any other purposes. It is available to you for error detection mechanisms & you can use it for error detection.

    --- Quote End ---

    In my case I only need the CRC check to trigger a reconfiguration (which is then reported by the status register in the remote_update IP), is this the only way to enable that?

    I'm on the same boat as with the watchdog here, I need to make certain that if, for whatever reason, the FPGA's configuration becomes corrupted a reconfiguration is triggered. Unfortunately, I don't have an external device who can monitor the CRC pin so I need to do it all internally, it would be nice if I didn't have to dedicate a pin for that (given that it'd become basically useless in such case) but if that's the only option then that's fine, I'll accommodate for it.

    Thank you for your help!

    Regards,

    Sebastian.