Finally! A Completely Open Complete FPGA Toolchain

On Tue, 28 Jul 2015 16:10:51 -0400
rickman <gnuarm@gmail.com> wrote:

> On 7/28/2015 3:55 PM, Jan Coombs <Jan-54 wrote:
> > An open-source toolchain for the IGLOO parts could be an
> > unusually powerful tool in the hands of a creative designer.
> 
> I have looked at the Igloo parts but never been impressed.
> Why would an open source tool chain improve them or any other
> part?

Because open source tools allow exploration of techniques which
are restricted using regular tools. 

a) iCE40 - see rest of thread. (Note suggestion to buy 3 iCE40
sticks if using IceStorm, one or more parts might die during 
(mal?)practice)

b) IGLOO - because you would then be able to create complex
logic without the noise or random signal states inherent in
using lookup tables. One possibility might be asynchronous
logic. 

c) [others] no idea, unless they are close relatives of the
above parts. (like ProASIC3)  

Jan Coombs
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

On 7/29/2015 5:50 AM, Jan Coombs <Jan-54 wrote:
> On Tue, 28 Jul 2015 16:10:51 -0400
> rickman <gnuarm@gmail.com> wrote:
>
>> On 7/28/2015 3:55 PM, Jan Coombs <Jan-54 wrote:
>>> An open-source toolchain for the IGLOO parts could be an
>>> unusually powerful tool in the hands of a creative designer.
>>
>> I have looked at the Igloo parts but never been impressed.
>> Why would an open source tool chain improve them or any other
>> part?
>
> Because open source tools allow exploration of techniques which
> are restricted using regular tools.

I'm not sure what this means.  What "techniques" are restricted by the 
vendor's tools?  Are we talking about techniques that are useful in a 
design environment or research?


> a) iCE40 - see rest of thread. (Note suggestion to buy 3 iCE40
> sticks if using IceStorm, one or more parts might die during
> (mal?)practice)

I thoought I had read the thread.  What did I miss?  All I've seen is 
that there are alternative tools available that may or may not be as 
good as the vendor's tools.  Other than not having to fight the 
licensing, what improvement do the alternative tools provide?


> b) IGLOO - because you would then be able to create complex
> logic without the noise or random signal states inherent in
> using lookup tables. One possibility might be asynchronous
> logic.

???  What logic won't the Igloo tools create?  Sounds like I clearly 
need to avoid the Microsemi parts.


> c) [others] no idea, unless they are close relatives of the
> above parts. (like ProASIC3)

ok

-- 

Rick

On Wed, 29 Jul 2015 12:32:08 -0400, rickman wrote:

> On 7/29/2015 5:50 AM, Jan Coombs <Jan-54 wrote:

>> a) iCE40 - see rest of thread. (Note suggestion to buy 3 iCE40 sticks
>> if using IceStorm, one or more parts might die during (mal?)practice)
> 
> I thoought I had read the thread.  What did I miss?  All I've seen is
> that there are alternative tools available that may or may not be as
> good as the vendor's tools.  Other than not having to fight the
> licensing, what improvement do the alternative tools provide?

Hackability. If you have an itch, you can scratch it yourself with FOSS 
tools. If you discover a bug, you can fix it yourself. If you want to 
repurpose, optimize or otherwise change the tool, you can do it with FOSS.

On 8/4/2015 7:05 PM, Aleksandar Kuktin wrote:
> On Wed, 29 Jul 2015 12:32:08 -0400, rickman wrote:
>
>> On 7/29/2015 5:50 AM, Jan Coombs <Jan-54 wrote:
>
>>> a) iCE40 - see rest of thread. (Note suggestion to buy 3 iCE40 sticks
>>> if using IceStorm, one or more parts might die during (mal?)practice)
>>
>> I thoought I had read the thread.  What did I miss?  All I've seen is
>> that there are alternative tools available that may or may not be as
>> good as the vendor's tools.  Other than not having to fight the
>> licensing, what improvement do the alternative tools provide?
>
> Hackability. If you have an itch, you can scratch it yourself with FOSS
> tools. If you discover a bug, you can fix it yourself. If you want to
> repurpose, optimize or otherwise change the tool, you can do it with FOSS.

