Re: [myhdl-list] Example of MyHDL for Python Developers Documentation

[G. A. S. <g.a...@gm...>]

Hi Jan,

Let me try to say it in another way.  Please forgive any inaccuracies; its
been a few years! :-)

If my synthesizable hardware description was put in a simulation black box
(call it "hdl") with some simple API that could be used like:

hdl.start()
for time in range(1,whatever):
  output_signals = hdl.next(list_of_input_signals)

then as a software engineer I'd completely understand how to write a
complex simulation and testbench around it.  For example, if my "hdl"
object defined a PCI bus card I could pretty easily write Python code that
jams in a bunch of fake PCI requests and make sure the right stuff comes
out.  I could easily make up code that runs a bunch of these black boxes
simultaneously and use unsynthesizable python to "glue" them together to
make a larger system -- thereby simulating a subset of some larger system.
I could even have each black box "running" at different clock speeds.  Or I
could even hook the simulation black box up to the actual code that will
run on a CPU and talk to my FPGA.

So I (as a software professional) don't need myHDL to help me do that.
What I need is it to help me with is what's inside that black box.  But the
docs (but please remember my heavy use was several years ago) keep trying
to teach me how to do the testbench part.  This confused me because I kept
thinking I was writing synthesizable code.

And I think that the somewhat monolithic combination of both simulation and
synthesizable code actually limits what can be done.  In particular, in
software there has ALWAYS been a tension between two software
architectures, essentially the "external" or "inline" model.  In XML
parsing, its the difference between DOM and SAX.  In DOM you see the entire
tree and grab what you need (since the tree is parsed first).  In SAX you
wait for a callback that occurs when the parser lands on a particular tag.
Its the difference between Windows 3.1 (solely event driven) and Win 95
(threaded).  In the DOM model, the parser is done by the time the user code
accesses the XML.  They are separate.  In SAX, the user code is called
during parsing; the code is entangled and has restrictions (like you can't
access data that comes later in the XML doc).

My API example above is sort of the "DOM" style -- I'm in control of each
tick and inject all my simulation signals at the top.  I can choose to stop
the simulation at any time.  I can even fork it, save it, save the exact
internal state for every clock. etc.  And I can even do those things based
on an internal examination of "hdl".  My testbench code is clearly
separated from what is under test.

myHDL is more like "create a bunch of generators that give me the next
values & I'll grab them when I need them."  Then just say "go".  The
testbench is not as clearly separate.

But I'm not advocating one style; is limiting to force the user to adopt
one architecture or the other... modern software techniques allow both,
which is why we have both "threads" and "generators" in Python.

Cheers!
Andrew



On Thu, May 3, 2012 at 1:41 PM, Jan Decaluwe <ja...@ja...> wrote:

> On 05/03/2012 05:03 PM, G. Andrew Stone wrote:
> > I taught myself RTL using myHDL a long time ago and then learned
> > Verilog by looking at what it output and modifying it.  I'm still a
> > beginner with it though... I mean its not my job so I haven't done
> > much more then what people would do in college courses -- small stuff
> > like PWM LEDs, drive stepper motors, etc.
> >
> > But folks, I think that Christopher has a few good points.  It was
> > HARD to learn it (but easier then learning straight Verilog).
>
> Thanks for that comment - it means that I reached my goal your case:
> it is hard work, yes (see "Why MyHDL"), but as long as it's easier
> than straight Verilog (and free),one gains.
>
> > The biggest issue was figuring out what can be synthesized or not.  I
> > mean, from a SW developer's perspective, I know perfectly well how to
> > write a simulation at multiple abstraction levels.  In fact the whole
> > "yield" thing forces the simulation into a certain "style" which can
> > be limiting.  In essence, as a software professional, I don't need
> > myHDL to help me write them at multiple abstraction levels EXCEPT for
> > the lowest -- i.e. a synthesizable simulation.
>
> I don't understand that. If I want to verify a synthesizable RTL
> description, which is a special kind of an event-driven model, I
> need event-driven models and test benches as a verification
> environment. So I really need event-driven and high-level modeling
> combined - something MyHDL gives me and stock Python does not.
>
> Note also that your comment is the opposite of what Uri Nix just
> said in another post.
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>     Python as a HDL: http://www.myhdl.org
>     VHDL development, the modern way: http://www.sigasi.com
>     World-class digital design: http://www.easics.com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>