Jan Decaluwe wrote:
This is a fairly "old" project (2003). At that time, MyHDL didn't
yet have conversion to Verilog.
After reviewing the code again, it's clear that it's written in
RTL (register-transfer level) style. This means that the building
blocks are combinatorial, or triggered on clock edges, closely
reflecting an actual implementation. As it is, it's not
convertible to Verilog (see the MyHDL manual for conversion
constraints), but it's close.
Thanks that's great to hear, and from something I find very interesting.
To someone with some synthesis experience, it should be fairly
straightforward to make the code synthesizable. I don't expect
that this would make the code more verbose or less clear.
I find that even more intersting :-)
I've been watching your project grow over the past couple of years with
great interest though little actual need at the moment, but for me seeing
MU0 crop up piques my interest because that shows that MyHDL is getting
up to a very interesting level.
As your interest was apparently triggered by an example, this
tells me that I should put more emphasis on publishing practical
examples, as conversion to Verilog was already introduced some time
ago (beginning of 2004).
Practical examples are great, I'd seen that you'd introduced conversion to
verilog some time back, but it wasn't clear how much was synthesisable. The
example on the website & seeing MU0 description made me really wonder.
After all MU0 is used as a teaching example of how a very minimal CPU can
MU0 itself is not that interesting, but for me the fact MyHDL might be able
to synthesise it *is* interesting. After all, synthesising such a beast
(essentially) directly from python shows to me a very powerful example
which can be built upon.
Note also that by now, there are designers that use MyHDL in real
projects, showing that you really can use it to go from Python to
an FPGA (or ASIC). Moreover, with development tools such
as Xilinx WebPack (now on Linux also) that start from Verilog,
this can be done using a zero-cost development environment.
Hmm... Very interesting :-)
I believe it's meaningful because in my view digital hardware
design can be regarded as just another specialized software
engineering discipline. Of course, things have to be learned,
but it's not more difficult than other application domains.
I should add that this is not the mainstream view of the
hardware design community :-)
For what it's worth, I agree. I've had some limited experience with
compilation to hardware in the past, specifically to asynchronous hardware,
but given you write code that can include loops, conditionals and these can
be translated to FPGA descriptions and then run this for me blurs the
hardware/software distinction. A specific example that looks like software
I'm thinking of is this:http://www.cs.man.ac.uk/fmethods/projects/AHV-PROJECT/node8.html
(In particularly it's not really that different from Occam)
Maybe I should continue this conversation on the MyHDL list, since I'd be
interested in getting started in this in a simple way. (Mainly because my
work project Kamaelia is designed, to an extent, with hardware constraints
in mind. Implementing some Kamaelia components in MyHDL would be pretty
cool. This might well be possible since we also use generators to model