myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Floating Point MEP

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

On 04/26/2012 12:05 AM, Christopher Lozinski wrote:
>
>
> Anyhow MyHDL does need the floating point modules. If I get them up
> and simulating correctly, then I am sure other newbies will start
> using them. Even without the conversion stuff. Anyone interested?

Wait a moment here, let's take a step back. You can perfectly
do event-driven system simulations with MyHDL using Python floats.
As I keep saying, modeling is intended to be completely general.
You can perfectly use floats or other Python types as the underlying
base type in a MyHDL signal.  Today.

A meaningful way of working would be to get the system simulations
to work first, and then later on refine and use user-defined code etc.
to get it to convert, if necessary.

-- 
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] Starting over

[David G. <dsg...@gm...>]

Hey, I'm sorry about that. I thought I was clicking reply--I meant to
keep that off-list.

Please accept my apologies, for you were the unintended recipients.

I was not trying to advertise, and I do not recommend my own solution (yet).

Sorry,
David

On Wed, Apr 25, 2012 at 11:38 PM, Christopher Felton
<chr...@gm...> wrote:
>> On 04/22/2012 01:02 PM, David Greenberg wrote:
>>> Hi Bob,
>>> I wanted to let you know about my own solution to this problem, a
>>> language embedded in Clojure called Piplin. I initially sought to use
>>> MyHDL for some of the reasons you did (integration ease) and some
>>> other reasons (leveraging type systems and new syntax to improve
>>> expressiveness). Yesterday, I successfully synthesized the code to
>>> verilog. I've implemented the type system and simulator too, but
>>> there's a lot of work to be done. Since it's embedded in Java, it's
>>> easy to use all kinds of numerical libraries and integrate with many
>>> systems. Here's the code: github.com/dgrnbrg/piplin
>>>
>> Hi David,
>>
>> I have negligible experience with Clojure, possibly because it
>> resurrects my Lisp nightmares of paren counting and infinite
>> recursion through tangled lists.
>>
>> I will take a look at your project as soon as time permits, which
>> unfortunately may not be until next weekend.  I am motivated to see
>> how you have approached the general issue, and what factors have
>> shaped your particular approach.
>>
>> Most of all, thanks for your supportive reply!  I really hate
>> criticizing Jan, especially when I know I'm trying to do battle
>> unarmed.  Yet I'm light-years away from even formulating, much less
>> implementing, my own solution to the problem.  So I'm highly
>> motivated to learn what others, such as you, are doing.
>>
>> Thanks,
>>
>> -BobC
>
> Some of Peter Novig's comments on different programming languages I have
> found informative.  Although the following is a quote of a paraphrase I
> think it captures some related points.
>
> """
> Peter made, primarily that Python is very effective, very expressive,
> and can cut out a lot of the bullshit that most Java programmers deal
> with on a regular basis.
> """
>
> I think the same could be said for lisp on-top of Java (or whatever the
> hell Clojure is).
>
> As mentioned numerous times in this thread and Jan D. stated eloquently
> in one of the latest replies.  No one is trying to discourage other
> projects or experimenting with different languages, levels of
> abstraction, new feature, etc.
>
> The following line from Jan's response I think describes many of the
> conversations (or lack of).
>
>> I am therefore frustrated by the fact that I hear all kinds
>> of opinions and suggestions to "merge" but that whenever things
>> get a little technical then the "I am a beginner" umbrella opens.
>
> In the above replace "merge" with "add XYZ language feature".  There are
> periodic suggestions to the newsgroup to add the latest high-level
> abstraction method.  But after the initial "You really should have ..."
> or better "I really need ..." the potentially great conversations fade,
> why?
>
> Personally, I am disappointed that this newsgroup has been infiltrated
> with a number of "hey people that follow MyHDL come check out my ...".
> I just don't see this in other Project specific mailing-lists.  I think
> open conversation why 'X' is better than 'Y' is always great.  Let the
> learning and growing flow.
>
> What could have been useful is a discussion, why you didn't think Python
> was the correct platform for your project.  And why a functional
> language serves your goals better Python or existing functional language
> HDLs like Lava.  Then you could have advertised another project, gave
> useful feedback to this project, and possibly had some great and
> educational conversations.
>
> 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/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Restrictions for conversion (initial values)

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

