myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] MEP - keep hierarchy in conversion

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

Hi

Sorry to keep you waiting :) . This is my MEP draft, I'll wait for your
comments before pushing to wiki

----

Introduction

MyHDL structural descriptions support an arbitrary complex hierarchy
for code conversion. As described in the FAQ, hierarchy is flattened
because conversion is based on an elaborated design.

However, there are some situations which is desirable to have an
equivalent structural description in the generated code. Usually, this
structural description consists of a top module that instantiates
several components previously defined.

One particular use case is floorplanning in FPGA, in which each
component in a structural description is allocated to fixed resources. 

As thoroughly discussed in the mail list, hierarchy conversion could
be useful in cases which a structural description is needed for
synthesis and post-synthesis processes.

Analysis

Structural descriptions in MyHDL are based on functions that returns a
list of generators. Those functions can be mapped to component
definitions, and function calls to component instantiations.

Looking at the returned value from a structural description,
information about hierarchy is keep as a list-of-lists of generators,
and flattened later for simulation and conversion.

Proposed solution

Hierarchical conversion can be supported by recursive calling to
converter function for each function present in the top-level
description. 

Attribute "maxdepth": controls the maximum depth which the
converter is recursively called.

 * 0: don't do recursive calling. This is equivalent to default
   conversion (hierarchy flattening).

 * 1:make only one recursive call. That means keep hierarchy only from
   top module. Components are converted as default hierarchy flattening
   conversion 

 * > 1: make recursive calls as deep as maxdepth value. 

 * None: Unlimited recursion depth. That means the converter will try to
   use component instantiation as possible.

File generation

Given that the converter is called recursively several times, multiple
files are generated and its contents are used for component
declaration (VHDL). Recursive calls must avoid file replication (for
VHDL case means avoid multiple package file generation). This is done
by keeping generated code in memory before pushing to files. 

Attribute "no_component_files" : 
 * False : all components code is saved to disk as soon as possible.
 * True : discard components code, only save top-module file.

Limitations

* Component conversion

All instantiated components must be top-module convertible. That means
its ports should be well-defined (for instance, don't read output only
ports), otherwise component declaration could use incorrect or
unexpected attributes (port direction, bit widths, etc.)

* Component parameters

Since converter doesn't support parameters at top-module level,
conversion has to "hard-code" them into several component declarations.
Each time converter detect different parameters (and also different bit
widths in signals), it generates a numbered component declaration for
each different parameter value.

-----

I also want to put a related issue to discuss: I need to keep generated
files in memory for this to work, but also I used this feature to write
files later for my design flow. Did anyone find itself in need to keep
the generated files in memory? If that's the case, I propose another
attribute to keep file contents in memory (by the way, I'm using
StringIO objects in a dict with filenames as keys). 

Best regards,

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

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

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

Re: [myhdl-list] Design West

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

If anyone is interested here are a couple photos
from the presentation(s):

https://twitter.com/FeltonChris/status/327069326962204672/photo/1
https://twitter.com/pdp7/status/327193753787969536/photo/1
https://twitter.com/GregHarrisonEE/status/327101322023284736/photo/1

I added a link to the white-paper and presentation
here:

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

The complete source for the examples in the white-paper
and presentation are available here:

https://bitbucket.org/cfelton/dw2013_examples

Some of the examples are variations of the previous
examples I have used in the past:

https://bitbucket.org/cfelton/examples

Regards,
Chris Felton

Re: [myhdl-list] timescale in _toVerilog and cosimulation

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

