myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] MyHDL: Why Do We Need Signal Assignments?

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

On Sep 23, 2012 10:13 AM, "Jan Decaluwe" <ja...@ja...> wrote:
>
> I have justed posted a blog about signal assignments, why they are
> needed and who MyHDL implements them.
>
> I feel these concepts are often misunderstood, which leads to
> misunderstandings later on. I hope you like it.
>
>
http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=251153&
>
> --
> th Co Jan Decaluwe

Very nice and clear post. It covers some very basic stuff, yet this is
something that I think a lot of people do not really understand.

I remember that, when I first read about MyHDL, I found the way signal
assignments work (by assigning to the "next" property) very intuitive. I'm
sure a lot of people will find your article very enlightening. I sure did,
and I forwarded it to the members of my team.

Cheers,

Angel

Re: [myhdl-list] MyHDL: Why Do We Need Signal Assignments?

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

Hi Chris:

Why not ask the question in the forum, let's make these
guys dizzy :-)

On 09/24/2012 07:55 PM, Christopher Felton wrote:
> On 9/23/2012 3:12 AM, Jan Decaluwe wrote:
>> I have justed posted a blog about signal assignments, why they are
>> needed and who MyHDL implements them.
>>
>> I feel these concepts are often misunderstood, which leads to
>> misunderstandings later on. I hope you like it.
>>
>> http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=251153&
>>
>
> Good post as usual.  I appreciate the connection between procedural
> descriptions and concurrent descriptions.  Any HDL designer (or anyone
> that has ever written a line of HDL) can learn quite a bit from your posts.
>
> Now ... one of the items you eluted to in a previous thread was that in
> Python3, MyHDL "variables" won't need to be explicitly declared in the
> generator.  If I am not mistaken, often if a variable is used you have
> to use the @instance decorator and cannot take advantage of the @always*
> decorators (not true for all variables use cases but many).  Is this
> true or am I mistaken?
>
> Regards,
> Chris
>
>
> ------------------------------------------------------------------------------
> 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/
>


-- 
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] MyHDL: Why Do We Need Signal Assignments?

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

On 9/23/2012 3:12 AM, Jan Decaluwe wrote:
> I have justed posted a blog about signal assignments, why they are
> needed and who MyHDL implements them.
>
> I feel these concepts are often misunderstood, which leads to
> misunderstandings later on. I hope you like it.
>
> http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=251153&
>

Good post as usual.  I appreciate the connection between procedural 
descriptions and concurrent descriptions.  Any HDL designer (or anyone 
that has ever written a line of HDL) can learn quite a bit from your posts.

Now ... one of the items you eluted to in a previous thread was that in 
Python3, MyHDL "variables" won't need to be explicitly declared in the 
generator.  If I am not mistaken, often if a variable is used you have 
to use the @instance decorator and cannot take advantage of the @always* 
decorators (not true for all variables use cases but many).  Is this 
true or am I mistaken?

Regards,
Chris

[myhdl-list] MyHDL: Why Do We Need Signal Assignments?

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

I have justed posted a blog about signal assignments, why they are
needed and who MyHDL implements them.

I feel these concepts are often misunderstood, which leads to
misunderstandings later on. I hope you like it.

http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=251153&

-- 
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] Filename path support for toVHDL and toVerilog functions

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

On 9/20/12 2:16 AM, Shankar Giri Venkita Giri wrote:
> Maybe we should be adding path support for toVHDL and toVerilog conversion functions in myhdl. This will allow us to generate HDL at user defined path and not pollute current directory. Since these functions have a variable arglist in the end, the path argument has to come in the beginning, which means API breaks. Thoughts?
>
> -Shankar
>

I like the idea and it might not be too difficult to implement.  If you 
use the current toV*.name attribute (see example below) the conversion 
functions would need to do some limited path/name checking.  Else, a new 
toV*.path (or output) attribute could be added.

In [125]: mkdir conversion_output

In [126]: def ex(clock, reset, x, y):
      ...:     @always_seq(clock.posedge, reset=reset)
      ...:     def hdl():
      ...:         x.next = y + y
      ...:     return hdl