On 4/25/12 8:30 AM, Norbo wrote:
>
>>> The initial values for the array signal are enough for a synthesizable
>>> approach.
>>> The Function with is used in the VHDL code is just another way which can
>>> be used to give the
>>> signals in the array there initial values in a more procedural way (for
>>> vhdl). If you have the procedure
>>> wich gives the values in python, you can write the initial values in
>>> vhdl
>>> to the array directly.
>
>> Is this true for Verilog and VHDL?  And is it true across multiple
>> vendor tools?  IMO the actual creation of the pre-init RAM is less
>> important, unless widely advertised, than wide support of pre-init.
>> Reworded, adding the init support even if it doesn't support pre-init
>> RAM in the vendor synthesis is ok, IMO.
> ......
> ......
>> But to clarify, you do not see initial value errors with Verilog in
>> Quartus?
>
> I looked at it more closely now, and here is what i found :
> Bassicaly a signal array with initial value can be used, meaningfull in
> the following scenarios:
>
> 1. reading it from a combinatorical process
> 	->   vhdl synthesis works&   verilog syntesis works (but signal array
> must be defined as "reg")
>
> 2. reading it synchron (clocked)
> 	->  vhdl synthesis works&   verilog syntesis works (but signal array must
> be defined as "reg")
>
> 3. reading it synchron (clocked) and writing it synchron
> 	->  vhdl synthesis works&   verilog synthesis works (signal array is
> allready defined as "reg")
>
> 4. reading it synchron (clocked) and writing it in a combinatorical process
> 	->  vhdl synthesis works&   verilog synthesis doesnt work !!! (because
> signal cant be defined as reg when you write to in a combinatorical
> process. So if you write to just one signal in the array the whole array
> needs to be defined as wire and you cant use the
> initial statment for that signal array, so you cant initialize all the
> other signals which are not written in a combinatorical process.
> it normally makes sense that  if you have a inital value in a signal that
> you are not allowed to overwrite it immidiatly with an combinatorical
> assignment.
> But the problem is that if you just use one signal of the array to write
> to it in a combinatorical process, you "lose" the hole array.
>
> Addition: "if there is a asynchron reset in a clocked process where you
> assign on of the array signals a reset value, then the verilog synthesis
> works with the initialized array"

This is an alternative to the initial block initial values (pre-init RAM)?

>
> 5. reading and writing in a combinatorical process
> same problem in verilog ->  you cant have the signal array be defined as
> "wire" and use the init block statment in verilog.
> Or in other words: If the signal array is defined as "reg" you cannot
> write to it in a combinatorical process.
>
In the above can you clarify between what synthesizes and what creates 
RAM/ROM as expected.  As we discovered with Quartus, it will not use a 
BRAM for a ROM when an always_comb is used to describe a ROM, the ROM 
needs to be clocked.  But this does not seem to be the case for the 
Xilinx tools.  One case is that is synthesizes and no BRAM used the 
other is synthesizes and BRAM used.

We might want to create a wiki page with a table and summarize these 
results.  The question would be where on the wiki, as a simple project 
page, a RAM/ROM cookbook page, or an FAQ page?

Regards,
Chris

Re: [myhdl-list] Starting over

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

> On 04/22/2012 01:02 PM, David Greenberg wrote:
>> Hi Bob,
>> I wanted to let you know about my own solution to this problem, a
>> language embedded in Clojure called Piplin. I initially sought to use
>> MyHDL for some of the reasons you did (integration ease) and some
>> other reasons (leveraging type systems and new syntax to improve
>> expressiveness). Yesterday, I successfully synthesized the code to
>> verilog. I've implemented the type system and simulator too, but
>> there's a lot of work to be done. Since it's embedded in Java, it's
>> easy to use all kinds of numerical libraries and integrate with many
>> systems. Here's the code: github.com/dgrnbrg/piplin
>>
> Hi David,
>
> I have negligible experience with Clojure, possibly because it
> resurrects my Lisp nightmares of paren counting and infinite
> recursion through tangled lists.
>
> I will take a look at your project as soon as time permits, which
> unfortunately may not be until next weekend.  I am motivated to see
> how you have approached the general issue, and what factors have
> shaped your particular approach.
>
> Most of all, thanks for your supportive reply!  I really hate
> criticizing Jan, especially when I know I'm trying to do battle
> unarmed.  Yet I'm light-years away from even formulating, much less
> implementing, my own solution to the problem.  So I'm highly
> motivated to learn what others, such as you, are doing.
>
> Thanks,
>
> -BobC

Some of Peter Novig's comments on different programming languages I have 
found informative.  Although the following is a quote of a paraphrase I 
think it captures some related points.

"""
Peter made, primarily that Python is very effective, very expressive, 
and can cut out a lot of the bullshit that most Java programmers deal 
with on a regular basis.
"""

I think the same could be said for lisp on-top of Java (or whatever the 
hell Clojure is).

As mentioned numerous times in this thread and Jan D. stated eloquently 
in one of the latest replies.  No one is trying to discourage other 
projects or experimenting with different languages, levels of 
abstraction, new feature, etc.

The following line from Jan's response I think describes many of the 
conversations (or lack of).

> I am therefore frustrated by the fact that I hear all kinds
> of opinions and suggestions to "merge" but that whenever things
> get a little technical then the "I am a beginner" umbrella opens.

In the above replace "merge" with "add XYZ language feature".  There are 
periodic suggestions to the newsgroup to add the latest high-level 
abstraction method.  But after the initial "You really should have ..." 
or better "I really need ..." the potentially great conversations fade, 
why?

Personally, I am disappointed that this newsgroup has been infiltrated 
with a number of "hey people that follow MyHDL come check out my ...". 
I just don't see this in other Project specific mailing-lists.  I think 
open conversation why 'X' is better than 'Y' is always great.  Let the 
learning and growing flow.

What could have been useful is a discussion, why you didn't think Python 
was the correct platform for your project.  And why a functional 
language serves your goals better Python or existing functional language 
HDLs like Lava.  Then you could have advertised another project, gave 
useful feedback to this project, and possibly had some great and 
educational conversations.

Regards,
Chris

[myhdl-list] Open Task Wiki Page

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

Back in the day Jan D. create the open-task wiki page.  This was 
intended to be descriptions of open items that an interested developer 
could tackle as a first/learning contribution item.

Many of these tasks have been completed.  I have summarized the open 
task list below and indicated which tasks I believe have been completed. 
  Feel free to provide feedback and comments on the accuracy of the 
"status".

   * "... intbv or Signal as array index" - Status: Completed.  This
     has been implemented.  Believe this was added in 0.7

   * "Initial value support" - Status: Open.  Have been some recent
     conversations.

   * "Support for tristates" - Status: Completed  This feature was
     added with the addition of shadow signals in 0.7.  There seems
     to be a bug, the "FAQ Tristates" post has an example.

   * "General support of indexed constants" - Status: Open.

   * "Support for conditional expressions" - Status: Completed

   * "RPM package for Fedora" - Status: Completed


If these are correct, I can update the page with the latest status.

Regards,
Chris

Re: [myhdl-list] Floating Point MEP

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

On 4/25/12 4:06 PM, Jan Decaluwe wrote:

>
>     Note however that in contrast to what you suggest, it is
>     perfectly possible to *simulate* "hierarchical" signals.
>     Simulation is intended to be completely general.

Great to know!

    The basic problem as I see it remains that the convertor
    (or "exporter" as you call it) is a tool which is
    'event-accurate'. It cannot "export" a combinatorial
    operator such as '*' to a module that has pipelining.
    The operator operates within a clock cycle, the module
    needs several.

Understood.  I was not planning on converting the innards of the
floating point module. It is not "in the convertible subset".   I just
wanted something that I could simulate and that would also run in
Verilog.   I will use a floating point multiplication library in
Verilog.    Not quite sure how I am going to do the conversion.  I
expect that I will write some "user defined verilog or vhdl" code.

Anyhow MyHDL does need the floating point modules.  If I get them up and
simulating correctly, then I am sure other newbies will start using
them.   Even without the conversion stuff.  Anyone interested?   

-- 
Regards
Christopher Lozinski

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

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

Re: [myhdl-list] Floating Point MEP

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

On 04/24/2012 12:53 PM, Christopher Lozinski wrote:
> Here is a MEP for floating point numbers.
>
> http://wiki.myhdlclass.com:8080/FloatingPoint
>
> The basic idea is to create a new signal type, float, out of sign,
> mantissa and exponent signals. In MyHDL model the calculation using
> python floating point operators with the appropriate delay. When
> exporting it call an existing Verilog or VHDL library. The big change
> is that MyHDL would need to understand hierarchical signals. Maybe it
> is not that hard. When dealing with a signal in a sensitivity list,
> MyHDL would first check it it were hierarchical, if it were, MyHDL
> would add all of the sub signals to the sensitivity list. And from
> there MyHDL could continue operating as before.
>
> If you are interested, I invite you to read the details in the MEP.
>
> http://wiki.myhdlclass.com:8080/FloatingPoint

I have a hard time understanding exactly what you expect.
(btw this post is buried deep in a thread where it doesn't belong.)

As you mentioned, all of this has been discussed before, I don't
see new elements.

The basic problem as I see it remains that the convertor
(or "exporter" as you call it) is a tool which is
'event-accurate'. It cannot "export" a combinatorial
operator such as '*' to a module that has pipelining.
The operator operates within a clock cycle, the module
needs several.

Note however that in contrast to what you suggest, it is
perfectly possible to *simulate* "hierarchical" signals.
Simulation is intended to be completely general.

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

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

On 04/19/2012 08:55 AM, Thomas Heller wrote:
> MyHDL uses 'steps' as time unit.  When it writes VCD files with
> traceSignals, one time unit is defined as 1ns.
>
> Considering the speed of todays logic, this is very coarse.
>
> I would find it convenient to be able to specify sub-nanosecond
> delays as floats,

Mm, simulation is based on discrete time steps so there
must be some smallest unit defined.

What Verilog does is to define the physical meaning of
the unit step with a global directive, but I'm not sure
even this is useful for MyHDL (accurate gate level timing
level simulations are not its target application). Within
a MyHDL simulation, you can attach any phyical meaning
that you want to the unit step.

> and to make the timescale written into the
> vcd files configurable.

Agreed - I have gone ahead and implemented a 'timescale'
directive as an attribute of the traceSignals function.
Actually, this existed for toVerilog also but was not
yet documented.

I have implemented this in the 0.8-dev branch. I have also
updated the documentation immediately. In the future, I
will try to keep a development version of the documentation
up to date and on-line, instead of doing it all at release
time. I have added the link to it in the Development Zone on the
web site.

-- 
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] Restrictions for conversion (initial values)

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

>> The initial values for the array signal are enough for a synthesizable
>> approach.
>> The Function with is used in the VHDL code is just another way which can
>> be used to give the
>> signals in the array there initial values in a more procedural way (for
>> vhdl). If you have the procedure
>> wich gives the values in python, you can write the initial values in  
>> vhdl
>> to the array directly.

> Is this true for Verilog and VHDL?  And is it true across multiple
> vendor tools?  IMO the actual creation of the pre-init RAM is less
> important, unless widely advertised, than wide support of pre-init.
> Reworded, adding the init support even if it doesn't support pre-init
> RAM in the vendor synthesis is ok, IMO.
......
......
> But to clarify, you do not see initial value errors with Verilog in  
> Quartus?

I looked at it more closely now, and here is what i found :
Bassicaly a signal array with initial value can be used, meaningfull in  
the following scenarios:

1. reading it from a combinatorical process
	->  vhdl synthesis works  &  verilog syntesis works (but signal array  
must be defined as "reg")

2. reading it synchron (clocked)
	-> vhdl synthesis works  &  verilog syntesis works (but signal array must  
be defined as "reg")

3. reading it synchron (clocked) and writing it synchron
	-> vhdl synthesis works  &  verilog synthesis works (signal array is  
allready defined as "reg")

4. reading it synchron (clocked) and writing it in a combinatorical process
	-> vhdl synthesis works  &  verilog synthesis doesnt work !!! (because  
signal cant be defined as reg when you write to in a combinatorical  
process. So if you write to just one signal in the array the whole array  
needs to be defined as wire and you cant use the
initial statment for that signal array, so you cant initialize all the  
other signals which are not written in a combinatorical process.
it normally makes sense that  if you have a inital value in a signal that  
you are not allowed to overwrite it immidiatly with an combinatorical  
assignment.
But the problem is that if you just use one signal of the array to write  
to it in a combinatorical process, you "lose" the hole array.

Addition: "if there is a asynchron reset in a clocked process where you  
assign on of the array signals a reset value, then the verilog synthesis  
works with the initialized array"

5. reading and writing in a combinatorical process
same problem in verilog -> you cant have the signal array be defined as  
"wire" and use the init block statment in verilog.
Or in other words: If the signal array is defined as "reg" you cannot  
write to it in a combinatorical process.




So a relative simple addition would be to find out wheter a signal is  
driven in a combinatorical process (@always_comb) or not, to decide
wheter the initial values are written for the signal array.
So that in Case 4. and  5. no initial values are written. This would mean  
some of vhdl's liberty is lost but acceptable since thes are very
rare cases. Is this possible to decide wheter it is driven in  
(@always_comb ) or not?


The more complex one would probably be to find out which signal in the  
array are driven in a combinatorical process, and then seperate these  
signals from the array so that these signals can be defined as "wire" and  
the other remaining can be defined as "reg".
Then a warning during conversion can be writen which says: "Warning: You  
are overiting initial values in a combinatorical process (initial value is  
usless in this case)" -> ;)

Sorry i didn't recognized this since i wasn't encountering this case.

greeting
Norbo

Re: [myhdl-list] What MyHDL is not

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

On 04/24/2012 05:20 AM, Bob Cunningham wrote:

> This may, in fact, be an ideal entry point for a MyHDL tutorial:
> Start with a "black box" module, a written description of its
> interface and intended behavior, then write the testbench.  Leverage
> Python skills the reader may already possess.  (It will also ensure
> the entire toolchain has been properly installed.)  Later lessons
> could introduce MyHDL primitives, then have the reader use a good
> testbench to find and fix the error in a flawed circuit (where the
> fix would require use the primitives just introduced).

http://myhdl.org/doku.php/cookbook:stopwatch

> Test first, design second.  It would also teach the reader to become
> good at reading circuit descriptions before writing them.  Both
> pedagogically and practically, this seems to me to be a very sound
> approach, one I'd be very interested in pursuing!  And MyHDL may be
> the first HDL to make this approach practical.  I think I see an
> O'Reilly book here somewhere...

http://www.myhdl.org/doku.php/why#you_would_like_to_do_algorithm_development_and_implementation_in_the_same_environment

http://www.myhdl.org/doc/current/manual/unittest.html



-- 
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] What MyHDL is not

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

On 04/24/2012 04:11 AM, Christopher Felton wrote:
> On 4/23/12 5:23 AM, Jan Decaluwe wrote:
>> I have written a page describing what MyHDL is not:
>>
>> http://www.myhdl.org/doku.php/whatitisnot
>>
> I believe this will help inform new users.  We often get new users, I
> believe, with unrealistic expectations of MyHDL.
>
> Some comments, cross linking to the "Why MyHDL" page (and vise-versa)
> could be useful.  We want to be useful setting expectations but also
> want to *highlight* the benefits :)

