cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
598 Views
Registered: ‎11-06-2018

The output of ICAPE3 when there is no data read

Jump to solution

Hi All,

I'm using VCU118. I'm trying to understand the output value of ICAPE3. The UG570 says: if there is no data is being read, the O[31:0] contains current status. However, during my on-chip testing, I found this is not true.

When ICAPE3 is at ease, the output value is something like 0xFFFFFFD9, which, according the following figure, means where is CRC_ERROR and so on. When I actually read the STAT register, the output value is 0x109079fc, which makes more sense.

Screenshot from 2019-11-14 12-25-36.png

 

Below is the ILA monitoed value of ICAPE3. As you can see, the default output is 0xFFFFFFD9. It became 0xFFFFFFDB after I writing the first set of commands (WHY?). At timestamp 525, we got the STAT register value 0x109079FC.

Screenshot from 2019-11-14 12-27-29.png

 

There is not so much documentation on this topic. I hope someone could help me out. Thank you in advance.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
562 Views
Registered: ‎08-25-2010

Hi @lastweek918 

I think the 8 bit should be defined in table 5-3, ug570:

 

 

Thanks
Simon
-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

abort.PNG
10 Replies
Highlighted
Xilinx Employee
Xilinx Employee
563 Views
Registered: ‎08-25-2010

Hi @lastweek918 

I think the 8 bit should be defined in table 5-3, ug570:

 

 

Thanks
Simon
-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

abort.PNG
Highlighted
Adventurer
Adventurer
552 Views
Registered: ‎11-06-2018

Hi @simon,


Thank you for your reply. UG570 Chapter 5 is about SelectMAP configuration, I didn't realize that the states of ICAPE3 are related to SelectMAP, which, was confusing for me.

 

1. Do you mean that when ICAP is at ease, the output values maps to Table 5-3? For my above case, the Output transit from FFFFFFD9 to FFFFFFDB, looks like the D06 (DALIGN) bit change from 0 to 1. It looks legit, since I have gave the Sync word to ICAP...

2. In general, how much stuff of SelectICAP is still applied to ICAP?

3. Are you aware of any ICAP related example designs? I fail to find much. 

 

Thank you for your help!

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
543 Views
Registered: ‎08-25-2010

Hi @lastweek918 

 


@lastweek918  已写:

Hi @simon,


Thank you for your reply. UG570 Chapter 5 is about SelectMAP configuration, I didn't realize that the states of ICAPE3 are related to SelectMAP, which, was confusing for me.

 

1. Do you mean that when ICAP is at ease, the output values maps to Table 5-3? For my above case, the Output transit from FFFFFFD9 to FFFFFFDB, looks like the D06 (DALIGN) bit change from 0 to 1. It looks legit, since I have gave the Sync word to ICAP...

Yes, they are

2. In general, how much stuff of SelectICAP is still applied to ICAP?

-  The ICAPE3 interface is similar to that for the external slave SelectMAP parallel 32-bit interface, including bit swapping 

3. Are you aware of any ICAP related example designs? I fail to find much. 

- 7 series have this example, for instance: https://www.xilinx.com/member/forms/download/design-license.html?cid=370270&filename=xtp201-kc705-multiboot-c-2014-3.pdf

 

Thank you for your help!


 

Thanks
Simon
-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Highlighted
Adventurer
Adventurer
537 Views
Registered: ‎11-06-2018
Simon, thank you for your information, it really helps. You first answer is accepted as the solution.
0 Kudos
Highlighted
Adventurer
Adventurer
502 Views
Registered: ‎11-06-2018

Hi @simon,

I have a follow-up question about the DALIGN bit.

  1. It seems that after we supply the SYNC (0xaa995566) word into ICAP, the DALIGN bit inside ICAP will become 1. Thus the O of ICAP changes from 0xFFFFFFD9 to 0xFFFFFFDB. This makes sense.
  2. It seems that the DESYNC command is used to reset the DALIGN bit. Thus in UG570 Table 10-1, we need to send another commands to the CMD+DESYNC register. If we skip this step, the output will stay at 0xFFFFFFD9
  3. It seems it is OKAY to continue reading the ICAP registers even with DALIGN bit set.

My question is: are there any implications if we leave the DALIGN bit set? I intend to do many operations with the ICAP.

 

Thank you.

 

0 Kudos
Highlighted
Participant
Participant
141 Views
Registered: ‎03-28-2020

Hi,

we are trying to build a part of the reconfigurable project based on the VCU128 platform (vu37p). When using ICAP, we also encountered the problem that the IDCode read back value is "FFFFFFD9". Even if HWICAP IP and the test cases built into the SDK are used, this error will still occur  ( XHwIcap_CfgInitialize() function in hwicap.c ).

Did you find the cause of the problem later? We have been confused about why IDCode returns this number. Hope to communicate with you further, thank you!

 

 

 

Best Regards

0 Kudos
Highlighted
Adventurer
Adventurer
125 Views
Registered: ‎11-06-2018

Hi @wuyouniyanhu 

 

As the doc pointed above, the output 0xFFFFFFD9 is a legit output value when ICAP is not used. At first I was using an HLS-based module to control ICAP and was not able to perform PR or readback. Eventually I turned to MicroBlaze-based solution like the one you are using one, it worked for me back then.

 

Were you able to read back any information? e.g., ICAP registers.

0 Kudos
Highlighted
Participant
Participant
102 Views
Registered: ‎03-28-2020

 

Thank you very much for your reply!

 

Now we are based on the Microblaze+HWICAP solution and found that reading IDCode always has a problem during initialization. Our software directly uses the interrupt demo code in selftest, and the operation sequence for ICAP is:

wuyouniyanhu_4-1600235442267.png

 

wuyouniyanhu_3-1600235406611.png

 

wuyouniyanhu_2-1600235365003.png

 

But when using ILA to observe the hardware signal, we found that on HWICAP's AXI4Lite interface, the order of instructions is as suggested by the UG570 document, but the order received by ICAP_i is messy, maybe this is what we can’t read The reason for the IDCode data, at the same time, our reading of the STAT register also failed due to confusion. When you use it on the VCU118 platform, do the operation instructions that finally arrive at ICAP follow the sequence of the above table? Is the returned IDCode value correct? Because we don’t know if the disorder of the operations in ICAP_i is the cause of the error. If we can see the correct sequence of ICAP operations, it will make our current work much clearer.

 


if you have kept the correct record of the ICAP input and output interfaces at that time (preferably ILA waveform), may you please send us for reference?

 

 

Many thanks!

0 Kudos
Highlighted
Adventurer
Adventurer
95 Views
Registered: ‎11-06-2018

Hi @wuyouniyanhu , I didn't check the ICAP waveform during testing back then, the shipped MicroBlaze C code just works on VCU108. The sequence of Table 10-1 should have been taken care of by the C code provided by Xilinx.

If you are seeing wrong signals at ICAP side, my best guess is that there might be some issues with the C library code, possibly version issue, or incompatible with VCU128?

Anyway, my old C code for VCU108 is here: https://github.com/lastweek/fpga_os/blob/master/kernel/mb/sched/core.c. The previously mentioned HLS-based code is here: https://github.com/lastweek/fpga_icap_hls 

0 Kudos
Highlighted
Participant
Participant
75 Views
Registered: ‎03-28-2020

Thank you for your help, it is very useful. About ICAP, maybe I need to learn something more deeply, and I will share with you again when I find the root cause of the problem.


Your open source project on github is great!

0 Kudos