By instantiating the LUTRAM cell directly, we avoid a trip through
altsyncram, which speeds up Quartus synthesis time. This also gives
a little more flexibility, as Yosys can build RAMs out of individual
32x1 LUTRAM cells.
While working on this, I discovered that the mem_init0 parameter of
<family>_mlab_cell gets ignored by Quartus.
log_assert(false) never returns and thus can't fall through, but gcc
doesn't seem to think that far. Making it the last case avoids the
problem entirely.
The current firrtl backend emits blackboxes as standard modules
with an empty body, but this causes the firrtl compiler to
optimize out entire circuits due to the absence of any drivers.
Yosys already tags blackboxes with a (*blackbox*) attribute, so this
commit just propagates this change to firrtl's syntax for blackboxes.
The workflow of debugging fatal pass errors in Yosys is flawed in
three ways:
1. Running Yosys under a debugger is sufficient for the debugger
to catch some fatal errors (segfaults, aborts, STL exceptions)
but not others (`log_error()`, `log_cmd_error()`). This is
neither obvious nor easy to remember.
2. To catch Yosys-specific fatal errors, it is necessary to set
a breakpoint at `logv_error_with_prefix()`, or at least,
`logv_error()`. This is neither obvious nor easy to remember,
and GDB's autocomplete takes many seconds to suggest function
names due to the large amount of symbols in Yosys.
3. If a breakpoint is not set and Yosys encounters with such
a fatal error, the process terminates. When debugging a crash
that takes a long time to reproduce (or a nondeterministic crash)
this can waste a significant amount of time.
To solve this problem, add a macro `YS_DEBUGTRAP` that acts as a hard
breakpoint (if available), and a macro `YS_DEBUGTRAP_IF_DEBUGGING`
that acts as a hard breakpoint only if debugger is present.
Then, use `YS_DEBUGTRAP_IF_DEBUGGING` in `logv_error_with_prefix()`
to obviate the need for a breakpoint on nearly every platform.
Co-Authored-By: Alberto Gonzalez <boqwxp@airmail.cc>