9dedac50 introduced this harmless but disconcerting warning, which was emitted
when abc/ did not yet exist and was about to be cloned:
/bin/sh: line 0: cd: abc: No such file or directory
This includes the following significant changes:
* Patching ezsat and minisat to disable resource limiting code
on WASM/WASI, since the POSIX functions they use are unavailable.
* Adding a new definition, YOSYS_DISABLE_SPAWN, present if platform
does not support spawning subprocesses (i.e. Emscripten or WASI).
This definition hides the definition of `run_command()`.
* Adding a new Makefile flag, DISABLE_SPAWN, present in the same
condition. This flag disables all passes that require spawning
subprocesses for their function.
By operating at a layer of abstraction over the rather clumsy Intel primitives,
we can avoid special hacks like `dffinit -highlow` in favour of simple techmapping.
This also makes the primitives much easier to manipulate, and more descriptive
(no more cyclonev_lcell_comb to mean anything from a LUT2 to a LUT6).
The make targets echo-yosys-ver, echo-git-ver and echo-abc-rev can be
used to programmatically extract contents of make variables for external
scripts. Unfortunately, when a Makefile.conf exists, its contents would
also be echoed, making the output almost unusable. This patch
selectively disables this functionality for these special targets.
`rev-parse --short` output may have a different abbreviated hash length than
ABCREV, so a simple string comparison always fails, even if the correct
commit is checked out. Pass both commits through rev-parse and then
compare the full hashes instead.
Add an `echo-abc-rev` target so that packaging scripts can set ABCPULL=0 and
handle all the git nastiness themselves.
`rev-parse --short` output may have a different abbreviated hash length than
ABCREV, so a simple string comparison always fails, even if the correct
commit is checked out. Pass both commits through rev-parse and then
compare the full hashes instead.
Add an `echo-abc-rev` target so that packaging scripts can set ABCPULL=0 and
handle all the git nastiness themselves.
The behaviour of python-config --libs has changed in Python 3.8.
For example, compare the output of it with Python 3.7 and 3.8 on an
ArchLinux system:
$ python3.7-config --libs
-lpython3.7m -lcrypt -lpthread -ldl -lutil -lm
$ python3.8-config --libs
-lcrypt -lpthread -ldl -lutil -lm -lm
$
The lack of -lpython in the latter case causes the linker to fail when
attempting to build Yosys against Python 3.8.
Passing the new --embed flag to python-config adds -lpython, just like
earlier versions of Python:
$ python3.8-config --embed --libs
-lpython3.8 -lcrypt -lpthread -ldl -lutil -lm -lm
$
This commit adds code for automatically detecting support for the
--embed flag. If it is supported, it is passed to all python-config
invocations. This fixes building against Python 3.8.
On some architectures, notably on Windows, the official name for the
Python binary from python.org is `python`. The build system assumes
that python is called `python3`, which breaks under this architecture.
There is already infrastructure in place to determine the name of the
Python binary when building PYOSYS. Since Python is now always required
to build Yosys, enable this check universally which sets the
`PYTHON_EXECUTABLE` variable.
Then, reuse this variable in other Makefiles as necessary, rather than
hardcoding `python3` everywhere.
Signed-off-by: Sean Cross <sean@xobs.io>
A new pass, connect_rpc, allows any HDL frontend that can read/write
JSON from/to stdin/stdout or an unix socket or a named pipe to
participate in elaboration as a first class citizen, such that any
other HDL supported by Yosys directly or indirectly can transparently
instantiate modules handled by this frontend.
Recognizing that many HDL frontends emit Verilog, it allows the RPC
frontend to direct Yosys to process the result of instantiation via
any built-in Yosys frontend. The resulting RTLIL is then hygienically
integrated into the overall design.
Problems/questions:
- fsm.ys. equiv_opt -assert failed because of unproven cells;
- latches.ys,tribuf.ys - internal cells present;
- memory.ys - sat called with -verify and proof did fail.
Problems/questions:
- memory.ys: ERROR: Failed to import cell gate.mem.0.0.0 (type
EG_LOGIC_DRAM16X4) to SAT database.
Why EG_LOGIC_DRAM16X4, not AL_LOGIC_BRAM?
- Internal cell type $_TBUF_ is present.
Did you think that `$(shell command -v ...)` would actually get run by
the shell? Foolish mortal; GNU Make is obviously far more wise than
thee, as it optimizes it to a direct -- and hence broken (since
`command` is a shell builtin) -- exec. This horrifying contortion
ensures that an actual shell runs the command and fixes the behaviour.
@Shizmob found the source of this misbehaviour; turns out gmake has a
hard-coded, incomplete list of shell builtins:
715c787dc6/src/job.c (L2691)
This contains `command`, but the whole function is full of horrible
heuristic garbage so who knows. I'm so sorry.