myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Migen logic design toolbox - now with simulator

[Sébastien B. <seb...@mi...>]

On 03/21/2012 10:43 AM, Sébastien Bourdeauducq wrote:
> comb += [If(a[i], pos.eq(i)) for i in downrange(a.bv.width)]

Of course, it should be "range" here, not "downrange".

S.

Re: [myhdl-list] Migen logic design toolbox - now with simulator

[Sébastien B. <seb...@mi...>]

Hi,

On 03/19/2012 01:30 PM, Jan Decaluwe wrote:
>> If you are talking about VHDL variables / blocking Verilog assignments
>> that can be used to synthesize sequential code that "executes" in one
>> cycle, then they are supported too (with the "variable" property of the
>> Signal object).
>
> That is what I call "horrible". These things are confusing enough,
> even in VHDL that makes a clear distinction between signals
> and variables. MyHDL improves further on this by using a
> dedicated, distinctive attribute assignment for Signal
> assignment.

Well, it's just a small detail, no need to break such a fuss about it. 
What would you propose then? replace the "variable" property simply with 
the use of a different assignment? or enforce that another assignment 
method is used when the "variable" property is set?

> def MsbDetector(pos, a):
>       """Return the bit position of the msb."""
>
>       @always_comb
>       def logic():
>           pos.next = 0
>           for i in downrange(len(a)):
>               if a[i] == 1:
>                   pos.next = i
>                   break
>
>       return logic

(...)

> How would this look like in Migen?

comb += [If(a[i], pos.eq(i)) for i in downrange(a.bv.width)]

Notes:
1. the default 0 is implicit (reset value of a combinatorial signal)
2. you can build the pos signal with the right size using bits_for:
pos = Signal(BV(bits_for(a.bv.width-1)))
3. we should add len() support for signals, thanks for the reminder :)
4. you can either assume the synthesizer will automagically build an 
optimized structure (it doesn't always), or use a bit more control, as in:
http://www.ohwr.org/projects/tdc-core/repository/revisions/master/entry/core/tdc_lbc.vhd
It's VHDL, but you could do the same with Migen too.

> So far for elegance

One line :)

> and parametrizability.

In this example, it's just as parametrizable as yours. In general, Migen 
is more parametrizable than MyHDL. Let's have another simple example: 
how would you parametrize the number of wait states (removing them 
entirely when the parameter is 0) at different points of a FSM?

> Well, no. Look at the test bench code versus Migen code and
> note that the modeling paradigm is entirely different.
> But in practice, today's high-level model that is part
> of the verification environment becomes tomorrow's
> synthesizable model and vice versa.

Following the same logic, you could say that all hardware and software 
designs should be written using high level languages such as Python, 
Ruby or Lisp normally, and hope that one day some magical synthesizer 
will make them fast and optimized on FPGA, ASIC and CPU. Given that Lisp 
is still slow more than 50 years after its invention, let me have doubts 
about this position.

Or you can be pragmatic and do things like Migen.

> Very often, this even happens within the same project.

Can you give some examples?

Sébastien

Re: [myhdl-list] Conversion of class methods

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

<snip>
>>>
>>> As for your other questions, I find it a bit weird that the "signal
>>> containers" MEP refers to "classes" as well. I don't think that
>>> classes are normally considered containers even if strictly speaking
>>> they are. Perhaps it is because they are so much more than that...
>>> So my 0.02$ is that that part should be rolled into the MEP 108.
>>
>> What united the classes and other containers, in my mind, is how a
>> Signal and numeric values embedded in a "container" is transformed.
>> You are correct, a class can be a super set but it is also
>> container.  The MEP only covers the container part of the class, that
>> is Signals, constants, and variables (?) as class attributes.
>
> Well, I think we should support classes, in the end, list and signals
> are also classes, and I think we shouldn't restrict cases like defining
> a custom container class. I think the problem here is how to access
> its members (index or attributes), I mean in the implementation.

I created a stackoverflow question, http://bit.ly/wxCQqA,  for this. 
AFAIK it is possible in both cases.

>
> However, following the idea of "baby steps", I agree on starting only
> with lists and dicts. Also, note that in this objects, the access to its
> members is done by indexing.
>

Classes can be accessed via the __dict__ or through attributes (which 
the attributes translates to the __dict__).  Classes could be handled 
the same as a dict, resolving the path (ast tree) between the attribute 
node and the name node.  In MEP-108 is a proposed translation rule from 
"container" to flat netlist.

The current proposed plan is:

MEP-108 conversion of class methods.  This only addresses the "self" 
port and the _extractHierarchy.  The class method with generators would 
have the same ability as the current functions with generators.

MEP-107 signal containers.  This addresses when a signal is embedded in 
a dict, class, or heterogeneous list (homogeneous lists currently 
supported).  These are grouped together (in my mind they are related), 
and the same "rule" would be applied for converting the hierarchical 
structures to a flat netlist.

Once both MEPS are implemented common support of classes would be 
enabled.  MEP-108 is the more straight-forward and was the intended 
first to be implemented, MEP-107 more involved, more conversation 
required.

Thanks for the comments!
Chris

Re: [myhdl-list] Conversion of class methods

[Oscar D. D. <osc...@gm...>]

El Sat, 17 Mar 2012 09:34:21 -0500
Christopher Felton <chr...@gm...> escribió:

> <snip>
>
> > > Performing a quick test by searching for "self" in the argument
> > > list and ignoring the self argument will render the object method
> > > convertible. 
> > > Adding these changes to
> > >    _AnalyzeTopFuncVisitor.vist_FunctionDev(...) (_analyze.py)
> > > allows a top-level class method and buried methods to be
> > > converted. I have prototyped and created some tests which can be
> > > viewed here,
> > > https://bitbucket.org/cfelton/myhdl-0.8-dev-containers/overview
> > > (clone of the myhdl 0.8 dev, see notes at the end).
> >
> > Coming back to the important part of your message, you are right
> > that calling the first method argument "self" is just a convention,
> > not a requirement. Nevertheless I've never seen any python code
> > that does not call the first method argument "self". Thus I don't
> > think you should worry too much about it. I think that it would be
> > safe to make that a requirement for MyHDL if you do not find a
> > better way to differentiate between funcions and class methods.

Note that, although the name can be anything, it always be the first
unnamed argument. Checking the _AnalyzeTopFuncVisitor
(conversion/analyze.py) function, it can extract all the argument list
on strings, and assign them to all the signal objects, So, we should
check if the list of strings and the list of signals have equal length.
Otherwise, the first argument is a "self" object, and should be
ignored on the list of strings (check "argnames" and "self.args"
inside the function). I know it looks like a "ugly hack", when I
get a better understanding of ast I check this again.

