myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] How to make MyHDL Object-Oriented

[Christopher L. <loz...@fr...>]

On 5/4/12 5:04 AM, Jan Decaluwe wrote:
> On 05/04/2012 01:45 AM, Christopher Lozinski wrote:
>> Thanks enormously to Andy Stone for pointing out that MyHDL, while in
>> Python is not object-oriented.  There is no hardware module class, just
>> a generator, and decorator which are functional approaches.
> How can you even say this, 

Actually the wiki says it. 

http://www.myhdl.org/doc/0.6/manual/intro.html
In MyHDL, classic functions are used to model hardware modules. In
particular, the parameter list is used to define the interface.

I would rather see objects being used to model hardware modules.  In
particular the instance variables should be used to model the
interface.  (and internal signals).

Here is another one.
http://www.myhdl.org/doc/current/manual/modeling.html

In MyHDL, an instance is recursively defined as being either a sequence
of instances, or a generator. Hierarchy is modeled by defining instances
in a higher-level function, and returning them.

That does sound to me like a functional approach.  I would rather see
hardware modules defined "in a higher level object" a module with parent
and child nodes. 
I would expect a hierarchy of chip modules, each of which points to its
children and parents.

Then let me quote others: Andrew Stone said this is what he expected:

    In fact, what I thought myHDL was going to let me do is create
    classes that define blocks of logic at the RTL level
    (synthesizable), perhaps with inputs and output "Signals" as
    variables passed in the constructor and then by instantiating those
    classes I'd be in effect plunking down copies of that logic in the
    FPGA (or within larger logic blocks by instantiating these within
    the constructor of another class).  4 years ago I did not ever
    figure out how to do this... I don't think anything wrapped in a
    class was synthesizable back then.  But maybe that has changed now;
    I haven't tried using classes since.

And yes, Dillon wrote that he does this, but I think we will find the
details of how he does it are different than at least what I would
expect.  In particular MyHDL does not pass variables into the object
constructor, it passes them into the generator.  There are no parent or
child links.


> when the manual has a section about
> object-oriented modeling, which has a Queue class, which you have
> just been struggling with?

If I recall correctly, the Queue class is not inside a @always,
@instance, or @always_comb, so it is not synthesizable.  While MyHDL is
quite general, it is only the synthesizable stuff I am interested in.


Jan Decaluwe wrote: 

>Perhaps this stuff really is too hard for the "general python developer", though I 

>still don't understand why.

Because it does not fit the way we see the world.   Different people
have different world views.  I am doing my best to explain my world
view.  In particular one of my concepts is that every real world thing
should be represented by a class.  So flip flops, adders, multipliers
should each be represented by a class.  And then I mostly want the
documentation to be a listing of the classes, representing physical
objects,  available to me to work with.  And yes the existing MyHDL
documentation would also be useful.

I now understand it is a hugely different view from the prevailing view
on this mailing list.   And that is why we keep clashing.  It is why I
am just not able to 'get' MyHDL.  Because we are operating under two
different world views.  

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] How to make MyHDL Object-Oriented

[Jan D. <ja...@ja...>]

On 05/04/2012 01:45 AM, Christopher Lozinski wrote:
> Thanks enormously to Andy Stone for pointing out that MyHDL, while in
> Python is not object-oriented.  There is no hardware module class, just
> a generator, and decorator which are functional approaches.

How can you even say this, when the manual has a section about
object-oriented modeling, which has a Queue class, which you have
just been struggling with?

Perhaps this stuff really is too hard for the "general python
developer", though I still don't understand why.

One more attempt: MyHDL, the modeling language, is very general:
as long as you feed it a number of generators communicating
through signals, it is happy. It doesn't matter whether these
are created by functions, classes, subclasses, mixin classes,
multiple inheritance, whatever. MyHDL is therefore what you
want it to be - functional, applicative, procedural, object-oriented,
aspect oriented, whatever.

It is only when you need conversion that restrictions drop in,
but identifying MyHDL with conversion or synthesis restrictions
is a sign of basic misunderstanding.

I understand that this may not have been clear enough in the
past: but this should be fixed now with the What MyHDL is not page,
and when I separate synthesizable/non-synthesizable chapters
in the manual.

> No wonder I was not able to 'get' MyHDL.  I very much think in
> object-oriented terms.  Many years ago I wrote object-oriented
> manufacturing simulations of NCR's ASIC manufacturing plant.  It was a
> roaring success.
>
> The difference in mind-set is just enormous between a functional model,
> and an object-oriented model.  But I certainly do not want to get into a
> fight over it.
>
> So here is my proposal for what I need to do.
>
> http://wiki.myhdlclass.com:8080/OOHDL

Coupling a sensitivity list to a module makes no sense.

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

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