In [127]: clock = Signal(bool(0))
      ...: reset = ResetSignal(bool(0), active=0, async=True)
      ...: x = Signal(intbv(0, min=-7, max=8))
      ...: y = Signal(intbv(0, min=2*x.min, max=2*x.max))
      ...: toVerilog.name = os.path.join('conversion_output/', 'new_name.v')
      ...: toVerilog(ex, clock, reset, x, y)
      ...:
---------------------------------------------------------------------------
IOError                                   Traceback (most recent call ...
IOError: [Errno 2] No such file or directory: 
'tb_conversion_output/new_name.v.v'


Regards,
Chris

[myhdl-list] Filename path support for toVHDL and toVerilog functions

[Shankar G. V. G. <sha...@me...>]

Maybe we should be adding path support for toVHDL and toVerilog conversion functions in myhdl. This will allow us to generate HDL at user defined path and not pollute current directory. Since these functions have a variable arglist in the end, the path argument has to come in the beginning, which means API breaks. Thoughts?

-Shankar

Re: [myhdl-list] MyHDL : The Case for a Better HDL

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

On 9/17/2012 4:44 AM, Jan Decaluwe wrote:
> On 09/12/2012 04:15 PM, Christopher Felton wrote:
>
>> Has anyone else read the blog on APP?  Anyone read the comments?
>>
>> As usual, I think the blog post Jan D. wrote is very good.  Jan has a
>> good ability of explaining concepts.
>
> Thanks for the encouraging words. Unfortunately, not everyone
> shares this opinion.
>
> I didn't feel like it was a resounding success. As usual, I
> was not prepared for the amount of nonsense that you can get
> as feedback. The "conventional wisdom" is extremely strong.
> So strong in fact, that people go as far as calling my
> carefully crafted post as "misleading" and a "disservice",
> instead of as an invitation for fresh, independent thinking.

Your original thought is probably correct; you sparked interest in MyHDL 
to a few who are not vocal on the message board.  And you taught a ton 
of readers more about their current HDL.

The lack of interest for something new / different is odd.  None of the 
commentors made had good technical rebuttals to the post.  If there was 
technical content it was more about being defensive about their current 
HDL.  I am suprised at the number of people that view Python as a 
scripting language.

The "misleading" and "disservice" is ridiculous.  Even if someone does 
not want to learn Python/MyHDL they can learn a lot about their own HDL 
from the information.

>
> When something like that happens, I tend to forget the lessons
> I try to teach myself and others, and I let everyone know that
> I don't find such a qualification acceptable.
>
> A problem with APP is that it sends out confusing messages.
> The quality of the contributions is very uneven, especially
> in the comment sections. Some total newbies in HDL design
> are listed as guru, and vice versa. How is novice supposed
> to know what information to trust?

There's a couple technical issues with the site, as you mention, in the 
comments sections users get an arbitrary "user rank".  Which appears to 
be based on the number of comments you post (not the quality of the 
comments).  Second, the comment "threading view" is useless.  If you get 
beyond a couple response in a thread the comments reduce to less than a 
word per line.  Not having a threaded view makes it difficult to follow 
the different conversations.  But the site is young, I imagine it can 
improve these deficiencies.

>
> Anyway, I have a new blog post almost ready. Let's try again.
>

I look forward to a new post and it will be interesting to see the 
responses :)

Regards,
Chris

Re: [myhdl-list] MyHDL : The Case for a Better HDL

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

On 09/12/2012 04:15 PM, Christopher Felton wrote:

>
> @jan, since you implicitly mentioned always_seq we should consider a
> release, I will help as much as I can with a 0.8 release :)

I know, it's becoming urgent. Problem is APP is distracting
me and moreover I'm in the middle of a project (also using
MyHDL) with deadlines!


-- 
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] MyHDL : The Case for a Better HDL

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

On 09/12/2012 04:15 PM, Christopher Felton wrote:

> Has anyone else read the blog on APP?  Anyone read the comments?
>
> As usual, I think the blog post Jan D. wrote is very good.  Jan has a
> good ability of explaining concepts.

Thanks for the encouraging words. Unfortunately, not everyone
shares this opinion.

