myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Restrictions for conversion

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

On 5/5/12 10:20 AM, Norbo wrote:
> Am 05.05.2012, 12:41 Uhr, schrieb Christopher Felton
> <chr...@gm...>:
<snip>
>>>>>>
>>>>>> 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.
>>>>
>>>> Why do you need "None"?  It would be my understanding that the
>>>> conversion process will always create the init values in the converted
>>>> code.  You don't need the _doinit flag and you don't need None.
>>>
>>> My thought on this was that it may be usefull to have explicit controll
>>> on
>>> whether the initial values are written ot not. For example if a big ram
>>> is
>>> described
>>> and you don't need the initial values, the converted file would be
>>> filled
>>> up with a
>>> huge number of basically useless values. ->   Or in the words of "import
>>> this" in python:
>>> Explicit is better than implicit
>>>
>>
>> To me this is *not* explicit, you don't have direct control over _doinit
>> you have implicit control if the initial values are generated or not
>> (which I have even forgotten what the control is).
> The idea of the controll was if you write:
>       aList=[Signal(intbv(None)) for i in range(10) ]  -->  then the initial
> values are not written no matter what.
>       aList=[Signal(intbv(i)) for i in range(10) ]  -->  the initial values
> are written in verilog and vhdl when there is
> 							no combinatorical assignment ("as a path of least resistance right
> now")
>
>

I think we are both in agreement, now, that the None can be used for the 
explicit control (which means more changes in the implementation).  But 
I don't think I agree that there are cases when the values should *not* 
be written.  I think they should always be written (when not None).  I 
think we can work through the implementation changes.

If None is used, that should mean the _doinit is not required.

>
>
>> I hear the argument for the large inclusive of init values.  And with
>> FPGA embedded memories and ASIC available ROM/RAM growing these could be
>> long init lists.  But I am not totally convinced the inconvenience of
>> long inits are bad because it breaks the earlier argument "MyHDL to
>> Verilog/VHDL mismatch".
>
> I didn't get that.

It has been brought up in the past that if MyHDL simulation has initial 
values and the Verilog/VHDL does not have initial values.  Then you have 
a simulation mismatch at time 0 through time N (most cases, until the 
reset occurs).

I think we have a good design plan to cover the initial values that 
includes the pre-init RAMS (nice addition).  We should probably 
summarize in a separate post (new thread, not buried).  I boils down to 
adding support for None and then creating  initial values in 
Verilog/VHDL if the intbv initial value is not None.

Regards,
Chris

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

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

On 08/05/12 13:19, Christopher Felton wrote:
> As you mentioned others are trying to give strong opinions on how to
> fish without understanding much about fishing (or why we are fishing).

Whether putting up a TV broadcast aerial, or just building a small 
house we have two principal choices: Understand all the engineering 
implications down to bedrock, or accept a ready made platform.

If the platform is as high as a TV tower, it might be good to know 
something of it's behaviour in wind before climbing up to install 
an aerial, just in case some extra pills are needed!  However, 
looking up at the waving top, and suggesting design modifications 
is likely to lessen the chance of anyone's aerial becoming installed.

> By hinder progress, you simply mean your attention is diverted to a
> lower-level non-related topic?

No, worse than that!  I get very interested in lower levels of the 
design in progress, the stuff that I can't control, and should 
happily entrust to synthesis tools.

> In general the claim to fame by [1] is
> that it takes the known, successful, design techniques and does the
> translation to async itself.

We might never need anything better!:)  Since RTL balances delays 
between latches (to a first approximation), then replacing buffers 
with 'signal re-synchronisation' logic should just work.

However, I dislike black boxes, so shall insist that I need to know 
the details, so that I can predict any odd cases where simple 
translation is not the best option.

> MyHDL should be as useful as any other tool for [1].
Yes, I'm just starting to appreciate it's power.  I struggle to 
read verilog in places where it is very terse, but also soon tired 
of using VHDL where so many things have to be written in triplicate.

> Feedback is always welcome, it might be challenged but I believe you and
> most have found that the group here is fair.

Yes, it's been a largely pleasant experience, and I feel 
sufficiently supported.

> It looks like you have been successful with MyHDL.  ...
The UART was the first sign of reasonable productivity. 
Translating the processor designs from verilog to MyHDL was an 
up-hill struggle - two unfamiliar languages, and no obvious means 
of testing anything less that a working whole.

Thanks for the encouragement, Jan Coombs.
-- 
[1] www.achronix.com

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

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