On 4/26/2013 3:05 PM, Jos Huisken wrote:
> Christopher Felton <chris.felton <at> gmail.com> writes:
>
>>
>> On 4/26/2013 2:03 PM, Jos Huisken wrote:
>>> In a cosimulation (with icarus in this case) you can generate 2 .vcd
> files,
>>> one from myhdl and one from icarus (using $dumpfile).
>>> When viewing both using gtkwave the clock period is x10 different.
>>> I think this is caused by the `timescale 1ns/10ps directive in generated
>>> verilog. At least when replacing it by 1ns/1ps solves the issue.
>>>
>>> Is this the way to do it?
>>>
>>> -- Jos
>>>
>>
>> Hmm, Icarus should use what is defined by the timescale
>> for the VCD creation?  There is a mismatch with the timescale
>> for the Verilog simulator and the timescale used in the
>> MyHDL VCD creation.
>>
>> You can use the following to control the timescales in
>> MyHDL.
>>
>>       traceSignals.timescale = '1ps'
>>       tb_dut = traceSignals(...)
>>       ...
>>       toVerilog.timescale = '1ns/1ps'
>>       toVerilog(...)
>>
>> In addition there should be away to tell the Verilog
>> simulator what the time resolution is.  If you can't
>> control the time resolution with the above you might
>> want to look at adding it to the simulation command
>> (i don't recall what it is off the top of my head).
>>
>> Regards,
>> Chris Felton
>>
>> --------------------------------------------------------------------------
>
> toVerilog.timescale = '1ns/1ps' does the job indeed.
> Then icarus writes .vcd with time values in 'ps' and timescale 1ps.
> (default it was in 1ps units with timescale 10ps).
>
> When using traceSignals.timescale = '1ps' the time values in the myhdl
> generated vcd do not change (they remain the same as used in writing your
> myhdl code). That's OK since myhdl does not assume any absolute time.

Correct, myhdl simulation does not assume absolute time
But if you want your time-units correct on the waveform
viewer the timescale in the VCD needs to be what you want,
example:

     $timescale
         1ps
     $end

The /traceSignals.timescale/ will modify this little bit
in the VCD file.  This is only useful if you want the scale
on the viewer to be the same if you had assumptions about
the simulation time-step units (or as you indicate, comparing).

If you are using arbitrary time this does not matter.

>
> I am assuming 1ns units in myhdl by writing 'delay(1)', and myhdl generates
> .vcd with timescale 1ns by default.

Yes, if /traceSignals.timescale = '1ns'/ then a /yield
delay(1)/ would generate a 1ns delay in the VCD file.

>
>
> The reason for this discussion is that I "compare" .vcd files to crosscheck
> simulation results.
>
> -- Jos

I agree, it is useful keeping track of the units programmatically
in Python is useful.  Especially if you need to present the
data/waveforms to someone not as familiar with digital simulation
(e.g. analog eng.) they will have a difficult time if it is not is
absolute time.

Regards,
Chris

Re: [myhdl-list] timescale in _toVerilog and cosimulation

[Jos H. <jos...@gm...>]

Christopher Felton <chris.felton <at> gmail.com> writes:

> 
> On 4/26/2013 2:03 PM, Jos Huisken wrote:
> > In a cosimulation (with icarus in this case) you can generate 2 .vcd 
files,
> > one from myhdl and one from icarus (using $dumpfile).
> > When viewing both using gtkwave the clock period is x10 different.
> > I think this is caused by the `timescale 1ns/10ps directive in generated
> > verilog. At least when replacing it by 1ns/1ps solves the issue.
> >
> > Is this the way to do it?
> >
> > -- Jos
> >
> 
> Hmm, Icarus should use what is defined by the timescale
> for the VCD creation?  There is a mismatch with the timescale
> for the Verilog simulator and the timescale used in the
> MyHDL VCD creation.
> 
> You can use the following to control the timescales in
> MyHDL.
> 
>      traceSignals.timescale = '1ps'
>      tb_dut = traceSignals(...)
>      ...
>      toVerilog.timescale = '1ns/1ps'
>      toVerilog(...)
> 
> In addition there should be away to tell the Verilog
> simulator what the time resolution is.  If you can't
> control the time resolution with the above you might
> want to look at adding it to the simulation command
> (i don't recall what it is off the top of my head).
> 
> Regards,
> Chris Felton
> 
> --------------------------------------------------------------------------

toVerilog.timescale = '1ns/1ps' does the job indeed.
Then icarus writes .vcd with time values in 'ps' and timescale 1ps.
(default it was in 1ps units with timescale 10ps).

When using traceSignals.timescale = '1ps' the time values in the myhdl 
generated vcd do not change (they remain the same as used in writing your 
myhdl code). That's OK since myhdl does not assume any absolute time.

I am assuming 1ns units in myhdl by writing 'delay(1)', and myhdl generates 
.vcd with timescale 1ns by default.


The reason for this discussion is that I "compare" .vcd files to crosscheck 
simulation results.

-- Jos

Re: [myhdl-list] timescale in _toVerilog and cosimulation

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

On 4/26/2013 2:03 PM, Jos Huisken wrote:
> In a cosimulation (with icarus in this case) you can generate 2 .vcd files,
> one from myhdl and one from icarus (using $dumpfile).
> When viewing both using gtkwave the clock period is x10 different.
> I think this is caused by the `timescale 1ns/10ps directive in generated
> verilog. At least when replacing it by 1ns/1ps solves the issue.
>
> Is this the way to do it?
>
> -- Jos
>

Hmm, Icarus should use what is defined by the timescale
for the VCD creation?  There is a mismatch with the timescale
for the Verilog simulator and the timescale used in the
MyHDL VCD creation.

You can use the following to control the timescales in
MyHDL.

     traceSignals.timescale = '1ps'
     tb_dut = traceSignals(...)
     ...
     toVerilog.timescale = '1ns/1ps'
     toVerilog(...)

In addition there should be away to tell the Verilog
simulator what the time resolution is.  If you can't
control the time resolution with the above you might
want to look at adding it to the simulation command
(i don't recall what it is off the top of my head).

Regards,
Chris Felton

[myhdl-list] timescale in _toVerilog and cosimulation

[Jos H. <jos...@gm...>]

In a cosimulation (with icarus in this case) you can generate 2 .vcd files, 
one from myhdl and one from icarus (using $dumpfile).
When viewing both using gtkwave the clock period is x10 different.
I think this is caused by the `timescale 1ns/10ps directive in generated 
verilog. At least when replacing it by 1ns/1ps solves the issue.

Is this the way to do it?

-- Jos

Re: [myhdl-list] Keep hierarchy in VHDL conversion

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

El Sun, 14 Apr 2013 17:25:45 +0200
Angel Ezquerra <ang...@gm...> escribió:

> This is something I have wanted pretty much since I discovered MyHDL.
> I hope you can make all the tests pass soon and that you can implement
> the Verilog side as well. I also hope Jan can have a look and
> hopefully integrate it into the official MyHDL code base.

Well, my initial plan is to use it as a external module, and when it's
sufficiently stable (and proven useful to users), then merge with
default converters.

So I'm pursuing two approaches: the external module and patched
converters.

By the way, I know this should be in a MEP, I'll write it this week.

> 
> I went though the github readme file briefly, and it was not super
> clear to me how you select the output file names and who you create
> the corresponding entities. It would be nice if you had some example
> so that it was easier to understand how the whole thing works.

I uploaded a couple regression tests, but I think they can be used for
demonstration, also I attach another example (extracted from one of
the tests): convert_kh.py .

To answer your question: entity names are based on function names, and
each function call will generate an instance statement. However, it
checks argument values for each function call to decide how many
components to generate. That means any constants (analogous to generics
in VHDL) and bit-widths are hard-coded in components, but if you
instantiate many components with the same constants and bit-widths it
only generate one component.

>

Regarding existing regression tests, there's some tests that I cannot
pass due to VHDL errors (two of them fails with current snapshot):

1. some tests fails due to VHDL case-insensitive identifiers. What
should the correct procedure in this case? Either notify the user about
identifier conflicts, or change generated names to avoid them?

2. User-defined code cannot infer "inout" signals, and those tests
fails when attempt to read "out" signals. Here I don't know how to do
that without parsing user-defined code.

I also attach a summary with the problems I found
(regression_tests_summary.py) and test reports for the failed tests in
current snapshot.

> 
> Cheers,
> 
> Angel
> 

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

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

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

Re: [myhdl-list] two issues about conversion

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

On 4/19/13 1:00 AM, Christopher Felton wrote:
> On 4/15/13 1:20 PM, David Guerrero Martos wrote:
>> Hello, my name is David and I'm new to MyHDL. I'm starting to learn
>> MyHDL and I've installed 0.8-dev. As an exercise, I'm trying to describe
>> and test an LFSR that is  attached as LFSR9.py. I got no errors when
>> executing it, but I cannot synthesize it because the code is not
>> properly converted to Verilog: If you have a look to the attached LFSR.v
>> you will see that the input to the xor gate is formed by references to
>> the name of the external variable passed as parameter (my_state) instead
>> of the formal name of the parameter in the prototype of the function
>> (state).
>>
>
> This one is a little tricky, I don't know the root
> cause or if it is an issue but I have duplicated the
> scenario  you have observed.  It will be some time before
> I can dig into this and see what the issue might be?
>
> I can offer a separate solution (see below/attached).
>
> Regards,
> Chris
>

from myhdl import *

def m_lfsr(clock,reset,prn,taps,N=3,initval=None):
     """ Simple Galois (one-to-many) LFSR

     Characteristic Polynomial Mapping
     ---------------------------------
     To define the LFSR sequence a "characteristic" polynomial
     is required.  This modules expects the polynomial described
     by the "taps" list.  The taps list is the delay elements
     that feed an XOR in a Galois LFSR configuration.

     The "taps" list is expanded into a bit position in the same
     word size as the lfs-register, then a loop can be used to
     insert the xors on the correct taps.
     """

     initval = (2**N)-1 if intval is None else initval
     # convert from compact form to expanded
     itaps = [Signal(bool(1)) if ii in taps else Signal(bool(0))
              for ii in range(N)]
     taps = Signal(concat(*itaps))
     lfsr = Signal(intbv(initval)[N:])

     @always_seq(clock.posedge, reset=reset)
     def hdl_lfsr():
         lfsr.next[0] = lfsr[N-1]
         for ii in range(1,N):
             if taps[ii-1]:
                 lfsr.next[ii] = lfsr[ii-1] ^ lfsr[N-1]
             else:
                 lfsr.next[ii] = lfsr[ii-1]

     if len(prn) == 1:
         @always_comb
         def hdl_out():
             prn.next = lfsr[N-1]
     else:
         @always_comb
         def hdl_out():
             prn.next = lfsr

     return hdl_lfsr,hdl_out


if __name__ == '__main__':
     clock = Signal(bool(0))
     reset = ResetSignal(0,active=0,async=False)
     prn = Signal(bool(0))
     taps = [0,2]
     toVerilog(m_lfsr,clock,reset,prn,taps=taps)

Re: [myhdl-list] two issues about conversion

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

On 4/15/13 1:20 PM, David Guerrero Martos wrote:
> Hello, my name is David and I'm new to MyHDL. I'm starting to learn
> MyHDL and I've installed 0.8-dev. As an exercise, I'm trying to describe
> and test an LFSR that is  attached as LFSR9.py. I got no errors when
> executing it, but I cannot synthesize it because the code is not
> properly converted to Verilog: If you have a look to the attached LFSR.v
> you will see that the input to the xor gate is formed by references to
> the name of the external variable passed as parameter (my_state) instead
> of the formal name of the parameter in the prototype of the function
> (state).
>

This one is a little tricky, I don't know the root
cause or if it is an issue but I have duplicated the
scenario  you have observed.  It will be some time before
I can dig into this and see what the issue might be?

I can offer a separate solution (see below/attached).

Regards,
Chris

Re: [myhdl-list] Keep hierarchy in VHDL conversion

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

All - thanks for the feedback.

I think a consensus is growing: stay with hg,
but move to bitbucket for development, because
it should improve the process: public forks
to demonstrate features, and pull requests
instead of patches and bundles.

I'm all for it - as a trial, I've imported
the main repo on bitbucket already and this
seems to work fine. (jandecaluwe/myhdl).

Jan


On 04/15/2013 02:48 AM, Christopher Felton wrote:
> On 4/14/13 2:28 PM, Jan Decaluwe wrote:
>> On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
>>
>>> Oscar,
>>>
>>> if you have never used mercurial and need some help drop me a line. I
>>> am very active in TortoiseHg development (and a bit on mercurial as
>>> well) so I think I could help bring you up to speed if you need it
>>
>> Interesting.
>>
>> Perhaps I should ask a more general question: should we
>> consider to move MyHDL development to github?
>>
>> This is not a technical question. Many Pythonistas probably
>> have a slight preference for Python-based mercurial.
>> Professionally, I use both and I am happy with either one.
>>
>> The point is that "everyone" seems to be at github. So
>> perhaps this is good for visibility.
>>
>> It may also be good for development. I like the way
>> Oscar presented his work: it shows commitment to
>> maintain the feature, and everyone can try/follow
>> it without requiring my assistance. Much better
>> than getting patches/bundles out of the blue that
>> I am supposed to review/check/integrate before others
>> can (easily) do so.
>>
>> Of course, for this to work, all development should
>> be on the same system.
>>
>> Jan
>>
>
> As Jan eluded, there are two features:
>
>      1) Improved work-flow:
>         a) pull requests (largest impact)
>         b) simplified interfaces (click buttons on webpages)
>         c) default public (mods not local on private machine)
>
>      2) Visibility (popular social thing)
>
> If we feel #2 holds a lot of weight then github is the answer. If
> visibility is important but not the most important then I would
> suggest we stay with hg and use bitbucket (like pypy, sphinx,
> cherrpy, ...).
>
> For me a move to git vs. hg would be disruptive.  Not because
> of some huge technical short-coming but because all my work has
> been with hg and bitbucket.  If we move to git and github my
> work flow and existing projects will not be compatible with the
> new work flow (i.e. git and github).
>
> Other than not being as popular I don't know of any technical
> limitations of bitbucket vs. github.
>
> It will be interesting to here back from Oscar, why he chose
> github over bitbucket being myhdl uses hg.
>
> My vote is to stay with hg and utilize bitbucket but I am not
> adamantly opposed to git and github.  I do think it is important
> that we start using bitbucket or github and pull requests.
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
>


