This makes it possible for yosys commands to return values when invoked
as tcl commands. Right now no commands natively support this, but the
tee command can be used with json output like this:
```tcl
set stat [yosys tee -q -s result.json stat -json -top top]
dict get $stat modules \\top num_cells_by_type \$pmux
```
Or with newline separated lists like this:
```tcl
split [yosys tee -q -s result.string select -list top] "\n"
```
The new bitwise case equality (`$bweqx`) and bitwise mux (`$bwmux`)
cells enable compact encoding and decoding of 3-valued logic signals
using multiple 2-valued signals.
When writing VCDs smtbmc replaces square brackets with angle brackets to
avoid the issues with VCD readers misinterpreting such signal names.
For memory addresses it also uses angle brackets and hexadecimal
addresses, while other tools will use square brackets and decimal
addresses.
Previously the code handled both forms of memory addresses, assuming
that any signal that looks like a memory address is a memory address.
This is not the case when the user uses regular signals whose names
include square brackets _or_ when the verific frontend generates such
names to represent various constructs.
With this change all angular brackets are turned into square brackets
when reading the trace _and_ when performing a signal lookup. This means
no matter which kind of brackets are used in the design or in the VCD
signals will be matched. This will not handle multiple signals that are
the same apart from replacing square/angle brackets, but this will cause
issues during the VCD writing of smtbmc already.
It still uses the distinction between square and angle brackets for
memories to decide whether the address is hex or decimal, but even if
something looks like a memory and is added to the `memory_to_handle`
data, the plain signal added to `name_to_handle` is used as-is, without
rewriting the address.
This last change is needed to successfully match verific generated
signal names that look like memory addresses while keeping memories
working at the same time. It may cause regressions when VCD generation
was done with a design that had memories but simulation is done with a
design where the memories were mapped to registers. This seems like an
unusual setup, but could be worked around with some further changes
should this be required.
* Change simlib's $mux cell to use the ternary operator as $_MUX_
already does
* Stop opt_expr -keepdc from changing S=x to S=0
* Change const eval of $mux and $pmux to match the updated simlib
(fixes sim)
* The sat behavior of $mux already matches the updated simlib
The verilog frontend uses $mux for the ternary operators and this
changes all interpreations of the $mux cell (that I found) to match the
verilog simulation behavior for the ternary operator. For 'if' and
'case' expressions the frontend may also use $mux but uses $eqx if the
verilog simulation behavior is requested with the '-ifx' option.
For $pmux there is a remaining mismatch between the sat behavior and the
simlib behavior. Resolving this requires more discussion, as the $pmux
cell does not directly correspond to a specific verilog construct.
This attribute can be used by formal backends to indicate which clocks
were mapped to the global clock. Update the btor and smt2 backend which
already handle clock inputs to understand this attribute.
These can be used to protect undefined flip-flop initialization values
from optimizations that are not sound for formal verification and can
help mapping all solver-provided values in witness traces for flows that
use different backends simultaneously.
This pull request is to address YosysHQ/yosys#2980.
The documentation, as originally written, does not make it clear that yosys commands, when used within a tcl script, do not return any value to the tcl script.
This pull request notes this and offers a workaround via tee as noted in the issue.
POSIX defines $TMPDIR as containing the pathname of the directory where
programs can create temporary files. On most systems, this variable points to
"/tmp". However, on some systems it can point to a different location.
Without respecting this variable, yosys fails to run on such systems.
Signed-off-by: Mohamed A. Bamakhrama <mohamed@alumni.tum.de>
- Prevent unmatched expected error patterns from self-matching
- Prevent infinite recursion on unmatched expected warnings
- Always print the error message for unmatched error patterns
- Add test coverage for all unmatched message types
- Add test coverage for excess matched logs and warnings
- Attempt to lookup a derived module if it potentially contains a port
connection with elaboration ambiguities
- Mark the cell if module has not yet been derived
- This can be extended to implement automatic hierarchical port
connections in a future change
- FfData now keeps track of the module and underlying cell, if any (so
calling emit on FfData created from a cell will replace the existing cell)
- FfData implementation is split off to its own .cc file for faster
compilation
- the "flip FF data sense by inserting inverters in front and after"
functionality that zinit uses is moved onto FfData class and beefed up
to have dffsr support, to support more use cases
- *_en is split into *_ce (clock enable) and *_aload (async load aka
latch gate enable), so both can be present at once
- has_d is removed
- has_gclk is added (to have a clear marker for $ff)
- d_is_const and val_d leftovers are removed
- async2sync, clk2fflogic, opt_dff are updated to operate correctly on
FFs with async load
This code now takes the AST nodes of type AST_BIND and generates a
representation in the RTLIL for them.
This is a little tricky, because a binding of the form:
bind baz foo_t foo_i (.arg (1 + bar));
means "make an instance of foo_t called foo_i, instantiate it inside
baz and connect the port arg to the result of the expression 1+bar".
Of course, 1+bar needs a cell for the addition. Where should that cell
live?
With this patch, the Binding structure that represents the construct
is itself an AST::AstModule module. This lets us put the adder cell
inside it. We'll pull the contents out and plonk them into 'baz' when
we actually do the binding operation as part of the hierarchy pass.
Of course, we don't want RTLIL::Binding to contain an
AST::AstModule (since kernel code shouldn't depend on a frontend), so
we define RTLIL::Binding as an abstract base class and put the
AST-specific code into an AST::Binding subclass. This is analogous to
the AST::AstModule class.
Jannis Harder
Miodrag Milanovic
KrystalDelusion
Emil J
Claire Xenia Wolf
Aki Van Ness
N. Engelhardt
Marcelina Kościelnicka
rockybulwinkle
Henner Zeller
Jacob Lifshay
Mohamed A. Bamakhrama
Alastair M. Robinson
NotAFile
Zachary Snow
Catherine
Lofty
Rupert Swarbrick