Re: [myhdl-list] What MyHDL is not

[Bob C. <fl...@gm...>]

On 04/23/2012 07:11 PM, Christopher Felton wrote:
> On 4/23/12 5:23 AM, Jan Decaluwe wrote:
>> I have written a page describing what MyHDL is not:
>>
>> http://www.myhdl.org/doku.php/whatitisnot
> I believe this will help inform new users.  We often get new users, I
> believe, with unrealistic expectations of MyHDL.
>
> Some comments, cross linking to the "Why MyHDL" page (and vise-versa)
> could be useful.  We want to be useful setting expectations but also
> want to *highlight* the benefits :)
>
> In the _It is not well suited for gate level simulation_ section.  You
> might want to mention co-simulation.  A potential user might come away
> with the wrong impression that they will need to redo a fair amount of
> verification implementation in Verilog/VHDL.  Rather, they should use a
> Verilog/VHDL simulator in conjunction to verify structural-physical
> correctness.

Yes!  Being able to use the full power of Python in simulation AND co-simulation testbenches is possibly the one truly revolutionary aspect of MyHDL.  (IMHO, YMMV, IANAHDLD)

When trying to learn an HDL by looking at example circuits (and trying to learn circuits by reading HDL), I often found the testbench was often the best way to understand the designer's intent (and proper module use), especially when the code contained few comments and used oddly named signals.  Unfortunately, designers occasionally put little or no effort into their testbenches (at least in some of the public projects I've seen).  Python should make it easy(-ier) to create a thorough testbench with much less code (and effort, hopefully).

For any such undocumented and untested modules, writing a testbench is how I would approach understanding it (as well as providing a service to the community).  I'd much rather do that in Python than in any HDL.

I suspect I'll be getting lots of benefit from this feature of MyHDL long before I'm proficient with the rest of it.

This may, in fact, be an ideal entry point for a MyHDL tutorial: Start with a "black box" module, a written description of its interface and intended behavior, then write the testbench.  Leverage Python skills the reader may already possess.  (It will also ensure the entire toolchain has been properly installed.)  Later lessons could introduce MyHDL primitives, then have the reader use a good testbench to find and fix the error in a flawed circuit (where the fix would require use the primitives just introduced).

Test first, design second.  It would also teach the reader to become good at reading circuit descriptions before writing them.  Both pedagogically and practically, this seems to me to be a very sound approach, one I'd be very interested in pursuing!  And MyHDL may be the first HDL to make this approach practical.  I think I see an O'Reilly book here somewhere...


-BobC