myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] MyHDL development has moved to git & GitHub

[Colin B. <co...@sw...>]

Awesome! I have a couple bugs written up as Gists that I'll add to the
issue tracker.
ᐧ

On Sun, Feb 22, 2015 at 6:23 AM, Josy Boelen <jos...@gm...> wrote:

>
> >
> > The development guide has been updated accordingly:
> >
> >      http://dev.myhdl.org/guide.html
>
> The BugTracker link is blank(?). I suppose you mean
> *https://github.com/jandecaluwe/myhdl/issues*
>
> Regards,
>
> Josy
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] MyHDL development has moved to git & GitHub

[Josy B. <jos...@gm...>]

> 
> The development guide has been updated accordingly:
> 
>      http://dev.myhdl.org/guide.html

The BugTracker link is blank(?). I suppose you mean 
*https://github.com/jandecaluwe/myhdl/issues*

Regards,

Josy

Re: [myhdl-list] MyHDL development has moved to git & GitHub

[Josy B. <jos...@gm...>]

I suppose that we have to *fork* the repository first.

Regards,

Josy

Re: [myhdl-list] MyHDL development has moved to git & GitHub

[Josy B. <jos...@gm...>]

Jan Decaluwe <jan <at> jandecaluwe.com> writes:

> 
> Hello:
> 
> MyHDL development has moved to git & GitHub.
> 
> The development guide has been updated accordingly:
> 
>      http://dev.myhdl.org/guide.html
> 
><snip>

the link on the http://dev.myhdl.org/guide.html page specifies 
github.*org* (which doesn't exist) in stead of than github.*com*

Regards,

Josy

Re: [myhdl-list] Is it time for 0.9 release?

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

On 02/18/2015 08:16 AM, Keerthan JC wrote:
> Jan,
> Is it safe for me to fork your github repo and apply my commits on it

Keerthan:

We are on git/github now with an up-to-date repo and development
guide. Let's go ahead.

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

[myhdl-list] MyHDL development has moved to git & GitHub

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

Hello:

MyHDL development has moved to git & GitHub.

The development guide has been updated accordingly:

     http://dev.myhdl.org/guide.html

Please note that in the process, the development flow
has been reorganized. "Bleeding edge" development is
now on the default branch, called 'master' in git.
Release maintenance is on a specific branch.

Please check the guide and let me know if anything
is not clear.

To avoid confusion, I have renamed the old repo
on bitbucket to myhdl-retired. It will stay there
for reference for the forseeable future, but links
in forked repo's will not work anymore. Sorry for
the inconvenience, but I think it is best to do
this kind of migration swiftly.

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] conversion filename?

[Henry G. <he...@ca...>]

On 18/02/15 20:44, Henry Gomersall wrote:
> On 17/02/15 08:57, Henry Gomersall wrote:
>> >There doesn't appear to be a mechanism to set the file/directory name of
>> >a converted v* file. Is this correct?
>> >
>> >It would be really useful to have a mechanism to do so - it could easily
>> >be through the same attribute interface as the name etc. If it is not
>> >set, then fall back to the current strategy.
>> >
>> >Having all the v* files dumped into my project root is a bit suboptimal.
>> >Of course I can work around it using the full power of python, but it
>> >seems like an odd thing to be missing.
>> >
>> >Is this something that would be accepted?
> I've implemented this at:
> https://bitbucket.org/heng/myhdl/src/2e9e7807e7cd61c8debe8d73dec3bf2a4cb81124/?at=0.9-dev-set_file_dir
>
> Tests, code and docs all modified.
>
> It seemed easier to put some code out their for discussion than await
> any more input.
>
> Comments before I raise a PR?

I've raised a PR on this though I can change things as necessary.

Essentially, the code adds an optional directory attribute to toVHDL and 
toVerilog.

Leaving the directory attribute as None results in the existing 
behaviour of putting the files in the current working directory.

Setting the directory attribute results in any generated files being 
placed in that directory (including an test bench files).

Cheers,

Henry

