myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Introduction and FPGA Camp Booth Proposal

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

First let me introduce myself, I am a hard core Python and Zope 
developer recently interested in FPGA.s
I know a lot about semiconductor manufacturing, but very little about 
digital electonics.  This MyHDL stuff looks hugely interesting, but hard 
to wrap my head around.

My core observation is that modern CPU's average 10 instructions per 
second with 2 billion transistors.  Surely that is hugely inefficient, 
and we can do better.

On to the conference.  Here is an upcoming free conference.  Kind of an 
open source camp.  Maybe we could have a free booth there.

http://www.fpgacentral.com/fpgacamp

What does everyone think?  Anyone interested?

-- 
Regards
Christopher Lozinski

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

Re: [myhdl-list] FW: Floating-point support

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

On 28/03/11 15:22, Christopher Felton wrote:
> I believe, most of Parhi work is in the area of 2's compliment bit-serial /
> digital-serial circuits.  You can use the general design and extend this to
> your variable-length floating-point structure (is that the intent?).
Yes. The complexity of the variable length FP sequencer is perhaps 
50% more than that of the variable length integer core. I'd like to 
aim for the simplest useful working hardware first.

> His (Parhi) book, "VLSI Digital SIgnal Processing Systems" has some more
> information on bit-serial systems.  Most of this information is probably
> available in papers though (book is expensive).
>
> In my experience, bit-serial (or digital-serial) focus has been to reduce
> hardware requirements.  Personally I have not seen it used to dynamically
> extend range.  I have only seen it used in fixed-precision same parallel
> structures.  More focus on the second reference (reduce hardware) and less
> on the big-num.  I think the big-num is an interesting application!

I am comfortable with the techniques needed to complete a processor 
implementation.  What concerns me is that users of the processor 
may need to adapt their algorithm in order to obtain optimum 
results.  The open source big-num package should contain good 
technique guidance for this.

My own focus and interest is hardware efficiency.  In order to 
maximise testing of the inherent data compression of this core, the 
current processor design is intended to have the smallest useful 
footprint.

Outline Specification:
   Register less design with cache for up to 3 data stack items.
   Memory: RAM ~1k x 4  (perhaps one memory block of an Actel Igloo)
           ROM 0 to MBs (from external serial x1/x4 flash)
   Numeric computation range: ~ +/-2e9
   ALU data path width: 3b
   Instructions:  (# x size - description)
      8 x 4b - operand stack re-ordering & subroutine exit
     16 x 8b - ALU operations, memory access & operand test
      4 x variable length - for call, branch, and literal

I'm imagining that one application this tiny core would be good for 
is to provide a smooth expansion path for a very large FSM design.

Whilst developing with this core I'd expect to be able to perform 
interactive code testing and debug on the live system, with source 
code store, compiler and debug window on a PC.

When it grows big enough to warrant a higher level programming 
language then there's  www.pythononachip.org

Jan Coombs

Re: [myhdl-list] FW: Floating-point support

[Christopher F. <cf...@uc...>]

On Mon, Mar 28, 2011 at 12:27 PM, David Blubaugh <
dav...@ya...> wrote:

> would it also be possible to use automated theorem provers within this
> endeavor ??
>

Could you elaborate?  How and why it is applicable?

.chris

Re: [myhdl-list] FW: Floating-point support

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

would it also be possible to use automated theorem provers within this endeavor ??
 
David Blubaugh
 
 


--- On Mon, 3/28/11, Christopher Felton <cf...@uc...> wrote:


From: Christopher Felton <cf...@uc...>
Subject: Re: [myhdl-list] FW: Floating-point support
To: "General discussions on MyHDL" <myh...@li...>
Cc: "Jan Coombs" <jan...@mu...>
Date: Monday, March 28, 2011, 10:22 AM


I believe, most of Parhi work is in the area of 2's compliment bit-serial / digital-serial circuits.  You can use the general design and extend this to your variable-length floating-point structure (is that the intent?).


His (Parhi) book, "VLSI Digital SIgnal Processing Systems" has some more information on bit-serial systems.  Most of this information is probably available in papers though (book is expensive).


In my experience, bit-serial (or digital-serial) focus has been to reduce hardware requirements.  Personally I have not seen it used to dynamically extend range.  I have only seen it used in fixed-precision same parallel structures.  More focus on the second reference (reduce hardware) and less on the big-num.  I think the big-num is an interesting application! 


.chris



On Mon, Mar 28, 2011 at 7:42 AM, Jan Coombs <jan...@mu...> wrote:


On 17/03/11 13:17, David Blubaugh wrote:
> That would a good place to start !!!  Lets start to develop your core processor

Ok, but what shall we call it?

As I see it, serialised numeric data methods exist for two main
reasons:

1) 'Bignum' packages, used to extend the natural range of a
hardware processor, for example:
  http://gmplib.org/

