cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Participant
Participant
817 Views
Registered: ‎12-27-2012

Dynamic partial reconfiguration time

Jump to solution

Hi all,

while doing a partial reconfiguration on Xilinx Zynq7000 mastered by ARM, so using DevC and PCAP, taking a bitstream stored in DDR3 external DRAM, I obtain the following reconfiguration time:

110 KB of bitstream partial reconfigured in 278 ns.

The measure has been done using the global timer of Zynq7000. The corresponding bandwidth is 395 GB/s.

It seems a strange value. The reconfiguration time should be related to the bandwidth of the whole path to reconfigure the FPGA. Coming to Zynq7000 TRM, v1.12.2, pp. 221, there is an indication of 145 MB/s in a typical condition.

How is it possible to have such a different value?

 

Thanks,

G

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Participant
Participant
599 Views
Registered: ‎12-27-2012

Hi,

I found the problem. I was basing my measure on interrupt status register of DevC controller that is cleared on write by writing one to its fields. I was incorrectly writing 0 to them, so it did not clear the status register as expected, causing the wrong measure.

Best,

Giacomo

View solution in original post

0 Kudos
5 Replies
Highlighted
Xilinx Employee
Xilinx Employee
724 Views
Registered: ‎10-11-2011

Something is wrong in that calculation. I never saw PCAP bandwith higher than 175MB/s.

395 GB/s is impossible.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Participant
Participant
701 Views
Registered: ‎12-27-2012

Yes, it is impossible.

I used global timer of Zynq7000 to measure the time of DPR, in the following way:

// function to initiate DMA of DevC
void XDcfg_InitiateDma(XDcfg *InstancePtr, u32 SourcePtr, u32 DestPtr, u32 SrcWordLength, u32 DestWordLength) { XDcfg_WriteReg(InstancePtr->Config.BaseAddr, XDCFG_DMA_SRC_ADDR_OFFSET, SourcePtr); XDcfg_WriteReg(InstancePtr->Config.BaseAddr, XDCFG_DMA_DEST_ADDR_OFFSET, DestPtr); XDcfg_WriteReg(InstancePtr->Config.BaseAddr, XDCFG_DMA_SRC_LEN_OFFSET, SrcWordLength); //before writing the fourth DMA register, I take start time, since the transfer should start after writing this register XTime_GetTime((XTime *) &tStart); XDcfg_WriteReg(InstancePtr->Config.BaseAddr, XDCFG_DMA_DEST_LEN_OFFSET, DestWordLength); }

the end time is taken when DONE signal is set high:

		// Poll DONE signal from PL
		while ((IntrStsReg & XDCFG_IXR_PCFG_DONE_MASK) !=
				XDCFG_IXR_PCFG_DONE_MASK) {
			IntrStsReg = XDcfg_IntrGetStatus(DcfgInstPtr);
		}

	 	XTime_GetTime((XTime *) &tEnd);

I got results around 270 ns for bitstream size of 110 KB moved from DDR. Doing the simple ratio 110 KB / 270 ns I got that bandwidth.

Do you see any mistake in the above line of reasoning?

 

Thanks.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
688 Views
Registered: ‎10-11-2011

Double check the XTime_GetTime() function. Maybe some divider or #define is incorrect and it deosn't return the proper number.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Participant
Participant
643 Views
Registered: ‎12-27-2012

I double checked each part of the code, together with defines, as suggested.

The problem does not happen the first time: during the first run, what I obtain is a partial bitstream transfer time equal to 6588383 ns for moving a reconfiguration module of size 857740 bytes into a reconfiguration partition, that provides a bandwidth around 139 MB/s (that makes more sense than GB/s).

Leaving the system working, when I reconfigure the same reconfiguration partition with another bitstream of the same size of previous (same size, different functionality), I obtain a reconfiguration time around 389 ns. It is too small.

The same happens when I reconfigure the same reconfiguration partition with the same bitstream (same size, same funcitonality, same process to obtain it): I obtain a reconfiguration time around 389 ns. It is too small too.

My doubt is that Zynq is modifying only the bitstream parts that effectively change inside the reconfiguration partition, and not all the bitstream related to reconfiguration module. Is this a possible explanation?

Thank you,

Giacomo

0 Kudos
Highlighted
Participant
Participant
600 Views
Registered: ‎12-27-2012

Hi,

I found the problem. I was basing my measure on interrupt status register of DevC controller that is cleared on write by writing one to its fields. I was incorrectly writing 0 to them, so it did not clear the status register as expected, causing the wrong measure.

Best,

Giacomo

View solution in original post

0 Kudos