-- 
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] Keep hierarchy in VHDL conversion

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

>> I have found some short coming with git and my work flow but I assume
>> that was me being less familiar with git than hg.
>
> I'm curious to know about your experience. Care to share?

I don't mind sharing but I do think I will embarrass
myself :)  I am sure, to a experienced git'er it is
basic or they would be appalled at my work flow.

I had created a MyHDL version for the fpgalink project[1]
but the module was embedded in another project I had on
bitbucket.  Since, fpgalink was on github I decided to
try and get a little more experience with git.  So I
created a project on github, cloned it to my pc and started
adding the files, commits, making modifications, etc.  Then
I had to travel or something and made a clone from my pc
to a laptop.  Made some changes, commits etc.

Now when I tried to push back to the pc it didn't work.
It said I could not push to a repo with modifications?  I
was confused.  I was unable to resolve the issue, I had to
do merge things manually.

I think the solution I would have been told would be to
push to github and then sync the pc with github.  But this
is not what I wanted to achieve.

Regards,
Chris

[1] https://groups.google.com/forum/#!topic/fpgalink-users/Oxh2Hu08J8A

Note the above post is outdated, I moved the code from the
original repo in the post to a github repo (or I tried,
still haven't gotten it pushed back).

Re: [myhdl-list] Keep hierarchy in VHDL conversion

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

> El Sun, 14 Apr 2013 19:48:15 -0500
> Christopher Felton <chr...@gm...> escribió:
>
>> My vote is to stay with hg and utilize bitbucket but I am not
>> adamantly opposed to git and github.  I do think it is important
>> that we start using bitbucket or github and pull requests.  
>
> And here I totally agree with Chris. It's easier for me to try
> bitbucket than move everyone to github.

Definitely bitbucket is a good alternative to github, I don't see any
other reason to move to github other than its popularity. Besides,
it seems pretty easy to work with both accounts. 

However, for the time being, I'll stick with github while keeping
bitbucket repo in sync.

Best regards,

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

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

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

[myhdl-list] two issues about conversion

[David G. M. <gu...@dt...>]

Hello, my name is David and I'm new to MyHDL. I'm starting to learn 
MyHDL and I've installed 0.8-dev. As an exercise, I'm trying to describe 
and test an LFSR that is  attached as LFSR9.py. I got no errors when 
executing it, but I cannot synthesize it because the code is not 
properly converted to Verilog: If you have a look to the attached LFSR.v 
you will see that the input to the xor gate is formed by references to 
the name of the external variable passed as parameter (my_state) instead 
of the formal name of the parameter in the prototype of the function 
(state).


The second issue I found while learning MyHDL was relative to shadow 
sliced signals. I attach another file with an example of it 
(reduce_and.py) . If I use an slice of just one bit, It works as I 
expect. But if the width of the slice is wider than one bit, I have to 
assign it to another intermediate signal in an always_comb generator to 
make it have any effect. Otherways, I will get a wrong conversion to 
Verilog. In the given example, if you change the reference to others in 
line 23 for its actual value [A(len(A),1)], it doesn't work, but if I 
use straight references to one-bit slices, as in lines 25 and 28, it 
does work as I'd expect in the previous case. Am I misunderstanding 
anything about shadow sliced signal or I hit a bug in the converter? I 
couldn't find any more info or examples about this kind of usecases in 
the documentation, sorry If I missed something.

Kind regards,
David.

Re: [myhdl-list] Keep hierarchy in VHDL conversion

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

El Sun, 14 Apr 2013 19:48:15 -0500
Christopher Felton <chr...@gm...> escribió:

> On 4/14/13 2:28 PM, Jan Decaluwe wrote:
> > On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
> >
> >> Oscar,
> >>
> >> if you have never used mercurial and need some help drop me a
> >> line. I am very active in TortoiseHg development (and a bit on
> >> mercurial as well) so I think I could help bring you up to speed
> >> if you need it
> >
> > Interesting.
> >
> > Perhaps I should ask a more general question: should we
> > consider to move MyHDL development to github?
> >
> > This is not a technical question. Many Pythonistas probably
> > have a slight preference for Python-based mercurial.
> > Professionally, I use both and I am happy with either one.

Well, I used both git and mercurial, but I decided to use git for
non-technical reasons: 1. git was the VCS used in my work and 2. github
was (and still is) very popular at that time (I didn't know about
bitbucket yet).

I don't mind switching to hg again, but I was used to github, and I
didn't know about bitbucket until couple months ago (In fact I'll sign
up and check it right now). 

