myhdl-list — Mailing list for discussions on MyHDL

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

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

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

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

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

On 5/2/12 7:30 PM, 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.
>

But a manual for the Ruby language will expect that you know how to 
program something, how to use a computer, etc.  It doesn't start from 
step one (what is step one?).

I do agree, there are different users that would be interested in MyHDL. 
  Those who know programming and basic hardware so the references to 
Verilog/VHDL could be bewildering.  On the flip-side those who are 
experienced/familiar with Verilog/VHDL the direct path would be to 
explaining MyHDL is to compare/contrast to Verilog/VHDL.

Although, the manual does mention Verilog and VHDL I think it does a 
good job of explaining the concepts, such that a user would not need to 
know Verilog/VHDL.  The _background_ section suggests knowing 
Verilog/VHDL is helpful but not required.  As mentioned you want a 
direct path for those that know HDLs without excluding programmers.  I 
think the manual does a decent job finding that balance.

Maybe a "read first", one for programmers and one for HDLers.  Or 
separate overview(s) could be useful?  But I don't think it is 
reasonable to expect the MyHDL manual to include logic circuits 101. 
That is out of the context of the manual.

Regards,
Chris

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

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

On 5/2/12 6:48 PM, Tom Dillon wrote:
> On 05/02/2012 06:30 PM, Christopher Lozinski wrote:
>> On 5/2/12 3:58 PM, Christopher Felton wrote:
>>> On 5/2/2012 1:52 PM, Uri Nix wrote:
>>>> IMHO it /is/ confusing, since the previous topics in the chapter are
>>>> synthesis oriented.
>>> The manual under "Modeling techniques" currently progresses; structural,
>>> RTL, High-level.  Do you think a top-down versus bottom-up order would
>>> be better?  Someone *without* a HW design background may find;
>>> High-level, RTL, structural order less confusing?  Or, in your opinion,
>>> do you think it needs to be a completely separate chapter?
>> It is still all not clear to me.  I am not sure about top down or bottom
>> up.  There are two different target markets, the experienced hardware
>> designers, and the experienced software developers.  I can only speak
>> for the later.
>>
>> I would love to see it structured more as a tutorial on hardware design
>> than as a class on MyHDL.  Start with a flip flop, maybe that is a
>> structural example progress to a more complex digital circuit, say a
>> clock, maybe that is RTL, and then onto High Level.    In particular I
>> would love to see a hardware example of when you use @always, @instance
>> and @always_comb.  Why are there only 3 decorators???? I think I
>> understand it, but I keep getting it wrong.  And then at a certain
>> point, say okay here is more stuff you can model, but that you cannot
>> synthesize.  Better yet, say this is more stuff you can model, but
>> cannot use to create an FPGA.  And I would love to add my section on
>> what you cannot synthesize to the docs.  In fact I would love to move
>> all or part of my wiki onto MyDHL.org
>
> 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?
>

You are absolutely correct!  The MyHDL manual should not be expected to 
teach hardware design, hardware verification, system modeling, hardware 
modeling etc.  Or what an FPGA or IC's are or how to design them.

Regards,
Chris

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

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

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

-- 
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 G. <dsg...@gm...>]

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.

On Wed, May 2, 2012 at 7:48 PM, Tom Dillon <td...@di...> wrote:
> On 05/02/2012 06:30 PM, Christopher Lozinski wrote:
>
> On 5/2/12 3:58 PM, Christopher Felton wrote:
>
> On 5/2/2012 1:52 PM, Uri Nix wrote:
>
> IMHO it /is/ confusing, since the previous topics in the chapter are
> synthesis oriented.
>
> The manual under "Modeling techniques" currently progresses; structural,
> RTL, High-level.  Do you think a top-down versus bottom-up order would
> be better?  Someone *without* a HW design background may find;
> High-level, RTL, structural order less confusing?  Or, in your opinion,
> do you think it needs to be a completely separate chapter?
>
> It is still all not clear to me.  I am not sure about top down or bottom
> up.  There are two different target markets, the experienced hardware
> designers, and the experienced software developers.  I can only speak
> for the later.
>
> I would love to see it structured more as a tutorial on hardware design
> than as a class on MyHDL.  Start with a flip flop, maybe that is a
> structural example progress to a more complex digital circuit, say a
> clock, maybe that is RTL, and then onto High Level.    In particular I
> would love to see a hardware example of when you use @always, @instance
> and @always_comb.  Why are there only 3 decorators???? I think I
> understand it, but I keep getting it wrong.  And then at a certain
> point, say okay here is more stuff you can model, but that you cannot
> synthesize.  Better yet, say this is more stuff you can model, but
> cannot use to create an FPGA.  And I would love to add my section on
> what you cannot synthesize to the docs.  In fact I would love to move
> all or part of my wiki onto MyDHL.org
>
>
> 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?
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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

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