2) 'Digit Serial Processing', a family of techniques used to reduce
chip area used in large fixed function calculating engines.  For
example, DARPA funded work was done by Minnesota Uni:
  http://adsabs.harvard.edu/abs/1991ITCS...38..358P
  http://www.mendeley.com/research/radix2n-serialserial-multipliers/

The common factor in these seems to me to be that a numeric item is
divided into slices in order to reduce the required size of
transmission channels and processing modules. For this reason I
have tended to refer to the process as 'sliced data processing' and
an engine as a 'sliced data processor'.  Any suggestions or comments?

Minnesota uni also did some work on a digit-serial processor core,
but I have not found any papers about this. Any references to any
other similar work would be much appreciated.

Jan Coombs


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar



_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list


-----Inline Attachment Follows-----


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
-----Inline Attachment Follows-----


_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list



      

Re: [myhdl-list] FW: Floating-point support

[Christopher F. <cf...@uc...>]

I believe, most of Parhi work is in the area of 2's compliment bit-serial /
digital-serial circuits.  You can use the general design and extend this to
your variable-length floating-point structure (is that the intent?).

His (Parhi) book, "VLSI Digital SIgnal Processing Systems" has some more
information on bit-serial systems.  Most of this information is probably
available in papers though (book is expensive).

In my experience, bit-serial (or digital-serial) focus has been to reduce
hardware requirements.  Personally I have not seen it used to dynamically
extend range.  I have only seen it used in fixed-precision same parallel
structures.  More focus on the second reference (reduce hardware) and less
on the big-num.  I think the big-num is an interesting application!

.chris

On Mon, Mar 28, 2011 at 7:42 AM, Jan Coombs <
jan...@mu...> wrote:

> On 17/03/11 13:17, David Blubaugh wrote:
> > That would a good place to start !!!  Lets start to develop your core
> processor
>
> Ok, but what shall we call it?
>
> As I see it, serialised numeric data methods exist for two main
> reasons:
>
> 1) 'Bignum' packages, used to extend the natural range of a
> hardware processor, for example:
>   http://gmplib.org/
>
> 2) 'Digit Serial Processing', a family of techniques used to reduce
> chip area used in large fixed function calculating engines.  For
> example, DARPA funded work was done by Minnesota Uni:
>   http://adsabs.harvard.edu/abs/1991ITCS...38..358P
>   http://www.mendeley.com/research/radix2n-serialserial-multipliers/
>
> The common factor in these seems to me to be that a numeric item is
> divided into slices in order to reduce the required size of
> transmission channels and processing modules. For this reason I
> have tended to refer to the process as 'sliced data processing' and
> an engine as a 'sliced data processor'.  Any suggestions or comments?
>
> Minnesota uni also did some work on a digit-serial processor core,
> but I have not found any papers about this. Any references to any
> other similar work would be much appreciated.
>
> Jan Coombs
>
>
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] FW: Floating-point support

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

On 17/03/11 13:17, David Blubaugh wrote:
> That would a good place to start !!!  Lets start to develop your core processor

Ok, but what shall we call it?

As I see it, serialised numeric data methods exist for two main 
reasons:

1) 'Bignum' packages, used to extend the natural range of a 
hardware processor, for example:
   http://gmplib.org/

2) 'Digit Serial Processing', a family of techniques used to reduce 
chip area used in large fixed function calculating engines.  For 
example, DARPA funded work was done by Minnesota Uni:
   http://adsabs.harvard.edu/abs/1991ITCS...38..358P
   http://www.mendeley.com/research/radix2n-serialserial-multipliers/

The common factor in these seems to me to be that a numeric item is 
divided into slices in order to reduce the required size of 
transmission channels and processing modules. For this reason I 
have tended to refer to the process as 'sliced data processing' and 
an engine as a 'sliced data processor'.  Any suggestions or comments?

Minnesota uni also did some work on a digit-serial processor core, 
but I have not found any papers about this. Any references to any 
other similar work would be much appreciated.