[Christopher L. <loz...@fr...>]

On 5/3/12 8:14 PM, Christopher Felton wrote:
>> I am personally all in favor of "doing whatever you want". But
>> > you can not expect that someone that jumps around has equal
>> > say in the "shared direction" of a project as those who are truly
>> > committed to it. That should be obvious.
>> >
> Amen to that!
Be tough on issues, soft on people. 

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

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

[Christopher F. <chr...@gm...>]

On 5/3/12 4:03 PM, Jan Decaluwe wrote:
> On 05/03/2012 06:30 PM, Christopher Lozinski wrote:
>>
>>>> My mistake.  It is easy to think of MyHDL as a shared project with
>>>> people having shared direction.  And then we get to discuss the shared
>>>> direction.  The reality is that each person does whatever they want.
>>>> Thank you for clearing up my understanding of open source projects.
>>
>>> Christopher, it sounds like you are being sarcastic here but if so in fact
>>> you really are mistaken about what happens in open source projects with no
>>> paid engineers.  The purpose of discussion is only to give a person ideas.
>>> That person will then go off and do whatever they want.  And whether that
>>> gets back into the main tree is entirely up to the owners of the project,
>>> who will do whatever they want with the submission :-).  If they don't take
>>> it you may get a fork...
>> Actually I was not being sarcastic.  I did not quite understand the
>> culture of open source projects.  Thank you for clearing that up.
>
> May I remind you and others that you certainly understand
> the "each person does whatever they want" part.
>
> A few weeks ago, you said that you preferred Migen, because you judged that
> you only needed concurrent statements. Just a few days ago, you gave
> us your final thoughts before moving to Verilog.
>
> I am personally all in favor of "doing whatever you want". But
> you can not expect that someone that jumps around has equal
> say in the "shared direction" of a project as those who are truly
> committed to it. That should be obvious.
>

Amen to that!

Re: [myhdl-list] How to make MyHDL Object-Oriented

[Tom D. <td...@di...>]

I use classes for all the modules I plan on re-using. Very useful. The 
beauty of Python classes are even a hardware guy can understand how to 
use them.

On 05/03/2012 06:45 PM, Christopher Lozinski wrote:
> Thanks enormously to Andy Stone for pointing out that MyHDL, while in
> Python is not object-oriented.  There is no hardware module class, just
> a generator, and decorator which are functional approaches.
>
> No wonder I was not able to 'get' MyHDL.  I very much think in
> object-oriented terms.  Many years ago I wrote object-oriented
> manufacturing simulations of NCR's ASIC manufacturing plant.  It was a
> roaring success.
>
> The difference in mind-set is just enormous between a functional model,
> and an object-oriented model.  But I certainly do not want to get into a
> fight over it.
>
> So here is my proposal for what I need to do.
>
> http://wiki.myhdlclass.com:8080/OOHDL
>
> For those who were not able to access the wiki, please let me know.  One
> person reported a problem, mostly he figured out it is because he is
> behind a corporate firewall.
>

[myhdl-list] How to make MyHDL Object-Oriented

[Christopher L. <loz...@fr...>]

Thanks enormously to Andy Stone for pointing out that MyHDL, while in
Python is not object-oriented.  There is no hardware module class, just
a generator, and decorator which are functional approaches.

No wonder I was not able to 'get' MyHDL.  I very much think in
object-oriented terms.  Many years ago I wrote object-oriented
manufacturing simulations of NCR's ASIC manufacturing plant.  It was a
roaring success.

The difference in mind-set is just enormous between a functional model,
and an object-oriented model.  But I certainly do not want to get into a
fight over it.

So here is my proposal for what I need to do. 

http://wiki.myhdlclass.com:8080/OOHDL

For those who were not able to access the wiki, please let me know.  One
person reported a problem, mostly he figured out it is because he is
behind a corporate firewall. 

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

[myhdl-list] Wiki Errors

[Christopher L. <loz...@fr...>]

You have a legitimate point that my wiki has errors.  One solution is
for you to try to fix them all, that must be hugely frustrating.  How
about if we post a heading on the wiki saying this is documentation
being written by a newbie, and contains errors.  Then if you or others
want to help with a particular page, we can clean up that page, remove
the warning and maybe even move it over to the MyHDL website.

It is good to have newbies write documentation, there just needs to be a
process to manage it.  And then sign off as the page quality improves. 

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

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

[Jan D. <ja...@ja...>]