Re: [myhdl-list] Interface conversion bug in 0.9-dev?

[SHEN C. <she...@co...>]

I agree the original title was poorly chosen. It's a problem with
ShadowSignal. I occurs no matter if interface is used.

A local reference does correct the variable inference. Thank you.
However, if I have to remember to do this every time,
I'd rather not using shadow signal for list element at all,

shenchen


On 2015-02-18 22:43, Christopher Felton wrote:

>> https://gist.github.com/cfelton/1648ad98e2bda5745ec9 [1] Not sure if
>> this will work in your case or not. It will take some more
>> investigation to determine if this is a bug or a not supported 
>> feature,
>> and if it is to be a not supported, can it be detected.
>
> I played around with this some more, the issue can be
> reproduced in 0.8.1 using just list-of-signals and
> ShadowSignals. It doesn't appear to be tied to the
> /interface/ conversion. The above gist link has an
> example of each.
>
> Regards,
> Chris
>
>
------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and 
> Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & 
> more
> Get technology previously reserved for billion-dollar corporations, 
> FREE
>
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

-- 

Links:
------
[1] https://gist.github.com/cfelton/1648ad98e2bda5745ec9

Re: [myhdl-list] conversion filename?

[Henry G. <he...@ca...>]

On 17/02/15 08:57, Henry Gomersall wrote:
> There doesn't appear to be a mechanism to set the file/directory name of
> a converted v* file. Is this correct?
>
> It would be really useful to have a mechanism to do so - it could easily
> be through the same attribute interface as the name etc. If it is not
> set, then fall back to the current strategy.
>
> Having all the v* files dumped into my project root is a bit suboptimal.
> Of course I can work around it using the full power of python, but it
> seems like an odd thing to be missing.
>
> Is this something that would be accepted?

I've implemented this at:
https://bitbucket.org/heng/myhdl/src/2e9e7807e7cd61c8debe8d73dec3bf2a4cb81124/?at=0.9-dev-set_file_dir

Tests, code and docs all modified.

It seemed easier to put some code out their for discussion than await 
any more input.

Comments before I raise a PR?

Cheers,

Henry

[myhdl-list] toVHDL.numericports = False

[Josy B. <jos...@gm...>]

How experimental / final is the support to use std_logic_vectors for the 
top-level in- and out-put ports in VHDL?

I had the impression it worked OK, but I recently updated my 'local' 
production copy to the latest 0.9-dev and it now seems broken. I was 
stupid enough to once not take a safety copy, which make it hard to find 
the differences ...

Regards,

Josy

Re: [myhdl-list] Interface conversion bug in 0.9-dev?

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

<snip>
>
> https://gist.github.com/cfelton/1648ad98e2bda5745ec9
>
> Not sure if this will work in your case or not.
>
> It will take some more investigation to determine if
> this is a bug or a not supported feature, and if it
> is to be a not supported, can it be detected.
>

I played around with this some more, the issue can be
reproduced in 0.8.1 using just list-of-signals and
ShadowSignals.  It doesn't appear to be tied to the
/interface/ conversion.  The above gist link has an
example of each.

Regards,
Chris

Re: [myhdl-list] Interface conversion bug in 0.9-dev?

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

On 2/15/2015 1:45 PM, SHEN Chen wrote:
<snip>

> However, the constant/variable inference is broken in t2, where A.X is
> a list, and A.X0 is a slice of an element in the list.
> t2.py converts to the following verilog code. Note the if(False) line,
> it seems that a.X0 is treated as a constant, despite the "a_X[0] <= 1"
> assignment.
>
> always @(posedge clk) begin: LOGIC_PROC
>       if (False) begin
>           b <= 1;
>       end
>       else begin
>           b <= 0;
>           a_X[0] <= 1;
>       end
> end
>
> I don't think this is correct behavior.

In this complicated "container" example (signal
inside a more complicated structure) you can
always create a local reference and it should
work/help.

I posted a work around here (also changed the
example slightly, see the second and third
module).

https://gist.github.com/cfelton/1648ad98e2bda5745ec9

