Warning The following text is obsolete with MyHDL 0.6. It is kept here for background reading.
MyHDL code can be converted to Verilog using the
toVerilog function. Several
users are using this successfully using to implement MyHDL descriptions in
However, there is also a significant demand for a VHDL backend, especially from
the FPGA world. Several people have offered help in the development of a
This page is used to define, specify and steer the development of
At this point, there are still many open issues. This page will document them, feed the discussion and be kept up-to-date with the status.
--- Jan Decaluwe 2005/11/14 15:53
Why is it not there yet?
To start, it may be enlightening to explain why
toVHDL is not there yet. I
will list the reasons, in order of increasing significance, as well as their
toVerilog was a significant effort. Afterwards, it seemed
appropriate to wait for some time to see how it would work in practice. At this
point, it seems to work fine.
Secondly, I was not satisfied with certain aspects of the implementation. I
thought it would be best to have a mature
toVerilog implementation before
toVHDL. In the mean time, things have improved. In particular, MyHDL
0.5 (still in development) has a much cleaner and more general method for
hierarchy extraction, and it adds support for signed representations of
toVHDL felt like doing a similar thing again. It was
not clear that there would be a significant need for it. It seemed more
appropriate to address other MyHDL issues. In practice however, the question
for VHDL support keeps popping up. At the time I also thought that perhaps
someone would jump in and implement
toVHDL. There have indeed been
indications of such projects. But it's not a minor undertaking. Moreover, some
important issues (see further) need to be solved, regardless of who does the
work. In any case: it's not there at this point.
Finally, the most important issue is yet to be solved: the verification strategy. This will be discussed in the next section. The overall status is that if we can solve that issue, we are ready to move ahead.
The verification problem
The Verilog conversion approach
Before starting an implementation, we need to have a verification strategy in place. It should be powerful enough to develop unit tests for every aspect of the conversion. The whole feature set should be covered with a comprehensive test suite. This is the only way to get the number of bugs down to an acceptable level, and to make later changes and add new features with an acceptable degree of confidence.
Verilog conversion is currently verified by using co-simulation with an open-source Verilog simulator. A MyHDL model that uses a specific feature is converted to Verilog. Co-simulation using the same MyHDL test bench is used to verify that the Verilog model has the same behavior as the MyHDL model.
An obvious strategy would be to use co-simulation with VHDL in the same way. But it's not that simple. What is needed is a VHDL simulator with a powerful C API interface, because co-simulation requires a relatively sophisticated C interface. At this point, I don't know of an open-source VHDL simulator that has the required support. GHDL has a C API, but according to reports its capabilities are limited. On the other hand, using commercial VHDL simulators doesn't seem possible either. At this point, the MyHDL project cannot afford a commercial license. The alternative of accessing commercial licenses from other users may have legal problems. Finally, using evaluation licences is not an option either: one should be able to verify at at any time when changes are made, bugs fixed, or features added.
For a long time, I thought that we were stuck here. But in fact the real question should be: is there a way to do verification without co-simulation? Perhaps there is.
Verification without co-simulation?
So, to make progress, we should investigate whether we can do verification without co-simulation.
From this point on all issues are open. I will describe my current thinking but I won't actively work on the project until 0.5 is released. So if anyone wants to jump in, I think here's a good starting point to make progress.
Please don't use this wiki page for discussions. Use the mailing list/newsgroup for that purpose. This page will be kept up to date with the status.
A first thing to note is that, as experience with
toVerilog shows, we can
convert much more than just a synthesizable subset. It should be possible to
convert test benches of some complexity. For that reason, we don't necessarily
need co-simulation to provide stimulus and check results. We can just convert
more code, including the test bench.
Of course, we still have to verify that the 2 testbenches do the same thing. At
some point I thought that perhaps the
py.test project could help. Basically,
py.test permits to create unit tests in a much simpler way than the standard
unittest module. With
py.test, it is not necessary to subclass special test
classes: any kind of python code with
assert statements can be a unit test.
By converting such a piece of MyHDL code to VHDL, we would have an equivalent
VHDL test bench.
py.test is clearly a useful project, it doesn't solve our
problem. We don't have to check that the MyHDL or VHDL test bench is
correct, but rather that they do the same thing. Functional correctness
can be verified using
assert statements, but conversion correctness can not.
For example, suppose that for some reasons no Python
assert statements would
be converted into VHDL. The VHDL test bench would not report errors, but of
course the conversion would have failed.
Instead, what we have to do is log every interesting aspect of a MyHDL test,
and compare it with the log of the converted VHDL test. For logging, we could
logging module, and convert these
report statements in VHDL. For example, to verify operators, we
would log each result. To verify loops, we could log each time we enter the
loop and an iteration number. To verify FSMs, we could log each state that we
enter and leave. And so on.
Some implementation ideas:
Ideally, no files should be used. We would capture the standard output of both simulations in memory buffers, and compare them.
The tests should be embedded in a unit test class. The actual log comparison and check should be done in a generic
tearDownmethod that can be defined in a superclass. If the tests fails, a detailed trace is printed.
If we get it to work, the method actually has an advantage over co-simulation. We don't compare port values, but detailed logs of the internal workings of the simulations. This is a more direct method that may make debugging easier.
The verification method can and should be developed before the implementation
toVHDL itself. Even better, it seems possible to develop the whole test
suite before that. It seems it could be largely independent of the target
language, so the existing
toVerilog function could be used in developing it.