On 05/03/2012 06:30 PM, Christopher Lozinski wrote:
>
>>> My mistake.  It is easy to think of MyHDL as a shared project with
>>> people having shared direction.  And then we get to discuss the shared
>>> direction.  The reality is that each person does whatever they want.
>>> Thank you for clearing up my understanding of open source projects.
>
>> Christopher, it sounds like you are being sarcastic here but if so in fact
>> you really are mistaken about what happens in open source projects with no
>> paid engineers.  The purpose of discussion is only to give a person ideas.
>> That person will then go off and do whatever they want.  And whether that
>> gets back into the main tree is entirely up to the owners of the project,
>> who will do whatever they want with the submission :-).  If they don't take
>> it you may get a fork...
> Actually I was not being sarcastic.  I did not quite understand the
> culture of open source projects.  Thank you for clearing that up.

May I remind you and others that you certainly understand
the "each person does whatever they want" part.

A few weeks ago, you said that you preferred Migen, because you judged that
you only needed concurrent statements. Just a few days ago, you gave
us your final thoughts before moving to Verilog.

I am personally all in favor of "doing whatever you want". But
you can not expect that someone that jumps around has equal
say in the "shared direction" of a project as those who are truly
committed to it. That should be obvious.

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

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

[Jan D. <ja...@ja...>]

On 05/03/2012 10:23 PM, G. Andrew Stone wrote:
> 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.

I hear what you say - but would this not mean that you had
to write an ad-hoc event-driven system, similar to what
MyHDL provides out of the box?

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

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
>

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

[Christopher L. <loz...@fr...>]

>> My mistake.  It is easy to think of MyHDL as a shared project with
>> people having shared direction.  And then we get to discuss the shared
>> direction.  The reality is that each person does whatever they want.
>> Thank you for clearing up my understanding of open source projects.

> Christopher, it sounds like you are being sarcastic here but if so in fact
> you really are mistaken about what happens in open source projects with no
> paid engineers.  The purpose of discussion is only to give a person ideas.
> That person will then go off and do whatever they want.  And whether that
> gets back into the main tree is entirely up to the owners of the project,
> who will do whatever they want with the submission :-).  If they don't take
> it you may get a fork...
Actually I was not being sarcastic.  I did not quite understand the
culture of open source projects.  Thank you for clearing that up.

> don't be a help
> vampire: http://slash7.com/2006/12/22/vampires/
Point well taken. 

On 5/3/12 10:03 AM, G. Andrew Stone wrote:
> Then write it... 
I am doing that.  That is why I wrote the starter Documentation Page. A
great way to contribute to open source is to write documentation.  By
now there is quite a bit of stuff on my wiki.

wiki.myhdlclass.com:8080

Some of it is even correct.

I just have to go and figure out why some people are able to access it
and others not.

On 5/3/12 10:03 AM, G. Andrew Stone wrote:
> In fact, what I thought myHDL was going to let me do is create classes that
> define blocks of logic at the RTL level (synthesizable), perhaps with
> inputs and output "Signals" as variables passed in the constructor and then
> by instantiating those classes I'd be in effect plunking down copies of
> that logic in the FPGA (or within larger logic blocks by instantiating
> these within the constructor of another class).  4 years ago I did not ever
> figure out how to do this... I don't think anything wrapped in a class was
> synthesizable back then.  But maybe that has changed now; I haven't tried
> using classes since.
Brilliant.  Thank you.  Now you have given me a clear idea as to where
MyHDL should be headed.    Here is how to decorate a class method.

http://stackoverflow.com/questions/1367514/how-to-decorate-a-method-inside-a-class

Now if we just agree that the method hardwareModule() is the decorated
method that simulates and converts a class, and the instance variables
are the signals, we can create a more Object-Oriented version of
MyHDL.   Then we can subclass existing hardware modules.  Maybe it will
not convert easily.

t must be more complicated than that.

Chris

Re: [myhdl-list] What is not convertible.

[Jan D. <ja...@ja...>]

On 05/02/2012 06:49 PM, Christopher Lozinski wrote:
> The manual has a great section on the convertible subset.  For those
> guys who are design engineers, it totally makes sense.  For those of us
> who are newer to digital circuit design, it is not quite clear what is
> not convertible.
>
> So I wrote up a section on my wiki. What is not convertible.
>
> wiki.myhdlclass.com:8080/WhatIsNotConvertible
>
> Really what this is telling software developers is what you cannot do at
> the RTL modeling level.

"Things should be kept as simple as possible, but not simpler." (Einstein)

You try to make things simpler than they really are. The result is a
page full of errors and inaccuracies that would greatly increase confusion.

* The convertible subset is not the same as the RTL level. It is much
broader, the intention is that it is never an obstruction for synthesis.
But don't think for a moment that anything that converts is also
synthesizable. In fact, it doesn't teach you anything about the RTL
level.

* Python objects not convertible? Well, isn't anything an object
in Python - some of those surely are convertible.