> >
> > As for your other questions, I find it a bit weird that the "signal
> > containers" MEP refers to "classes" as well. I don't think that
> > classes are normally considered containers even if strictly speaking
> > they are. Perhaps it is because they are so much more than that...
> > So my 0.02$ is that that part should be rolled into the MEP 108.
> 
> What united the classes and other containers, in my mind, is how a 
> Signal and numeric values embedded in a "container" is transformed.
> You are correct, a class can be a super set but it is also
> container.  The MEP only covers the container part of the class, that
> is Signals, constants, and variables (?) as class attributes.

Well, I think we should support classes, in the end, list and signals
are also classes, and I think we shouldn't restrict cases like defining
a custom container class. I think the problem here is how to access
its members (index or attributes), I mean in the implementation.

However, following the idea of "baby steps", I agree on starting only
with lists and dicts. Also, note that in this objects, the access to its
members is done by indexing.

> 
> >
> > I also think that it is perhaps a good idea to go the "baby steps"
> > route and make a first version that does not handle class
> > attributes. I believe that any progress is good progress. Having
> > this feature, even in a limited form, may already prove useful, and
> > it may even give you hints on how to proceed further later on.
> >
> > Cheers,
> >
> > Angel
> 
> Thanks for the comments,
> Chris
> 

In summary: I agree on both MEPs, let me study them carefully to make
additional comments. Great work Chris! Thanks a lot.

> 
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list


-- 
Oscar Díaz
Key Fingerprint = 904B 306C C3C2 7487 650B  BFAC EDA2 B702 90E9 9964
gpg --keyserver subkeys.pgp.net --recv-keys 90E99964

I recommend using OpenDocument Format
for daily use and exchange of documents.

http://www.fsf.org/campaigns/opendocument

Re: [myhdl-list] Convertion to Verilog inout port

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

On 3/20/12 3:45 AM, Wesley New wrote:
> Hi All,
>
> I need myhdl to generate an inout port for my toplevel verilog as we
> have a bus with bidirectional data lines between our FPGA and CPU.
>
> I am using user_defined code so there is no way that MyHDL can infer
> that the port must be inout.
>
> How would I go about doing this?
>
> Thanks
>
> Wesley
>

To get started, you can review the ShadowSignal MEP and the latest 
release notes,
   * http://www.myhdl.org/doc/current/whatsnew/0.7.html#shadow-signals
   * http://www.myhdl.org/doku.php/meps:mep-105
   * http://www.myhdl.org/doku.php/meps:mep-105#tristatesignal
it is worthwhile reading to get more background on the latest TriState 
(ShadowSignal) implementation.

I have not generated tri-states myself in MyHDL; I do not have an 
example handy.  If you need more information or have additional 
questions don't hesitate to ask.

Regards,
Chris

[myhdl-list] Convertion to Verilog inout port

[Wesley N. <we...@sk...>]

Hi All,

I need myhdl to generate an inout port for my toplevel verilog as we have a
bus with bidirectional data lines between our FPGA and CPU.

I am using user_defined code so there is no way that MyHDL can infer that
the port must be inout.

How would I go about doing this?

Thanks

Wesley

Re: [myhdl-list] Migen logic design toolbox - now with simulator

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

On 03/19/2012 10:06 AM, Sébastien Bourdeauducq wrote:

> For sequential test bench code, you can use e.g. Python generators as in
> the Wishbone example from the doc.

Sure, one can argue that Migen is for synthesizable code only,
and for the rest we have Python, so that's OK, isn't it?

Well, no. Look at the test bench code versus Migen code and
note that the modeling paradigm is entirely different.
But in practice, today's high-level model that is part
of the verification environment becomes tomorrow's
synthesizable model and vice versa. Very often, this even
happens within the same project.

Refinements may be necessary, but always within the same
modeling paradigm. Having to switch between modeling
paradigms depending on the particular view is unnatural  and
leads no needless modeling effort duplication. The great
advantage of the event-driven paradigm is that it is
general enough to provide a single modeling paradigm
for any type of logic.

-- 
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] Migen logic design toolbox - now with simulator

[Jan C. <jan...@mu...>]

On 19/03/12 12:30, Jan Decaluwe wrote:
     ...
>
> But Migen uses the same type of assignment for 2 things
> which semantically could not be more different, and
> hides that difference in an object constructor. No
> excuses here. This is horrible!
>
> Apart from all this, and even more importantly, what
> is missing is support for typical procedural modeling.
> Consider the following combinatorial circuit in MyHDL:
>
> def MsbDetector(pos, a):
>       """Return the bit position of the msb."""
>
>       @always_comb
>       def logic():
>           pos.next = 0
>           for i in downrange(len(a)):
>               if a[i] == 1:
>                   pos.next = i
>                   break
>
>       return logic

Thanks, these are the first two technical points in the discussion 
which I have been able to understand.

Jan Coombs

Re: [myhdl-list] Migen logic design toolbox - now with simulator

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

On 03/19/2012 01:17 PM, Bob Cunningham wrote:
> On 03/19/2012 01:26 AM, Jan Decaluwe wrote:

>> 2) for the synthesizable logic it is desirable to push the
>> abstraction level as high as possible for productivity reasons.
>
> Can you provide some simple examples where such complexity is
> required?

Yes, look at the examples in the MyHDL by Example section.

http://www.myhdl.org/doku.php/cookbook

> Why are these simple examples impossible to effectively design
> without explicitly handling such complexity?

You tell me, e.g. after trying the cookbook examples with Migen.

> At what point should a non-EE hobbyist newcomer to digital design
> become concerned about such complexity?

Right from the start.

> Do you think very many non-EE FPGA hobbyists would need to reach this
> level of complexity?

Yes, all of them. FPGA's are huge. And it's not *that* difficult
also. Non-EE FPGA hobbyists may have the advantage that they don't
think in terms of gates and FFs all the time.

> Do you believe tools can and should help mitigate exposure to such
> complexity?

Yes, that is one goal of MyHDL.


-- 
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] Migen logic design toolbox - now with simulator

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

On 03/19/2012 10:06 AM, Sébastien Bourdeauducq wrote:

> If you are talking about VHDL variables / blocking Verilog assignments
> that can be used to synthesize sequential code that "executes" in one
> cycle, then they are supported too (with the "variable" property of the
> Signal object).

That is what I call "horrible". These things are confusing enough,
even in VHDL that makes a clear distinction between signals
and variables. MyHDL improves further on this by using a
dedicated, distinctive attribute assignment for Signal
assignment.