I didn't feel like it was a resounding success. As usual, I
was not prepared for the amount of nonsense that you can get
as feedback. The "conventional wisdom" is extremely strong.
So strong in fact, that people go as far as calling my
carefully crafted post as "misleading" and a "disservice",
instead of as an invitation for fresh, independent thinking.

When something like that happens, I tend to forget the lessons
I try to teach myself and others, and I let everyone know that
I don't find such a qualification acceptable.

A problem with APP is that it sends out confusing messages.
The quality of the contributions is very uneven, especially
in the comment sections. Some total newbies in HDL design
are listed as guru, and vice versa. How is novice supposed
to know what information to trust?

Anyway, I have a new blog post almost ready. Let's try again.

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

Re: [myhdl-list] MyHDL : The Case for a Better HDL

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

On 9/16/12 7:16 PM, Werner Thie wrote:
> Hi all
>
> ..snip..
>>>> Yes, I have been invited by Max Maxfield to become a blogger
>>>> on that site. I was looking for a good forum to tell
>>>> "the MyHDL story" for some time, and this looks ideal. It
>>>> should give us visibility and spur some interesting
>>>> discussions :-)
>>>>
>>>> I'll try to blog every 2 weeks or so.
>>>>
>>>
>>> Has anyone else read the blog on APP?  Anyone read the comments?
>
> Yes, thumbs up and continue
>
> ..snip..
>> After using myhdl for some time now i really would not want to switch back
>> to vhdl or systemC or systemVerilog.
>> I think the reason is that when i write in myhdl i have to remember way
>> less syntax and function calls with parameters (like with which types can
>> i use with to_unsigned(..) function,is a bitwidth needed?, or how to use
>> the shift_left(..) function, which types does the function needs,etc..)
>> So i actually can write hardware code without visiting "google" and or
>> different manuals every once and a while.
>
> I believe, that the feeling of 'not wanting to go back' has a lot to do
> with the investment which goes with whatever tool you choose,
> investments oftentimes so big, that you're locked in. Which is exactly
> the strategy of the guys selling tools, luring people into their nets,
> entangle them such, that there is no way out anymore. Happened in CAD
> software, it's also happening in the HDL sector, with all the IDE's and
> basic stuff being free, but if you want to access certain features then
> you'll bleed, which all the more make those being entangled advocates of
> whatever they're hooked into.
>

I partially agree with this but I don't see it as much as a "don't go 
back" but more of a "why learn something else/new".

In my opinion MyHDL/Python is different.  I have seen enough folks try 
to learn some other HDL technology and not adopt it, e.g. someone who 
knows Verilog learning VHDL or vise-vera.  I also see people put 
significant resources into learning SV, convertible Matlab subset, e, 
bluespec, SystemC, etc.  Each of those has different utility but we are 
talking about the time invested to learn a technology.

I am sure their are those that have put some effort into MyHDL and have 
not reaped dividends.  But, I think that is a different case, the folks 
that have tried MyHDL and failed are typically not digital system 
designers or prior HDL professionals.

Regards,
Chris

Re: [myhdl-list] MyHDL : The Case for a Better HDL

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

On 9/16/12 10:42 AM, Norbo wrote:
> Am 12.09.2012, 16:15 Uhr, schrieb Christopher Felton
> <chr...@gm...>:
>
<snip>
>
> I think there is a tendency not to switch back once one really got started
> with myhdl. Is this only my impression?
>

Been my experience and observation as well.

>
> greetings
> Norbo
>
>

Re: [myhdl-list] MyHDL : The Case for a Better HDL

[Werner T. <we...@th...>]

Hi all

..snip..
>>> Yes, I have been invited by Max Maxfield to become a blogger
>>> on that site. I was looking for a good forum to tell
>>> "the MyHDL story" for some time, and this looks ideal. It
>>> should give us visibility and spur some interesting
>>> discussions :-)
>>>
>>> I'll try to blog every 2 weeks or so.
>>>
>>
>> Has anyone else read the blog on APP?  Anyone read the comments?

Yes, thumbs up and continue

