Finally! A Completely Open Complete FPGA Toolchain

[rickman]

I am very impressed. I was reading about Antti's incredibly tiny FPGA
project board and saw a mention of a FOSS FPGA toolchain. Not just the
compiler, but the entire bitstream generation!

http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-that-small/

Several people have built on each other's work to provide "a fully open
source Verilog to bitstream development tool chain for the Lattice
iCE40LP with support for more devices in the works."

http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/

https://github.com/cseed/arachne-pnr

I haven't tried any of it yet, but I am very impressed that they are
reverse engineering the devices so that they can generate bit streams
and not rely on the vendor.

--

Rick

 

[rickman]

On 7/27/2015 12:34 PM, rickman wrote:

I am very impressed. I was reading about Antti's incredibly tiny FPGA
project board and saw a mention of a FOSS FPGA toolchain. Not just the
compiler, but the entire bitstream generation!

http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-that-small/


Several people have built on each other's work to provide "a fully open
source Verilog to bitstream development tool chain for the Lattice
iCE40LP with support for more devices in the works."

http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/

https://github.com/cseed/arachne-pnr

I haven't tried any of it yet, but I am very impressed that they are
reverse engineering the devices so that they can generate bit streams
and not rely on the vendor.

I found another link relating to the tools called "IceStorm".

http://www.clifford.at/icestorm/

--

Rick

 

[Tim Wescott]

On Mon, 27 Jul 2015 12:34:21 -0400, rickman wrote:

I am very impressed. I was reading about Antti's incredibly tiny FPGA
project board and saw a mention of a FOSS FPGA toolchain. Not just the
compiler, but the entire bitstream generation!

http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-
that-small/

Several people have built on each other's work to provide "a fully open
source Verilog to bitstream development tool chain for the Lattice
iCE40LP with support for more devices in the works."

http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/

https://github.com/cseed/arachne-pnr

I haven't tried any of it yet, but I am very impressed that they are
reverse engineering the devices so that they can generate bit streams
and not rely on the vendor.

Kewl.

It'll be even more kewl if it shames the vendors into being open with
their bitstream specifications. I have no idea why they seem to feel
this needs to be held so close to their chests.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[rickman]

On 7/27/2015 1:57 PM, Tim Wescott wrote:

On Mon, 27 Jul 2015 12:34:21 -0400, rickman wrote:

I am very impressed. I was reading about Antti's incredibly tiny FPGA
project board and saw a mention of a FOSS FPGA toolchain. Not just the
compiler, but the entire bitstream generation!

http://hackaday.com/2015/07/03/hackaday-prize-entry-they-make-fpgas-
that-small/

Several people have built on each other's work to provide "a fully open
source Verilog to bitstream development tool chain for the Lattice
iCE40LP with support for more devices in the works."

http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/

https://github.com/cseed/arachne-pnr

I haven't tried any of it yet, but I am very impressed that they are
reverse engineering the devices so that they can generate bit streams
and not rely on the vendor.

Kewl.

It'll be even more kewl if it shames the vendors into being open with
their bitstream specifications. I have no idea why they seem to feel
this needs to be held so close to their chests.

I seriously doubt this will ever happen. They have all done this nearly
100% of the time and I'm sure they are convinced it is the best way to
do business. From what they have said their concern is that with open
source tools their hardware will be subject to "problems" caused by poor
tools. Or maybe they limit access to chip features through the tools
which they couldn't do with FOSS tools. I seem to recall someone
ranting that a line of Altera parts had some devices which were labeled
as smaller chips but would load and run a bitstream for a larger part.
I expect this would show up quickly and clearly if the tools were FOSS.

Those who have been in this business long enough may remember the line
of parts Xilinx made specifically to support an open bit stream. It was
popular with academia and a number of papers were written about
researchy things you might do with it. I'm not sure what Xilinx's
motive was for producing these chips, but they dropped the line and
crushed the molds. I'm pretty sure there is no mention of these parts
anywhere on their site now. Or did I only dream all of that?

--

Rick

 

[Tomas D.]

Those who have been in this business long enough may remember the line of
parts Xilinx made specifically to support an open bit stream. It was
popular with academia and a number of papers were written about researchy
things you might do with it. I'm not sure what Xilinx's motive was for
producing these chips, but they dropped the line and crushed the molds.
I'm pretty sure there is no mention of these parts anywhere on their site
now. Or did I only dream all of that?