I added that in the beginning. Also used some less negative wordings
here and there.
>
> In the _It is not well suited for gate level simulation_ section.  You
> might want to mention co-simulation.  A potential user might come away
> with the wrong impression that they will need to redo a fair amount of
> verification implementation in Verilog/VHDL.  Rather, they should use a
> Verilog/VHDL simulator in conjunction to verify structural-physical
> correctness.

I agree completely. I have rewritten this without reference
to gate level simulation in the title - "timing simulations" instead.
And I have included a short description of co-simulation.

Thanks,

Jan

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

Re: [myhdl-list] Floating Point MEP

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

I guess I misunderstood the first time around. I just scanned your post.

I thought you were talking about an IP module, that could be used to 
make logic. I think that would be very useful, and could attract new 
users to MyHDL.

I don't think it needs to be built into MyHDL, but could just be a 
package used with it.

When I read it over more, I think you are really talking about being 
able to model floating point in MyHDL, with no plans to convert it to 
logic. I think that is quite simple and really you are just talking 
about making conversions to/from MyHDL types to/from Python floating 
point numbers?

I don't think any changes are needed in MyHDL to support this effort.

I think having IP available built with MyHDL would be a good way to 
attract new interest in MyHDL. Also a good way to showcase the power of 
MyHDL. That is really what I use it for, making parametric modules that 
are easy to reuse and have are easy to test.