Verilog is much worse, because it doesn't make the distinction
between signals and variables. But at least it uses
two different types of assignment. Unfortunately, this is
not enough for most Verilog designers to get the
difference.

But Migen uses the same type of assignment for 2 things
which semantically could not be more different, and
hides that difference in an object constructor. No
excuses here. This is horrible!

Apart from all this, and even more importantly, what
is missing is support for typical procedural modeling.
Consider the following combinatorial circuit in MyHDL:

def MsbDetector(pos, a):
     """Return the bit position of the msb."""

     @always_comb
     def logic():
         pos.next = 0
         for i in downrange(len(a)):
             if a[i] == 1:
                 pos.next = i
                 break

     return logic

I think it is hard to argue about the elegance and
clarity of the description. Moreover, it is
parametrizable for any bit width by default.

How would this look like in Migen? Some elaborate
if-then-else structure that explicitly lists all
the cases. Moreover, the structure size would depend
on the actual bit width. So far for elegance and
parametrizability.

-- 
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] Migen logic design toolbox - now with simulator

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

On 03/19/2012 01:26 AM, Jan Decaluwe wrote:
> On 03/19/2012 01:19 AM, Bob Cunningham wrote:
>
>> Would you please define what you mean when you repeatedly use the
>> phrases "serious digital design" and "serious design" in your posts?
>>
>> Please be clear and concise.  State what is and is not "serious
>> digital design" according to your definition of the phrase.  Try to
>> make your point without using that phrase.
>>
>> You are throwing those phrases around as if they were self-obvious
>> and self-justifying.  They most certainly are not!  What do they mean
>> to you?
>>
>> What do you believe those phrases should mean to me?
> But of course. Clarity and conciseness: every poster should
> keep it in mind. BTW, asking the question once is enough.
>
> With the word "serious" I refer to design work with a
> complexity level that is such that
>
> 1) test bench modeling, high-level modeling and
> verification will make up the bulk of the work;
>
> 2) for the synthesizable logic it is desirable to push
> the abstraction level as high as possible for
> productivity reasons.

Can you provide some simple examples where such complexity is required?

Why are these simple examples impossible to effectively design without explicitly handling such complexity?

At what point should a non-EE hobbyist newcomer to digital design become concerned about such complexity?

Do you think very many non-EE FPGA hobbyists would need to reach this level of complexity?

Do you believe tools can and should help mitigate exposure to such complexity?


-BobC

Re: [myhdl-list] Migen logic design toolbox - now with simulator

[Sébastien B. <seb...@mi...>]

On 03/18/2012 11:10 PM, Jan Decaluwe wrote:
> With "procedural support" I am not referring to procedures.
> Rather, I am using the word "procedural" to refer to statements whose
> order matters, as opposed to "concurrent" statements. The VHDL
> terminology is "sequential" but this word can be confusing also
> (as it also used to refer to clocked behavior.)

If you are talking about VHDL variables / blocking Verilog assignments 
that can be used to synthesize sequential code that "executes" in one 
cycle, then they are supported too (with the "variable" property of the 
Signal object).

For sequential test bench code, you can use e.g. Python generators as in 
the Wishbone example from the doc.

Anything else that I missed?

Sébastien

Re: [myhdl-list] Migen logic design toolbox - now with simulator

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

On 03/19/2012 01:19 AM, Bob Cunningham wrote:

> Would you please define what you mean when you repeatedly use the
> phrases "serious digital design" and "serious design" in your posts?
>
> Please be clear and concise.  State what is and is not "serious
> digital design" according to your definition of the phrase.  Try to
> make your point without using that phrase.
>
> You are throwing those phrases around as if they were self-obvious
> and self-justifying.  They most certainly are not!  What do they mean
> to you?
>
> What do you believe those phrases should mean to me?

But of course. Clarity and conciseness: every poster should
keep it in mind. BTW, asking the question once is enough.

With the word "serious" I refer to design work with a
complexity level that is such that

1) test bench modeling, high-level modeling and
verification will make up the bulk of the work;

2) for the synthesizable logic it is desirable to push
the abstraction level as high as possible for
productivity reasons.

-- 
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] Migen logic design toolbox - now with simulator

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

On 03/18/2012 03:18 PM, Jan Decaluwe wrote:
> On 03/17/2012 09:20 PM, Bob Cunningham wrote:
>> On 03/16/2012 02:03 PM, Jan Decaluwe wrote:
>>> My conclusion is that Migen found an easy target in you, as a
>>> newbie, to confuse you. It made you think it can be used for
>>> serious design work.
>> Sorry, Jan.  If I have to be "confused" to play with my FPGA, then so
>> be it.  I'm very "serious" about being able to play with my FPGA!
>>
>> Your statement has an obvious implicit context: To me, you are
>> shouting, "MyHDL is for Serious Designers Only!  Newbies and
>> Pragmatists should Go Away!"
> No, the "obvious implicit context" is "obviously" entirely
> different: I assume you want to do serious design work and
> I find it a pity that Migen managed to make you think it is
> a valid alternative for that purpose. I hate to see people
> wasting their time.
>
> And I was not shouting.

Would you please define what you mean when you repeatedly use the phrases "serious digital design" and "serious design" in your posts?

Please be clear and concise.  State what is and is not "serious digital design" according to your definition of the phrase.  Try to make your point without using that phrase.

You are throwing those phrases around as if they were self-obvious and self-justifying.  They most certainly are not!  What do they mean to you?

What do you believe those phrases should mean to me?


--

Your use of those phrases reminds me of my own past, back in the day when we had stickers on our terminals that said things like "Real Programmers Use Assembler" and "Coders Use Assembler: Real Hackers Write Machine Language".  I am of that generation where I wrote several programs in binary, octal and hexadecimal machine language, manually strobing words into memory locations to build programs and data in-place.  This was not because assemblers and higher-level language compilers didn't exist, but because they weren't freely available to me at the time.  Or sometimes because I was working with machines so broken that they had no functional peripherals for storage or I/O beyond rows of lights and switches on the front panel.

We took great joy in our knowledge of the fundamentals and particulars of a given machine's instruction set and its idiosyncratic behaviors.  We became a clique that considered those who did not match our interests and expertise as not being interested in "serious program development".

Then we noticed some folks were getting just as much work done in the "real world" as we were, with 10% of our technical knowledge, using tools such as BASIC and even (*gasp*) spreadsheets.  Sure, their programs weren't fast, nor were they elegant, but they got the job done.

