Namaste FPGA Technologies

Most common valid signal SV assertion checks for AXI DUTs. AXI is one of the bus protocols that everyone encounters at some point in their learning journey. Let us analyze the most common assertion checks related to the VALID signal that are included in almost all AXI DUTs. The first check ensures that all data and control signals have known values when VALID is asserted. We can use $isunknown to make sure all signals are valid whenever VALID is high. Instead of using individual $isunknown calls for each signal, we can concatenate all relevant signals into a single vector and check that none of its bits are unknown. This check is performed only when VALID is asserted, so VALID acts as the antecedent. We begin checking in the same clock tick using an overlapping implication operator (|->): aw_valid |-> !$isunknown({aw_addr, aw_id, aw_len, aw_size, aw_burst}); The second rule ensures that all control and data signals remain stable when VALID is high and READY has not yet been asserted by the slave. Again, we concatenate all signals inside $stable to confirm that the concatenated vector value remains unchanged compared to the previous clock tick. The antecedent checks that VALID is high while READY is low; once that evaluates to true, we need to verify that values stay stable using $stable. Since $stable compares values across two clock cycles, we use a non-overlapping implication operator (|=>) so that the check starts on the next clock tick. This guarantees that control and data signals stay constant while VALID is asserted and READY is low. aw_valid && !aw_ready |=> $stable({aw_addr, aw_len, aw_size, aw_burst}); The third rule ensures that VALID is not withdrawn abruptly in the middle of a handshake. Once VALID is asserted, it must remain high until READY is asserted. Deasserting VALID before READY is a protocol violation. The antecedent is when VALID is high and READY is low, and we ensure that VALID remains high in the next clock tick. aw_valid && !aw_ready |=> aw_valid; The fourth rule ensures that VALID remains deasserted while reset is active. Reset acts as the antecedent, and we perform the check in the same clock cycle to verify that VALID stays low when reset is asserted. !rst_n |-> !valid; Learn more about fundamentals of SV assertions from scratch here : https://lnkd.in/gm8r7eXh

Most common valid signal SV assertion checks for AXI DUTs. AXI is one of the bus protocols that everyone encounters at some point in their learning journey. Let us analyze the most common assertion checks related to the VALID signal that are included in almost all AXI DUTs. The first check ensures that all data and control signals have known values when VALID is asserted. We can use $isunknown to make sure all signals are valid whenever VALID is high. Instead of using individual $isunknown calls for each signal, we can concatenate all relevant signals into a single vector and check that none of its bits are unknown. This check is performed only when VALID is asserted, so VALID acts as the antecedent. We begin checking in the same clock tick using an overlapping implication operator (|->): aw_valid |-> !$isunknown({aw_addr, aw_id, aw_len, aw_size, aw_burst}); The second rule ensures that all control and data signals remain stable when VALID is high and READY has not yet been asserted by the slave. Again, we concatenate all signals inside $stable to confirm that the concatenated vector value remains unchanged compared to the previous clock tick. The antecedent checks that VALID is high while READY is low; once that evaluates to true, we need to verify that values stay stable using $stable. Since $stable compares values across two clock cycles, we use a non-overlapping implication operator (|=>) so that the check starts on the next clock tick. This guarantees that control and data signals stay constant while VALID is asserted and READY is low. aw_valid && !aw_ready |=> $stable({aw_addr, aw_len, aw_size, aw_burst}); The third rule ensures that VALID is not withdrawn abruptly in the middle of a handshake. Once VALID is asserted, it must remain high until READY is asserted. Deasserting VALID before READY is a protocol violation. The antecedent is when VALID is high and READY is low, and we ensure that VALID remains high in the next clock tick. aw_valid && !aw_ready |=> aw_valid; The fourth rule ensures that VALID remains deasserted while reset is active. Reset acts as the antecedent, and we perform the check in the same clock cycle to verify that VALID stays low when reset is asserted. !rst_n |-> !valid; Learn more about fundamentals of SV assertions from scratch here : https://lnkd.in/gm8r7eXh

Evolution of FSM coding styles over years in Verilog Over the years, numerous styles of FSMs have been developed, each offering unique advantages and reflecting the essence of design engineering when working on complex scenarios. One such style involves adding default values to all variables outside the case statement. This approach is based on the principle that we should only assign new values when required in a specific state; otherwise, the variables will retain their default values. Another popular style of writing FSMs updates variables uniquely within each state, but this method is prone to latch inference if any variable is missed in a particular state. In FSM design, we are mainly concerned with covering all possible states, which is generally handled by including all valid states along with a default state behavior. In cases where multiple paths exist within a single state—built using if-else or nested case blocks—failing to cover all paths can also lead to unintended latches. Therefore, when using an FSM style that requires assigning values to all variables, it is essential to include all possible paths. By adding default values to all variables before entering the case statement, we can focus only on the signals that need to change while the rest automatically retain their defaults. This approach keeps the FSM safe from both issues: missing states and missing signal assignments within states. For this reason, most modern designs have started adopting this practice. So, the next time you design your own FSM, follow this approach to eliminate the possibility of the two most common FSM errors. Learn more about essential Verilog practices for synthesizable RTL from scratch here: https://lnkd.in/d5AAPFYj