..snip..
> After using myhdl for some time now i really would not want to switch back
> to vhdl or systemC or systemVerilog.
> I think the reason is that when i write in myhdl i have to remember way
> less syntax and function calls with parameters (like with which types can
> i use with to_unsigned(..) function,is a bitwidth needed?, or how to use
> the shift_left(..) function, which types does the function needs,etc..)
> So i actually can write hardware code without visiting "google" and or
> different manuals every once and a while.

I believe, that the feeling of 'not wanting to go back' has a lot to do 
with the investment which goes with whatever tool you choose, 
investments oftentimes so big, that you're locked in. Which is exactly 
the strategy of the guys selling tools, luring people into their nets, 
entangle them such, that there is no way out anymore. Happened in CAD 
software, it's also happening in the HDL sector, with all the IDE's and 
basic stuff being free, but if you want to access certain features then 
you'll bleed, which all the more make those being entangled advocates of 
whatever they're hooked into.

With OpenSource projects like MyHDL there is a way out of this 
dependency mess, MyHDL is not trivial, the investment is also high, but 
gaining that freedom running your business like you want to run it, 
instead of some other paid guys telling you how, is the beauty of 
OpenSource.

On the other hand does OpenSource suffer from projects becoming 
fractured such, that their is not a group working on it, but a single 
individual. Rolling your own, by branching off or redoing things from 
scratch sometimes wastes a lot of energy.

All in all I really like MyHDL because it's dependable, it evolves, it 
has a lot of potential and it let's you do stuff, which might not be 
possible with basic tools at the level of manpower and money at least I 
have at my disposition, while the quality and expressiveness of the code 
is at a level where maintainability for longer time frames is given.

Just wanted to say thank you to all who invested time into MyHDL

Werner

Re: [myhdl-list] MyHDL : The Case for a Better HDL

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

Am 12.09.2012, 16:15 Uhr, schrieb Christopher Felton  
<chr...@gm...>:

> On 9/7/2012 2:25 AM, Jan Decaluwe wrote:
>> On 09/07/2012 03:14 AM, Christopher Felton wrote:
>>> Jan has posted an interesting blog post
>>> "MyHDL : The Case for a Better HDL"
>>> http://bit.ly/ToK6xg at the All Programmable
>>> Planet, http://www.programmableplanet.com/.
>>>
>>> Be sure and check out the post and contribute
>>> to the conversation.
>>
>> Yes, I have been invited by Max Maxfield to become a blogger
>> on that site. I was looking for a good forum to tell
>> "the MyHDL story" for some time, and this looks ideal. It
>> should give us visibility and spur some interesting
>> discussions :-)
>>
>> I'll try to blog every 2 weeks or so.
>>
>
> Has anyone else read the blog on APP?  Anyone read the comments?

Yes i have read through it.

After using myhdl for some time now i really would not want to switch back  
to vhdl or systemC or systemVerilog.
I think the reason is that when i write in myhdl i have to remember way  
less syntax and function calls with parameters (like with which types can  
i use with to_unsigned(..) function,is a bitwidth needed?, or how to use  
the shift_left(..) function, which types does the function needs,etc..)
So i actually can write hardware code without visiting "google" and or  
different manuals every once and a while.

I think there is a tendency not to switch back once one really got started  
with myhdl. Is this only my impression?


greetings
Norbo

Re: [myhdl-list] Proposal: Cycle accurate software decorator

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

Am 12.09.2012, 15:06 Uhr, schrieb Christopher Felton  
<chr...@gm...>:

> On 9/10/2012 3:51 PM, Norbo wrote:
>> hey i just had an idea about a new decorator something like:
>> @cycle_software
>> it came across me when i was implementing a statemachine. To implement  
>> the
>> statemachine i really was
>> thinking in software. Like, while some condition is not met, stay in  
>> this
>> state, and if this and this happens go
>> to another state. I realised that a "if" and "while" statement would be
>> enougth to describe the statemachine.
>> And i realised that it would have been way easier to write down the  
>> state
>> machine with "if and while" available and no
>> need to write down all the additional states and trying to give them
>> meaningfull names.
>>
> <snip>
>> this state it would then go to the THIRD state
>> 				
>>
>> So what i think is, that it should be quit possible to convert a
>> description like this ( only with "if" and "while" at first) to a valid
>> statemachine, which then would be convertible to vhdl or verilog.
>> This would rise a couple of questions
>>
>
> I am not sure I know what you mean by "thinking in software" vs. the
> implied "thinking in hardware"?  Do you simply mean procedural vs.
> concurrent representations?  In this context the "software thinking" is
> intended to suggest higher abstraction and procedural?

