myhdl-list

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

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

On 19/05/12 02:13, Christopher Lozinski wrote:
    . . .
> Let us lighten up a little bit.  And embrace all the wonderful ideas
> that this group of people have.  Let us face it, we are not mainstream
> digital circuit designers.  There are some very interesting ideas
> floating around.  I love Dillon's examples of  Hierarchical signals,
> complex numbers.  I love the idea of building a python processor.

Excellent.  I have a delightful little processor, not python, but 
shares some features.  It should be able to support interactive 
code development while running in the MyHDL simulator, but,

I got stuck trying to choose the best way to simulate a comm port 
which would link the development tools to the hardware.  perhaps 
you could fix this?

You could also use this design to develop your ideas about higher 
level hardware description.  There is already one example of module 
reuse in the design.

This project is unusual, it is tiny, you will be able to understand 
the hardware and target code generation from top to bottom, and if 
successful you will have a silicon embeddable processor capable of 
interactive code generation and LED blinking.

The code set is summarised below, Jan Coombs.
-- 

b16_ComponentList_asat2012-05-19

Hardware Source in MyHDL
------------------------
test_b16.py        3.0
   b16_ram.py      11.0   (simple tests)
   b16_cpu.py      16.6
     b16_opcodes    5.2
     b16_alu.py     2.2
     b16_stack2.py  1.7
                   ----
                   39.7 kB

Cross Development Tools in gForth
---------------------------------
b16_jc.fs     10.6  assembler &c
   strings.fs   6.7  string support
   serial.fs    6.4  PC comm port support
   syscalls.fs  1.4  PC hw driver access
               ----
               25.1 kB

Code For Target in b16 'Assembler'
----------------------------------
boot.asm    6.2  signon & blink LED
b16.asm     2.4  instruction set test
sieve.asm   0.5  another test
usb.asm     0.3  incomplete
             ---
             9.4 kB

Original source:
http://bernd-paysan.de/b16.html

Re: [myhdl-list] What MyHDL is not

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

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

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

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

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

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

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

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


-BobC

Re: [myhdl-list] What MyHDL is not

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

On 04/24/2012 05:20 AM, Bob Cunningham wrote:

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

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

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

http://www.myhdl.org/doku.php/why#you_would_like_to_do_algorithm_development_and_implementation_in_the_same_environment

http://www.myhdl.org/doc/current/manual/unittest.html



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

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

