Using RapidWright to emulate stuck at faults in logic resources

[gabrielcobostello]

Greetings!
I have already raised this question multiple times already, but its proving to be trickier than expected due to the FPGA architecture and my lack of experience regarding RapidWright.

Basically the problem I am facing is the inability to generate a bitstream where the stuck at fault takes place, despite injecting the fault via bistream manipulation in RapidWright.

I'm doing the following:

1. Loading a cell from my design (a test design with just one FDRE connected to a led and pushbuttons)
2. Cloning all the minor frames from the block in which the cell resides, into an arrayList
3. Disconnecting a physical pin of the cell (cell.removePinMapping("SR");)
4. Updating the configuration array (configArray.updateUserStateBits(cell);)
5. Once again cloning all minor frames, but this time after the change and into a different arrayList
6. Comparing the arrayList (before and after), word by word, and storing the FARs, the word indexes, and a bit masks of any changed words (This is for a FaultList).

The problem resides in the fact that disconnecting a pin doesn't seem to change anything in the configuration memory, or at least not in the part corresponding to the cell's block.

In the cases in which I change a property of the cell, like the "init", I do see a change, and the fault generated matches the change in the bitstream generated by vivado when done manually. So it seems like my approach works.

My question:

• Does cell.removePinMapping("SR"); not have an effect in the bitstream cause I'm not using the API correctly ? or is it because rapidwright wont allow "ilegal" changes in which a net is left unconnected, and reverts them before updating the bitstream? or is it something else?

I'm really reaching the end of my wits here, so any help would be greatly appreciated, I just want to generate a bitstream where SR is not connected, but the net still exists, as it is shared by the rest FDRE cells.

Thx in advance :)
Gabriel.

[clavin-xlnx]

Hi Gabriel,

It is hard to say exactly what changes to the design implementation will trigger a change in the bitstream. Vivado provides a user abstraction and not each detail/attribute may contribute to directly to a bitstream change, it might need to be multiple changes in unison. The fabric has a "default" mode when part of the fabric is not programmed and so, if the model happens to match that, you won't see a difference.

In your example you want to disconnect the SR input to a flip-flop. However, even if the user does not specify a signal driving it, it must be driven by either GND or VCC. I think it would be more correct to say that you want to connect SR to GND (which I believe would be the default mode), Vivado will generate a bitstream that will drive it with either one if not specified, it can't leave it floating. I think if you wanted to exercise both methods (GND vs VCC), you would have to explicitly route the path to the SR pin with GND or VCC.

To do this in Series 7 devices, the SR pin has a local GND pin supply in the SLICE:

Again, because of the architecture, you can only change the signal on the SR pin for all flip-flops in a SLICE at once, there is not a way to do this individually per flop. RapidWright has an API to perform intra-site routing changes so that you can change the routing of a site wire:

Design d = Design.readCheckpoint("your_dcp_name.dcp");
SiteInst si = d.getSiteInstFromSiteName("SLICE_X#Y#");
BELPin gnd = si.getBEL("SRUSEDGND").getPin("0");
BELPin sinkSR = si.getBEL("AFF").getPin("SR");
si.unrouteIntraSiteNet(gnd, sinkSR);
si.routeIntraSiteNet(d.getGndNet(), gnd, sinkSR);

Not sure if this will answer your question or lead to the behavior you are expecting, but site routing is something that you'll need to make consistent.

Hope that helps.

Chris

[gabrielcobostello]

Hi Chris,
Thx for the detailed reply, it was very helpful!

So in order to describe the behavior I want to emulate I will give some background as to what im doing.

I'm trying to emulate real faults in space applications caused by charged particles, by means of FPGA based fault injection. To this extend I'm trying to design a tool that will allow me to manipulate the bitstream (in a way similar to a bit-flip), without having to know the bitstream's structure (Xilinx doesnt publish this). This is where RapidWrigth could prove really interesting for me, as it can modify bitstream generated by vivado.

In order to emulate real faults I have to replicate certain types of fault models, one of which is the stuck at fault. I believe that in the case of FPGA Flip-flops this kind of fault can happen due to:

• changes in the internal state of the cell (not controlled by config mem),
• or by changes to the routing of the cell (represented in the bitstream). This last one implies that either the cell is not allowed to change value due to the D, CK, or SR & CE inputs being disconnected (driven to GND by routing).