Evolution of FSM coding styles over years in Verilog Over the years, numerous styles of FSMs have been developed, each offering unique advantages and reflecting the essence of design engineering when working on complex scenarios. One such style involves adding default values to all variables outside the case statement. This approach is based on the principle that we should only assign new values when required in a specific state; otherwise, the variables will retain their default values. Another popular style of writing FSMs updates variables uniquely within each state, but this method is prone to latch inference if any variable is missed in a particular state. In FSM design, we are mainly concerned with covering all possible states, which is generally handled by including all valid states along with a default state behavior. In cases where multiple paths exist within a single state—built using if-else or nested case blocks—failing to cover all paths can also lead to unintended latches. Therefore, when using an FSM style that requires assigning values to all variables, it is essential to include all possible paths. By adding default values to all variables before entering the case statement, we can focus only on the signals that need to change while the rest automatically retain their defaults. This approach keeps the FSM safe from both issues: missing states and missing signal assignments within states. For this reason, most modern designs have started adopting this practice. So, the next time you design your own FSM, follow this approach to eliminate the possibility of the two most common FSM errors. Learn more about essential Verilog practices for synthesizable RTL from scratch here: https://lnkd.in/d5AAPFYj

Choosing the Right STA Violation Correction Technique for FPGAs: Small, Medium, and Large Fixes Explained Numerous violation correction techniques have been discovered over time, each suited to specific requirements. Let us go over a simple cheat sheet that helps decide which technique to use under different situations. Violation correction techniques can be classified into three categories: small violations, medium violations, and large violations. A violation of less than 1 ns can be considered small, a medium violation occurs when the range is between 1 ns and 3 ns, and a large violation is anything above 3 ns. Small violations are usually corrected with inbuilt tool strategies or simple manual techniques. Medium violations require more aggressive strategies, while large violations often need structural changes. This also means that small violations can be corrected quickly, whereas large violations significantly increase development time. Small setup violations (less than 1 ns) can be corrected in two ways: automatic correction using inbuilt optimization strategies in tools like phys_opt_design, or manual methods such as forward or backward retiming, logic replication to reduce fan-out, using faster primitives, and manually optimizing physical placement. These techniques can help correct setup violations in the range of 0.3 ns to 1 ns without major structural changes. Medium violations (1 ns to 3 ns) can be corrected using tool-based phys_opt_design optimization, as well as manual methods such as logic optimization by replacing critical logic with dedicated DSP blocks or carry chains, or using forward or backward retiming. These techniques can typically correct setup violations in the range of 1 ns to 3 ns, but may require structural changes. For large violations beyond 3 ns, tool-based optimization techniques are usually insufficient, and we mostly rely on adding pipeline registers or reducing the operating frequency to correct them. Similarly, there are techniques to correct hold violations, which we can explore another day. If you wish to build a strong foundation in STA for the Vivado Design Suite, explore our beginner-friendly STA course : https://lnkd.in/dWB-Y9B8

Choosing the Right STA Violation Correction Technique for FPGAs: Small, Medium, and Large Fixes Explained Numerous violation correction techniques have been discovered over time, each suited to specific requirements. Let us go over a simple cheat sheet that helps decide which technique to use under different situations. Violation correction techniques can be classified into three categories: small violations, medium violations, and large violations. A violation of less than 1 ns can be considered small, a medium violation occurs when the range is between 1 ns and 3 ns, and a large violation is anything above 3 ns. Small violations are usually corrected with inbuilt tool strategies or simple manual techniques. Medium violations require more aggressive strategies, while large violations often need structural changes. This also means that small violations can be corrected quickly, whereas large violations significantly increase development time. Small setup violations (less than 1 ns) can be corrected in two ways: automatic correction using inbuilt optimization strategies in tools like phys_opt_design, or manual methods such as forward or backward retiming, logic replication to reduce fan-out, using faster primitives, and manually optimizing physical placement. These techniques can help correct setup violations in the range of 0.3 ns to 1 ns without major structural changes. Medium violations (1 ns to 3 ns) can be corrected using tool-based phys_opt_design optimization, as well as manual methods such as logic optimization by replacing critical logic with dedicated DSP blocks or carry chains, or using forward or backward retiming. These techniques can typically correct setup violations in the range of 1 ns to 3 ns, but may require structural changes. For large violations beyond 3 ns, tool-based optimization techniques are usually insufficient, and we mostly rely on adding pipeline registers or reducing the operating frequency to correct them. Similarly, there are techniques to correct hold violations, which we can explore another day. If you wish to build a strong foundation in STA for the Vivado Design Suite, explore our beginner-friendly STA course : https://lnkd.in/dWB-Y9B8