yeah i mean in a more procedural representation. e.g a "while" construct  
where you continue doing things until
a condition gets true (by doing one thing after the other).
In hardware this could be a statemachine where one state is executed after  
the other and then "while" construct would map to
a state with an "if" where the if selectes which state comes next.

greetings
Norbert

Re: [myhdl-list] MyHDL : The Case for a Better HDL

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

<snip>
>
> As usual, I think the blog post Jan D. wrote is very good.  Jan has a
> good ability of explaining concepts.  If you have not read the post, it
> is worth reading, http://bit.ly/ToK6xg.
>

There has been some concern about shortened links (I never really 
thought about it).  The issues are; 1) longevity, 2) where am I going? 
3) obfuscation.  I don't want to discourage anyone from following the 
link, here is the full URL.

http://www.programmableplanet.com/author.asp?section_id=2438&doc_id=250236&

I don't know others opinion on shorten links, mine is a small 
preference, a long URL breaks up the sentence / paragraph, not as much 
with shortened-links.  In the future if I use a shortened link I will 
provide the full link at the end of the response/post.

Regards,
Chris

Re: [myhdl-list] MyHDL : The Case for a Better HDL

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

On 9/7/2012 2:25 AM, Jan Decaluwe wrote:
> On 09/07/2012 03:14 AM, Christopher Felton wrote:
>> Jan has posted an interesting blog post
>> "MyHDL : The Case for a Better HDL"
>> http://bit.ly/ToK6xg at the All Programmable
>> Planet, http://www.programmableplanet.com/.
>>
>> Be sure and check out the post and contribute
>> to the conversation.
>
> Yes, I have been invited by Max Maxfield to become a blogger
> on that site. I was looking for a good forum to tell
> "the MyHDL story" for some time, and this looks ideal. It
> should give us visibility and spur some interesting
> discussions :-)
>
> I'll try to blog every 2 weeks or so.
>

Has anyone else read the blog on APP?  Anyone read the comments?

As usual, I think the blog post Jan D. wrote is very good.  Jan has a 
good ability of explaining concepts.  If you have not read the post, it 
is worth reading, http://bit.ly/ToK6xg.

Jan's Post Covers the following topics::

    * Integer arithmetic
    * Constant representation.
    * Variables
    * RTL abstraction
    * Modern coding practices

For more information on the first topic, see Jan's "These Ints are Made 
For Countin'" essay http://jandecaluwe.com/hdldesign/counting.html.

For me, the "RTL abstraction" section touched on some important points. 
  How do you effectively teach complex digital systems architecture and 
implementation (HDL) and the low-level digital circuits?  I see this as 
a failure in the current education sytle.  We teach the digital systems 
and HDL the same as the digital circuits, from the bottom-up.  Even 
folks that are teaching themselves HDL appear to fall into folly.

@jan, since you implicitly mentioned always_seq we should consider a 
release, I will help as much as I can with a 0.8 release :)

Regards,
Chris

Re: [myhdl-list] Proposal: Cycle accurate software decorator

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

On 9/10/2012 3:51 PM, Norbo wrote:
> hey i just had an idea about a new decorator something like:
> @cycle_software
> it came across me when i was implementing a statemachine. To implement the
> statemachine i really was
> thinking in software. Like, while some condition is not met, stay in this
> state, and if this and this happens go
> to another state. I realised that a "if" and "while" statement would be
> enougth to describe the statemachine.
> And i realised that it would have been way easier to write down the state
> machine with "if and while" available and no
> need to write down all the additional states and trying to give them
> meaningfull names.
>
<snip>
> this state it would then go to the THIRD state
> 				
>
> So what i think is, that it should be quit possible to convert a
> description like this ( only with "if" and "while" at first) to a valid
> statemachine, which then would be convertible to vhdl or verilog.
> This would rise a couple of questions
>