I feel no need to repeat that path with digital design. I have a powerful computer (well, several of them) that should be able to do most of the heavy-lifting for me as I design and implement my first circuits.  I want to start with a spreadsheet-like tool that will let me design and implement useful things with my FPGA.  Today!

Unfortunately, that tool does not yet seem to exist.  But Migen is clearly a step in that direction when compared to the available HDLs.

Sure, you probably shouldn't use a spreadsheet to implement a real-time aircraft control system.  There are some things that any given tool won't be ideal for accomplishing.  I'm not looking for a be-all end-all do-it-all tool or approach.  I just want to do "fun stuff" with my FPGA!  I want an enabling approach, maximum yield for the initial effort.

When I outgrow my initial tools, I will know it.  That will be when I'll need to get more "serious".  But not today, and perhaps not ever.


You chose Python as your tool for implementing MyHDL, when you could have been a "more serious" programmer and chosen assembler instead (not machine language, because no computer has front panel switches any more).  Or even C.  Why didn't you?

Clearly, you valued pragmatic productivity over any abstract notion of software "seriousness".  I seek the same in the arena of digital design.


So, what does the phrase "serious digital design" mean to you?

Perhaps you yourself are not really serious enough when it comes to digital design:  Doesn't everyone know that "Real Digital Designers Use Rubylith!"?  When was the last time you used a switch to toggle the ones and zeros to manually feed a bitstream into an FPGA?

Clearly you aren't against using higher-level hardware and software tools to abstract away low-level details that are irrelevant to the work at hand.  I desire the same, and Migen is clearly a step in that direction.


Again, I ask, what do you mean when you say "serious digital design"?

Do some contexts permit "serious digital design", and other contexts somehow magically exclude it?  Please clarify your terminology.


-BobC

Re: [myhdl-list] Migen logic design toolbox - now with simulator

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

On 3/18/12 5:10 PM, Jan Decaluwe wrote:
> The relevant feature is whether events are explicit (VHDL, Verilog, MyHDL)
> or implicit (Migen et al). In practice, all HDLs with explicit events
> that I know of support procedural semantics, and none of the HDLs
> with implicit events that I know of do so.
>
> In particular, Migen has concurrent semantics only. The lack of
> procedural semantics is a showstopper.
>
Thank you so much Jan.  This is what I was looking for.  A very high
level view of what the difference is between the two approaches.   Let
us see if the Migen people agree with your characterization. 

Actually in my case, I think I am only interested in the concurrent
semantics, not the procedural ones so I will
now go and take a closer look at the Migen documents.   I could be
wrong.  As I get into detailed designs, perhaps I will also need the
procedural approach.   Maybe I will even switch back and forth a few times.

In any case I would like to thank you for allowing the Migen people to
speak on this list.  I certainly learned a lot from the back and forth
debate.  From the global perspective, the guys trying to design chips
with python are a single group of people.  And I understand that if you
are a hardcore Migen or MyHDL person, they appear to be two different
communities. 

-- 
Regards
Christopher Lozinski

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

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

Re: [myhdl-list] Migen logic design toolbox - now with simulator

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

On 03/17/2012 09:20 PM, Bob Cunningham wrote:
> On 03/16/2012 02:03 PM, Jan Decaluwe wrote:
>> My conclusion is that Migen found an easy target in you, as a
>> newbie, to confuse you. It made you think it can be used for
>> serious design work.
>
> Sorry, Jan.  If I have to be "confused" to play with my FPGA, then so
> be it.  I'm very "serious" about being able to play with my FPGA!
>
> Your statement has an obvious implicit context: To me, you are
> shouting, "MyHDL is for Serious Designers Only!  Newbies and
> Pragmatists should Go Away!"

No, the "obvious implicit context" is "obviously" entirely
different: I assume you want to do serious design work and
I find it a pity that Migen managed to make you think it is
a valid alternative for that purpose. I hate to see people
wasting their time.

And I was not shouting.

-- 
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] Migen logic design toolbox - now with simulator

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

On 03/17/2012 02:15 AM, Sébastien Bourdeauducq wrote:
> On 03/16/2012 10:03 PM, Jan Decaluwe wrote:
>> When Migen claims that the "event-driven" paradigm is
>> too general, what it really dumps is procedural support
>> in your HDL descriptions - the interesting stuff.
>
> This isn't entirely fair (I will not even mention the impolite bits
> above). First, procedures in V*HDL can often be easily converted to bits
> of Python code that manipulate the lower layer bits - admittedly in a
> less elegant way (though perhaps easier to understand), but it can be
> done. Second, for synthesis those procedures always need to "execute" in
> one clock cycle, which seriously limits their real usefulness.

With "procedural support" I am not referring to procedures.
Rather, I am using the word "procedural" to refer to statements whose
order matters, as opposed to "concurrent" statements. The VHDL
terminology is "sequential" but this word can be confusing also
(as it also used to refer to clocked behavior.)

>  Also,
> this while thing has little to do with event-driven vs. cycle-based.

The relevant feature is whether events are explicit (VHDL, Verilog, MyHDL)
or implicit (Migen et al). In practice, all HDLs with explicit events
that I know of support procedural semantics, and none of the HDLs
with implicit events that I know of do so.

In particular, Migen has concurrent semantics only. The lack of
procedural semantics is a showstopper.

-- 
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] Migen logic design toolbox - now with simulator

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

On 03/16/2012 02:03 PM, Jan Decaluwe wrote:
> My conclusion is that Migen found an easy target in
> you, as a newbie, to confuse you. It made you think it
> can be used for serious design work.

Sorry, Jan.  If I have to be "confused" to play with my FPGA, then so be it.  I'm very "serious" about being able to play with my FPGA!

Your statement has an obvious implicit context: To me, you are shouting, "MyHDL is for Serious Designers Only!  Newbies and Pragmatists should Go Away!"

If that's what you are saying, then please be direct: Don't attack Migen for being what it was intentionally created to be, or for being something MyHDL is not intended to be.  Are you upset about Migen existing, or that there is an audience MyHDL can't help as well as Migen may be able to?  If you'd rather beginners like myself go elsewhere, just say so.

Remember, Migen wasn't created to be useful to beginners: It was created by an experienced FPGA designer concerned about practicality and productivity for a specific Open Source hardware project.  It simply happened that some things became a bit clearer to me after looking at Migen and the problems it was created to address.  Whatever Migen leaves out may have been what was getting in my way!

I'm actually quite lazy: What is the *least* I need to know to make useful digital designs *now*?