> > The point is that "everyone" seems to be at github. So
> > perhaps this is good for visibility.

You're right, I'd prefer github because of its popularity and its
social features, but I don't see them a valid reason to make a
migration. 

> > It may also be good for development. I like the way
> > Oscar presented his work: it shows commitment to
> > maintain the feature, and everyone can try/follow
> > it without requiring my assistance. Much better
> > than getting patches/bundles out of the blue that
> > I am supposed to review/check/integrate before others
> > can (easily) do so.

That's the way I decided to present my contributions. When I started
this discussion couple months ago, I was really desperate to have this
feature, so I boldly went for it and patched up to the point of have
practically forked MyHDL. Then I started to "de-fork" and refactor
it, so I can propose an external module that can use with
minimal changes on MyHDL base code.

Of course, I'd love to have it added to mainstream code, but this way
is easier to debug and prevent from breaking base code. Besides, this
is an additional feature, my intention wasn't to change the original
conversion functions.

> > Of course, for this to work, all development should
> > be on the same system.
> >
> > Jan
> >
> 
> As Jan eluded, there are two features:
> 
>     1) Improved work-flow:
>        a) pull requests (largest impact)
>        b) simplified interfaces (click buttons on webpages)
>        c) default public (mods not local on private machine)
> 
>     2) Visibility (popular social thing)
> 
> If we feel #2 holds a lot of weight then github is the answer. If
> visibility is important but not the most important then I would
> suggest we stay with hg and use bitbucket (like pypy, sphinx,
> cherrpy, ...).
> 
> For me a move to git vs. hg would be disruptive.  Not because
> of some huge technical short-coming but because all my work has
> been with hg and bitbucket.  If we move to git and github my
> work flow and existing projects will not be compatible with the
> new work flow (i.e. git and github).
> 
> Other than not being as popular I don't know of any technical
> limitations of bitbucket vs. github.
> 
> It will be interesting to here back from Oscar, why he chose
> github over bitbucket being myhdl uses hg.
> 
> My vote is to stay with hg and utilize bitbucket but I am not
> adamantly opposed to git and github.  I do think it is important
> that we start using bitbucket or github and pull requests.

And here I totally agree with Chris. It's easier for me to try
bitbucket than move everyone to github.

Best regards.

PD: Angel, thanks for your help, I appreciate it.

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

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

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

Re: [myhdl-list] Keep hierarchy in VHDL conversion

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