Not sure if this will work in your case or not.

It will take some more investigation to determine if
this is a bug or a not supported feature, and if it
is to be a not supported, can it be detected.

>
> It took me some time before I realize there is some constant v.s.
> variable inference going on.
> I'm not sure if I understood it correctly. Is there any documentation
> on this? Thank you.

We are in the process of generating the documentation
on interfaces for 0.9 release.  The only documentation
that currently exists is the MEP (MEP107).  I don't
think it describes signal/variable/constant handling.

I will add this to the documentation being added.

Regards,
Chris

Re: [myhdl-list] Is it time for 0.9 release?

[Keerthan JC <jck...@gm...>]

Jan,
Is it safe for me to fork your github repo and apply my commits on it or
should I send a PR to bitbucket?

On Sat, Feb 14, 2015 at 8:43 AM, Christopher Felton <chr...@gm...>
wrote:

>
> >
> > When I tested 0.8.1 with no modifications I had a
> > ShadowSignal failure:
> >
> >     >> py.test GHDL.py test_*.py
> >     <snip>
> >     test_ShadowSignal.py .F..
> >     test_ternary.py F.
> >
>
> That was incomplete, wanted 0.8.1 to be the baseline.
> This is the results for testing the latest 0.9-dev
> on my system:
>
>      >> py.test GHDL.py test_*.py
>      test_interfaces3.py ..FF
>      test_ShadowSignal.py .F..
>      test_ternary.py F.
>
>      >> py.test vcom.py test_*.py
>      test_interfaces3.py ..FF
>      test_ternary.py F.
>
>      >> py.test Icarus.py test_*.py
>      test_interfaces3.py ..FF
>
>
> Regards,
> Chris
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
have a nice day
-jck

Re: [myhdl-list] Interface conversion bug in 0.9-dev?

[SHEN C. <she...@co...>]

Hi all,

I hope someone could shed some light on this conversion problem,
either fixes, workarounds or points to look at in the source code.

I've been trying to switch to 0.9 and use Interface in my new project,
and this conversion problem is the last thing holding us back.
Thank you.

regards,
shenchen


On 2015-02-16 03:45, SHEN Chen wrote:

> Hi all,
>
> I found that the conversion of shadow signal in an "interface" is 
> wrong
> if the signal is in a list.
> Consider the two programs t1 and t2 at the end of the message.
>
> I define a signal A.X, and use a slice of it A.X0 as a condition in
> proc().
> I realized that it is important to have "a.X.next = 1" in the 
> process,
> otherwise a.X (and by extension a.X0) will be regarded as constants.
>
> However, the constant/variable inference is broken in t2, where A.X 
> is
> a list, and A.X0 is a slice of an element in the list.
> t2.py converts to the following verilog code. Note the if(False) 
> line,
> it seems that a.X0 is treated as a constant, despite the "a_X[0]
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] conversion filename?

[Josy B. <jos...@gm...>]

SHEN Chen <shenchen <at> cogenda.com> writes:

> 
> You can do this:
> 
>   toVerilog.timescale = '1ns/1ps'
>   toVerilog.name = 'moduleA'
>   toVerilog(rtl_moduleA, chain)
> 
> It's in the reference section in the manual : 
> http://docs.myhdl.org/en/latest/manual/reference.html
> 
> shenchen
> 
> <snip>

Yes, partially as the *name* is treated as a single argument. In my 
(special Qsys) case the argument would be *directory-path/filename* so we 
would have to split that up. But I could have saved me the code to change 
the entity names, I'll change that. Maybe add a directory atrribute in  
the toVHDL() code?

Regards,
Josy

Re: [myhdl-list] conversion filename?

[SHEN C. <she...@co...>]

You can do this:

  toVerilog.timescale = '1ns/1ps'
  toVerilog.name = 'moduleA'
  toVerilog(rtl_moduleA, chain)

It's in the reference section in the manual : 
http://docs.myhdl.org/en/latest/manual/reference.html

shenchen