On 05/02/2012 06:30 PM, Christopher Lozinski wrote:
> On 5/2/12 3:58 PM, Christopher Felton wrote:
>> On 5/2/2012 1:52 PM, Uri Nix wrote:
>>> IMHO it /is/ confusing, since the previous topics in the chapter are
>>> synthesis oriented.
>> The manual under "Modeling techniques" currently progresses; structural,
>> RTL, High-level.  Do you think a top-down versus bottom-up order would
>> be better?  Someone *without* a HW design background may find;
>> High-level, RTL, structural order less confusing?  Or, in your opinion,
>> do you think it needs to be a completely separate chapter?
> It is still all not clear to me.  I am not sure about top down or bottom
> up.  There are two different target markets, the experienced hardware
> designers, and the experienced software developers.  I can only speak
> for the later.
>
> I would love to see it structured more as a tutorial on hardware design
> than as a class on MyHDL.  Start with a flip flop, maybe that is a
> structural example progress to a more complex digital circuit, say a
> clock, maybe that is RTL, and then onto High Level.    In particular I
> would love to see a hardware example of when you use @always, @instance
> and @always_comb.  Why are there only 3 decorators???? I think I
> understand it, but I keep getting it wrong.  And then at a certain
> point, say okay here is more stuff you can model, but that you cannot
> synthesize.  Better yet, say this is more stuff you can model, but
> cannot use to create an FPGA.  And I would love to add my section on
> what you cannot synthesize to the docs.  In fact I would love to move
> all or part of my wiki onto MyDHL.org

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?

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

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

On 5/2/12 3:58 PM, Christopher Felton wrote:
> On 5/2/2012 1:52 PM, Uri Nix wrote:
>> IMHO it /is/ confusing, since the previous topics in the chapter are
>> synthesis oriented.
> The manual under "Modeling techniques" currently progresses; structural, 
> RTL, High-level.  Do you think a top-down versus bottom-up order would 
> be better?  Someone *without* a HW design background may find; 
> High-level, RTL, structural order less confusing?  Or, in your opinion, 
> do you think it needs to be a completely separate chapter?
It is still all not clear to me.  I am not sure about top down or bottom
up.  There are two different target markets, the experienced hardware
designers, and the experienced software developers.  I can only speak
for the later.

I would love to see it structured more as a tutorial on hardware design
than as a class on MyHDL.  Start with a flip flop, maybe that is a
structural example progress to a more complex digital circuit, say a
clock, maybe that is RTL, and then onto High Level.    In particular I
would love to see a hardware example of when you use @always, @instance
and @always_comb.  Why are there only 3 decorators???? I think I
understand it, but I keep getting it wrong.  And then at a certain
point, say okay here is more stuff you can model, but that you cannot
synthesize.  Better yet, say this is more stuff you can model, but
cannot use to create an FPGA.  And I would love to add my section on
what you cannot synthesize to the docs.  In fact I would love to move
all or part of my wiki onto MyDHL.org

I guess words like structural, RTL, and High level make sense to the
chip designers, but for me I am not quite sure of the differences. 
Specific examples would be much more helpful.

The point is, if you are targeting python developers, then the
documentation needs to be written in ways that are mindful of their
mindset.  They understand python, but not chip design, so explain the
later to them. 

In contrast, the hardware guys are probably quite happy with the current
manual structure, although I cannot speak for them.

I hope that helps.

Re: [myhdl-list] MyHDL, LGPL, Business Model and Patents.

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

On 05/01/2012 07:59 PM, Christopher Lozinski wrote:
> http://wiki.myhdlclass.com:8080/License