On 5/6/2012 3:23 AM, Jan Coombs wrote:
> On 06/05/12 06:35, Tom Dillon wrote:
>
>> "Experienced python developer", what is that? I am not sure what
>> that has to do with anything.
> True. An "Experienced python developer" is most likely someone who
> has gained some control over a machine at a very high level of
> abstraction. They may know little or nothing about the
> progressively differing layers of software beneath, supporting
> their code.  Likely, the further layers of hardware concepts
> expressed below are completely out of sight.
>
>> There is nothing unnatural about MyHDL. Again, trying to draw
>> somebody into a meaningless discussion.
> I think he's angling to get a fish, a big one.  A person wanting to
> learn to fish would need to be interested in understanding and
> clearly distinguishing the names of the tools, behaviour of fish,
> affects of tides, etc.  Asking why angling is not an iPhone app
> that can be run, sat on a bench in the park while watching bowls is
> pointless.
>
>> MyHDL works fine. I fail to see a conflict at all.
> I'm struggling, but much too inexperienced with Python to suggest
> changing any of MyHDL.

As you mentioned others are trying to give strong opinions on how to 
fish without understanding much about fishing (or why we are fishing). 
Thanks for being one of the sane members of the community.

>
> My hardware experience started with borrowing my mums breadboard
> and dressmaking pins, and using surplus germanium diodes and
> transistors.  I still like to know the details of the fabric I'm
> using.
>
> Today I still have questions, for example: Do clockless gate arrays
> use standard SRAM blocks in an async wrapper, or are they async to
> a much lower level than this.  It may seem pointless to ask, but it
> would help me to estimate the reliability of tools which translate
> RTL designs to use a clockless fabric. [1]
>
> But this extremely low-level interest might hinder my progress in
> using MyHDL in a similar way to having an insufficiently deep
> understanding of electronics.  I'll need to work to get the balance
> right.
>

By hinder progress, you simply mean your attention is diverted to a 
lower-level non-related topic?  In general the claim to fame by [1] is 
that it takes the known, successful, design techniques and does the 
translation to async itself.  MyHDL should be as useful as any other 
tool for [1].

> It has been a hard struggle for me to get started with MyHDL,
> hopefully we can work out why, and make it easier for others in the
> future.
>
> Jan Coombs

Feedback is always welcome, it might be challenged but I believe you and 
most have found that the group here is fair.  And the group is much more 
tolerable to trolls than other groups.

Don't be afraid to ping questions you have asked in the past if you 
still have questions.  It looks like you have been successful with 
MyHDL.  You have posted your UART code (comp.arch.fpga), mentioned your 
forth processor, and a couple other projects.

Regards,
Chris

Re: [myhdl-list] Restrictions for conversion

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

>
>> This might be the path of least resistance right now.  But I don't think
>> there is a reason that the converted couldn't generate
>>
>>        reg [7:0] out1 = 8'd0;
>>        reg [7:0] aListSig [0:10-1];
>>        // initial blocks ...
>>        @always_comb begin
>
> nice: @always_comb begin a myhdl artefact ;)
>
>>            aListSig[3] = in_data
>>            out1 = aListSig[3]
>>        end
>>

Yes, typo should not have included the '@'.  Note: *always_comb* and 
*always_ff* are new key words in later version of Verilog and support by 
most Sysnthesis tools, even the free ones.  Or it is fine to use always 
@(*) or explicitly include the sensitivity list as the VHDL conversion does.

Regards,
Chris

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

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

On 5/3/2012 3: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.
>
> So I (as a software professional) don't need myHDL to help me do that.
> What I need is it to help me with is what's inside that black box.  But the
> docs (but please remember my heavy use was several years ago) keep trying
> to teach me how to do the testbench part.  This confused me because I kept
> thinking I was writing synthesizable code.
>

I don't understand where the confusion comes from?  Both Python and 
MyHDL are tools -languages/tools- that help us build *things* as you 
suggest.

Example, I have a verification framework that I use for building and 
verifying DSP modules.  This has a mix of non-HDL blocks and HDL blocks. 
  Here is a brief preview.

     from myhdl import Simulation
     import blocks
     from filters import MyFilter
     sine1 = blocks.sources.Sine(frequency=40e3, sample_rate=1e6)
     sine2 = blocks.sources.Sine(frequency=30e3, sample_rate=1e6)
     a1 = sine1 + sine2
     flt = MyFilter(a1)
     plot1 = blocks.sinks.Plotter(sine1, sine2, a1, flt)
     v1 = blocks.sinks.VerifySequence(flt, exact=False, vfunc=vfunc)
     Simulation(blocks.GetAllGenerators()).run()

This simple example verifies the expected output of the HDL filter.  OO 
design was used heavily in this framework.  MyHDL and Python are at the 
core, the technologies that enabled me to build such an environment. 
Without MyHDL's objects, functions, and *quality* I would have had to do 
a ton more work (which would have made it non-feasible).  MyHDL enables 
me to have a competitive advantage!