Jan Coombs

Re: [myhdl-list] rosettacode submission

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

Jan D. has created project spaces on the MyHDL wiki.  You can create a page
for this project.  Others might be interested in the progress and
development.  It will also be a good place to post non-text information
(block diagrams, etc) that might be useful in newsgroup conversations.

Chris Felton

On Wed, Mar 23, 2011 at 3:52 PM, David Blubaugh <dav...@ya...
> wrote:

> Jan,
>
> I will be more than happy to be apart of the project.
>
> David Blubaugh
>
>
>
>
> --- On *Mon, 3/21/11, Jan Coombs <jan...@mu...>*wrote:
>
>
> From: Jan Coombs <jan...@mu...>
> Subject: Re: [myhdl-list] rosettacode submission
> To: myh...@li...
> Date: Monday, March 21, 2011, 7:34 PM
>
>
> On 21/03/11 19:10, Jan Decaluwe wrote:
> > I couldn't resist to post my take on this.   . . .
> Thanks, much appreciated.  I had started to take on board Chris and
> your comments, but still have much to learn.  As to what to post on
> rosettacode I have asked for guidance from the problem proposer.
>
> Should David Blubaugh and myself go ahead with the goal of
> producing a novel processor core using MyHDL, what level of traffic
> would be welcome here?
>
> Jan Coombs
>
>
>

Re: [myhdl-list] rosettacode submission

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

Jan,
 
I will be more than happy to be apart of the project.  
 
David Blubaugh
 
 


--- On Mon, 3/21/11, Jan Coombs <jan...@mu...> wrote:


From: Jan Coombs <jan...@mu...>
Subject: Re: [myhdl-list] rosettacode submission
To: myh...@li...
Date: Monday, March 21, 2011, 7:34 PM


On 21/03/11 19:10, Jan Decaluwe wrote:
> I couldn't resist to post my take on this.   . . .
Thanks, much appreciated.  I had started to take on board Chris and 
your comments, but still have much to learn.  As to what to post on 
rosettacode I have asked for guidance from the problem proposer.

Should David Blubaugh and myself go ahead with the goal of 
producing a novel processor core using MyHDL, what level of traffic 
would be welcome here?

Jan Coombs


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list



      

Re: [myhdl-list] rosettacode submission

[Christopher F. <cf...@uc...>]

On Mon, Mar 21, 2011 at 6:34 PM, Jan Coombs <
jan...@mu...> wrote:

> On 21/03/11 19:10, Jan Decaluwe wrote:
> > I couldn't resist to post my take on this.   . . .
> Thanks, much appreciated.  I had started to take on board Chris and
> your comments, but still have much to learn.  As to what to post on
> rosettacode I have asked for guidance from the problem proposer.
>
> Should David Blubaugh and myself go ahead with the goal of
> producing a novel processor core using MyHDL, what level of traffic
> would be welcome here?
>
>
In my opinion, any level of activity would be fine.  But you might find that
responses and activity will vary.  If you are expecting to get frequent
response in minutes or hours, you might be disappointed.  But I think you
will get some type of response / comment within a couple of days.   If the
participants are ok with the described expectations, post away!

Chris Felton

Re: [myhdl-list] rosettacode submission

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

On 21/03/11 19:10, Jan Decaluwe wrote:
> I couldn't resist to post my take on this.   . . .
Thanks, much appreciated.  I had started to take on board Chris and 
your comments, but still have much to learn.  As to what to post on 
rosettacode I have asked for guidance from the problem proposer.

Should David Blubaugh and myself go ahead with the goal of 
producing a novel processor core using MyHDL, what level of traffic 
would be welcome here?

Jan Coombs

Re: [myhdl-list] rosettacode submission

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

I couldn't resist to post my take on this. I realize
that the whole handling of lists is sometimes confusing,
however I think that is especially so for small
examples like this with a "forced" structural
approach.

I have added comments to clarify what I'm doing.
I would use the opportunity to illustrate conversion
to Verilog and VHDL, and unit testing. This is
all in my example code.

I have used the SystemVerilog code as an example -
the unit test worked first time right.