* Things outside a decorator not convertible? Well, be careful with
the message here. Conversion works after elaboration, which means
you can do all kinds of crazy things outside decorated functions,
without conversion restrictions.

* tuples of.. and list of ... Well, one should check the table to
learn about restrictions.

Note that my post of corrections is longer than the page
your wrote. This really takes up a lot of energy.

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

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

[Jan D. <ja...@ja...>]

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).  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.  But -- no offense intended -- judging by the TCL (and C) code I've seen I can certain see how hardware guys might really need it!!! :-)
>
> In this example: http://www.myhdl.org/doc/current/manual/modeling.html#object-oriented-modeling its still unclear whether the "queue" class was synthesizable or not (just by reading the docs, I mean you could try it!).  But it would be really nice if the document clearly marked what is expected to be synthesizable.  Frankly it would be awesome if unsynthesizable stuff was magically highlighted in red in my emacs editor but I don't think that will happen soon :-).
>
> In fact, what I thought myHDL was going to let me do is create classes that define blocks of logic at the RTL level (synthesizable), perhaps with inputs and output "Signals" as variables passed in the constructor and then by instantiating those classes I'd be in effect plunking down copies of that logic in the FPGA (or within larger logic blocks by instantiating these within the constructor of another class).  4 years ago I did not ever figure out how to do this... I don't think anything wrapped in a class was synthesizable back then.  But maybe that has changed now; I haven't tried using classes since.
>
> Some comments inline:
>
>
> On Thu, May 3, 2012 at 9:35 AM, Christopher Lozinski <loz...@fr... <mailto:loz...@fr...>> wrote:
>
>     So here is an example of the  what I think python developers would like
>     to see.
>
>     http://wiki.myhdlclass.com:8080/Documentation
>
>     The embedded Decorator link is an excellent resource.  I make the clock
>     cycle on Delay(1) not 20.  I try to describe the digital design issues
>     for consumption by a python developer.
>
>     As for the other discussions, I am not quite sure why I generate so much
>     negative response.  I really liked David's comment.
>
>     On 5/3/12 6:16 AM, David Arnold wrote:
>      > My view of gratis software is that I'm grateful for what's given and the creator(s) are under no obligation to do anything.
>     My mistake.  It is easy to think of MyHDL as a shared project with
>     people having shared direction.  And then we get to discuss the shared
>     direction.  The reality is that each person does whatever they want.
>     Thank you for clearing up my understanding of open source projects.
>
>
> Christopher, it sounds like you are being sarcastic here but if so in fact you really are mistaken about what happens in open source projects with no paid engineers.  The purpose of discussion is only to give a person ideas.  That person will then go off and do whatever they want.  And whether that gets back into the main tree is entirely up to the owners of the project, who will do whatever they want with the submission :-).  If they don't take it you may get a fork...
>
> The fact of the matter is that Jan seems to have written myHDL to solve issues in complex hardware design and hardware simulation that only experts in the field can understand (either that or they are such totally obvious mistakes in doing a simulation that any software person would think OMG!! so we think that that CAN'T be the real issue :-) ) and a lot of us are trying to twist the project to: 1. make it really easy to do quick and dirty FPGA hackups 2. learn how to program these "seas of gates".
>
>
>     Nor am I asking for the senior MyHDL developers to be writing this.
>     Writing up documentation is a great way to learn the systems.   But if
>     they would be so kind as to proofread it that would be a huge help.
>
>
> Then write it... but honestly WRT proofreading I have one comment.  From reading this list it seems like you keep claiming the X does not exist and then Jan has to go off and point to the spot in the docs.  So the law clerk is having the lawyer run around and look stuff up... don't be a help vampire: http://slash7.com/2006/12/22/vampires/
>
> Cheers!
> Andrew
>
>
>
> ------------------------------------------------------------------------------
> 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


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

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

[Jan D. <ja...@ja...>]

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

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

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

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).  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.  But -- no offense intended -- judging by the TCL (and C) code
I've seen I can certain see how hardware guys might really need it!!! :-)

In this example:
http://www.myhdl.org/doc/current/manual/modeling.html#object-oriented-modelingits
still unclear whether the "queue" class was synthesizable or not (just
by reading the docs, I mean you could try it!).  But it would be really
nice if the document clearly marked what is expected to be synthesizable.
Frankly it would be awesome if unsynthesizable stuff was magically
highlighted in red in my emacs editor but I don't think that will happen
soon :-).

In fact, what I thought myHDL was going to let me do is create classes that
define blocks of logic at the RTL level (synthesizable), perhaps with
inputs and output "Signals" as variables passed in the constructor and then
by instantiating those classes I'd be in effect plunking down copies of
that logic in the FPGA (or within larger logic blocks by instantiating
these within the constructor of another class).  4 years ago I did not ever
figure out how to do this... I don't think anything wrapped in a class was
synthesizable back then.  But maybe that has changed now; I haven't tried
using classes since.