I have had to build, what feels like thousands of simulation models over 
the years, everything from C/C++/SystemC, HDLs, Matlab, etc.  Some of 
these were non-HDL models, others mixed, and others pure HDL.  But 
nothing has been more efficient to develop than Python/MyHDL!  And now 
with the performance improvements I get to watch colleagues never meet a 
schedule and the one weak argument they had ... is irrelevant.

Here is another example:

     @instance
     def tb_stimulus():
        # Write Wishbone memory mapped device
        yield fx2Model.WriteAddress(0x0101, 1)
        yield fx2Model.WriteAddress(0x0103, 0xAA)
        yield fx2Model.ReadAddress(0x0103, rbuf)
        [fx2Model.Write(data, fx2Model.EP4 for dat in test_data1]
        # Wait for the data to transfer
        yield fx2Model.IsEmpty(fx2Model.EP4)
        ...
        raise StopSimulation

In this example I have a model with "transactors".  The transactors 
bridge my event driven model world to the HDL world.

I guess from my point of view you can build frameworks with the 
interfaces you might want.  And these interfaces might be different for 
each problem to solve.

Regards,
Chris

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

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

Now I get it, you need us all to know that you are an experienced python 
programmer (more experienced than the audience here) and also witty.

On 05/06/2012 06:17 AM, Christopher Lozinski wrote:
> On 5/6/12 12:35 AM, Tom Dillon wrote:
>> MyHDL works fine. I fail to see a conflict at all.
> There is a huge difference between representing signals are arguments to
> a function, and as instance variables on an object.   The later supports
> inheritance, and quickly leads to rich libraries of Atomic and Compound
> Hardware Module libraries.  I am sincerely sorry you do not see the
> difference.  If there is any way I can help you understand the issues,
> please let me know.  Wait for the punchline.
> .
> .
> .
> .
> .
> .
> .
> .
> .
>
> You just need more experience with Object-Oriented Modelling.
> .
> .
>
>

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

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

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.
I always assumed that would be obvious to other MyHDL users but
I recognize this is an assumption that may have been too implicit.

Anyway, it explains why I'm not interested in discussions when MyHDL
is limited to that aspect: it is not my world. And there are further
reasons. The continuous identification of MyHDL "limitations" with
conversion or even synthesis limitations is tiresome. And it is
demotivating. I hardly hear any talk about the HDL limitations
that MyHDL actually lifted in comparision to $$$ synthesis, e.g.
by the way conversion works after elaboration, and how it does
integers.

-- 
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] Manual update: rtl versus high level

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

On 5/6/12 6:05 AM, Jan Decaluwe wrote:

Those are all great steps in the right direction.

> I have separated the chapters about modeling in the manual.
> I have also added an introduction making it clear that
> high-level modeling is very useful, but not intended for synthesis.
>
>      http://www.myhdl.org/doc/dev/index.html
>

To write synthesizable models in MyHDL

please make it,

If you want to build an ASIC, or FPGA, use...

python guys are not quite sure what synthesizable means.  Specifically f
you gave me a test, I would not be able to distinguish synthesizable
logic from non-synthesizable logic. 
>
>   And I have further refined the What MyHDL is Not page.
>
>     http://myhdl.org/doku.php/whatitisnot#myhdl_is_not_only_for_implementation
>
 
And here are my comments on that page.

MyHDL is not a classic object-model of a digital circuit

In MyHDL hardware modules are modeled by functions, not objects. Signals
are arguments to that function, not instance variables of a class.  
There is no class called HardwareModule
<http://wiki.myhdlclass.com:8080/AtomicHardwareModule>.  If there were,
it would look like this.  http://wiki.myhdlclass.com:8080/OOHDL   While
Verlilog talks about Hardware module hierarchies, MyHDL has no parent
instance variable, there is no children instance variables. Indeed there
is no class to put them into.  There is no rich library of hardware
modules that subclass off of these classes. You cannot iterate over the
tree of hardware modules to calculate something.  By default, there is
no such tree, unless you build it yourself.    While MyHDL is written in
python, I would call it a functional approach to modelling a digital
design.  It is designed for hardware engineers, not experienced python
developers. 

It would be beyond awesome if you would add that to your wiki.  In the
meantime people can find a copy at:
http://wiki.myhdlclass.com:8080/WhatMyHDLisNot

Forgive me for being so direct.  I sincerely hope the feedback is helpful.

Thank you for listening, I am getting better at finding my voice.

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

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

On 5/6/12 12:35 AM, Tom Dillon wrote:
> MyHDL works fine. I fail to see a conflict at all. 

There is a huge difference between representing signals are arguments to
a function, and as instance variables on an object.   The later supports
inheritance, and quickly leads to rich libraries of Atomic and Compound
Hardware Module libraries.  I am sincerely sorry you do not see the
difference.  If there is any way I can help you understand the issues,
please let me know.  Wait for the punchline.
.
.
.
.
.
.
.
.
.

