Contact Info

Level 30, Singapore Land Tower, 50 Raffles Place, Singapore

Email :

Solid State Device Test Automation

We build solution and system integration for Solid State Devices Test Automation process and Test Script, Driver improvements. We have helped semiconductor, and solid-state disk drive manufacturers on their test process improvement and related automation. Looking at the drivers, scripts and the hardware used, we try incorporate changes to their test process by improving speed of the testing also improve the process.

Solid-state drives (SSDs) are commonly used in client, hyperscale and enterprise compute environments. They typically come in three flavors: NVMe™, SAS, and SATA. Since SSDs are made from flash memory, they can be built in many different form factors. This resource guide is designed to provide information on the most common and current SSDs in their various form factors. In addition to the form factor dimensions, information such as use case, interface, protocol, and mechanical/electrical and connector specifications are provided.

  • M.2
  • 2.5-inch (U.2)
  • Add In Cards

There are various interfaces in the test process where drives are interfaced and tested. EDSFF stands for Enterprise and Data center Standard Form Factor. The family of specifications were developed by a group of 15 companies working together to address the concerns of data center storage, and are now maintained by SNIA.

EDSFF offers a dynamic range of form factors that have advantages vs the incumbent SSD form factors in capacity, scalability, performance, serviceability, manageability, thermal and power management. Today all the EDSFF family of form factors share the same protocol (NVMe), the same interface (PCIe® ), the same edge connector (SFF-TA-1002), the same pinout and functions (SFF-TA-1009). Infrastructure, especially test infrastructure, can be developed to support multiple EDSFF form factors.

Where Used

  • The primary usage is SSDs, but E3 is big enough to accommodate a broader range of device types.
  • The E3 form factor allows for x4, x8, or x16 PCIe host interface.

M.2 is a form factor specification for internally mounted SSDs. Formerly known as Next Generation Form Factor (NGFF), M.2 supports PCIe, SATA and USB interfaces and comes in various widths and lengths. It also has keying notches on the edge connector to designate various interface or PCIe lane configurations. M.2 is smaller than the typical 2.5” form factor SSD and is typically removable, except Type 1620 (BGA), which offers a ball grid array chip package and it typically mounted on the main system board.

The 2.5-inch form factor (U.2) is the most common deployment of an SSD, and is offered with PCIe (with NVMe), SAS or SATA interfaces. It is typically used in desktops, servers and storage systems built around hard disk drives (HDD). This form factor is commonly associated with the term U.2 and is sometimes referred to as the U.2 form factor. U.2 is defined as compliance with the PCI Express SFF-8639 Module specification, and no longer typically references SAS or SATA SSDs.

We develop Verification and Silicon IP’s and Verification IP’s where when solution is developed using FPGA or SOC, our IP’s can be used to develop the Interface boards or testing of systems.

Verification IP (VIP) (A pre-packaged set of code used for verification)

Verification IP (VIP) is a pre-packaged set of code used for verification. It may be a set of assertions for verifying a bus protocol, or it could be a module intended to be used within a defined verification methodology, such as UVM. This would often contain stimulus sequences, bus functional models, a set of checkers, coverage model and other things associated with a particular block in the design, such as a USB interface.

The main engine inside verification IP is the transactor model — sometimes called masters and slaves, sometimes just called VIPs, and in some flows called agents — that are the elements that can get told by a UVM, or whatever approach is being used, to write the test vectors.

VIP emerged as a form of reusable IP, which can be used to create the tests needed to shorten SoC verification time and increase coverage. While it is often used to verify standard bus protocols, it also can be used for system performance analysis and is increasingly being used with emulation, simulation, and virtual prototyping. For example, VIP can be used with emulation for simulation acceleration and APIs. The simulation acceleration side uses emulation to run faster with a UVM test environment, very similar to the verification IP used with UVM, but not targeted to run on an emulator.

Some of the verification IP’s that we have developed are as below:


In today’s era of IC designs more and more system functionality are getting integrated into single chips (System on Chip /SOC designs). In these SOC designs, these pre-designed IP cores/blocks are becoming more and more important. This is because most of the SOC designs have a standard microprocessor and lot of system functionality which are standardized and hence if designed once can be re-used across several designs.

Refer following diagram (Reference wikipedia) and you can see that a lot of the components are standardized protocols and designs – eg the ARM bus protocols like AHB, APB, the designs like Ethernet, SPI, USB , UART core etc. All of these can be designed stand alone as IP cores/blocks and can be licenced to multiple design houses and for different designs.

Find the Solution That Best Fits Your Business