Maybe you will also be interested in this:
https://recon.cx/2015/slides/recon2015-18-andrew-zonenberg-From-Silicon-to-Compiler.pdf

Tomas D.

 

[Brian Drummond]

On Mon, 27 Jul 2015 14:30:34 -0400, rickman wrote:

On 7/27/2015 1:57 PM, Tim Wescott wrote:
On Mon, 27 Jul 2015 12:34:21 -0400, rickman wrote:

I am very impressed. I was reading about Antti's incredibly tiny FPGA
project board and saw a mention of a FOSS FPGA toolchain. Not just
the compiler, but the entire bitstream generation!

http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-
fpgas/

Excellent! Though I'm not surprised it's Lattice, I vaguely recall
looking through an early (pre-2000) toolchain of theirs and thinking the
details were closer to the surface than with other vendors.

Those who have been in this business long enough may remember the line
of parts Xilinx made specifically to support an open bit stream. It was
popular with academia and a number of papers were written about
researchy things you might do with it. I'm not sure what Xilinx's
motive was for producing these chips, but they dropped the line and
crushed the molds. I'm pretty sure there is no mention of these parts
anywhere on their site now. Or did I only dream all of that?

Indeed you didn't dream the XC6200 series. It wasn't so much that Xilinx
developed them, as they bought the company that did (Algotronics or
Algotronix I think, based in Edinburgh). Presumably they bought them for
tech in general or possibly some key patents rather than the specific
device family.