I'm a beginner:  Though I'd love to someday be able to design circuits like Shakespeare wrote sonnets, I'd be more than happy today if I were able to work at the level of "Green Eggs and Ham", a true masterpiece written with an absolute minimum of linguistic complexity.

> When Migen claims that the "event-driven" paradigm is
> too general, what it really dumps is procedural support
> in your HDL descriptions - the interesting stuff.

What's "interesting" to you can be a frustrating block for a newbie.  I hope to one day also be very interested in those aspects of MyHDL, but it seems to have little to do with what I want to get done today, which is to find the simplest path to get basic circuits out of my mind and in to my FPGA.  Then use them as building-blocks in my hobby projects.

> Unfortunately, I cannot direct you to a good introductory
> text explaining all this in a decent way, even though those
> techniques are more than 20 years old. I will eventually
> get to this in my blog, in which I already discussed some
> background.
>
> http://www.sigasi.com/janhdl

I *love* the way you write!  I've read every word of yours I could find, and I will very gladly read every new thing you share.  If you provide a new example, I will faithfully follow it.  If you direct me to a helpful reference, I will study it.

Most importantly, if you ever write an introductory digital design text that uses MyHDL both as an instructional language and as an implementation language, then I promise to be first in line to buy a copy. I will volunteer in any way I can to help create that book, from proofreading (for grammar and flow, not technical content) to working the examples and attempting the exercises.

I am *totally* behind MyHDL!  You may recall that I was first to post here about using the updated PyPy to pass 100% of the MyHDL test suite.  It was a simple thing, but I do try to help where I can.  I also greatly respect every bit of the work you're doing: When I wanted to talk to other EEs about MyHDL, I first asked you about the correct pronunciation of your name.  I believe you have made an important contribution by creating MyHDL, and I want others to know about it.

I am a MyHDL fan.  Unfortunately, I simply remain unable to use MyHDL to accomplish my own immediate hobby needs.  That does not indicate any flaw in MyHDL, merely the extent my own limitations.  Do not be surprised that I am interested in any tool that helps me circumvent those limitations!

I actually *like* how Migen slices and dices the process of FPGA design: The parts that are left out are ones I doubt newbies like me would notice, much less care about, until confronted with unusually challenging designs.  I suspect Sebastien would agree with much of your analysis, the proper response being: "So What?"

It's not about theoretical power or completeness: It's about barriers to entry.  It's not about what I can do in 5 years, but about what I can do in 5 weeks.  Migen is primarily about pragmatism and productivity, making powerful circuits quickly and easily, and far less about expert capabilities, theoretical purity or even consistency.

I seek tools that will help me do what I want to get done today, and so far Migen seems like it will be most useful.  Tomorrow will likely require additional tools, and I *absolutely* expect (and want) MyHDL to the first of those tools.  It is not an either-or proposition: I want Migen *and* MyHDL.  I realize MyHDL will take more time to master, and I'm willing to commit that time.  But I also want to create something sooner, rather than later.  And I believe that 100% of what I learn using Migen will later prove useful with MyHDL.  I believe using Migen will keep me motivated toward learning MyHDL.

Right next to me I have a Spartan 3E-500 that contains nothing of my own design.  That must change!


-BobC

> On 03/14/2012 05:07 AM, Bob Cunningham wrote:
>> On 03/13/2012 02:19 AM, Jan Decaluwe wrote:
>>> On 03/13/2012 02:07 AM, Bob Cunningham wrote:
>>>
>>>>  From my perspective as an HDL newbie (but a 30+ year engineering
>>>> veteran otherwise), major feature development in MyHDL appears
>>>> to have stalled, and Migen provides important capabilities MyHDL
>>>> either lacks or can implement only with cumbersome and fragile
>>>> kluges or work-arounds.  (At least, that's what they look like to
>>>> me, with my newbie eyes and brain.)
>>> Could you please provide a list of those important capabilities
>>> that MyHDL lacks in your opinion?
>> I must admit I set MyHDL aside a few months ago after having daunting
>> problems getting my 'simple' systems to work (mainly trying to glue
>> together components from Open Cores).  I had trouble writing useful
>> MyHDL, and I found that one of my 'glue' problems, a Wishbone
>> interface, had a simpler solution (from my perspective) in Migen.  It
>> could have been a unique or special case, I don't know enough yet to
>> tell: I haven't solved all my other problems with this project.
>>
>> Another project idea, a dataflow signal processor for a 'flying
>> pixel' camera, had me spending all my initial design time working on
>> the interface between the dataflow stages (simple in software, harder
>> in hardware) rather than on the content of each stage.  Though I
>> haven't implemented anything yet, it seems to me that Migen may make
>> such interfaces easier.
>>
>> However, the sum of my difficulties showed me that I lacked the
>> perspective and depth needed to make proper use of MyHDL, so I'm
>> taking some time to extend my hardware skills, to design some
>> circuits and boards.  Back to schematic capture, device specs, board
>> layout, and using an o'scope and logic analyzer.
>>
>> I understand using gates (bits), and I understand using chips
>> (interfaces).  It's the stuff in between that I'm having problems
>> with.  From my limited perspective, it seems to me that Migen does
>> particularly well with interfaces, and the distinct separation
>> between sequential and combinatorial logic seems to fit my current
>> thought processes.
>>
>> I have no idea how far I can go with Migen compared to MyHDL.  But
>> the initial learning curve, with the goal of making my Spartan 3E
>> board do fun and useful things, for the moment seems to favor Migen
>> over MyHDL.
>>
>> But I am well aware that situation may not persist as my knowledge
>> and experience grow.  I have no intention of abandoning MyHDL: I
>> closely monitor this list, and I periodically review the MyHDL
>> documentation (especially the examples) to see if my comprehension
>> has grown.
>>
>> Perhaps Migen makes FPGA development feel more like building with
>> Legos:  It makes it easy(er) to create parts and click them together.
>> I suspect MyHDL may more like a machine shop: More skill is required
>> to make use of it, but there may be no limit to what can be built,
>> such as a Lego factory.
>>
>> Migen feels more newbie-friendly, while MyHDL may be more attractive
>> to battle-weary V*HDL veterans.  Migen is FPGA-centric, while MyHDL
>> is fully ASIC-capable.  Migen sometimes implements features
>> inelegantly, while MyHDL excludes inelegant features.  Practicality
>> vs purity.  High-level abstractions vs low-level power.
>>
>> Bottom line, I suspect both tools have their place, and share enough
>> common premises that it is a mistake to view one as competing with or
>> detracting from the other: Both agree the V*HDLs have limitations,
>> both agree Python is a great tool for implementing HDLs.  Each
>> chooses a different approach, provides differing capabilities,
>> targets a slightly different domain, and may attract different groups
>> of users, all of which appears to me to be more complimentary than
>> competitive.
>>
>> I don't see how there can be any need to push Migen and MyHDL apart:
>> I think they should stand back-to-back and show the V*HDLs better
>> ways to fill FPGAs.  More like siblings who occasionally argue, than
>> any kind of enemy.
>>
>>
>> -BobC
>>