The second case is not very likely to happen (and is only interesting if the design is going to be on an FPGA upon final deployment), but the first one can happen (also in ASIC), and the only way we can emulate it is via the config mem, so hence my interest in disconnecting pins to get individual FDRE cells stuck at a certain value.

Now based on what you say, I have some more questions:

• I get the idea that vivado will generate a bitstream that will have the nets driven to either GND of VCC if not specified, but does this mean that even if the responsible bits are flipped, the only options are VCC and GND? Meaning that there is no possible floating state, even if the bitstream is changed after generation?

• If there is a possibiliti for a floating state, since the nets for SR, CK, and CE are shared by all cells, are there no bits in the bitstream that would be responsible for connecting the nets to the individual cell pins?

• If there is no possibiliti for individual pin disconnects, and since the cells share the clock net too, does this mean that the biestables in the un-instantiated FDRE cells are always changing value based on the clock too?

I imagen, by looking at the architecture like you say, that there is no possible individual pin floating state. So my only solution is either to drive all cells to CK pins to GND or somehow drive the D port to either GND or VCC.

I see one possible way to achieve this would be by using the following route:

So I tried to generate it by using the methodology you showed:

BELPin gnd = si.getBEL("CYINITGND").getPin("0");
BELPin Carry = si.getBEL("CARRY4").getPin("CYINIT");
BELPin xor = si.getBEL("CARRY4_AXOR").getPin("1");
BELPin mux = si.getBEL("AFFMUX").getPin("XOR");
BELPin mux2 = si.getBEL("AFFMUX").getPin("AX");
BELPin sinkD = cell.getBEL().getPin("D");
		
si.unrouteIntraSiteNet(mux2, sinkD);
si.routeIntraSiteNet(design.getGndNet(), gnd, Carry);
si.routeIntraSiteNet(design.getGndNet(), Carry, xor);
si.routeIntraSiteNet(design.getGndNet(), xor, mux);
si.routeIntraSiteNet(design.getGndNet(), mux, sinkD);

But this doesn't seem to generate all the nets. Is there anything Im missing ? should I instantiate the BELs too?

Also when I use your code to connect SR to ground:

BELPin gnd2 = si.getBEL("SRUSEDGND").getPin("0");
BELPin In = si.getBEL("SRUSEDMUX").getPin("IN");
BELPin sinkSR = si.getBEL("AFF").getPin("SR");
		
si.unrouteIntraSiteNet(In, sinkSR);
si.routeIntraSiteNet(design.getGndNet(), gnd2, sinkSR);

My bitstream does not change after having updated it. Which I'm quite sure is due to my use of 'configArray.updateUserStateBits(cell)' , as I don't know what cells to give it when I am changing so many things at once.
I update the bitstream by doing:

bitstream.updatePacketsFromConfigArray();
		
design.writeCheckpoint("/home/gabcotel/WorkSpace/Stuck_at_test/Stuck_at_test_R_GND_noCRC_RW.dcp");
bitstream.writeBitstream("/home/gabcotel/WorkSpace/Stuck_at_test/Bitstream_R_GND_noCRC_RW.bit");

Again, thx for any help, its very much appreciated!

Best Regards,
Gabriel.

[clavin-xlnx]

Hi Gabriel,

I can see you want to modify the physical netlist to create artificial scenarios stuck-at faults. This is can be tricky as Xilinx does not document the behavior of bits in the bitstream beyond initialization values.

BELPin gnd = si.getBEL("CYINITGND").getPin("0");
BELPin Carry = si.getBEL("CARRY4").getPin("CYINIT");
BELPin xor = si.getBEL("CARRY4_AXOR").getPin("1");
BELPin mux = si.getBEL("AFFMUX").getPin("XOR");
BELPin mux2 = si.getBEL("AFFMUX").getPin("AX");
BELPin sinkD = cell.getBEL().getPin("D");
		
si.unrouteIntraSiteNet(mux2, sinkD);
si.routeIntraSiteNet(design.getGndNet(), gnd, Carry);
si.routeIntraSiteNet(design.getGndNet(), Carry, xor);
si.routeIntraSiteNet(design.getGndNet(), xor, mux);
si.routeIntraSiteNet(design.getGndNet(), mux, sinkD);

From your example in trying to route through the carry, I'm not quite certain the exact way to achieve what you want. One issue is that the existing routed path to the destination flip-flop is not unrouted or disconnected logically. This will confuse Vivado and likely lead to DRC errors. Its difficult to construct an example without the sample design, so if you are willing to share it, perhaps we can dig further.