That's great.  But only important to a small few.  I use tools to get 
work done.  I have zero interest in digging into the code of the tools 
without a real need.  I have not found any bugs in the vendor's tools 
that would make me want to spend weeks learning how they work in the, 
most likely, vain hope that I could fix them.

I think FOSS is great and I am very happy to see that finally happen in 
an end to end toolchain for an FPGA.  But it is statements like this 
that I don't understand, "An open-source toolchain for the IGLOO parts 
could be an unusually powerful tool in the hands of a creative 
designer", or this "Because open source tools allow exploration of 
techniques which are restricted using regular tools."

Not trying to give anyone grief.  I'd just like to understand what 
people expect to happen with FOSS that isn't happening with the vendor's 
closed, but free tools.

-- 

Rick

On 05.08.2015 01:46, rickman wrote:
> On 8/4/2015 7:05 PM, Aleksandar Kuktin wrote:
>>
>> Hackability. If you have an itch, you can scratch it yourself with FOSS
>> tools. If you discover a bug, you can fix it yourself. If you want to
>> repurpose, optimize or otherwise change the tool, you can do it with
>> FOSS.
> 
> That's great.  But only important to a small few.  I use tools to get
> work done.  I have zero interest in digging into the code of the tools
> without a real need.  I have not found any bugs in the vendor's tools
> that would make me want to spend weeks learning how they work in the,
> most likely, vain hope that I could fix them.
> 
> I think FOSS is great and I am very happy to see that finally happen in
> an end to end toolchain for an FPGA.  But it is statements like this
> that I don't understand, "An open-source toolchain for the IGLOO parts
> could be an unusually powerful tool in the hands of a creative
> designer", or this "Because open source tools allow exploration of
> techniques which are restricted using regular tools."
> 
> Not trying to give anyone grief.  I'd just like to understand what
> people expect to happen with FOSS that isn't happening with the vendor's
> closed, but free tools.
> 

Same thing that's happening with compilers all the time.

Just a personal example:
A log time ago I decided to make a few games for the ColecoVision
console. The ColecoVision uses a Z80, and at the tie all the other
homebrew game developers used an old DOS eval version of IAR within
Windows. I used the free sdcc compiler. Not always being happy with the
generated code I started improving it, ad later became the maintainer of
the Z80 port.
A few years ago I joined the group for theory of computer science at the
univesity in Frankfurt as a PhD student. I found that I could apply
graph structure theory in compiler construction. This resulted in some
quite unusual optimizations in SDCC currently not found in any other
compiler.

Philipp

On 8/5/2015 5:30 PM, Philipp Klaus Krause wrote:
> On 05.08.2015 01:46, rickman wrote:
>> On 8/4/2015 7:05 PM, Aleksandar Kuktin wrote:
>>>
>>> Hackability. If you have an itch, you can scratch it yourself with FOSS
>>> tools. If you discover a bug, you can fix it yourself. If you want to
>>> repurpose, optimize or otherwise change the tool, you can do it with
>>> FOSS.
>>
>> That's great.  But only important to a small few.  I use tools to get
>> work done.  I have zero interest in digging into the code of the tools
>> without a real need.  I have not found any bugs in the vendor's tools
>> that would make me want to spend weeks learning how they work in the,
>> most likely, vain hope that I could fix them.
>>
>> I think FOSS is great and I am very happy to see that finally happen in
>> an end to end toolchain for an FPGA.  But it is statements like this
>> that I don't understand, "An open-source toolchain for the IGLOO parts
>> could be an unusually powerful tool in the hands of a creative
>> designer", or this "Because open source tools allow exploration of
>> techniques which are restricted using regular tools."
>>
>> Not trying to give anyone grief.  I'd just like to understand what
>> people expect to happen with FOSS that isn't happening with the vendor's
>> closed, but free tools.
>>
>
> Same thing that's happening with compilers all the time.
>
> Just a personal example:
> A log time ago I decided to make a few games for the ColecoVision
> console. The ColecoVision uses a Z80, and at the tie all the other
> homebrew game developers used an old DOS eval version of IAR within
> Windows. I used the free sdcc compiler. Not always being happy with the
> generated code I started improving it, ad later became the maintainer of
> the Z80 port.
> A few years ago I joined the group for theory of computer science at the
> univesity in Frankfurt as a PhD student. I found that I could apply
> graph structure theory in compiler construction. This resulted in some
> quite unusual optimizations in SDCC currently not found in any other
> compiler.

