Capturing a UART Design in MyHDL and Testing It in an FPGA | Hacker News Reader

Capturing a UART Design in MyHDL and Testing It in an FPGA

eetimes.com

19 pointsaprdm12 comments

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?

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...). 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.

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.

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.

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.

I agree with the general sentiment with VHDL. I't not a bad language beneath it all, but the syntax does not make it an enjoyable experience. Though I haven't touched it in years, I did at one point try to clean up the syntax very slightly using some rather dumb parsing/substitution. Once you're past the ada syntax and the bad tooling, it's not entirely bad.

http://log.fundamental-code.com/2011/06/11/vhdl-code-generat... http://github.com/fundamental/modv

I don't have enough experience in the other HDL options out there to really say anything conclusive other than the space is a bit of a mess as a whole.

What's your opinion on PSHDL and Chisel? They try to solve these problems in very different ways. PSHDL can interact with standard VHDL code. Chisel can generate Verilog and C++-based cycle-accurate software simulators.

https://pshdl.org/

https://chisel.eecs.berkeley.edu/

PSHDL is incredibly low-level & basic, afaik it doesn't even have functions & you can't define your own datatypes. I think it's a mistake to make a HDL language that aims to be 99% synthesize-able. I didn't write this but I do agree with it: http://www.jandecaluwe.com/blog/its-a-simulation-language.ht...

I haven't looked a chisel yet (scala is my favorite software programming language though).

You missed the point on SystemVerilog: It's a great language for use in both RTL and verification. The complex structures that you are addressing deal with assertions and classes and other constructs for verification. UVM built a verification library with those constructs. SystemVerilog.us

The problem is that they add a new language feature for every new use case instead of trying to make features fit together in a nice compact core & building on top of that core (in other words 'modern language design'). Systemverilog now has ~250 keywords, do you think you know all of them? There are so many that they allow you to selectively disable keywords using compiler pragmas. In python there are only 33 keywords! VHDL avoided this issue because they mostly copied the ADA language which was developed by competent language designers.

I don't doubt the usefulness of a subset of systemverilog, but as a language it's very badly designed.

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

here's a virtual 16550

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.

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.

Reply on news.ycombinator.com