myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Bug in generated code?

[Tom D. <TD...@Di...>]

Thanks for the education. I would have to say I have been coding with MyHDL
like a "Verilog die-hard". I have been resizing myself never thinking MyHDL
might do that for me.

One question, does MyHDL produce an error in simulation if (c + d) > 255?


On Thu, Jan 17, 2013 at 4:23 PM, Thomas Heller <th...@ct...> wrote:

> Am 17.01.2013 17:26, schrieb Tom Dillon:
> > Hi,
> >
> > This is interesting but I don't think it would be a bug. I am not sure
> > the MyHDL specs call for automatic size conversions.
>
> I'd say it is a bug, because the generated VHDL code behaves differently
> than the MyHDL simulation.
>
> Also, IMO it disagrees stronly with the spirit of Jan's article:
>
> http://www.jandecaluwe.com/hdldesign/counting.html
>
> which says:
>
> <quote>
> The convertor will generate the required sign extensions, resizings and
> type castings. It therefore automates this tedious and error-prone
> bookkeeping task for you.
> <quote/>
>
> Thomas
>
> >
> >
> > On Wed, Jan 16, 2013 at 1:26 PM, Thomas Heller <th...@ct...
> > <mailto:th...@ct...>> wrote:
> >
> >     I believe I have found a bug in the code generator.
> >
> >     Here is the MyHDL code:
> >
> >           rx = Signal(intbv(0, min=-1024, max=1024)
> >           a = Signal(intbv(0, min=0, max=256)
> >           b = Signal(intbv(0, min=0, max=256)
> >           c = Signal(intbv(0, min=0, max=256)
> >           d = Signal(intbv(0, min=0, max=256)
> >
> >
> >           rx.next = a + b - (c + d)
> >
> >     and this is the generated VHDL code:
> >
> >           a: in unsigned(7 downto 0);
> >           b: in unsigned(7 downto 0);
> >           c: in unsigned(7 downto 0);
> >           d: in unsigned(7 downto 0);
> >
> >           signal rx: signed (9 downto 0);
> >
> >           rx <= signed((resize(a, 10) + b) - (c + d));
> >
> >     If I understand the VHDL code correctly, there is data
> >     lost in the (c + d) operation since the intermediate result has only
> >     8 bits instead of the required 10 bits.
> >
> >
> > I am most used to Verilog, but if I were coding this in Verilog and
> > didn't wanted the c+d to grow, I would of forced them into an
> > intermediate signal that was one bit bigger and then performed the
> > addition to guarantee the carry was not lost.
> >
> > I am not sure if this is any different in VHDL.
> >
> > Also, I would not think that MyHDL would guarantee the growth either.
> > There are cases where you don't want it as well.
> >
> > If I were coding this, I would also grow them before the addition if you
> > wanted the carry to count.
> >
> > Others may have a better grasp of what MyHDL is supposed to do for this
> > case.
> >
> > Yours,
> >
> > Tom Dillon
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> > MVPs and experts. ON SALE this month only -- learn more at:
> > http://p.sf.net/sfu/learnmore_122712
> >
> >
> >
> > _______________________________________________
> > myhdl-list mailing list
> > myh...@li...
> > https://lists.sourceforge.net/lists/listinfo/myhdl-list
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Bug in generated code?

[Thomas H. <th...@ct...>]

Am 17.01.2013 17:26, schrieb Tom Dillon:
> Hi,
>
> This is interesting but I don't think it would be a bug. I am not sure
> the MyHDL specs call for automatic size conversions.

I'd say it is a bug, because the generated VHDL code behaves differently
than the MyHDL simulation.

Also, IMO it disagrees stronly with the spirit of Jan's article:

http://www.jandecaluwe.com/hdldesign/counting.html

which says:

<quote>
The convertor will generate the required sign extensions, resizings and 
type castings. It therefore automates this tedious and error-prone 
bookkeeping task for you.
<quote/>

Thomas

>
>
> On Wed, Jan 16, 2013 at 1:26 PM, Thomas Heller <th...@ct...
> <mailto:th...@ct...>> wrote:
>
>     I believe I have found a bug in the code generator.
>
>     Here is the MyHDL code:
>
>           rx = Signal(intbv(0, min=-1024, max=1024)
>           a = Signal(intbv(0, min=0, max=256)
>           b = Signal(intbv(0, min=0, max=256)
>           c = Signal(intbv(0, min=0, max=256)
>           d = Signal(intbv(0, min=0, max=256)
>
>
>           rx.next = a + b - (c + d)
>
>     and this is the generated VHDL code:
>
>           a: in unsigned(7 downto 0);
>           b: in unsigned(7 downto 0);
>           c: in unsigned(7 downto 0);
>           d: in unsigned(7 downto 0);
>
>           signal rx: signed (9 downto 0);
>
>           rx <= signed((resize(a, 10) + b) - (c + d));
>
>     If I understand the VHDL code correctly, there is data
>     lost in the (c + d) operation since the intermediate result has only
>     8 bits instead of the required 10 bits.
>
>
> I am most used to Verilog, but if I were coding this in Verilog and
> didn't wanted the c+d to grow, I would of forced them into an
> intermediate signal that was one bit bigger and then performed the
> addition to guarantee the carry was not lost.
>
> I am not sure if this is any different in VHDL.
>
> Also, I would not think that MyHDL would guarantee the growth either.
> There are cases where you don't want it as well.
>
> If I were coding this, I would also grow them before the addition if you
> wanted the carry to count.
>
> Others may have a better grasp of what MyHDL is supposed to do for this
> case.
>
> Yours,
>
> Tom Dillon
>
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] VHDL Cosim Initial Thoughts

[Daryl W. <dw...@ou...>]

Thanks again. I cloned the code to my computer. I will push 
the changes once I have the cross-platform C-code completed. 
It works more or less, with the one problem I mentioned. I 
have some ideas for fixing it, just need to find a little 
more time.... 

-Daryl

Re: [myhdl-list] Bug in generated code?

[Tom D. <TD...@Di...>]

Hi,

This is interesting but I don't think it would be a bug. I am not sure the
MyHDL specs call for automatic size conversions.


On Wed, Jan 16, 2013 at 1:26 PM, Thomas Heller <th...@ct...> wrote:

> I believe I have found a bug in the code generator.
>
> Here is the MyHDL code:
>
>      rx = Signal(intbv(0, min=-1024, max=1024)
>      a = Signal(intbv(0, min=0, max=256)
>      b = Signal(intbv(0, min=0, max=256)
>      c = Signal(intbv(0, min=0, max=256)
>      d = Signal(intbv(0, min=0, max=256)
>
>
>      rx.next = a + b - (c + d)
>
> and this is the generated VHDL code:
>
>      a: in unsigned(7 downto 0);
>      b: in unsigned(7 downto 0);
>      c: in unsigned(7 downto 0);
>      d: in unsigned(7 downto 0);
>
>      signal rx: signed (9 downto 0);
>
>      rx <= signed((resize(a, 10) + b) - (c + d));
>
> If I understand the VHDL code correctly, there is data
> lost in the (c + d) operation since the intermediate result has only
> 8 bits instead of the required 10 bits.
>

I am most used to Verilog, but if I were coding this in Verilog and didn't
wanted the c+d to grow, I would of forced them into an intermediate signal
that was one bit bigger and then performed the addition to guarantee the
carry was not lost.

I am not sure if this is any different in VHDL.

Also, I would not think that MyHDL would guarantee the growth either. There
are cases where you don't want it as well.

If I were coding this, I would also grow them before the addition if you
wanted the carry to count.

Others may have a better grasp of what MyHDL is supposed to do for this
case.

Yours,

Tom Dillon

Re: [myhdl-list] Bug in generated code?

[Thomas H. <th...@ct...>]

Am 16.01.2013 20:26, schrieb Thomas Heller:
> I believe I have found a bug in the code generator.
>
[...]
>
> Note that I'm using MyHDL 0.7, have not tried the newer version.

Version 0.8-dev as of yesterday night has the same problem.

Thomas

[myhdl-list] Bug in generated code?

[Thomas H. <th...@ct...>]

I believe I have found a bug in the code generator.

Here is the MyHDL code:

     rx = Signal(intbv(0, min=-1024, max=1024)
     a = Signal(intbv(0, min=0, max=256)
     b = Signal(intbv(0, min=0, max=256)
     c = Signal(intbv(0, min=0, max=256)
     d = Signal(intbv(0, min=0, max=256)


     rx.next = a + b - (c + d)

and this is the generated VHDL code:

     a: in unsigned(7 downto 0);
     b: in unsigned(7 downto 0);
     c: in unsigned(7 downto 0);
     d: in unsigned(7 downto 0);

     signal rx: signed (9 downto 0);

     rx <= signed((resize(a, 10) + b) - (c + d));

If I understand the VHDL code correctly, there is data
lost in the (c + d) operation since the intermediate result has only
8 bits instead of the required 10 bits.

Restructuring the MyHDL code like this:
     rx.next = a + b - c - d
generates this VHDL code:
     rx <= signed(((resize(a, 10) + b) - c) - d);
which looks correct to me.

Note that I'm using MyHDL 0.7, have not tried the newer version.

Thomas

[myhdl-list] check this link out

[David B. <dav...@ya...>]

check this link out 
 
http://tce.cs.tut.fi/screenshots.html
 
I think that this might lead to development of Python for higher level synthesis applications.
 
David Blubaugh
 


--- On Tue, 1/15/13, Jan Coombs <ja...@mu...> wrote:


From: Jan Coombs <ja...@mu...>
Subject: Re: [myhdl-list] Next Python to VHDL generator by using LLVM
To: "General discussions on MyHDL" <myh...@li...>
Date: Tuesday, January 15, 2013, 6:06 PM


On 15/01/13 18:00, Christopher Felton wrote:
    ...
> I completely disagree this is *not* something the MyHDL group 
> should be interested in.    ...

Perhaps David is looking for this link you posted some time ago:

   http://pycpu.wordpress.com/

Which might provide the basis of a more practical python into 
hardware route, but, either way, this has little to do with MyHDL 
development, but, if developed could have a bit to do with MyHDL 
promotion.

Jan Coombs.


------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Next Python to VHDL generator by using LLVM

[David B. <dav...@ya...>]

Yes,
 
That is exactly what i am interested in seeing is MyHDL promotion.  I wonder that since PyPy targets both LLVM and C if it would not be possible to develop LLVM to support PyPy to HDL targeting and optimization??  I might be dreaming here, but LLVM was used in the PyPY project to prevent failure of the project and to mitigate the problem of future changes being made to Python over the next ten years.  Also since we are concerned with the static nature of an HDL, it would not be possible to create a FPGA LLVM IR VM based on Python ??  
 
David
 
 
 
 
 
 
 

--- On Tue, 1/15/13, Jan Coombs <ja...@mu...> wrote:


From: Jan Coombs <ja...@mu...>
Subject: Re: [myhdl-list] Next Python to VHDL generator by using LLVM
To: "General discussions on MyHDL" <myh...@li...>
Date: Tuesday, January 15, 2013, 6:06 PM


On 15/01/13 18:00, Christopher Felton wrote:
    ...
> I completely disagree this is *not* something the MyHDL group 
> should be interested in.    ...

Perhaps David is looking for this link you posted some time ago:

   http://pycpu.wordpress.com/

Which might provide the basis of a more practical python into 
hardware route, but, either way, this has little to do with MyHDL 
development, but, if developed could have a bit to do with MyHDL 
promotion.

Jan Coombs.


------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Next Python to VHDL generator by using LLVM

[Jan L. <jan...@et...>]

Am 15.01.2013 19:43, schrieb Christopher Felton:
>>> On 1/15/2013 11:45 AM, David Blubaugh wrote:
>>>> I was wondering if someone has looked in the use of the LLVM to be able to generate full featured python into synthesizable VHDL with simulation support of course ??
>>>>
>>>> I STRONGLY BELIEVE YOU GUYS NEED TO LOOK AT LLVM for greatly enhancing MyHDL to support a greater domain of the python language to support synthesizable designs and testbench support.
>>> I completely disagree this is *not* something the MyHDL
>>> group should be interested in.  There would be no benefit
>>> for the MyHDL folks to look at this.
>>>
>>> In addition, other than a buzz word you didn't provide
>>> any technical arguments why this would be desirable.
>> The reason as to why this needs to be looked at is that if you want to support higher level functionality of the python language to support synthesizable HDL designs the current method is to to use a subset of the python language.  What I am talking about is the possibility of extending MyHDL capabilities of supporting ALL if not most of the higher level functionality of the python language to support advanced designs in synthesizable HDLs.  Take a look at Trident C programmingl language with LLVM support.  It supported close to 98 percent of C functionality for directed and efficient synthesizable HDL design.
>>
>> Please take a look at the following link:
>>
>> http://trident.sourceforge.net/
>>
>> This is for the C language but I wonder if an equivalent system could not be developed by using python as the central controlling programming language instead of C.  LLVM stands for low level virtual machine language that allows the expression of one language, this case python, to be implemented on an entirely different architecture (FPGAS instead of a von-neumann architecture).
>>
>> Any feedback or questions is more than appreciated !!!
>>
>> David
> I am familiar with trident, have actually used it.  I am
> familiar with LLVM (barely).  The state of trident is that
> it was used for a particular set of cases/experiments.  It
> would be difficult to use it other than experiments and
> investigation.
>
> I don't believe trident has been touched in years.  I am not
> an LLVM expert but I think LLVM fits better if you are trying
> to kludge C-family of code into something rather than something
> like Python.  At one point, I thought Uladen-Swallow Python
> (US-Python) would win out over pypy, well that appears to have
> played out and US-Python was the loser.  I don't know for sure
> but I believe US-Python didn't succeed because of limitations
> in LLVM.  I also (gut guess) don't think LLVM is ideal as
> an intermediate format for representing hardware.
>
> I believe LLVM is great for languages like C/C++ and resulted
> in cleaner C* compilers (e.g. clang).  But I don't think it is
> a cure all fit all.  I am commenting out of my league about this
> C compiler stuff, I only know the little I have read here and
> there.
>
> If someone where really interested in this LLVM -> HDL it
> won't be the MyHDL folks.  The MyHDL folks are interested
> in describing hardware in Python in the manner Jan D. has
> outlined.  Which may or many not include some HLS as it
> grows.  If you want a magic Python -> intermediate
> format -> hardware, I don't think it overlaps with the
> efforts/goals of MyHDL.  What you would want to do is get
> your LLVM->HDL working (use the trident framework, which
> by the way is in java) and when someone completes the
> Python->LLVM you will be set, but again, I don't think it
> is something that is of interest to the majority of MyHDL users.
>
> I believe, if MyHDL incorporates HLS it will be in the same
> elaboration/generator (HDL) description as exists now.  I
> believe this really fits what you would want for hardware
> description.  Instead of trying to convert a ton of Python
> code, ugh that would be a mess with or without an LLVM.
> I think you are under estimating what a Python to LLVM
> and LLVM to HDL would take and overestimating what LLVM
> provides.

Hi all,

I would like to quickly comment:

I agree that LLVM is not a solution for MyHDL. Its front end, which 
would be the interesting part, offers little more value to MyHDL than 
the introspection, bytecode compilation and builtin parsing capabilities 
that Python itself already got out of the box. In general, LLVM solves a 
problem for C/C++ that does not exist in Python. I am probably "leaning 
way too much out of the window" right now :-).

Furthermore, the value of HLS starting from Python is not that big at 
the moment. For the next time HLS will probably need a statically typed 
input language. After all, hardware is static and the stuff that is 
allowed inside the MyHDL generators is pretty much static, too.

Regards,
Jan

Re: [myhdl-list] Next Python to VHDL generator by using LLVM

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

On 15/01/13 18:00, Christopher Felton wrote:
    ...
> I completely disagree this is *not* something the MyHDL group 
> should be interested in.    ...

Perhaps David is looking for this link you posted some time ago:

   http://pycpu.wordpress.com/

Which might provide the basis of a more practical python into 
hardware route, but, either way, this has little to do with MyHDL 
development, but, if developed could have a bit to do with MyHDL 
promotion.

Jan Coombs.

Re: [myhdl-list] Next Python to VHDL generator by using LLVM

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

>>
>> On 1/15/2013 11:45 AM, David Blubaugh wrote:
>>>
>>> To All,
>>>
>>> I was wondering if someone has looked in the use of the LLVM to be able to generate full featured python into synthesizable VHDL with simulation support of course ??
>>>
>>> I STRONGLY BELIEVE YOU GUYS NEED TO LOOK AT LLVM for greatly enhancing MyHDL to support a greater domain of the python language to support synthesizable designs and testbench support.
>>>
>>> David Blubaugh
>>>
>>
>> I completely disagree this is *not* something the MyHDL
>> group should be interested in.  There would be no benefit
>> for the MyHDL folks to look at this.
>>
>> In addition, other than a buzz word you didn't provide
>> any technical arguments why this would be desirable.
>>
>> Regards,
>> Chris
>>
>
> The reason as to why this needs to be looked at is that if you want to support higher level functionality of the python language to support synthesizable HDL designs the current method is to to use a subset of the python language.  What I am talking about is the possibility of extending MyHDL capabilities of supporting ALL if not most of the higher level functionality of the python language to support advanced designs in synthesizable HDLs.  Take a look at Trident C programmingl language with LLVM support.  It supported close to 98 percent of C functionality for directed and efficient synthesizable HDL design.
>
> Please take a look at the following link:
>
> http://trident.sourceforge.net/
>
> This is for the C language but I wonder if an equivalent system could not be developed by using python as the central controlling programming language instead of C.  LLVM stands for low level virtual machine language that allows the expression of one language, this case python, to be implemented on an entirely different architecture (FPGAS instead of a von-neumann architecture).
>
> Any feedback or questions is more than appreciated !!!
>
> David


I am familiar with trident, have actually used it.  I am
familiar with LLVM (barely).  The state of trident is that
it was used for a particular set of cases/experiments.  It
would be difficult to use it other than experiments and
investigation.

I don't believe trident has been touched in years.  I am not
an LLVM expert but I think LLVM fits better if you are trying
to kludge C-family of code into something rather than something
like Python.  At one point, I thought Uladen-Swallow Python
(US-Python) would win out over pypy, well that appears to have
played out and US-Python was the loser.  I don't know for sure
but I believe US-Python didn't succeed because of limitations
in LLVM.  I also (gut guess) don't think LLVM is ideal as
an intermediate format for representing hardware.

I believe LLVM is great for languages like C/C++ and resulted
in cleaner C* compilers (e.g. clang).  But I don't think it is
a cure all fit all.  I am commenting out of my league about this
C compiler stuff, I only know the little I have read here and
there.

If someone where really interested in this LLVM -> HDL it
won't be the MyHDL folks.  The MyHDL folks are interested
in describing hardware in Python in the manner Jan D. has
outlined.  Which may or many not include some HLS as it
grows.  If you want a magic Python -> intermediate
format -> hardware, I don't think it overlaps with the
efforts/goals of MyHDL.  What you would want to do is get
your LLVM->HDL working (use the trident framework, which
by the way is in java) and when someone completes the
Python->LLVM you will be set, but again, I don't think it
is something that is of interest to the majority of MyHDL users.

I believe, if MyHDL incorporates HLS it will be in the same
elaboration/generator (HDL) description as exists now.  I
believe this really fits what you would want for hardware
description.  Instead of trying to convert a ton of Python
code, ugh that would be a mess with or without an LLVM.
I think you are under estimating what a Python to LLVM
and LLVM to HDL would take and overestimating what LLVM
provides.

Regards,
Chris

Re: [myhdl-list] Next Python to VHDL generator by using LLVM

[David B. <dav...@ya...>]

The reason as to why this needs to be looked at is that if you want to support higher level functionality of the python language to support synthesizable HDL designs the current method is to to use a subset of the python language.  What I am talking about is the possibility of extending MyHDL capabilities of supporting ALL if not most of the higher level functionality of the python language to support advanced designs in synthesizable HDLs.  Take a look at Trident C programmingl language with LLVM support.  It supported close to 98 percent of C functionality for directed and efficient synthesizable HDL design.  
 
Please take a look at the following link:
 
http://trident.sourceforge.net/
 
This is for the C language but I wonder if an equivalent system could not be developed by using python as the central controlling programming language instead of C.  LLVM stands for low level virtual machine language that allows the expression of one language, this case python, to be implemented on an entirely different architecture (FPGAS instead of a von-neumann architecture).  
 
Any feedback or questions is more than appreciated !!!
 
David
 


--- On Tue, 1/15/13, Christopher Felton <chr...@gm...> wrote:


From: Christopher Felton <chr...@gm...>
Subject: Re: [myhdl-list] Next Python to VHDL generator by using LLVM
To: myh...@li...
Date: Tuesday, January 15, 2013, 1:00 PM


On 1/15/2013 11:45 AM, David Blubaugh wrote:
>
>
>
>
>
> To All,
>
> I was wondering if someone has looked in the use of the LLVM to be able to generate full featured python into synthesizable VHDL with simulation support of course ??
>
> I STRONGLY BELIEVE YOU GUYS NEED TO LOOK AT LLVM for greatly enhancing MyHDL to support a greater domain of the python language to support synthesizable designs and testbench support.
>
> David Blubaugh
>
>
>
>
>

I completely disagree this is *not* something the MyHDL
group should be interested in.  There would be no benefit
for the MyHDL folks to look at this.

In addition, other than a buzz word you didn't provide
any technical arguments why this would be desirable.

Regards,
Chris



------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Next Python to VHDL generator by using LLVM

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

On 1/15/2013 11:45 AM, David Blubaugh wrote:
>
>
>
>
>
> To All,
>
> I was wondering if someone has looked in the use of the LLVM to be able to generate full featured python into synthesizable VHDL with simulation support of course ??
>
> I STRONGLY BELIEVE YOU GUYS NEED TO LOOK AT LLVM for greatly enhancing MyHDL to support a greater domain of the python language to support synthesizable designs and testbench support.
>
> David Blubaugh
>
>
>
>
>

I completely disagree this is *not* something the MyHDL
group should be interested in.  There would be no benefit
for the MyHDL folks to look at this.

In addition, other than a buzz word you didn't provide
any technical arguments why this would be desirable.

Regards,
Chris

[myhdl-list] Next Python to VHDL generator by using LLVM

[David B. <dav...@ya...>]

To All,
 
I was wondering if someone has looked in the use of the LLVM to be able to generate full featured python into synthesizable VHDL with simulation support of course ??  
 
I STRONGLY BELIEVE YOU GUYS NEED TO LOOK AT LLVM for greatly enhancing MyHDL to support a greater domain of the python language to support synthesizable designs and testbench support.  
 
David Blubaugh
 
 

Re: [myhdl-list] synchronous register with asynchronous reset

[Ben <ben...@gm...>]

Hi Martin,

On Tue, Jan 15, 2013 at 12:54 AM, Martin Schoeberl <ma...@jo...> wrote:
> Why isn't 0.8 put out as a stable version?
> The official stable version (0.7) is quite old.

I can help you over there, at least with this answer from beginning of
december, I don't think it changed a lot since then:

http://article.gmane.org/gmane.comp.python.myhdl/2828/

Regards,
Benoît.

Re: [myhdl-list] synchronous register with asynchronous reset

[Martin S. <ma...@jo...>]

Hi Chris,

that looks better. Very good.

This leads to a question I wanted to post later on:
Why isn't 0.8 put out as a stable version?
The official stable version (0.7) is quite old.

Cheers,
Martin

On 13 Jan, 2013, at 6:25, Christopher Felton wrote:

> On 1/12/13 8:28 PM, Martin Schoeberl wrote:
>> Hi Norbo
>> 
>> On 12 Jan, 2013, at 5:11, Norbo wrote:
>> 
>>> Hi Martin
>>> 
>>> the following code does the trick: (notice the rst.posedge in the
>>> sensitivity list)
>> 
>> Thanks, I should have tried this myself as it did the trick:
>> 
>>     @always(clk.posedge, reset.posedge)
>>     def hdl():
>>         if reset == 1:
>>             sig.next = 0
>>         else:
>>             sig.next = not sig
>> 
>>     return hdl
>> 
>> ends in the VHDL code I like:
>> 
>> FOO_HDL: process (clk, reset) is
>> begin
>>     if (reset = '1') then
>>         sig <= '0';
>>     elsif rising_edge(clk) then
>>         sig <= to_std_logic((not to_boolean(sig)));
>>     end if;
>> end process FOO_HDL;
>> 
>> It is now an asynchronous reset and that's what FPGA flip-flops
>> support without using LUT resources.
>> 
>> An asynchronous reset is level sensitive. Therefore, MyHDL code
>> on @always(…, reset.posedge) is a little bit confusing.
>> 
>> <snip>
>> 
>>> But the way i imagine a Flip-Flop with an asynchron reset is that if the
>>> reset is active
>>> then the Flip-Flop gets reset permanently and not only on a particular
>>> edge. For example if
>> 
>> Yes, that's what FPGA FFs support. And you also can have this in ASIC
>> as well. Just a minor notice: your reset signal itself shall be registered
>> and clock synchronous. Releasing the reset shall not violate any
>> 'setup' and 'hold' times.
>> 
>>> Anyway i prefere using a Flip-Flop with a low reset level. And then use a
>> 
>> I don't. Low level reset or negative active signals is history. Positive
>> active feel more natural. But that's just a matter of taste.
>> 
>> <snip>
>> 
> 
> Martin,
> 
> You can also use a new decorator, the @always_seq.  This
> might feel more natural.  It works like the following:
> 
>     def example(clock, reset, sig):
>         @always_seq(clock.posedge, reset=reset)
>         def hdl():
>             sig.next = not sig
>         return hdl
> 
>     clock,sig = (Signal(bool(0)), Signal(bool(0)))
>     reset = ResetSignal(bool(0), active=0, async=True)
>     toVHDL(example, clock, reset, sig)
> 
> The following is the VHDL generated:
> 
>     EXAMPLE_HDL: process (clock, reset) is
>     begin
>         if (reset = '0') then
>             sig <= '0';
>         elsif rising_edge(clock) then
>             sig <= stdl((not bool(sig)));
>         end if;
>     end process EXAMPLE_HDL;
> 
> See the MEP write-up for more information,
> http://myhdl.org/doku.php/meps:mep-109
> 
> To use the @always_seq you will have to get the latest
> version from the repository.  The repository code is
> stable and I have been using the 0.8-dev for a long time.
> 
> To get the latest you need to do the following:
> 
>>> hg clone http://hg.myhdl.org/myhdl
>>> hg up -C 0.8-dev  # update to the 0.8-dev development
> 
> 
> Regards,
> Chris
> 
> 
> 
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_123012
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 
> 

Re: [myhdl-list] VHDL Cosim Initial Thoughts

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

On 1/13/13 3:26 PM, Daryl Wasden wrote:
> Christopher Felton <chris.felton <at> gmail.com> writes:
>
>>
>> On 1/8/13 6:30 PM, Daryl Wasden wrote:
>>>>>> Also, I haven't yet figured out how to deal with delays...
>>>>> I am not sure what you are asking or not understanding
>>>>> here?
>>> I see how this works now. I didn't completely understand the
>>> format. Now, I see the protocol structure. The time is sent
>>> first, then any signal changes. Doing the socket-based
>>> cosimulation in verilog was helpful.
>>>
>>> I am still fixing one bug, but the simulation is running
>>> correctly using socket communication on windows. I ran
>>> the test_bin2gray using Icarus. The bug is related to
>>> reusing the same port when moving between tests... If I
>>> get this up and running and fix the bug, then I'll work
>>> on porting it over to Linux/Mac OSX as well.
>>>
>>> -Daryl
>>>
>>>
>>
>> Sounds like you are making good progress.  If you want, we
>> can setup a bitbucket repository and I can test out your
>> changes as well.  I don't have a windows system right now
>> but I can test it out on a linux.
>>
>> Regards,
>> Chris
>>
>>
>
> Sure, that would be great. My free time is going away quickly,
> but I should be able to put in at least a few hours every week.
> With where I am now, that should still get things done
> relatively fast. Currently, the simulation runs okay, but
> if you try to execute two simulations quickly, there can be
> a problem because ports don't register as closed immediately
> after you close them. Also, it only works on localhost
> right now because of how it is designed... This wouldn't be
> too difficult to change, but it would require the user to
> start the process on the server manually prior to starting
> the MyHDL simulation which deviates from the current
> implementation, but may be useful for me later. So, I'll
> look into that as well at some point.
>
> I've never used bit bucket before, but I will look into it.
> Should I email you personally when I've got everything up or
> just keep posting to the mailing list? Also, should I put
> the 0.8dev code up there and contribute to it or just
> include the subclassed code and the (modified) test code?

You can create a repository and push your changes or I
created a repository on bitbucket.  If you want to use
the clone I created:

https://bitbucket.org/cfelton/myhdl_vhdl_cosim/overview

The following should get you started.

    >> hg clone https://bitbucket.org/cfelton/myhdl_vhdl_cosim
       <local_path>
    # Add a <user>@bitbucket.org if you want to push later
    # after cloned the bitbucket clone of myhdl, push your changes
    >> cd <to your current working >
    >> hg commit # commit any modifications
    >> hg push <path to your local clone, first command above>

You will need to create a bitbucket user and then you can push,
bitbucket is essentially the same as github just mercurial
based and not git.

The conversation can continue on this mailing-list unless
anyone else objects.  The feedback from other users/devs
can be very useful.

>
> The one problem is that this method (or any method other than
> the one provided in the present version) requires a change
> to _Simulation.py as well because the Cosimulation pipes are
> closed by the Simulation class methods manually and not by a
> call to the Cosimulation class methods. This would be easily
> changed, but I'm not sure how to suggest such a patch. I
> looked on the website and it says to send ideas to the mailing
> list for discussion. I put it in an earlier reply on this
> thread, but maybe I should make a new thread and put it there?

Yes, a new thread with this specific issue.

>
> I'm sorry for all my questions, I'm trying to figure out the
> proper etiquette for contributing to the project still. The
> modification would not change any existing behavior, it would
> just make it possible to subclass the Cosimulation object and
> use other methods for inter-process communication. At some
> point, I think I'll look into putting windows pipes.

Questions are perfect!  Jan D. has outlined how to communicate
changes and commit bundles (patches).

http://www.myhdl.org/doku.php/dev:patches

>
> Also, the class CosimulationWithSockets is based heavily on
> the original Cosimulation class with the only changes being
> initialization, communication, and clean up of the sockets
> (instead of the pipes) and the use of the multiprocessing
> module to generate a child process instead of os.fork().
> I should include the original license at the top of the
> file in this case, correct?
>
> Thanks again, I really appreciate you helping me to
> understand these things. I know that you are busy, too...
>
> -Daryl
>

No problem, these two topics are asked once in a while,
VHDL cosimulation and windows cosimulation.  I think
their are others that might be interested as well but
probably don't have the cycles right now.

Regards,
Chris

Re: [myhdl-list] VHDL Cosim Initial Thoughts

[Daryl W. <dw...@ou...>]

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

> 
> On 1/8/13 6:30 PM, Daryl Wasden wrote:
> >>>> Also, I haven't yet figured out how to deal with delays...
> >>> I am not sure what you are asking or not understanding
> >>> here?
> > I see how this works now. I didn't completely understand the
> > format. Now, I see the protocol structure. The time is sent
> > first, then any signal changes. Doing the socket-based
> > cosimulation in verilog was helpful.
> >
> > I am still fixing one bug, but the simulation is running
> > correctly using socket communication on windows. I ran
> > the test_bin2gray using Icarus. The bug is related to
> > reusing the same port when moving between tests... If I
> > get this up and running and fix the bug, then I'll work
> > on porting it over to Linux/Mac OSX as well.
> >
> > -Daryl
> >
> >
> 
> Sounds like you are making good progress.  If you want, we
> can setup a bitbucket repository and I can test out your
> changes as well.  I don't have a windows system right now
> but I can test it out on a linux.
> 
> Regards,
> Chris
> 
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122912
> 

Sure, that would be great. My free time is going away quickly, 
but I should be able to put in at least a few hours every week. 
With where I am now, that should still get things done
relatively fast. Currently, the simulation runs okay, but 
if you try to execute two simulations quickly, there can be
a problem because ports don't register as closed immediately
after you close them. Also, it only works on localhost
right now because of how it is designed... This wouldn't be
too difficult to change, but it would require the user to
start the process on the server manually prior to starting
the MyHDL simulation which deviates from the current 
implementation, but may be useful for me later. So, I'll 
look into that as well at some point. 

I've never used bit bucket before, but I will look into it. 
Should I email you personally when I've got everything up or 
just keep posting to the mailing list? Also, should I put 
the 0.8dev code up there and contribute to it or just 
include the subclassed code and the (modified) test code?

The one problem is that this method (or any method other than 
the one provided in the present version) requires a change 
to _Simulation.py as well because the Cosimulation pipes are 
closed by the Simulation class methods manually and not by a 
call to the Cosimulation class methods. This would be easily 
changed, but I'm not sure how to suggest such a patch. I 
looked on the website and it says to send ideas to the mailing 
list for discussion. I put it in an earlier reply on this 
thread, but maybe I should make a new thread and put it there? 

I'm sorry for all my questions, I'm trying to figure out the 
proper etiquette for contributing to the project still. The 
modification would not change any existing behavior, it would 
just make it possible to subclass the Cosimulation object and 
use other methods for inter-process communication. At some 
point, I think I'll look into putting windows pipes. 

Also, the class CosimulationWithSockets is based heavily on 
the original Cosimulation class with the only changes being 
initialization, communication, and clean up of the sockets 
(instead of the pipes) and the use of the multiprocessing
module to generate a child process instead of os.fork().
I should include the original license at the top of the
file in this case, correct? 

Thanks again, I really appreciate you helping me to 
understand these things. I know that you are busy, too... 

-Daryl

Re: [myhdl-list] synchronous register with asynchronous reset

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

On 1/12/13 8:28 PM, Martin Schoeberl wrote:
> Hi Norbo
>
> On 12 Jan, 2013, at 5:11, Norbo wrote:
>
>> Hi Martin
>>
>> the following code does the trick: (notice the rst.posedge in the
>> sensitivity list)
>
> Thanks, I should have tried this myself as it did the trick:
>
>      @always(clk.posedge, reset.posedge)
>      def hdl():
>          if reset == 1:
>              sig.next = 0
>          else:
>              sig.next = not sig
>
>      return hdl
>
> ends in the VHDL code I like:
>
> FOO_HDL: process (clk, reset) is
> begin
>      if (reset = '1') then
>          sig <= '0';
>      elsif rising_edge(clk) then
>          sig <= to_std_logic((not to_boolean(sig)));
>      end if;
> end process FOO_HDL;
>
> It is now an asynchronous reset and that's what FPGA flip-flops
> support without using LUT resources.
>
> An asynchronous reset is level sensitive. Therefore, MyHDL code
> on @always(…, reset.posedge) is a little bit confusing.
>
> <snip>
>
>> But the way i imagine a Flip-Flop with an asynchron reset is that if the
>> reset is active
>> then the Flip-Flop gets reset permanently and not only on a particular
>> edge. For example if
>
> Yes, that's what FPGA FFs support. And you also can have this in ASIC
> as well. Just a minor notice: your reset signal itself shall be registered
> and clock synchronous. Releasing the reset shall not violate any
> 'setup' and 'hold' times.
>
>> Anyway i prefere using a Flip-Flop with a low reset level. And then use a
>
> I don't. Low level reset or negative active signals is history. Positive
> active feel more natural. But that's just a matter of taste.
>
> <snip>
>

Martin,

You can also use a new decorator, the @always_seq.  This
might feel more natural.  It works like the following:

     def example(clock, reset, sig):
         @always_seq(clock.posedge, reset=reset)
         def hdl():
             sig.next = not sig
         return hdl

     clock,sig = (Signal(bool(0)), Signal(bool(0)))
     reset = ResetSignal(bool(0), active=0, async=True)
     toVHDL(example, clock, reset, sig)

The following is the VHDL generated:

     EXAMPLE_HDL: process (clock, reset) is
     begin
         if (reset = '0') then
             sig <= '0';
         elsif rising_edge(clock) then
             sig <= stdl((not bool(sig)));
         end if;
     end process EXAMPLE_HDL;

See the MEP write-up for more information,
http://myhdl.org/doku.php/meps:mep-109

To use the @always_seq you will have to get the latest
version from the repository.  The repository code is
stable and I have been using the 0.8-dev for a long time.

To get the latest you need to do the following:

    >> hg clone http://hg.myhdl.org/myhdl
    >> hg up -C 0.8-dev  # update to the 0.8-dev development


Regards,
Chris

Re: [myhdl-list] synchronous register with asynchronous reset

[Martin S. <ma...@jo...>]

Hi Norbo

On 12 Jan, 2013, at 5:11, Norbo wrote:

> Hi Martin
> 
> the following code does the trick: (notice the rst.posedge in the  
> sensitivity list)

Thanks, I should have tried this myself as it did the trick:

    @always(clk.posedge, reset.posedge)
    def hdl():
        if reset == 1:
            sig.next = 0
        else:
            sig.next = not sig

    return hdl

ends in the VHDL code I like:

FOO_HDL: process (clk, reset) is
begin
    if (reset = '1') then
        sig <= '0';
    elsif rising_edge(clk) then
        sig <= to_std_logic((not to_boolean(sig)));
    end if;
end process FOO_HDL;

It is now an asynchronous reset and that's what FPGA flip-flops
support without using LUT resources.

An asynchronous reset is level sensitive. Therefore, MyHDL code
on @always(…, reset.posedge) is a little bit confusing.

<snip>

> But the way i imagine a Flip-Flop with an asynchron reset is that if the  
> reset is active
> then the Flip-Flop gets reset permanently and not only on a particular  
> edge. For example if

Yes, that's what FPGA FFs support. And you also can have this in ASIC
as well. Just a minor notice: your reset signal itself shall be registered
and clock synchronous. Releasing the reset shall not violate any
'setup' and 'hold' times.

> Anyway i prefere using a Flip-Flop with a low reset level. And then use a  

I don't. Low level reset or negative active signals is history. Positive
active feel more natural. But that's just a matter of taste.

<snip>

Cheers,
Martin

Re: [myhdl-list] synchronous register with asynchronous reset

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

On 1/12/13 5:20 PM, Norbo wrote:
> Am 12.01.2013, 23:01 Uhr, schrieb Christopher Felton
> <chr...@gm...>:
>
>> <snip>
>>>
>>> Anyway i am also not quite happy with the fact that the code suggestes
>>> that the reset is
>>> edge sensitive (which is actually true from a Simulation standpoint).
>>> But the way i imagine a Flip-Flop with an asynchron reset is that if the
>>> reset is active
>>> then the Flip-Flop gets reset permanently and not only on a particular
>>> edge. For example if
>>> the Flip-Flop is in reset state and gets flipped over by cosmic
>>> radiation
>>> /noise than no actuall
>>> edge of the reset would be needed to flip it back to the reset state,
>>> its
>>> really more level sensitive i think.
>>>
>>
>> I don't think the example is a fair / correct example
>> because: The event that occurs happens at a level that
>> is not being modeled.  The cosmic ray has to effect
>> the internal structure of the transistor without effecting
>> the "signal" (if it effected the signal, the transition
>> event would be detected and behavior would match).
>
> yep, thats right the example is quite far-fetched, and has nothing to do
> with the model.
>
> But another case came to my mind which expresses better what i meant.
>
> Whats about the case when simulation starts,( hardware equivalent ->
> voltage is turned on).
> And the async-reset input of the flip-flop is tied to ground, and the
> flip-flop has low level active reset input.
> In this case no negedge occurs at the reset input, but the flip-flop would
> still put out its reset value, because it is
> in its reset state.
> Which for makes it more level sensitve than edge sensitive. just a thought.
>
> greetings
> Norbo
>

Yes, this was the case I eluded to in the other response,
I called it POR (power-on-reset).  In this case the initial
value is handled by the value set when you declare
(instantiate) the Signal.

    sig = Signal(bool(0))

In this case the initial value is 0 and not dependent on an
event.  I think this modeling is correct, because the power
on case (or time-zero, T0) is a special case and could be
different phenomena in the real-world.

Regards,
Chris

Re: [myhdl-list] synchronous register with asynchronous reset

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

Am 12.01.2013, 23:01 Uhr, schrieb Christopher Felton  
<chr...@gm...>:

> <snip>
>>
>> Anyway i am also not quite happy with the fact that the code suggestes
>> that the reset is
>> edge sensitive (which is actually true from a Simulation standpoint).
>> But the way i imagine a Flip-Flop with an asynchron reset is that if the
>> reset is active
>> then the Flip-Flop gets reset permanently and not only on a particular
>> edge. For example if
>> the Flip-Flop is in reset state and gets flipped over by cosmic  
>> radiation
>> /noise than no actuall
>> edge of the reset would be needed to flip it back to the reset state,  
>> its
>> really more level sensitive i think.
>>
>
> I don't think the example is a fair / correct example
> because: The event that occurs happens at a level that
> is not being modeled.  The cosmic ray has to effect
> the internal structure of the transistor without effecting
> the "signal" (if it effected the signal, the transition
> event would be detected and behavior would match).

yep, thats right the example is quite far-fetched, and has nothing to do  
with the model.

But another case came to my mind which expresses better what i meant.

Whats about the case when simulation starts,( hardware equivalent ->  
voltage is turned on).
And the async-reset input of the flip-flop is tied to ground, and the  
flip-flop has low level active reset input.
In this case no negedge occurs at the reset input, but the flip-flop would  
still put out its reset value, because it is
in its reset state.
Which for makes it more level sensitve than edge sensitive. just a thought.

greetings
Norbo

Re: [myhdl-list] synchronous register with asynchronous reset

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

<snip>
>
> Anyway i am also not quite happy with the fact that the code suggestes
> that the reset is
> edge sensitive (which is actually true from a Simulation standpoint).
> But the way i imagine a Flip-Flop with an asynchron reset is that if the
> reset is active
> then the Flip-Flop gets reset permanently and not only on a particular
> edge. For example if
> the Flip-Flop is in reset state and gets flipped over by cosmic radiation
> /noise than no actuall
> edge of the reset would be needed to flip it back to the reset state, its
> really more level sensitive i think.
>

I don't think the example is a fair / correct example
because: The event that occurs happens at a level that
is not being modeled.  The cosmic ray has to effect
the internal structure of the transistor without effecting
the "signal" (if it effected the signal, the transition
event would be detected and behavior would match).

At this level, we are not modeling the particulars of
the transistor internals.  I think the reset.posedge
effectively captures the behavior.  VHDL simply assumes
reset.posedge and reset.negedge and the process body
has to differentiate.  MyHDL you specify the actual
event so you do not need to be redundant in the generator
body and simulation is more efficient.

Regards,
Chris

Re: [myhdl-list] synchronous register with asynchronous reset

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

<snip>
>
> However, that's not what I really want. There shall be no falling_edge on reset.
> I would like to write some MyHDL code to generate the 'standard' pattern in VHDL:
>
>      if (reset = '1') then
>          sig <= '0';
>      elsif rising_edge(clk) then
>          sig <= to_std_logic((not to_boolean(sig)));
>      end if;
>
> Sorry, if this is a too rival question and I should have found the answer somewhere else.
>
> Cheers,
> Martin
>

As Norbo indicated what you want to do is:

     def conversion_example(clock, reset, sig):
         @always(clock.posedge, reset.posedge)
         def hdl():
             if reset:
                 sig.next = 0
             else:
                 sig.next = not sig
         return hdl

     clock,reset,sig = [Signal(bool(0) for ii in range(3)]
     toVHDL(conversion_example, clock, reset, sig)

Here is the converted code from the above example
(just the process portion).

     CONVERSION_EXAMPLE_HDL: process (clock, reset) is
     begin
         if bool(reset) then
             sig <= '0';
         elsif rising_edge(clock) then
             sig <= stdl((not bool(sig)));
         end if;
     end process CONVERSION_EXAMPLE_HDL;

Here is my take on an explanation.  The VHDL syntax,
essentially, says on any signal event in the sensitivity
list execute the process body.  The MyHDL syntax does
not assume all events so you have to specify what
events trigger the process/generator (generator is the
python terminology).

The reset.posedge covers all cases because we are talking
about binary signals.  The only way the reset can get
to a '1' is by transitioning, hence posedge.  The one
exception is at T0 and this might be similar to a
POR reset condition where the reset value is active and
nothing causes a transition.  In MyHDL this is covered
by the initial value in the Signal.  VHDL works the
same, it requires and event on the signal (one of the
signals in the sensitivity list) before executing the
process body and the T0 value can be controlled by
initializing the signal.  I think the reset.posedge
is valid syntax/description.

Example with prints and a simple simulation:

     def conversion_example(clock, reset, sig):
         @always(clock.posedge, reset.posedge)
         def hdl():
             print('%8d:       clock %d reset %d sig %d' % (
                   now(), clock, reset, sig))
             if reset:
                 sig.next = 0
             else:
                 sig.next = not sig
             print('%8d: next: clock %d reset %d sig %d' % (
                   now(), clock.next, reset.next, sig.next))
         return hdl

     clock,reset,sig = [Signal(bool(0)) for ii in range(3)]
     tb_dut = conversion_example(clock, reset, sig)
     @instance
     def tb_stimulus():
         print('%8d: start simulation' % (now()))
         yield delay(20)
         reset.next = True
         yield delay(20)
         reset.next = False
         yield delay(20)
         clock.next = True
         yield delay(20)
         clock.next = False
         yield delay(20)
         print('%8d: send simulation' % (now()))
         raise StopSimulation
     Simulation((tb_dut, tb_stimulus)).run()

Here is the output from the above simulation:

        0: start simulation
       20:       clock 0 reset 1 sig 0
       20: next: clock 0 reset 1 sig 0
       60:       clock 1 reset 0 sig 0
       60: next: clock 1 reset 0 sig 1
      100: send simulation


Regards,
Chris

Re: [myhdl-list] [PATCH] timezone in date in emitting HDL comment

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

On 1/8/13 8:08 PM, KISHIMOTO, Makoto wrote:
> Hello,
>
> I propose patch to print timezone in date in emitting HDL comment.


I think, in general this is a reasonable addition.  We
might want to formalize it a little and add a function
attribute for the time format (similar to the header
message).  If it is decided the common strftime format
can be used, the proposed can be used as the default
and add a function attribute so it can be customized.

    toVerilog.strftime = "%H"
    toVHDL.strftime = "%H"

I don't know if we want a limit on the number of
function attributes for customizing the conversion.
Currently, the following exist:

    toV*.name
    toV*.header
    toV*.no_myhdl_header
    toV*.timescale

Additional toVHDL attributes
    toVHDL.architecture
    toVHDL.component_declarations
    toVHDL.library
    toVHDL.no_myhdl_package

(some verilog attributes that show up in the 0.8-dev
that I am not familiar with)
    toVerilog.prefer_blocking_assignments
    toVerilog.radix
    toVerilog.standard

And the following have been proposed additions:

    toV*.strftime : Time format to be printed
    toV*.disable_signal_init : don't initialize signals
       when and if initialize signals implemented.
    toV*.enable_list_init : create the code for list
       of signals init.

The last two have been part of the RAM/ROM discussions.
To make it a little more flexible, I propose we use
the strftime pattern proposed as the default and add
a function attribute so it can be customized.

Regards,
Chris

>
> diff -ur myhdl-0.7.ORG/myhdl/conversion/_toVHDL.py myhdl-0.7/myhdl/conversion/_toVHDL.py
> --- myhdl-0.7.ORG/myhdl/conversion/_toVHDL.py	2010-10-15 02:58:48.000000000 +0900
> +++ myhdl-0.7/myhdl/conversion/_toVHDL.py	2013-01-07 16:27:12.000000000 +0900
> @@ -27,7 +27,7 @@
>   import math
>
>   import inspect
> -from datetime import datetime
> +import time
>   #import compiler
>   #from compiler import ast as astNode
>   import ast
> @@ -197,7 +197,7 @@
>   def _writeFileHeader(f, fn):
>       vars = dict(filename=fn,
>                   version=myhdl.__version__,
> -                date=datetime.today().ctime()
> +                date=time.strftime("%a %b %d %H:%M:%S %Y %Z")
>                   )
>       if not toVHDL.no_myhdl_header:
>           print >> f, string.Template(myhdl_header).substitute(vars)
> diff -ur myhdl-0.7.ORG/myhdl/conversion/_toVerilog.py myhdl-0.7/myhdl/conversion/_toVerilog.py
> --- myhdl-0.7.ORG/myhdl/conversion/_toVerilog.py	2010-10-15 02:58:48.000000000 +0900
> +++ myhdl-0.7/myhdl/conversion/_toVerilog.py	2013-01-07 16:27:44.000000000 +0900
> @@ -27,7 +27,7 @@
>   import math
>   import traceback
>   import inspect
> -from datetime import datetime
> +import time
>   import compiler
>   # from compiler import ast as astNode
>   import ast
> @@ -189,7 +189,7 @@
>   def _writeFileHeader(f, fn, ts):
>       vars = dict(filename=fn,
>                   version=myhdl.__version__,
> -                date=datetime.today().ctime()
> +                date=time.strftime("%a %b %d %H:%M:%S %Y %Z")
>                   )
>       if not toVerilog.no_myhdl_header:
>           print >> f, string.Template(myhdl_header).substitute(vars)
>
> ------------------------------------------------------------------------------
> Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
> and much more. Keep your Java skills current with LearnJavaNow -
> 200+ hours of step-by-step video tutorials by Java experts.
> SALE $49.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122612
>