You just need more experience with Object-Oriented Modelling.
.
.


-- 
Regards
Christopher Lozinski

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

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

[myhdl-list] Manual update: rtl versus high level

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

I have separated the chapters about modeling in the manual.
I have also added an introduction making it clear that
high-level modeling is very useful, but not intended for synthesis.

     http://www.myhdl.org/doc/dev/index.html

And I have further refined the What MyHDL is Not page.

    http://myhdl.org/doku.php/whatitisnot#myhdl_is_not_only_for_implementation

This should remove all confusions about the subject.
If any pop up in the future I hope to be able to respond with
a reference instead of endlessly repeating and rephrasing myself.

-- 
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 C. <jan...@mu...>]

On 06/05/12 06:35, Tom Dillon wrote:

> "Experienced python developer", what is that? I am not sure what
> that has to do with anything.
True. An "Experienced python developer" is most likely someone who 
has gained some control over a machine at a very high level of 
abstraction. They may know little or nothing about the 
progressively differing layers of software beneath, supporting 
their code.  Likely, the further layers of hardware concepts 
expressed below are completely out of sight.

> There is nothing unnatural about MyHDL. Again, trying to draw
> somebody into a meaningless discussion.
I think he's angling to get a fish, a big one.  A person wanting to 
learn to fish would need to be interested in understanding and 
clearly distinguishing the names of the tools, behaviour of fish, 
affects of tides, etc.  Asking why angling is not an iPhone app 
that can be run, sat on a bench in the park while watching bowls is 
pointless.

> MyHDL works fine. I fail to see a conflict at all.
I'm struggling, but much too inexperienced with Python to suggest 
changing any of MyHDL.

My hardware experience started with borrowing my mums breadboard 
and dressmaking pins, and using surplus germanium diodes and 
transistors.  I still like to know the details of the fabric I'm 
using.

Today I still have questions, for example: Do clockless gate arrays 
use standard SRAM blocks in an async wrapper, or are they async to 
a much lower level than this.  It may seem pointless to ask, but it 
would help me to estimate the reliability of tools which translate 
RTL designs to use a clockless fabric. [1]

But this extremely low-level interest might hinder my progress in 
using MyHDL in a similar way to having an insufficiently deep 
understanding of electronics.  I'll need to work to get the balance 
right.

It has been a hard struggle for me to get started with MyHDL, 
hopefully we can work out why, and make it easier for others in the 
future.

Jan Coombs
-- 
[1] www.achronix.com

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

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

On 05/05/2012 02:59 PM, Christopher Lozinski wrote:
> In the page on Atomic and Compound Hardware modules, I model ports as
> public instance variables.  And internal signals as private instance
> variables.    It is how experienced python developers expect to see
> things.  It is natural for us to think of ports as instance variables.
> Then you can get inheritance of ports for  free as Hardware Modules are
> subclassed.  The port methods automatically remove Children and Parents
> from the instance variable list.  With this design, one would not have
> to list all the ports repeatedly in the generator function for each
> subclass.  They just get inherited.  Brings us a step closer towards
> rich libraries of hardware modules that can be subclassed.  Cool!
"Experienced python developer", what is that? I am not sure what that 
has to do with anything.

There is nothing unnatural about MyHDL. Again, trying to draw somebody 
into a meaningless discussion.
>
> But there is a problem, as that is not how MyHDL models ports.  It is
> not just an implementation problem.  It is a conflict between how
> experienced Python developers see the world, and the functional approach
> favored by experienced hardware engineers.

MyHDL works fine. I fail to see a conflict at all.

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

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

Jan Decaluwe wrote:

    Coupling a sensitivity list to a module makes no sense.

Understood.  Here is the source of my confusion.

The manual says:

    Hardware descriptions need to support the concepts of module
    instantiation and hierarchy. In MyHDL, an instance (of a hardware
    module) is recursively defined as being either a sequence of
    instances, or a generator.

There are really two concepts here.   One is a high level module which
is recursively represented by a sequence of submodules.  And the other
is a leaf module which is represented by a generator.  Ports can be
associated with both high and low level modules   The logic,  generator 
and sensitivity lists are only associated with the leaf module.  Or we
could call them atomic and compound hardware modules.

Did I get that correct?   If so, thanks Jan for clearing that up for me. 

Accordingly I have updated split the Hardware Module class definition in
two here:

wiki.myhdlclass.com:8080/OOHDL

But that still does not solve all my problems for these classes. Back to
the Manual.

    The clock driver function ClkDriver() has a clock signal as its
    parameter. This is how a /port/ is modeled in MyHDL.