In case somebody worries about this: don't.

The LGPL is crystal clear.

What it means with MyHDL is the following. Suppose that you
distribute a product that uses MyHDL, such as a high-level
synthesis tool or the RTL code for an IP block. Then you have
to open source any changes made to the myhdl library itself,
under the same LGPL license. But with your own code, the
code that imports the myhdl library, you can do what you
want, including keeping it completely closed.

-- 
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] Object Oriented Modelling

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

On 04/30/2012 07:06 PM, Christopher Lozinski wrote:
> Here are my comments on the Object Oriented Queue Model in the
> documentation.
>
> wiki.myhdlclass.com:8080/ObjectModels

To quote from your page:
"I thought that all MyHDL generators had to have a decorator."

This is wrong, and I went back to the manual to check what it
says. I think it is quite clear. It states explicitly that the
basic MyHDL elements are generators. Decorators are just a (very
convenient) way to create them for a number of common cases.

Once again, I think the confusion comes from a basic
misunderstanding: the difference between general modeling and
conversion/synthesis. However, the manual is explicit about
this in the chapter about conversion. I quote:

"""
For pure modeling, it doesn’t matter how generators are created.
However, in convertible code they should be created using one
of the MyHDL decorators: instance(), always() or always_comb().
"""

-- 
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/2012 1:52 PM, Uri Nix wrote:
> IMHO it /is/ confusing, since the previous topics in the chapter are
> synthesis oriented.

The manual under "Modeling techniques" currently progresses; structural, 
RTL, High-level.  Do you think a top-down versus bottom-up order would 
be better?  Someone *without* a HW design background may find; 
High-level, RTL, structural order less confusing?  Or, in your opinion, 
do you think it needs to be a completely separate chapter?

Regards,
Chris

>
> 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.
>
> Cheers,
> Uri
>
>
> On 2 May 2012 18:55, Tom Dillon<td...@di...>  wrote:
>
>>   I think the manual is clear and it makes pretty good sense what can be
>> converted.
>>
>> One of the great things about MyHDL/Python is that as long as your code at
>> the lowest level is RTL, then it will convert.
>>
>> You can use all the power of Python of top of that to make very high level
>> structures.
>>
>>
>>
>> On 05/02/2012 10:30 AM, Jan Decaluwe wrote:
>>
>> On 04/27/2012 02:52 AM, Christopher Lozinski wrote:
>>
>>
>>   The higher level approach is to model things as objects. There is a
>> queue example in the docs.  This stuff blows my mind.  How that can be
>> synthesized, what it means in terms of hardware functions, I really do
>> not yet understand.   Sure the queue example is easily understandable to
>> a software engineer, but what does that look like when converted?
>>
>>   I went back to the manual, to understand where so much confusion can
>> come from.
>>
>> But really, I don't see it. I think the manual is crystal clear. In the
>> chapter you refer to, it describes a number of modeling options that
>> MyHDL supports. When it talks about RTL, it explicitly makes the connection
>> with synthesis. Then it moves on to high-level modeling - I think
>> it's obvious that there is no direct link with synthesis.
>>
>> To understand the link between conversion and synthesis, move to the
>> chapter about conversion. It explicitly states that the first goal
>> of conversion is synthesis, but also that the convertible subset
>> is more general than the synthesizable subset. And it describes
>> the convertible *subset*.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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

[Uri N. <ur...@gm...>]

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.

Cheers,
Uri


On 2 May 2012 18:55, Tom Dillon <td...@di...> wrote:

>  I think the manual is clear and it makes pretty good sense what can be
> converted.
>
> One of the great things about MyHDL/Python is that as long as your code at
> the lowest level is RTL, then it will convert.
>
> You can use all the power of Python of top of that to make very high level
> structures.
>
>
>
> On 05/02/2012 10:30 AM, Jan Decaluwe wrote:
>
> On 04/27/2012 02:52 AM, Christopher Lozinski wrote:
>
>
>  The higher level approach is to model things as objects. There is a
> queue example in the docs.  This stuff blows my mind.  How that can be
> synthesized, what it means in terms of hardware functions, I really do
> not yet understand.   Sure the queue example is easily understandable to
> a software engineer, but what does that look like when converted?
>
>  I went back to the manual, to understand where so much confusion can
> come from.
>
> But really, I don't see it. I think the manual is crystal clear. In the
> chapter you refer to, it describes a number of modeling options that
> MyHDL supports. When it talks about RTL, it explicitly makes the connection
> with synthesis. Then it moves on to high-level modeling - I think
> it's obvious that there is no direct link with synthesis.
>
> To understand the link between conversion and synthesis, move to the
> chapter about conversion. It explicitly states that the first goal
> of conversion is synthesis, but also that the convertible subset
> is more general than the synthesizable subset. And it describes
> the convertible *subset*.
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>

[myhdl-list] What is not convertible.

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

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.  

License agreement at bottom of page.   Edits are welcome.

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

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

I think the manual is clear and it makes pretty good sense what can be 
converted.

One of the great things about MyHDL/Python is that as long as your code 
at the lowest level is RTL, then it will convert.

You can use all the power of Python of top of that to make very high 
level structures.



On 05/02/2012 10:30 AM, Jan Decaluwe wrote:
> On 04/27/2012 02:52 AM, Christopher Lozinski wrote:
>
>> The higher level approach is to model things as objects. There is a
>> queue example in the docs.  This stuff blows my mind.  How that can be
>> synthesized, what it means in terms of hardware functions, I really do
>> not yet understand.   Sure the queue example is easily understandable to
>> a software engineer, but what does that look like when converted?
> I went back to the manual, to understand where so much confusion can
> come from.
>
> But really, I don't see it. I think the manual is crystal clear. In the
> chapter you refer to, it describes a number of modeling options that
> MyHDL supports. When it talks about RTL, it explicitly makes the connection
> with synthesis. Then it moves on to high-level modeling - I think
> it's obvious that there is no direct link with synthesis.
>
> To understand the link between conversion and synthesis, move to the
> chapter about conversion. It explicitly states that the first goal
> of conversion is synthesis, but also that the convertible subset
> is more general than the synthesizable subset. And it describes
> the convertible *subset*.
>

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

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

On 04/27/2012 02:52 AM, Christopher Lozinski wrote:

> The higher level approach is to model things as objects. There is a
> queue example in the docs.  This stuff blows my mind.  How that can be
> synthesized, what it means in terms of hardware functions, I really do
> not yet understand.   Sure the queue example is easily understandable to
> a software engineer, but what does that look like when converted?

I went back to the manual, to understand where so much confusion can
come from.

But really, I don't see it. I think the manual is crystal clear. In the
chapter you refer to, it describes a number of modeling options that
MyHDL supports. When it talks about RTL, it explicitly makes the connection
with synthesis. Then it moves on to high-level modeling - I think
it's obvious that there is no direct link with synthesis.

To understand the link between conversion and synthesis, move to the
chapter about conversion. It explicitly states that the first goal
of conversion is synthesis, but also that the convertible subset
is more general than the synthesizable subset. And it describes
the convertible *subset*.

-- 
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 04/27/2012 02:52 AM, Christopher Lozinski wrote:
> You can see the long term version of this page at:
>
> http://wiki.myhdlclass.com:8080/WhenToUse
>
> The different modelling options in MyHDL are very confusing.  I get the
> idea of digital circuits as blocks that have inputs and outputs.  But
> there are three different ways to represent them in MyHDL, @always(),
> @instance(), and @always_comb()  Which should I use?

If there is confusion, I believe it is in the mindset that
MyHDL is for implementation only.

This keeps coming up. I have tried to clarify the issue once and
for all explictly by rephrasing an item in the "What MyHDL is not" page:

http://myhdl.org/doku.php/whatitisnot?&#myhdl_is_not_only_for_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

[myhdl-list] Actel/Microsemi IGLOO nano starter kit

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

I have a number of MyHDL projects which build source files for 
demos on this low power FPGA card, and would be happy to share 
these.  Card detail:

http://www.actel.com/products/hardware/devkits_boards/igloonano_starter.aspx

They include access to switches and LEDs on the board, and the 
source for a UART for linking the card to a host PC.

Next, I moving on to testing the block RAMs, then building a 
complex processor cache.  Anyone been there before?

