June 2017 - Now
Leading DFT Engineer
Sondrel (England)
Leading DFT Engineer
Sondrel (England)
Following the acquisition of our team by Sondrel, I took more responsibilities by becoming lead of the ongoing DFT activities.
Technical lead of a +400 mm2 SoC in 16nm :
ATE bring-up of a 4M DFF in 28nm SoC (ES and respin) :
I inherited a web based tool used by the backend team to monitor synthesis and layout jobs, providing a quick way to access metrics on how a given job is progressing. The tool is based on PHP/MySQL, with a TCL server to feed data into the database (the physical design flow sends the relevant information to this server). I have since improved this tool to also capture scan insertion metrics, allowing easy access to scan insertion metrics to anyone but also helping me to collect and track scan insertion quality across the SoC. A second improvement I made to the tool was to introduce tracking of the memory bist releases that are made (internal release process of a memory bist inserted design) for a given SoC and the ability to search for the physical design jobs using a given memory bist release.
Technical lead of a +400 mm2 SoC in 16nm :
- Leading 3 DFT engineer, involving planning the remaining work, assigning tasks, managing priorities, reporting progress to the programme manager and to the project manager.
- Architecting the DFT for the SoC. The major challenge here for me was architecting the scan due to the size of the project. The scan strategy is based around scan isolation wrapper to allow testing of different parts of the SoC independently while maintaining hight coverage and hight pattern efficiency. Another important architecting decision was to base memory bist and AMS testing on IEEE1687 IJTAG, to allow hierarchical insertion, and easy pattern re-targeting thanks to Tessent Shell from Mentor Graphics.
- Leading flow developments to facilitate the DFT work on the project. By working on the scan insertion flow, I learnt about the complex scan insertion techniques available with Synopsys DFTMAX, like the hybride flow and the core wrapping techniques.
- Documenting the DFT architecture and specifying its implementation. With the help of my team of DFT engineers, we are writing and maintaining general documents for the overall SoC, but also specific documents tailored to specificity of each subsystem.
ATE bring-up of a 4M DFF in 28nm SoC (ES and respin) :
- AMS tests development, and support the test house to bring them up. IP involved : HDMI, MIPI, ADC, DAC, DDR4 controller, efuse, USB3, boundary scan
- Memory bist bring-up. This involved re-generating some of the test patterns with a different clock tree setup due to some clocks running too fast.
- ATPG and scan bring-up. A few issues encountered during scan bring-up. One of them was related to the scan clock timeplate. Another issue was related to a bug on some of the pads (fixed for the respin).
I inherited a web based tool used by the backend team to monitor synthesis and layout jobs, providing a quick way to access metrics on how a given job is progressing. The tool is based on PHP/MySQL, with a TCL server to feed data into the database (the physical design flow sends the relevant information to this server). I have since improved this tool to also capture scan insertion metrics, allowing easy access to scan insertion metrics to anyone but also helping me to collect and track scan insertion quality across the SoC. A second improvement I made to the tool was to introduce tracking of the memory bist releases that are made (internal release process of a memory bist inserted design) for a given SoC and the ability to search for the physical design jobs using a given memory bist release.
Aug. 2015 - May 2017
DFT Hardware Design Engineer
Imagination Technologies (England)
DFT Hardware Design Engineer
Imagination Technologies (England)
I joined a Design For Test team in the SoC design division.
DFT work on a first SoC (1000k DFF, tapped out end of 2016) :
DFT work on 2 new SoC (both kickoff end of 2016) :
Methodology work :
DFT work on a first SoC (1000k DFF, tapped out end of 2016) :
- In charge of ATPG. Working with physical design to provide ECO scripts to fix scan issues. Synopsys TetraMAX used for ATPG.
- Scan simulation (Stuck-At, Transition Fault with Synopsys OCC, in 0 delay and with SDF) : In order to improve efficiency, I developed a script based environment to run scan simulations. This environment is based on a combination of modular configuration files in order to centralise the configuration across the different type of scan simulations.
- AMS tests : Responsible for the BIST testing of Synopsys HDMI Rx PHY and Synopsys DDR4 PHY. Tests written in SVF format. This was a good opportunity for me to learn about JTAG / TAP based testing.
- Working with STA to identify case analysis, give feedback about what can be false pathed, and debug failing at-speed simulations.
- ATE bring-up coordination and support
DFT work on 2 new SoC (both kickoff end of 2016) :
- Writing and reviewing DFT specifications for subsystems involving third party IPs (DDR4, HDMI, MIPI, PCIe, SATA, SerDes).
- In charge of the top level DFT strategy for one of the 2 SoC.
Methodology work :
- Development of a hierarchical MBIST insertion flow (Mentor Tessent Shell), at RTL level on VHDL and Verilog design, in a bottom up fashion.
- Development of a boundary scan verification flow for subsystems.
- Evaluation of Mentor IJTAG (IEEE 1687) solution for AMS testing.
- Responsible of a memory partitioning/generation tool. This is used across the division to generate RAMs and ROMs for our SoCs.
- Creation of a few test cases in order to experiment new tools or flows. Small VHDL and Verilog designs containing memories, with the associated scripts for MBIST insertion, MBIST simulation, synthesis, scan insertion, formal equivalence, and ATPG.
- Study and development of a hardware solution to provide scan testing through the TAP with limited equipments (in our lab or at our desk for example). Wide variety of technical challenges involved in this project : Software (development of a STIL parser, USB communication), Hardware (FPGA development).
Sept. 2013 - Aug. 2015 (2 years)
DFT Hardware Design Engineer
STMicroelectronics Edinburgh (Scotland)
DFT Hardware Design Engineer
STMicroelectronics Edinburgh (Scotland)
I joined a Design For Test implementation and methodology team. The aim of the team was to Spec the test requirements for our circuits, implement previously defined solutions, verify it after been integrated, and deliver patterns to test engineers.
Often working on multiple projects in parallel with very tight schedules, I know how to organize myself to not miss anything. I had also to interact with other team from different domains (Design, Synthesis/P&R, Timing analysis, Test Engineer, ...) and from other geographic sites with different time zone.
Our mission was also to develop and improve our methodology/flows. I contributed to this activity by developing a SystemVerilog package used for the Verification of the Design. This module provide an easy and standardized way to communicate to the DUT (Device Under Test) through serial buses.
- I was in charge of the setup, maintaining and run ATPG tool (Mentor Tessent) for some of our projects
- Running Scan simulations on the previously generated patterns by ATPG tool (zero delay and back-annotated with SDF)
- I was also asked to develop SystemVerilog (UVM) testbench for DFT functional tests (BIST, IO muxing, ...), or to verify some parts of the design (I worked on the verification of a CAB RCC BIST)
Often working on multiple projects in parallel with very tight schedules, I know how to organize myself to not miss anything. I had also to interact with other team from different domains (Design, Synthesis/P&R, Timing analysis, Test Engineer, ...) and from other geographic sites with different time zone.
Our mission was also to develop and improve our methodology/flows. I contributed to this activity by developing a SystemVerilog package used for the Verification of the Design. This module provide an easy and standardized way to communicate to the DUT (Device Under Test) through serial buses.
- Thanks to this module, a test can be easily used on an other project with a different serial bus (for instance SPI instead of I2C)
- The module was also monitoring all the interactions at the boundary of the DUT and dump automatically a pattern set in an human readable language that can be run on our FPGA platforms, on tester, and also can be re-simulated
- Thanks to that, test writing become more standardized from project to project and the pattern delivery is more reliable and quick
Sept. 2010 - Aug. 2013 (3 years)
Engineer degree in apprenticeship
STMicroelectronics Crolles (France)
Engineer degree in apprenticeship
STMicroelectronics Crolles (France)
I join a characterization team in the R&D department, and my mission was to develop tools to improve the everyday work of the team.
My first main project was a tool to automatically setup semi-conductor test equipment. The data was loaded from a follow-up software. This tool speed up the time required to setup the tester (now done in 15mins instead of 1h) and made this process more reliable. I had to work closely with other team to understand the requirements, and also with an external company who developed the follow up software to understand how I can get the information that I need.
My second main project was a monitoring of our tests equipment.
My first main project was a tool to automatically setup semi-conductor test equipment. The data was loaded from a follow-up software. This tool speed up the time required to setup the tester (now done in 15mins instead of 1h) and made this process more reliable. I had to work closely with other team to understand the requirements, and also with an external company who developed the follow up software to understand how I can get the information that I need.
My second main project was a monitoring of our tests equipment.
- The aim was in the first place to see in live and in one go what is the status of any tester (used, not used, frozen)
- The second requirement was to draw usage graph over weeks or month of our set of testers
- The last requirement was to trigger an alarm on the phone of some people if something is going wrong on a tester
Sept. 2009 - Aug. 2010 (1 year)
Second year of technical degree in apprenticeship
STMicroelectronics Crolles (France)
Second year of technical degree in apprenticeship
STMicroelectronics Crolles (France)
I was part of a High Frequency Characterization team for 1 year of apprenticeship.
The main activity was to do HF measurement and write report analyses of the results. S parameter were measured on transistor or self with different geometry. The aim was to characterise new technology node libraries.
During this activity I suggested to my team to develop a software to automate the raw data import to Excel and generating useful graphs. They agreed, so this became a side activity. I came up after some month to something who generated the skeleton of the report with inside the main parts of the required graph. By using the tool, writing a report now take 1 day instead of 2 without it.
The main activity was to do HF measurement and write report analyses of the results. S parameter were measured on transistor or self with different geometry. The aim was to characterise new technology node libraries.
During this activity I suggested to my team to develop a software to automate the raw data import to Excel and generating useful graphs. They agreed, so this became a side activity. I came up after some month to something who generated the skeleton of the report with inside the main parts of the required graph. By using the tool, writing a report now take 1 day instead of 2 without it.