CWE - CWE-1461: Hardware Simulation / Synthesis Mismatch (5.0)

Weakness ID: 1461

Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

View customized information:

Shows the description and diagram, platforms, mitigations, consequences, relationships, memberships, and content history. For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.

Description

The hardware design contains structures that are interpreted differently during synthesis than during simulation, which cause inconsistencies in security-relevant behavior between the synthesized implementation and the simulation.

Extended Description

Hardware-description-language (HDL) code describes functionality which can be verified as correct using simulation tools. Synthesis tools then (automatically) convert this into a physically-realizable representation. Certain HDL code structures cannot be exactly represented, or have multiple valid representations from which the synthesis tool must choose. This can result in output which behaves differently to the (functionally-correct) HDL code. These "simulation/synthesis mismatches" may have security consequences.

Common Consequences

This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Impact	Details
Varies by Context	Scope: Other The consequences depend on the affected hardware behavior. The synthesized implementation may make different control decisions, incorrectly update protected state, expose data, or fail to enforce restrictions that appeared to operate correctly during HDL simulation.

Potential Mitigations

Phase(s)

Mitigation

Implementation & Physical Design (Hardware)

Establish and enforce HDL coding and review practices that minimize differences between simulation semantics and synthesis interpretation. Avoid HDL constructs, synthesis directives, and tool-dependent behaviors known to cause simulation/synthesis mismatch, with particular attention to security-relevant logic.

Effectiveness: High

Note:

Avoidance of the patterns of code which can result in these errors removes the opportunity for error. However, in some cases (notably state machine encodings) this can be very difficult to achieve efficiently.

Implementation & Physical Design (Hardware)

For security-critical logic, preserve intentional redundancy that is required for security. Examples may include redundant logic, triple modular redundancy (TMR) structures, Hamming-distance state encodings, or state-machine recovery logic. Use synthesis constraints, preservation attributes, carefully controlled structural implementation, or manual implementation of selected critical blocks to prevent this redundancy from being merged, re-encoded, or optimized away.

Effectiveness: High

Note:

This mitigation removes the structures which cause the problem, at the expense of additional design and verification effort, and additional risk of inclusion of other functional errors.

Relationships

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf, Overlaps, and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

	Nature	Type	ID	Name
Relevant to the view "Complete Weakness Hierarchy" (View-1000)
	ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	435	Improper Interaction Between Multiple Correctly-Behaving Entities

Relevant to the view "Hardware Design" (View-1194)
	Nature	Type	ID	Name
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1199	General Circuit and Logic Design Concerns
	MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1208	Cross-Cutting Problems

Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase(s)	Note
Implementation & Physical Design (Hardware)	This weakness can be introduced when HDL constructs, assignment ordering, synthesis directives, or tool-dependent semantics are used whose simulation behavior may not match synthesis interpretation. These constructs may behave correctly during HDL simulation but produce different security-relevant behavior in the synthesized implementation.
Implementation & Physical Design (Hardware)	This weakness can be introduced or exposed during synthesis when the synthesis tool applies assumptions, optimizations, or transformations to HDL structures that cannot be physically implemented exactly as the simulation semantics dictate, or that permit multiple (valid) hardware implementations. The resulting netlist may behave differently from the model that was verified during simulation.

Applicable Platforms

This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Type	Applicable Platforms	Notes
Languages	Verilog (Undetermined Prevalence) VHDL (Undetermined Prevalence) Class: Hardware Description Language (Undetermined Prevalence)
Architectures	Class: Not Architecture-Specific (Undetermined Prevalence)
Technologies	Class: System on Chip (Undetermined Prevalence)

Demonstrative Examples

Example 1

A hardware designer implements an access control latch which takes in lock and unlock signals (which are only active for a single cycle) and a reset signal, and outputs an unlocked state signal. During operation, the unlocked signal is synchronously set high by the unlock input and set low by the lock input. The unlocked signal also intended to be low from startup and set low by reset.

(bad code)