On 2015-02-17 17:44, Josy Boelen wrote:

> Henry Gomersallcantab.net> writes:
>
>> There doesn't appear to be a mechanism to set the file/directory 
>> name
>
> of
>
>> a converted v* file. Is this correct? It would be really useful to 
>> have
>> a mechanism to do so - it could
>
> easily


Links:
------
[1] 
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
[2] mailto:myh...@li...
[3] https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] conversion filename?

[Josy B. <jos...@gm...>]

Henry Gomersall <heng <at> cantab.net> writes:

> 
> There doesn't appear to be a mechanism to set the file/directory name 
of 
> a converted v* file. Is this correct?
> 
> It would be really useful to have a mechanism to do so - it could 
easily 
> be through the same attribute interface as the name etc. If it is not 
> set, then fall back to the current strategy.
> 
> Having all the v* files dumped into my project root is a bit 
suboptimal. 
> Of course I can work around it using the full power of python, but it 
> seems like an odd thing to be missing.
> 
> Is this something that would be accepted?
> 
> Cheers,
> 
> Henry
> 

It would certainly suit me. E.g. I have Altera's Qsys calling on the 
Python module to generate a tailored version. Now the Python module has 
to remove any existing target and copy/rename/move (using os.rename()) 
the generated file into the correct place. Having an in-place generation 
would certainly be nice. A second plus: the local generated V*-file 
would corroborate with the 'development parameters' as it will no longer 
be overwritten.

Regards,

Josy

[myhdl-list] conversion filename?

[Henry G. <he...@ca...>]

There doesn't appear to be a mechanism to set the file/directory name of 
a converted v* file. Is this correct?

It would be really useful to have a mechanism to do so - it could easily 
be through the same attribute interface as the name etc. If it is not 
set, then fall back to the current strategy.

Having all the v* files dumped into my project root is a bit suboptimal. 
Of course I can work around it using the full power of python, but it 
seems like an odd thing to be missing.

Is this something that would be accepted?

Cheers,

Henry

[myhdl-list] Interface conversion bug in 0.9-dev?

[SHEN C. <she...@co...>]

Hi all,

I found that the conversion of shadow signal in an "interface" is wrong 
if the signal is in a list.
Consider the two programs t1 and t2 at the end of the message.

I define a signal A.X, and use a slice of it A.X0 as a condition in 
proc().
I realized that it is important to have "a.X.next = 1" in the process, 
otherwise a.X (and by extension a.X0) will be regarded as constants.

However, the constant/variable inference is broken in t2, where A.X is 
a list, and A.X0 is a slice of an element in the list.
t2.py converts to the following verilog code. Note the if(False) line, 
it seems that a.X0 is treated as a constant, despite the "a_X[0] <= 1" 
assignment.

always @(posedge clk) begin: LOGIC_PROC
     if (False) begin
         b <= 1;
     end
     else begin
         b <= 0;
         a_X[0] <= 1;
     end
end

I don't think this is correct behavior.

It took me some time before I realize there is some constant v.s. 
variable inference going on.
I'm not sure if I understood it correctly. Is there any documentation 
on this? Thank you.

regards,
Shenchen


============================== t1.py =============================
from myhdl import *

class A(object):
     def __init__(self):
         self.X = Signal(intbv(0)[8:])
         self.X0 = self.X(0)

def logic(clk, b):
     a = A()
     @always(clk.posedge)
     def proc():
         if a.X0:
             b.next = 1
         else:
             b.next = 0
             a.X.next = 1
     return proc

clk = Signal(False)
b = Signal(intbv(0)[8:])
toVerilog(logic, clk, b)
===================================================================

============================== t2.py =============================
from myhdl import *

class A(object):
     def __init__(self):
         self.X = [Signal(intbv(0)[8:]), Signal(intbv(0)[8:])]
         self.X0 = self.X[0](0)

def logic(clk, b):
     a = A()
     @always(clk.posedge)
     def proc():
         if a.X0:
         #if a.X[0][0]:
             b.next = 1
         else:
             b.next = 0
             a.X[0].next = 1
     return proc

