

Capturing a UART Design in MyHDL and Testing It in an FPGA - aprdm
http://www.eetimes.com/author.asp?section_id=36&doc_id=1323837&

======
ajross
As yet another FPGA enthusiast with a software background, I want to like
MyHDL more than I actually do. It makes the expression of complex generated
hardware easier (because it's Python), but the workaday circuit level stuff
ends up even cruftier-looking than VHDL. And the simulation backend seems like
mostly a toy. Chisel is sort of the same thing, but based on Scala, and has a
lot of the same issues IMHO.

Honestly I wonder if all these "open source HDLs aimed at hackers" projects
are simply trying to do too much and what the world really needs is just a
cleaner Verilog with the synthesis and simulation environments more strictly
separated...

Also: what editor thought that the best way to represent code examples was as
an unreadably small app screenshot followed by helpful "bigger image" and
(sigh) "view this code on github" links?

~~~
oelang
I think verilog (and mostly systemverilog) is beyond saving. Systemverilog has
a spec bigger than c++ and it's full of broken, unused features or features
that aren't compatible. Over the years they have added any feature that some
HW engineer asked for resulting in a true kitchensink language. I don't think
that there is a single simulator that implements the complete spec. (and on
top of the regular language they use lexical macros very heavily)

VHDL is a little better but the syntax is horribly verbose and it lacks power
to do advanced verification (either it needs a better library or it needs a
few more features). In my mind VHDL can be saved, some VHDL-coffeescript could
be wonderful.

MyHdl is interesting, it's build with clear goals & it's made by an
experienced HW engineer that also understands good software design (most
don't). He would disagree with you about simulation
([http://www.jandecaluwe.com/blog/its-a-simulation-
language.ht...](http://www.jandecaluwe.com/blog/its-a-simulation-
language.html)). The RTL code that MyHdl generates always looked very clean to
me and the simulation possibilities with python are of course infinitely
better than anything that systemverilog or vhdl can offer.

~~~
aprdm
Very nice comment, I agree with it 100%. Being able to apply good software
desgin at a RTL design is a killer feature of MyHDL in my opinion.

The possibility to mix RTL and high level software is a very nice feature, for
exemple: To make a FFT in Python in few lines and compare the output to your
RTL FFT with asserts. And script it so you can loop through a different number
of fixed bits width and check the TVE at each bit width.

To do this in Python I used ~50 lines, in VHDL it would be a headache and I
probably would end up needing to use matlab to compare the results.

~~~
ajross
I guess I don't see this as such a big deal. My own experience is limited, but
doing this kind of validation by iterating over the input space using e.g.
perl to generate verilog is fairly straightforward. I've done exactly that
with decent success; again it's a straightforward software problem, and I'm a
software guy.

I think the problems I had is sort of the converse: hardware is hard.
Reasoning about hardware is hard. And having the representation of your
hardware about which you much reason be expressed in the actions of an
interpreted program (where the synthesis is a side effect basically) makes
things harder than it has to be. The RTL ends up being polluted with
simulation constructs and hiding the meaning I'm trying to see. And if
anything MyHDL is actually worse at this than Verilog or VHDL.

~~~
oelang
Because reasoning about hardware is hard it's important to be able to rely on
simulation. I'm not saying that all issues can be caught/detected in
simulation but many can. In most designs 90% of the code (typically the
synchronous logic) can be fully debugged in simulation. Ok there is still a
portion that can't be debugged, and you'll likely spend a large amount of time
on that final 10% but the alternative is certainly worse.

A good designer can avoid constructs that can't be or are very hard to
simulate correctly. A good example is signals that have to cross clock
domains, metastability is easily missed in simulation and the problems it
causes in actual hardware are huge. Good hardware design tries to avoid or
encapsulate these kind of constructs.

Beyond this you still have to deal with the analogue world and that is often
hard to simulate. Clock generators that misbehave, working with memory
controllers (and buggy IP cores): it's not all under your control and that why
hardware design often feels so hard. A lot of time is spend on these issues,
but that's only because the rest is made easy by using VHDL.

------
VLM
Its a nice simple design. Interesting to see it python instead of the usual
verilog/vhdl

Real uarts tend to implement FIFOs and oversample and do control signals. The
virtual 16550 linked below oversamples at 16x and the generic verilog uart
below does at least try to sniff at the center of the bit clock even if I
don't think it oversamples.

Here's a generic verilog uart

[http://opencores.org/project,osdvu](http://opencores.org/project,osdvu)

here's a virtual 16550

[http://opencores.org/project,uart16550](http://opencores.org/project,uart16550)

Those projects would be logical paths of inspiration to extend the python
uart. You could probably just steal/borrow the PDF spec sheet for the virtual
16550 and use that as a spec to implement the python uart.

~~~
aprdm
Thank you very much for your feedback!It's indeed a very simple
implementation, the goal was more to explore MyHDL than to have a robust UART.