Keep in mind, that floating point modules are available from all FPGA 
vendors for free. So the effort to make them is really only worth it if 
you are targeting an ASIC. If you are targeting an ASIC, there is a good 
chance the extra effort will be used to make fixed point work, to save 
valuable area and power.



On 04/24/2012 10:56 AM, Christopher Lozinski wrote:
> On 4/24/12 8:40 AM, Tom Dillon wrote:
>> My other 2 cents is, for something as complex as a floating point 
>> operator, say multiply I don't think you would have much luck 
>> overriding the operator as in:
>>
>> c = a * b
>>
>> I think you really want a module instantiation, since you want to be 
>> able to pass parameters along with the signals. Such as number of 
>> pipelines, type of rounding and so on. That would lead to a much more 
>> worth while library component. 
> Agreed.  Sorry if my posting was not clear.  I have edited the wiki, 
> it now says.
>
>
>     Implementing Floating Point Multiply
>
> Conceptually, given a binary sign, an intbv exponent, and a fixed 
> point mantissa, it is not that hard to implement a floating point 
> multiply.
>
> http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BinMath/multFloat.html
>
> But, that does look like a lot of work. And it is complex to figure 
> out the pipelining.
>
> So my plan is to create MyHDL modules for floating point 
> multiplication, division and addition/subtraction. Each such module 
> will accept inputs of two floating point signals. Internally it will 
> convert the signals into a python floating point number, and then in 
> MyHDL simulation it will just use python floating point multiplication.
>
>   * output = input1 * input2
>
> Then the output signals will be set using the results from the python 
> computation.
>
> Of course this will not work on export, so on export there will be a 
> call to a Verilog library to do the hard work.
>
> And then pipelining also has to be represented.  And delays have to be 
> added.
>
> Is that better?
>
> That page now also has the creative commons license.
>
> -- 
> Regards
> Christopher Lozinski
>
> Check out my iPhone apps TextFaster and EmailFaster
> http://textfaster.com
>
> Expect a paradigm shift.
> http://MyHDL.org

