An FPGA-to-ASIC case study for refining smart meter design
Many embedded system designs are first implemented using FPGAs. This may be for quicker prototyping or to provide a platform for software development. Sometimes, the FPGAs will remain in the design after production begins. But usually, the plan is to convert the FPGA (or FPGAs) to an ASIC for volume manufacturing.
It is easy to think of this conversion as nearly automatic. Just recompile the verified FPGA RTL code using ASIC libraries, verify the resulting netlist, and send the files to a back-end design shop. But to get the best results, the process may not be that simple—especially if there is an opportunity to consolidate multiple chips into the ASIC or if mixed-signal functions are required.
Recently, Faraday Technology participated in such an FPGA-to-ASIC conversion project for a smart electric meter. The design illustrates many of the important nuances of the conversion process. And it shows the importance of finding the right conversion partner.
Smart meter design
At first glance, an electric meter is simple. It monitors the power-line voltage and current at the entry to the customer’s premises and records the cumulative energy delivered, usually in kW-hours in the United States. Traditionally, this task was done by a rather clever electric motor driving a mechanical counter.
But a smart meter is different. Eliminating the electromechanical moving parts, the smart meter samples the voltage and current and accumulates their product digitally. It also provides a means of remote reading, eliminating the human walking from house to house with a pencil and clipboard. In the design we are discussing, there are other features, such as cutting off power to the customer premises and reporting a fault to the network control center if the meter detects an abnormal voltage or current event.
Since most of the functionality of the smart meter is in the software, the hardware is relatively simple and mostly related to I/O (Figure 1). In the client’s prototype, the hardware included a host processor, an FPGA that acted as an I/O hub, various sensors, displays that are mostly connected through serial interfaces, and a subsystem for power-line communications (PLC) back to the network control center. The latter element turned out to be a vital part of the design.
Figure 1 The client’s initial design included an FPGA and an external host CPU. Achieving EMI and ESD compliance was a concern throughout the design. Source: Faraday Technology
The PLC interface requires a unique media access controller (MAC), physical-layer interface (PHY), and analog front-end (AFE). In the prototype design, all these functions were implemented in the FPGA. However, the PLC interface also required an external line driver and power-line coupler.
The main goal of the FPGA-to-ASIC conversion was to reduce cost, partly by eliminating some external components. However, the need to meet electrostatic discharge (ESD) and electromagnetic interference (EMI) immunity specifications for the challenging use environment—a real struggle for the FPGA-based AFE—also weighed heavily on the design team.
The conversion process
Far from being automatic, the FPGA-to-ASIC conversion process involved significant interaction between the design services company and the client. The result was an ARM-based, mixed-signal ASIC design that reduced the chip count (Figure 2).
Figure 2 The ASIC design included an internal CPU, elaborate multiplexing of external control signals, and the analog front-end for the power-line communications interface. Source: Faraday Technology
Faraday began by evaluating the smart-meter architecture. It was decided that in addition to implementing the FPGA’s existing functions as an I/O hub and PLC interface, the ASIC could also take on the functions of the host processor. This led to a reasonably conventional architecture based on an ARM Cortex-M4F CPU core, an AHB-Lite system bus, and an ARM peripheral bus.
The system bus connected interfaces to internal memory, plus major subsystems. That included a gigabit MAC, DMA controller, and, since data integrity and security are crucial to this application, a CRC controller and an AES crypto engine.
The plethora of I/O pins connect to the peripheral bus through multiplexing. The design included internal ROM and SRAM for the CPU, internal eFuses with their controller, plus interfaces for external SDRAM and serial flash.
Gathering IP
Faraday and the client worked together on selecting and configuring the ASIC IP. This allowed simply replacing many of the blocks in the FPGA with either Faraday, ARM, or third-party ASIC IP blocks. The remaining HDL logic was translated to the ASIC, and Faraday replaced the FPGA phase-locked loops, SRAM, and I/O instances with equivalent ASIC IP.
The PLC interface was vital to the conversion process, particularly integrating the analog front-end into the ASIC. This was a challenging analog design, as no off-the-shelf IP existed that could clearly meet the stringent ESD and EMI requirements. So, it was decided that a Faraday analog design team would create a new design for the block.
Faraday performed the final integration of the SoC and clock distribution and basic functional verification to ensure all the pieces worked correctly and talked to each other. The client did application-driven verification and software integration. Faraday then did the physical design and sign-off verification.
Once again, during verification, the PLC interface was a special case. The only way to ensure ESD/EMI compliance was to put a physical chip on a test bench. Rather than gamble on an entire production run, it was decided to do a test chip of the AFE and put it on a shuttle run for a quick fab turn-around.
Faraday and the client agreed that if the test chip passed compliance tests, the client would pay for the test chip. Faraday would correct the design if it failed and provide a free shuttle for the corrected test chip. Nevertheless, the initial test chip passed, greatly relieving the client.
A full-fledged collaboration
Faraday now supplies the finished, assembled, and tested SoC to the client in volume.
This smart-meter design illustrates that FPGA-to-ASIC conversion is not a push-button process or a send-files-and-forget contract relationship. Especially when there are unique functional blocks, special electrical requirements, or the opportunity to consolidate multiple chips into one ASIC, the process becomes a close collaboration between the client and the design services company.
The first step toward success is to carefully evaluate the design service company’s technology, IP access, experience, and willingness to work one-on-one with the client design team. Each of these factors will contribute to the outcome of the relationship, as it did with this smart meter.
Barry Lai heads the System Development and Chip Design Department at Faraday Technology, an ASIC design service and IP provider.
Related Content
FPGA-to-ASIC conversion a crucial concern
FPGA-ASIC conversion: Is automatic an option?
FPGA-prototyping and ASIC-conversion considerations
Addressing the challenges of smart utility meter design
How smart is it to deploy smart meters on the smart grid?
googletag.cmd.push(function() { googletag.display(‘div-gpt-ad-native’); });
–>
The post An FPGA-to-ASIC case study for refining smart meter design appeared first on EDN.