Some comments inline:


On Thu, May 3, 2012 at 9:35 AM, Christopher Lozinski <
loz...@fr...> wrote:

> So here is an example of the  what I think python developers would like
> to see.
>
> http://wiki.myhdlclass.com:8080/Documentation
>
> The embedded Decorator link is an excellent resource.  I make the clock
> cycle on Delay(1) not 20.  I try to describe the digital design issues
> for consumption by a python developer.
>
> As for the other discussions, I am not quite sure why I generate so much
> negative response.  I really liked David's comment.
>
> On 5/3/12 6:16 AM, David Arnold wrote:
> > My view of gratis software is that I'm grateful for what's given and the
> creator(s) are under no obligation to do anything.
> My mistake.  It is easy to think of MyHDL as a shared project with
> people having shared direction.  And then we get to discuss the shared
> direction.  The reality is that each person does whatever they want.
> Thank you for clearing up my understanding of open source projects.
>
>
Christopher, it sounds like you are being sarcastic here but if so in fact
you really are mistaken about what happens in open source projects with no
paid engineers.  The purpose of discussion is only to give a person ideas.
That person will then go off and do whatever they want.  And whether that
gets back into the main tree is entirely up to the owners of the project,
who will do whatever they want with the submission :-).  If they don't take
it you may get a fork...

The fact of the matter is that Jan seems to have written myHDL to solve
issues in complex hardware design and hardware simulation that only experts
in the field can understand (either that or they are such totally obvious
mistakes in doing a simulation that any software person would think OMG!!
so we think that that CAN'T be the real issue :-) ) and a lot of us are
trying to twist the project to: 1. make it really easy to do quick and
dirty FPGA hackups 2. learn how to program these "seas of gates".


Nor am I asking for the senior MyHDL developers to be writing this.
> Writing up documentation is a great way to learn the systems.   But if
> they would be so kind as to proofread it that would be a huge help.
>

Then write it... but honestly WRT proofreading I have one comment.  From
reading this list it seems like you keep claiming the X does not exist and
then Jan has to go off and point to the spot in the docs.  So the law clerk
is having the lawyer run around and look stuff up... don't be a help
vampire: http://slash7.com/2006/12/22/vampires/

Cheers!
Andrew

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

[Christopher L. <loz...@fr...>]

So here is an example of the  what I think python developers would like
to see.

http://wiki.myhdlclass.com:8080/Documentation

The embedded Decorator link is an excellent resource.  I make the clock
cycle on Delay(1) not 20.  I try to describe the digital design issues
for consumption by a python developer. 

As for the other discussions, I am not quite sure why I generate so much
negative response.  I really liked David's comment.

On 5/3/12 6:16 AM, David Arnold wrote:
> My view of gratis software is that I'm grateful for what's given and the creator(s) are under no obligation to do anything. 
My mistake.  It is easy to think of MyHDL as a shared project with
people having shared direction.  And then we get to discuss the shared
direction.  The reality is that each person does whatever they want. 
Thank you for clearing up my understanding of open source projects.

Nor am I asking for the senior MyHDL developers to be writing this. 
Writing up documentation is a great way to learn the systems.   But if
they would be so kind as to proofread it that would be a huge help.  
Obviously no one is under any obligation to do so.

-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] When to use @always, @instance and @always_comb

[David A. <da...@po...>]

My view of gratis software is that I'm grateful for what's given and the creator(s) are under no obligation to do anything. 

If you phrase the question differently though: would Python programmers seeking to learn digital design with MyHDL find some basic digital design tutorials using MyHDL useful, then I think the answer is yes. 

In other words, I think there's a large audience for "Introduction to Digital Design with MyHDL", but that's an opportunity not an obligation. 




d


On 02/05/2012, at 22:18, Tom Dillon <td...@di...> wrote:

> OK, but do you expect the MyHDL documentation to teach you basics of digital design?
> 
> On 05/02/2012 10:22 PM, David Arnold wrote:
>> 
>> If you already know Python, and want to learn digital design, MyHDL is attractive. Plus, there are assertions that it's actually better than VHDL or Verilog anyway.
>> 
>> 
>> 
>> 
>> d
>> 
>> 
>> On 02/05/2012, at 22:03, Tom Dillon <td...@di...> wrote:
>> 
>>> Why is would anyone not familiar with "Digital Circuit Design" be using MyHDL?
>>> 
>>> 
>>> On 05/02/2012 07:34 PM, Christopher Lozinski wrote:
>>>> 
>>>>> Am I missing something here, why would the MyHDL documentation be
>>>>> expected to teach hardware design?
>>>>> 
>>>>> Last week I used a Python package to allow me to read/write an Excel
>>>>> spreadsheet. I did not expect the documentation for that package to
>>>>> teach me how to use Excel. Why would it?
>>>> Great question.  The problem with MyHDL is that you have two
>>>> computational models, Python and Digital Circuit Design.    Unlike a
>>>> spreadsheet, which is not part of Python,  Digital Circuit Design is
>>>> part of MyHDL.  The documentation needs to highlight both or it gets
>>>> very confusing to people who are not already Digital Circuit Designers. 
>>>> Currently the documentation does a good job describing the python, but
>>>> not such a good job describing digital circuit design.  My proposal was
>>>> a way to make the Digital Circuit Models part more explicit.   Push them
>>>> forward, as the python part is already taken care of.  IMHO that would
>>>> make things much clearer.
>>>> 
>>>> Then there is the argument about MyHDL being a tiny community, and how
>>>> important it is for us to reach out to the larger python community.  But
>>>> in an open source world, where developers do things for their own
>>>> benefit, that does not carry much weight. 
>>>> 
>>> ------------------------------------------------------------------------------
>>> 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
>> 
>> 
>> ------------------------------------------------------------------------------
>> 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
> ------------------------------------------------------------------------------
> 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

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Jan D. <ja...@ja...>]

On 05/03/2012 06:55 AM, Christopher Lozinski wrote:

> This is all really about Python and MyHDL. Nothing about chips. Not
> that much about computational models of circuits. And in particular,
> not at all clear where chip modeling ends and other modeling begins.
> Nor what kind of chips use @always, @instance and @always_comb.


That is clearly not true. The section on RTL modeling starts as follows:

"The present section describes how MyHDL supports RTL style modeling
  as is typically used for synthesizable models."

Then it moves on to describe templates for "computational models"
for combinatorial logic and for sequential logic. Just two, and
with those two you can do everything :-) And then it shows how to
describe an FSM, which is what you will be using all the time.


>  The focus is not on the models of digital circuits, it is on the features
> of MyHDL.

This is the MyHDL manual. In the RTL section, it shows you how you can
use MyHDL to write models that a synthesis tool will turn into digital
circuits. In the next section, it shows you can do all kinds of other
interesting things at a higher level.

Let me try again: I think your confusion comes from the mindset. It is
wrong to look at any MyHDL construct, like Signals or decorators, and
immediately worry about what the corresponding hardware implementation
is. That is just not how it works. For example: the 3 decorators exist
because they let you easily describe useful event-driven behaviors,
*not* because they correspond uniquely to some hardware implementation.

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

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Jan D. <ja...@ja...>]

On 05/03/2012 07:26 AM, Christopher Felton wrote:
> On 5/2/12 10:22 PM, David Arnold wrote:
>> If you already know Python, and want to learn digital design, MyHDL is
>> attractive. Plus, there are assertions that it's actually better than
>> VHDL or Verilog anyway.
>>
>>
>> d
>
> There seems to be interest in the above; Python programmer to MyHDL
> hardware describer :).  The question is where should this
> information/tutorial live (and who is going to write it).
>
> "HDL for programmers" or "MyHDL for Python Programmers"?  I think this
> would be a separate tutorial that someone would need to put together.
> This would take some *art* to imagine how to concisely transition the
> world of Python free programming to describing hardware.  Part of it
> would be to first teach digital systems; the "what" is being
> described/modeled.
>
> I would imagine the low-level flip-flop, gates, etc would not be covered
> in such a tutorial.  It would be you have N inputs and M outputs of a
> digital system and how do you describe the behavior such that the
> description is syntheziable most likely by FPGA tools.

Exactly!

> I think most agree the manual isn't the right spot for a tutorial of
> this nature.  There are folks on this list that could write such a
> tutorial but I don't know if anyone has the bandwidth.

Right again!




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

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Jan D. <ja...@ja...>]

On 05/03/2012 02:30 AM, David Greenberg wrote:
> The problem is that all of the references are in Verilog and VHDL. If
> you want to start using MyHDL now, you first have to learn Verilog,
> then you can start using MyHDL. This is different than how software
> languages have progressed, in that you don't, i.e. need to know C to
> learn Ruby.

Personally, I don't think there's a good reference that teaches
HDL-based design. If you have one, let me know.

The books I know tend to teach how to describe FFs, gates,
adders, Moore, Mealy etc in Verilog/VHDL - something no one
really does (I hope) because we use synthesis for that. Then
there is an appendix about synthesis instead making it an integral
part of the material.

