Jan. 2019 - Present
Staff Design Engineer
Blaize (England)
Staff Design Engineer
Blaize (England)
Staff Design Engineer at Blaize, an AI accelerator company. I joined the SoC design team as DFT lead for the company's SoC and IP designs, and my role grew to span SoC design, debug infrastructure, and in-house tooling across the full silicon lifecycle.
DFT & Implementation
DFT & Implementation
- DFT lead for SoC designs and Blaize IP designs, owning scan, MBIST and ATPG from architecture to sign-off. Taped out a 6M flops, 75 mm2 design, and currently developing a ~70M flops SoC.
- Synthesis trials for various designs across the SoC: SoC blocks, video IP, parts of the NoC, and debug probes.
- DFT and synthesis TCL flow development on Siemens Tessent Shell and Cadence Genus respectively.
- SoC debug infrastructure development using Siemens Embedded Analytics (formerly UltraSoC).
- SoC NoC design using Arteris FlexNoC5. Fully hierarchical and asynchronously partitioned NoC to ease top-level, partition and subsystem physical design tasks.
- Authored specifications and RTL for multiple SoC blocks: programmable address-hashing function, MSI generator, programmable address extension, and PVT controller.
- FPGA designs to support bootrom development and video IP validation using Xilinx Vivado, leveraging the built-in PCIe and DDR IPs of the FPGA.
- Python scripts and infrastructure supporting video tiling/detiling IP verification, SoC and subsystem stitching, and pad wrapper generation.
- RAM macro partitioning and wrapper generation tool in Python.
- In-house physical design flow monitoring tool: a web-based dashboard (PHP/MySQL) tracking synthesis and layout job progress. Allows full traceability of Synthesis and PnR jobs for QOR results, design size, logs and reports, and traces provenance of RTL and flow scripts back to the git commit they came from.
- Internal distributed video streaming platform to support SW validation efforts, with a Django-based web interface.
- Sphinx documentation infrastructure and template used across the hardware team.
- Championed the transition to GitLab to establish rigorous code review workflows for the SoC hardware design team, improving design quality across RTL, scripting, and verification.
- Set up and maintained the build servers that run the jobs dispatched by one of our software teams' CI/CD pipelines.
June 2017 - Dec. 2018
Leading DFT Engineer
Sondrel (England)
Leading DFT Engineer
Sondrel (England)
Following the acquisition of our team by Sondrel, I took more responsibilities by becoming the lead
of the ongoing DFT activities.
Technical lead of a +400 mm2 SoC in 16 nm :
ATE bring-up of a 4M DFF in 28 nm 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, providing easy access to scan insertion metrics for anyone and 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 16 nm :
- Leading a team of 3 DFT engineers, 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 high coverage and high 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 hybrid flow and the core wrapping techniques.
- Documenting the DFT architecture and specifying its implementation. With the help of my team of DFT engineers, we wrote and maintained general documents for the overall SoC, but also specific documents tailored to the specificity of each subsystem.
ATE bring-up of a 4M DFF in 28 nm SoC (ES and respin) :
- AMS tests development, and supported 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 were 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, providing easy access to scan insertion metrics for anyone and 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 at the end of 2016) :
DFT work on two new SoCs (both kicked off at the end of 2016) :
Methodology work :
DFT work on a first SoC (1000k DFF, tapped out at the 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 two new SoCs (both kicked off at the 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 two SoCs.
Methodology work :
- Development of a hierarchical MBIST insertion flow (Mentor Tessent Shell), at RTL level on VHDL and Verilog designs, 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 for 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 with 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 equipment (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 specify
the test requirements for our circuits, implement previously defined solutions, verify it after
being 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 also had to interact with other teams from different domains (Design, Synthesis/P&R, Timing analysis, Test Engineer, ...) and from other geographic sites with different time zones.
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 provides an easy and standardized way to communicate to the DUT (Device Under Test) through serial buses.
- I was in charge of the setup, maintenance and running of the 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) testbenches 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 also had to interact with other teams from different domains (Design, Synthesis/P&R, Timing analysis, Test Engineer, ...) and from other geographic sites with different time zones.
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 provides 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 another 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 a human-readable language that can be run on our FPGA platforms, on testers, and also can be re-simulated
- Thanks to that, test writing becomes 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 joined 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 semiconductor 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 15 mins instead of 1 hour) and made this process more reliable. I had to work closely with other teams 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 monitoring our test equipment.
My first main project was a tool to automatically setup semiconductor 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 15 mins instead of 1 hour) and made this process more reliable. I had to work closely with other teams 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 monitoring our test 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 graphs over weeks or months 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 measurements and write report analyses of the results. S parameters were measured on transistors and coils with different geometries. 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 into Excel and generating useful graphs. They agreed, so this became a side activity. I came up after a few months with something that generated the skeleton of the report with inside the main parts of the required graph. By using the tool, writing a report now takes 1 day instead of 2 without it.
The main activity was to do HF measurements and write report analyses of the results. S parameters were measured on transistors and coils with different geometries. 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 into Excel and generating useful graphs. They agreed, so this became a side activity. I came up after a few months with something that generated the skeleton of the report with inside the main parts of the required graph. By using the tool, writing a report now takes 1 day instead of 2 without it.