Example Language: Verilog

			module lock_control (

			  input  wire clk,

			  input  wire reset,

			  input  wire lock,

			  input  wire unlock,

			  output reg  unlocked

			);

			  reg unlocked_next = 1'b0;

			  always @(lock or unlock or unlocked) begin

				if (reset == 1'b1) begin

				  unlocked_next = 1'b1; 

				end else if (lock == 1'b1) begin

				  unlocked_next = 1'b0; 

				end else if (unlock == 1'b1) begin

				  unlocked_next = 1'b1; 

				end else begin

				  unlocked_next = unlocked; 

				end

			  end

			  always @(posedge clk) begin

				unlocked <= unlocked_next;

			  end

			endmodule

The following VHDL example is written for VHDL-93 or later.

(bad code)

Example Language: VHDL

			library ieee;

			use ieee.std_logic_1164.all;

			entity lock_control is

			  port (

				clk      : in  std_logic;

				reset    : in  std_logic;

				lock     : in  std_logic;

				unlock   : in  std_logic;

				unlocked : out std_logic

			  );

			end entity lock_control;

			architecture behavioral of lock_control is

			  signal unlocked_reg  : std_logic:=’0’;

			  signal unlocked_next : std_logic;

			begin

			  process(lock, unlock, unlocked_reg)

			  begin

				if reset = '1' then

                  unlocked_next <= '1';

				elsif lock = '1' then

                  unlocked_next <= '0';

				elsif unlock = '1' then

                  unlocked_next <= '1';

				else

                  unlocked_next <= unlocked_reg;

				end if;

			  end process;

			  process(clk)

			  begin

				if rising_edge(clk) then

                  unlocked_reg <= unlocked_next;

				end if;

			  end process;

			  unlocked <= unlocked_reg;

			end architecture behavioral;

The always block is intended to describe combinational logic for unlocked_next, which depends on four signals (lock, unlock, unlocked and reset). However, the sensitivity list is missing reset.

During pre-synthesis RTL simulation, this tells the simulator not to rerun the block when reset changes (only when the other signals change). The signal unlocked_next defaults to 1’b0 so the simulation sees the expected locked state and so the tests of the state after reset will pass.

Synthesis tools assume a complete sensitivity list and will therefore infer logic including the reset signal. When reset is high, the unlocked _next signal is (erroneously) set to 1’b1. This is a bug (as reset should force a non-unlocked state), which would be expected to be found in simulation. The design uses a two-process state machine style which masks this bug in the code during simulation, but allows it to propagate to the synthesized implementation.

The synthesized hardware exits reset in an insecure state (with unlocked set to 1’b1) and remains in that state until one of the lock/unlock signals changes state. An adversary can take advantage of this by exploiting whatever logic makes use of this signal to set itself to a secure state.

(good code)

Example Language: Algorithm

			For combinational logic, ensure that simulation is
			triggered by every signal read by the block. This can be
			done by listing both inputs explicitly, but this is not
			recommended.
			

			A safer and more maintainable approach is to use (in
			Verilog) always @*, which tells the simulator to include
			all signals used inside the block. In SystemVerilog, use
			always_comb. In VHDL use process(all).
			

Example 2

A hardware developer is debugging logic which requires the system to be in an unprotected mode. In order to enable their work, they have (temporarily) removed some code related to the "protected_mode_enabled" flag in a way that does not cause the simulations to fail.

(bad code)

Example Language: VHDL

                                
			-- The following VHDL example is written for VHDL-93 or later.

			signal secure     : boolean; -- implicitly initialized to ‘false’

			signal policy_ok  : boolean;

			signal lock_ready : boolean;

			...

			-- synthesis translate_off

			secure <= security_check(policy_ok, lock_ready); -- TODO: restore this after debugging

			-- synthesis translate_on

			protected_mode_enabled <= secure;

(bad code)

Example Language: Verilog

			reg secure; 

			wire policy_ok;

			wire lock_ready;

			wire protected_mode_enabled;

			...

			always @(*) begin

			  secure = 1'b0; // default value

			  // synopsys translate_off

			  secure = security_check(policy_ok, lock_ready); // TODO: restore this after debugging

			  // synopsys translate_on

			end

			assign protected_mode_enabled = secure;

The design assigns the security-relevant secure signal using logic that is hidden from synthesis by translate_off / translate_on or equivalent synthesis exclusion directives. Simulation tools treat these directives as comments and include the enclosed assignment, so simulation updates secure according to security_check(policy_ok, lock_ready) and appears to validate the intended protected-mode behavior.

Synthesis tools omit the code between the exclusion directives. The synthesized implementation therefore does not contain the same assignment that was exercised during simulation. This creates a simulation/synthesis mismatch in security-relevant behavior: the HDL model used for verification enables or disables protected mode using logic that is absent from the synthesized hardware.

Because the synthesized implementation does not include the same logic that was present during simulation, the hardware defaults to an insecure state. An attacker can take advantage of this to execute activities which would normally require some form of authorization, even though simulation results suggested that protected mode would be enforced.

(good code)

Example Language: Algorithm

		  Do not place security-relevant assignments inside
		  synthesis-excluded regions. Any logic that affects
		  protected-mode behavior should be represented consistently
		  in both simulation and synthesis.
		  

		  Limit synthesis translate_off / translate_on regions to
		  simulation-only code that cannot assign, modify, override,
		  or mask security-sensitive signals.
		  

		  Carefully review all uses of translate_on/off directives.
		  Ensure that developers can efficiently authorize their
		  activities during development work, to avoid the temptation
		  to bypass security features in this way.
		  

(good code)

Example Language: VHDL

                                
		  -- The following VHDL example is written for VHDL-93 or later.

		  signal secure     : boolean; -- implicitly initialized to ‘false’

		  signal policy_ok  : boolean;

		  signal lock_ready : boolean;

		  ...

		  secure <= security_check(policy_ok, lock_ready);

		  protected_mode_enabled <= secure;

(good code)

Example Language: Verilog

		  reg secure;

		  wire policy_ok;

		  wire lock_ready;

		  wire protected_mode_enabled;

		  ...

		  always @(*) begin

			secure = security_check(policy_ok, lock_ready);

		  end

		  assign protected_mode_enabled = secure;

Example 3

A hardware developer is designing a controller that manages whether protected configuration registers can be written. The controller includes states for reset handling, user-level operation, and privileged operation.

(bad code)

Example Language: VHDL

		  -- The following VHDL example is written for VHDL-93 or later.

		  type t_priv_state is (RESET, USER_ONLY, PRIVILEGED);

		  signal priv_state       : t_priv_state := RESET;

		  signal auth_passed      : boolean := false;

		  signal privilege_revoke : boolean := false;

		  ...

		  process(clk, reset_n)

		  begin

			if reset_n = '0' then

			  priv_state <= RESET;

			elsif rising_edge(clk) then

			  case priv_state is

				when RESET =>

				  priv_state <= USER_ONLY;

				when USER_ONLY =>

				  if auth_passed then

					priv_state <= PRIVILEGED;

				  end if;

				when PRIVILEGED =>

				  if privilege_revoke then

					priv_state <= USER_ONLY;

				  end if;

				when others =>

				  priv_state <= USER_ONLY; -- intended recovery for unexpected encodings

				end case;

			  end if;

			end process;

			protected_cfg_write_en <= (priv_state = PRIVILEGED);

(bad code)

Example Language: Verilog

			localparam RESET      = 2'b00;

			localparam USER_ONLY  = 2'b01;

			localparam PRIVILEGED = 2'b10;

			reg [1:0] priv_state    = RESET;

			wire      auth_passed;       // Implicitly 1-bit (boolean equivalent)

			wire      privilege_revoke;  // Implicitly 1-bit (boolean equivalent)

			wire      clk;

			wire      reset_n;

			wire      protected_cfg_write_en;

			...

			always @(posedge clk or negedge reset_n) begin

			  if (!reset_n) begin

				priv_state <= RESET;

			  end else begin

				case (priv_state)

				  RESET: begin

					priv_state <= USER_ONLY;

				  end

				  USER_ONLY: begin

					if (auth_passed) begin

                      priv_state <= PRIVILEGED;

					end

				  end

				  PRIVILEGED: begin

					if (privilege_revoke) begin

                      priv_state <= USER_ONLY;

					end

				  end

				  default: begin

					priv_state <= USER_ONLY; // intended recovery for unexpected encodings

				  end

				endcase

			  end

			end

			assign protected_cfg_write_en = (priv_state == PRIVILEGED);

The design relies on a VHDL others choice or Verilog default branch to express recovery behavior for state values not explicitly listed in the state transition logic. In RTL simulation, the intended behavior is that unexpected controller states will transition to USER_ONLY, where protected configuration writes are blocked.

The error is assuming that this RTL-level recovery behavior will necessarily be preserved after synthesis. During synthesis, the state machine may be encoded, optimized, or transformed based on the states considered reachable during normal operation. As a result, logic associated with unused or faulty hardware encodings may be removed or altered, and the synthesized implementation may not preserve the same recovery behavior that appeared in RTL simulation.

If the synthesized implementation does not preserve the unexpected-state recovery behavior, the hardware may fail to return to USER_ONLY after a fault, reset anomaly, voltage glitch, clock disturbance, or other condition that places the state storage into an unintended encoding.

An attacker who can induce or influence such conditions may be able to leave protected configuration writes enabled, or cause them to become enabled, even though simulation suggested that unexpected state values would be forced into a state where those writes are blocked.

(good code)

Example Language: Algorithm

			  Do not rely on a VHDL others choice or Verilog default
			  branch to guarantee post-synthesis recovery behavior for
			  security-critical state machines. If recovery from
			  unexpected state encodings affects access to protected
			  configuration registers, the implementation should not
			  depend on synthesis inferring and preserving that
			  behavior from RTL alone.
			

			  For this type of security-critical controller, implement
			  the state machine using a carefully-controlled
			  structural or hand-synthesized representation where the
			  relevant state elements, reset behavior, transition
			  logic, and fail-closed recovery behavior are
			  explicit. Be careful that the synthesiser does not infer
			  a state machine from the crafted logic, and “undo” the
			  work. Review the resulting gate-level or structural
			  implementation to confirm that unintended encodings are
			  handled as required.

			  Perform post-synthesis simulations where faults are
			  injected into the state registers and confirm the
			  behavior.

			  Perform formal analysis to prove that the behavior of
			  these critical blocks has not been altered by the
			  synthesis process.

			  After the implementation is verified and validated,
			  preserve it during integration so later synthesis or
			  whole-design optimization does not re-encode, merge,
			  remove, or otherwise transform the security-critical
			  recovery logic.

			  This approach is costly and design-specific, but it is
			  appropriate when relying on ordinary RTL synthesis would
			  create unacceptable security risk.
			

Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference	Description
CVE-2025-51678	The synthesized netlist incorrectly calculates memory addresses and fetches co-processor instructions, potentially causing unintended memory accesses or incorrect custom-instruction execution.
CVE-2025-51677	Debug-load requests should return complete load store unit (LSU) data, but the synthesized netlist returned incomplete data, potentially causing incorrect interpretation of memory state.
CVE-2025-51679	Instruction execution should update program-counter state correctly, but the synthesized netlist produced incomplete or undefined updates, potentially causing unintended control flow.
CVE-2025-51675	The program counter should update when the next-program-counter value changes, but the synthesized netlist allowed stale PC state, potentially causing incorrect instruction fetches or stalls.

Weakness Ordinalities

Ordinality	Description
Resultant	(where the weakness is typically related to the presence of some other weaknesses) This is a resultant weakness as the primary would be something like bad RTL coding practices or Synthesis optimization that then would result in a mismatch.

Detection Methods

Method	Details
Automated Static Analysis - Source Code	HDL linting, rule-based static analysis, and HDL checker tools can examine source code for structures that may be interpreted differently by simulation and synthesis tools. They may identify synthesis-sensitive coding patterns associated with this weakness. Effectiveness: Moderate Note: This method can be useful for detecting potential coding issues, but it may not reveal whether these constructs result in observable behavioral divergence after synthesis. Moreover, a user may suppress or bypass these warnings and still produce the erroneous synthesized hardware implementation. This method can give false positives.
Manual Analysis	Synthesis warning review can examine synthesis logs and reports for tool messages associated with possible simulation/synthesis mismatch. It may identify ignored constructs, unsupported HDL semantics, synthesis assumptions, or optimizations that could affect security-relevant behavior. Effectiveness: Limited Note: Can reveal potential synthesis issues but relies on engineers interpreting warnings. Moreover, a user may suppress or bypass these warnings and still produce the erroneous synthesized hardware implementation.
Formal Verification	HDL-source-to-netlist formal equivalence checking can examine the simulated model and synthesized netlist for behavioral mismatch associated with this weakness. It may identify non-equivalent outputs, failed compare-points, state-mapping issues, or counterexamples under the checked constraints. Effectiveness: High Note: Formal equivalence checking can be effective at the IP level for identifying mismatches between the source-code model and synthesized implementation. However, effectiveness may decrease as design complexity grows, particularly at the SoC level, due to state-space expansion and difficulty mapping non-equivalent points. Synthesis optimizations may merge, eliminate, or rename signals, which can also produce false positives or require additional setup to account for expected transformations.
Simulation / Emulation	Cross-simulation across HDL-source and post-synthesis models can examine both abstraction levels for observable behavioral divergence associated with this weakness. It may identify mismatches when security-relevant behaviors are explicitly exercised. Effectiveness: High Note: This method can be useful for detecting observable behavioral mismatches, but it may not exercise all execution scenarios and should be combined with other detection methods to improve coverage.
Fuzzing	Coverage-guided differential fuzzing can examine HDL source code and synthesized implementation models for behavioral divergence associated with this weakness. It may identify generated inputs or state conditions that expose synthesis-induced mismatches. Effectiveness: High Note: This method can be useful for detecting previously unknown synthesis-induced behavioral mismatches by exploring diverse execution paths through coverage-guided input generation. However, it may not exercise every reachable design state and should be combined with other detection methods to improve coverage.

Memberships

This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Nature	Type	ID	Name
MemberOf	Grouping - a CWE entry that contains a set of other entries that share a common characteristic.	1398	Comprehensive Categorization: Component Interaction

Vulnerability Mapping Notes

Usage	ALLOWED-WITH-REVIEW (this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reasons	Frequently-Resultant, Acceptable-Use
Rationale	This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comments	Since this entry is often resultant, there might be other CWEs that are more appropriate as the root cause, although there might be some gaps. Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

References

[REF-1552]	Don Mills and Clifford E. Cummings. "RTL Coding Styles That Yield Simulation and Synthesis Mismatches". 1999. <https://www.researchgate.net/profile/Clifford-Cummings/publication/228554783_RTL_Coding_Styles_That_Yield_Simulation_and_Synthesis_Mismatches/links/54bfe9760cf21674ce9ca726/RTL-Coding-Styles-That-Yield-Simulation-and-Synthesis-Mismatches.pdf>.
[REF-1553]	Raghul Saravanan, Sudipta Paria, Aritra Dasgupta, Venkat Nitin Patnala, Swarup Bhunia and Sai Manoj P. D.. "SynFuzz: Leveraging Fuzzing of Netlist to Detect Synthesis Bugs". 2025-04-26. <https://arxiv.org/abs/2504.18812>.
[REF-1554]	Mike Turpin. "The Dangers of Living with an X (bugs hidden in your Verilog)". 2003-10-14. <https://developer.arm.com/documentation/arp0009/a/?lang=en>.
[REF-1555]	Stuart Sutherland and Don Mills. "Standard Gotchas: Subtleties in the Verilog and SystemVerilog Standards That Every Engineer Should Know". 2006. <https://sutherland-hdl.com/papers/2006-SNUG-Boston_standard_gotchas_paper.pdf>.
[REF-1556]	Flavien Solt and Kaveh Razavi. "Lost in Translation: Enabling Confused Deputy Attacks on EDA Software with TransFuzz". 2025-08. <https://www.usenix.org/conference/usenixsecurity25/presentation/solt>. (URL validated: 2026-10-19) Media types: Common-Proprietary-Text; Video
[REF-1557]	Don Mills. "Yet Another Latch and Gotchas Paper". 2012. <https://lcdm-eng.com/papers/snug12_Paper_final.pdf>.
[REF-1558]	Clifford E. Cummings. "“full_case parallel_case”, the Evil Twins of Verilog Synthesis". 1999. <https://csg.csail.mit.edu/6.375/6_375_2009_www/papers/cummings-case-snug99.pdf>.

Content History

Submissions
Submission Date	Submitter	Organization
2025-05-20 (CWE 5.0, 2026-10-28)	Raghul Saravanan	George Mason University
2025-05-20 (CWE 5.0, 2026-10-28)
2025-05-20 (CWE 5.0, 2026-10-28)	Sudipta Paria	University of Florida
2025-05-20 (CWE 5.0, 2026-10-28)
Contributions
Contribution Date	Contributor	Organization
2026-03-30 (CWE 5.0, 2026-10-28)	CWE Ad Hoc RTL WG
2026-03-30 (CWE 5.0, 2026-10-28)	Participated in a series of meetings betwee March 2026 and September 26, in which members contributed significant feedback related to this entry as it evolved before publication in CWE 5.0.
2026-03-30 (CWE 5.0, 2026-10-28)	MITRE
2026-03-30 (CWE 5.0, 2026-10-28)	Guided evolution of the name and description for this entry, followed by suggestions for mitigations, demonstrative examples, and detection methods. Note: some content development was AI-assisted, with expert review and editing by MITRE and members of the CWE Ad Hoc RTL WG.


	Site Map \| Terms of Use \| Manage Cookies \| Cookie Notice \| Privacy Policy \| Contact Us \| Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2026, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.

Common Weakness Enumeration

CWE-1461: Hardware Simulation / Synthesis Mismatch

Edit Custom Filter