In the page on Atomic and Compound Hardware modules, I model ports as
public instance variables.  And internal signals as private instance
variables.    It is how experienced python developers expect to see
things.  It is natural for us to think of ports as instance variables. 
Then you can get inheritance of ports for  free as Hardware Modules are
subclassed.  The port methods automatically remove Children and Parents
from the instance variable list.  With this design, one would not have
to list all the ports repeatedly in the generator function for each
subclass.  They just get inherited.  Brings us a step closer towards
rich libraries of hardware modules that can be subclassed.  Cool! 

But there is a problem, as that is not how MyHDL models ports.  It is
not just an implementation problem.  It is a conflict between how
experienced Python developers see the world, and the functional approach
favored by experienced hardware engineers. 

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

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

At the time it took me a while to wrap my mind around the Queue example,
since it introduces a different aspect of using MyHDL, which is more of a
system architecture tool.

IMO this merits a separate chapter, since one can drop the RTL/Synthesis
requirements in favour of a different style of programming. I'd be happy to
prepare some concrete examples for further discussion.

On 2 May 2012 23:58, Christopher Felton <chr...@gm...> 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?
>
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> 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] How to make MyHDL Object-Oriented

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

Jan Decaluwe wrote:

    Coupling a sensitivity list to a module makes no sense.

Understood.  Here is the source of my confusion.

The manual says:

    Hardware descriptions need to support the concepts of module
    instantiation and hierarchy. In MyHDL, an instance (of a hardware
    module) is recursively defined as being either a sequence of
    instances, or a generator.

There are really two concepts here.   One is a high level module which
is recursively represented by a sequence of submodules.  And the other
is a leaf module which is represented by a generator.  Ports can be
associated with both high and low level modules   The logic,  generator 
and sensitivity lists are only associated with the leaf module.  Or we
could call them atomic and compound hardware modules.

Did I get that correct?   If so, thanks Jan for clearing that up for me. 

Accordingly I have updated split the Hardware Module class definition in
two here:

wiki.myhdlclass.com:8080/OOHDL

But that still does not solve all my problems for these classes. Back to
the Manual.

    The clock driver function ClkDriver() has a clock signal as its
    parameter. This is how a /port/ is modeled in MyHDL.


In the page on Atomic and Compound Hardware modules, I model ports as
public instance variables.  And internal signals as private instance
variables.    It is how experienced python developers expect to see
things.  It is natural for us to think of ports as instance variables. 
Then you can get inheritance of ports for  free as Hardware Modules are
subclassed.  The port methods automatically remove Children and Parents
from the instance variable list.  With this design, one would not have
to list all the ports repeatedly in the generator function for each
subclass.  They just get inherited.  Brings us a step closer towards
rich libraries of hardware modules that can be subclassed.  Cool! 

But there is a problem, as that is not how MyHDL models ports.  It is
not just an implementation problem.  It is a conflict between how
experienced Python developers see the world, and the functional approach
favored by experienced hardware engineers. 

-- 
Regards
Christopher Lozinski

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

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

Re: [myhdl-list] Restrictions for conversion

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

Am 05.05.2012, 12:41 Uhr, schrieb Christopher Felton  
<chr...@gm...>:

> On 5/5/12 4:00 AM, Norbo wrote:
>> Am 05.05.2012, 06:49 Uhr, schrieb Christopher Felton
>> <chr...@gm...>:
>>
>>> On 5/1/12 1:00 PM, Norbo wrote:
>>>>> 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.
>>>
>>> Why do you need "None"?  It would be my understanding that the
>>> conversion process will always create the init values in the converted
>>> code.  You don't need the _doinit flag and you don't need None.
>>
>> My thought on this was that it may be usefull to have explicit controll  
>> on
>> whether the initial values are written ot not. For example if a big ram  
>> is
>> described
>> and you don't need the initial values, the converted file would be  
>> filled
>> up with a
>> huge number of basically useless values. ->  Or in the words of "import
>> this" in python:
>> Explicit is better than implicit
>>
>
> To me this is *not* explicit, you don't have direct control over _doinit
> you have implicit control if the initial values are generated or not
> (which I have even forgotten what the control is).
The idea of the controll was if you write:
     aList=[Signal(intbv(None)) for i in range(10) ]  --> then the initial  
values are not written no matter what.
     aList=[Signal(intbv(i)) for i in range(10) ]  --> the initial values  
are written in verilog and vhdl when there is
							no combinatorical assignment ("as a path of least resistance right  
now")




> I hear the argument for the large inclusive of init values.  And with
> FPGA embedded memories and ASIC available ROM/RAM growing these could be
> long init lists.  But I am not totally convinced the inconvenience of
> long inits are bad because it breaks the earlier argument "MyHDL to
> Verilog/VHDL mismatch".

I didn't get that.




> This might be the path of least resistance right now.  But I don't think
> there is a reason that the converted couldn't generate
>
>       reg [7:0] out1 = 8'd0;
>       reg [7:0] aListSig [0:10-1];
>       // initial blocks ...
>       @always_comb begin

nice: @always_comb begin a myhdl artefact ;)