Regarding your second question:

My bitstream does not change after having updated it. Which I'm quite sure is due to my use of 'configArray.updateUserStateBits(cell)' , > as I don't know what cells to give it when I am changing so many things at once.

RapidWright can only update documented bitstream bits--in this case the INIT values for the flip-flops. If you change the site routing, RapidWright cannot update the bitstream, you'll have to do this in Vivado.

Chris

[gabrielcobostello]

Hi Cris, thx again for the reply!
Ill leave a dcp of my dummy design here for you to use. It basically is just two FDRE cells connected to leds and switches.
Stuck_at_test_Init_0_noCRC.zip

As for the update bitstream stuff... that is too bad. In any case, I don't necessarily need to modify a bitstream, but just see the frames that change in the config array, although I feel like it will be the same issue. This is what i do to record changed frames:

                List<Integer> Frame_Index = new ArrayList<Integer>();
		List<Integer> Word_Index = new ArrayList<Integer>();
		
		int[][] UnchangedFrames = new int[36][101];
		int[][] ChangedFrames = new int[36][101];
			
		List<Integer> ChangedWords = new ArrayList<Integer>();
		
		//Get frames before changes
		Block StandardBlock = configArray.getConfigBlock(cell.getTile());
		Frame [] StandardFrames = StandardBlock.getFrames();
		
                //Save frames before changes
		for (int frame=0;frame<36;frame++) {
			UnchangedFrames[frame] = StandardFrames[frame].getWords().clone();
		}
		
		make_stuck_at(cell, "INIT", "1'b"+conf.stuck_at_val);
		
		//Get frames after changes
		Block TargetBlock = configArray.getConfigBlock(cell.getTile());
		Frame [] TargetFrames = TargetBlock.getFrames();
		
                //Save frames after changes
		for (int frame=0;frame<36;frame++) {
			ChangedFrames[frame] = TargetFrames[frame].getWords().clone();
		}
		
		//Find changed words in bitstream to generate fault list
		for (int frame=0;frame<36;frame++) {
			for(int word=0;word<101;word++) {
				if(UnchangedFrames[frame][word] != ChangedFrames[frame][word]) {
					ChangedWords.add(ChangedFrames[frame][word]);
					Frame_Index.add(frame);
					Word_Index.add(word);
					int mask = UnchangedFrames[frame][word] ^ ChangedFrames[frame][word];

                                        //Function that generates the FAR 
					int FAR = get_FAR(TargetBlock, frame);
					frecords.add(new FlistRecord(ExperimentID, FAR, word, mask));
				}
			}
		}

Ofc if the config array does not change after the netlist modifications we do, then this piece of code wont be able to see a difference in the frames.

I don't know if you can think of any way this could be achieved, otherwise I will have to revert to mapping the bitstream manually, which is what we have done in the past anyways.

Cheers,
Gabriel.

[clavin-xlnx]

Returning to your earlier request to re-route site routing to get GND to the input of D on AFF, I don't think there is a way to generate a bitstream in the way you are hoping. Although it might be possible to route through the CARRY in theory, it is simpler to just route from the LUT6 output to AFF.D:

        // Unroute the existing site routing
        BELPin sink = si.getBEL("AFF").getPin("D");
        si.unrouteIntraSiteNet(si.getSitePinInst("AX").getBELPin(), sink);
        // Route GND to the AFF D input
        si.routeIntraSiteNet(d.getGndNet(), si.getBEL("A6LUT").getPin("O6"), sink);

        // Unroute the part of the net that arrives at the AX pin on the site
        SitePinInst ax = si.getSitePinInst("AX"); 
        ax.getNet().unroutePin(ax);
        // Update the logical netlist to avoid DRC errors and warnings during bitstream generation
        EDIFCellInst eci = d.getNetlist().getCellInstFromHierName("Test_stuck_at_i/FlipFlop_0/U0/FF");
        EDIFNet logicalNet = eci.getPortInst("D").getNet();
        logicalNet.removePortInst(eci.getPortInst("D"));
        EDIFNet gndNet = EDIFTools.getStaticNet(NetType.GND, eci.getParentCell(), d.getNetlist());
        gndNet.addPortInst(eci.getPortInst("D"));

The code above will accomplish this, however, you will still have more bitstream changes because of the removal of the routing arriving at the AX pin.