clk = Signal(False)
b = Signal(intbv(0)[8:])
toVerilog(logic, clk, b)
===================================================================

Re: [myhdl-list] multiple instantiations

[Josy B. <jos...@gm...>]

Edward Vidal <develone <at> sbcglobal.net> writes:

<snip>
> jp_process;JP_PROCESS_JPEG_LOGIC: process (update_s, right_s(0), 
right_s(1), ..., right_s(63), flgs_s(0), flgs_s(1), ..., flgs_s(63), 
sam_s(0), sam_s(1), ... , sam_s(63), left_s(0), left_s(1), ... , 
left_s(63)) is 
>begin    
><snip>
I had noticed this behaviour before, and it will generate a warning (at 
least in the Sigasi VHDL editor). I added this to my MyHDL code in 
_toVHDL.py:
def compressSensitivityList(senslist):
    ''' reduce spelled out list items like [**name**(0), **name**(1), 
..., **name**(n)] to just **name**'''
    r = []
    for item in senslist:
        name = item._name.split('(',1)[0]
        if not name in r:
            r.append( name ) # note that the list now contains names and 
not Signals, but we are interested in the strings ...        
    return r

class _ConvertAlwaysCombVisitor(_ConvertVisitor):

    def __init__(self, tree, blockBuf, funcBuf):
        _ConvertVisitor.__init__(self, tree, blockBuf)
        self.funcBuf = funcBuf


    def visit_FunctionDef(self, node):
        self.writeDoc(node)
        senslist = **compressSensitivityList**( self.tree.senslist )
        . . .

Your list should now be a short as:
jp_process;JP_PROCESS_JPEG_LOGIC: process (update_s, right_s, flgs_s, 
sam_s, left_s) is

Regards,
Josy

Re: [myhdl-list] Is it time for 0.9 release?

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

>
> When I tested 0.8.1 with no modifications I had a
> ShadowSignal failure:
>
>     >> py.test GHDL.py test_*.py
>     <snip>
>     test_ShadowSignal.py .F..
>     test_ternary.py F.
>

That was incomplete, wanted 0.8.1 to be the baseline.
This is the results for testing the latest 0.9-dev
on my system:

     >> py.test GHDL.py test_*.py
     test_interfaces3.py ..FF
     test_ShadowSignal.py .F..
     test_ternary.py F.

     >> py.test vcom.py test_*.py
     test_interfaces3.py ..FF
     test_ternary.py F.

     >> py.test Icarus.py test_*.py
     test_interfaces3.py ..FF


Regards,
Chris

Re: [myhdl-list] Is it time for 0.9 release?

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

On 2/13/2015 12:28 PM, Jan Decaluwe wrote:
> On 02/10/2015 07:03 AM, Keerthan JC wrote:
>> There are failing VHDL tests: https://travis-ci.org/jck/myhdl/jobs/47472029
>>
>> Are we planning to fix there before 0.9?
>
> I have to review the ternary operator test. This was in anticipation
> of VHDL-2008, but now I'm not sure it's official VHDL.
>
> As for the other tests, the tests that fail at my side are different
> than yours (on github). Seems you fixed test_interfaces3.py,
> but another test related to ShadowSignals now fails.
>
> The goal for 0.9 should definitely be no failing tests.
>
> Jan
>

When I tested 0.8.1 with no modifications I had a
ShadowSignal failure:

   >> py.test GHDL.py test_*.py
   <snip>
   test_ShadowSignal.py .F..
   test_ternary.py F.

Regards,
Chris

Re: [myhdl-list] multiple instantiations

[Henry G. <he...@ca...>]

