|
|
| Line 1: |
Line 1: |
| − | = Notes from "Discussion on common benchmark designs & tools" - March 7th 2018 - ICT 207ab =
| |
| | | | |
| − | We tried to understand what benchmarks and tool everyone in the department are using.
| |
| − |
| |
| − | 3 objectives:
| |
| − | - Everyone knows what each group does
| |
| − | - Finding overlaps in designs and maybe collaboration
| |
| − | - Maybe coming up with one platform that we can use between groups for collaboration
| |
| − |
| |
| − | - Purpose: Give an overview of what each group in the department has done so far.
| |
| − | How much we can re-use the available benchmarks and tools
| |
| − |
| |
| − | - Tools:
| |
| − |
| |
| − | 1) IC Health Monitoring Instrumentation (Kostja): (IJTAG and Testonica related)
| |
| − |
| |
| − | Fault monitoring and prevention -> based on integrated fault detectors.
| |
| − | Health and fault management architecture -> several layers from HW to SW.
| |
| − | Faults occurred in HW are handled with HW monitors and IJTAG network is used for transmitting fault information.
| |
| − | In SW, drivers get the information and understand what has happened to the HW.
| |
| − | (Drivers connect the fault management hardware to the SW ?!)
| |
| − |
| |
| − | Each app. uses which resources is also tracked.
| |
| − | Main idea: track the health and faults in HW and react accordingly in SW.
| |
| − |
| |
| − | Demo is on Zynq platform -> going to be implemented on a platform with LEON3 processor and Linux as the OS.
| |
| − |
| |
| − | LEON3 is used because it is a soft-core and faults can be injected into the processor.
| |
| − | Also used because it is widely used in space apps. -> Collaboration with Geisler (?!) (maybe even using Bonfire NoC and connect LEON3 processors to it.)
| |
| − |
| |
| − | AXI bus is used to connect the HW to the rest of the system.
| |
| − |
| |
| − | Initial configuration was with 4 LEON3 processors (bus-based communication).
| |
| − | Currently their own architecture is run on top of the system. Application to be run is yet to be planned. For now it is some dummy calculations. Apps are running on Linux and Linux runs on LEON3.
| |
| − |
| |
| − | 2) IJTAG (Anton):
| |
| − |
| |
| − | 4 categories for the benchmarks:
| |
| − | Basic
| |
| − | Classic
| |
| − | Standard
| |
| − | Advanced
| |
| − |
| |
| − | The webpage also provides the schematics of each structure. (From BASTION project page)
| |
| − | - PDL is also included (?!)
| |
| − |
| |
| − | IJTAG tool:
| |
| − | A software library for processing ICL (in Java)
| |
| − | At bottom layer ICL sources are read, and their semantics are checked. In the middle layer, algorithms and checkers can be added in Java. On the top layer, the application or the converter is built (for example a VHDL converter). Visualization capability can also be added at the top layer.
| |
| − | SMD converter has also been done as part of BASTION project.
| |
| − | Recently PDL parser is also added (reading PDL and creating a structure and traverse later if needed).
| |
| − | Re-targetter (?!) is still an open question.
| |
| − | The library is extendible.
| |
| − |
| |
| − |
| |
| − | 3) Embedded Instrumentation (Igor)
| |
| − |
| |
| − | For PCBs -> IF PCB has an FPGA, a set of instruments have been provided that can be integrated into the FPGA.
| |
| − | Testonica provides the whole framework.
| |
| − | It is limited to FPGA boards only.
| |
| − | This is related to board testing, not chip testing.
| |
| − |
| |
| − | 4) ISCAS'85 combinational circuits (Sergei Kostin)
| |
| − |
| |
| − | ISCAS benchmark circuits
| |
| − | No. of inputs , logic gates number, ...
| |
| − | Available both in edif and Verilog formats.
| |
| − | Can be used in Turbo Tester
| |
| − |
| |
| − | ISCAS'89 sequential circuits
| |
| − | ISCAS benchmark circuits
| |
| − | Available in bench and edif formats.
| |
| − | Available in pseudo-combinational forms (FFs are changed to pseudo-combinational circuit)
| |
| − | To be used by Turbo Tester fault simulation tools for combinational circuits.
| |
| − |
| |
| − | ITC'99 sequential circuits
| |
| − | Another benchmark
| |
| − | Available on github.
| |
| − | Available in bench and edif and vhd formats.
| |
| − | Includes more complex circuits compared to previous benchmarks (?!).
| |
| − |
| |
| − | All benchmarks are available in RTL, not only in gate-level.
| |
| − |
| |
| − | 5) Turbo Tester and Apricot (Jaan)
| |
| − |
| |
| − | Turbo Tester:
| |
| − | An old system, started in the beginning of 90s.
| |
| − | In 1993, it was some pieces of programs.
| |
| − | In 1993 Jaan implemented everything again.
| |
| − | It is about test tools at gate-level using SSBDDs.
| |
| − | Still being used for experiments at gate-level.
| |
| − | They have been modified to add support for concurrent online checkers for detecting stuck at faults in control part of NoCs.
| |
| − | The logic can be represented at gate level or macro level.
| |
| − | This has opportunities: implementing new methods.
| |
| − | Advances of Higher level circuit modeling.
| |
| − | Jaan developed ATPGs.
| |
| − | During the years, through research, new features and tools were added to TT (some tools even faster than Mentor Graphics tools (parallel fault simulator)).
| |
| − | Today, combinational critical path tracing is still being used, even used in sequential circuits (?!). Sergei Devadze has contributed to this.
| |
| − | Adding support for simulating in sequential circuits. (Artjom).
| |
| − | Now we divide sequential circuits to two paths.
| |
| − | A paper being published soon regarding this.
| |
| − | Speed-up up to 500 times has been achieved compared to state-of-the-art.
| |
| − | Advantage: You can take a look inside the simulations. But this is not present in commercial tools or it is slower.
| |
| − | 20 papers based on TT -> Should be explained in a manual.
| |
| − | Jaan will talk to Siavoosh about this.
| |
| − | TT also has tools for analyzing BISTs.
| |
| − | Sequential and Sequential_fast differences unclear ?!
| |
| − | We need updated documentation.
| |
| − |
| |
| − | Apricot tool:
| |
| − | Older than TT.
| |
| − | ?!
| |
| − |
| |
| − | We have to look into what we have and make sure the links work and whether they are well-documented. We should analyze if there is a need.
| |
| − |
| |
| − | 6) ZamiaCAD (one of the reasons that we got shifted from Apricot)
| |
| − |
| |
| − | The tool was initially meants to be sold to IBM.
| |
| − | Scalability was taken into account for designing the tool.
| |
| − | Provides the possibility to analyze, synthesize and simulate the VHDL design.
| |
| − | Going to support Verilog soon.
| |
| − | Able to localize bugs in the VHDL design.
| |
| − | Supports NBTI rejuvenation.
| |
| − | It can extract FSMs from the design as well (of course some synthesis tools also do that!)
| |
| − | It was able to import a SoC design with more than 3000 processors (LEON3)!
| |
| − | Compared to Synopsys Design Compiler and Cadence Virtuoso, they could not import this big design (?!). Sigasi also couldn't handle this properly.
| |
| − | The tool is automated by Python scripts.
| |
| − | For Cem and Apneet, they are going to use this tool.
| |
| − | Possible to control everything using Python scripts.
| |
| − |
| |
| − | 7) SoCDep2 (Siavoosh)
| |
| − |
| |
| − | A Python-based tool
| |
| − | Able to model applications and the architecture (for example NoC)
| |
| − | Different task mapping heuristics.
| |
| − | Mapper/Scheduler support
| |
| − | It has been used for testing:
| |
| − | Routing graph related stuff (possible to the model the routing algorithm of a network based on the RG (routing graph))
| |
| − | Possible to see connectivity between two nodes, also checking reachability.
| |
| − | Testing system availability (predict failure)
| |
| − | Perform a mapping as close to as the current mapping
| |
| − | No real application is there yet. There is task graph based app.
| |
| − | SHMU is a stand-alone unit and does not get into the actual scheduling of the system.
| |
| − |
| |
| − | 8) Bonfire (Siavoosh)
| |
| − |
| |
| − | A fault-tolerant NoC with dependability mechanisms (VHDL RTL)
| |
| − | Supports Plasma as the processor at each node.
| |
| − | Plasma is so slow that we cannot even flood the network.
| |
| − | No OS support yet on Bonfire NoC!
| |
| − | An updated version available with VC support
| |
| − | Used for two projects:
| |
| − | 1) QoSinNoC with Torino (Quality of Service and mixed criticality)
| |
| − | 2) Security-directed project with TU Munich
| |
| − | Maybe we decide to connect RISC-V based core to Bonfire NoC ?!
| |
| − | The Network Interface (NI) uses memory-mapped IO.
| |
| − |
| |
| − | 9) IoT Development Center (Mairo)
| |
| − |
| |
| − | Research objectives:
| |
| − | Bring Machine learning more into the embedded world
| |
| − | Self-driving car
| |
| − | Understand in a big aquarium, how fish are affected by the forces (?!)
| |
| − | Implementation of the algorithm and then analysis (development + analysis)
| |
| − | Different development environments and tools are used.
| |
| − | Most of the work is related to data.
| |
| − | The data needs to be analyzed later somehow.
| |
| − | Possibility to work between Mairo (dependability aspects of the work) and Kalle (self-awareness)
| |
| − | Mostly RT (Real-Time) OS is used -> FreeRTOS
| |
| − | Can this data be used for a traffic on Network on Chip. -> possible, especially if parallelsim of running the apps would be needed!
| |
| − |
| |
| − | 10) Self-awareness studies (Kalle)
| |
| − |
| |
| − | Definitions:
| |
| − | * Attention in hardware: Find out which issues are important and use the focused intelligence to converse energy ?!
| |
| − | * Reasoning: predicting behaviour and providing some sort of analysis (?!)
| |
| − |
| |
| − | NuPIC : Cortical learning algorithm of Numenta
| |
| − | - Inspired by how the human cortex in brain works (?!)
| |
| − | - Established by Jeff Hawkins (?!)
| |
| − | - Available for free (downloadable).
| |
| − |
| |
| − | Possible to connect self-awareness to Mairo's work (machine learning).
| |
| − | Dependable -> possible for collaboration with our group.
| |
| − |
| |
| − | 11) FRASER (Karl)
| |
| − |
| |
| − | A tool developed by DLR
| |
| − | The tool simulates complex systems
| |
| − | Event-based simulation envinronment, where you can run different models together.
| |
| − | With different levels of abstraction (for example behavioural C++ and RTL design together).
| |
| − | Initially it was used for satellite applications (?!)
| |
| − | If you want to test how a specific component integrates into the system, this tool can be a possibility to be used.
| |
| − | Possible to add abstract model of the processing system as well in this tool.
| |
| − | Currently:
| |
| − | Trying to implement the Bonfire NoC in it.
| |
| − | SystemC model of Bonfire NoC is being built. -> Saif
| |
| − | The tool is meant for satellites, but other cyber-physical systems can also be used (?!).
| |
| − |
| |
| − | We will have one repository for Bonfire, maybe with different implementations of it in different languages.
| |
| − |
| |
| − | 12) Embedded software performance analysis (Priit)
| |
| − |
| |
| − | Without using any OS currently.
| |
| − | Benchmarks are used. They can act as traffic generators we use in QoSinNoC.
| |
| − | Even maybe possible to be used for Joel's work.
| |
| − | Might be used for: Non-functional verification for different non-functional aspects (Anna)
| |
| − | It also includes the total energy, which defines the performance. (?!)
| |
| − |
| |
| − | 13) Parwan CPU (Artjom)
| |
| − |
| |
| − | Used as a processor for runnning benchmarks by Sergei ?!
| |
| − | Programs are written in Assembly.
| |
| − |
| |
| − | 14) MiniMIPS (Artjom + Marina)
| |
| − |
| |
| − | It is pipelined.
| |
| − | It is in RTL + simulation is available.
| |
| − | Gate-level analysis
| |
| − | Need to run a script and the program will be compiled for MiniMIPS and test vector gets extracted.
| |
| − |
| |
| − | The version which is on Opencores is not working.
| |
| − | Artjom has the working version gotten from Torino.
| |
| − |
| |
| − | 14) Plasma CPU (Karl)
| |
| − |
| |
| − | Open-source processor
| |
| − | Synthesizable for ASIC and FPGA use.
| |
| − | Based on MIPS I architecture + GCC support
| |
| − | Too slow for our needs:
| |
| − | It was very slow when used with Bonfire NoC (interrupts also make it very slow).
| |
| − | Used as Processing Element (PE) in Bonfire chip for IMMORTAL project.
| |