Actually I think the section about RTL in MyHDL is not that
bad - it teaches the templates that we all use for synthesizable
logic, and includes material about FSM design, which I think is
the basic building block in RTL design.

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

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Jan D. <ja...@ja...>]

On 05/02/2012 08:52 PM, Uri Nix wrote:
> IMHO it /is/ confusing, since the previous topics in the chapter are
> synthesis oriented.
>
> I have had very good experience with MyHDL for system modelling,
> which uses a different mindset than the FPGA direction. It is
> amazingly powerful, follows similar idioms as in SystemC with the
> ease of Python, and might use some more mention.

Point taken. What I could easily do of course is break up the
three sections in separate chapters. Then add an intro to the
chapter making it explicit that RTL is for synthesis, and
high-level modeling not. In fact, the content is bound
to grow in future releases so breaking this up seems good
for clarity anyway.


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

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Christopher F. <chr...@gm...>]

On 5/2/12 10:22 PM, David Arnold wrote:
> If you already know Python, and want to learn digital design, MyHDL is
> attractive. Plus, there are assertions that it's actually better than
> VHDL or Verilog anyway.
>
>
> d

There seems to be interest in the above; Python programmer to MyHDL 
hardware describer :).  The question is where should this 
information/tutorial live (and who is going to write it).

"HDL for programmers" or "MyHDL for Python Programmers"?  I think this 
would be a separate tutorial that someone would need to put together. 
This would take some *art* to imagine how to concisely transition the 
world of Python free programming to describing hardware.  Part of it 
would be to first teach digital systems; the "what" is being 
described/modeled.

I would imagine the low-level flip-flop, gates, etc would not be covered 
in such a tutorial.  It would be you have N inputs and M outputs of a 
digital system and how do you describe the behavior such that the 
description is syntheziable most likely by FPGA tools.

I think most agree the manual isn't the right spot for a tutorial of 
this nature.  There are folks on this list that could write such a 
tutorial but I don't know if anyone has the bandwidth.

Right now the resources would be the manual, cookbook, mailing-list, 
etc. for a beginner.

Regards,
Chris

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Christopher L. <loz...@fr...>]

On 5/2/12 9:18 PM, Tom Dillon wrote:
> OK, but do you expect the MyHDL documentation to teach you basics of
> digital design? 
No not really.  But I do want a clear set of digital designs, presented
one at a time in the docs. Each one describing a new MyHDL concept.  
Here is the index for the section on modelling.

  * Modeling techniques
    <http://www.myhdl.org/doc/current/manual/modeling.html#>
      o Structural modeling
        <http://www.myhdl.org/doc/current/manual/modeling.html#structural-modeling>

          + Conditional instantiation
            <http://www.myhdl.org/doc/current/manual/modeling.html#conditional-instantiation>
          + Lists of instances and signals
            <http://www.myhdl.org/doc/current/manual/modeling.html#lists-of-instances-and-signals>
          + Converting between lists of signals and bit vectors
            <http://www.myhdl.org/doc/current/manual/modeling.html#converting-between-lists-of-signals-and-bit-vectors>
          + Inferring the list of instances
            <http://www.myhdl.org/doc/current/manual/modeling.html#inferring-the-list-of-instances>
      o RTL modeling
        <http://www.myhdl.org/doc/current/manual/modeling.html#rtl-modeling>

          + Combinatorial logic
            <http://www.myhdl.org/doc/current/manual/modeling.html#combinatorial-logic>

              # Template
                <http://www.myhdl.org/doc/current/manual/modeling.html#template>
              # Example
                <http://www.myhdl.org/doc/current/manual/modeling.html#example>
          + Sequential logic
            <http://www.myhdl.org/doc/current/manual/modeling.html#sequential-logic>

              # Template
                <http://www.myhdl.org/doc/current/manual/modeling.html#model-seq-templ>
              # Example
                <http://www.myhdl.org/doc/current/manual/modeling.html#model-seq-ex>
          + Finite State Machine modeling
            <http://www.myhdl.org/doc/current/manual/modeling.html#finite-state-machine-modeling>
      o High level modeling
        <http://www.myhdl.org/doc/current/manual/modeling.html#high-level-modeling>

          + Modeling with bus-functional procedures
            <http://www.myhdl.org/doc/current/manual/modeling.html#modeling-with-bus-functional-procedures>
          + Modeling memories with built-in types
            <http://www.myhdl.org/doc/current/manual/modeling.html#modeling-memories-with-built-in-types>
          + Modeling errors using exceptions
            <http://www.myhdl.org/doc/current/manual/modeling.html#modeling-errors-using-exceptions>
          + Object oriented modeling
            <http://www.myhdl.org/doc/current/manual/modeling.html#object-oriented-modeling>