[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

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

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

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

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

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


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

[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] What is not convertible.

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

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

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

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

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

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

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

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

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

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

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

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

On 5/4/12 8:34 AM, Tom Dillon wrote:
> Right now debating whether or not you can use classes is absurd. 
Thank you for being sensitive to my concerns.  And yes this time I am
being sarcastic.

I did not say you could not use classes.  I said that there are specific
representational issues in MyHDL which conflict with my world view.  
You completely failed to address the specific concern I have, instead
resorting to attacking my experience level.

Be hard on issues, soft on people.   You ignored the issue, and were
hard on me.    I am not surprised by the response, but I am glad to have
figured out the specific technical problem I have with MyHDL.   My
apologies if I had to bounce around to figure it out.

Regards
Chris





-- 
Regards
Christopher Lozinski

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

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

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

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

Hardly an attack.

I fail to see the issue to be hard on.



On 05/04/2012 09:27 AM, Christopher Lozinski wrote:
> On 5/4/12 8:34 AM, Tom Dillon wrote:
>> Right now debating whether or not you can use classes is absurd.
> Thank you for being sensitive to my concerns.  And yes this time I am
> being sarcastic.
>
> I did not say you could not use classes.  I said that there are specific
> representational issues in MyHDL which conflict with my world view.
> You completely failed to address the specific concern I have, instead
> resorting to attacking my experience level.
>
> Be hard on issues, soft on people.   You ignored the issue, and were
> hard on me.    I am not surprised by the response, but I am glad to have
> figured out the specific technical problem I have with MyHDL.   My
> apologies if I had to bounce around to figure it out.
>
> Regards
> Chris
>
>
>
>
>

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

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

> I don't want to start a discussion about the merits of your point
> of view, but again I point out that heavy MyHDL users, myself included,
> see things entirely differently.
>
> I developed MyHDL because I wanted to do modeling and verification
> in python, and stock python didn't give me the fine-grained threading
> and event-driven paradigm needed. At that time, it was not clear if
> it was desirable or even possible to do conversion as a path to  
> synthesis.
>
> If synthesizable code would be all it did, I wouldn't see the point.

For me, synthesizable code is also a key aspect in Myhdl.
Back in University and in two Jobs where i worked with VHDL the major
job to do was to implement several Filters or Signalprocessing piplines  
where
lookuptables occoured. Normally i used Matlab or Python (with pylab) to
calculate these Filter coeffiecents or lookuptable values. The question
then was how to get these values to the VHDL design. This is really a
pain because in some stages of development these coeffiecents or  
lookuptable values
change quite often, and every time they change i had to copy and paste  
them, change
signal value ranges, array ranges, etc... --> with Myhdl i can use these  
values directly from
the python code where i calculated them and let the signal value range,  
array range, etc..
be adjusted automatically. For me this is really extremly usfull and  
really simplifies the process.

I think that fast signal processing piplines with lookuptables and filter  
design is a key area for
hardware description languages and FPGAs. The other key area is maybe  
special bus interfaces, for them
i didn't see a point of synthesisable Myhdl either. --> I couldn't think  
of any other case right now where
a standard microcontroller or DSP wouldn't be enough.

Back in University we also did some golden model checking for a cordic  
VHDL core design, by using SystemC with tlm
and doing coSimulation. This is where the pain really starts. This is  
where Myhdl really starts to shine. If
we would have used Myhdl back then, i think we really could have skipped  
half a year.


greetings
Norbo

[myhdl-list] Jan Coomb's Processor

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

It looks like you have made huge process on this device.  Not only in
MyHDL, but also in forth.   Congratulations on the hard work. 

I like that you list the components, RAM, CPU, Stack, ALU.  Goes a long
way to explaining what you have built. Of course code is always painful
to read through, English high level description is always easier and
faster to read.  The article on a forth processor in FPGA looks hugely
interesting.  What is your relationship with the author?

I did not understand the table at the top of your web page.  What are
the horizontal and vertical axes?

So let me ask the obvious marketing questions.  How many transistors are
in this device?  How many in the 8051?  Better yet, how many in each
component, where did you shrink it the most?   And how many instructions
per second can each execute.   Which component slows you down the most? 
Obviously this is on a FPGA, the other on silicon, so one needs to scale
between them.

Many many years ago, Marvin Minsky, an AI professor at MIT tried to
build a slower cpu.  A bit embarrassing.  He does not talk about it very
much.  But a smaller, more power and space efficient cpu is a great idea. 

So how much better is this device?  Of course the real test are the
benchmarks.


Regards
Chris







-- 
Regards
Christopher Lozinski

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

Expect a paradigm shift.
http://MyHDLClass.com:8080

Re: [myhdl-list] Bernd Paysan's b16 processor in MyHDL

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

On 19/05/12 12:41, Christopher Lozinski wrote:
> It looks like you have made huge process on this device.  Not only in
> MyHDL, but also in forth.   Congratulations on the hard work.
Not mine!  Credits appear in sources.

> I like that you list the components, RAM, CPU, Stack, ALU.  Goes a long
> way to explaining what you have built. Of course code is always painful
> to read through, English high level description is always easier and
> faster to read.  The article on a forth processor in FPGA looks hugely
> interesting.  What is your relationship with the author?
Bernd rides what I dreamed of as a boy.  I just split his code into 
separate files, and expanded the signal names so it would be easier 
for you to read.

> I did not understand the table at the top of [Bernd's] web page.  What are
> the horizontal and vertical axes?
This is the instruction set matrix, but there is a much clearer one 
in the MyHDL source file.

> So let me ask the obvious marketing questions.  How many transistors are
> in this device?  How many in the 8051?  Better yet, how many in each
> component, where did you shrink it the most?   And how many instructions
> per second can each execute.   Which component slows you down the most?
> Obviously this is on a FPGA, the other on silicon, so one needs to scale
> between them.
Bernd has used this [2] in silicon, but, as I have no access to 
silicon I do not know.  Because the instruction set is unusual, you 
would need to test with some real code; give it a try.

> Many many years ago, Marvin Minsky, an AI professor at MIT tried to
> build a slower cpu.  A bit embarrassing.  He does not talk about it very
> much.  But a smaller, more power and space efficient cpu is a great idea.
I recently heard that the wiring in the brain is like layers of 
matting, providing X & Y axis fibers, with Z axis fibers 
penetrating the layers of matting. [1]  Having a large number of 
simpler slower processors is no problem if you have massive 
interconnect, and superb organisational skills.

> So how much better is this device?  Of course the real test are the
> benchmarks.
Yes, you could start with just the hardware description in MyHDL, 
and test a few instructions, then move on to using the cross 
development tools.  Any documentation shortages we could make up 
between us.

It would be good to get interactive code development working using 
the cross-dev tools and the MyHDL model.  Then you could choose 
some simple jobs, and get benchmarking.

Jan Coombs
-- 
[1] http://www.nsf.gov/news/news_images.jsp?cntn_id=123711&org=NSF
[2] http://bernd-paysan.de/b16.html

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

[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

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

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

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

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

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

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

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

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

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

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

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

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

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

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

Regards,
Chris

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

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

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

Exactly!

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

Right again!




-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

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

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

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

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

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

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

wiki.myhdlclass.com:8080

Some of it is even correct.

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

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

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

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

t must be more complicated than that.

Chris

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

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

On 05/03/2012 10:23 PM, G. Andrew Stone wrote:
> Hi Jan,
>
> Let me try to say it in another way.  Please forgive any
> inaccuracies; its been a few years! :-)
>
> If my synthesizable hardware description was put in a simulation
> black box (call it "hdl") with some simple API that could be used
> like:
>
> hdl.start() for time in range(1,whatever): output_signals =
> hdl.next(list_of_input_signals)
>
> then as a software engineer I'd completely understand how to write a
> complex simulation and testbench around it.  For example, if my "hdl"
> object defined a PCI bus card I could pretty easily write Python code
> that jams in a bunch of fake PCI requests and make sure the right
> stuff comes out.  I could easily make up code that runs a bunch of
> these black boxes simultaneously and use unsynthesizable python to
> "glue" them together to make a larger system -- thereby simulating a
> subset of some larger system.  I could even have each black box
> "running" at different clock speeds.  Or I could even hook the
> simulation black box up to the actual code that will run on a CPU and
> talk to my FPGA.

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

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

[myhdl-list] Wiki Errors

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

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

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

-- 
Regards
Christopher Lozinski

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

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

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

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

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

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

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

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

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com