FPGAs becoming more SoC-like • Hacker News Board

Re: FPGAs becoming more SoC-like

#31

Post by TomVDB » Sat, Jun 09, 2018, 4:15 PM UTC

arghwhat wrote: post #24

orbifold wrote: post #9

Earlier quoted context omitted.

All the FPGA tools by Xilinx work well under Linux and Vivado is actually quite pleasant to use. Almost all of the EDA tools can be scripted with TCL (cadence has a host of other DSL aswell) so you don’t need to use the GUI if you don’t want to.

Vivado is absolutely terrible, especially the GUI. Our toolchain at work is set up so that it can be entirely avoided, with developers only writing Verilog in their editor of choice, and calling make or pushing to Jenkins when they want results. And then they go home, as it takes a full day to build a product on our server farm. Sim/others is done with third-party products. I recall one Xilinx event where a Xilinx pr…

I don’t see how the quality of the IDE has any influence on what selection of FPGA to use.

We select FPGAs based on HW features and that is that.

The tools are more than good enough for debugging or to kick off an occasional custom synthesis run when you don’t have the time to wrap it in a Makefile.

Re: FPGAs becoming more SoC-like

#32

Post by TomVDB » Sat, Jun 09, 2018, 4:22 PM UTC

thesz wrote: post #16

Article says "CPU does not fit FPGA synthesis very well and uses almost whole thing". People serious about prototyping usually get daughterboards for FPGA and/or FPGA stacks specifically to prototype big things with CPUs. The buses can go outside of main FPGA with CPU and into other things. I know at least one big SoC project which went that way. I also think that having an ARM core in FPGA is a vendor lock in. For e…

The lack of multi-register store and load is one is one of my biggest gripes with the RISC-V ISA. It just hurts to see the compiler waste 32 x2 bytes just to save and restore register context. (It matters a lot when you have a little CPU with 4KB of program RAM.)

What does it matter that it’s not pure?

Re: FPGAs becoming more SoC-like

#33

Post by madengr » Sat, Jun 09, 2018, 4:25 PM UTC

stochastic_monk wrote: post #22

detaro wrote: post #21

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/System_on_a_chip

Thank you! I couldn’t find anything in the article.

Yeah, took me several articles until I found out that the SD means Software Defined. Irks me when articles don’t define acronyms.

Re: FPGAs becoming more SoC-like

#34

Post by dman » Sat, Jun 09, 2018, 4:43 PM UTC

lvoudour wrote: post #29

arghwhat wrote: post #24

Earlier quoted context omitted.

Vivado is absolutely terrible, especially the GUI. Our toolchain at work is set up so that it can be entirely avoided, with developers only writing Verilog in their editor of choice, and calling make or pushing to Jenkins when they want results. And then they go home, as it takes a full day to build a product on our server farm. Sim/others is done with third-party products. I recall one Xilinx event where a Xilinx pr…

Vivado is absolutely terrible, especially the GUI. Our toolchain at work is set up so that it can be entirely avoided, with developers only writing Verilog in their editor of choice, and calling make or pushing to Jenkins when they want results. And then they go home, as it takes a full day to build a product on our server farm. Sim/others is done with third-party products. That's how most companies do it in my exper…

Is it possible that the market for software developers is larger than the fpga developer market hence allowing tool development costs to be amortized over a larger set of users.

Re: FPGAs becoming more SoC-like

#35

Post by planteen » Sat, Jun 09, 2018, 5:38 PM UTC

TomVDB wrote: post #31

arghwhat wrote: post #24

Earlier quoted context omitted.

Vivado is absolutely terrible, especially the GUI. Our toolchain at work is set up so that it can be entirely avoided, with developers only writing Verilog in their editor of choice, and calling make or pushing to Jenkins when they want results. And then they go home, as it takes a full day to build a product on our server farm. Sim/others is done with third-party products. I recall one Xilinx event where a Xilinx pr…

I don’t see how the quality of the IDE has any influence on what selection of FPGA to use. We select FPGAs based on HW features and that is that. The tools are more than good enough for debugging or to kick off an occasional custom synthesis run when you don’t have the time to wrap it in a Makefile.

The quality of the tool chain absolutely has bearing. You are essentially locked into using using the FPGA vendor's tools. And its not like there is much choice in FPGAs anyway. You have Xilinx, Altera, Lattice, and MicroSemi. In a small company with a low volume product, the engineer working with the FPGA has a ton of other duties. The speed with which you can knock out the FPGA is huge and the tools and available documentation play a large part in that.

Re: FPGAs becoming more SoC-like

#36

Post by deepnotderp » Sat, Jun 09, 2018, 5:41 PM UTC

thesz wrote: post #16

Article says "CPU does not fit FPGA synthesis very well and uses almost whole thing". People serious about prototyping usually get daughterboards for FPGA and/or FPGA stacks specifically to prototype big things with CPUs. The buses can go outside of main FPGA with CPU and into other things. I know at least one big SoC project which went that way. I also think that having an ARM core in FPGA is a vendor lock in. For e…