On 03/21/2011 12:32 PM, Jan Decaluwe wrote:
> I believe the most important thing is to look good :-)
>
> I don't think we should be holier than the pope - ADA and
> SystemVerilog in this case. Both use basic bit-operations
> to model basic gates - even an xor as opposed to what
> the spec says. We should be allowed to do the same and
> start from the Half-Adder.
>
> I would keep things simple and first do the whole thing
> using lists of signals. Then, I would use a top-level wrapper
> that would only do the conversion from intbv's to lists and vice
> versa. Note that, in a real design environment, this is only
> strictly necessary if you want to convert the adder as
> a top-level - something not very likely.
>
> The ConcatSignal in your code really creates a signal and should
> be used outside generators, if conversion is an issue
> (and probably otherwise also, to use Signals in the "intended" way.)
> The functional equivalent that returns a value is myhdl.concat.
>
> I would *definitely* include a simple test bench, using `assert`
> that could be used by a framework such as py.test.
>
> Jan
>
> On 03/19/2011 01:07 PM, Jan Coombs wrote:
>> While helping with some code debugging for another rosettacode page, I noticed that there is a simple hardware category:
>>
>> http://rosettacode.org/wiki/Four_bit_adder
>>
>> I now have some questions about my potential submission:
>>
>> 1) Could posting this on rosettacode generate an unwelcome influx of MyHDL newbies?
>>
>> 2) My 'ConcatSignal(*reversed' phrase did not work. Have I missed something, or do I have to use an @always_comb and loop?
>>
>> 3) Does my code have about the right level of commenting for a novice reader? Should I expand signal names for easier reading?
>>
>> Any further suggestions for making this submission attractive, understandable, and a good representation of MyHDL would be much appreciated.
>>
>> Jan Coombs
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>>
>>
>>
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>


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

Re: [myhdl-list] rosettacode submission

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

I believe the most important thing is to look good :-)

I don't think we should be holier than the pope - ADA and
SystemVerilog in this case. Both use basic bit-operations
to model basic gates - even an xor as opposed to what
the spec says. We should be allowed to do the same and
start from the Half-Adder.

I would keep things simple and first do the whole thing
using lists of signals. Then, I would use a top-level wrapper
that would only do the conversion from intbv's to lists and vice
versa. Note that, in a real design environment, this is only
strictly necessary if you want to convert the adder as
a top-level - something not very likely.

The ConcatSignal in your code really creates a signal and should
be used outside generators, if conversion is an issue
(and probably otherwise also, to use Signals in the "intended" way.)
The functional equivalent that returns a value is myhdl.concat.

I would *definitely* include a simple test bench, using `assert`
that could be used by a framework such as py.test.

Jan

On 03/19/2011 01:07 PM, Jan Coombs wrote:
> While helping with some code debugging for another rosettacode page, I noticed that there is a simple hardware category:
>
> http://rosettacode.org/wiki/Four_bit_adder
>
> I now have some questions about my potential submission:
>
> 1) Could posting this on rosettacode generate an unwelcome influx of MyHDL newbies?
>
> 2) My 'ConcatSignal(*reversed' phrase did not work. Have I missed something, or do I have to use an @always_comb and loop?
>
> 3) Does my code have about the right level of commenting for a novice reader? Should I expand signal names for easier reading?
>
> Any further suggestions for making this submission attractive, understandable, and a good representation of MyHDL would be much appreciated.
>
> Jan Coombs
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list


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

Re: [myhdl-list] rosettacode submission

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

I believe the most important thing is to look good :-)

I don't think we should be holier than the pope - ADA and
SystemVerilog in this case. Both use basic bit-operations
to model basic gates - even an xor as opposed to what
the spec says. We should be allowed to do the same and
start from the Half-Adder.

I would keep things simple and first do the whole thing
using lists of signals. Then, I would use a top-level wrapper
that would only do the conversion from intbv's to lists and vice
versa. Note that, in a real design environment, this is only
strictly necessary if you want to convert the adder as
a top-level - something not very likely.

The ConcatSignal in your code really creates a signal and should
be used outside generators, if conversion is an issue
(and probably otherwise also, to use Signals in the "intended" way.)
The functional equivalent that returns a value is myhdl.concat.

I would *definitely* include a simple test bench, using `assert`
that could be used by a framework such as py.test.

Jan

On 03/19/2011 01:07 PM, Jan Coombs wrote:
> While helping with some code debugging for another rosettacode page, I noticed that there is a simple hardware category:
>
> http://rosettacode.org/wiki/Four_bit_adder
>
> I now have some questions about my potential submission:
>
> 1) Could posting this on rosettacode generate an unwelcome influx of MyHDL newbies?
>
> 2) My 'ConcatSignal(*reversed' phrase did not work. Have I missed something, or do I have to use an @always_comb and loop?
>
> 3) Does my code have about the right level of commenting for a novice reader? Should I expand signal names for easier reading?
>
> Any further suggestions for making this submission attractive, understandable, and a good representation of MyHDL would be much appreciated.
>
> Jan Coombs
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
>
>
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list


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

