Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

`assert` emits `$fatal` before error messages in generated Verilog

See original GitHub issue

Type of issue: bug report Impact: API modification Development Phase: request

Other information As per the implementation of assert https://github.com/chipsalliance/chisel3/blob/024847d75079a125e5946e9dcf2ed9c14d2db730/core/src/main/scala/chisel3/VerificationStatement.scala#L94-L97 A verification statement is generated before the failure message, which gets turned into a $fatal statement by firrtl. This makes the failure message never visible in simulations.

steps to reproduce the problem Call assert in any elaborated code.

What is the current behavior? $fatal generated before $fwrite

What is the expected behavior? $fwrite generated before $fatal, or at least have a switch for changing the order.

Please tell us about your environment: Windows 11 WSL2, ArchLinux

What is the use case for changing the behavior? Better debug experience using external simulator.

Issue Analytics

State:
Created 2 years ago
Reactions:3
Comments:7 (7 by maintainers)

Top GitHub Comments

2reactions

ekiwicommented, Apr 14, 2022

Integrating the Message with the Verification Statement

It’s complicated… There are two interacting things:
1. Chisel emits these asserts as an `assert`/`printf` pattern (with the assert before the printf). Chisel should really be emitting this as just an assert with a message.
It seems cleanest to fix (1).

Unfortunately (1) won’t work without some significant work on the firrtl compilers. You would have to extend the assert and assume statements to support format strings and potentially duplicate some code for handling print statements. I think this would be a nice solution, just want to point out that there would be some work involved.

Assertion Message Semantics

The Verilog that the C++ firrtl compiler generates would work well when there is, however what would happen if there are two assertions that fail in the same cycle? What if they are in different modules? Are we giving any guarantees in that case? Would it be OK for the Scala firrlt compiler to move all assert/stop statements below all printf statements? I.e. we would guarantee that printfs inside a module happen in order, but assertions will always happen after all printfs (inside a module).

Fixing this Issue

I have a short fix which should bring things back to the state we had in 3.4: https://github.com/chipsalliance/chisel3/pull/2484

1reaction

jerryz123commented, Apr 14, 2022

Is there any activity on this? This is a significant nuisance on 3.5.0 and newer.

Top Results From Across the Web

Add assert IR op and tie to DSLX fail! #232 - google/xls - GitHub

In Verilog we really want the wildcard arm to lower to something near: assert(x == 42 || x == 64) else $fatal("Assertion failure...

Error messages - from assertions - Verification Academy

I'm reviewing various ways to report error messages from assertions. questa reports when using $error() and ovm_report_error() ? I don't have ...

verilator Arguments — Verilator 5.005 documentation - Veripool

Verilator will spawn the specified command as a subprocess pipe, to allow the command to perform custom edits on the Verilog code before...

Errors and Warnings — Verilator 5.005 documentation

This usually indicates that the profile data was generated from a different Verilog source code than Verilator is currently running against. It is...

freechipsproject/chisel3 - Gitter

Hello Guys, how to run the gate-level simulation for the chisel generated Verilog?? Do I need to define RANDOMIZE_REG_INIT?? Because I tried running...