Jan Coombs
-- 
jan4myhdl at the above domain

Re: [myhdl-list] Restrictions for conversion

[Norbo <Nor...@gm...>]

> I was taking a look at your patch, your patch is not based on the latest
> 0.8-dev branch.  There are enough changes that it doesn't auto import to
> the 0.8-dev branch.
>
> I don't know if the _doinit flag is actually needed?  I believe the
> conversion code can determine if the value should be written or not
> without modifying the Signal or intbv objects.  As your modified intbv
> does, it can always create the initial value unless the Signal/intbv
> init value is None.
Yes this would be possible if the value (._val) of the intbv is set to
None.
But there are several things that raise, exceptions if the value is set to
None. (Boundcheck, __getitem__, etc..)
so i added the _doinit flag and set the (._val) to 0 (or to the min value
if defined), and thereby avoided the error-prone changing of these
functions which wouldnt work with the None value.


> Lastly, the changes do break the unit-tests.  As mentioned, the patch
> didn't auto import.  I believe I got all the changes manually but
> possibly something was missed in the manual addition of the changes.  I
> think removing the _doinit will fix the failures (but I didn't really
> look that closely).
The now appended patch file is based on the 0.8-dev branch, the core test
passes but until now i wasnt able to
run the  conversion tests.

The initial values in this patch for the array signal are now written in
the following casess:  for VHDL and Verilog:

1. reading it in a combinatorical process --- initial values are written
2. reading it synchron (clocked)            --- initial values are
written  (could be used to describe inited ROM)
3. reading it synchron (clocked) and writing it synchron  --- initial
values are written (could be used to describe pre-inited RAM, or even
pre-inited dual ported RAM)
4. reading it synchron (clocked) and writing it in a combinatorical
process --- initial values are not ! written (because it is syntactically
not possible in verilog)
5. reading and writing in a combinatorical process       ---  initial
values are not ! written (because it is syntactically not possible in
verilog)


would this be acceptable/desirable?

greetings
Norbo

[myhdl-list] MyHDL, LGPL, Business Model and Patents.

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

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

Anyhow thanks for everything guys.  I have learned a huge amount from
this group.  Thank you to the guy who posted the source for a python
processor.  Boy was that an inspiration.  Thanks to Jan for all his time
and feedback.  Thanks to Chris Felton for writing a blinking light tutorial.

I will point out the email list  traffic histogram.
http://dir.gmane.org/gmane.comp.python.myhdl

I think that huge peak was when I started the trade show initiatives. 
So I had some use to this mailing list. 

Here are my last thoughts.
http://wiki.myhdlclass.com:8080/VerilogVsMyHDL

-- 
Regards
Christopher Lozinski

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

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

[myhdl-list] Object Oriented Modelling

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

Here are my comments on the Object Oriented Queue Model in the
documentation.

wiki.myhdlclass.com:8080/ObjectModels

If any other MyHDL beginners wants to talk about their designs, I would
be hugely interested in skyping. 

-- 
Regards
Christopher Lozinski

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

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

[myhdl-list] conversion to case statement - odd behaviour?

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

In this code the first condition is separated into a separate 'if' 
with the 'elif' lines becoming part of a verilog case statement:

   @always(keyDBclk.posedge)
   def ledLatchLogic():
     ''' connect push button event to action '''
     if   keyEventPB_SW==1:  ledLatch.next = ledLatch>>1
     elif keyEventPB_SW==2:  ledLatch.next = ~ledLatch
     elif keyEventPB_SW==4:  ledLatch.next = ~DIP_SW
     elif keyEventPB_SW==8:  ledLatch.next = (ledLatch<<1) & 255
     else:                   ledLatch.next = ledLatch

I have tried reversing the order of bit selection, and without the 
'else'/'default' clause.

Jan Coombs

Re: [myhdl-list] Restrictions for conversion (initial values)

[Norbo <Nor...@gm...>]

Am 26.04.2012, 05:49 Uhr, schrieb Christopher Felton  
<chr...@gm...>:


