Design Article
Tell us What You Think
We want to know what you thought about this Design. Let us know by adding a comment.
Developing FPGA applications for Edition 2 of the IEC 61508 Safety Standard
Dr. Giulio Corradi, Xilinx & Romuald Girardey, Endress+Hauser
1/25/2013 4:26 PM EST
Design isolation
The IDF is explained using Spartan 6 FPGAs as an example. Each isolated function is separated by a fence, thereby generating isolated regions within the device. The flow uses early floorplanning, modular design, modular synthesis, and adherence to a set of guidelines and considerations to guarantee isolation between desired functions. Once a design is implemented, the Isolation Verification Tool (IVT) can be used to constrain the modules and fence; also verifying that the design rules for isolation have been successfully implemented. The isolation blocks can also be considered as a structure that separate and decouple physical blocks. They can be considered as a potential ring since they are driven to be completely connected to ground.
With the development of the IDF, functional safety and non-functional safety processing logic can reside on the same FPGA, thereby allowing safety system designers to realize the full capability of programmable logic. The IDF was developed to allow independent functions to operate on a single device. The process is achieved using the XST, IVT, and PlanAhead tools. Furthermore it can be used to simplify the impact analysis for changes to the non-safety related blocks post-certification.
IDF Flow Description
The first step is module synthesis, followed by system floorplanning, timing analysis; IVT on UCF, design implementation, and IVT on NCD (see Figure 3).
Figure 3. IDF design flow
The example code in Figure 4 shows the top instance of an extremely simplified dual channel, redundant realization of a simple speed checker. Two modules called SafeRight and SafeLeft accept clock, reset, start, speed, and run inputs, and produce fail outputs. All the relevant signals are represented as anti-valent coding except for the clock. Another module, the non-functional-safety, is also implemented. Constraints are applied to all the modules to include I/O within isolated areas, and floorplanning commences much earlier in the design process to ensure that proper isolation is achieved in the logic, routing, and I/O blocks (IOB).
To achieve the proper separation, each isolated function must be in its own partition. Each partition must consist of a single module instantiation. A fence must be used to separate isolated partitions within a single chip. IOBs must be inferred or instantiated inside isolated partitions for proper isolation of the IOB.
Figure 4. Example of redundant speed checker
Designers do not specify the fence location directly; instead, this is created automatically by applying appropriate logic and routing constraints (the AREA_GROUP constraint) to each region to be isolated. This procedure is applied to all the modules to synthesize applying an area constraint.
The PlanAhead tool should be used to create the AREA_GROUPs with physical blocks (PBLOCKS) in such a way that there is specific mapping between the isolated regions and the proper, design dependent, physical area in the FPGA. When placing I/O buffers or pins, it is imperative to consider the physical location of I/Os in relation to the logic regions with which they interface, and this does need to be physically placed within that region. All available resources should be included, even if the logic is not used, because excluding them also excludes using their respective routing resources. This includes clock components such as DCMs, PLLs, and BUFGs, even though such components are instantiated (logically owned) at the top level. Naturally, all used components must be included in the isolated area; the IOB deserve special attention to ensure that they are included properly in the isolated region (Figure 5).
Figure 5. Floorplanning of isolated region
The definition of whether a function is isolated is determined in the PlanAhead tool by setting the module as a partition and then attaching the SCC_ISOLATED attribute to it.
The IVT software is used to verify that an FPGA design that has been partitioned into isolated modules meets the isolation requirements. IVT is a batch application with a command line and file-based user interface. As a first step, IVT is used to perform a series of design rule checks on floorplans and pin assignments. It checks the User Constrain File (UCF) file to identify potential isolation problems before being committed to board layout. After the design is complete, IVT is used again to validate the NCD file such that the required isolation is built into the design and its results can be supplied to a certifying agency for verification. IVT in UCF mode (see Figure 6), checks the following:
Figure 6. Floorplanning with isolation
The IVT is then run in NCD mode and checks the above list against the NCD file. IVT outputs a text file that is a detailed report with faults and other items to be used for official evaluation. Additionally IVT outputs a graphical file representing a high-level overview of the user design that is helpful in quick identification of isolation faults.
Safety-aware place-and-route tools – addressing the challenge without a design isolation flow
Implementing the fence without using the PlanAhead tool is not a simple matter, since all resources must be configured or connected to ground. The solution is to implement the fence during the Place-and-Route (PAR or P&R) phase. This involves defining hard macros by hand using the FPGA Editor (see Figure 7). With a hard macro, it is possible to save a placed-and-routed functional block for reuse in another design. In this case, the fence can be defined and routed by hand, then saved into a hard macro, and finally used in the standard Xilinx toolflow. These tools will implement the macro without modification, and place-and-route the rest of the design around it. However, realizing the fence by hand typically takes so much time that it is not practicable. Therefore, safety-aware PAR Tools have been developed to generate the fence.
Figure 7. Safety-aware PAR tool
The user first defines the form and size of the fence and all function blocks in an Excel sheet, following the rule: a minimum size of 8 CLB for the fence (in gray in Figure 7). The tool then creates a UCF template with the pin assignments for each block and the fence. The user can use this to make their individual assignments. The tool also generates a view of the pin assignments for the PCB Layout. The user can lay out the board according to this information. As stated by the standard, the layout is also important for the implementation of on-chip redundancy.
The tool then creates a SQLite3 database, with all resources present in the fence. For each CLB, DCM, BRAM, multiplier, and IO, the tools uses configuration templates. These templates are defined in such a manner that the maximum amount of internal resources, such as Lookup Tables (LUT), Flip-Flops (FF) and routing lines are configured or connected to ground. The tool creates a XDL file, with the configuration of all resources present in the fence. The XDL file is a configuration description file for the FPGA. This file type comes with a homonymous tool, XDL, which converts XDL files into hard macro files (.nmc) and vice versa. With XDL, it is also possible to retrieve all information about a defined resource, such as all interconnect lines of a CLB and their destinations. This information is used by the Safety-Aware PAR tool: all interconnect lines of a resource in the fence are saved into the database. Afterwards, the tool configures each interconnect line that starts and ends in the fence (according to the information present in the database) to ground. This is a compromise to reduce the interconnect lines usage without compromising the purpose of the fence. Nevertheless, it is ensured that no interconnect lines cross the fence. The long lines crossing the fence are also connected to ground. The configuration of the interconnect lines is also written into the XDL file. Finally, the complete XDL file can be converted into a hard macro file using XDL. The resulting fence is represented as hard macro in blue in Figure 8. For clarity, long lines are not represented here. The generated macro can then be instantiated in the top level HDL file together with all other function blocks. It will be implemented as it is in the FPGA. The other blocks will be placed and routed around.
Figure 8. Resulting fence
Summary
Advancements in design methodologies, combined with tools like PlanAhead, help in achieving the requirements of the IEC 61508 Edition 2 with a smooth design flow. The use of PlanAhead facilitates the definition and placement of isolation regions and timing verification. IVT makes it possible to automate the verification step in such a way that potential human errors are eliminated. The isolation design flow is part of the Xilinx IEC 61508 package for functional safety under the IEC 61508 Edition 2 Safety Standard. The main focus of this article is on 7 Series FPGAs, and how the potential of these devices can be realized in safety applications while being complaint with the IEC 61508 Edition 2 Safety Standard.
About the authors
Dr. Giulio Corradi is a Senior System Architect with the Xilinx Industrial, Scientific and Medical (ISM) group in Munich, Germany. He brings 25 year of experience in management, software engineering, and the development of ASICs and FPGA in industrial, automation and medical systems – specifically in the field of control and communication for the major corporations. DSP algorithms, applied chromatography, motor control, real-time communication, and functional safety have been his major focus. In the years 1997 to 2005, he managed several European funded research projects for train communication networking and wireless remote diagnostic systems. From 2000 to 2005, he headed the IEC61375 conformance test standard. In 2006, Dr. Corradi joined the Xilinx Munich office contributing to the Industrial Networking and Motor Control reference platforms, providing customer guidance on functional safety applications.
Dr. Corradi holds a Doctorate degree in Electronic Engineering from the University of Padua (Italy) where he also has a long-standing collaboration as co-advisor on DSP, control systems, and microelectronic systems. He is active with the Karlsruhe Institute of Technology (Germany) for safety systems; also with the University of Cergy-Pointoise (France) and the University of Maribor (Slovenia) for power systems. In his spare time, he enjoys swimming and playing the piano.
Romuald Girardey received a Master's degree in industrial informatics in 2003 from the Ecole Nationale Supérieure de Physique de Strasbourg (ENSPS) in Strasbourg, France. Since 2003, he has been working for Endress+Hauser in the R&D electronics department as an electronic developer. He has a broad experience in the development of software, analog and digital electronics and FPGA design, especially in ultra-low power and safety-critical applications in the process automation domain. He is certified as a Functional Safety Engineer by the TÜV Rheinland. In parallel, since October 2007, he has worked on his PhD study at the Institute for Information Processing (ITIV), from the Karlsruhe Institute of Technology (KIT), in Karlsruhe, Germany, with the topic: “FPGA and FPAA in safety critical applications.”
If you found this article to be of interest, visit Programmable Logic Designline where – in addition to my Max's Cool Beans blogs – you will find the latest and greatest design, technology, product, and news articles with regard to programmable logic devices of every flavor and size (FPGAs, CPLDs, CSSPs, PSoCs...).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
The IDF is explained using Spartan 6 FPGAs as an example. Each isolated function is separated by a fence, thereby generating isolated regions within the device. The flow uses early floorplanning, modular design, modular synthesis, and adherence to a set of guidelines and considerations to guarantee isolation between desired functions. Once a design is implemented, the Isolation Verification Tool (IVT) can be used to constrain the modules and fence; also verifying that the design rules for isolation have been successfully implemented. The isolation blocks can also be considered as a structure that separate and decouple physical blocks. They can be considered as a potential ring since they are driven to be completely connected to ground.
With the development of the IDF, functional safety and non-functional safety processing logic can reside on the same FPGA, thereby allowing safety system designers to realize the full capability of programmable logic. The IDF was developed to allow independent functions to operate on a single device. The process is achieved using the XST, IVT, and PlanAhead tools. Furthermore it can be used to simplify the impact analysis for changes to the non-safety related blocks post-certification.
IDF Flow Description
The first step is module synthesis, followed by system floorplanning, timing analysis; IVT on UCF, design implementation, and IVT on NCD (see Figure 3).
Figure 3. IDF design flow
The example code in Figure 4 shows the top instance of an extremely simplified dual channel, redundant realization of a simple speed checker. Two modules called SafeRight and SafeLeft accept clock, reset, start, speed, and run inputs, and produce fail outputs. All the relevant signals are represented as anti-valent coding except for the clock. Another module, the non-functional-safety, is also implemented. Constraints are applied to all the modules to include I/O within isolated areas, and floorplanning commences much earlier in the design process to ensure that proper isolation is achieved in the logic, routing, and I/O blocks (IOB).
To achieve the proper separation, each isolated function must be in its own partition. Each partition must consist of a single module instantiation. A fence must be used to separate isolated partitions within a single chip. IOBs must be inferred or instantiated inside isolated partitions for proper isolation of the IOB.
Figure 4. Example of redundant speed checker
Designers do not specify the fence location directly; instead, this is created automatically by applying appropriate logic and routing constraints (the AREA_GROUP constraint) to each region to be isolated. This procedure is applied to all the modules to synthesize applying an area constraint.
The PlanAhead tool should be used to create the AREA_GROUPs with physical blocks (PBLOCKS) in such a way that there is specific mapping between the isolated regions and the proper, design dependent, physical area in the FPGA. When placing I/O buffers or pins, it is imperative to consider the physical location of I/Os in relation to the logic regions with which they interface, and this does need to be physically placed within that region. All available resources should be included, even if the logic is not used, because excluding them also excludes using their respective routing resources. This includes clock components such as DCMs, PLLs, and BUFGs, even though such components are instantiated (logically owned) at the top level. Naturally, all used components must be included in the isolated area; the IOB deserve special attention to ensure that they are included properly in the isolated region (Figure 5).
Figure 5. Floorplanning of isolated region
The definition of whether a function is isolated is determined in the PlanAhead tool by setting the module as a partition and then attaching the SCC_ISOLATED attribute to it.
The IVT software is used to verify that an FPGA design that has been partitioned into isolated modules meets the isolation requirements. IVT is a batch application with a command line and file-based user interface. As a first step, IVT is used to perform a series of design rule checks on floorplans and pin assignments. It checks the User Constrain File (UCF) file to identify potential isolation problems before being committed to board layout. After the design is complete, IVT is used again to validate the NCD file such that the required isolation is built into the design and its results can be supplied to a certifying agency for verification. IVT in UCF mode (see Figure 6), checks the following:
- Pins from different isolation groups are not physically adjacent, vertically or horizontally, at the die
- Pins from different isolation groups are not physically adjacent at the package. Adjacency is defined in eight compass directions: north, south, east, west, northeast, southeast, northwest, and southwest.
- Pins from different isolation groups are not co-located in an IOB bank
- The AREA_RANGE constraints in the UCF are defined such that a minimum of a one tile-wide fence exists between isolated regions.
Figure 6. Floorplanning with isolation
The IVT is then run in NCD mode and checks the above list against the NCD file. IVT outputs a text file that is a detailed report with faults and other items to be used for official evaluation. Additionally IVT outputs a graphical file representing a high-level overview of the user design that is helpful in quick identification of isolation faults.
Safety-aware place-and-route tools – addressing the challenge without a design isolation flow
Implementing the fence without using the PlanAhead tool is not a simple matter, since all resources must be configured or connected to ground. The solution is to implement the fence during the Place-and-Route (PAR or P&R) phase. This involves defining hard macros by hand using the FPGA Editor (see Figure 7). With a hard macro, it is possible to save a placed-and-routed functional block for reuse in another design. In this case, the fence can be defined and routed by hand, then saved into a hard macro, and finally used in the standard Xilinx toolflow. These tools will implement the macro without modification, and place-and-route the rest of the design around it. However, realizing the fence by hand typically takes so much time that it is not practicable. Therefore, safety-aware PAR Tools have been developed to generate the fence.
Figure 7. Safety-aware PAR tool
The user first defines the form and size of the fence and all function blocks in an Excel sheet, following the rule: a minimum size of 8 CLB for the fence (in gray in Figure 7). The tool then creates a UCF template with the pin assignments for each block and the fence. The user can use this to make their individual assignments. The tool also generates a view of the pin assignments for the PCB Layout. The user can lay out the board according to this information. As stated by the standard, the layout is also important for the implementation of on-chip redundancy.
The tool then creates a SQLite3 database, with all resources present in the fence. For each CLB, DCM, BRAM, multiplier, and IO, the tools uses configuration templates. These templates are defined in such a manner that the maximum amount of internal resources, such as Lookup Tables (LUT), Flip-Flops (FF) and routing lines are configured or connected to ground. The tool creates a XDL file, with the configuration of all resources present in the fence. The XDL file is a configuration description file for the FPGA. This file type comes with a homonymous tool, XDL, which converts XDL files into hard macro files (.nmc) and vice versa. With XDL, it is also possible to retrieve all information about a defined resource, such as all interconnect lines of a CLB and their destinations. This information is used by the Safety-Aware PAR tool: all interconnect lines of a resource in the fence are saved into the database. Afterwards, the tool configures each interconnect line that starts and ends in the fence (according to the information present in the database) to ground. This is a compromise to reduce the interconnect lines usage without compromising the purpose of the fence. Nevertheless, it is ensured that no interconnect lines cross the fence. The long lines crossing the fence are also connected to ground. The configuration of the interconnect lines is also written into the XDL file. Finally, the complete XDL file can be converted into a hard macro file using XDL. The resulting fence is represented as hard macro in blue in Figure 8. For clarity, long lines are not represented here. The generated macro can then be instantiated in the top level HDL file together with all other function blocks. It will be implemented as it is in the FPGA. The other blocks will be placed and routed around.
Figure 8. Resulting fence
Summary
Advancements in design methodologies, combined with tools like PlanAhead, help in achieving the requirements of the IEC 61508 Edition 2 with a smooth design flow. The use of PlanAhead facilitates the definition and placement of isolation regions and timing verification. IVT makes it possible to automate the verification step in such a way that potential human errors are eliminated. The isolation design flow is part of the Xilinx IEC 61508 package for functional safety under the IEC 61508 Edition 2 Safety Standard. The main focus of this article is on 7 Series FPGAs, and how the potential of these devices can be realized in safety applications while being complaint with the IEC 61508 Edition 2 Safety Standard.
About the authors
Dr. Giulio Corradi is a Senior System Architect with the Xilinx Industrial, Scientific and Medical (ISM) group in Munich, Germany. He brings 25 year of experience in management, software engineering, and the development of ASICs and FPGA in industrial, automation and medical systems – specifically in the field of control and communication for the major corporations. DSP algorithms, applied chromatography, motor control, real-time communication, and functional safety have been his major focus. In the years 1997 to 2005, he managed several European funded research projects for train communication networking and wireless remote diagnostic systems. From 2000 to 2005, he headed the IEC61375 conformance test standard. In 2006, Dr. Corradi joined the Xilinx Munich office contributing to the Industrial Networking and Motor Control reference platforms, providing customer guidance on functional safety applications.Dr. Corradi holds a Doctorate degree in Electronic Engineering from the University of Padua (Italy) where he also has a long-standing collaboration as co-advisor on DSP, control systems, and microelectronic systems. He is active with the Karlsruhe Institute of Technology (Germany) for safety systems; also with the University of Cergy-Pointoise (France) and the University of Maribor (Slovenia) for power systems. In his spare time, he enjoys swimming and playing the piano.
Romuald Girardey received a Master's degree in industrial informatics in 2003 from the Ecole Nationale Supérieure de Physique de Strasbourg (ENSPS) in Strasbourg, France. Since 2003, he has been working for Endress+Hauser in the R&D electronics department as an electronic developer. He has a broad experience in the development of software, analog and digital electronics and FPGA design, especially in ultra-low power and safety-critical applications in the process automation domain. He is certified as a Functional Safety Engineer by the TÜV Rheinland. In parallel, since October 2007, he has worked on his PhD study at the Institute for Information Processing (ITIV), from the Karlsruhe Institute of Technology (KIT), in Karlsruhe, Germany, with the topic: “FPGA and FPAA in safety critical applications.”If you found this article to be of interest, visit Programmable Logic Designline where – in addition to my Max's Cool Beans blogs – you will find the latest and greatest design, technology, product, and news articles with regard to programmable logic devices of every flavor and size (FPGAs, CPLDs, CSSPs, PSoCs...).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
|
|
|
|
|
Navigate to related information