-
Nonsense. There is no real barrier to using an FPGA in an OSHW project that an OS toolchain would remove.
I could use this on a none x86 cpu and (with a lot of learning) port it to an OS that isn't Windows or Linux. If you can't see some possibilities opening up there, no matter how niche, that's a bit of a lack of imagination. -
The big-parts issue isn't really an issue here as we're talking parts with multi-hundred dollar price tags, in big BGA packages which need umpteen PCB layers to route. If you're making that kind of investment, a few $k on tools is chickenfeed. I suspect the reason for this is that they can use it to subsidise providing free tools to lower-end users.QuoteNonsense. There is no real barrier to using an FPGA in an OSHW project that an OS toolchain would remove. Everyone can access FPGA tools at minimal cost.
To be fair, the bigger devices are supported only by the costly versions of stuff - atleast for Xilinx. Dunno about the rest, Altera, erm, Intertra?.
I never really got this - what's the point of not publishing stuff like this? From a chip manufacturers point of view it seems the best course of action would be to ensure that ALL of my tools area available to everyone, free of charge. Or atleast MASSIVELY support open source initiatives like this.
The availability of free or cheaply priced tools is a big issue for me, I assume the same goes for others.QuoteI could use this on a none x86 cpu and (with a lot of learning) port it to an OS that isn't Windows or Linux. If you can't see some possibilities opening up there, no matter how niche, that's a bit of a lack of imagination.
I'm not saying that there aren't some niche situations where it might be interesting, just that these would be the exception, and existing tools are just fine for the vast majority of users, so the existence of OSS tools is a minimal benefit, to a few people.
The reason FPGAs aren't used very widely is nothing to do with tools, it's simply that they are only needed in niche applications. Availability of OSS tools won't change that.
-
The reason FPGAs aren't used very widely is nothing to do with tools, it's simply that they are only needed in niche applications. Availability of OSS tools won't change that.
In the hobbyist domain I'd say how overwhelming the tools can be is a serious barrier to entry. Something like this could lead to an Arduino style revolution (it has had it's upsides) for FPGAs. -
No it won't. Most hobbyists have no use for FPGAs.The reason FPGAs aren't used very widely is nothing to do with tools, it's simply that they are only needed in niche applications. Availability of OSS tools won't change that.
In the hobbyist domain I'd say how overwhelming the tools can be is a serious barrier to entry. Something like this could lead to an Arduino style revolution (it has had it's upsides) for FPGAs.
Although they are huge and clunky, you can install and use an existing FPGA toolchain pretty easily. The biggest hurdle by far is getting your head round using an HDL. That is where there is definitely scope for interesting things to be done, and that doesn't need anyone to spend time reinventing the wheel with the back-end tools as any "easy-to-use" front-end can output HDL or RTL to the existing toolchain.
-
Nonsense. There is no real barrier to using an FPGA in an OSHW project that an OS toolchain would remove. Everyone can access FPGA tools at minimal cost.
You're quite quick to call someone else's experience nonsense, aren't you? I don't understand why you feel so strongly against this. Likely, in 1987 people like you were arguing against Richard Stallman for starting gcc.
It's not just the cost that is problematic, it is also the license restrictions to distribution. Distributing, say, a VM or docker image with ready-made FPGA toolchain is usually not allowed. Neither is offering an automatic 'build server' for bitstreams. This is the problem Parallela bumped against, as well as some educational projects.QuoteThat is where there is definitely scope for interesting things to be done, and that doesn't need anyone to spend time reinventing the wheel with the back-end tools as any "easy-to-use" front-end can output HDL or RTL to the existing toolchain.
The one doesn't exclude the other. There's many people working on different projects...
-
Yes, when it's obviousNonsense. There is no real barrier to using an FPGA in an OSHW project that an OS toolchain would remove. Everyone can access FPGA tools at minimal cost.
You're quite quick to call someone else's experience nonsense, aren't you?
QuoteI don't understand why you feel so strongly against this. Likely, in 1987 people like you were arguing against Richard Stallman for starting gcc.
gcc is not a reasonable comparison. The potential user base is orders of magnitude smaller, and there are currently tools available at no cost that are perfectly adequate for the majority of that user base.Quote
and how many people is that actually useful for?
It's not just the cost that is problematic, it is also the license restrictions to distribution. Distributing, say, a VM or docker image with ready-made FPGA toolchain is usually not allowed. Neither is offering an automatic 'build server' for bitstreams. This is the problem Parallela bumped against, as well as some educational projects.Quote
The one doesn't exclude the other. There's many people working on different projects...
That is where there is definitely scope for interesting things to be done, and that doesn't need anyone to spend time reinventing the wheel with the back-end tools as any "easy-to-use" front-end can output HDL or RTL to the existing toolchain.
[/quote]
True but given a limited number of available man-hours, my argument is simply that those hours would be more useful to more people if they were spent making new front-end tools and new design flows than reinventing stuff that already exists in a form that is perfectly fine for the vast majority of potential users, and will get updated by the manufacturers for new devices long after OSS projects have stalled and been abandoned.
-
An open sourced FPGA toolchain could have a benefit. For instance Python is heavily used in scientific field, this could leverage on demand use of higher level libs like MyHDL, and produce bitstream. Decreasing the barrier of entry and streamlining the whole process. There is definitely room and demand for it. But not really for hardware design, more for performance computing.
I have to agree though for hardware design, it would be hard for a FOSS project to reach the quality and functionality of what's already provided by the FPGA manufacturers for free. -
An open sourced FPGA toolchain could have a benefit. For instance Python is heavily used in scientific field, this could leverage on demand use of higher level libs like MyHDL, and produce bitstream.
And what would be the advantage of that over feeding it into the existing tools?
-
Automated deployment for cloud compute. I think things are about to get interesting in the FPGA and x86 server market. With Intel buying Altera I could see an FPGA with x86 cores, used for hw acceleration of your compute clusters.An open sourced FPGA toolchain could have a benefit. For instance Python is heavily used in scientific field, this could leverage on demand use of higher level libs like MyHDL, and produce bitstream.
And what would be the advantage of that over feeding it into the existing tools?
Sort of how OpenCL is being used, except FPGA can offer distinct advantages, like low latency. Opening the bitstream for this use would help adoption since most of your cloud outhere runs on Linux and FOSS stack.
It wouldn't really change how one designs in FPGAs into their hardware, but it would open up FPGAs to new applications. -
Yes but in that example you'd almost certainly only be loading pre-compiled designs.
Automated deployment for cloud compute. I think things are about to get interesting in the FPGA and x86 server market. With Intel buying Altera I could see an FPGA with x86 cores, used for hw acceleration of your compute clusters.An open sourced FPGA toolchain could have a benefit. For instance Python is heavily used in scientific field, this could leverage on demand use of higher level libs like MyHDL, and produce bitstream.
And what would be the advantage of that over feeding it into the existing tools?
Sort of how OpenCL is being used, except FPGA can offer distinct advantages, like low latency.
It wouldn't really change how one designs in FPGAs into their hardware, but it would open up FPGAs to new applications.
There is no way we'd ever see an OSS solution for a device that complex anyway. -
Yes sorry I edited my response to include why I think it would be important. To help adoption, because most of your cloud runs Linux and the FOSS stack. Same reason Open CL exists over Cuda.
Yes but in that example you'd almost certainly only be loading pre-compiled designs.
Automated deployment for cloud compute. I think things are about to get interesting in the FPGA and x86 server market. With Intel buying Altera I could see an FPGA with x86 cores, used for hw acceleration of your compute clusters.An open sourced FPGA toolchain could have a benefit. For instance Python is heavily used in scientific field, this could leverage on demand use of higher level libs like MyHDL, and produce bitstream.
And what would be the advantage of that over feeding it into the existing tools?
Sort of how OpenCL is being used, except FPGA can offer distinct advantages, like low latency.
It wouldn't really change how one designs in FPGAs into their hardware, but it would open up FPGAs to new applications.
There is no way we'd ever see an OSS solution for a device that complex anyway. -
FPGA development environments are so universally awful that anything that can help spur innovation is a godsend.
-
Quote
Nonsense. There is no real barrier to using an FPGA in an OSHW project that an OS toolchain would remove. Everyone can access FPGA tools at minimal cost.
To be fair, the bigger devices are supported only by the costly versions of stuff - atleast for Xilinx. Dunno about the rest, Altera, erm, Intertra?.
I never really got this - what's the point of not publishing stuff like this? From a chip manufacturers point of view it seems the best course of action would be to ensure that ALL of my tools area available to everyone, free of charge. Or at least MASSIVELY support open source initiatives like this.
The availability of free or cheaply priced tools is a big issue for me, I assume the same goes for others.
The limits on size of 'free' versions isn't as big as it was even 5 years ago. Take for example Xilinx Vivado - the free version supports the XC7A200T part... 740 DSP blocks, quarter a million flip flips, 13Mb of on-chip RAM, 16 6Gb transceivers, PCIe, 500 I.O pins.
That is a LOT of stuff. What can't you build with that that doesn't need a team of full time engineers and enough financing to actually buy a license (which is rewarding Xilinx for their efforts, rather than just leaching
)?
-
FPGA development environments are so universally awful that anything that can help spur innovation is a godsend.
No argument there, but IMO the biggest problem is the archaic nature of the HDLs, and definitely an area where something new is well overdue.
Reinventing what's already there is just wasted effort and will not do anything to improve the awfulness.
Unless of course someone can come up with some magic solution to place & route much, much more quickly.
Just imagine how useful it would be to use all the power sitting in GPUs to get near-instant update of a device when you change logic onscreen...
-
FPGA development environments are so universally awful that anything that can help spur innovation is a godsend.
No argument there, but IMO the biggest problem is the archaic nature of the HDLs, and definitely an area where something new is well overdue.
Reinventing what's already there is just wasted effort and will not do anything to improve the awfulness.
Unless of course someone can come up with some magic solution to place & route much, much more quickly.
Just imagine how useful it would be to use all the power sitting in GPUs to get near-instant update of a device when you change logic onscreen...
Outside of hobby use it wouldn't be too useful at all. Unlike incremental software compilation, changes made higher up in a design force structural changes all the way through the design, and changes in the lowest levels could be unfairly constrained by what is already in place. It is most likely that any reasonable commercial design will use over 50% of some of the resources on a chip (otherwise you would use a smaller chip) and that doesn't leave much room for rip-up and place and route.
You would also have the problem that the performance of your design will depend on everything that has happened to the design beforehand - so you can't give a copy of the source to a co-worker and expect them to get the same results.
And I have to eat humble pie and say that Vivado isn't that bad (I didn't like it at first) - I'm currently working on a design using 90 DSP slices, running at 250MHz (about 0.13ns slack), and it build in under 5 minutes on my i3 laptop. Imagine if you were doing the equivalent of a PCB layout for ninety 100-pin chips and a few thousand bits of bubblegum logic... it is not just putting instructions and data into memory (which is all a s/w compiler has to).
And it is asking a bit much - Right I'm working on a design with 90 DSP splices, 18,000+ paths, running at 250MHz, with about 5% timing slack. -
No, I'm not talking incremental, I mean, you make a change to your HDL or whatever, and it recompiles, places, routes and downloads in a second or two.FPGA development environments are so universally awful that anything that can help spur innovation is a godsend.
No argument there, but IMO the biggest problem is the archaic nature of the HDLs, and definitely an area where something new is well overdue.
Reinventing what's already there is just wasted effort and will not do anything to improve the awfulness.
Unless of course someone can come up with some magic solution to place & route much, much more quickly.
Just imagine how useful it would be to use all the power sitting in GPUs to get near-instant update of a device when you change logic onscreen...
Outside of hobby use it wouldn't be too useful at all. Unlike incremental software compilation, changes made higher up in a design force structural changes all the way through the design, and changes in the lowest levels could be unfairly constrained by what is already in place. It is most likely that any reasonable commercial design will use over 50% of some of the resources on a chip (otherwise you would use a smaller chip) and that doesn't leave much room for rip-up and place and route.
You would also have the problem that the performance of your design will depend on everything that has happened to the design beforehand - so you can't give a copy of the source to a co-worker and expect them to get the same results.Quote
Is Vivado the new name for ISE, or something completely new?
And I have to eat humble pie and say that Vivado isn't that bad (I didn't like it at first)
If so what sort of differences are there?
-
FPGA development environments are so universally awful that anything that can help spur innovation is a godsend.
No argument there, but IMO the biggest problem is the archaic nature of the HDLs, and definitely an area where something new is well overdue.
The archaic nature of the HDLs? What archaic nature would this be...? -
Is Vivado the new name for ISE, or something completely new?
If so what sort of differences are there?
Vivado is the toolset for Xilinx's 7 series devices (Zynq, Aritx,...) . Much more oriented around building IP blocks with standard interfaces and joining them graphically to build your SoC or other design. It supports quite a high level of design automation (so when you add a GPIO IP block to your ARM SoC, it will connect up the AXI interconnects and insert any bridges and reset controllers you need and so on).
It also has support for high-level synthesis (i.e. a subset of C to HDL).
The tools are all quite integrated, so you can bounce between project, implemented design, RTL design, block-level design, simulation and hardware programming in the one application window. But you do have to drop out into Eclipse to do any S/W side of a design though. -
FPGA development environments are so universally awful that anything that can help spur innovation is a godsend.
No argument there, but IMO the biggest problem is the archaic nature of the HDLs, and definitely an area where something new is well overdue.
The archaic nature of the HDLs? What archaic nature would this be...?
The fact that the two major HDLs were initially defined before some of these kids were born? You know, like how there are kids who want to do full-scale object-oriented coding on an 8051. Or something.
I have no idea. VHDL does everything I need it to do. -
Speaking about VHDL as that's what I sort-of know...FPGA development environments are so universally awful that anything that can help spur innovation is a godsend.
No argument there, but IMO the biggest problem is the archaic nature of the HDLs, and definitely an area where something new is well overdue.
The archaic nature of the HDLs? What archaic nature would this be...?
no block comments, no #define, #include, compile-time macros
Having to hope that the synthesis process infers what you want instead of being able to specify things more simply & directly (e.g. stuff like async resets).
Yet another different comment symbol
No meaningful way (AFAICS) to easily manage build variants for different parts, pinouts etc. (more of an issue with the whole toolchain than the HDL)
I'll admit I don't use FPGAs that often and don't know VHDL inside out, but it just seems that I'm often finding that the sort of things that I do routinely in software projects are a total ball-ache to do.
A concrete example - I use Lattice Diamond but my previous experience of ISE seemed pretty much the same.
I have a design that can be used on one of two different PCBs, with a few different FPGAs, depending on pins and memory required for a particular build.
It already has a lot of paramaterization using VHDL constants ( much of which would have been easier with #ifdef type structures) , but what I'd like to be able to do is have a single #define in the top level source that would allow it to pull in the required set of pin definitions and define the FPGA type depending which PCB it will go on and how big a memory it needs.
And there isn't even a way to have it automatically download to a device on a successful build. or even beep at me to tell me it's done compiling. Pathetic.
-
Not every language has block comments; any editor that isn't incompetent can still comment off a block. You're the first person I've ever seen to claim not having macros makes it archaic, those are archaic features typically only provided by older languages. Async resets are easy to do, I don't know what you're on about there (though I'd not really recommend using them at all). Build variants are easily accomplished using generics.
And there isn't even a way to have it automatically download to a device on a successful build. or even beep at me to tell me it's done compiling. Pathetic.
buh, wha?? you're using a computer, dude, script it! -
Can you define pin settings in Verilog? I have not been able to figure it out. I am also using the Lattice toolchain. Been doing it from the spreadsheet view which I find really annoying. I have a KiCad project that knows all the pins, my CPLD pins depend on the board layout so I would really like KiCad to drive that, so I don't have to manually define them.
-
Not every language has block comments
I shouldn't have to change editors because of inadequacies in a language
; any editor that isn't incompetent can still comment off a block.QuoteAsync resets are easy to do, I don't know what you're on about there
I'm sure they are if you use VHDL regularly. As an occasional user it's the sort of thing I always have to look up, and find the syntax somewhat cumbersome for what should be a simple operationQuote
Power-up initialisation? Dealing with lost input clocks?
(though I'd not really recommend using them at all).
This would be less of an issue if it weren't for the the near-impossibility of easily specifying the logic state you want a node to be at powerup. The FPGA hardware initialises everything to a known state , but by the time the toolchain has had its way it can be anyone's guess what you end up with.QuoteBuild variants are easily accomplished using generics.
Build variants include FPGA type and pinouts. You should be able to specify these in the HDL.
I have a vague recollection of reading that in ISE there is a way to specify pin constraints in HDL but couldn't find it last time I looked. And even then I don't think this was amenable to selecting with compile-time constantsAnd there isn't even a way to have it automatically download to a device on a successful build. or even beep at me to tell me it's done compiling. Pathetic.
This is the sort of stuff that's been standard in MCU environments for ever. FPGA tools are pretty retarded in this sort of useability aspect Again. I shouldn't have to dick around with scripts to get what should be a standard feature of any sane dev environment.
buh, wha?? you're using a computer, dude, script it!
And don't get me started with the ridiculously limited ways to specify ROM data for BlockRAM (in Lattice Diamond at least). On what planet would someone call a "binary" file a text file full of binary strings...? ...And having to specify ROM data in the native bus width rather than the width you've generated it... -
Not every language has block comments
I shouldn't have to change editors because of inadequacies in a language
; any editor that isn't incompetent can still comment off a block.
Is it too bloody much that you use the right hammer for your nail before you start whinging about the nail?QuoteThis would be less of an issue if it weren't for the the near-impossibility of easily specifying the logic state you want a node to be at powerup.
erm.?Code: [Select]signal foo: std_ulogic := '1';
There, done.QuoteBuild variants include FPGA type and pinouts. You should be able to specify these in the HDL.
This is done in the constraints file. I really can't imagine you have too much issue with having one separate file for that? -
Speaking about VHDL as that's what I sort-of know...
no block comments,
As already noted, that's easily handled by your favorite editor. But it was added to VHDL-2008! It's up to the tool vendors to implement it (as well as other new features).Quoteno #define,
Why do you need #define? If you want to #define a constant, you can do so either in the architecture's declarative block (before the first begin), or you can pass one through an entity interface as a generic.
You can also create an enumerated type.
If you want to #define a macro, I suppose I should ask: why?Quote#include
Why do you need to #include anything? If you wish to "include" a component declaration, you should be using the direct instantiation of an entity idiom instead, such as:
u_foo : entity work.foo port map (bar => bar, bletch => bletch);
This has been in the language since VHDL-93.
If you wish to #include constants, type definitions, function and procedure declarations, use packages, which have been in the language since the beginning.Quotecompile-time macros
See above.QuoteHaving to hope that the synthesis process infers what you want instead of being able to specify things more simply & directly (e.g. stuff like async resets).
If you code an async reset, you get an async reset. There's no hoping involved. Now, yes, we know that the synthesis tools have a switch which will tell them to convert async resets into sync resets, but that's off by default and of course you are better off coding that sort of thing directly.QuoteNo meaningful way (AFAICS) to easily manage build variants for different parts, pinouts etc. (more of an issue with the whole toolchain than the HDL)
With generics and generate statements you can manage quite a bit. For example, I have this Camera Link transmitter module I wrote initially for Virtex 4, and I ported it to Spartan 6. what's the difference? XST is too stupid to infer DDR output (and input) flops, so you have to instantiate them. And the library element is not the same for the two families. So a simple generic and generate combo chooses the correct primitive.
As for different pinouts, you are constrained by the family architectures, and which pins support specific features (global clock inputs, differential pairs, hard IP blocks like memory controllers, whatever), and you are correct, that's not really a synthesis issue, more of an implementation-tool issue. So you have to maintain a constraint file with pinouts and timing constraints.QuoteI'll admit I don't use FPGAs that often and don't know VHDL inside out, but it just seems that I'm often finding that the sort of things that I do routinely in software projects are a total ball-ache to do.
I do FPGAs every day, and I know VHDL as well as anyone who's used it forever can know it, I guess.
I suppose that I can say that I find some of the things one needs to do going between different processors and compilers can be a total ball-ache to do. Oh, this ARM needs this sort of initialization, and code I wrote for my 8051 can't be directly ported to ARM because the 8051 compiler needs to care about different memory spaces where ARM doesn't, and what is this linker-description file stuff, anyway?QuoteA concrete example - I use Lattice Diamond but my previous experience of ISE seemed pretty much the same.
I have a design that can be used on one of two different PCBs, with a few different FPGAs, depending on pins and memory required for a particular build.
It already has a lot of paramaterization using VHDL constants ( much of which would have been easier with #ifdef type structures) , but what I'd like to be able to do is have a single #define in the top level source that would allow it to pull in the required set of pin definitions and define the FPGA type depending which PCB it will go on and how big a memory it needs.
Without seeing the design, I really can't suggest better ways of doing what you want. But I do think that setting generics at the top level and making sure the synthesizer can find the correct entity source files and such, you can get there.
What I have done when my (Xilinx) designs need to support different board configurations (depending on the number of ADC channels, etc) is to write the source code to cover the different configurations (again, top-level generics and generate statements as needed), and each configuration has its own .xise and .ucf files. The .xise file has correct settings for the generics which filter down to the source, and the .ucf file has the pinouts defined for each variant. Then of course I have to build each variant, but that's not really a big deal.QuoteAnd there isn't even a way to have it automatically download to a device on a successful build.
Most of the time, I'm not even connected to the real hardware. So that's not very interesting.Quoteor even beep at me to tell me it's done compiling.
I have the sound turned down on the machine. if everyone's computer beeped every time it did something, there'd be cacophony here. But what I would like to see is an option which will make the entire screen blink brightly and annoyingly so that when the boss walks by, he'll see that the computer is actually doing something and I'm not just just staring into space!