On Mon, Apr 15, 2013 at 2:52 AM, Christopher Felton
<chr...@gm...> wrote:
> On 4/14/13 2:48 PM, Angel Ezquerra wrote:
>> On Sun, Apr 14, 2013 at 9:28 PM, Jan Decaluwe <ja...@ja...> wrote:
>>> On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
>>>
>>>> Oscar,
>>>>
>>>> if you have never used mercurial and need some help drop me a line. I
>>>> am very active in TortoiseHg development (and a bit on mercurial as
>>>> well) so I think I could help bring you up to speed if you need it
>>>
>>> Interesting.
>>>
>>> Perhaps I should ask a more general question: should we
>>> consider to move MyHDL development to github?
>>>
>>> This is not a technical question. Many Pythonistas probably
>>> have a slight preference for Python-based mercurial.
>>> Professionally, I use both and I am happy with either one.
>>>
>>> The point is that "everyone" seems to be at github. So
>>> perhaps this is good for visibility.
>>>
>>> It may also be good for development. I like the way
>>> Oscar presented his work: it shows commitment to
>>> maintain the feature, and everyone can try/follow
>>> it without requiring my assistance. Much better
>>> than getting patches/bundles out of the blue that
>>> I am supposed to review/check/integrate before others
>>> can (easily) do so.
>>>
>>> Of course, for this to work, all development should
>>> be on the same system.
>>>
>>> Jan
>>
>>
>> As you an imagine given my background I really like the fact that
>> MyHDL is developed using mercurial, which I greatly prefer over git.
>>
>> This is a bit off topic but I personally find the fact that so many
>> technical people use and even advocate git rather than mercurial both
>> surprising and a little depressing, since (IMHO) mercurial is a much
>> better all around version control system (_much_ better UI, better
>> tools, better Windows support, better, simpler model, etc). I think
>> github is a big reason why git is more popular than mercurial (at the
>> time github was created, there was nothing quite like it, unless you
>> count SourceForge...) but the real reason is probably the fact that it
>> was created by Linus... I guess we technical people are as prone to
>> decide things based on non technical reasons as anybody else...
>
> Can you outline some of the technical pros?  From what I have been
> able to gather it is somewhat subjective.  It seems both projects
> have been influence each other resulting in technical equals.

Before I start I want to first state that I am way more knowledgeable
about mercurial than about git. As I said I contribute to mercurial in
addition to using it everyday (for work and for my own stuff). I have
much less experience with git, but I believe I have enough to judge
both systems on their merits.

With that being said, and taking into account that everything I say
here is just my humble opinion and that my git-fu is not nearly as
good as my mercurial-fu...

/rant mode on :-)

In truth both systems are more similar than they are different. Both
are excellent distributed version control systems with a pretty
similar technical foundation. This makes sense since both were
originally designed to solve the same problem, notably, the
replacement of BitKeeper as the version control system for the Linux
kernel. Both had their first version publicly released pretty much
simultaneously (withing a couple of days I think) and both were
created by notable Linux kernel hackers (although obviously one of
them is the most notable and famous kernel hacker of them all :-) ).
Both handle and use pretty similar concepts, even though some of the
user facing names they use are not the same (e.g. git branches ˜
mercurial bookmarks).

However, precisely because they are so similar, the few differences
they have become very important. In particular:

1. Git's UI is atrocious: Tens of commands, some of which do pretty
much but not quite the same, some of which do 2, even 3 totally
different, almost unrelated things depending on the command line
arguments; commands which by default do the "wrong" thing (i.e. you
must always use a particular combination of command line parameters to
do the right thing), etc (Steve Losh recently made a funny and just
slightly togue in cheek blog post about this title "Git koans":
http://stevelosh.com/blog/2013/04/git-koans/).

Another thing which is a bit of putting and a symptom of a lack of
clear UI design (although in practice is not a big deal) is the fact
that most git's commands are in their own shells scripts or programs
(rather than a single stand alone command).

If you compare git's command line UI with mercurial's command line UI
the difference is like night and day. There are very few important
mercurial commands (init, clone, commit, update, pull and push) and
each of them does one main thing, and it does it by default (no extra
parameters needed in the usual case). There are other mercurial
commands (add, remove, revert, etc) and all commands have some options
but you do not usually need to use them.

In a funny, kind of perverse way I think this is one of the things
that made git so popular. Git is so hard to use that once people
finally manage to master it they feel a sense of accomplishment which
compels them to write / blog about it. Why are there so many git
tutorials? Is it because git is cool or because it is hard? People
seem to think that the huge number of git tutorials and git blog
postsare due to git being very popular. That is partly true, but I
think the real reason is because it is just hard.

Mercurial on the other hand is just easy (for a version control
system). People just learn to use it and get on with their work. There
is no need to brag about it because there is nothing to brag about.
This is also what makes (again, this is _all_ IMHO) many git users so
fiercely defensive when you criticize their tool of choice. To them
git's UI is not bad, it is just they way it is. If you don't like it
it is because you do not get it. The fact that you must understand
git's internals to get anything serious done is not bad, it is
awesome, etc, etc. It is as if they suffer from some sort of Helsinki
syndrome :->

2. I find that most git GUI tools are poor compared to mercurial's
equivalents (despite their developer's best efforts). This is a direct
consequence of the poor git command line UI. This is not due to a lack
of competence on the git GUI tool developers (which I respect and even
sympathize with). It is due to the fact that they must somehow map
git's command line UI concepts into a sane GUI, which is _very_ hard.
Basically they are between a rock and a hard place because they can
either expose all the rich git functionality at the cost of a complex
UI or they can have a simple UI but lose a lot of what makes git
powerful. I do not think that is as much the case for mercurial GUI
tools and for TortosieHg in particular. I cannot claim that TortoiseHg
is perfect (it is not) but I think the fact that the underlying
mercurial command line model is so clean makes our job of exposing all
of mercurial's power much easier.

3. Git is _very_ Unix-centric. This may improve in the future, given
that Microsoft Visual Studio will soon get built-in git support, but
even then git on Windows relies and will continue to rely on MinGW. A
lot of the things that make git fast are only true on Unix (specially
on Linux).

On the other hand, mercurial is truly cross platform and runs on
windows natively (thanks to it being mostly written in Python).

4. In mercurial, history is "sacred" and "append only" by _default_.
You can easily edit history, but this is discouraged in many subtle
ways, such as the need to manually edit the history editing extensions
(such as mq and rebase). In git, editing history, even _other people's
history_ is not only possible but almost encouraged. I find that is a
big red flag for a version control system. In addition, mercurial is
getting built-in and _safe_ history rewriting commands (this is still
a work in progress, but it is almost done) which add a way to create
new revisions that "replace" old revisions while still keeping the old
revisions around (for more info, check
http://hg-lab.logilab.org/doc/mutable-history/html/).

5. mercurial has cheaper branching that git. This may shock some
people because git users usually claim that that git's branches are
much cheaper than mercurial's. When they say so they often also
mention that mercurial branches are "clones". If you hear that then
you can stop listening to whoever says it because he has not used a
less than 3 year's old mercurial version. Mercurial now has 4 ways to
branch: clones, named branches, bookmarks and anonymous branches.
"mercurial bookmarks" are pretty much the same as "git branches"
although there are some small differences. There are no named branches
nor anonymous branches in git. Anonymous branches are the cheapest
branches of all because you do not need to create them explicitly.
They just happen and you can deal with them as you want. They are a
very powerful and simple concept which (as all in this rant) IMHO let
mercurial capture what really happen when two contributors do
different things based on the same point in history.

6. Mercurial is easier to extend. Its hook and extension system is
very easy to use and give you a lot of power. You can use external
programs but you can also use python and when you do so you have
access to all the mercurial's internals. This has the drawback that if
the mercurial internals change you may need to update your extension,
but in my experience this is rarely necessary.

This is not to say that mercurial is perfect or even better than git
in every way. Its "submodule" support (what mercurial calls
"subrepos") can be (and is being) improved for example. The way it
handles tags is perhaps a little confusing (although it makes sense
when you understand it), etc. Git's clones are often a bit smaller
than mercurial's and git is a bit faster than mercurial on Linux. I
don't think these small advantages are significant enough for most
users, and that mercurial is just the better overall tool.

I've personally had to introduce a lot of people to mercurial (several
tens of people, probably about one hundred). Many of these are
hardware and firmware engineers (the kind of people that MyHDL could
target) for whom a good version control system before learning
mercurial was zip + Skype. I had a very easy time helping them get up
to speed with mercurial. I shudder to think how hard it would have
been to help them reach the same level of proficiency with git.

/rant mode off

> I have found some short coming with git and my work flow but I assume
> that was me being less familiar with git than hg.

I'm curious to know about your experience. Care to share?

Cheers,

Angel

Re: [myhdl-list] Keep hierarchy in VHDL conversion

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

On 4/14/13 2:48 PM, Angel Ezquerra wrote:
> On Sun, Apr 14, 2013 at 9:28 PM, Jan Decaluwe <ja...@ja...> wrote:
>> On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
>>
>>> Oscar,
>>>
>>> if you have never used mercurial and need some help drop me a line. I
>>> am very active in TortoiseHg development (and a bit on mercurial as
>>> well) so I think I could help bring you up to speed if you need it
>>
>> Interesting.
>>
>> Perhaps I should ask a more general question: should we
>> consider to move MyHDL development to github?
>>
>> This is not a technical question. Many Pythonistas probably
>> have a slight preference for Python-based mercurial.
>> Professionally, I use both and I am happy with either one.
>>
>> The point is that "everyone" seems to be at github. So
>> perhaps this is good for visibility.
>>
>> It may also be good for development. I like the way
>> Oscar presented his work: it shows commitment to
>> maintain the feature, and everyone can try/follow
>> it without requiring my assistance. Much better
>> than getting patches/bundles out of the blue that
>> I am supposed to review/check/integrate before others
>> can (easily) do so.
>>
>> Of course, for this to work, all development should
>> be on the same system.
>>
>> Jan
>
>
> As you an imagine given my background I really like the fact that
> MyHDL is developed using mercurial, which I greatly prefer over git.
>
> This is a bit off topic but I personally find the fact that so many
> technical people use and even advocate git rather than mercurial both
> surprising and a little depressing, since (IMHO) mercurial is a much
> better all around version control system (_much_ better UI, better
> tools, better Windows support, better, simpler model, etc). I think
> github is a big reason why git is more popular than mercurial (at the
> time github was created, there was nothing quite like it, unless you
> count SourceForge...) but the real reason is probably the fact that it
> was created by Linus... I guess we technical people are as prone to
> decide things based on non technical reasons as anybody else...

Can you outline some of the technical pros?  From what I have been
able to gather it is somewhat subjective.  It seems both projects
have been influence each other resulting in technical equals.

I have found some short coming with git and my work flow but I assume
that was me being less familiar with git than hg.

Regards,
Chris

Re: [myhdl-list] Keep hierarchy in VHDL conversion

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

On 4/14/13 2:28 PM, Jan Decaluwe wrote:
> On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
>
>> Oscar,
>>
>> if you have never used mercurial and need some help drop me a line. I
>> am very active in TortoiseHg development (and a bit on mercurial as
>> well) so I think I could help bring you up to speed if you need it
>
> Interesting.
>
> Perhaps I should ask a more general question: should we
> consider to move MyHDL development to github?
>
> This is not a technical question. Many Pythonistas probably
> have a slight preference for Python-based mercurial.
> Professionally, I use both and I am happy with either one.
>
> The point is that "everyone" seems to be at github. So
> perhaps this is good for visibility.
>
> It may also be good for development. I like the way
> Oscar presented his work: it shows commitment to
> maintain the feature, and everyone can try/follow
> it without requiring my assistance. Much better
> than getting patches/bundles out of the blue that
> I am supposed to review/check/integrate before others
> can (easily) do so.
>
> Of course, for this to work, all development should
> be on the same system.
>
> Jan
>

As Jan eluded, there are two features:

    1) Improved work-flow:
       a) pull requests (largest impact)
       b) simplified interfaces (click buttons on webpages)
       c) default public (mods not local on private machine)

    2) Visibility (popular social thing)

If we feel #2 holds a lot of weight then github is the answer. If
visibility is important but not the most important then I would
suggest we stay with hg and use bitbucket (like pypy, sphinx,
cherrpy, ...).

For me a move to git vs. hg would be disruptive.  Not because
of some huge technical short-coming but because all my work has
been with hg and bitbucket.  If we move to git and github my
work flow and existing projects will not be compatible with the
new work flow (i.e. git and github).

