Making a stuck-at fault by altering the cell pins and its INIT

[Gabriel Cobos Tello]

Greetings!

Im trying to emulate a stuck-at-fault in a FDRE flip-flop by doing two things:

1. Set the INIT property of the cell to a certain value (1 or 0)
2. Disconnect the clock enable pin and reset to prevent the reg cell from changing value

In theory based on Xilinx Documentation: "a flip-flop is asynchronously initialized when power is applied. When global set/reset (GSR) is active either upon power-up or when asserted via the STARTUP block, the value of the INIT attribute is placed on the register’s output."

So by setting the init to a certain value, and disabling the CE and R pins, the cell should be stuck at its init value. To this extend I have done the following:

1. cell.getProperty("INIT").setValue("1");
2. //Disconnect logically
3. EDIFNet targetNet = cell.getEDIFCellInst().getPortInst("R").getNet();
4. targetNet.removePortInst(pinnameR);
5. EDIFNet targetNet2 = cell.getEDIFCellInst().getPortInst("CE").getNet();
6. targetNet2.removePortInst(pinnameCE);
7. //Disconnect physically
8. cell.removePinMapping("SR");
9. cell.removePinMapping("CE");

Where the pin name is the cell name + "\R" or "\CE". Checking the generated DCP in vivado I can confirm that the changes do in fact happen in the device view, and the pins are disconnected.

Now my question is the following... What values will the cell have at its pins if these are disconnected? 

I would like R and CE to be constant 0, so another option would be to connect these pins to the site's GND. But this has proven tricky, as doing :

1. cell.connectStaticSourceToPin(NetType.GND, "SR");
2. cell.connectStaticSourceToPin(NetType.GND, "CE");

Seems to connect the GND to the existing net, basically connecting GND to all FDRE cells R and CE pins in the site. This ofc creates an undesired effect. How can we connect the pins of the desired cell and only these to GND?

 

Ill attach the original DCP and its modification.

Thx for any assistance,

Gabriel

[RapidWright]

Again, apologies for the delay in responding, Google Groups email notifications appears to be broken...

I'm not sure if the value of the flop output is specified without CE and SR connected.  I'm sure there is a value in the hardware, but it would require an experiment to find out.  

You would probably need to attach SR and CE to GND.  The configuration of a Series 7 SLICE has those inputs shared among all FFs in a SLICE.  So, to decouple them, you'll need to move the FF to a SLICE where none of the other FFs are being used (or also want CE and SR to be GND).  This is changing the implementation, so probably not what you want. Not sure if you want to simulate stuck-at faults for all FFs, but you could just choose a FF that is in a slice by itself.  For example:

select_objects [get_cells base_mb_i/microblaze_0/U0/MicroBlaze_Core_I/Performance.Core/Use_Debug_Logic.Master_Core.Debug_Perf/Serial_Dbg_Intf.shift_datain_reg[28]]

might be a good candidate.

[Gabriel Cobos Tello]

Not a problem, it's great that you reply in any case :) 

Ah well in that case it's what I feared... I will have to scale up the granularity of the fault injections to sites rather than cells, since i want to simulate stuck-at for all FFs and i can't change the implementation.

Do you by any chance know if the shared GND is also the case in ultrascale and + devices? I tried to find documentation on it, but it's rather hard to find such details in Xilinx documentation.

Thx for the help, it's greatly appreciated!

[RapidWright]

In UltraScale and UltraScale+ (they share the same SLICE structure), there are shared control sets (CE / RST inputs), however at different granularity.  You can find it in the UltraScale CLB User Guide: 

https://www.xilinx.com/support/documentation/user_guides/ug574-ultrascale-clb.pdf  (see pg. 18-19).  

You can also look in the Device view of any UltraScale part, for example, here I have highlighted SR yellow, and the dual CE red and green: