Dual Configuration IP on MAX10

Hello John,

yes I do. The sequence in the state machine is

• addr="000", writedata = "01"
• addr="000", writedata = "01", write='1' (triggering the reconfiguration)
• addr="011", read='1'
• addr="011", read='1' and wait till readdata(0) is '0'

Hi John,

it is not stuck there. It actually never gets busy at all, after writing.

Hi,

yes it is the same pof file and I can change to Image 1 with the config_sel pin at startup.

I also tested it with writing the config_sel=1 and config_sel_overwrite=0 to just triggering the rconfig.
On the good boards I read the input_reg with 0 because of the reconfiguration and on the three that do not reconfigure I still read config_sel=1...

Because of your last post I added just one additional state for the busy checking.

• addr="000", writedata = "01"
• addr="000", writedata = "01", write='1' (triggering the reconfiguration)
• addr="011", read='1'
• addr="011", read='1' <-- added
• addr="011", read='1' and wait till readdata(0) is '0'

Still it never gets busy (readdata(0) is always zero), but now it does the reconfiguration. I actually don't understand why.

Is it necessary to check the busy after writing to Offset 0? Can any operations after the triggering of the reconfiguration "abort" the reconfig?

Hi John,

I think the busy signal is not generated after writing to offset = 0. Also in the UG-M10CONFIG the busy flag is not mentioned for writing to offset 0, unlike the offset 1 and 2 where it is explicilty described that it is generated.
So I think it makes no difference if I check the status of the busy flag or wait for the same number of clock cycles it takes to check the busy flag.

In my program I'm writing to offset 0 to trigger reconfiguration, then check the busy flag and after that I write to offset 2 to trigger the read of one of the registers.

Because of the busy flag is always zero the number of clock cycles between writing to offset 0 and writing to offset 2 is always the same.
The time between the two write operations (means the time where the write bit is set to zero) initally was 3 clock cycles (75 ns). As described before this worked for most of the devices, but not all.
When I added an additional cycle, to have 4 clock cycles (100 ns). This now workes for the devices that did not reconfigure before. I also tested it with a device that was working with the inital solution and removed one cycle. With 2 clock cycles (50 ns) this now did not reconfigure anymore, too. So it seems to me that 2 clock cycles are definitly too less, 3 work in most cases and 4 hopefully always...

Im just wondering now, if adding 4 idle cyles after writing to registor with offset 0 is the solution to the problem. Is there some technical explanation for this? Can a write to another register (like offset 2) interfere with the reconfiguration? In this case how long do I have to wait after writing to offset 0 before I start another write operation?
Does the same apply for reseting the watchdog timer (also a write to offset 0)?

Is it correct that it makes no sense to read the busy flag after writing to offset 0?

Best Regards

Tom

Hi,

the clock frequency is 40 MHz. This is also set in the dual config IP (see attached screenshot).

There is also a design contraint set for the clock

create_generated_clock -name ru_clk -divide_by 2 -master_clock PLL|altpll_component|auto_generated|pll1|clk[1] -source [get_pins -compatibility_mode { *altera_dual_boot:dual_boot_0|alt_dual_boot_avmm:alt_dual_boot_avmm_comp|alt_dual_boot:alt_dual_boot|ru_clk|clk }] [get_pins -compatibility_mode { *altera_dual_boot:dual_boot_0|alt_dual_boot_avmm:alt_dual_boot_avmm_comp|alt_dual_boot:alt_dual_boot|ru_clk|q } ]

Hi,

you mean the clock that is connected to the clk input of the dual config IP? This is the 40 MHz clock at the output two of the internal PLL.

Hi John,

the dual configuration IP is controlled by a state machine. Both are running at the same 40 MHz clock. The PLL is generating two clocks, the second one is the 40 MHz and is used for the state machine and the dual configuration IP. It is the pll1|clk[1] in the sdc file.
This means the the state of the state machine is updated on the rising edge of the input clock.