Re: [myhdl-list] rosettacode submission

[Felton C. <chr...@gm...>]

On Mar 19, 2011, at 7:07 AM, Jan Coombs wrote:

> While helping with some code debugging for another rosettacode page,  
> I noticed that there is a simple hardware category:
>
>  .0200
>
> I now have some questions about my potential submission:
>
> 1) Could posting this on rosettacode generate an unwelcome influx of  
> MyHDL newbies?
I would not be concerned about this.

>
> 2) My 'ConcatSignal(*reversed' phrase did not work.  Have I missed  
> something, or do I have to use an @always_comb and loop?
I am not familiar with *reversed?  Will need to look at this when I  
have some time.

>
> 3) Does my code have about the right level of commenting for a  
> novice reader?  Should I expand signal names for easier reading?
I think it is fine but I would use the port names defined on the  
rossetta page.  That makes it easier to follow for someone working  
through the page.

>
> Any further suggestions for making this submission attractive,  
> understandable, and a good representation of MyHDL would be much  
> appreciated.
>
> Jan Coombs

Couple additional comments,

I would add self-checking capabilities to the testbench vs. simply  
printing out the results.

Also, I know this example follows the page description for a  
"simulation" on the rosetta code page (your code has the comment  
"synthesis"?).  Instead of a bottom up approach I think it would be  
nice to show an actual "behavioral" synthesis and show that the tools  
generate the full-adder as described.  In my opinion, other than an  
academic exercise, creating a the 4-bit adder built from HA and FAs  
has limited use.  I do realize that is probably not the intent of the  
example for the page.

Some of the other examples don't create functions/modules for the  
primitive operations.  It makes the example very explicit but with  
that it is verbose.

Chris Felton

[myhdl-list] rosettacode submission

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

While helping with some code debugging for another rosettacode 
page, I noticed that there is a simple hardware category:

   http://rosettacode.org/wiki/Four_bit_adder

I now have some questions about my potential submission:

1) Could posting this on rosettacode generate an unwelcome influx 
of MyHDL newbies?

2) My 'ConcatSignal(*reversed' phrase did not work.  Have I missed 
something, or do I have to use an @always_comb and loop?

3) Does my code have about the right level of commenting for a 
novice reader?  Should I expand signal names for easier reading?

Any further suggestions for making this submission attractive, 
understandable, and a good representation of MyHDL would be much 
appreciated.

Jan Coombs

Re: [myhdl-list] FW: Floating-point support

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

That would a good place to start !!!  Lets start to develop your core processor  
 
David Blubaugh
 
 

--- On Thu, 3/17/11, Jan Coombs <jan...@mu...> wrote:


From: Jan Coombs <jan...@mu...>
Subject: Re: [myhdl-list] FW: Floating-point support
To: myh...@li...
Date: Thursday, March 17, 2011, 6:30 AM


On 03/03/11 09:42, Jan Decaluwe wrote:
> As always, if your interest is purely modeling, you can do
> anything you want today with MyHDL.
I am hoping to become comfortable with MyHDL and python, as they 
are appear to be very powerful tools.

> If your interest is conversion or synthesis to an implementation
> in silicon: I have personally no plans nor experience for
> floating-point support.
Because numeric resolution, range, and data rate are design 
parameters to any fixed function engine I can not imagine a use for 
FP. So I believe you have the best useful tool extensions in mind 
when you wrote:

> On a related sidenote, the situation is completely different for
> fixed point. I have little experience with it, but great interest
> in enhancing MyHDL support for this. It seems this could be a
> "killing feature", as Verilog doesn't have it and I think the VHDL
> approach can be improved. I have been following Chris Felton's
> work with great interest. As it happens, I am now doing a project
> involving fixed point and after that I hope to have time
> to work on it in MyHDL.

The project that I would like to get out into the wild is a very 
scalable processor core.  The perceived overlap in interest between 
this and David Blubaugh is that my core would use an unbounded 
integer as it's standard data type, and there is a small further 
step to supporting an unbounded float.

Jan Coombs


------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list



      

Re: [myhdl-list] FW: Floating-point support

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

