EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

Phrasing!

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - Phrasing!

Goto page Previous  1, 2, 3

mac
Guest

Fri Dec 02, 2016 12:54 am   



> But is *is* like writing C per-ANSI, when every compiler had its own variant.

pre-ANSI

The churn in language revisions isn't helping either

KJ
Guest

Fri Dec 02, 2016 1:32 pm   



On Friday, December 2, 2016 at 3:10:19 AM UTC-5, o pere o wrote:
Quote:

This is a point, although a weak one. The same should also happen to the
microcontroller industry... but does not. They are quite happy selling
chips that are being programmed by the open-sourced gcc toolchain.

Also consider that on the gcc side of things that they have a lot of people who know how to write software that are writing and developing the gcc software. There aren't nearly as many people who know how to write software working on software stuff for hardware like FPGAs. Witness that we don't have much of anything other than GHDL as a basic simulator. Development on that is up to the whims of one person who chooses to work on it (or not in which case everything stops...as it has of late).


It wouldn't surprise me if FPGA companies probably consider that the open source community would take forever to develop anything.

Kevin

o pere o
Guest

Fri Dec 02, 2016 3:10 pm   



On 26/11/16 05:57, rickman wrote:
Quote:
On 11/25/2016 4:26 PM, Tim Wescott wrote:

Reading this whole thread, I'm reminded of a gripe I have about the FPGA
manufacturers, or at least Xilinx and Altera.

If they -- or just any one of them -- would PUBLISH the details of how
their bitfiles map to the workings of their FPGAs, then all of a sudden
that company's stuff would be the subject of all the intensive university
research on FPGA optimization that you might desire, and possibly even
see an open-source tools ecology grow around its parts.

It wouldn't immediately lead to nirvana, but it may at least lead to more
and better optimization, and lots of people experimenting with different
optimization approaches.

Let's say I am Xilinx... I have a bazillion dollars of investment into
my products and the support software. I sell to large companies who
want reliable, consistent products. I open up my chip design and a
bunch of university idealists start creating tools for my devices. The
tools work to varying degrees and are used for a number of different
designs by a wide variety of groups.

So what happens when some of these groups report problems "with the
chips"? Are these problems really with the chips or with the tools? If
any of these groups ask us to deal with these problems, how do we begin?

In other words, how do we keep these tools from causing problems with
our reputation?


This is a point, although a weak one. The same should also happen to the
microcontroller industry... but does not. They are quite happy selling
chips that are being programmed by the open-sourced gcc toolchain.

Pere

Theo Markettos
Guest

Fri Dec 02, 2016 6:08 pm   



o pere o <me_at_somewhere.net> wrote:
Quote:
This is a point, although a weak one. The same should also happen to the
microcontroller industry... but does not. They are quite happy selling
chips that are being programmed by the open-sourced gcc toolchain.


An ISA is an API. A lot of work goes on implementing the microarchitecture
which implements the API, either in hardware or software (microcode).
Another lot of work goes on proving that the implementation matches the API
and is bug-free (and 'halt and catch fire' is definitely a bug).

FPGA silicon doesn't have an API, you just have the raw transistors to
control. The main safeguards to prevent them generating flame-inducing
configurations (or more prosaically customer returns) are in the tools.

You can put an API on top of an FPGA (eg as the 'FPGA virtualisation' folks
do) but the performance and flexibility impact is substantial. As far as
I'm aware of the current state of FPGA virtualisation (admittedly not that
much), there's nothing there that would be usable in a product anytime soon.

Theo

rickman
Guest

Fri Dec 02, 2016 6:58 pm   



On 12/2/2016 3:10 AM, o pere o wrote:
Quote:
On 26/11/16 05:57, rickman wrote:
On 11/25/2016 4:26 PM, Tim Wescott wrote:

Reading this whole thread, I'm reminded of a gripe I have about the FPGA
manufacturers, or at least Xilinx and Altera.

If they -- or just any one of them -- would PUBLISH the details of how
their bitfiles map to the workings of their FPGAs, then all of a sudden
that company's stuff would be the subject of all the intensive
university
research on FPGA optimization that you might desire, and possibly even
see an open-source tools ecology grow around its parts.

It wouldn't immediately lead to nirvana, but it may at least lead to
more
and better optimization, and lots of people experimenting with different
optimization approaches.

Let's say I am Xilinx... I have a bazillion dollars of investment into
my products and the support software. I sell to large companies who
want reliable, consistent products. I open up my chip design and a
bunch of university idealists start creating tools for my devices. The
tools work to varying degrees and are used for a number of different
designs by a wide variety of groups.

So what happens when some of these groups report problems "with the
chips"? Are these problems really with the chips or with the tools? If
any of these groups ask us to deal with these problems, how do we begin?

In other words, how do we keep these tools from causing problems with
our reputation?


This is a point, although a weak one. The same should also happen to the
microcontroller industry... but does not. They are quite happy selling
chips that are being programmed by the open-sourced gcc toolchain.


I think this is apples and oranges. It is easy to look at the output of
a compiler and see what it is doing. The details of the configuration
file for an FPGA is not so easy to analyze. Also, the configuration bit
stream isn't just a matter of telling the chip what to do, it can set up
internal conflicts that can damage the chip.

Even if the FPGA vendors release their technical info on the
configuration bit stream, it is a very complex thing to deal with.

--

Rick C

KJ
Guest

Fri Dec 02, 2016 10:41 pm   