Can you tell me if the line in the sdc file is correct?
create_generated_clock -name ru_clk -divide_by 2 -master_clock PLL|altpll_component|auto_generated|pll1|clk[1] -source [get_pins -compatibility_mode { *altera_dual_boot:dual_boot_0|alt_dual_boot_avmm:alt_dual_boot_avmm_comp|alt_dual_boot:alt_dual_boot|ru_clk|clk }] [get_pins -compatibility_mode { *altera_dual_boot:dual_boot_0|alt_dual_boot_avmm:alt_dual_boot_avmm_comp|alt_dual_boot:alt_dual_boot|ru_clk|q } ]

I am sorry but I can't post the source code here in the forum.

I will try to describe the state sequence here. Every item is one state, equals to one clock cycle (25 ns).
(Not named inputs in the states are set to zero)

The inital sequence of the states, that did not work for all devices...

• ...
• avmm_rcv_address="000", avmm_rcv_writedata(0)='1', avmm_rcv_write='0'
• avmm_rcv_address="000", avmm_rcv_writedata(0)='1', avmm_rcv_write='1'
• avmm_rcv_address="011", avmm_rcv_read='1'
• avmm_rcv_address="011", avmm_rcv_read='1' (avmm_rcv_readdata(0) is checked here, but because it is always zero, it makes no difference if it is checked or not)
• avmm_rcv_address="010", avmm_rcv_writedata(idx)='1', avmm_rcv_write='0' where idx is 0 to 3
• avmm_rcv_address="010", avmm_rcv_writedata(idx)='1', avmm_rcv_write='1' where idx is 0 to 3 and of course the same value as in the state before
• avmm_rcv_address="011", avmm_rcv_read='1'
• avmm_rcv_address="011", avmm_rcv_read='1', repeat this state till avmm_rcv_readdata(0)='0'
• ...

What leads to the same result, as checking the busy flag (does not work for all devices)

• ...
• avmm_rcv_address="000", avmm_rcv_writedata(0)='1', avmm_rcv_write='0'
• avmm_rcv_address="000", avmm_rcv_writedata(0)='1', avmm_rcv_write='1'
• IDLE state (all set to zero)
• IDLE state
• avmm_rcv_address="010", avmm_rcv_writedata(idx)='1', avmm_rcv_write='0' where idx is 0 to 3
• avmm_rcv_address="010", avmm_rcv_writedata(idx)='1', avmm_rcv_write='1' where idx is 0 to 3 and of course the same value as in the state before
• avmm_rcv_address="011", avmm_rcv_read='1'
• avmm_rcv_address="011", avmm_rcv_read='1', repeat this state till avmm_rcv_readdata(0)='0'
• ...

What seems to work

• ...
• avmm_rcv_address="000", avmm_rcv_writedata(0)='1', avmm_rcv_write='0'
• avmm_rcv_address="000", avmm_rcv_writedata(0)='1', avmm_rcv_write='1'
• IDLE state (all set to zero)
• IDLE state
• IDLE state
• avmm_rcv_address="010", avmm_rcv_writedata(idx)='1', avmm_rcv_write='0' where idx is 0 to 3
• avmm_rcv_address="010", avmm_rcv_writedata(idx)='1', avmm_rcv_write='1' where idx is 0 to 3 and of course the same value as in the state before
• avmm_rcv_address="011", avmm_rcv_read='1'
• avmm_rcv_address="011", avmm_rcv_read='1', repeat this state till avmm_rcv_readdata(0)='0'
• ...

What does not work for any of the devices

• ...
• avmm_rcv_address="000", avmm_rcv_writedata(0)='1', avmm_rcv_write='0'
• avmm_rcv_address="000", avmm_rcv_writedata(0)='1', avmm_rcv_write='1'
• IDLE state (all set to zero)
• avmm_rcv_address="010", avmm_rcv_writedata(idx)='1', avmm_rcv_write='0' where idx is 0 to 3
• avmm_rcv_address="010", avmm_rcv_writedata(idx)='1', avmm_rcv_write='1' where idx is 0 to 3 and of course the same value as in the state before
• avmm_rcv_address="011", avmm_rcv_read='1'
• avmm_rcv_address="011", avmm_rcv_read='1', repeat this state till avmm_rcv_readdata(0)='0'
• ...