Re: [myhdl-list] Floating Point MEP

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

On 4/24/12 8:40 AM, Tom Dillon wrote:
> My other 2 cents is, for something as complex as a floating point
> operator, say multiply I don't think you would have much luck
> overriding the operator as in:
>
> c = a * b
>
> I think you really want a module instantiation, since you want to be
> able to pass parameters along with the signals. Such as number of
> pipelines, type of rounding and so on. That would lead to a much more
> worth while library component. 
Agreed.  Sorry if my posting was not clear.  I have edited the wiki, it
now says. 


    Implementing Floating Point Multiply

Conceptually, given a binary sign, an intbv exponent, and a fixed point
mantissa, it is not that hard to implement a floating point multiply.

http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BinMath/multFloat.html

But, that does look like a lot of work. And it is complex to figure out
the pipelining.

So my plan is to create MyHDL modules for floating point multiplication,
division and addition/subtraction. Each such module will accept inputs
of two floating point signals. Internally it will convert the signals
into a python floating point number, and then in MyHDL simulation it
will just use python floating point multiplication.

  * output = input1 * input2

Then the output signals will be set using the results from the python
computation.

Of course this will not work on export, so on export there will be a
call to a Verilog library to do the hard work.

And then pipelining also has to be represented.  And delays have to be
added.

Is that better? 

That page now also has the creative commons license.

-- 
Regards
Christopher Lozinski

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

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

Re: [myhdl-list] Floating Point MEP

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

Hi,

A couple of quick comments;

We have had the discussion about being able to group signals. That would 
be a good thing to have, I would use it for complex numbers all the 
time. It only really matters at the top level I/O, as conversion and 
simulation will choke. I pass around an object of a complex class to 
make internal connections and that works great, then break them out at 
the top level.

My other 2 cents is, for something as complex as a floating point 
operator, say multiply I don't think you would have much luck overriding 
the operator as in:

c = a * b

I think you really want a module instantiation, since you want to be 
able to pass parameters along with the signals. Such as number of 
pipelines, type of rounding and so on. That would lead to a much more 
worth while library component.

Tom





