FPGA Market Entry Barriers

On Friday, October 26, 2018 at 3:24:34 PM UTC-4, Jecel wrote:
> Niches have to be large enough to allow the costs of the masks and engineering to be recovered.
> 
> The use of open source tools let the ICE40 be used in applications such as Raspberry Pi "hats", but the 8Kluts limit is restricting this niche.

This isn't a niche, it would need to grow to be a micro-niche.  No FPGA vendor even thinks about this. 


> Some hobbyists long for DIP packages and 5V i/o. Though this is a tiny niche, using an obsolete node (like 250nm or 350nm) might make crowdfunding practical. It would probably be more popular than 
> 
> https://www.crowdsupply.com/chips4makers/retro-uc

Time expired with only 18% funding raised.  :(  

Not sure you need to go way up to 350 nm.  I expect the fab costs at 150 aren't so bad.  That equipment was amortized a long time ago.  I guess the real issue is mask costs.  Not sure how bad that is at 150 nm, but I believe you can still support 5 volt I/Os since many MCUs do it.  


> About SiliconBlue, part of their motivation were the expiration of a bunch of FPGA patents. Even more have expired since then.

That may be, but expired patents aren't really significant.  The basic functionality of the LUT/FF and routing have been available for quite some time now.  The details of FPGA architectures only matter when you are competing head to head.  That's why Silicon Blue focused on a market segment that was ignored by the big players.  The big two chase the telecom market with max capacity, high pin count barn burners and the other markets are addressed with the same technology making it impossible to compete in the low power areas.  In the end no significant user who is considering an iCE40 part even looks at a part from Xilinx or Altera. 

Rick C.

> https://www.xilinx.com/video/hardware/vivado-hls-in-depth-technical-overview.html
> 
> After watching this consider what a top of the range HLS tool can do.
> 

I know you're joking about HLS but the whole FPGA market is limited because any real work must be done by experiences specialists working at a very low level of abstraction.  It really does take months to do what you can do in Matlab in a couple of hours.  It's not really any different in that respect than it was fifteen years ago.  The market would be so much bigger if things were just a bit easier.  I haven't figured out if this is because it's an inherently difficult problem or if the tool designers aren't that skilled.  A little of both, I think.  I still think the people working on HLS are going in the wrong direction and need to spend more time refining the HDL tools.  They aim too high and fail utterly.  Why can't I infer a FIFO?  Just start with that.  The amount of time I spend on very basic structures is crazy.  I don't think any of this will change in the near future, though.  

(PS, I know you were probably actually serious about HLS.)

> That may be, but expired patents aren't really significant.  The basic functionality of the LUT/FF and routing have been available for quite some time now.  The details of FPGA architectures only matter when you are competing head to head.  That's why Silicon Blue focused on a market segment that was ignored by the big players.  The big two chase the telecom market with max capacity, high pin count barn burners and the other markets are addressed with the same technology making it impossible to compete in the low power areas.  In the end no significant user who is considering an iCE40 part even looks at a part from Xilinx or Altera. 
> 
> Rick C.

I don't do hobbyist stuff anymore since I'm too busy with work but I would think one could just use eval boards.  I don't know why a DIP would be required.  I don't know about the cost of the tools for a hobbyist, though.

As for the high pin counts, I would think that the need would be mitigated with all the high-speed serial interfaces. 

On Friday, October 26, 2018 at 9:49:03 PM UTC-4, Kevin Neilson wrote:
> > https://www.xilinx.com/video/hardware/vivado-hls-in-depth-technical-overview.html
> > 
> > After watching this consider what a top of the range HLS tool can do.
> > 
> 
> I know you're joking about HLS but the whole FPGA market is limited because any real work must be done by experiences specialists working at a very low level of abstraction.  It really does take months to do what you can do in Matlab in a couple of hours.  

I think this is rather exaggerated and comparing to Matlab coding is a bit disingenuous.  Are many projects coded in Matlab then they are done??? 

Coding in HDL is not really much different from coding in any high level language unless you have significant speed or capacity issues.  Even then that is not much different from programming CPUs.  If you are short on CPU speed or memory, you code very differently and spend a lot of time validating your goals at every step. 

Even then I have worked on a number of projects where the design was size and/or speed constrained and it wasn't a debilitating burden... just like the CPU coding projects I've worked on.  

I think the real difference is in the tasks that are done in FPGAs tend to be fairly complex.  I have done a number of projects in FPGAs that most of the work could have been done in a CPU and the FPGA project went rather quickly. 


> It's not really any different in that respect than it was fifteen years ago.  The market would be so much bigger if things were just a bit easier.  I haven't figured out if this is because it's an inherently difficult problem or if the tool designers aren't that skilled.  A little of both, I think.  I still think the people working on HLS are going in the wrong direction and need to spend more time refining the HDL tools.  They aim too high and fail utterly.  Why can't I infer a FIFO?  Just start with that.  The amount of time I spend on very basic structures is crazy.  I don't think any of this will change in the near future, though.  

I don't know, why can't *you* infer a fifo?  The code required is not complex.  Are you saying you feel you have to instantiate a vendor module for that???  I recall app notes from some time ago that explained how to use gray counters to easily infer fifos.  Typically the thing that slows me down in HDL is the fact that I'm using VHDL with all it's verbosity.  Some tools help with that, but I don't have those.  I've just never bitten the bullet to try working much in Verilog. 

Rick C.

On Friday, October 26, 2018 at 10:25:57 PM UTC-4, Kevin Neilson wrote:
> > That may be, but expired patents aren't really significant.  The basic functionality of the LUT/FF and routing have been available for quite some time now.  The details of FPGA architectures only matter when you are competing head to head.  That's why Silicon Blue focused on a market segment that was ignored by the big players.  The big two chase the telecom market with max capacity, high pin count barn burners and the other markets are addressed with the same technology making it impossible to compete in the low power areas.  In the end no significant user who is considering an iCE40 part even looks at a part from Xilinx or Altera. 
> > 
> > Rick C.
> 
> I don't do hobbyist stuff anymore since I'm too busy with work but I would think one could just use eval boards.  I don't know why a DIP would be required.  I don't know about the cost of the tools for a hobbyist, though.

Tools are zero cost, no?  I bought tools once, $1500 I believe.  Ever since I just use the free versions. 


> As for the high pin counts, I would think that the need would be mitigated with all the high-speed serial interfaces.

Uh, tell that to Xilinx, Altera, Lattice and everyone else (which I guess means Microsemi).  Lattice has some low pin count parts for the iCE40 line, but they are very fine pitch BGA type devices which are hard to route.  Otherwise the pin counts tend to be much higher than what I consider to be a similar MCU if not high pin count by all measures.  

Rick C.

> I think this is rather exaggerated and comparing to Matlab coding is a bit disingenuous.  Are many projects coded in Matlab then they are done??? 
> 
> Coding in HDL is not really much different from coding in any high level language unless you have significant speed or capacity issues.  Even then that is not much different from programming CPUs.  If you are short on CPU speed or memory, you code very differently and spend a lot of time validating your goals at every step. 
> 
It's not necessarily that it's in Matlab that makes it easy, but that it's very abstracted.  It might not be that much harder in abstract SystemVerilog.  What takes months is converting to a parallelized design, adding pipelining, meeting timing, placing, dealing with domain crossings, instantiating primitives when necessary, debugging, etc.  The same would be true of any language.  I suppose you can get an FPGA written in C to work as well, but it's not going to be *abstract* C.  It's going to be the kind of C that looks like assembly, in which the actual algorithm is indiscernible without extensive comments.

> Even then I have worked on a number of projects where the design was size and/or speed constrained and it wasn't a debilitating burden... just like the CPU coding projects I've worked on.  
> 
> I think the real difference is in the tasks that are done in FPGAs tend to be fairly complex.  I have done a number of projects in FPGAs that most of the work could have been done in a CPU and the FPGA project went rather quickly. 
> 
> 
> I don't know, why can't *you* infer a fifo?  The code required is not complex.  Are you saying you feel you have to instantiate a vendor module for that???  I recall app notes from some time ago that explained how to use gray counters to easily infer fifos.  Typically the thing that slows me down in HDL is the fact that I'm using VHDL with all it's verbosity.  Some tools help with that, but I don't have those.  I've just never bitten the bullet to try working much in Verilog. 
> 
> Rick C.

True--I instantiate FIFOs, but they themselves are actually written in HDL, Gray counters and all, though often the RAMs are instantiated for various reasons.  (If you want to use Xilinx's hard FIFOs, I believe you have to instantiate those.)  What I meant to say was that they should be, as a commonly-used element, much more abstracted.  I ought to be able to do it as a function call, such as:

  if (wr_en && fifo.size<256) fifo.push_front(wr_data);

I *can* do that, in SystemVerilog simulation, but any synthesizer would just scoff at that, though I don't see why it should be impossible to turn that into a FIFO.  Forcing designers to know about Gray counters and clock-domain crossings means that FPGA design will continue to be a recondite art limited to the few.

On Saturday, October 27, 2018 at 12:30:55 AM UTC-4, Kevin Neilson wrote:
> > I think this is rather exaggerated and comparing to Matlab coding is a bit disingenuous.  Are many projects coded in Matlab then they are done??? 
> > 
> > Coding in HDL is not really much different from coding in any high level language unless you have significant speed or capacity issues.  Even then that is not much different from programming CPUs.  If you are short on CPU speed or memory, you code very differently and spend a lot of time validating your goals at every step. 
> > 
> It's not necessarily that it's in Matlab that makes it easy, but that it's very abstracted.  It might not be that much harder in abstract SystemVerilog.  What takes months is converting to a parallelized design, adding pipelining, meeting timing, placing, dealing with domain crossings, instantiating primitives when necessary, debugging, etc.  The same would be true of any language.  I suppose you can get an FPGA written in C to work as well, but it's not going to be *abstract* C.  It's going to be the kind of C that looks like assembly, in which the actual algorithm is indiscernible without extensive comments.

And that is exactly my point.  The problem you point out is not a problem related in any way to implementing in FPGAs, it's that the design is inherently complex.  While you may be able to define the design in an abstract way in Matlab, that is not the same thing as an implementation in *any* medium or target. 

Your claim was, "the whole FPGA market is limited because any real work must be done by experiences specialists working at a very low level of abstraction".  This isn't a problem with the FPGA aspect, it is a problem with the task being implemented since it would be the same problem with any target.  


> > Even then I have worked on a number of projects where the design was size and/or speed constrained and it wasn't a debilitating burden... just like the CPU coding projects I've worked on.  
> > 
> > I think the real difference is in the tasks that are done in FPGAs tend to be fairly complex.  I have done a number of projects in FPGAs that most of the work could have been done in a CPU and the FPGA project went rather quickly. 
> > 
> > 
> > I don't know, why can't *you* infer a fifo?  The code required is not complex.  Are you saying you feel you have to instantiate a vendor module for that???  I recall app notes from some time ago that explained how to use gray counters to easily infer fifos.  Typically the thing that slows me down in HDL is the fact that I'm using VHDL with all it's verbosity.  Some tools help with that, but I don't have those.  I've just never bitten the bullet to try working much in Verilog. 
> > 
> > Rick C.
> 
> True--I instantiate FIFOs, but they themselves are actually written in HDL, Gray counters and all, though often the RAMs are instantiated for various reasons.  (If you want to use Xilinx's hard FIFOs, I believe you have to instantiate those.)  What I meant to say was that they should be, as a commonly-used element, much more abstracted.  I ought to be able to do it as a function call, such as:
> 
>   if (wr_en && fifo.size<256) fifo.push_front(wr_data);
> 
> I *can* do that, in SystemVerilog simulation, but any synthesizer would just scoff at that, though I don't see why it should be impossible to turn that into a FIFO.  Forcing designers to know about Gray counters and clock-domain crossings means that FPGA design will continue to be a recondite art limited to the few.

I'm not sure how you can do that in any language unless fifo.push_front() is already defined.  Are you suggesting it be a part of a language?  In C there are many libraries for various commonly used functions.  In VHDL there are some libraries for commonly used, but low level functions, nothing like a fifo.  If you write a procedure to define fifo.push_front() you can do exactly this, but there is none written for you.  

Rick C.

On 27/10/2018 02:48, Kevin Neilson wrote:
>> https://www.xilinx.com/video/hardware/vivado-hls-in-depth-technical-overview.html
>>
>> After watching this consider what a top of the range HLS tool can do.
>>
> 
> I know you're joking about HLS but the whole FPGA market is limited because any real work must be done by experiences specialists working at a very low level of abstraction.  

wow....HLS is not perfect by far and you still need to have RTL 
knowledge but I think your understanding of HLS is about 10 years in the 
past. Can I suggest you do a bit of googling to see what the current 
state is of HLS.

It really does take months to do what you can do in Matlab in a couple 
of hours.

yes but to be fair the power comes from some powerful library functions 
and not from basic m-code. Equally, it takes very little effort to 
instantiate some very complex IP cores.

It's not really any different in that respect than it was fifteen years 
ago.  The market would be so much bigger if things were just a bit 
easier.  I haven't figured out if this is because it's an inherently 
difficult problem or if the tool designers aren't that skilled.  A 
little of both, I think.

It is a complex problem, the EDA industry if worth many billions so 
there is no lack of financial incentive to develop these tools.

I still think the people working on HLS are going in the wrong direction 
and need to spend more time refining the HDL tools.

That is what they are doing by removing the time and architectural 
requirements of the input design. I agree that I would have preferred 
they used another language than C/C++ but at least the simulation is 
very very fast compared to RTL.

They aim too high and fail utterly.

No they don't, companies like Google, Nvidia, Qualcomm and many more are 
all very successful with HLS tools.

Why can't I infer a FIFO?  Just start with that.

Again, look at Vivado HLS, they have full support for FIFO's and can 
infer one from a stream array.

The amount of time I spend on very basic structures is crazy.

Why, write ones, stick in a library and instantiate as often as you 
like. Most synthesis tools are pretty good at inferring the required 
memory type.

I don't think any of this will change in the near future, though.
> 
> (PS, I know you were probably actually serious about HLS.)

I am, I am just surprised that you have so a low appreciation of the 
current technology.

HLS is happening but it will be a many decades before our skill set 
becomes obsolete (assuming we don't keep up).

Hans
www.ht-lab.com

On 27/10/2018 07:22, gnuarm.deletethisbit@gmail.com wrote:
> On Saturday, October 27, 2018 at 12:30:55 AM UTC-4, Kevin Neilson wrote:
..
>> It's not necessarily that it's in Matlab that makes it easy, but that it's very abstracted.  It might not be that much harder in abstract SystemVerilog.  What takes months is converting to a parallelized design, adding pipelining, meeting timing, placing, dealing with domain crossings, instantiating primitives when necessary, debugging, etc.  The same would be true of any language.  I suppose you can get an FPGA written in C to work as well, but it's not going to be *abstract* C.  It's going to be the kind of C that looks like assembly, in which the actual algorithm is indiscernible without extensive comments.
> 
> And that is exactly my point.  The problem you point out is not a problem related in any way to implementing in FPGAs, it's that the design is inherently complex.  While you may be able to define the design in an abstract way in Matlab, that is not the same thing as an implementation in *any* medium or target.
> 
> Your claim was, "the whole FPGA market is limited because any real work must be done by experiences specialists working at a very low level of abstraction".  This isn't a problem with the FPGA aspect, it is a problem with the task being implemented since it would be the same problem with any target.
> 

Well said.

..
>>>
>>> I don't know, why can't *you* infer a fifo?  The code required is not complex.  Are you saying you feel you have to instantiate a vendor module for that???  I recall app notes from some time ago that explained how to use gray counters to easily infer fifos.  Typically the thing that slows me down in HDL is the fact that I'm using VHDL with all it's verbosity.  

really, what aspect of VHDL is slowing you down that would be quicker in 
Verilog?

www.synthworks.com/papers/VHDL_2008_end_of_verbosity_2013.pdf

Personally I think verbosity is a good thing as it makes it easier to 
understand somebody else's code.

>Some tools help with that, but I don't have those.  I've just never bitten the bullet to try working much in Verilog.

I would forget about Verilog as it has too many quirks, go straight to 
SystemVerilog (or just stick with VHDL).

Hans
www.ht-lab.com

HT-Lab <hans64@htminuslab.com> wrote:
> On 27/10/2018 07:22, gnuarm.deletethisbit@gmail.com wrote:
> > On Saturday, October 27, 2018 at 12:30:55 AM UTC-4, Kevin Neilson wrote:

> >>> I don't know, why can't *you* infer a fifo?  The code required is not
> >>> complex.  Are you saying you feel you have to instantiate a vendor
> >>> module for that???  I recall app notes from some time ago that
> >>> explained how to use gray counters to easily infer fifos.  Typically
> >>> the thing that slows me down in HDL is the fact that I'm using VHDL
> >>> with all it's verbosity.
> 
> really, what aspect of VHDL is slowing you down that would be quicker in 
> Verilog?
> 
> www.synthworks.com/papers/VHDL_2008_end_of_verbosity_2013.pdf
> 
> Personally I think verbosity is a good thing as it makes it easier to 
> understand somebody else's code.

I'm don't have much to do with VHDL, but that sounds like it's making a bad
thing slightly less bad.  I'd be interested if you could point me towards an
example of tight VHDL?

The other issue that that a lot of these updated VHDL and Verilog standards
take a long time to make it into the tools.  So if you code in a style
that's above the lowest common denominator, you're now held hostage about
using the particular tool that supports your chosen constructs.

There's another type of tool out there, that compiles to Verilog as its
'assembly language'.  Basic register-transfer Verilog is pretty universally
supported, and so they support most toolchains.

As regards FIFOs, here's a noddy example:


import FIFO::*;

interface Pipe_ifc;
        method Action send(Int#(32) a);
        method ActionValue#(Int#(32)) receive();
endinterface

module mkDoubler(Pipe_ifc);
        FIFO#(Int#(32)) firstfifo <- mkFIFO;
        FIFO#(Int#(32)) secondfifo <- mkFIFO;

        rule dothedoubling;
                let in = firstfifo.first();
                firstfifo.deq;
                secondfifo.enq ( in * 2 );
        endrule

        method Action send(Int#(32) a);
                firstfifo.enq(a);
        endmethod

        method ActionValue#(Int#(32)) receive();
                let result = secondfifo.first();
                secondfifo.deq;
                return result;
        endmethod

endmodule


This creates a module containing two FIFOs, with a standard pipe interface -
a port for sending it 32 bit ints, and another for receiving 32 bit ints
back from it.  Inside, one FIFO is wired to the input of the module, the
other to the output.  When data comes in, it's stored in the first FIFO. 
When there is space in the second FIFO, it's dequeued from the first,
doubled, and enqueued in the second.  If any FIFO becomes full, backpressure
is automatically applied.  There's no chance of data getting lost by missing
control signals.

This is Bluespec's BSV, not VHDL or Verilog.  The compiler type checked it
for me, so I'm very confident it will work first time.  I could have made it
polymorphic (there's nothing special about 32 bit ints here) with only a
tiny bit more work.  It compiles to Verilog which I can then synthesise.

Notice there are no clocks or resets (they're implicit unless you say you
want multiple clock domains), no 'if valid is high then' logic, it's all
taken care of.  This means you can write code that does a lot of work very
concisely.

Theo