>           aListSig[3] = in_data
>           out1 = aListSig[3]
>       end
>
> This is only an issue in Verilog and not VHDL.  Maybe a behavioral
> statement should be written instead of a continuous assignment.  To me
> it appears a lot of complexity would be added which could be avoided by
> simply converting the Verilog similar to how the VHDL is converted.

Damm, i overlooked that. The synthesis of the follwing is succesfully.

   ....
   reg [7:0] aListSig [0:10-1];

   initial
   begin : INIT_aListSig
   aListSig[0]=0;
   aListSig[1]=1;
   aListSig[2]=2;
   aListSig[3]=3;
   aListSig[4]=4;
   aListSig[5]=5;
   aListSig[6]=6;
   aListSig[7]=7;
   aListSig[8]=8;
   aListSig[9]=9;
   end

   always @(in_data,aListSig[3]) begin // or   always @* begin
       aListSig[3] = in_data;
       out1 = aListSig[3];
   end

summary:
this means the "assign" in the verilog conversion needs to be replaced (by  
always @* begin ... end) and
also if it gets declared as "wire" would need to be defined as "reg".


another point is that i think it is a good thing to have all the variables  
by default not to be initialized
with values in the converted code. Initialisation should only occour if  
you really want to describe (pre-init RAM)
or ROM.
because for example in VHDL all the std_logic signals are set at startup  
of a vhdl simulation to the value 'U' (stands for uninitialized) if there  
is no other initial value given. After the reset all values should have  
changed from this
'U' to something usefull. This allows you to see imidiatly if you have  
messed up or missed something in the reset code.
If all values are set by default to something usefull you can easyl  
overlook some resets, you couldnt even check it
with a testbench at startup if the reset is done properly, when the  
initial value has the same value as the reset value you have forgotten in  
the code.

The point is, by default no initial value should be written in the  
converted code, only when you need it explicit to describe something.
Maybe a default None value in the intbv?

grettings
Norbo

Re: [myhdl-list] Restrictions for conversion

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

On 5/5/12 4:00 AM, Norbo wrote:
> Am 05.05.2012, 06:49 Uhr, schrieb Christopher Felton
> <chr...@gm...>:
>
>> On 5/1/12 1:00 PM, Norbo wrote:
>>>> 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.
>>
>> Why do you need "None"?  It would be my understanding that the
>> conversion process will always create the init values in the converted
>> code.  You don't need the _doinit flag and you don't need None.
>
> My thought on this was that it may be usefull to have explicit controll on
> whether the initial values are written ot not. For example if a big ram is
> described
> and you don't need the initial values, the converted file would be filled
> up with a
> huge number of basically useless values. ->  Or in the words of "import
> this" in python:
> Explicit is better than implicit
>

To me this is *not* explicit, you don't have direct control over _doinit 
you have implicit control if the initial values are generated or not 
(which I have even forgotten what the control is).  There are a set of 
rules that decide for you if initial values are to be generated or not. 
  I would think explicit would be the use of None, you are directly 
indicating no init values.

I hear the argument for the large inclusive of init values.  And with 
FPGA embedded memories and ASIC available ROM/RAM growing these could be 
long init lists.  But I am not totally convinced the inconvenience of 
long inits are bad because it breaks the earlier argument "MyHDL to 
Verilog/VHDL mismatch".

I think the question; "Is the absence of initial values detrimental 
because it causes a co-simulation mismatch"?  If it decided this is a 
bad thing then I think we need to live with the long init list or 
support the None initial values on the MyHDL side.

>
>>>> 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?
>>
>> Lost me.  I don't understand why it matters how the Signal variable is
>> used to determine if the initial value should be written.  As mentioned,
>> shouldn't the initial values always be written?
>
> For example for the case 5. "reading and writing in a combinatorical
> process"
>
>     assign aListSig[3] = in_data;
>     assign out1 = aListSig[3];
>
>     endmodule
>

This might be the path of least resistance right now.  But I don't think 
there is a reason that the converted couldn't generate

      reg [7:0] out1 = 8'd0;
      reg [7:0] aListSig [0:10-1];
      // initial blocks ...
      @always_comb begin
          aListSig[3] = in_data
          out1 = aListSig[3]
      end

This is only an issue in Verilog and not VHDL.  Maybe a behavioral 
statement should be written instead of a continuous assignment.  To me 
it appears a lot of complexity would be added which could be avoided by 
simply converting the Verilog similar to how the VHDL is converted.