Re: [myhdl-list] Conversion of class methods

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

<snip>
>>
>
> Hi Christopher,
>
> I wonder how you are messing up mercurial and branches. I find them
> very easy and straight forward to use. Are you using plain mercurial
> or a GUI such as TortoiseHg? I am one of the core TortoiseHg
> developers, so do not hesitate to contact me if you need any help with
> that. If you are not using it I'd love for you to give it a try. I
> think it is quite helpful. If you are using it already and are having
> problems with it I'd love to hear about them so that we can improve
> things a little.

Pretty sure it's a U.S.E.R error, I simply forgot to switch the branch 
before making my modifications and don't have enough mercurial savvy to 
remedy my errors.  It is ok for now, these changes are in a development 
branch and I should be able to clean it up before creating a patch (if I 
get that far).

>
> In any case, if you ever find that you committed to the wrong branch,
> you can use the MQ extension to "qrefresh" your commit, changing the
> branch at will.

Thanks, this is useful information.

>
> Coming back to the important part of your message, you are right that
> calling the first method argument "self" is just a convention, not a
> requirement. Nevertheless I've never seen any python code that does
> not call the first method argument "self". Thus I don't think you
> should worry too much about it. I think that it would be safe to make
> that a requirement for MyHDL if you do not find a better way to
> differentiate between funcions and class methods.
>
> As for your other questions, I find it a bit weird that the "signal
> containers" MEP refers to "classes" as well. I don't think that
> classes are normally considered containers even if strictly speaking
> they are. Perhaps it is because they are so much more than that... So
> my 0.02$ is that that part should be rolled into the MEP 108.

What united the classes and other containers, in my mind, is how a 
Signal and numeric values embedded in a "container" is transformed.  You 
are correct, a class can be a super set but it is also container.  The 
MEP only covers the container part of the class, that is Signals, 
constants, and variables (?) as class attributes.

>
> I also think that it is perhaps a good idea to go the "baby steps"
> route and make a first version that does not handle class attributes.
> I believe that any progress is good progress. Having this feature,
> even in a limited form, may already prove useful, and it may even give
> you hints on how to proceed further later on.
>
> Cheers,
>
> Angel

Thanks for the comments,
Chris

Re: [myhdl-list] Conversion of class methods

[Angel E. <ang...@gm...>]

On Sat, Mar 17, 2012 at 6:33 AM, Christopher Felton
<chr...@gm...> wrote:
> I had put together a fairly generic (weak) MEP for class method
> conversion, http://www.myhdl.org/doku.php/meps:mep-108.  The following
> is a more in depth conversation/analysis of the items (I am aware of)
> that need to be handled to enable class method conversion.  The items
> discussed are:  The "self" argument, class attributes, and the extract
> hierarchy process.
>
> The MEP was only intended to handle class methods and not arbitrary
> conversion of classes.
>
> Handling the "self" argument
> -----------------------------
> If I naively send a class method to the conversion routines the method
> will fail to convert correctly.   It will fail because the "self"
> argument is treated as the first port (see the current MEP for an
> example).
>
> Performing a quick test by searching for "self" in the argument list and
> ignoring the self argument will render the object method convertible.
> Adding these changes to
>   _AnalyzeTopFuncVisitor.vist_FunctionDev(...) (_analyze.py)
> allows a top-level class method and buried methods to be converted.  I
> have prototyped and created some tests which can be viewed here,
> https://bitbucket.org/cfelton/myhdl-0.8-dev-containers/overview (clone
> of the myhdl 0.8 dev, see notes at the end).
>
> A couple *issues* with this approach!  Although the "self" argument is
> almost always used I don't believe its enforcement; the "first" argument
> can have any name.  A simple experiment demonstrates the object
> reference can be anything.
>
>   >>> class Foo():
>   ...     def __init__(this, self):
>   ...             print("New foo, this, self %s" % (self))
>   ...
>   >>> f = Foo('bar')
>   New foo, this, self bar
>   >>>
>
> A more generic identification would be required.  Ideally, you would
> like to identify the class method (distinguish the method from a
> function) and ignore the first argument, currently I do not know how
> this can be accomplished in the AST parsing (visiting).
>
> Assuming this technical hurdle can be overcome, the class method
> conversion would be possible.  But ... this only takes care of the
> "self" argument, in addition the class/objects attribute access and the
> extract hierarchy need to be addressed/discussed.
>
> Class attribute access
> -----------------------
> There are two types of attributes to consider.  The first a simple
> attribute (immutable?) which would simply hold a constant.  Example, the
> number of bits to have in a signal, etc.  Even these simple attributes
> would require changes.
>
> The bigger issue is accessing convertible types (Signal) that are
> referenced through the object's attributes.  This issue is a can of
> worms and I was not intending to address this "feature" with this MEP,
> but a separate MEP was created,
> http://www.myhdl.org/doku.php/meps:mep-107, to address general class
> attribute conversion.
>
> This brings up a couple questions:
>
>   1. Should an initial class method conversion be added with the
> limitation: no class attributes can be accessed?  (baby steps)
>
>   2. If no, then should the MEPs be changed so that 107 only addresses
> the other "containers" (if this is even desired) and 108 should include
> handling attributes?
>
> Extracting the hierarchy
> -------------------------
> While experimenting it was noticed that class methods were not
> identified in the _extractHeirarchy.  The _extractHeirarchy uses a
> different approach to determine the functions and generators that are to
> be converted.  The approach, using the "profile" functions does not
> identify the class methods, only functions (?).  This breaks some of the
> features (e.g. user-defined code).  It needs to be determined if the
> "profile" parsers can handle extracting the class methods or if the AST
> parser will need to be used (light-weight version of the AST to only
> extract hierarchy)?  Thanks to Wesley for providing the examples with
> the user-defined code.
>
> Closing remarks
> ----------------
> Note, this work is preliminary, I have not made enough progress to
> present a complete working solution.  This post is to inform the group
> what I have done and some issues I have run into and to solicit
> feedback.  Any comments or suggestions welcomed and appreciated.  I
> intent to hack away at this and try to resolve the above issues, time
> permitting.
>
> If you look at the commits in bitbucket be prepared.  One, I must have
> my editor to replace tabs with spaces.  In some cases more lines are
> modified than needed.  Two, I keep messing up mercurial and branches,
> extra commits to default that were not intended.  Both these mistakes
> make the commit diffs unusable.  At some point I will need a clean
> working clone, doh.
>
> References
> -----------
> [1] http://docs.python.org/tutorial/classes.html
>