>> .. signal cant be defined as reg when you write to in a combinatorical
>> process. So if you write to just one signal in the array the whole array
>> needs to be defined as wire and you cant use the
>> initial statment for that signal array, so you cant initialize all the
>> other signals which are not written in a combinatorical process.
>> it normally makes sense that  if you have a inital value in a signal  
>> that
>> you are not allowed to overwrite it immidiatly with an combinatorical
>> assignment.
>> But the problem is that if you just use one signal of the array to write
>> to it in a combinatorical process, you "lose" the hole array.
>>
>> Addition: "if there is a asynchron reset in a clocked process where you
>> assign on of the array signals a reset value, then the verilog synthesis
>> works with the initialized array"
>
> This is an alternative to the initial block initial values (pre-init  
> RAM)?

If you initialize the signals in the reset part of the code, then the  
synthesis tool
will map this to a register. So there is no change that the synthesis tool  
can map
this to RAM or BRAM, because average RAM doesnt have an asynchron reset  
input.



The question on the myhdl side for me is really more if i can express all  
sort of different things (e.g pre-init RAM).
This should then give synthesisable code, and  wheter the synthesis tool  
maps it to RAM, ROM, BRAM, registers,LUTs, etc is then dependend on what  
fpga device is used, what synthesis setting are made or how much RAM, ROM,  
logic, etc blocks are left in the device. The last process should be an  
issue of the synthesis tool. And from my expirence in 99% of the cases  
they do a good job
if you give them synthesisable vhdl or "verilog" code.


myhdl side      -> being able to express all sort of things (also pre-init  
RAM), with the goal to produce synthesisable vhdl or verilog code
synthesis tool side -> optimize, map to RAM, ROM, logic, registers  
dependend on what device it is synthesised for. If the device
has no ROM or no RAM, then it will be mapped to logic und registers anyway.





>>
>> 5. reading and writing in a combinatorical process
>> same problem in verilog ->  you cant have the signal array be defined as
>> "wire" and use the init block statment in verilog.
>> Or in other words: If the signal array is defined as "reg" you cannot
>> write to it in a combinatorical process.
>>
> In the above can you clarify between what synthesizes and what creates
> RAM/ROM as expected.

In the above everything is mapped into logic and register, because i used  
the initialized
array with multiple indexes in one expression. -> then everything was  
mapped to logic.
But this doesnt mean that other synthesis tools, or even quartus, could  
map same parts of it to RAM, or ROM blocks, i didn't
looked to deep into the settings.

For me the idea is to produce a code for the synthesis tool, so that the  
synthesis tool at least has the opportunity to map it to a RAM block. If I  
have to assign the initial values at the asynchron reset part to the  
signal, then the synthesis tool as no opportunity to map it into RAM. This  
is where the initial values and initial blocks come into play, beeing able  
to express this.



greetings
Norbo

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

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

You can see the long term version of this page at:

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

So I have a first draft of my floating point multiplier module, and I
just wanted to make sure I am doing the modelling right.  I find the
best way to work with open source is to document it.  Then people after
me have an easier path, and the people who came before are quite happy
to correct the documents, rather than let poor information hang out
there.  So here goes again. 

The different modelling options in MyHDL are very confusing.  I get the
idea of digital circuits as blocks that have inputs and outputs.  But
there are three different ways to represent them in MyHDL, @always(),
@instance(), and @always_comb()  Which should I use? 
 
It has to do with what the electrical engineers call sensitivity lists. 
When do you want the statements to run?  If you want something that runs
at well defined times, use the @always.  So a clock driver would be on
@always, or maybe something that runs with each positive edge of the
clock signal.  Or it runs on the basis of any other signals or signal
edges you want it to be based on.  Or things that run on regular delay
intervals.  There are other ways to accomplish the same sensitivity
list,  but that is the simplest.  And sense the sensitivity list is in
the @always statement, it should not have sensitivity lists in the yield
statements.   

If you have combinatorial logic, and you want it to run whenever the
logic changes, use @always_comb.  It figure out by itself when to run
based on the inputs to the module.   And finally if you want to return
changing sensitivity lists, use @instance.  Then it can have different
yield statements at different times. 

Having written this documentation, it helped me to  figured out the
solution to my problem.  My floating point multiplier initially just
needs to run when the start signal is given.  Once it has started, it
also needs to wait 14 clock cycles for the pipelined result to be
returned.  So I need to use the @instance, so I can change the
sensitivity list as required. 