Regards,
Chris

Re: [myhdl-list] Restrictions for conversion

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

Am 05.05.2012, 06:49 Uhr, schrieb Christopher Felton  
<chr...@gm...>:

> On 5/1/12 1:00 PM, Norbo wrote:
>>> 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.
>
> Why do you need "None"?  It would be my understanding that the
> conversion process will always create the init values in the converted
> code.  You don't need the _doinit flag and you don't need None.

My thought on this was that it may be usefull to have explicit controll on
whether the initial values are written ot not. For example if a big ram is  
described
and you don't need the initial values, the converted file would be filled  
up with a
huge number of basically useless values. -> Or in the words of "import  
this" in python:
Explicit is better than implicit


>>> 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?
>
> Lost me.  I don't understand why it matters how the Signal variable is
> used to determine if the initial value should be written.  As mentioned,
> shouldn't the initial values always be written?

For example for the case 5. "reading and writing in a combinatorical  
process"
a example in for verilog could look like this:

   Myhdl code:
   ------------------------------------------------------
   def TOP(out1,in_data):
       aListSig=[Signal(intbv(i)[8:]) for i in range(10)]

       @always_comb
       def comb_logic():
	  out1.next=aListSig[3]

       @always_comb
       def comb2_logic():
	  aListSig[3].next=in_data
	
       return comb2_logic ,comb_log


   Verilog code:
   ---------------------------------------------------
   module TOP (
       out1,
       in_data
   );
   output [7:0] out1;
   wire [7:0] out1;
   input [7:0] in_data;
   wire [7:0] aListSig [0:10-1];

   //hypothetical inital block would be placed here
   //but if a initial block is placed here
   //the code is no longer valid because "aListSig" is defined as wire.
   //but it needs to be defined as wire because somewhere in the code  
someone
   //writes to the variable "aListSig" in combinatorically assignment.
   //therfore the initial signal cant be written in the case when a  
combinatoricall
   //assignment to the variable "aListSig" takes place somewhere in the  
code.
   //Anyway a initialvalue is not needed when a combinatorical assignment  
to the variable "aListSig" is made,
   //because the "aListSig" then gets its value imidiatley at the beginning  
of the simulation by this
   //assignment.(or after some delta cycles with zero delay).
   //In verilog the complete signal array is defined as wire, so if only  
the variable
   //with index 3 is (as below aListSig[3]) used combinatorically then the  
complete array
   //needs to be defined as "wire" and therfore no initialvalues are  
possible

   assign aListSig[3] = in_data;
   assign out1 = aListSig[3];

   endmodule




greetings
Norbo

 

Re: [myhdl-list] Restrictions for conversion

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

On 5/1/12 1:00 PM, Norbo wrote:
>> 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.

Why do you need "None"?  It would be my understanding that the 
conversion process will always create the init values in the converted 
code.  You don't need the _doinit flag and you don't need None.

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

Lost me.  I don't understand why it matters how the Signal variable is 
used to determine if the initial value should be written.  As mentioned, 
shouldn't the initial values always be written?
Note: these are only simulation and or "special" synthesis mapping 
initial values.  Reset values are still reset values.

The only thing that needs to be determined is if the initial block needs 
to be added.  That should simply be based on list of signals or not.

Regards,
Chris

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

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

On 5/4/12 8:34 AM, Tom Dillon wrote:
> It seems to me we are just being drawn into ridiculous conversations.
>
> I am more productive with MyHDL/Python and Verilog/VHDL that with only
> straight Verilog/VHDL, so I use it.
>
> Particularly for test benches and re-usable IP modules. I would suggest
> to anyone who wants to learn the benefits of MyHDL, that begin with test
> benches. It is a great way to increase your test coverage and do it in
> far less time than with an HDL test bench.
>
> After some experience is gained using MyHDL, your comments about what
> can and can't be done with it might be more useful to the list.
>
> Right now debating whether or not you can use classes is absurd.
>
>

+1 Tom has many good point here!

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

[garyr <ga...@fi...>]

----- Original Message ----- 
From: "Tom Dillon" <td...@di...>
To: <myh...@li...>
Sent: Friday, May 04, 2012 7:40 AM
Subject: Re: [myhdl-list] How to make MyHDL Object-Oriented


> Hardly an attack.
> 
> I fail to see the issue to be hard on.

Amen to that. Crackpots shouldn't expect sympathy.

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] How to make MyHDL Object-Oriented

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