> ARM itself is not very nice design from contemporary point of view. I expressed my dissatisfaction with ARM ISA many times here and just let me start with two points: 1) ARM is not RISC (multiregister load/store execute in several clocks) and 2) too much of initial design of first ARM (which was not planned for longterm evolution) is visible in ISA.

Found the guy who took his first computer architecture course and now thinks everyone at Intel, amd, ARM, etc is stupid for not going full on RISC.

Re: FPGAs becoming more SoC-like

#37

Post by repiret » Sat, Jun 09, 2018, 5:51 PM UTC

thesz wrote: post #16

Article says "CPU does not fit FPGA synthesis very well and uses almost whole thing". People serious about prototyping usually get daughterboards for FPGA and/or FPGA stacks specifically to prototype big things with CPUs. The buses can go outside of main FPGA with CPU and into other things. I know at least one big SoC project which went that way. I also think that having an ARM core in FPGA is a vendor lock in. For e…

> For example, you cannot use AMBA/APB/AXB and other ARM buses with ARM CPU core in your design without paying ARM for license for these buses

Do you have a citation for that? I’m pretty sure none of the AMBA busses require a paid license to implement.

Re: FPGAs becoming more SoC-like

#38

Post by TomVDB » Sat, Jun 09, 2018, 5:55 PM UTC

planteen wrote: post #35

TomVDB wrote: post #31

Earlier quoted context omitted.

I don’t see how the quality of the IDE has any influence on what selection of FPGA to use. We select FPGAs based on HW features and that is that. The tools are more than good enough for debugging or to kick off an occasional custom synthesis run when you don’t have the time to wrap it in a Makefile.

The quality of the tool chain absolutely has bearing. You are essentially locked into using using the FPGA vendor's tools. And its not like there is much choice in FPGAs anyway. You have Xilinx, Altera, Lattice, and MicroSemi. In a small company with a low volume product, the engineer working with the FPGA has a ton of other duties. The speed with which you can knock out the FPGA is huge and the tools and available d…

I wrote "quality of IDE" not "quality of the toolchain" for a reason. In fact, let's reduce this to "quality of the editor." The text editors are absolutely terrible, but that's why they invented Vim. You're only a "Add File" away to work around that.

Other than that, getting from Verilog to a design mapped to hardware is pretty trivial with both Quartus and Vivado. They both have excellent debugging tools with SignalTap and ChipScope, they have pin planners that works reasonably well. Synthesis and P&R results are decent.

If your design is so generic that it really doesn't matter which FPGA you're using, then, sure, make your decision based on this kind of detail. But I find that to be almost never the case. Price, number of DSPs and their precision, amount of block RAM, performance of the SERDES units. Those are real decision makers.

Re: FPGAs becoming more SoC-like

#39

Post by TomVDB » Sat, Jun 09, 2018, 5:56 PM UTC

repiret wrote: post #37

thesz wrote: post #16

Article says "CPU does not fit FPGA synthesis very well and uses almost whole thing". People serious about prototyping usually get daughterboards for FPGA and/or FPGA stacks specifically to prototype big things with CPUs. The buses can go outside of main FPGA with CPU and into other things. I know at least one big SoC project which went that way. I also think that having an ARM core in FPGA is a vendor lock in. For e…

> For example, you cannot use AMBA/APB/AXB and other ARM buses with ARM CPU core in your design without paying ARM for license for these buses Do you have a citation for that? I’m pretty sure none of the AMBA busses require a paid license to implement.

That was my understanding as well.

Re: FPGAs becoming more SoC-like

#40

Post by arghwhat » Sat, Jun 09, 2018, 6:10 PM UTC

TomVDB wrote: post #31

arghwhat wrote: post #24

Earlier quoted context omitted.

Vivado is absolutely terrible, especially the GUI. Our toolchain at work is set up so that it can be entirely avoided, with developers only writing Verilog in their editor of choice, and calling make or pushing to Jenkins when they want results. And then they go home, as it takes a full day to build a product on our server farm. Sim/others is done with third-party products. I recall one Xilinx event where a Xilinx pr…

I don’t see how the quality of the IDE has any influence on what selection of FPGA to use. We select FPGAs based on HW features and that is that. The tools are more than good enough for debugging or to kick off an occasional custom synthesis run when you don’t have the time to wrap it in a Makefile.

Vivado isn't just an IDE, it's a toolchain. Poor or buggy verilog support, synthesis bugs, etc. can definitely influence the choice of FPGA's. And FPGA toolchains are all very buggy. Current issues we have involve that Vivado cannot reproduce builds even with the same seed.

Our main reason to not have picked Altera was usually much poorer routing and inability to meet our bandwidth demands (>100Gb/s), but the poorer toolchain was also a factor.

However, for IDE, it can be a killer if use is a requirement.