On 04/24/2012 05:53 AM, Christopher Lozinski wrote:
> Here is a MEP for floating point numbers.
>
> http://wiki.myhdlclass.com:8080/FloatingPoint
>
> The basic idea is to create a new signal type, float, out of sign, 
> mantissa and exponent signals. In MyHDL model the calculation using 
> python floating point operators with the appropriate delay. When 
> exporting it call an existing Verilog or VHDL library. The big change 
> is that MyHDL would need to understand hierarchical signals. Maybe it 
> is not that hard. When dealing with a signal in a sensitivity list, 
> MyHDL would first check it it were hierarchical, if it were, MyHDL 
> would add all of the sub signals to the sensitivity list. And from 
> there MyHDL could continue operating as before.
>
> If you are interested, I invite you to read the details in the MEP.
>
> http://wiki.myhdlclass.com:8080/FloatingPoint
>
> -- 
> Regards
> Christopher Lozinski
>
> Check out my iPhone apps TextFaster and EmailFaster
> http://textfaster.com
>
> Expect a paradigm shift.
> http://MyHDL.org
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Floating Point MEP

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

Am 24.04.2012 12:53, schrieb Christopher Lozinski:
> Here is a MEP for floating point numbers.
>
> http://wiki.myhdlclass.com:8080/FloatingPoint

I always get timeouts when I try to connect to this site.

Thomas

Re: [myhdl-list] delta cycles

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

On 04/24/2012 04:06 AM, Christopher Felton wrote:
> On 4/23/12 5:39 AM, Jan Decaluwe wrote:

>>
>> If it is really a problem, I think the best way would be
>> solve it a the waveform viewer level, e.g. by moving
>> a clock trace backwards a little. But I am thinking
>> aloud, don't know if there are waveform viewers that
>> can do this.
>   >
>   >  Jan
>
> I am not aware of any viewer that allows the clock (or any signal) to
> shifted slightly.  But this does seem to be a common problem with other
> designers / students I have run across.
>
> ... (15 minutes elapse)
>
> But then I decided to poke around GTKwave.  And it looks like you can
> use the "time warp" feature to do this.  I simply selected a signal
> (clk) and the used the "Edit->Time Warp->Warp Marked" and then typed in
> "-1 ns" and the clk signal was shifted to the left 1ns.

Good catch! I had also searched for this but didn't find it
readily. After warping, you can then use 'Pattern Search' to
mark rising edges; it creates markers that run over the whole
waveform viewer window.

-- 
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] Floating Point MEP

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

Here is a MEP for floating point numbers.

http://wiki.myhdlclass.com:8080/FloatingPoint

The basic idea is to create a new signal type, float, out of sign,
mantissa and exponent signals. In MyHDL model the calculation using
python floating point operators with the appropriate delay. When
exporting it call an existing Verilog or VHDL library. The big change is
that MyHDL would need to understand hierarchical signals. Maybe it is
not that hard. When dealing with a signal in a sensitivity list, MyHDL
would first check it it were hierarchical, if it were, MyHDL would add
all of the sub signals to the sensitivity list. And from there MyHDL
could continue operating as before.

If you are interested, I invite you to read the details in the MEP.

http://wiki.myhdlclass.com:8080/FloatingPoint

-- 
Regards
Christopher Lozinski

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

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

Re: [myhdl-list] delta cycles

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

>>> When this counter is simulated, count changes a delta cycle after
>>> the positive clock edge.  When traceSignals is used to write a VCD file,
>>> gtkwave shows that the count changes exactly at the same time as the
>>> clock edge.  This is confusing (at least in more complicated cases) in
>>> the timing diagram.
>>

> But then I decided to poke around GTKwave.  And it looks like you can
> use the "time warp" feature to do this.  I simply selected a signal
> (clk) and the used the "Edit->Time Warp->Warp Marked" and then typed in
> "-1 ns" and the clk signal was shifted to the left 1ns.
>
> To make this useful you need to change the "delay" in the clock to
> something of significant value (depending how much you want it skewed).
>    If you use delay(1) and time warp -1 ns you will shift by half a clock
> cycle.

Cool! Thanks for the hint.

Thomas

Re: [myhdl-list] Restrictions for conversion

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

