Forum Discussion

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

Remote System Update JTAG AS EPCS64 Cyclone IV

I am new to other-than JTAG configuration options for FPGA development. First, here is my setup.

I have two images, factory and application, built with custom VHDL (state machines and concurrent processes ... not NIOS) including the ALT_REMOTE_UPDATE megafunction. This is on a Cyclone IV FPGA with EPCS64 configuration device. I want to boot the factory image and then have it load the application image.

As for configuring an FPGA, what I've always done before is convert .sof to .jic and download ... easy. But, now I have two files. So, my first thought was the load the factory.sof in one page, the application.sof in another page, convert to .jic, download, recycle power to the device, and see if the application ever loads. But, that did not work. I programmed/verified with no errors and it boots just the factory image - never the application image. I played with some of the parameters for the ALT_REMOTE_UPDATE and feel comfortable with their current settings (based on debugging/simulating).

Question 1. Should that work?

After much reading, I see there is a .pof (actually a couple of different types of .pof files show up in my convert programming file) extension for AS mode. Moreover, I can't convert a .pof to .jic. But, I have come across an SFL option for JTAG to AS interface.

Question 2. Am I headed down the right path? Should I be using the SLF function in order to use the .pof files? There seems to be a lot of documentation out there, and I want to make sure I'm on the right path.

So, again, all I want to do in the end is boot the factory image and have it load the application image. In the future, I want to be able to DLF another application image when needed.

Any advice/insight is much appreciated.

Regards,

David

2 Replies

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

    It appears that the SFL is built-in. That is, I don't need to configure anything for it. I have already been writing to the EPCS device via JTAG, and this is how it works. So, I don't think I need to go down that trail.

    I think my first attempt (creating a factory.sof and application.sof and placing them in flash) is the way to go (unless someone says otherwise and can support their claim).

    I can see that the FPGA resets upon asserting my RSU_Control module. But, for some reason it fails booting the application image. I've tried different configurations (i.e. enabling the watchdog timer, disabling the watchdog timer, using the boot address, using the page number). For now, I just want to see my application image boot. As for the boot address, I see some conflicting remarks. That is, I see in two different places where it calls for the boot address to be written and another section references the page number location (that is 1 - 6). So, I tried both (the actual address and the page number) but neither worked.

    I attached my "control" module and simulation (it maybe too small to view, but it matches the actual operation (I have some debug pins I can port the signals out and view with a scope)).

    RSU_Control.vhd is placed in my top.vhd and is enabled via a pushbutton (i.e. start the reconfiguration when I push a button). I have this same RSU_Control in my application image but hardwired the enable to be off. RSU_control.vhd calls the Remote System Upgrade megafunction. Also, the reset_timer signal to the megafunction is set high in the application image. First, it toggles a reset line, sets the timeout value, enables the watchdog timer, sets the boot address, and then asserts the reconfig line.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Ok, I made a few changes to RSU_Control.vhd (attached).

    At the falling edge of my clock, I set write_param for one clock cycle. So, at the rising edge of the ALTREMOTE_UPDATE clock, it sees this signal once. I added some read states in RSU_Control.vhd to ensure the values are getting set, which I can't verify they are.

    It looks like the read_source input is determined by the parameter you want to read. Ok ... but I can't find anything to really help me with this. The ALTREMOTE_UPDATE megafunction reference list some generic settings for read_source, and I'm guessing "11" is what I want. When I set it this way to read what I've written, I can only verify the watchdog timeout value. That is, when I read this pararmeter, it returns whatever I've written. This isn't the case for the watchdog enable or boot address. Whether I enable or disable the watchdog timer, the read response always comes back as "1". The boot address read always returns 0. Now, if I change the read_source setting to "10", I see a response of 3. Moreover, read_source settings of "01" and "00" return 0. So, I'm trying to focus in this area since I can't boot to address 0x100000.

    Any input is appreciated.

    David