@always(args)
   This is a decorator.  It turns the following function into a
generator.  The args can either be a delay, or a signal, or a positive
or negative edge.  No yield statement is required. In fact no yield
statement is allowed. 

@instance()
   This is a simpler decorator.  The decorated function has to be a
generator already, meaning it has to have one or more yield statements.

@always_comb()
   This is a decorator.  It turns the following function into a
generator.  It figures out what the input signals are, and if any of
them change, the function is executed. 

I was really surprised by the example in the documents that went

   statement 1
   yield
   statement 2
   yield

If you think of yield like a return statement, that makes no sense.  But
yield is not a return statement, when the code generator picks up again,
it just keeps running, so the multiple yield statements do make sense. 
Just hard to understand the first time I read it.

The higher level approach is to model things as objects. There is a
queue example in the docs.  This stuff blows my mind.  How that can be
synthesized, what it means in terms of hardware functions, I really do
not yet understand.   Sure the queue example is easily understandable to
a software engineer, but what does that look like when converted?

Anyhow I hope that helps you.  I am sure I got it wrong, but there is a
process of writing, and people correcting it, that hopefully helps all
concerned. 




-- 
Regards
Christopher Lozinski

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

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

Re: [myhdl-list] Open Task Wiki Page

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

On 04/26/2012 05:15 AM, Christopher Felton wrote:
> Back in the day Jan D. create the open-task wiki page.  This was
> intended to be descriptions of open items that an interested developer
> could tackle as a first/learning contribution item.
>
> Many of these tasks have been completed.  I have summarized the open
> task list below and indicated which tasks I believe have been completed.
>    Feel free to provide feedback and comments on the accuracy of the
> "status".
>
>     * "... intbv or Signal as array index" - Status: Completed.  This
>       has been implemented.  Believe this was added in 0.7
>
>     * "Initial value support" - Status: Open.  Have been some recent
>       conversations.
>
>     * "Support for tristates" - Status: Completed  This feature was
>       added with the addition of shadow signals in 0.7.  There seems
>       to be a bug, the "FAQ Tristates" post has an example.
>
>     * "General support of indexed constants" - Status: Open.
>
>     * "Support for conditional expressions" - Status: Completed
>
>     * "RPM package for Fedora" - Status: Completed
>
>
> If these are correct, I can update the page with the latest status.

Correct afaik.


-- 
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] Floating Point MEP

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

On 4/26/12 2:26 AM, Jan Decaluwe wrote:
> On 04/26/2012 12:05 AM, Christopher Lozinski wrote:
>>
>> Anyhow MyHDL does need the floating point modules. If I get them up
>> and simulating correctly, then I am sure other newbies will start
>> using them. Even without the conversion stuff. Anyone interested?
> Wait a moment here, let's take a step back. You can perfectly
> do event-driven system simulations with MyHDL using Python floats.
> As I keep saying, modeling is intended to be completely general.
> You can perfectly use floats or other Python types as the underlying
> base type in a MyHDL signal.  Today.
>
Thank you enormously.   I did do a first draft of the code last night,
not yet interpreting, but it is a bit of a tangle.  By just using python
floats in the simulation, it will all get much easier.   I can simplify
things hugely for the first release.

Maybe that will also be easier to export than a hierarchical
representation.  Back to reading the source code.  There is good
documentation in the spec directory of the source code. 

-- 
Regards
Christopher Lozinski

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

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

Re: [myhdl-list] Floating Point MEP

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

On 04/26/2012 12:05 AM, Christopher Lozinski wrote:
>
>
> Anyhow MyHDL does need the floating point modules. If I get them up
> and simulating correctly, then I am sure other newbies will start
> using them. Even without the conversion stuff. Anyone interested?

Wait a moment here, let's take a step back. You can perfectly
do event-driven system simulations with MyHDL using Python floats.
As I keep saying, modeling is intended to be completely general.
You can perfectly use floats or other Python types as the underlying
base type in a MyHDL signal.  Today.

A meaningful way of working would be to get the system simulations
to work first, and then later on refine and use user-defined code etc.
to get it to convert, if necessary.

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