I think this is the point some are making.  The examples of the utility 
of FOSS often point to more obscure examples which impact a relatively 
small number of users.  I appreciate the fact that being able to tinker 
with the tools can be very useful to a few.  But those few must have the 
need as well as the ability.  With hardware development both are less 
likely to happen.

Maybe I just don't have enough imagination.

-- 

Rick

Am Mittwoch, 5. August 2015 23:30:58 UTC+2 schrieb Philipp Klaus Krause:
> On 05.08.2015 01:46, rickman wrote:
> > On 8/4/2015 7:05 PM, Aleksandar Kuktin wrote:
> >>
> >> Hackability. If you have an itch, you can scratch it yourself with FOSS
> >> tools. If you discover a bug, you can fix it yourself. If you want to
> >> repurpose, optimize or otherwise change the tool, you can do it with
> >> FOSS.
> > 
> > That's great.  But only important to a small few.  I use tools to get
> > work done.  I have zero interest in digging into the code of the tools
> > without a real need.  I have not found any bugs in the vendor's tools
> > that would make me want to spend weeks learning how they work in the,
> > most likely, vain hope that I could fix them.
> > 
> > I think FOSS is great and I am very happy to see that finally happen in
> > an end to end toolchain for an FPGA.  But it is statements like this
> > that I don't understand, "An open-source toolchain for the IGLOO parts
> > could be an unusually powerful tool in the hands of a creative
> > designer", or this "Because open source tools allow exploration of
> > techniques which are restricted using regular tools."
> > 
> > Not trying to give anyone grief.  I'd just like to understand what
> > people expect to happen with FOSS that isn't happening with the vendor's
> > closed, but free tools.
> > 
> 
> Same thing that's happening with compilers all the time.
> 
> Just a personal example:
> A log time ago I decided to make a few games for the ColecoVision
> console. The ColecoVision uses a Z80, and at the tie all the other
> homebrew game developers used an old DOS eval version of IAR within
> Windows. I used the free sdcc compiler. Not always being happy with the
> generated code I started improving it, ad later became the maintainer of
> the Z80 port.
> A few years ago I joined the group for theory of computer science at the
> univesity in Frankfurt as a PhD student. I found that I could apply
> graph structure theory in compiler construction. This resulted in some
> quite unusual optimizations in SDCC currently not found in any other
> compiler.
> 
> Philipp

I think C-compilers are the piece of software were open source works best, as there is a big user base, many of them are skilled programmers. So there is both the skill and motivation to improve the product.

For software not targeted to programmers, the user base must be very large to have sufficient contributors, IMHO.

For FPGA design, the user base is much smaller than for a C compiler. How much of them would really use the open source alternatives when there are very advanced free vendor tools? And how much of them are really skilled software gurus? And have enough spare time? Of course you would find some students which are contributing (e.g. for their thesis), but I doubt that it will be enough to get a competitve product and to maintain it. New devices should be supported with short delay, otherwise the tool would not be very useful.

Of course it could be a good playfield for students, to have a reference for future "real" jobs in the EDA field, but then the tool would not aim to be really used by the average FPGA designer...

BTW: Thanks for your contribution to SDCC, we have ported it to our ERIC5 soft-core many years ago. We also found quite some bugs at that time...

Thomas

thomas.entner99@gmail.com wrote:
> Am Mittwoch, 5. August 2015 23:30:58 UTC+2 schrieb Philipp Klaus Krause:

(snip on open source hardware design tools)

>> Same thing that's happening with compilers all the time.
 