Other than not being as popular I don't know of any technical
limitations of bitbucket vs. github.

It will be interesting to here back from Oscar, why he chose
github over bitbucket being myhdl uses hg.

My vote is to stay with hg and utilize bitbucket but I am not
adamantly opposed to git and github.  I do think it is important
that we start using bitbucket or github and pull requests.

Regards,
Chris

Re: [myhdl-list] Keep hierarchy in VHDL conversion

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

On Sun, Apr 14, 2013 at 9:28 PM, Jan Decaluwe <ja...@ja...> wrote:
> On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
>
>> Oscar,
>>
>> if you have never used mercurial and need some help drop me a line. I
>> am very active in TortoiseHg development (and a bit on mercurial as
>> well) so I think I could help bring you up to speed if you need it
>
> Interesting.
>
> Perhaps I should ask a more general question: should we
> consider to move MyHDL development to github?
>
> This is not a technical question. Many Pythonistas probably
> have a slight preference for Python-based mercurial.
> Professionally, I use both and I am happy with either one.
>
> The point is that "everyone" seems to be at github. So
> perhaps this is good for visibility.
>
> It may also be good for development. I like the way
> Oscar presented his work: it shows commitment to
> maintain the feature, and everyone can try/follow
> it without requiring my assistance. Much better
> than getting patches/bundles out of the blue that
> I am supposed to review/check/integrate before others
> can (easily) do so.
>
> Of course, for this to work, all development should
> be on the same system.
>
> Jan


As you an imagine given my background I really like the fact that
MyHDL is developed using mercurial, which I greatly prefer over git.

This is a bit off topic but I personally find the fact that so many
technical people use and even advocate git rather than mercurial both
surprising and a little depressing, since (IMHO) mercurial is a much
better all around version control system (_much_ better UI, better
tools, better Windows support, better, simpler model, etc). I think
github is a big reason why git is more popular than mercurial (at the
time github was created, there was nothing quite like it, unless you
count SourceForge...) but the real reason is probably the fact that it
was created by Linus... I guess we technical people are as prone to
decide things based on non technical reasons as anybody else...

You are right however that moving to github may give some additional
visibility to the project. That being said I think the MyHDL audience
may not be as likely to be on github as other more "pure software"
projects.

As an alternative, I find that BitBucket works really well and is also
very popular. It has very good support for mercurial (and git). It is
where TortoiseHg is hosted and it works really well. I find that its
features are on par with github.

In any case, I have contributed little to MyHDL (a few patches some
time ago, which are still waiting to be reviewed or applied, *hint*,
*hint* :-) so take my opinion for what is worth to the project.

Cheers,

Angel

Re: [myhdl-list] Keep hierarchy in VHDL conversion

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

On 04/14/2013 06:02 PM, Angel Ezquerra wrote:

> Oscar,
>
> if you have never used mercurial and need some help drop me a line. I
> am very active in TortoiseHg development (and a bit on mercurial as
> well) so I think I could help bring you up to speed if you need it

Interesting.

Perhaps I should ask a more general question: should we
consider to move MyHDL development to github?

This is not a technical question. Many Pythonistas probably
have a slight preference for Python-based mercurial.
Professionally, I use both and I am happy with either one.

The point is that "everyone" seems to be at github. So
perhaps this is good for visibility.

It may also be good for development. I like the way
Oscar presented his work: it shows commitment to
maintain the feature, and everyone can try/follow
it without requiring my assistance. Much better
than getting patches/bundles out of the blue that
I am supposed to review/check/integrate before others
can (easily) do so.

Of course, for this to work, all development should
be on the same system.

Jan



-- 
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] Keep hierarchy in VHDL conversion

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

On Sun, Apr 14, 2013 at 5:54 PM, Jan Decaluwe <ja...@ja...> wrote:
> On 04/14/2013 03:54 AM, Oscar Daniel Diaz wrote:
>>
>> Hi
>>
>> I've been working in this for a long time ago, and I managed to hack
>> the converter to keep hierarchy as close as possible to MyHDL source
>> design. Now, after a lot of code cleaning and passing almost all the
>> tests I can release the code.
>
>
> Oscar:
>
> I will certainly look into this, but I have one practical question:
> how do you keep track of MyHDL development given that you use
> git and MyHDL development is currently in mercurial?
>
> I am asking because I recently make a number of changes (crucial
> for a customer of mine), still in 0.8 dev. (Chris and I have
> been working on the documentation for a release, but it's
> not finished yet.)
>
> Jan

Oscar,

if you have never used mercurial and need some help drop me a line. I
am very active in TortoiseHg development (and a bit on mercurial as
well) so I think I could help bring you up to speed if you need it.

Cheers,

Angel

Re: [myhdl-list] Keep hierarchy in VHDL conversion

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

On 04/14/2013 03:54 AM, Oscar Daniel Diaz wrote:
> Hi
>
> I've been working in this for a long time ago, and I managed to hack
> the converter to keep hierarchy as close as possible to MyHDL source
> design. Now, after a lot of code cleaning and passing almost all the
> tests I can release the code.

Oscar:

I will certainly look into this, but I have one practical question:
how do you keep track of MyHDL development given that you use
git and MyHDL development is currently in mercurial?

I am asking because I recently make a number of changes (crucial
for a customer of mine), still in 0.8 dev. (Chris and I have
been working on the documentation for a release, but it's
not finished yet.)

Jan


> https://github.com/dargor0/myhdl-addons
>
> check the "conversion" directory.
>
> Long threads and many words we have dedicated to this issue, but I want
> to re-state my motivation and main rationale to propose this "modified
> converter": It's very difficult to do floor-planning with a flat
> single-file design, not to mention almost impossible to do partial
> re-configuration (PR). With this converter, now I can generate a
> top-module based on component instantiations that reflects as close as
> possible the structural design from design source.
>
> This converter pass almost all regression tests (I'm working to pass
> all of them), but it is usable and works perfectly for its main
> use-case: keeping top-module structural design.
>
> Only VHDL conversion is supported for now, but I'm working on Verilog
> converter too.
>
> And finally, now that I propose this converter, I'd like to propose an
> Idea to extend conversion process. Following this proposal, I'm
> thinking of add custom "filter" functions to modify the extracted
> internal data (ast tree), and doing some kind of optimizations. It only
> needs one dummy function call in conversion code, then "custom
> converters" only need to subclass them. This initially would help me to
> avoid some monkey-patching I did to implement this converter, but I
> think it can be a starting point to extend the convertible subset, and
> also to ease testing of this "extensions".
>
> Best regards,
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
>
>
>
> _______________________________________________
> 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] [Patch] Missing import in _Signal.py

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