On Friday, November 25, 2016 at 4:26:11 PM UTC-5, Tim Wescott wrote:
Quote:

If they -- or just any one of them -- would PUBLISH the details of how
their bitfiles map to the workings of their FPGAs, then all of a sudden
that company's stuff would be the subject of all the intensive university
research on FPGA optimization that you might desire, and possibly even
see an open-source tools ecology grow around its parts.


I kind of doubt that would happen. I don't think there are enough hardware knowledgeable folks who can write good software. If there were, we would all be simulating with some open source VHDL+Verilog simulator that puts Modelsim and Aldec to shame [1]. But instead most people I think are using Modelsim/Aldec or some lame simulator that comes bundled with the tools.

Since there apparently aren't many folks diving in to develop something that would benefit many with a decent simulator, why would you think there would be enough to dive in and help develop something that benefits a subset of that market?

Open source developers tend to use their tools in their day to day work as well. Those developers 'only' need to be good at developing software in order to develop open source stuff. When you talk about open source tools to be used for hardware development, you would want to have someone good at developing hardware and software so that the tools they develop they would then use day to day. If nothing else, there are fewer of those folks that have both skills and, based on the lack of developers for open source simulators, I think there just isn't the critical mass.

Manufacturers keeping their details secret could be seen as nothing more than their seeing that there aren't enough people out there who could even develop what is needed in an open source scenario. So they pay people to develop what they need.

Quote:
It wouldn't immediately lead to nirvana, but it may at least lead to more
and better optimization, and lots of people experimenting with different
optimization approaches.

I know you're not holding your breath waiting for that nirvana...but I'd wager that you will have taken your last breath long before such nirvana was reached.


Kevin Jennings

[1] Yes I know about GHDL and it is and appears to have always been a one man band. The original band member left the band and years later someone else picked it up. Last two releases are 0.31 released in Oct-2015 and 0.33 in Dec-2015, nothing new in about 12 months and counting. It is still not up to release 1.0 and there will be another revision to the VHDL standard in 2017. One person can only do so much...in addition to doing something that puts food on the table.

Brian Davis
Guest

Sat Dec 03, 2016 2:28 am   



On Friday, December 2, 2016 at 3:41:04 PM UTC-5, KJ wrote:
Quote:

[1] Yes I know about GHDL <snip
Last two releases are 0.31 released in Oct-2015 and 0.33 in Dec-2015,
nothing new in about 12 months and counting.

Tristan moved the development to GitHub:
https://github.com/tgingold/ghdl/releases

-Brian

KJ
Guest

Sat Dec 03, 2016 2:52 am   



On Friday, December 2, 2016 at 7:28:42 PM UTC-5, Brian Davis wrote:
Quote:
On Friday, December 2, 2016 at 3:41:04 PM UTC-5, KJ wrote:

[1] Yes I know about GHDL <snip
Last two releases are 0.31 released in Oct-2015 and 0.33 in Dec-2015,
nothing new in about 12 months and counting.

Tristan moved the development to GitHub:
https://github.com/tgingold/ghdl/releases


That's good to hear, now you need to let Google in on the secret. I do see there is mention of the move to Github on the summary page on SourceForge page, but maybe you should consider pulling all the old stuff down from SourceForge and put some more redirection links to the new home.

Kevin Jennings

Kevin Neilson
Guest

Sat Dec 03, 2016 4:32 am   



> I kind of doubt that would happen. I don't think there are enough hardware knowledgeable folks who can write good software. If there were, we would all be simulating with some open source VHDL+Verilog simulator that puts Modelsim and Aldec to shame [1]. But instead most people I think are using Modelsim/Aldec or some lame simulator that comes bundled with the tools.

I agree. It doesn't seem likely that there would be a lot of people versed in low-level silicon design and high-level software and who would also be willing to put in a lot of time for free.

I don't suppose there is anything stopping somebody from making a synthesizer--you can just convert RTL into structural HDL containing primitives--but I don't see a lot of free synthesizers around.

Jan Coombs
Guest

Sat Dec 03, 2016 8:44 pm   



On Fri, 2 Dec 2016 03:32:16 -0800 (PST)
KJ <kkjennings_at_sbcglobal.net> wrote:

Quote:
Also consider that on the gcc side of things that they have a
lot of people who know how to write software that are writing
and developing the gcc software. There aren't nearly as many
people who know how to write software working on software
stuff for hardware like FPGAs. Witness that we don't have
much of anything other than GHDL as a basic simulator.
Development on that is up to the whims of one person who
chooses to work on it (or not in which case everything
stops...as it has of late).


The MyHDL community is vibrant [1], and this fast[2] simulator
exports Verilog and VHDL for synthesis.


Quote:
It wouldn't surprise me if FPGA companies probably consider
that the open source community would take forever to develop
anything.


I'm using open source tools [3]. As for community, there are many
users, not sure about developers, maybe clues here [4].

Clifford did/does warn about frying chips, but the value of the
project far exceeds the cost of a few sacrificial ICs.

Jan Coombs
--
[1] http://myhdl.org/
[2] http://myhdl.org/docs/performance.html
[3] http://www.clifford.at/icestorm/
[4] https://www.reddit.com/r/yosys/comments/4ocilz/icestorm_adding_support_for_new_devices_part_1/

Goto page Previous  1, 2, 3

elektroda.net NewsGroups Forum Index - FPGA - Phrasing!

Ask a question - edaboard.com

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map