Hi Christopher,

I wonder how you are messing up mercurial and branches. I find them
very easy and straight forward to use. Are you using plain mercurial
or a GUI such as TortoiseHg? I am one of the core TortoiseHg
developers, so do not hesitate to contact me if you need any help with
that. If you are not using it I'd love for you to give it a try. I
think it is quite helpful. If you are using it already and are having
problems with it I'd love to hear about them so that we can improve
things a little.

In any case, if you ever find that you committed to the wrong branch,
you can use the MQ extension to "qrefresh" your commit, changing the
branch at will.

Coming back to the important part of your message, you are right that
calling the first method argument "self" is just a convention, not a
requirement. Nevertheless I've never seen any python code that does
not call the first method argument "self". Thus I don't think you
should worry too much about it. I think that it would be safe to make
that a requirement for MyHDL if you do not find a better way to
differentiate between funcions and class methods.

As for your other questions, I find it a bit weird that the "signal
containers" MEP refers to "classes" as well. I don't think that
classes are normally considered containers even if strictly speaking
they are. Perhaps it is because they are so much more than that... So
my 0.02$ is that that part should be rolled into the MEP 108.

I also think that it is perhaps a good idea to go the "baby steps"
route and make a first version that does not handle class attributes.
I believe that any progress is good progress. Having this feature,
even in a limited form, may already prove useful, and it may even give
you hints on how to proceed further later on.

Cheers,

Angel

[myhdl-list] Conversion of class methods

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

I had put together a fairly generic (weak) MEP for class method 
conversion, http://www.myhdl.org/doku.php/meps:mep-108.  The following 
is a more in depth conversation/analysis of the items (I am aware of) 
that need to be handled to enable class method conversion.  The items 
discussed are:  The "self" argument, class attributes, and the extract 
hierarchy process.

The MEP was only intended to handle class methods and not arbitrary 
conversion of classes.

Handling the "self" argument
-----------------------------
If I naively send a class method to the conversion routines the method 
will fail to convert correctly.   It will fail because the "self" 
argument is treated as the first port (see the current MEP for an 
example).

Performing a quick test by searching for "self" in the argument list and 
ignoring the self argument will render the object method convertible. 
Adding these changes to
   _AnalyzeTopFuncVisitor.vist_FunctionDev(...) (_analyze.py)
allows a top-level class method and buried methods to be converted.  I 
have prototyped and created some tests which can be viewed here, 
https://bitbucket.org/cfelton/myhdl-0.8-dev-containers/overview (clone 
of the myhdl 0.8 dev, see notes at the end).

A couple *issues* with this approach!  Although the "self" argument is 
almost always used I don't believe its enforcement; the "first" argument 
can have any name.  A simple experiment demonstrates the object 
reference can be anything.

   >>> class Foo():
   ...     def __init__(this, self):
   ...             print("New foo, this, self %s" % (self))
   ...
   >>> f = Foo('bar')
   New foo, this, self bar
   >>>

A more generic identification would be required.  Ideally, you would 
like to identify the class method (distinguish the method from a 
function) and ignore the first argument, currently I do not know how 
this can be accomplished in the AST parsing (visiting).

Assuming this technical hurdle can be overcome, the class method 
conversion would be possible.  But ... this only takes care of the 
"self" argument, in addition the class/objects attribute access and the 
extract hierarchy need to be addressed/discussed.

Class attribute access
-----------------------
There are two types of attributes to consider.  The first a simple 
attribute (immutable?) which would simply hold a constant.  Example, the 
number of bits to have in a signal, etc.  Even these simple attributes 
would require changes.

The bigger issue is accessing convertible types (Signal) that are 
referenced through the object's attributes.  This issue is a can of 
worms and I was not intending to address this "feature" with this MEP, 
but a separate MEP was created, 
http://www.myhdl.org/doku.php/meps:mep-107, to address general class 
attribute conversion.

This brings up a couple questions:

   1. Should an initial class method conversion be added with the 
limitation: no class attributes can be accessed?  (baby steps)

   2. If no, then should the MEPs be changed so that 107 only addresses 
the other "containers" (if this is even desired) and 108 should include 
handling attributes?

Extracting the hierarchy
-------------------------
While experimenting it was noticed that class methods were not 
identified in the _extractHeirarchy.  The _extractHeirarchy uses a 
different approach to determine the functions and generators that are to 
be converted.  The approach, using the "profile" functions does not 
identify the class methods, only functions (?).  This breaks some of the 
features (e.g. user-defined code).  It needs to be determined if the 
"profile" parsers can handle extracting the class methods or if the AST 
parser will need to be used (light-weight version of the AST to only 
extract hierarchy)?  Thanks to Wesley for providing the examples with 
the user-defined code.

Closing remarks
----------------
Note, this work is preliminary, I have not made enough progress to 
present a complete working solution.  This post is to inform the group 
what I have done and some issues I have run into and to solicit 
feedback.  Any comments or suggestions welcomed and appreciated.  I 
intent to hack away at this and try to resolve the above issues, time 
permitting.

If you look at the commits in bitbucket be prepared.  One, I must have 
my editor to replace tabs with spaces.  In some cases more lines are 
modified than needed.  Two, I keep messing up mercurial and branches, 
extra commits to default that were not intended.  Both these mistakes 
make the commit diffs unusable.  At some point I will need a clean 
working clone, doh.

References
-----------
[1] http://docs.python.org/tutorial/classes.html

Re: [myhdl-list] Migen logic design toolbox - now with simulator

[Sébastien B. <seb...@mi...>]

On 03/16/2012 10:03 PM, Jan Decaluwe wrote:
> When Migen claims that the "event-driven" paradigm is
> too general, what it really dumps is procedural support
> in your HDL descriptions - the interesting stuff.

This isn't entirely fair (I will not even mention the impolite bits 
above). First, procedures in V*HDL can often be easily converted to bits 
of Python code that manipulate the lower layer bits - admittedly in a 
less elegant way (though perhaps easier to understand), but it can be 
done. Second, for synthesis those procedures always need to "execute" in 
one clock cycle, which seriously limits their real usefulness. Also, 
this while thing has little to do with event-driven vs. cycle-based.

S.

Re: [myhdl-list] Migen logic design toolbox - now with simulator

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

