Forum Discussion

Danlar81's avatar
Danlar81
Icon for New Contributor rankNew Contributor
1 year ago

Creating Bootloader within ROM using Cyclone V

Hi,

I'm looking to for some feedback/suggestions to the following.

I have been tasked with creating a boot loader to be able to perform remote loading via serial interface.

I initially did some research, and thought that the best way to perform this would be through 'Partial Reconfiguration', however I have since confirmed that the Cyclone V 5CEFA9F23I7N device I am working with does not support it.

For some more context, the place I work for creates the firmware model within Simulink which is then synthesized via HDL coder and turned into a bit-stream via Quartus before loading onto the FPGA.

Since discovering I am unable to use 'Partial Reconfiguration', I have thought about alternatives in concept, one of which is to potentially have the logic required to for the UART/RS-485 and SPI protocols in the firmware, along with the state machine to configure the external flash registers. The bit-stream would be received via RS-485, decoded then sent via SPI and written to flash. Assuming the bit-stream was complete, the FPGA would be reset and load the configuration from flash.

I will admit, this sounds error prone and is the least preferred.

The other alternative is to configure the FPGA internal ROM via .mif file, and have the ROM load the bit-stream into flash. This would mean the serial interface protocols would need to be stored within ROM, along with the code to configure the flash registers. I have read that the .mif can be written using HDL language such as VHDL, however I am wondering if it could be created via MATLAB script .m files?

I have kept this at a pretty high level as I am just thinking about this conceptually, however I am looking for some advice given the situation presented.

I'd be interested to know if anybody has had experience doing something like I have described before, and if so, what else should I consider?

I'm a little uncertain about having the serial interfaces and state machine in ROM, as it's typically used to store configuration data. I'm not sure if it's even possible, or what the outcomes may be by trying to do this?

Is there any resources that would be of further benefit which may aid the decision making, or introduce another alternative which have have not covered?

Keen to hear all feedback.

Regards,

Dan

Configuration
Fpga Devkit

5 Replies

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor
    1 year ago

    Hi,
    ROM content can't be loaded at runtime, .mif data has to be compiled into configuration bit stream. Consider also that internal RAM/ROM capacity usually isn't suffcient to hold the configuration data.

    You should look at Remote Update design examples.

    Regards
    Frank

    • Danlar81's avatar
      Danlar81
      Icon for New Contributor rankNew Contributor
      1 year ago

      Hi Frank,

      Thanks for the reply.

      I have looked into Remote Updates as suggested, and this looks to be the best method. However, I'm hoping you may be able to answer some further questions?

      It seems that a good approach would be to use the Remote Update IP Core which has the internal circuitry for communication with flash. However, the constraint is the UART interface.

      Assuming I created a UART Tx/Rx interface in VHDL, how do you go about interfacing that with the IP Core?

      Is that something that that is done in the Quartus via configuration settings?

      Would it be possible to create a design in Quartus which configured the Remote Update IP Core and flash which could be imported into Simulink using the HDL verifier toolbox?

      If that even worked I would not expect to see the contents of the remote Update IP core, I would only be after the block.

      From what I read, it didn't appear to be an issue not having control over the CONF_DONE, nCONFIG or nSTATUS pins when using the Remote Update IP Core. Is this correct, or have I got this wrong?

      I only ask, because the existing design currently uses these pins for programming via USB.

      The new RS-485 transceiver is connected to DIFFIO pins, therefore it would be ideal to interface via UART directly to the Remote Update IP Core.

      Regards,

      Dan

  • Farabi's avatar
    Farabi
    Icon for Regular Contributor rankRegular Contributor
    1 year ago

    "We sincerely apologize for the inconvenience caused by the delay in addressing your Forum queries. Due to an unexpected back-end issue in our system, your Forum cases, along with others, did not get through as intended. As a result, we have a backlog of cases that we are currently working through one by one.

    Please be assured that we are doing everything we can to resolve this issue as quickly as possible. However, this process will take some time, and we kindly ask for your patience and understanding during this period. The cases will be attended by AE shortly.

    We appreciate your patience and understanding, and we are committed to providing you with the best support possible.

    Thank you for your understanding."


  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor
    1 year ago

    Hi Dan,
    sorry for late response to your previous post, I was on vacation.

    A remote update design is comprised of these functions
    - Remote Update FPGA IP, controlling boot of different configuration images, e.g. factory/application
    - Flash programming IP, e.g. ASMI Parallel IP
    - Remote update state machine in user logic
    - Flash interface wrapper translating your transfer protocol and data format to flash IP interface
    - Interface logic, e.g. UART, I2C, SPI or user specfic

    Beside Remote Update and Flash IP, that can be imported from IP catalog, functions 3 - 5 have to be written by yourself or copied from design examples.

    I don't see much use of Simulink for Test of remote update. First step is to decide about used communication interface and protocols.
    We started 10 years ago with a RSU design that puts high level functions in the FPGA like decoding .hex files and CRC check of programmed flash image. Finally we stepped back to a lower level protocol transferring binary flash data and verifying it externally.

    If you have more specific questions, we can hopefully help you.

    Best regards
    Frank

  • Farabi's avatar
    Farabi
    Icon for Regular Contributor rankRegular Contributor
    1 year ago

    Hello Dan,


    I agree with Frank suggestion to use the Remote System Update(RSU) as Cyclone V devices dont support Partial Reconfig. RSU is the IP already established and known to work. You can update the image using the existing development flow.


    regards,

    Farabi