I am not sure I know what you mean by "thinking in software" vs. the 
implied "thinking in hardware"?  Do you simply mean procedural vs. 
concurrent representations?  In this context the "software thinking" is 
intended to suggest higher abstraction and procedural?

Regards,
Chris

[myhdl-list] Proposal: Cycle accurate software decorator

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

hey i just had an idea about a new decorator something like:  
@cycle_software
it came across me when i was implementing a statemachine. To implement the  
statemachine i really was
thinking in software. Like, while some condition is not met, stay in this  
state, and if this and this happens go
to another state. I realised that a "if" and "while" statement would be  
enougth to describe the statemachine.
And i realised that it would have been way easier to write down the state  
machine with "if and while" available and no
need to write down all the additional states and trying to give them  
meaningfull names.


I start with an example

@cycle_software(clk.posedge)
def func_software():
    while 1:
	while not Recieved:     ## would be FIRST state which is left if Received  
is True
	    pass
	
	Data_header.next=Rx_data  ## would be SECOND state which is left  
imidiatly after it is entered
	Count.next=0              ## could be SECOND state but then der should be  
some mechanisem to group expressions
			          ## or every instruction gets its own state with one clock  
cycle inbetween them.

	while not (Count==100):   ## would be in THIRD state,state would go to  
FIRST state if Count==100
             while not Recieved:   ## would be in THIRD state, would go to  
FOURTH state if Received==True
	       pass

	    if Data_header[0]:     ## would all be in the FOURTH state
	    	Ram1[Count].next=Rx_data
             else:
                 Ram2[Count].next=Rx_data
             Count.next=Count+1     ## or an extra state for this, from  
this state it would then go to the THIRD state
				

So what i think is, that it should be quit possible to convert a  
description like this ( only with "if" and "while" at first) to a valid  
statemachine, which then would be convertible to vhdl or verilog.
This would rise a couple of questions

But the way bigger question would be how to integrate this code into  
simulation?
Some thoughts i had for this:
  * use byteplay or something like this and insert a yield clk.posedge  
between every line or at the positions needed
  * do the yield clk.posedge in the  ".next" or use something other than  
the ".next" like ".nextSoftware"
  but then the "while not Recieved: pass" loop would still need to yield  
something.
could be replaced with "while not Recieved: PASS()" and define it with

def PASS():
      yield clk.posedge

but the converter would then need to ignore this.
hmm....

anyway i think it could somehow be possible and get at some (very very  
distant day) a very cool feature.

greetings
Norbo

Re: [myhdl-list] MyHDL : The Case for a Better HDL

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

On 9/7/12 2:18 PM, Jan Decaluwe wrote:
> On 09/07/2012 05:31 PM, Christopher Felton wrote:
>> On 9/7/12 2:25 AM, Jan Decaluwe wrote:
>>> On 09/07/2012 03:14 AM, Christopher Felton wrote:
<snip>
>>
>> I look forward to future post and hopefully a following from your
>> involvement with the site.  It looks like the first post is generating a
>> few comments.
>
> Chris et al:
>
> I think there are some crucial differences with the newsgroup:
>
> First, we will get a lot of visibility by all kinds of people,
> not necessarily interested in MyHDL in the first place. We
> should take that into account.
>
> Second, we are at the steering wheel. (Well in fact, I am.) I think
> there's a big difference in perception between the original blogger
> and the commentators. Let's use that power.
>
> Therefore, we should approach this differently than in the newsgroup.
>
> First, remember the politician's attitude: "Any publicity is good
> publicity". Let's not worry too much about negative reactions: many
> people will think differently. BTW, so far I think reactions are
> reasonable and as could be expected.
>
> Second, we have the power to address any specific topics in a blog
> with much more visiblity/credibility. Just let me know about
> any frustrations!
>
> Personally, I will try to keep comments short and to the point,
> and try not to sound defensive - we have a strong case!
>

Good points and advice, many rat-holes can be avoided :)  Definitely a 
lot of activity on the topic -- which is good --.  It will be 
interesting to see this progress.

Regards,
Chris

Re: [myhdl-list] MyHDL : The Case for a Better HDL

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