My conclusion is that Migen found an easy target in
you, as a newbie, to confuse you. It made you think it
can be used for serious design work.

But it cannot - unless all you need is a sophisticated
generator of concurrent statements and a single clock.
That is all Migen really is (and then it added some
horrible design choices despite having a good example).

For serious design work, procedural support alongside
concurrent semantics is essential. Not just for test benches
and high level modeling (of course) but also for synthesizable
code.

When Migen claims that the "event-driven" paradigm is
too general, what it really dumps is procedural support
in your HDL descriptions - the interesting stuff.

What you (and many Verilog/VHDL designers, and Migen's
designers) miss is the role of RTL/logic synthesis.
It is much more than technology mapping. It can handle
procedural descriptions quite well, including features
such as register inferencing from procedural variables.
It enables you to move the abstraction level a little
higher by thinking about (admittedly low-level) *code*
instead of gates.

Unfortunately, I cannot direct you to a good introductory
text explaining all this in a decent way, even though those
techniques are more than 20 years old. I will eventually
get to this in my blog, in which I already discussed some
background.

http://www.sigasi.com/janhdl


On 03/14/2012 05:07 AM, Bob Cunningham wrote:
> On 03/13/2012 02:19 AM, Jan Decaluwe wrote:
>> On 03/13/2012 02:07 AM, Bob Cunningham wrote:
>>
>>> From my perspective as an HDL newbie (but a 30+ year engineering
>>> veteran otherwise), major feature development in MyHDL appears
>>> to have stalled, and Migen provides important capabilities MyHDL
>>> either lacks or can implement only with cumbersome and fragile
>>> kluges or work-arounds.  (At least, that's what they look like to
>>> me, with my newbie eyes and brain.)
>> Could you please provide a list of those important capabilities
>> that MyHDL lacks in your opinion?
>
> I must admit I set MyHDL aside a few months ago after having daunting
> problems getting my 'simple' systems to work (mainly trying to glue
> together components from Open Cores).  I had trouble writing useful
> MyHDL, and I found that one of my 'glue' problems, a Wishbone
> interface, had a simpler solution (from my perspective) in Migen.  It
> could have been a unique or special case, I don't know enough yet to
> tell: I haven't solved all my other problems with this project.
>
> Another project idea, a dataflow signal processor for a 'flying
> pixel' camera, had me spending all my initial design time working on
> the interface between the dataflow stages (simple in software, harder
> in hardware) rather than on the content of each stage.  Though I
> haven't implemented anything yet, it seems to me that Migen may make
> such interfaces easier.
>
> However, the sum of my difficulties showed me that I lacked the
> perspective and depth needed to make proper use of MyHDL, so I'm
> taking some time to extend my hardware skills, to design some
> circuits and boards.  Back to schematic capture, device specs, board
> layout, and using an o'scope and logic analyzer.
>
> I understand using gates (bits), and I understand using chips
> (interfaces).  It's the stuff in between that I'm having problems
> with.  From my limited perspective, it seems to me that Migen does
> particularly well with interfaces, and the distinct separation
> between sequential and combinatorial logic seems to fit my current
> thought processes.
>
> I have no idea how far I can go with Migen compared to MyHDL.  But
> the initial learning curve, with the goal of making my Spartan 3E
> board do fun and useful things, for the moment seems to favor Migen
> over MyHDL.
>
> But I am well aware that situation may not persist as my knowledge
> and experience grow.  I have no intention of abandoning MyHDL: I
> closely monitor this list, and I periodically review the MyHDL
> documentation (especially the examples) to see if my comprehension
> has grown.
>
> Perhaps Migen makes FPGA development feel more like building with
> Legos:  It makes it easy(er) to create parts and click them together.
> I suspect MyHDL may more like a machine shop: More skill is required
> to make use of it, but there may be no limit to what can be built,
> such as a Lego factory.
>
> Migen feels more newbie-friendly, while MyHDL may be more attractive
> to battle-weary V*HDL veterans.  Migen is FPGA-centric, while MyHDL
> is fully ASIC-capable.  Migen sometimes implements features
> inelegantly, while MyHDL excludes inelegant features.  Practicality
> vs purity.  High-level abstractions vs low-level power.
>
> Bottom line, I suspect both tools have their place, and share enough
> common premises that it is a mistake to view one as competing with or
> detracting from the other: Both agree the V*HDLs have limitations,
> both agree Python is a great tool for implementing HDLs.  Each
> chooses a different approach, provides differing capabilities,
> targets a slightly different domain, and may attract different groups
> of users, all of which appears to me to be more complimentary than
> competitive.
>
> I don't see how there can be any need to push Migen and MyHDL apart:
> I think they should stand back-to-back and show the V*HDLs better
> ways to fill FPGAs.  More like siblings who occasionally argue, than
> any kind of enemy.
>
>
> -BobC
>
>
> ------------------------------------------------------------------------------
>
>
Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/


-- 
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] Python package organization

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

On 3/14/2012 6:07 AM, Christopher Felton wrote:
> Slightly off-topic, where do people like to put there tests (unit tests)
> in a python package directory structure?  Using the example in the
> Python documents:

I really should learn not to post early in the morning when I am barely 
awake :)

.chris

[myhdl-list] Python package organization

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

Slightly off-topic, where do people like to put there tests (unit tests) 
in a python package directory structure?  Using the example in the 
Python documents:

   python_pkg/
      setup.py
      sound/                     Top-level package
       __init__.py               Initialize the sound package
       formats/                  Subpackage for file format conversions
               __init__.py
               wavread.py
               wavwrite.py
               ...
       effects/                  Subpackage for sound effects
               __init__.py
               echo.py
               surround.py
               reverse.py
               ...
       filters/                  Subpackage for filters
               __init__.py
               equalizer.py
               ...

Would you have one test folder in python_pkg/ or sound/ with all the 
tests.  Or do you have module specific tests with the modules.  Or a 
combination.

In general, I suppose this is project specific.  Some projects don't 
benefit from a package/module organization.  But there are some 
technical constraints, e.g. if the test access as a package or 
individual modules.

I usually end up with something like:

   python_pkg/
      setup.py
      sound/
          __init__.py
          formats/
               __init__.py
               wavread.py
               wavwrite.py
               test_wav.py
               ...
          effects/
               __init__.py
               echo.py
               surround.py
               reverse.py
               test_echo.py
               test_surround.py
               ...
          filters/
               __init__.py
               equalizer.py
               ...
       test/
          test_sound.py
          test_echo.py


I have top-level, system tests, and module tests.

Regards,
Chris