Divergence, Convergence & Reconvergence in CDC ? A) Divergence (or fan-out) in Clock Domain Crossing (CDC) happens when a single signal in the single clock domain splits into multiple independent paths before crossing to the destination domain through separate synchronizers. We have two situations here. If the signals are never merged and each follows its own independent logic path in the destination domain, then there is no collective data incoherency, so the best strategy is simply to use a standard flop synchronizer on each independent path. But if those signals later merge again in the destination domain, then flip-flop synchronizers alone are not enough, because each path can arrive at different times; in that case we need to adopt same strategies that prevent reconvergence hazards, described next. B) Reconvergence happens when multiple signals from one clock domain take different paths, then each crosses the boundary through its own synchronizer, and finally they are combined again (for example, ANDed, ORed, compared, decoded) by combinational logic in the destination domain to produce some output. Reconvergence can also happen when two signals are generated in the same clock domain but have different path delays and we merge them in combinational logic; this local reconvergence can still cause a glitch if the logic is sensitive to momentary mismatches. Most preferred approach here is to register output in same clock domain before crossing. While in case of signal merging in different domain startegies vary based on source and destination clock frequencies. Most common approach is to treat the related signals as one unit: combine them into a bus in the source domain, freeze that bus so it stays stable, and send a single control (valid/ready style) across. Then, depending on the frequency relationship between the two domains, we choose the mechanism. If the source clock is slower than the destination clock, we can hold the grouped signals stable and send a valid pulse that the destination synchronizes and uses to latch the whole bus at once, which is basically a lightweight handshake. If we need stronger guarantee or bi-directional control, we use a full request/acknowledge handshake. If the source clock is faster than the destination clock, we should use an asynchronous FIFO to safely transfer the merged data, because the FIFO can absorb rate differences without losing information. If both clocks are frequency-related (for example derived from the same PLL with known phase) then we may be able to treat that crossing with normal STA-based timing techniques instead of generic asynchronous CDC. A more detailed coding walkthrough and demo of these techniques will be covered in the next post. If you want to learn the fundamentals of CDC for Vivado FPGA engineers, enroll in our beginner-friendly CDC course here: https://lnkd.in/dFvsAM_n

Divergence, Convergence & Reconvergence in CDC ? A) Divergence (or fan-out) in Clock Domain Crossing (CDC) happens when a single signal in the single clock domain splits into multiple independent paths before crossing to the destination domain through separate synchronizers. We have two situations here. If the signals are never merged and each follows its own independent logic path in the destination domain, then there is no collective data incoherency, so the best strategy is simply to use a standard flop synchronizer on each independent path. But if those signals later merge again in the destination domain, then flip-flop synchronizers alone are not enough, because each path can arrive at different times; in that case we need to adopt same strategies that prevent reconvergence hazards, described next. B) Reconvergence happens when multiple signals from one clock domain take different paths, then each crosses the boundary through its own synchronizer, and finally they are combined again (for example, ANDed, ORed, compared, decoded) by combinational logic in the destination domain to produce some output. Reconvergence can also happen when two signals are generated in the same clock domain but have different path delays and we merge them in combinational logic; this local reconvergence can still cause a glitch if the logic is sensitive to momentary mismatches. Most preferred approach here is to register output in same clock domain before crossing. While in case of signal merging in different domain startegies vary based on source and destination clock frequencies. Most common approach is to treat the related signals as one unit: combine them into a bus in the source domain, freeze that bus so it stays stable, and send a single control (valid/ready style) across. Then, depending on the frequency relationship between the two domains, we choose the mechanism. If the source clock is slower than the destination clock, we can hold the grouped signals stable and send a valid pulse that the destination synchronizes and uses to latch the whole bus at once, which is basically a lightweight handshake. If we need stronger guarantee or bi-directional control, we use a full request/acknowledge handshake. If the source clock is faster than the destination clock, we should use an asynchronous FIFO to safely transfer the merged data, because the FIFO can absorb rate differences without losing information. If both clocks are frequency-related (for example derived from the same PLL with known phase) then we may be able to treat that crossing with normal STA-based timing techniques instead of generic asynchronous CDC. A more detailed coding walkthrough and demo of these techniques will be covered in the next post. If you want to learn the fundamentals of CDC for Vivado FPGA engineers, enroll in our beginner-friendly CDC course here: https://lnkd.in/dFvsAM_n