On 05/04/2012 02:18 PM, Christopher Lozinski wrote:
> On 5/4/12 5:04 AM, Jan Decaluwe wrote:
>> On 05/04/2012 01:45 AM, Christopher Lozinski wrote:
>>> Thanks enormously to Andy Stone for pointing out that MyHDL,
>>> while in Python is not object-oriented.  There is no hardware
>>> module class, just a generator, and decorator which are
>>> functional approaches.
>> How can you even say this,
>
> Actually the wiki says it.
>
> http://www.myhdl.org/doc/0.6/manual/intro.html In MyHDL, classic
> functions are used to model hardware modules. In particular, the
> parameter list is used to define the interface.

Point taken. However, I am not sure how to change that for full
generality in an introductory chapter, without being overly confusing
to new users.

However: it is true that I think that the approach based on functions
is the best choice for a first step. It is correct that I wanted to make
things as simple as possible for hardware designers, especially Verilog
designers, with no exposure to object-orientation in their HDLs.
It is also true that conversion was written with this choice in mind
in the first place.

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

You can do that today.

> Here is another one.
> http://www.myhdl.org/doc/current/manual/modeling.html
>
> In MyHDL, an instance is recursively defined as being either a
> sequence of instances, or a generator. Hierarchy is modeled by
> defining instances in a higher-level function, and returning them.
>
> That does sound to me like a functional approach. I would rather see
> hardware modules defined "in a higher level object" a module with
> parent and child nodes. I would expect a hierarchy of chip modules,
> each of which points to its children and parents.
>
> Then let me quote others: Andrew Stone said this is what he
> expected:
>
> In fact, what I thought myHDL was going to let me do is create
> classes that define blocks of logic at the RTL level (synthesizable),
> perhaps with inputs and output "Signals" as variables passed in the
> constructor and then by instantiating those classes I'd be in effect
> plunking down copies of that logic in the FPGA (or within larger
> logic blocks by instantiating these within the constructor of another
> class). 4 years ago I did not ever figure out how to do this... I
> don't think anything wrapped in a class was synthesizable back then.
> But maybe that has changed now; I haven't tried using classes since.
>
> And yes, Dillon wrote that he does this, but I think we will find the
> details of how he does it are different than at least what I would
> expect. In particular MyHDL does not pass variables into the object
> constructor, it passes them into the generator. There are no parent
> or child links.
>
>
>> when the manual has a section about object-oriented modeling, which
>> has a Queue class, which you have just been struggling with?
>
> If I recall correctly, the Queue class is not inside a @always,
> @instance, or @always_comb, so it is not synthesizable. While MyHDL
> is quite general, it is only the synthesizable stuff I am interested
> in.

Then you should clearly say so in your communication. Otherwise your
statements are totally confusing to people, including myself, who
are equally interested, or even more so, in other aspects of MyHDL.

> Jan Decaluwe wrote:
>
>> Perhaps this stuff really is too hard for the "general python
>> developer", though I
>
>> still don't understand why.
>
> Because it does not fit the way we see the world. Different people
> have different world views. I am doing my best to explain my world
> view. In particular one of my concepts is that every real world thing
> should be represented by a class. So flip flops, adders, multipliers
> should each be represented by a class. And then I mostly want the
> documentation to be a listing of the classes, representing physical
> objects, available to me to work with. And yes the existing MyHDL
> documentation would also be useful.

But that is a low-level view that I'm not interested in at all!
I don't care about models for flip-flops, adders, multipliers etc -
I have synthesis tools that infer them efficiently and by the dozen
from the behavior of my code, without requiring my attention.
(Of course, I know about them very well, to judge the quality
of the synthesis result in the back end).

But if you insist - you can do that today, and then work at
the net list level in MyHDL connecting them. Just add some print method
to each class that prints out the instance representation in some
technology in Verilog and you are done - you have a netlist
generator. No conversion needed, and no synthesis for that matter.

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

And I don't buy that. More important than the software
technique is the abstraction level at which
you are working. Your object-oriented approach is just a low-level
approach in disguise - not interested.

You don't get MyHDL because you don't yet get the basics of
HDL-based design. Unfortunately, I don't see an alternative
of getting your hands dirty and building up experience
yourself, painstakingly.

Trying out Verilog, as you announced, may actually be a wise
step. If you are happy with it, all the better. But if you
are not, I trust the discussion will become much easier.

Look at it this way. Synopsys has become very rich by selling
great synthesis tools. But after all these years, I am still
not aware of a reference work that I can recommend to really
learn what synthesis can do.

Don't expect some poor open-source guys to fill in that gap.

>
> -- Regards Christopher Lozinski
>
> Check out my iPhone apps TextFaster and EmailFaster
> http://textfaster.com
>
> Expect a paradigm shift. http://MyHDL.org
>
>
>
> ------------------------------------------------------------------------------
>
>
Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.
> Discussions will include endpoint security, mobile security and the
> latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________ myhdl-list mailing
> list myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list


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

Re: [myhdl-list] 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