> Markdown version of [/jobs/ext/4011732-hardware-engineer-performance-modeling](https://www.wearedevelopers.com/jobs/ext/4011732-hardware-engineer-performance-modeling). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Hardware Engineer, Performance Modeling

- **Company:** Normal Computing
- **Location:** Mountain View, CA, United States
- **Experience:** Expert
- **Contract:** Permanent contract
- **Skills:** Artificial Intelligence, C++ (Programming Language), Computer Programming, Computer Engineering, Field-Programmable Gate Array (FPGA), Hardware Design, Python (Programming Language), SystemC, Network Switches, Application Specific Integrated Circuits, Large Language Models, Low Latency, Cacti, Physical Design, Model Inference
- **Published:** October 29, 2026
- **Apply:** https://www.careerbuilder.com/job-details/hardware-engineer-performance-modeling-mountain-view-ca--80a8e222-9a44-48b4-a990-c24e3ad943fb

## About the Role

Computer Engineering, Performance Modeling, Artificial Intelligence (AI), Semiconductors, Problem Solving Skills, ASIC (Application Specific Integrated Circuit), Physics, Performance Modeling, Prototyping, Kernel Programming, * 5+ years of experience in performance modeling at a major semiconductor company

 * Demonstrated proficiency in understanding architectures and transforming that to performant modeling code
 * Use of various modeling techniques and languages
 * Excellent written and spoken communication skills

Bonus Points

 * Experience with AI acceleration hardware
 * Experience with architecture-level modeling and cost tools such as AccelForge, Timeloop/Accelergy, CACTI, McPAT, or gem5
 * Experience with DV methodology
 * Hands-on use of LLMs or agentic tools in development workflows
 * Exposure to analog, mixed-signal, or unconventional compute
 * Experience with memory interfaces (LPDDR, HBM, DDR) and other I/O

## Description

As a Performance Modeling Engineer at Normal, you will build the transaction-level model (TLM) of our physics-inspired ASICs. It is the model that sits between RTL and the rest of our modeling stack, and that both our architects and our verification team rely on.

You will own the path from RTL to the numerical performance results. You will correlate the TLM against RTL, FPGA prototypes, and synthesis results, then turn it into calibrated latency, bandwidth and energy parameters for kernel-level models. You will work closely with the architecture, hardware design and DV teams, using their feedback to help refine our end-to-end system.

The through-line is your modeling expertise, applied to an architecture that computes differently from anything you have modeled before, and to the AI that is changing how AI workloads get done. This is a seat for a performance modeling engineer who wants their craft to compound rather than repeat. Ultimately Normal Computing will build a next generation system with 100-1000× improvement in AI inference, and your work will make this possible., * Transaction-Level Model: Build and maintain a cycle-accurate approximate TLM of our compute tiles, memory hierarchy, and interconnect in an appropriate language (SystemC, C++ or Python). The code must be fast enough to simulate real workloads and accurate enough to make production design decisions

 * Feeding the Modeling Stack: Translate TLM and RTL results combined with physical design into calibrated parameters (latency, bandwidth, energy, utilization, occupancy, etc.) to enable end-to-end system level performance prediction on AI workloads
 * Verification Reference: Provide the TLM as a reference "golden model" for DV, including transaction level scoreboards and performance checks and work with the DV and RTL team to ensure RTL produces the desired end-target behavior so that the TLM reflects the RTL and the RTL reflects the TLM.
 * Planning and Performance Feedback: Plan modeling work against the hardware roadmap and run sensitivity studies on key hardware parameters (buffer sizes, interface widths, scheduling policies, and bus configurations) to turn results into clear recommendations for the architecture and hardware teams