On 09/07/2012 05:31 PM, Christopher Felton wrote:
> On 9/7/12 2:25 AM, Jan Decaluwe wrote:
>> On 09/07/2012 03:14 AM, Christopher Felton wrote:
>>> Jan has posted an interesting blog post
>>> "MyHDL : The Case for a Better HDL"
>>> http://bit.ly/ToK6xg at the All Programmable
>>> Planet, http://www.programmableplanet.com/.
>>>
>>> Be sure and check out the post and contribute
>>> to the conversation.
>>
>> Yes, I have been invited by Max Maxfield to become a blogger
>> on that site. I was looking for a good forum to tell
>> "the MyHDL story" for some time, and this looks ideal. It
>> should give us visibility and spur some interesting
>> discussions :-)
>>
>> I'll try to blog every 2 weeks or so.
>>
>
> It is interesting to see the comments to the blog post.  But there has
> not been many "interesting conversations", yet.  There appears to be two
> types of "commentors".  One, those who have very general comments and
> also comments on most of the other blogs in a general way.  They seem to
> have neutral comments, e.g. "it seems interesting".  Or comments for the
> sake of commenting?
>
> Second, are those who seem opposed to the idea and have long post (not
> sure if these long post say much).  But these users "hide" there
> identity, so it is hard to take them serious, was it a drunken rant that
> they were not afraid to post because it had little to no repercussions?
>    Is it worth investing time rebutting their comments?  We have seen on
> this mailing-list a lot of effort can spent with little progress of
> understanding.
>
> I would love to contribute to the conversation, because I agree this
> seems like a good forum to get some interest.  But, I don't know if I
> can invest the time to clearly state my case why I think MyHDL is great
> and explain how my returns from my investment are huge.  I think it will
> drive me crazy not being able to allocate the time and only contribute
> small comments (but this hasn't stopped me in the past, doh).
>
> I look forward to future post and hopefully a following from your
> involvement with the site.  It looks like the first post is generating a
> few comments.

Chris et al:

I think there are some crucial differences with the newsgroup:

First, we will get a lot of visibility by all kinds of people,
not necessarily interested in MyHDL in the first place. We
should take that into account.

Second, we are at the steering wheel. (Well in fact, I am.) I think
there's a big difference in perception between the original blogger
and the commentators. Let's use that power.

Therefore, we should approach this differently than in the newsgroup.

First, remember the politician's attitude: "Any publicity is good
publicity". Let's not worry too much about negative reactions: many
people will think differently. BTW, so far I think reactions are
reasonable and as could be expected.

Second, we have the power to address any specific topics in a blog
with much more visiblity/credibility. Just let me know about
any frustrations!

Personally, I will try to keep comments short and to the point,
and try not to sound defensive - we have a strong case!

-- 
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] MyHDL : The Case for a Better HDL

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

On 9/7/12 2:25 AM, Jan Decaluwe wrote:
> On 09/07/2012 03:14 AM, Christopher Felton wrote:
>> Jan has posted an interesting blog post
>> "MyHDL : The Case for a Better HDL"
>> http://bit.ly/ToK6xg at the All Programmable
>> Planet, http://www.programmableplanet.com/.
>>
>> Be sure and check out the post and contribute
>> to the conversation.
>
> Yes, I have been invited by Max Maxfield to become a blogger
> on that site. I was looking for a good forum to tell
> "the MyHDL story" for some time, and this looks ideal. It
> should give us visibility and spur some interesting
> discussions :-)
>
> I'll try to blog every 2 weeks or so.
>

It is interesting to see the comments to the blog post.  But there has 
not been many "interesting conversations", yet.  There appears to be two 
types of "commentors".  One, those who have very general comments and 
also comments on most of the other blogs in a general way.  They seem to 
have neutral comments, e.g. "it seems interesting".  Or comments for the 
sake of commenting?

Second, are those who seem opposed to the idea and have long post (not 
sure if these long post say much).  But these users "hide" there 
identity, so it is hard to take them serious, was it a drunken rant that 
they were not afraid to post because it had little to no repercussions? 
  Is it worth investing time rebutting their comments?  We have seen on 
this mailing-list a lot of effort can spent with little progress of 
understanding.