Which was something of a dead end in other respects, too fine grained (I
believe' 1 gate, 1FF per CLB). Much simpler and more regular, but
wouldn't scale too well to million-CLB devices dominated by routing,
where the XC4000 and later devices would give the same capacity with a
much smaller and cheaper die.

I think it was that simple regular structure that made opening the
bitstream format attractive, as well as killing the device long-term.

You may also recall a company that successfully reverse-engineered the
bitstream for Xilinx devices, and started to market their own independent
toolchain.

Yup, Xilinx bought them too. But their name lives on in the .ncd (neocad)
file extension.

-- Brian

 

[rickman]

On 7/28/2015 6:06 AM, Brian Drummond wrote:

On Mon, 27 Jul 2015 14:30:34 -0400, rickman wrote:

On 7/27/2015 1:57 PM, Tim Wescott wrote:
On Mon, 27 Jul 2015 12:34:21 -0400, rickman wrote:

I am very impressed. I was reading about Antti's incredibly tiny FPGA
project board and saw a mention of a FOSS FPGA toolchain. Not just
the compiler, but the entire bitstream generation!

http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-
fpgas/


Excellent! Though I'm not surprised it's Lattice, I vaguely recall
looking through an early (pre-2000) toolchain of theirs and thinking the
details were closer to the surface than with other vendors.

Those who have been in this business long enough may remember the line
of parts Xilinx made specifically to support an open bit stream. It was
popular with academia and a number of papers were written about
researchy things you might do with it. I'm not sure what Xilinx's
motive was for producing these chips, but they dropped the line and
crushed the molds. I'm pretty sure there is no mention of these parts
anywhere on their site now. Or did I only dream all of that?

Indeed you didn't dream the XC6200 series. It wasn't so much that Xilinx
developed them, as they bought the company that did (Algotronics or
Algotronix I think, based in Edinburgh). Presumably they bought them for
tech in general or possibly some key patents rather than the specific
device family.

Which was something of a dead end in other respects, too fine grained (I
believe' 1 gate, 1FF per CLB). Much simpler and more regular, but
wouldn't scale too well to million-CLB devices dominated by routing,
where the XC4000 and later devices would give the same capacity with a
much smaller and cheaper die.

I think it was that simple regular structure that made opening the
bitstream format attractive, as well as killing the device long-term.

You may also recall a company that successfully reverse-engineered the
bitstream for Xilinx devices, and started to market their own independent
toolchain.

It has been a very long time, but I don't think NeoCAD was spitting out
bitstreams for Xilinx parts where they? I may not remember it right,
but I thought their claim to fame was their router which did a better
job than the Xilinx tools which is why Xilinx bought them. Rather than
bury the NeoCAD tools and moving on, they shipped the NeoCAD tools as
their main tool. They reverse engineered the routing I know. I guess
it wouldn't be so hard to figure out the bit stream too.

I recall that NeoCAD was supporting other companies because they
realized what a large job it was to write their own tools. So other new
entries to the market used NeoCAD as their only tool. There were
clauses in place to give them rights to the software if NeoCAD was
bought by a competitor, which is what happened. I'm not sure that was
much solace since they all ended up having to support their own software
at that point which is what they were trying to get away from.

Yup, Xilinx bought them too. But their name lives on in the .ncd (neocad)
file extension.

I seem to recall having the NeoCAD tools for some product other than
Xilinx. It may be the ORCA devices which Lucent produced with their
license from Xilinx. Not an XC4000 clone, but used Xilinx patents with
similar functionality. I seem to recall they had the first CLBs where
all components were not equivalent. Lattice does that in several of
their FPGA lines now that they have the Lucent FPGA products and Xilinx
licenses.

I recall that Altera has terms in their software to limit what you can
do with the bit stream. If you want to make an ASIC you *have* to come
to them. That killed a company who was providing exactly that service,
bit stream to ASIC. Do all the FPGA makers do that? I would think that
alone would be reason enough to reverse engineer the bit stream. That
company could then produce the bit stream themselves which would retain
the 1:1 relation between your verified FPGA design and the ASIC.

Maybe that is why FPGA companies don't want FOSS tools? It would take
away their ASIC business. Is that very popular anymore? I haven't seen
it promoted in years.

--

Rick

 

[Jan Coombs]

On Tue, 28 Jul 2015 13:32:39 -0400
rickman <gnuarm@gmail.com> wrote:

I recall that NeoCAD was supporting other companies because
they realized what a large job it was to write their own
tools. So other new entries to the market used NeoCAD as
their only tool. There were clauses in place to give them
rights to the software if NeoCAD was bought by a competitor,
which is what happened. I'm not sure that was much solace
since they all ended up having to support their own software
at that point which is what they were trying to get away from.

Yup, Xilinx bought them too. But their name lives on in
the .ncd (neocad) file extension.

I seem to recall having the NeoCAD tools for some product
other than Xilinx. It may be the ORCA devices which Lucent
produced with their license from Xilinx. Not an XC4000 clone,
but used Xilinx patents with similar functionality. I seem to
recall they had the first CLBs where all components were not
equivalent. Lattice does that in several of their FPGA lines
now that they have the Lucent FPGA products and Xilinx
licenses.

And NeoCAD is still around:

************************************************************
** Lattice Synthesis Engine **
************************************************************

synthesis -f "spi12_impl1_lattice.synproj"
synthesis: version Diamond (64-bit) 3.4.0.80

Copyright (c) 1991-1994 by NeoCAD Inc. All rights reserved.
Copyright (c) 1995 AT&T Corp. All rights reserved.
Copyright (c) 1995-2001 Lucent Technologies Inc. All rights
reserved. Copyright (c) 2001 Agere Systems All rights reserved.
Copyright (c) 2002-2014 Lattice Semiconductor Corporation, All
rights reserved. Tue Jul 28 19:53:33 2015

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

 

[Jan Coombs]

On Tue, 28 Jul 2015 10:06:48 +0000 (UTC)
Brian Drummond <brian@shapes.demon.co.uk> wrote:

On Mon, 27 Jul 2015 14:30:34 -0400, rickman wrote:

Those who have been in this business long enough may
remember the line of parts Xilinx made specifically to
support an open bit stream. [...] I'm pretty sure there
is no mention of these parts anywhere on their site now. Or
did I only dream all of that?

Indeed you didn't dream the XC6200 series. It wasn't so much
that Xilinx developed them, as they bought the company that
did (Algotronics or Algotronix I think, based in Edinburgh).
Presumably they bought them for tech in general or possibly
some key patents rather than the specific device family.

Which was something of a dead end in other respects, too fine
grained (I believe' 1 gate, 1FF per CLB). Much simpler and
more regular, but wouldn't scale too well to million-CLB
devices dominated by routing, where the XC4000 and later
devices would give the same capacity with a much smaller and
cheaper die.

How about half a half a LUT or FF per CLB then?

The Microsemi "IGLOO nano Low Power Flash" FPGAs are very
similar in size and capability to the Lattice iCE40 range,
except:

The basic building block is either a flop or a LUT3 equivalent
circuit, and these are then grouped into 8x8 blocks. [1]

Innovation seems to come from smaller companies: as Lattice
inherited the iCE40 series from SiliconBlue, Microsemi
got the IGLOO parts from Actel, and the technology seen
even earlier with ConcurrentLogic.

An open-source toolchain for the IGLOO parts could be an
unusually powerful tool in the hands of a creative designer.

Jan Coombs
--
[1] pg 73 of
http://www.microsemi.com/document-portal/doc_view/130695-igloo-nano-low-power-flash-fpgas-datasheet

email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk

 

[rickman]

On 7/28/2015 3:55 PM, Jan Coombs <Jan-54 wrote:

On Tue, 28 Jul 2015 10:06:48 +0000 (UTC)
Brian Drummond <brian@shapes.demon.co.uk> wrote:

On Mon, 27 Jul 2015 14:30:34 -0400, rickman wrote:

Those who have been in this business long enough may
remember the line of parts Xilinx made specifically to
support an open bit stream. [...] I'm pretty sure there
is no mention of these parts anywhere on their site now. Or
did I only dream all of that?

Indeed you didn't dream the XC6200 series. It wasn't so much
that Xilinx developed them, as they bought the company that
did (Algotronics or Algotronix I think, based in Edinburgh).
Presumably they bought them for tech in general or possibly
some key patents rather than the specific device family.

Which was something of a dead end in other respects, too fine
grained (I believe' 1 gate, 1FF per CLB). Much simpler and
more regular, but wouldn't scale too well to million-CLB
devices dominated by routing, where the XC4000 and later
devices would give the same capacity with a much smaller and
cheaper die.

How about half a half a LUT or FF per CLB then?

The Microsemi "IGLOO nano Low Power Flash" FPGAs are very
similar in size and capability to the Lattice iCE40 range,
except:

The basic building block is either a flop or a LUT3 equivalent
circuit, and these are then grouped into 8x8 blocks. [1]

Innovation seems to come from smaller companies: as Lattice
inherited the iCE40 series from SiliconBlue,

I wouldn't say Lattice "inherited" the iCE40 family. That was what they
bought, the rest of the SiBlue company came for free.

Microsemi
got the IGLOO parts from Actel, and the technology seen
even earlier with ConcurrentLogic.

I don't think Concurrent Logic ended up in the hands of Actel. I know
they were bought by Atmel and died a very slow death of being unfunded.
I received training from the guy at Atmel who was the champion of that
line. They never made an effort to keep up with process technology
advances to reduce the costs. That said, I expect they knew the way to
go was something more like the Xilinx/Altera routes. The fine grained
architecture without routing resources just won't work for larger
designs. As Xilinx used to say, "We sell you the routing and give you
the logic for free."

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?

--

Rick

 

[Jan Coombs]

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

 

[rickman]

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.

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

ok

--

Rick

 

[Aleksandar Kuktin]

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.

 

[rickman]

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

 

[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

 

[rickman]

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

 

[Aleksandar Kuktin]

The quoted post has beed turned upside-down for the purposes of my typing.

On Wed, 05 Aug 2015 18:50:11 -0400, rickman wrote:

> Maybe I just don't have enough imagination.

A distinct possibility.

On Wed, 05 Aug 2015 18:50:11 -0400, rickman wrote:

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.

Few matter. How many ISA designers are there? Yet, if they get good tools
that let them creatively hack out the solution, we're all better of. Same
with random dudes banging on some FPGA somewhere. You never know where
the next thing you want will appear, and having good peer-reviewed tools
creates more potential for good stuff to be made.

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.

Maybe you just didn't try hard enough? Maybe you did but didn't notice
you found a gaping bug in vendor 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.

Maybe you would be able to generate a FPGA handheld device that can
reconfigure itself on the fly. Like a smartphone^H^H^H^H^H^H^H^H^H^H
PDA^H^H^H trikoder that runs on some energy-efficient MIPS and that has a
scriptable (meaning CLI) synthesizer that you can feed random Verilog
sources and then instantiate an Ethernet device so you can jack yourself
in while at home, a FM radio to listen to while driving down the road, a
TV receiver with HDMA output so you can view the news and maybe a
vibrator or something for the evening.

Anyway, that's what I want to have and can't right now but COULD have
with FOSS tools (since I'm not gonna use QEMU to instantiate a VM so I
could synthesize on my phone).

This resulted in some quite unusual optimizations in SDCC currently
not found in any other compiler.

Okay, now we need to check out SDCC.

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.

But they will happen nevertheless.