A 'next generation' concept study for myHDL syntax emulation based on a different hardware generator kernel. The v2we acronym (working title pun) stands for 'van twee walletjes eten' (dutch meaning to 'take advantage from both sides') or 'version two working environment'.
This is the Cyrite and intbv
compatible branch. This is likely going to be the main development path for the future.
What it is based on:
intbv
benefitsWhat it is not:
Why VHDL, despite fading out support for vendor toolchains?
VHDL, due to its strict typing, is still the best golden reference to check against and make sure no implicit magic slips through. Once the VHDL tool flow is proven to be robust, other targets can be tackled.
Is VHDL-2019 support planned?
Not for the time being. It is unlikely that any FPGA toolchain on the market will implement the full VHDL-2019 support.
Is this a myHDL fork?
No. It is a different kernel, originally designed to procedurally generate HDL/RTL pipelines.
It was partially rewritten to be compatible with other data types, such as myHDL's intbv
which may still serve as 'state of the art' reference implementation for bit vectors. MyHDL emulation is implemented using AST-Translation.
Is functionality being back-ported into MyHDL/a fork?
No, see above. The different kernel architecture doesn't allow that.
Where is the github repository for the kernel?
There is none. The myIRL binary part of the kernel still contains proprietary code which is hosted in a private repository. The cleanups for full opensource compatibility will come last.
What is going to happen to myHDL synthesis via yosys ('jupyosys')?
See above WRT RTLIL. The myHDL support will no longer be maintained for jupyosys and remains as 'experiment only'.