cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
1,538 Views
Registered: ‎02-01-2019

TMR SEM interface, initialization problem

Jump to solution

Hi everyone,


I’m working on a fault injection system on Zedboard.
I’m using the Soft Error Mitigation IP core to inject faults in the design and I need that Zynq communicate with SEM IP through an AXI interface.


In Vivado 2018.2 seems impossible to add SEM ip to block design and i’ve chosen to use TMR SEM interface, that how it's specified in the relative user guide, it's a wrapper of the SEM IP.
The problem is that the TMR SEM does not complete the initialization stage, I read from MON_RECEIVE register one character at once and the initialization report is frozen at icap check:


X7_SEM_V_4_1
SC 01
FS 0E
ICAP

I'm reading on the forum that the SEM goes in polling on icap and to solve it, it is necessary to set icap_grant to 0, change to 0 the 27-bit of DEV_CFG register, and then set icap_grant to 1.
But with TMR SEM I don’t have any access to the icap interface.


How can I solve my problem? Does anyone know how to work with TMR SEM?

Otherwise, if the TMR SEM Interface is the wrong way to use the SEM, how can I use SEM IP (with AXI interface) if Vivado does not allow me to add it to the block design?


For completeness, I attach my design:Design.png

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
1,355 Views
Registered: ‎08-10-2008

No if you did not run any injection yet, this is abnormal. IP did not start up correctly. It just finishes initialization, and it believes it detects more than one bit error (even if there is actually none) , then IP stops and enters into IDLE state. 

You can either stop using TMR SEM, or you can test with a 'pure' example design only. Modify as less as possible of the example design and see how it behaves.

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

View solution in original post

8 Replies
Highlighted
Visitor
Visitor
1,447 Views
Registered: ‎06-29-2018

Check SEM IP user guide

In order for the controller to function, configuration logic access must be transferred to the ICAP.
This is accomplished by clearing PCAP_PR (bit 27) in the PS device configuration control register (DEVCFG CTRL, address 0xF8007000).

0 Kudos
Highlighted
Visitor
Visitor
1,420 Views
Registered: ‎02-27-2019

Hi,

I have/had a similar problem in my design for the icap_grant signal.

 


How can I solve my problem? Does anyone know how to work with TMR SEM?

I succeed to make it work by:

An example of soft can be found here (https://forums.xilinx.com/t5/Embedded-Processor-System-Design/PCAP-configuration-for-Zynq-SEM-IP-core/td-p/642713)

(The reset signal might reset all golden frame ECC value and device-level CRC like the soft reset does - XAPP1261 - Introduction)

 

Otherwise, if the TMR SEM Interface is the wrong way to use the SEM, how can I use SEM IP (with AXI interface) if Vivado does not allow me to add it to the block design?

In PG268 - page 20 | TMR SEM - (https://www.xilinx.com/support/documentation/ip_documentation/tmr/v1_0/pg268-tmr.pdf):image.png

 

You can see that the TMR SEM IP contain just the SEM core with the AXI4-Lite /UART interface.

To use the SEM IP you just have to create a VHDL wrapper with the block design and SEM IP.

For the AXI interface you can use the AXI UARTlite IP in your bd.

 

But there is some question that I didn't manage to find any answer:

  • For TMR SEM IP, this reset technique look a little rough, can we bypass it?
  • When the frame ECC/device level are calculated? after icap_grant?
  • The reset signal command reset the IP state machine or the frame ECC/device level or both?
  • Can we hope for a TMR SEM IP with icap_grant signal in the future if needed?

 

Regards,

Rubens

Highlighted
1,400 Views
Registered: ‎02-01-2019

Thank you both for your replies.
I have managed the initialization (clearing the 27 bit of DEVCFG) but the output read from the MON_RECEIVE is:

X7_SEM_V_4_1
SC 01
FS 0E
ICAP OK
RDBK OK
INIT OK
SC 02
O>
SC 04
DED
PA 01800000
LA 00001EF6
COR
END
FC 20
SC 08
FC 60
SC 00

After the initialization, an error is detected and (the) SEM goes in error correction and then in the classification. Why has SEM this behaviour?

Furthermore, once that this procedure is completed, to send any commands to the SEM seems impossibile. To take a test on the transmission of commands I force SEM to go to the observation state writing 'O' in the MON_TRASMIT register, but any write on this register seems blocked. How can i solve it?

Regards.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
1,392 Views
Registered: ‎08-10-2008

1. Whether or not you enable Classification feature, when IP sees an error, it always passes the same path: correction - classification. What you see is expected.

2. For this log, is that all? Nothing after 'SC 00'? Well if this is the case, IP stuck here. IP must always resides in Observation or Idle, in other word, you should have 'I>' or 'O>' at last. In this case, you should have I>.

Consider some possible reasons: 

1. You inject more than one errors and you inject on IP itself, this can lead to IP abnormal.

2. The FIFO of the MON interface is throttling. IP can resume work only when all characters are shifted out. Check if something lead to failure of FIFO writing.

3. Did you have any other logic in the design that may get access to ICAP, PCAP, etc, at this stage?

 

------------------------------------------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------------------
Highlighted
1,375 Views
Registered: ‎02-01-2019

1. Even if I don't inject any error, is this behaviour that is expected?
2. Yes, you're right, the log ends with 'I>'.

Considering the solutions suggested:

1. I have not tried to inject any error yet.
2. I wait until all characters from MON_RECEIVE are read and try to write 'O' followed by 0x0D. But nothing happens. If I try to read It from MON_RECEIVE the program results blocked.
3. In the design there are only the TMR SEM and the Zynq.

0 Kudos
Highlighted
1,370 Views
Registered: ‎09-17-2018

Aside:

TMR of SEM IP makes everything worse, not better.  Unless you spent a lot of time getting it done perfectly, followed by beam testing, you will not get it to even work (as there is only one ICAP).  So, I advise you to STOP.

Even if you perfectly triplicated, voted the PicoBlaze used, your result is only making the cross-section larger, and the failure more likely.  SEM IP is already the best it can possibly be (I know, as I invented it).

l.e.o.

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
1,356 Views
Registered: ‎08-10-2008

No if you did not run any injection yet, this is abnormal. IP did not start up correctly. It just finishes initialization, and it believes it detects more than one bit error (even if there is actually none) , then IP stops and enters into IDLE state. 

You can either stop using TMR SEM, or you can test with a 'pure' example design only. Modify as less as possible of the example design and see how it behaves.

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

View solution in original post

Highlighted
1,329 Views
Registered: ‎02-01-2019

I've chosen to stop working with TMR SEM and I develop a wrapper for SEM IP.

I've created a custom AXI IP in which the SEM is instantiated. This module is connected through AXI to the Zynq and the bitstream is generated correctly.
For test purpose, one led is connected to the signal  status_heartbeat.
When I launch the program nothing happens, and SEM does not work.
If I try to read the status interface all signals result as zeros and also the led is off.
Furthermore, I've executed the self test generated automatically but It doesn't return XST_SUCCESS.

Any suggestion of how to create correctly the wrapper for the SEM IP?

Obviously, in the initialization stage I clear the 27 bit of DEVCFG register as in the previous case. 

0 Kudos