This is all really about Python and MyHDL.  Nothing about chips.  Not
that much about computational models of circuits.  And in particular,
not at all clear where chip modeling ends and other modeling begins. 
Nor what kind of chips use  @always, @instance and @always_comb. The
focus is not on the models of digital circuits, it is on the features of
MyHDL.

How about structuring it like:
   Flip Flop
   Signal
   Clock
   Wires
   Ram Model
   Rom Model
   Fixed Point
   Sequential Logic
   Finite State Machine
   Bus.
   Etc.

Then each chip section could describe one of the features of MyHDL.  I
am sure the hardware guys can think of a hardware example that
illustrates each of the above concepts. 

Actually this approach has the real nice property, that you are
effectively documenting the existing components.  Right now things are
scattered, it took me a while to find the memory models and the fixed
point models.  I did not realize they existed.   And more importantly
you are publishing a series of digital circuit models.  The software
developers can figure out the MyHDL commands.  The digital circuit
models is where they need the help. 



-- 
Regards
Christopher Lozinski

Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com

Expect a paradigm shift.
http://MyHDL.org

Re: [myhdl-list] When to use @always, @instance and @always_comb

[Tom D. <td...@di...>]

OK, but do you expect the MyHDL documentation to teach you basics of 
digital design?

On 05/02/2012 10:22 PM, David Arnold wrote:
> If you already know Python, and want to learn digital design, MyHDL is 
> attractive. Plus, there are assertions that it's actually better than 
> VHDL or Verilog anyway.
>
>
>
>
> d
>
>
> On 02/05/2012, at 22:03, Tom Dillon <td...@di... 
> <mailto:td...@di...>> wrote:
>
>> Why is would anyone not familiar with "Digital Circuit Design" be 
>> using MyHDL?
>>
>>
>> On 05/02/2012 07:34 PM, Christopher Lozinski wrote:
>>>> Am I missing something here, why would the MyHDL documentation be
>>>> expected to teach hardware design?
>>>>
>>>> Last week I used a Python package to allow me to read/write an Excel
>>>> spreadsheet. I did not expect the documentation for that package to
>>>> teach me how to use Excel. Why would it?
>>> Great question.  The problem with MyHDL is that you have two
>>> computational models, Python and Digital Circuit Design.    Unlike a
>>> spreadsheet, which is not part of Python,  Digital Circuit Design is
>>> part of MyHDL.  The documentation needs to highlight both or it gets
>>> very confusing to people who are not already Digital Circuit Designers.
>>> Currently the documentation does a good job describing the python, but
>>> not such a good job describing digital circuit design.  My proposal was
>>> a way to make the Digital Circuit Models part more explicit.   Push them
>>> forward, as the python part is already taken care of.  IMHO that would
>>> make things much clearer.
>>>
>>> Then there is the argument about MyHDL being a tiny community, and how
>>> important it is for us to reach out to the larger python community.  But
>>> in an open source world, where developers do things for their own
>>> benefit, that does not carry much weight.
>>>
>> ------------------------------------------------------------------------------
>> 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... 
>> <mailto:myh...@li...>
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
> ------------------------------------------------------------------------------
> 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

Re: [myhdl-list] When to use @always, @instance and @always_comb

[David A. <da...@po...>]

If you already know Python, and want to learn digital design, MyHDL is attractive. Plus, there are assertions that it's actually better than VHDL or Verilog anyway.




d


On 02/05/2012, at 22:03, Tom Dillon <td...@di...> wrote:

> Why is would anyone not familiar with "Digital Circuit Design" be using MyHDL?
> 
> 
> On 05/02/2012 07:34 PM, Christopher Lozinski wrote:
>> 
>>> Am I missing something here, why would the MyHDL documentation be
>>> expected to teach hardware design?
>>> 
>>> Last week I used a Python package to allow me to read/write an Excel
>>> spreadsheet. I did not expect the documentation for that package to
>>> teach me how to use Excel. Why would it?
>> Great question.  The problem with MyHDL is that you have two
>> computational models, Python and Digital Circuit Design.    Unlike a
>> spreadsheet, which is not part of Python,  Digital Circuit Design is
>> part of MyHDL.  The documentation needs to highlight both or it gets
>> very confusing to people who are not already Digital Circuit Designers. 
>> Currently the documentation does a good job describing the python, but
>> not such a good job describing digital circuit design.  My proposal was
>> a way to make the Digital Circuit Models part more explicit.   Push them
>> forward, as the python part is already taken care of.  IMHO that would
>> make things much clearer.
>> 
>> Then there is the argument about MyHDL being a tiny community, and how
>> important it is for us to reach out to the larger python community.  But
>> in an open source world, where developers do things for their own
>> benefit, that does not carry much weight. 
>> 
> ------------------------------------------------------------------------------
> 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