devcontainers are a convenient way to provide users a reproducible
build environment. It is currently supported by Visual Studio Code,
Visual Studio and IntelliJ.
When the user opens the verilator repo in VSCode with the standard
devcontainer extension installed, VSCode will ask the user if they
want to reopen in the devcontainer, then build the Docker image as per
our definition and then restart VSCode 'remotely' attached to the
Docker container.
More information:
https://code.visualstudio.com/docs/devcontainers/containers
Also:
- zlibc is missing on Debian-based systems now
- Add non-root user to Dockerfile and make default
Adds timing support to Verilator. It makes it possible to use delays,
event controls within processes (not just at the start), wait
statements, and forks.
Building a design with those constructs requires a compiler that
supports C++20 coroutines (GCC 10, Clang 5).
The basic idea is to have processes and tasks with delays/event controls
implemented as C++20 coroutines. This allows us to suspend and resume
them at any time.
There are five main runtime classes responsible for managing suspended
coroutines:
* `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle`
with move semantics and automatic cleanup.
* `VlDelayScheduler`, for coroutines suspended by delays. It resumes
them at a proper simulation time.
* `VlTriggerScheduler`, for coroutines suspended by event controls. It
resumes them if its corresponding trigger was set.
* `VlForkSync`, used for syncing `fork..join` and `fork..join_any`
blocks.
* `VlCoroutine`, the return type of all verilated coroutines. It allows
for suspending a stack of coroutines (normally, C++ coroutines are
stackless).
There is a new visitor in `V3Timing.cpp` which:
* scales delays according to the timescale,
* simplifies intra-assignment timing controls and net delays into
regular timing controls and assignments,
* simplifies wait statements into loops with event controls,
* marks processes and tasks with timing controls in them as
suspendable,
* creates delay, trigger scheduler, and fork sync variables,
* transforms timing controls and fork joins into C++ awaits
There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`)
that integrate static scheduling with timing. This involves providing
external domains for variables, so that the necessary combinational
logic gets triggered after coroutine resumption, as well as statements
that need to be injected into the design eval function to perform this
resumption at the correct time.
There is also a function that transforms forked processes into separate
functions.
See the comments in `verilated_timing.h`, `verilated_timing.cpp`,
`V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals
documentation for more details.
Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
Unify the actions in the Dockerfiles between the runtime environment
and the run containers.
Fixes#2345
Signed-off-by: Stefan Wallentowitz <stefan.wallentowitz@hm.edu>
* [docker] Remove versions from Docker files
There is no dependency on an actual version, it was only there to
silence the linter. Instead the linter is now set to not warn about
it.
Signed-off-by: Stefan Wallentowitz <stefan.wallentowitz@hm.edu>
* [docker] Update to Ubuntu 20.04
Update to new Ubuntu release:
- Only GCC 9.3 available. Also add clang (10.0) now.
- SystemC is now a package 🎉
Signed-off-by: Stefan Wallentowitz <stefan.wallentowitz@hm.edu>
This adds files to build and run two Docker images:
- run: Build a Docker container that can be used as an executable
drop-in for verilator. This can be useful to test behavior of
older versions or a development version. The functionality is
pretty simplistic at the moment for a start.
- buildenv: Everything needed to build and test Verilator. Useful to
run quick tests in the cloud or try other compilers. It can
also serve as basis for further CI integration.