Verilator Lint Rule Walkthrough – Part 1: Combinational & Sequential Best Practices Verilator is one of the interesting free-to-use lint checkers, offering far more checks compared to Vivado, sufficient for most hobbyist projects and even for graduate and post-graduate projects. Verilator supports around 128 lint checks, out of which approximately 48% (about 60) belong to the synthesizable RTL category. These can be used before running Vivado lint checks to ensure there are no unexpected syntax issues in the code that could lead to functional failures. Synthesizable rules can be divided into six categories, viz. combinational & sequential circuit recommended practices, width & type practices, block connection practices, constants & parameters practices, simulation-only construct practices, and coding style practices. Let us cover most of them in a six-day series, handling one category at a time. We start with combinational & sequential best practices to avoid simulation and synthesis mismatches and to ensure the intended hardware blocks are correctly inferred. This category includes six rules to correctly infer combinational and sequential circuits. Let us walk through them: 1) always@(): Combinational always blocks must be sensitive to all desired inputs of the system and cannot be empty. An empty sensitivity list means the block will never run. The recommended practice is to always use * with combinational always blocks. 2) All variables in a combinational always block must be assigned before being read to avoid unintended feedback paths or combinational loops. The recommended approach is to declare the variable, assign a value to it, and then read it. 3) A combinational always block should only include blocking assignment operators. Mixing blocking and non-blocking assignments in a combinational always block will lead to synthesis-simulation mismatches. Ensure that the same signal is not assigned values using both blocking and non-blocking assignments. A variable should be updated in only one always block, and the assignment operator must be chosen based on the type of circuit and remain consistent within that block. 4) Sequential always blocks should only use non-blocking assignment operators. 5) Avoid using initial blocks in synthesizable RTL code. Instead, use reset logic to assign initial or default values to signals. 6) Delay constructs are non-synthesizable and must be avoided in both sequential and combinational circuits. Instead, use counters to generate hardware delays. Follow all of the above rules to create synthesizable designs that correctly infer the intended hardware behavior. Learn more about other commonly used lint rules in Verilog for FPGA engineering here: https://lnkd.in/dYR8BnbS

Verilator Lint Rule Walkthrough – Part 1: Combinational & Sequential Best Practices Verilator is one of the interesting free-to-use lint checkers, offering far more checks compared to Vivado, sufficient for most hobbyist projects and even for graduate and post-graduate projects. Verilator supports around 128 lint checks, out of which approximately 48% (about 60) belong to the synthesizable RTL category. These can be used before running Vivado lint checks to ensure there are no unexpected syntax issues in the code that could lead to functional failures. Synthesizable rules can be divided into six categories, viz. combinational & sequential circuit recommended practices, width & type practices, block connection practices, constants & parameters practices, simulation-only construct practices, and coding style practices. Let us cover most of them in a six-day series, handling one category at a time. We start with combinational & sequential best practices to avoid simulation and synthesis mismatches and to ensure the intended hardware blocks are correctly inferred. This category includes six rules to correctly infer combinational and sequential circuits. Let us walk through them: 1) always@(): Combinational always blocks must be sensitive to all desired inputs of the system and cannot be empty. An empty sensitivity list means the block will never run. The recommended practice is to always use * with combinational always blocks. 2) All variables in a combinational always block must be assigned before being read to avoid unintended feedback paths or combinational loops. The recommended approach is to declare the variable, assign a value to it, and then read it. 3) A combinational always block should only include blocking assignment operators. Mixing blocking and non-blocking assignments in a combinational always block will lead to synthesis-simulation mismatches. Ensure that the same signal is not assigned values using both blocking and non-blocking assignments. A variable should be updated in only one always block, and the assignment operator must be chosen based on the type of circuit and remain consistent within that block. 4) Sequential always blocks should only use non-blocking assignment operators. 5) Avoid using initial blocks in synthesizable RTL code. Instead, use reset logic to assign initial or default values to signals. 6) Delay constructs are non-synthesizable and must be avoided in both sequential and combinational circuits. Instead, use counters to generate hardware delays. Follow all of the above rules to create synthesizable designs that correctly infer the intended hardware behavior. Learn more about other commonly used lint rules in Verilog for FPGA engineering here: https://lnkd.in/dYR8BnbS