On 03/03/11 09:42, Jan Decaluwe wrote:
> As always, if your interest is purely modeling, you can do
> anything you want today with MyHDL.
I am hoping to become comfortable with MyHDL and python, as they 
are appear to be very powerful tools.

> If your interest is conversion or synthesis to an implementation
> in silicon: I have personally no plans nor experience for
> floating-point support.
Because numeric resolution, range, and data rate are design 
parameters to any fixed function engine I can not imagine a use for 
FP. So I believe you have the best useful tool extensions in mind 
when you wrote:

> On a related sidenote, the situation is completely different for
> fixed point. I have little experience with it, but great interest
> in enhancing MyHDL support for this. It seems this could be a
> "killing feature", as Verilog doesn't have it and I think the VHDL
> approach can be improved. I have been following Chris Felton's
> work with great interest. As it happens, I am now doing a project
> involving fixed point and after that I hope to have time
> to work on it in MyHDL.

The project that I would like to get out into the wild is a very 
scalable processor core.  The perceived overlap in interest between 
this and David Blubaugh is that my core would use an unbounded 
integer as it's standard data type, and there is a small further 
step to supporting an unbounded float.

Jan Coombs

Re: [myhdl-list] FW: Floating-point support

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

Jan,
 
Forget that I had mentioned anything about Lie Groups.  It is something that would be developed after the FP modules for MyHDL have been developed.
 
More is coming !!
 
David Blubaugh
 
 


--- On Fri, 3/11/11, Jan Coombs <jan...@mu...> wrote:


From: Jan Coombs <jan...@mu...>
Subject: Re: FW: Floating-point support
To: "General discussions on MyHDL" <myh...@li...>
Cc: "David Blubaugh" <dav...@ya...>
Date: Friday, March 11, 2011, 5:37 AM


On 09/03/11 17:49, David Blubaugh wrote:
   . . .
> the development of FP modules would be extremely important ...
Why?

Ok, that's not very helpful, so I'll prod and ask questions:

For most simple engineering applications fixed point is optimum. (hey, does this imply that a package of maths operations for unbounded streamable integers would also be useful?)

You mentioned Lie Group calculations, but from what I've read I'm not likely to quickly obtain an understanding of practical application, so I'll have to ignore your recipe, and just ask about the ingredients you are looking for.

For e8, I noticed that the matrix size is ~60GB, so would you want unbounded integers for address calculations?  How much of this data must be memory resident for useful work?

Do you want FP for it's very wide dynamic range?  What sort of mix of simple FP operations will you use?  What sort of resolution do you need, minimum, and generally?

Can your algorithms be optimised for streaming data rather than using arrays with random access? (I believe FFT can) This allows inherent data compression, and reduces memory accesses.

What proportion of data stream inputs to basic maths modules are obtained from:
1) matrices or arrays which need address calculation?
2) FIFOs or stacks, which primarily support serial access?
3) another basic math module, so can be viewed as a stream?

Why do you want a slow but area efficient implementation of FP arithmetic?  If this is for research, a more economic solution might be to buy more crates of FPGAs!

Also, even if you need FP, you might be limited by the number of hardware multipliers available per chip for acceptable performance.

Any answers or comments would be of interest. As well as trying to understand what might be useful, this will help specify module interfaces, and allow practical performance estimates.

Jan Coombs
-- 


      

Re: [myhdl-list] FW: Floating-point support

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

On 09/03/11 17:49, David Blubaugh wrote:
    . . .
> the development of FP modules would be extremely important ...
Why?

Ok, that's not very helpful, so I'll prod and ask questions:

For most simple engineering applications fixed point is optimum. 
(hey, does this imply that a package of maths operations for 
unbounded streamable integers would also be useful?)

You mentioned Lie Group calculations, but from what I've read I'm 
not likely to quickly obtain an understanding of practical 
application, so I'll have to ignore your recipe, and just ask about 
the ingredients you are looking for.

For e8, I noticed that the matrix size is ~60GB, so would you want 
unbounded integers for address calculations?  How much of this data 
must be memory resident for useful work?

Do you want FP for it's very wide dynamic range?  What sort of mix 
of simple FP operations will you use?  What sort of resolution do 
you need, minimum, and generally?

Can your algorithms be optimised for streaming data rather than 
using arrays with random access? (I believe FFT can) This allows 
inherent data compression, and reduces memory accesses.