>> Just a personal example:
>> A log time ago I decided to make a few games for the ColecoVision
>> console. The ColecoVision uses a Z80, and at the tie all the other
>> homebrew game developers used an old DOS eval version of IAR within
>> Windows. I used the free sdcc compiler. Not always being happy with the
>> generated code I started improving it, ad later became the maintainer of
>> the Z80 port.

(snip)
> I think C-compilers are the piece of software were open source 
> works best, as there is a big user base, many of them are 
> skilled programmers. So there is both the skill and motivation 
> to improve the product.
 
> For software not targeted to programmers, the user base must be 
> very large to have sufficient contributors, IMHO.

I wonder what one would have said before gcc?

It used to be that unix always came with a C compiler, as one
was required to sysgen a kernel.  At one point, Sun changed to
a bundled minimal C compiler, and charge for a better one.
That opened a door for gcc that might otherwise not have been there.
 
> For FPGA design, the user base is much smaller than for a 
> C compiler. How much of them would really use the open source 
> alternatives when there are very advanced free vendor tools? 
> And how much of them are really skilled software gurus? 
> And have enough spare time? Of course you would find some 
> students which are contributing (e.g. for their thesis), 
> but I doubt that it will be enough to get a competitve 
> product and to maintain it. New devices should be supported 
> with short delay, otherwise the tool would not be very useful.

Again, consider before gcc. I suspect that there are many times
more C programmers now than in the 1980s, yet there were enough
to cause gcc to exist.
 
> Of course it could be a good playfield for students, 
> to have a reference for future "real" jobs in the EDA field, 
> but then the tool would not aim to be really used by the 
> average FPGA designer...

People use gcc because it works well, and it works well because
people use it, and want it to work well. 

But one reason we have free HDL tools (from Xilinx and Altera)
now is related to the competition between them. With only
one FPGA company, there would be no need for competition,
tools could be expensive, and there could be a significant
advantage to FOSS tools.
 
> BTW: Thanks for your contribution to SDCC, we have ported 
> it to our ERIC5 soft-core many years ago. We also found 
> quite some bugs at that time...

-- glen

On 8/5/2015 7:46 PM, glen herrmannsfeldt wrote:
>
> But one reason we have free HDL tools (from Xilinx and Altera)
> now is related to the competition between them. With only
> one FPGA company, there would be no need for competition,
> tools could be expensive, and there could be a significant
> advantage to FOSS tools.

I'm not sure the price of the tools is so much related to the 
competition between the companies.  Hypothesizing only one FPGA company 
is not very realistic and it is certainly far down my list of concerns. 
  I expect the price of tools is much more related to promoting the 
"exploration" of the use of FPGAs.  If you even have to spend $100, that 
makes for a barrier to anyone wanting to start testing the tools.  I ran 
into this myself in jobs where I wanted to try something, but couldn't 
get one dime spent.  I can always find a little free time to spend on 
ideas, but spending money almost always goes through a review of some 
sort where they want you to show why and the "why" is what you want to 
determine.

-- 

Rick

rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)
>> But one reason we have free HDL tools (from Xilinx and Altera)
>> now is related to the competition between them. With only
>> one FPGA company, there would be no need for competition,
>> tools could be expensive, and there could be a significant
>> advantage to FOSS tools.
 
> I'm not sure the price of the tools is so much related to the 
> competition between the companies.  Hypothesizing only one FPGA company 
> is not very realistic and it is certainly far down my list of concerns. 
>  I expect the price of tools is much more related to promoting the 
> "exploration" of the use of FPGAs.  If you even have to spend $100, that 
> makes for a barrier to anyone wanting to start testing the tools.  I ran 
> into this myself in jobs where I wanted to try something, but couldn't 
> get one dime spent.  

OK, but as I understand it Altera started distributing free versions,
and Xilinx followed, presumably for competitive reasons.

As you note, the free versions allowed exploration.

If one hadn't done it first, the other might not have. 

> I can always find a little free time to spend on 
> ideas, but spending money almost always goes through a review of some 
> sort where they want you to show why and the "why" is what you want to 
> determine.

The way free market is supposed to work.
 

-- glen