FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5741 Discussions

Reading issue with the ALTREMOTE_UPDATE IP

Altera_Forum
Honored Contributor I
887 Views

Hello all! 

 

I am using the remote system upgrade feature in my cyclone III. To do so, I instantiated the altremote_update controller in sopc builder. 

 

Everything works fine ... almost. I would like to measure the time the FPGA takes to be updated. So, in my factory configuration, before initiating the reconfig, I set the Watchdog timeout value to 0x00100000 let say, and enable it. At the beginning of my application configuration, I check the current state mode register, correctly set to 0b11 "Application mode with Watchdog". 

Then, I initiate a read access to the Watchdog timeout value using this instruction: 

IORD ( REMOTE_UPDATE_CYCLONEIII_0_BASE , 0x0A ) ; 

and I always get the init timeout value plus 0x8, i.e. 0x00100008 in this case. Changing the read_source input I get all 0s. 

 

Therefore my questions are: 

Does the remote upgrade circuitry allow us to read the timeout value dynamically? 

Why am I getting the init timeout value plus 8 when I try to read the timeout value? 

 

Thanks in advance for your answers :) 

 

Florian
0 Kudos
7 Replies
Altera_Forum
Honored Contributor I
38 Views

I don't know why you get the timeout value plus 8. However, the value in that register is not the current value of the watchdog timer. It's simply the timeout value. The value in that register is loaded into the counter each time the application performs a write to the watchdog timer. And it's not intended necessarily to be read by the application image. 

 

Jake
Altera_Forum
Honored Contributor I
38 Views

Thank you jakobjones, everything works fine then, except the "plus 8", but it does not really matter. 

 

Florian
Altera_Forum
Honored Contributor I
38 Views

Hi, 

 

I have a related but different issue. I am interfacing directly to the ALTREMOTE_UPDATE megafunction. 

 

All works fine - I can reconfigure the device. But, if I read back the boot address and watchdog timer count, I don't get back 24bits or 29bits, just the same I wrote. 

 

The device is Cyclone III. 

 

That is 

 

writing at param => 0x4, data_in => 0x10_0000; 

reading back for param => 0x4, read_source => 0x3; the data_out is 0x10_0000, I expected it to be 0x40_0000. 

 

So I also tried the watch dog timer (though I am not really using it). 

 

Writing at param => 0x2, data_in => 0xfff; 

Reading back for param => 0x2, read_source => 0x3; the data_out is 0xfff, I expected it to be 0x1ffe0000. 

 

Used 8.0 linux version for the megafunction. 

 

Anything I am missing? 

 

Thanks, 

Rejeesh
Altera_Forum
Honored Contributor I
38 Views

The megafunction writes the 22 MSBs and reads all 24bits, read the manual carefuly it is explained there.

Altera_Forum
Honored Contributor I
38 Views

Some may find it difficult to understand the question, so here is another version. 

 

I want to program the boot address (byte address) to be 'h400000. 

 

And now I am looking at the megafunction on how to set this. 

 

I set data_in[21:0] = 'h100000; -- correct? 

 

What will I read back on data_out ???? 

 

data_out == 'h400000; ??? 

data_out == 'h100000; ??? 

 

I am reading back 'h100000. I thought I should be reading back 'h400000, as the device appends 2'b00 to the boot address.
Altera_Forum
Honored Contributor I
38 Views

> set data_in[21:0] = 'h100000; -- correct? 

yes 

 

> What will I read back on data_out ???? 

data_out == 'h400000; 

 

If you are reading something else then there is some issue in your logic.
Altera_Forum
Honored Contributor I
38 Views

Hi, 

 

I'm getting the same problem: I read back the same value I've written: 

* written 0x20000 

* read 0x20000 

I was expecting 0x80000 back. 

 

 

rejeesh, did you find the reason why you had the same behaviour?
Reply