On 13/02/15 19:28, Christopher Felton wrote:
> On 2/13/2015 7:52 AM, Henry Gomersall wrote:
>> >I think I know the answer to this, but wanted to check.
>> >
>> >I'm creating lots of instances of the same component (with different
>> >signals) - 128 in all. Clearly, this will lead to a pretty unwieldy vhdl
>> >file if every one has it's own process block.
>> >
>> >I understand I could make this neater in raw VHDL (which I can do
>> >through MyHDL easily enough) with the generate keyword.
>> >
>> >Is there a way to do a tight conversion for multiple equivalent
>> >instances? Is this one of the targets of MEP 110
>> >(http://dev.myhdl.org/meps/mep-110.html)?
> The design is flattened and so each instance will show up
> as a process in the generated file.  And yes, if this was
> perceived as an issue MEP 110 would address it, MEP 110
> could be used to allow one module to be instantiated many
> times in the generated V* (IIRC MEP 110 is still in
> draft/proposal it hasn't been accepted?).
>
> What is the down side of the flattening?

Just a massive unwieldy V* file. No other reason. :)

Henry

Re: [myhdl-list] multiple instantiations

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

On 2/13/2015 7:52 AM, Henry Gomersall wrote:
> I think I know the answer to this, but wanted to check.
>
> I'm creating lots of instances of the same component (with different
> signals) - 128 in all. Clearly, this will lead to a pretty unwieldy vhdl
> file if every one has it's own process block.
>
> I understand I could make this neater in raw VHDL (which I can do
> through MyHDL easily enough) with the generate keyword.
>
> Is there a way to do a tight conversion for multiple equivalent
> instances? Is this one of the targets of MEP 110
> (http://dev.myhdl.org/meps/mep-110.html)?

The design is flattened and so each instance will show up
as a process in the generated file.  And yes, if this was
perceived as an issue MEP 110 would address it, MEP 110
could be used to allow one module to be instantiated many
times in the generated V* (IIRC MEP 110 is still in
draft/proposal it hasn't been accepted?).

What is the down side of the flattening?

Regards,
Chris

Re: [myhdl-list] Is it time for 0.9 release?

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

On 02/10/2015 07:03 AM, Keerthan JC wrote:
> There are failing VHDL tests: https://travis-ci.org/jck/myhdl/jobs/47472029
>
> Are we planning to fix there before 0.9?

I have to review the ternary operator test. This was in anticipation
of VHDL-2008, but now I'm not sure it's official VHDL.

As for the other tests, the tests that fail at my side are different
than yours (on github). Seems you fixed test_interfaces3.py,
but another test related to ShadowSignals now fails.

The goal for 0.9 should definitely be no failing tests.

Jan


> On Mon, Feb 9, 2015 at 6:31 PM, Angel Ezquerra <ang...@gm... <mailto:ang...@gm...>> wrote:
>
>     On Mon, Feb 9, 2015 at 1:32 PM, Henry Gomersall <he...@ca... <mailto:he...@ca...>> wrote:
>     > On 09/02/15 12:29, Angel Ezquerra wrote:
>     >> I find that the BitBucket UI is not as flashy as
>     >> github's but is IMHO easier to use and mercurial is oh so much simpler
>     >> than git!
>     >
>     > I find precisely the opposite. Perhaps it's to do with what tools one is
>     > used to.
>
>     It was not my intention to start a mercurial vs git flamewar (hence
>     the "IMHO" qualifier on my statement above).
>
>     Out of curiosity, which part do you disagree with, the github vs
>     bitbucket part, the git vs mercurial part or both?
>     I'd be inclined to agree with you in that it is a matter of the tool
>     you are used to on the first part. On the second one (git vs
>     mercurial) not so much :P
>
>     Cheers!
>
>     Angel
>
>     ------------------------------------------------------------------------------
>     Dive into the World of Parallel Programming. The Go Parallel Website,
>     sponsored by Intel and developed in partnership with Slashdot Media, is your
>     hub for all things parallel software development, from weekly thought
>     leadership blogs to news, videos, case studies, tutorials and more. Take a
>     look and join the conversation now. http://goparallel.sourceforge.net/
>     _______________________________________________
>     myhdl-list mailing list
>     myh...@li... <mailto:myh...@li...>
>     https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
>
> --
> have a nice day
> -jck
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> 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