FPGA Market Entry Barriers

ering to be recovered.

s 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 ven dor even thinks about this.

che, using an obsolete node (like 250nm or 350nm) might make crowdfunding p ractical. It would probably be more popular than

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 ar en't so bad. That equipment was amortized a long time ago. I guess the re al 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.

h of FPGA patents. Even more have expired since then.

That may be, but expired patents aren't really significant. The basic func tionality 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 wa s ignored by the big players. The big two chase the telecom market with ma x 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 eve n looks at a part from Xilinx or Altera.

Rick C.

Reply to
gnuarm.deletethisbit
Loading thread data ...

iew.html

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 lo w level of abstraction. It really does take months to do what you can do i n Matlab in a couple of hours. It's not really any different in that respe ct than it was fifteen years ago. The market would be so much bigger if th ings 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 skill ed. A little of both, I think. I still think the people working on HLS ar e 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? Ju st 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.)

Reply to
Kevin Neilson

nctionality of the LUT/FF and routing have been available for quite some ti me now. The details of FPGA architectures only matter when you are competi ng 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 address ed with the same technology making it impossible to compete in the low powe r areas. In the end no significant user who is considering an iCE40 part e ven looks at a part from Xilinx or Altera.

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 requ ired. 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.

Reply to
Kevin Neilson

rview.html

se 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 la nguage unless you have significant speed or capacity issues. Even then tha t is not much different from programming CPUs. If you are short on CPU spe ed 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 a nd/or speed constrained and it wasn't a debilitating burden... just like th e 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 qui ckly.

go. 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 probl em 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 amoun t 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 compl ex. Are you saying you feel you have to instantiate a vendor module for th at??? 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 h elp with that, but I don't have those. I've just never bitten the bullet t o try working much in Verilog.

Rick C.

Reply to
gnuarm.deletethisbit

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 compe ting head to head. That's why Silicon Blue focused on a market segment tha t was ignored by the big players. The big two chase the telecom market wit h max capacity, high pin count barn burners and the other markets are addre ssed with the same technology making it impossible to compete in the low po wer areas. In the end no significant user who is considering an iCE40 part even looks at a part from Xilinx or Altera.

d think one could just use eval boards. I don't know why a DIP would be re quired. 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.

d with all the high-speed serial interfaces.

Uh, tell that to Xilinx, Altera, Lattice and everyone else (which I guess m eans 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. Oth erwise the pin counts tend to be much higher than what I consider to be a s imilar MCU if not high pin count by all measures.

Rick C.

Reply to
gnuarm.deletethisbit

t disingenuous. Are many projects coded in Matlab then they are done???

language unless you have significant speed or capacity issues. Even then t hat is not much different from programming CPUs. If you are short on CPU s peed or memory, you code very differently and spend a lot of time validatin g 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 SystemVerilo g. What takes months is converting to a parallelized design, adding pipeli ning, 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 loo ks like assembly, in which the actual algorithm is indiscernible without ex tensive comments.

and/or speed constrained and it wasn't a debilitating burden... just like the CPU coding projects I've worked on.

o be fairly complex. I have done a number of projects in FPGAs that most o f the work could have been done in a CPU and the FPGA project went rather q uickly.

plex. 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 gr ay 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.

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 in stantiate those.) What I meant to say was that they should be, as a common ly-used element, much more abstracted. I ought to be able to do it as a fu nction call, such as:

if (wr_en && fifo.size

Reply to
Kevin Neilson

bit disingenuous. Are many projects coded in Matlab then they are done???

l 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 validat ing your goals at every step.

s very abstracted. It might not be that much harder in abstract SystemVeri log. What takes months is converting to a parallelized design, adding pipe lining, meeting timing, placing, dealing with domain crossings, instantiati ng primitives when necessary, debugging, etc. The same would be true of an y language. I suppose you can get an FPGA written in C to work as well, bu t it's not going to be *abstract* C. It's going to be the kind of C that l ooks 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 r elated in any way to implementing in FPGAs, it's that the design is inheren tly 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 mus t be done by experiences specialists working at a very low level of abstrac tion". 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.

ze and/or speed constrained and it wasn't a debilitating burden... just lik e the CPU coding projects I've worked on.

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.

omplex. Are you saying you feel you have to instantiate a vendor module fo r 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 dow n in HDL is the fact that I'm using VHDL with all it's verbosity. Some too ls help with that, but I don't have those. I've just never bitten the bull et to try working much in Verilog.

L, Gray counters and all, though often the RAMs are instantiated for variou s 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 comm only-used element, much more abstracted. I ought to be able to do it as a function call, such as:

ust scoff at that, though I don't see why it should be impossible to turn t hat into a FIFO. Forcing designers to know about Gray counters and clock-d omain 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() i s already defined. Are you suggesting it be a part of a language? In C th ere 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 e xactly this, but there is none written for you.

Rick C.

Reply to
gnuarm.deletethisbit

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.

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

formatting link

Reply to
HT-Lab

..

Well said.

..

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

formatting link

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

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

Hans

formatting link

Reply to
HT-Lab

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

Reply to
Theo

Lattice have some ice40 series parts in 48pin 0.5mm pitch QFN, easily hotplate and hand solderable. Altera have MAX10 with 50kLUTs (approx) in 144 pin TQFP. There are no modern Xilinx parts in other than BGA but you can get Artix and Spartan 7 in 1mm pitch BGA. Should be possible to use on low cost (0.15mm track and gap) 4 layer boards. I mean to try quite soon - I'll let you know.

MK

Reply to
Michael Kellett

On 27/10/2018 13:12, Theo wrote: ..

I should have said "verbosity to a certain degree", of course you can have too much verbosity which can lead to bugs (TLDR phenomenon). There are occasions where you want to have concise code. In my C code I do use the '?' operator quite a bit.

I cannot answer this as it is too broad.

Tell me about it, I am currently wasting time removing VHDL2008 constructs as Quartus Pro supports VHDL2008 but Quartus Prime does not. Why does Intel think it is a good approach to have 2 fully supported P&R products with different language support? Customers using a Cyclone10GX cannot easily move to Cyclone10LP without mutilating their VHDL.

But to answer your question, I think you just shot yourself in the foot as BlueSpec BSV is a worse hostage taker than a standardised VHDL2008/SV language. As far as I can tell Bluespec BSV is not an open standard and there is no second source so any company using BSV is locked into the Bluespec's toolchain. At least with VHDL2008/SV I can move to many other vendors.

I haven't spend much time looking into Bluespec but I do know that many companies are nervous adopting a custom language supported by a single vendor.

Impressive example, however, I am not sure if any other high level RTL language will be a lot more verbose. You are instantiating a FIFO and connecting the ports with a bit of control logic right?

It looks like BSV sits between RTL and HLS, you have raised the level of abstraction but still have an implicit clock.

Thanks for the example,

Hans

formatting link

Reply to
HT-Lab

related in any way to implementing in FPGAs, it's that the design is inher ently complex. While you may be able to define the design in an abstract w ay in Matlab, that is not the same thing as an implementation in *any* medi um or target.

ust be done by experiences specialists working at a very low level of abstr action". This isn't a problem with the FPGA aspect, it is a problem with t he task being implemented since it would be the same problem with any targe t.

It's hard to turn abstract sequential code into a parallelized algorithm. But a more basic issue is the poor tools and lack of IP that requires low-l evel coding for everything, almost as if a C coder had to write his own pri ntf() function. If you just want to implement an algorithm and speed and g ates are not an issue, then yes, things are easy. But we rarely get projec ts like that, because those are done in microcontrollers.

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 ther e are some libraries for commonly used, but low level functions, nothing li ke a fifo. If you write a procedure to define fifo.push_front() you can do exactly this, but there is none written for you.

That is actual syntax from Systemverilog. When I want to set up a FIFO in a testbench, I declare a queue and use the .push_front() and .pop_back() me thods. It's already in the language; it just isn't supported in synthesis. This isn't a case where I'm asking the tool to convert sequential to para llel; I'm just asking it to look for a function call and instantiate a FIFO . Just something to make the code a little easier to write, read, and main tain.

Reply to
Kevin Neilson

ds

This is the problem I run into all the time. No matter how low-level I wri te something, some tool somewhere won't like it and I have to write it in a yet lower level. It's amazing how many tools can't parse basic things fro m Verilog-2005. It's been thirteen years! I ran into some tool recently, maybe it was Synopsys DC, which doesn't allow $readmemh(), which I think mi ght from Verilog-1995, and which I've been using my whole career. I had to rewrite a bunch of code as a result. So much time spent rewriting stuff t hat already works.

Reply to
Kevin Neilson

I've been fooled too many times before. I'm not going to be a chump and waste any more time it.

Reply to
Kevin Neilson

:

it's very abstracted. It might not be that much harder in abstract SystemV erilog. What takes months is converting to a parallelized design, adding p ipelining, meeting timing, placing, dealing with domain crossings, instanti ating 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 tha t looks like assembly, in which the actual algorithm is indiscernible witho ut extensive comments.

em related in any way to implementing in FPGAs, it's that the design is inh erently 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* me dium or target.

must be done by experiences specialists working at a very low level of abs traction". 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 tar get.

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 us e gray counters to easily infer fifos. Typically the thing that slows me d own in HDL is the fact that I'm using VHDL with all it's verbosity.

That's a great paper for a newbie to learn some advantages of VHDL-2008, bu t it is far from justifying that VHDL isn't verbose.

One of the most verbose aspects of VHDL is the need to type signals three t imes when instantiating modules. 1) typing the module, 2) typing the insta nce, 3) typing the signal declarations in the module where the instance is used. I had regular expressions I used to convert between these forms. I expect some editors do this for you. I think VHDL-2008 provides a way to a void typing the ports in instantiations (or the whole instantiation), but I don't recall the details and I don't see it in the above paper.

