MicroZed Chronicles: Using Isolation Flow in Vivado

We recently looked at how we could create a Triple Modular Redundant MicroBlaze solution for use in high reliability applications. Of course, that is not the only design methodology we can deploy in our FPGA /SoC if we are creating a high reliability system.

Another technique we can use is the use of physical isolation of functions within the device itself. This is very useful for when we want to ensure redundant functions cannot affect the other, e.g. to provide physical separation between TMR channels. Isolation is also useful when it comes to information security and ensuring encrypted data (black) cannot be leak out clear text data (red).

Rather helpfully, Vivado provides us the ability to implement isolation between channels with the isolation flow.

Let’s take a look at how we can do this, using a simple Zynq-based example that utilizes two channels — each one identical containing a AXI BRAM controller and a BRAM. These blocks will be mapped into the PS memory space for access from the PL.

There are a few rules when we create a design we intend to use with isolation flow. The first and most important is that the top level of the design should contain minimal logic, all functionality should be contained within hierarchical blocks.

While this is a basic example, the idea is to outline the development flow that we as engineers undertake to use the isolation flow.

The first step in implementing isolation between elements is to open the elaborated design. It is in this view that we can identify to the tool which elements of the design we wish to isolate by applying the HD.ISOLATED property.

In this example, we will be applying it to the hierarchical blocks channel and channel1. To add this property, you need to open the cell properties view and then click on the add properties button and select it from the list which is then provided.

Once the property is available within the cell properties window, the final step is to check it to ensure it is applied to the block.

With isolation enabled for the two hierarchical blocks the next step is to save the elaborated design. Doing so will ask if you want to save the constraints, it is in the constraints file the the isolation information is supplied.

Having identified the blocks we wish to isolate from each other, before we can implement the design we need to create two Pblocks and allocate the isolated areas to them.

The Pblocks need to contain the resources needed to implement the isolated function. As the two isolated functions I am creating are contained solely in the PL, my Pblocks will not contain any IO resources.

When implemented, all logic for a function will be contained within the PBlock or if it communicates with another isolated function, a trusted route will be implemented. Trusted routes are only allowed between isolated functions and cannot be used to communicate with non-isolated functions.

Of course, this could present issues with global routes such as clocks, inside a isolated function. To address this issue, we can use the ISOLATE EXEMPT constraint, which can be applied to global / regional clocks and other exempted signals.

We can use the synthesized design to floor plan the Pblocks, location, and size.

When we create the Pblocks, we need to keep in mind the rules regarding fencing. Fencing in the insertion of at least one unused tile / function between isolated functions, this ensures a single error cannot break the isolation.

Once the Pblocks have been created, the next stage is to apply the isolation functions to the Pblocks.

We are then in a position where we are able to implement the design. If we try and implement the design with only the isolation functions defined but no Pblock allocation, we receive a number of implementation errors.

Once the implementation is completed, we need to run the Vivado Isolation Verification DRC checks. This ensures there are no errors in the design.

To include these in our design, we need to download and source a TCL script.

To run these scripts, we need to open the implemented design, and run the isolation DRC checks. If we are working on a complicated design which takes time to build, we can also run these DRC after we have finished the floor planning stage to de-risk the process.

Once these tests have been run, warnings and errors may be raised which should be addressed prior to deployment.

This is a fairly simple example but it shows the ease with which we can implement isolated functions in our design and verify we have implemented them correctly. The ability to provide in-device isolation is critical for many applications which FPGA and SoC are being deployed in.

You can find more information on isolation flow here.

See My FPGA / SoC Projects: Adam Taylor on Hackster.io

Get the Code: ATaylorCEngFIET (Adam Taylor)

Access the MicroZed Chronicles Archives with over 250 articles on the Zynq / Zynq MpSoC updated weekly at MicroZed Chronicles.