I would love to contribute to the conversation, because I agree this 
seems like a good forum to get some interest.  But, I don't know if I 
can invest the time to clearly state my case why I think MyHDL is great 
and explain how my returns from my investment are huge.  I think it will 
drive me crazy not being able to allocate the time and only contribute 
small comments (but this hasn't stopped me in the past, doh).

I look forward to future post and hopefully a following from your 
involvement with the site.  It looks like the first post is generating a 
few comments.

Best Regards,
Chris

Re: [myhdl-list] MyHDL : The Case for a Better HDL

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

On 09/07/2012 03:14 AM, Christopher Felton wrote:
> Jan has posted an interesting blog post
> "MyHDL : The Case for a Better HDL"
> http://bit.ly/ToK6xg at the All Programmable
> Planet, http://www.programmableplanet.com/.
>
> Be sure and check out the post and contribute
> to the conversation.

Yes, I have been invited by Max Maxfield to become a blogger
on that site. I was looking for a good forum to tell
"the MyHDL story" for some time, and this looks ideal. It
should give us visibility and spur some interesting
discussions :-)

I'll try to blog every 2 weeks or so.

-- 
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 : The Case for a Better HDL

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

Jan has posted an interesting blog post
"MyHDL : The Case for a Better HDL"
http://bit.ly/ToK6xg at the All Programmable
Planet, http://www.programmableplanet.com/.

Be sure and check out the post and contribute
to the conversation.

Regards,
Chris

Re: [myhdl-list] Plans for 0.8 Release

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

On 8/29/12 7:59 AM, Norbo wrote:
> Am 29.08.2012, 04:04 Uhr, schrieb Christopher Felton
> <chr...@gm...>:
>
>> I am curious if there are any thoughts on a 0.8 target
>> release date.  Are there *items* that are targeted for
>> 0.8 but not yet implemented?
>
>
> i was trying to implement a quite simple enhancment which concerns the
> usage of list or dicts that contain only constant
> ints or longs in conversion.
>

 From my perspective that's not be a bad addition but
I don't know how gnarly it is to add the enhancement.
A MEP should be written for the new feature.

I was thinking there have been quite a few new features
added to 0.8 to date.

New items in 0.8:
    * modbv
    * signal optimization (speed enhancements)
    * benchmarking
    * modelsim vpi
    * VCD timescale
    * document updates
    * MEP 108
    * Trace list of signals in VCD
    * always_seq

The branch is approaching 200 change sets.

Possible items for 0.9:
    * MEP107
    * Initial value support / Pre-init RAM
    * fxintbv
    * <others I am unaware of>

The list for 0.9 are items I have been involved with.
I am sure there are others I am not aware of.

The push for a release is somewhat selfish.  I am using
quite a bit of features from the 0.8-dev branch.  And
it would be nice to have a release I can point to for
my development work.

Regards,
Chris

Re: [myhdl-list] Plans for 0.8 Release

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

Am 29.08.2012, 04:04 Uhr, schrieb Christopher Felton  
<chr...@gm...>:

> I am curious if there are any thoughts on a 0.8 target
> release date.  Are there *items* that are targeted for
> 0.8 but not yet implemented?


i was trying to implement a quite simple enhancment which concerns the  
usage of list or dicts that contain only constant
ints or longs in conversion.

It is known thhat the code below works in simulation.
So the enhancment would be that the constants are also inserted in  
converted code if the content of the list or dict is a int or long value.
this would only be for lists with ints or dictionarys with ints,or longs.

tuple of int,
list of bool and
list of intbvs should stay untouched since they are used for other  
purposes.

Being able to use this for converted code also is nice i think.

Code example to show usage:

   CONSTLIST=[3,2,6]
   CONSTDICT={'Opcode_and':1,'Opcode_plus':3}

   def unit_Constout(i_data,o_outvalue):

     @always_comb
     def comb_logic():
       if i_data==CONSTDICT['Opcode_and']: #CONSTLIST[0]:
           o_outvalue.next=0
       elif i_data==CONSTDICT['Opcode_plus']:
	  o_outvalue.next=0
       else:
         o_outvalue.next=1

     return instances()