What proportion of data stream inputs to basic maths modules are 
obtained from:
1) matrices or arrays which need address calculation?
2) FIFOs or stacks, which primarily support serial access?
3) another basic math module, so can be viewed as a stream?

Why do you want a slow but area efficient implementation of FP 
arithmetic?  If this is for research, a more economic solution 
might be to buy more crates of FPGAs!

Also, even if you need FP, you might be limited by the number of 
hardware multipliers available per chip for acceptable performance.

Any answers or comments would be of interest. As well as trying to 
understand what might be useful, this will help specify module 
interfaces, and allow practical performance estimates.

Jan Coombs
-- 

Re: [myhdl-list] FW: Floating-point support

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

>
>
> Following this interesting thread, I would say MyHDL should have an
> API for custom conversions. I'm not sure but I saw a proposal to
> change the hooks __verilog__ and __vhdl__ to add custom code. Maybe
> some access to the introspection logic can provide a way to define
> custom code to implement FP or anything else. In my case, It happened
> to me that some structures (e.g. buses and interconnects) I already
> know how to convert efficiently to VHDL, and I wanted to have a custom
> converter for this circumstances.
>
> Let me think a bit more (and refresh my memory), but I saw here some
> enhancement proposals.
>
> Bye!
>
> It might of been in the MyHDL release (what's new) documentation,
http://www.myhdl.org/doc/0.7/whatsnew/0.7.html

<http://www.myhdl.org/doc/0.7/whatsnew/0.7.html>Chris Felton

Re: [myhdl-list] FW: Floating-point support

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

2011/3/9 Christopher Felton <cf...@uc...>:
>
>
> On Wed, Mar 9, 2011 at 11:31 AM, Jan Coombs
> <jan...@mu...> wrote:
>>
>> On 06/03/11 21:28, David Blubaugh wrote:
>>
>> > What you are thinking regarding my words are exactly as to what I was
>> > thinking.  How would you like to proceed??
>>
>> Openly, unless there is clearly more chance of success/profit by
>> working privately.
>>
>> Your original requirements looked easy to me. This is likely
>> because I've not specified them fully, and partly because number
>> representation has interested me for some time.
>>
>> When building a synthesizable fixed function maths engine, I would
>> want to be able to select basic computation modules, and then wire
>> them together. The width of the interconnect could be selected
>> independently, and could be varied to balance resources used with
>> required data rate.
>>
>> Do you think that a library of FP functions and interconnect
>> modules written in synthesizable MyHDL would be generally useful,
>> and worth the effort to develop?
>>
>>
>
> I agree, development of MyHDL convertible FP modules and interconnect would
> be useful to many developers.

Following this interesting thread, I would say MyHDL should have an
API for custom conversions. I'm not sure but I saw a proposal to
change the hooks __verilog__ and __vhdl__ to add custom code. Maybe
some access to the introspection logic can provide a way to define
custom code to implement FP or anything else. In my case, It happened
to me that some structures (e.g. buses and interconnects) I already
know how to convert efficiently to VHDL, and I wanted to have a custom
converter for this circumstances.

Let me think a bit more (and refresh my memory), but I saw here some
enhancement proposals.

Bye!

> .chris
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>



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

Recomiendo usar OpenDocument Format
para uso e intercambio de documentos

http://www.spreadopendocument.org/

Re: [myhdl-list] FW: Floating-point support

[Christopher F. <cf...@uc...>]

On Wed, Mar 9, 2011 at 11:31 AM, Jan Coombs <
jan...@mu...> wrote:

> On 06/03/11 21:28, David Blubaugh wrote:
>
> > What you are thinking regarding my words are exactly as to what I was
> thinking.  How would you like to proceed??
>
> Openly, unless there is clearly more chance of success/profit by
> working privately.
>
> Your original requirements looked easy to me. This is likely
> because I've not specified them fully, and partly because number
> representation has interested me for some time.
>
> When building a synthesizable fixed function maths engine, I would
> want to be able to select basic computation modules, and then wire
> them together. The width of the interconnect could be selected
> independently, and could be varied to balance resources used with
> required data rate.
>
> Do you think that a library of FP functions and interconnect
> modules written in synthesizable MyHDL would be generally useful,
> and worth the effort to develop?
>
>
>
I agree, development of MyHDL convertible FP modules and interconnect would
be useful to many developers.

.chris

Re: [myhdl-list] FW: Floating-point support

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

My God yes, 
 
the development of FP modules would be extremely important to develop.  That would not only be defined for just FP modules.  Other modules would be extremely important to develop.  Also, I am looking at that many have developed python programs for Lie Group calculations.  I have a pretty good reason to hope for the development of MYHDL synthesizable modules for these as well.  Would You all like to know more ?? 
 
David Blubaugh
 
 


--- On Wed, 3/9/11, Jan Coombs <jan...@mu...> wrote:


From: Jan Coombs <jan...@mu...>
Subject: Re: FW: Floating-point support
To: "General discussions on MyHDL" <myh...@li...>
Cc: "David Blubaugh" <dav...@ya...>
Date: Wednesday, March 9, 2011, 12:31 PM


On 06/03/11 21:28, David Blubaugh wrote:

> What you are thinking regarding my words are exactly as to what I was thinking.  How would you like to proceed??

Openly, unless there is clearly more chance of success/profit by working privately.

Your original requirements looked easy to me. This is likely because I've not specified them fully, and partly because number representation has interested me for some time.

When building a synthesizable fixed function maths engine, I would want to be able to select basic computation modules, and then wire them together. The width of the interconnect could be selected independently, and could be varied to balance resources used with required data rate.

Do you think that a library of FP functions and interconnect modules written in synthesizable MyHDL would be generally useful, and worth the effort to develop?

Jan Coombs.
-- 



      

Re: [myhdl-list] FW: Floating-point support

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

On 06/03/11 21:28, David Blubaugh wrote:

> What you are thinking regarding my words are exactly as to what I was thinking.  How would you like to proceed??

Openly, unless there is clearly more chance of success/profit by 
working privately.

Your original requirements looked easy to me. This is likely 
because I've not specified them fully, and partly because number 
representation has interested me for some time.

When building a synthesizable fixed function maths engine, I would 
want to be able to select basic computation modules, and then wire 
them together. The width of the interconnect could be selected 
independently, and could be varied to balance resources used with 
required data rate.

Do you think that a library of FP functions and interconnect 
modules written in synthesizable MyHDL would be generally useful, 
and worth the effort to develop?

Jan Coombs.
-- 

Re: [myhdl-list] FW: Floating-point support

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

Only partial comments, will have to address the complete reply later.

On Wed, Mar 9, 2011 at 10:30 AM, Jan Coombs <
jan...@mu...> wrote:

> On 09/03/11 14:14, Christopher Felton wrote:
>
>  You lost me a little, I think you might have mispoken.  You stated
>> "request that interest me ... provision of synthesizable modules to
>> perform
>> basic FP ..."
>> but then later said
>> "... automatically string these modules together based on a higher level
>> description is probably beyond my interest..."
>>
>> These are conflicting statements?  I am not sure what you are looking for
>> but lets take an example, a simple floating-point expression in MyHDL
>>
>
> Sorry that my cautiousness to reply and provide explanation has cost you so
> much writing. Your 3 cents is much appreciated, but I only have a 1 cent
> answer.
>
> Your design sketch would be appropriate where maximum processing rate is
> required, otherwise it would not be ideal.  Implementation efficiency can be
> increased by using a serial data format, and abandoning the IEEE float
> representation formats.
>
> There is a clear processing speed penalty here.  There are also less
> obvious benefits: The chip area used is reduced by a greater proportion than
> the loss in performance.  When using streamed data with many values close to
> zero the number of bits pulled from memory is reduced by a large factor.
>
> Because the proposed data representation is not IEEE compliant, any
> modelling requiring equivalent methods must use a suitable equivalent data
> type in python.  Two unconstrained integers may  be used to represent an
> unconstrained float.
>
>
> That is my point exactly.  What you described, thus far, are all
implementation details!  And there are plenty to choose from.

Why do you say it is not IEEE compliant?  I would disagree, I would say
there isn't enough detail in the limit example to decipher.

The example was not intended in any form to be a complete example but rather
a starting point for some  conversation.  And to help determine the effort
of such a project.  To build a converter one would need to start with
parsing the Python FP expressions.  The backend implementation can have many
forms, doh there it is again, the difficult part.

>From my point of view, we are not discussing what is efficient
floating-point implementation, my knowledge is limited in that area.  But
how would you even start and what would be the steps to getting to a
conversion.

I believe the original question, "Does MyHDL support FP expressions "
(summarized).  Is the inquire, "Does MyHDL automatically generate serial
FP"?

.chris