On 04/12/2013 08:14 PM, Thomas Heller wrote:
> Hope it is ok to post these patches here instead of opeing a bug
> report...

Thanks for asking. For small patches, I prefer hg patches
(hg export -o ...). Easier in my workflow, and the contributor
gets the credit.

I have made the correction.

Jan

>
> Thanks, Thomas
>
> diff -r 890982e941e2 myhdl/_Signal.py
> --- a/myhdl/_Signal.py  Thu Apr 11 22:20:37 2013 +0200
> +++ b/myhdl/_Signal.py  Fri Apr 12 20:11:17 2013 +0200
> @@ -29,6 +29,7 @@
>
>    from inspect import currentframe, getouterframes
>    from copy import copy, deepcopy
> +import operator
>
>    from myhdl import _simulator as sim
>    from myhdl._simulator import _signals, _siglist, _futureEvents, now
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
>


-- 
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] Keep hierarchy in VHDL conversion

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

On Sun, Apr 14, 2013 at 3:54 AM, Oscar Daniel Diaz <osc...@gm...> wrote:
> Hi
>
> I've been working in this for a long time ago, and I managed to hack
> the converter to keep hierarchy as close as possible to MyHDL source
> design. Now, after a lot of code cleaning and passing almost all the
> tests I can release the code.
>
> https://github.com/dargor0/myhdl-addons
>
> check the "conversion" directory.
>
> Long threads and many words we have dedicated to this issue, but I want
> to re-state my motivation and main rationale to propose this "modified
> converter": It's very difficult to do floor-planning with a flat
> single-file design, not to mention almost impossible to do partial
> re-configuration (PR). With this converter, now I can generate a
> top-module based on component instantiations that reflects as close as
> possible the structural design from design source.
>
> This converter pass almost all regression tests (I'm working to pass
> all of them), but it is usable and works perfectly for its main
> use-case: keeping top-module structural design.
>
> Only VHDL conversion is supported for now, but I'm working on Verilog
> converter too.
>
> And finally, now that I propose this converter, I'd like to propose an
> Idea to extend conversion process. Following this proposal, I'm
> thinking of add custom "filter" functions to modify the extracted
> internal data (ast tree), and doing some kind of optimizations. It only
> needs one dummy function call in conversion code, then "custom
> converters" only need to subclass them. This initially would help me to
> avoid some monkey-patching I did to implement this converter, but I
> think it can be a starting point to extend the convertible subset, and
> also to ease testing of this "extensions".
>
> Best regards,
>
> --
> Oscar Díaz

Oscar, this is awesome!

This is something I have wanted pretty much since I discovered MyHDL.
I hope you can make all the tests pass soon and that you can implement
the Verilog side as well. I also hope Jan can have a look and
hopefully integrate it into the official MyHDL code base.

I went though the github readme file briefly, and it was not super
clear to me how you select the output file names and who you create
the corresponding entities. It would be nice if you had some example
so that it was easier to understand how the whole thing works.

Cheers,

Angel

Re: [myhdl-list] Missing parens in isinstance call, in _toVHDL.py

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

Thanks.

This was a duplicate of bug 28 that I forgot to solve
(also for lack of a test case.)

I have solved it now in the default branch and 0.8-dev.

On 03/28/2013 09:04 PM, Thomas Heller wrote:
> The following diff is against the current 0.8-dev branch.
> The bug is triggered when code like this is converted:
>
>       dout.next = 0x8030 + (channel << 10)
>
> Thomas
>
>
> diff -r 57a3b8fd0e77 myhdl/conversion/_toVHDL.py
> --- a/myhdl/conversion/_toVHDL.py       Sun Mar 10 22:25:20 2013 +0100
> +++ b/myhdl/conversion/_toVHDL.py       Thu Mar 28 21:01:14 2013 +0100
> @@ -602,7 +602,7 @@
>                    else:
>                        raise AssertionError("unexpected op %s" % op)
>                elif isinstance(left.vhd, vhd_int) and
> isinstance(right.vhd, vhd_vector):
> -                if isinstance(op, ast.Add, ast.Sub, ast.Mod, ast.FloorDiv):
> +                if isinstance(op, (ast.Add, ast.Sub, ast.Mod,
> ast.FloorDiv)):
>                        right.vhd.size = ns
>                        node.vhdOri.size = ns
>                    elif isinstance(op, ast.Mult):
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel(R) Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest. Compete
> for recognition, cash, and the chance to get your game on Steam.
> $5K grand prize plus 10 genre and skill prizes. Submit your demo
> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
>


-- 
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] Keep hierarchy in VHDL conversion

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

Hi

I've been working in this for a long time ago, and I managed to hack
the converter to keep hierarchy as close as possible to MyHDL source
design. Now, after a lot of code cleaning and passing almost all the
tests I can release the code.

https://github.com/dargor0/myhdl-addons

check the "conversion" directory. 

Long threads and many words we have dedicated to this issue, but I want
to re-state my motivation and main rationale to propose this "modified
converter": It's very difficult to do floor-planning with a flat
single-file design, not to mention almost impossible to do partial
re-configuration (PR). With this converter, now I can generate a
top-module based on component instantiations that reflects as close as
possible the structural design from design source.

This converter pass almost all regression tests (I'm working to pass
all of them), but it is usable and works perfectly for its main
use-case: keeping top-module structural design.

Only VHDL conversion is supported for now, but I'm working on Verilog
converter too.

And finally, now that I propose this converter, I'd like to propose an
Idea to extend conversion process. Following this proposal, I'm
thinking of add custom "filter" functions to modify the extracted
internal data (ast tree), and doing some kind of optimizations. It only
needs one dummy function call in conversion code, then "custom
converters" only need to subclass them. This initially would help me to
avoid some monkey-patching I did to implement this converter, but I
think it can be a starting point to extend the convertible subset, and
also to ease testing of this "extensions".

Best regards,

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

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

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