>
>
> Of curse this doesnt get mapped into ram, but the code is synthesisable
> and the netlist-viewer seems to show
> a good result.
> In the patch i posted previously i noticed an error i made:
> The verilog code is not synthesisable if the list of signals is only
> used in reading, because then the toVerilog conversion
> defines the list of signals with the "wire" keyword ( in the case above
> "wire [7:0] aListSig [0:10-1];" )
> but it is not possible to use the "initial block" with the wire keyword.
> so i changed it in this case to "reg" (in the case above "reg [7:0]
> aListSig [0:10-1];")
> I just appended the new patch.
>
>
>
> greetings
>
> Norbo
>
>

I was taking a look at your patch, your patch is not based on the latest 
0.8-dev branch.  There are enough changes that it doesn't auto import to 
the 0.8-dev branch.

I don't know if the _doinit flag is actually needed?  I believe the 
conversion code can determine if the value should be written or not 
without modifying the Signal or intbv objects.  As your modified intbv 
does, it can always create the initial value unless the Signal/intbv 
init value is None.

Lastly, the changes do break the unit-tests.  As mentioned, the patch 
didn't auto import.  I believe I got all the changes manually but 
possibly something was missed in the manual addition of the changes.  I 
think removing the _doinit will fix the failures (but I didn't really 
look that closely).

Regards,
Chris

Re: [myhdl-list] Restrictions for conversion (initial values)

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

<snip>
>> To get to an actual synthesizable approach it
>> appears the initial values would not be enough?
>
> The initial values for the array signal are enough for a synthesizable
> approach.
> The Function with is used in the VHDL code is just another way which can
> be used to give the
> signals in the array there initial values in a more procedural way (for
> vhdl). If you have the procedure
> wich gives the values in python, you can write the initial values in vhdl
> to the array directly.
> The "specifying initial memory contents at power-up"
>

Is this true for Verilog and VHDL?  And is it true across multiple 
vendor tools?  IMO the actual creation of the pre-init RAM is less 
important, unless widely advertised, than wide support of pre-init. 
Reworded, adding the init support even if it doesn't support pre-init 
RAM in the vendor synthesis is ok, IMO.

>
>> One of the reasons why initial values has not been implemented (it is on
>> the todo list,
>> http://www.myhdl.org/doku.php/dev:tasks#initial_values_suppot) is that
>> it was observed that Quartus did not support initial value support in
>> Verilog.  There would be a mis-match between the Verilog conversion and
>> VHDL conversion.
>
> I just can say that i use quartus v11.1 and i dont see this limitation
> there.
> But this is probably not satisfactorily if someone uses a older version.

I think moving forward that is ok, not to support older Quartus, I don't 
recall any objections in the past.

But to clarify, you do not see initial value errors with Verilog in Quartus?

>
> There is this another open task:
> http://www.myhdl.org/doku.php/dev:tasks # More general support of indexed
> constants
>
> If the  array of signals is initialized with values (also in the vhdl an
> verilig code)
>    you can then use it also as a indexed "constant" value
> in a more general way, this signal can  be used everyvere where like a
> normal signal.
> if you never write to this signal it is just like a constant.
>
>
> greetings
> Norbo
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2

Re: [myhdl-list] What MyHDL is not

[Bob C. <fl...@gm...>]

On 04/23/2012 07:11 PM, Christopher Felton wrote:
> On 4/23/12 5:23 AM, Jan Decaluwe wrote:
>> I have written a page describing what MyHDL is not:
>>
>> http://www.myhdl.org/doku.php/whatitisnot
> I believe this will help inform new users.  We often get new users, I
> believe, with unrealistic expectations of MyHDL.
>
> Some comments, cross linking to the "Why MyHDL" page (and vise-versa)
> could be useful.  We want to be useful setting expectations but also
> want to *highlight* the benefits :)
>
> In the _It is not well suited for gate level simulation_ section.  You
> might want to mention co-simulation.  A potential user might come away
> with the wrong impression that they will need to redo a fair amount of
> verification implementation in Verilog/VHDL.  Rather, they should use a
> Verilog/VHDL simulator in conjunction to verify structural-physical
> correctness.

Yes!  Being able to use the full power of Python in simulation AND co-simulation testbenches is possibly the one truly revolutionary aspect of MyHDL.  (IMHO, YMMV, IANAHDLD)

When trying to learn an HDL by looking at example circuits (and trying to learn circuits by reading HDL), I often found the testbench was often the best way to understand the designer's intent (and proper module use), especially when the code contained few comments and used oddly named signals.  Unfortunately, designers occasionally put little or no effort into their testbenches (at least in some of the public projects I've seen).  Python should make it easy(-ier) to create a thorough testbench with much less code (and effort, hopefully).

For any such undocumented and untested modules, writing a testbench is how I would approach understanding it (as well as providing a service to the community).  I'd much rather do that in Python than in any HDL.

I suspect I'll be getting lots of benefit from this feature of MyHDL long before I'm proficient with the rest of it.

This may, in fact, be an ideal entry point for a MyHDL tutorial: Start with a "black box" module, a written description of its interface and intended behavior, then write the testbench.  Leverage Python skills the reader may already possess.  (It will also ensure the entire toolchain has been properly installed.)  Later lessons could introduce MyHDL primitives, then have the reader use a good testbench to find and fix the error in a flawed circuit (where the fix would require use the primitives just introduced).

Test first, design second.  It would also teach the reader to become good at reading circuit descriptions before writing them.  Both pedagogically and practically, this seems to me to be a very sound approach, one I'd be very interested in pursuing!  And MyHDL may be the first HDL to make this approach practical.  I think I see an O'Reilly book here somewhere...


-BobC

Re: [myhdl-list] What MyHDL is not

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

On 4/23/12 5:23 AM, Jan Decaluwe wrote:
> I have written a page describing what MyHDL is not:
>
> http://www.myhdl.org/doku.php/whatitisnot
>
I believe this will help inform new users.  We often get new users, I 
believe, with unrealistic expectations of MyHDL.

Some comments, cross linking to the "Why MyHDL" page (and vise-versa) 
could be useful.  We want to be useful setting expectations but also 
want to *highlight* the benefits :)

