4 ms·

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

19 points by aprdm 12y ago

VLM 12y ago
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 12y ago
  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.
ajross 12y ago
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 12y ago
  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.html 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.
  - aprdm 12y ago
    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 12y ago
      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.

19 points by aprdm 12y ago

VLM 12y ago

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 12y ago
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.

ajross 12y ago

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 12y ago
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.html 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.
- aprdm 12y ago
  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 12y ago
    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.