Sure, that's no small reason why I haven't switched. The guys who's Verilo g code I see seem to eschew white space and cram it all together. I find t hat alone to make the code hard to read. But it's all about what you are u sed to really. They seem to get along just fine.

en the bullet to try working much in Verilog.

I'm not doing much with any HDL so little chance of working with anything o ther than VHDL at the moment.

These days I mostly receive POs and issue POs.

Rick

Reply to
gnuarm.deletethisbit

te:

ot

y
n

ad

an

I don't think that is the point. The verbosity of VHDL is intended. There are things that you have to do in VHDL that aren't done in Verilog where t he intent is to avoid a class of mistakes. This is the reason for strong t yping which brings on some verbosity.

an_integer_variable This is Bluespec's BSV, not VHDL or Verilog. The compiler type checked i t

it

What about simulation? Is the BSV simulated or the Verilog?

y

How do you distinguish code that is combinatorial?

Rick C.

Reply to
gnuarm.deletethisbit

I've probably seen these and forgotten them since they are a bit too small for my needs. I'm using an obsolete Lattice XP part in a 100 pin TQFP with 60+ I/Os. The 48QFN is very interesting, but won't actually fit my need. Thanks for the reminder though. Maybe two of them, lol

Yeah, not so small though. The package is 22 mm square and my board is onl y 21.6 mm wide! If I have to I can squeeze a BGA-256 on the board. I just don't want to deal with the layout issues.

That might work. I haven't looked at replacements in awhile. Didn't even know of the 196 pin package. Thanks. For the time being I can get all the XP parts I need.

Rick C.

Reply to
gnuarm.deletethisbit

Oh, I hadn't realised that - that's a pain.

Yes, this is a big problem. It's something Bluespec Inc themselves realise too - I think they would open source the compiler but they have customers who are paying the bills, so...

(There are also other toy BSV compilers around, but nothing I've seen that's production ready)

However it's slightly different from the VHDL/Verilog problem. The VHDL/Verilog tools are compiling to something else (standard cells, FPGA netlists). If you're targeting Altera, you have to use Quartus for this. If you want to move your code to an ASIC, you now have to switch to Synopsys DC (or whatever), and discover that your SystemVerilog constructs aren't supported. In the BSV case, the Verilog 95 emitted by the BSV compiler can be used with Altera or Synopsys. So your backend is flexible, even if one piece of your frontend is fixed.

In that noddy example. Interfaces mean you can wrap up a lot of verbosity into a few lines. For a randomly selected example, here's a processor TLB, in 500 lines of BSV:

formatting link

Also, being polymorphic, you can generate a variety of different modules from the one description - which saves a lot of repetition.

Yes. It's still timed, so you still have decide what's going in each cycle. (or at least your idea of that - your synthesis tool may retime). And it's possible to get bubbles - your system still works, but takes more cycles because parts will stall if there's no data for them to operate on. Also, there's still skill in understanding what will impact your critical path.

ISTM one issue with HLS is it's good at handling work in the datapath, but perhaps not so good in the control path. So you can describe some kinds of compute very well, but I'm not sure how well they would handle a control-heavy structure like a cache.

Theo

Reply to
Theo

em related in any way to implementing in FPGAs, it's that the design is inh erently 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* me dium or target.

must be done by experiences specialists working at a very low level of abs traction". 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 tar get.

But a more basic issue is the poor tools and lack of IP that requires low

-level coding for everything, almost as if a C coder had to write his own p rintf() function. If you just want to implement an algorithm and speed and gates are not an issue, then yes, things are easy. But we rarely get proj ects like that, because those are done in microcontrollers.

I don't agree with that last bit. The difference in speed and density of a design is orders of magnitude between FPGAs and MCUs. There is plenty of room for easier FPGA designs that still won't be easy even if possible on a n MCU.

() 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 th ere 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.

n a testbench, I declare a queue and use the .push_front() and .pop_back() methods. It's already in the language; it just isn't supported in synthesi s. This isn't a case where I'm asking the tool to convert sequential to pa rallel; I'm just asking it to look for a function call and instantiate a FI FO. Just something to make the code a little easier to write, read, and ma intain.

But if it isn't supported in synthesis, what good is it? If I am coding fo r simulation only I can take all manner of shortcuts.

Rick C.

Reply to
gnuarm.deletethisbit

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.