In the _It is not well suited for gate level simulation_ section.  You 
might want to mention co-simulation.  A potential user might come away 
with the wrong impression that they will need to redo a fair amount of 
verification implementation in Verilog/VHDL.  Rather, they should use a 
Verilog/VHDL simulator in conjunction to verify structural-physical 
correctness.

Regards,
Chris

Re: [myhdl-list] delta cycles

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

On 4/23/12 5:39 AM, Jan Decaluwe wrote:
<snip>
>> When this counter is simulated, count changes a delta cycle after
>> the positive clock edge.  When traceSignals is used to write a VCD file,
>> gtkwave shows that the count changes exactly at the same time as the
>> clock edge.  This is confusing (at least in more complicated cases) in
>> the timing diagram.
>
> This is typical in the zero-delay RTL methodology: delta
> cycles are a way to define causality within zero time.

Just to clarify, what we are talking about is the following:

ts ....................  (simulation time step)
C  ___|---|___|---|___|  (clock)
D  ___|-------|________  (clocked signal)
Q  ___________|-------|  (clocked signal)
       0       1

The D and Q are "clocked" on the posedge.  Visually this can be 
confusing because it is not visually clear which value is "clocked" on 
the posedge.

The delay cycle provides a visual queue.

ts ....................  (simulation time step)
C  ___|---|___|---|___|  (clock)
D  ____|-------|________ (clocked signal)
Q  ____________|-------| (clocked signal)
       0       1

The delay in the signal visually clarifies where the signal is clocked. 
  There is no visual ambiguity what value is clocked on the posedge.  In 
this simple example it is easy to follow but in a more complex display 
it can be confusing?

>
> I think most RTL designers cope with it (at least I did)
> by developing a "clocks are special" mindset.
>
> In fact, clocks are the only signals where such confusion is
> possible. Therefore, I think measures such as a default delay
> for all signals are overkill (and can lead to other types
> of confusion).

Is this practically speaking because we usually only "edge" on clocks. 
But generally it would occur for any @always(<signal>.posedge).

>
> I once saw a waveform viewer that allowed to visualize
> delta cycles, but also here I think that is overkill.
>
> If it is really a problem, I think the best way would be
> solve it a the waveform viewer level, e.g. by moving
> a clock trace backwards a little. But I am thinking
> aloud, don't know if there are waveform viewers that
> can do this.
 >
 > Jan

I am not aware of any viewer that allows the clock (or any signal) to 
shifted slightly.  But this does seem to be a common problem with other 
designers / students I have run across.

... (15 minutes elapse)

But then I decided to poke around GTKwave.  And it looks like you can 
use the "time warp" feature to do this.  I simply selected a signal 
(clk) and the used the "Edit->Time Warp->Warp Marked" and then typed in 
"-1 ns" and the clk signal was shifted to the left 1ns.

To make this useful you need to change the "delay" in the clock to 
something of significant value (depending how much you want it skewed). 
  If you use delay(1) and time warp -1 ns you will shift by half a clock 
cycle.

Regards,
Chris

Re: [myhdl-list] What MyHDL is not

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

On 4/23/12 5:23 AM, Jan Decaluwe wrote:
> I have written a page describing what MyHDL is not:
>
> http://www.myhdl.org/doku.php/whatitisnot
>
And I wrote a different version of the page at:
wiki.MyHDLClass.com:8080/WhatMyHDLisNot

The difference is about audience.  There are two different audiences. 
The experienced python developer and the experienced chip designer.  The
mental models of the two groups are different, their issues are
different.  Jan's page did not resonate with me.  I hope that python
developers connect better with the page I just wrote.

Comments and edits are most appreciated.

The other point is to finish off the page  and each point on it on an
upbeat note, so that we do not scare new users away. 

Hope that helps.  It would be great if someone would edit the myhdl wiki
page with the same ideas in mind.

And I have added the creative commons licensing agreement to the bottom
of the page I just wrote.

-- 
Regards
Christopher Lozinski

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

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

Re: [myhdl-list] Why MyHDL (New MyHDL Wiki)

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

On 04/22/2012 01:21 PM, Christopher Lozinski wrote:
> First thank you for your excellent email two days ago, and even more so
> for what you wrote this morning.
>
> On 4/22/12 5:25 AM, Jan Decaluwe wrote:
>> I
>> believe the main problem in HDL-based design is verification, and
>> how MyHDL (unlike Migen) helps you by the fact that you
>> can use the same modelling paradigm for high-level models and
>> test benches as for synthesizable logic.
>>
>> You seemed surprized, which I found suprizing in turn. Is
>> it so different in software? Really, getting those gates into
>> an FPGA is the easy part. The difficult part is getting
>> them to work properly.
>>
>>
>> Well, I don't. Verification is the problem. The reason why I
>> think the abstraction level of synthesizable logic should
>> be as high as possible, is because that leaves more time
>> for verification.
>
> I think this is the central point from a marketing perspective.  And
> once you believe this, then the advantage of MyHDL is clear.  Only MyHDL
> gives you both structural and dynamic information in the same
> computational model.  And the latter is clearly needed for verification.
>
> On my wiki, I will be using the same creative commons license as on your
> wiki.  Once that is posted on my wiki, may I go ahead and quote from
> your emails using that same license?

Sure.

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