FPGAs becoming more SoC-like • Hacker News Board

Re: FPGAs becoming more SoC-like

#41

Post by davrosthedalek » Sat, Jun 09, 2018, 6:26 PM UTC

TomVDB wrote: post #38

planteen wrote: post #35

Earlier quoted context omitted.

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 Signa…

In Vivado, you can actually tell it to spawn a different editor than the build in one. I use emacs. Much better.

Re: FPGAs becoming more SoC-like

#42

Post by planteen » Sat, Jun 09, 2018, 6:33 PM UTC

TomVDB wrote: post #38

planteen wrote: post #35

Earlier quoted context omitted.

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 Signa…

Yeah, I know you can use vim. Text editing is not even close to where the major pain points are with Vivado. There's more to the workflow of developing a FPGA than adding files in Vivado.

My experience went something like this: An hardware engineer needs to do a routine task like add a peripheral, swap some pin assignments, and modify the Verilog/VHDL. So they do all their synthesis and have an export ready to hand it off the the software engineer. They commit their changes and it probably causes differences in dozens of files, but so is life. It seems like this could be reduced to differences in a few human-readable files, except for the bitstream which obviously is binary.

The SW engineer then needs to update the FSBL and BSP for the board. I never found a way to automate this on the command line, you needed to update the FSBL using their horrible Eclipse-based import tool. In my case, I had to make some manual modifications to the FSBL. I think for my modifications that I needed to flip some GPIO pins early in the boot process and also do some RSA validation on the bitstream. Well, all those modifications would get wiped out. I never found a way to template those and preserve them across new imports.

So I had a bunch of differences that had to be manually merged every time. I had notes about it, but come on. What a pain. At the end of all of this, many dozens more files were changed. Once again, it seems like this should reduce to just handful of human-readable files like a FSBL configuration header / C file, the new U-Boot config, and the new kconfig. But instead you had two massive changesets in version control for some very routine work.

Re: FPGAs becoming more SoC-like

#43

Post by lvoudour » Sat, Jun 09, 2018, 6:44 PM UTC

dman wrote: post #34

lvoudour wrote: post #29

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

That's true, but that doesn't explain why the HDL IDEs lack modern productivity features or why the simulator GUIs have the same interface as 20 years ago. Inertia and vendor lock-in are better explanations IMHO.

I hope with FPGAs becoming more mainstream the open source/hobbyist community will step in and refine some things, but if the big EDA shops don't take hints from the software industry things are not going to change very fast.

Re: FPGAs becoming more SoC-like

#44

Post by 0xcde4c3db » Sat, Jun 09, 2018, 6:58 PM UTC

planteen wrote: post #30

adwn wrote: post #23

Earlier quoted context omitted.

> ARM itself is not very nice design from contemporary point of view. [...] they decided to use that ARM thing ARM CPUs are the de-facto standard in the embedded world (except for simple 8-bit MCUs), so what should Xilinx have done? Design their own, proprietary CPU architecture and ISA? Choose some other architecture with 2% market share? Both paths would have led to the immediate death of the whole product line. >…

> ARM CPUs are the de-facto standard in the embedded world (except for simple 8-bit MCUs), so what should Xilinx have done? Design their own, proprietary CPU architecture and ISA? Choose some other architecture with 2% market share? Both paths would have led to the immediate death of the whole product line. Totally agree. IIRC, didn't Xilinx have another hard core CPU+FPGA design before the Zynq using a PowerPC? PPC…

> didn't Xilinx have another hard core CPU+FPGA design before the Zynq using a PowerPC?

Yes; more than one. There were at least the Virtex II Pro, Virtex 4 FX, and Virtex 5 FX families.

Re: FPGAs becoming more SoC-like

#45

Post by gluggymug » Sat, Jun 09, 2018, 9:51 PM UTC

planteen wrote: post #42

TomVDB wrote: post #38

Earlier quoted context omitted.

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 Signa…

Yeah, I know you can use vim. Text editing is not even close to where the major pain points are with Vivado. There's more to the workflow of developing a FPGA than adding files in Vivado. My experience went something like this: An hardware engineer needs to do a routine task like add a peripheral, swap some pin assignments, and modify the Verilog/VHDL. So they do all their synthesis and have an export ready to hand i…

I believe Tcl scripts can help automate your FSBL and BSP changes. Pretty much everything you do in the GUI translates to Tcl commands.

Re: FPGAs becoming more SoC-like

#46

Post by arghwhat » Sat, Jun 09, 2018, 11:55 PM UTC

xfer wrote: post #10

lnsru wrote: post #5

Earlier quoted context omitted.

The colleagues are telling me, that this ugly GUI works nowadays under Linux too. You also can script much using tcl commands. I have it running on Windows and it works somehow, but I am not happy user:-/

Xilinx Vivado is not ugly; but resource heavy; so most people stick to tcl scripting.

I'd argue that it's both ugly and resource heavy, but "ugly" would be a matter of taste.

I just have a very strong aversion for IDE's that fail to prioritize text editing, permanently wasting space on all sorts of buttons and knobs that are only needed 0.1% of the time. It doesn't help that they often also fail to be responsive.

Re: FPGAs becoming more SoC-like

#47

Post by thesz » Sun, Jun 10, 2018, 9:23 AM UTC

adwn wrote: post #23

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. [...] they decided to use that ARM thing ARM CPUs are the de-facto standard in the embedded world (except for simple 8-bit MCUs), so what should Xilinx have done? Design their own, proprietary CPU architecture and ISA? Choose some other architecture with 2% market share? Both paths would have led to the immediate death of the whole product line. >…

RISC-V started 2010, the year Zynq was dreamed up. Candence bought XTensa (much less than 2%) and I know of several products using their cores.

My arguments about ARM CPU inferiority are about ARM CPU inferiority and related vendor lock-in. I summarize them: for your substantial money you get inferior CPU you cannot improve much, for prototyping and then for product, with highly aggressive pricing when you want to run ASIC.

Re: FPGAs becoming more SoC-like

#48

Post by thesz » Sun, Jun 10, 2018, 9:24 AM UTC

planteen wrote: post #30

adwn wrote: post #23

Earlier quoted context omitted.

> ARM itself is not very nice design from contemporary point of view. [...] they decided to use that ARM thing ARM CPUs are the de-facto standard in the embedded world (except for simple 8-bit MCUs), so what should Xilinx have done? Design their own, proprietary CPU architecture and ISA? Choose some other architecture with 2% market share? Both paths would have led to the immediate death of the whole product line. >…

> ARM CPUs are the de-facto standard in the embedded world (except for simple 8-bit MCUs), so what should Xilinx have done? Design their own, proprietary CPU architecture and ISA? Choose some other architecture with 2% market share? Both paths would have led to the immediate death of the whole product line. Totally agree. IIRC, didn't Xilinx have another hard core CPU+FPGA design before the Zynq using a PowerPC? PPC…

Intel didn't own Altera in 2010.

Re: FPGAs becoming more SoC-like

#49

Post by thesz » Sun, Jun 10, 2018, 9:38 AM UTC

deepnotderp wrote: post #36

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…

I think that choosing today ARM and/or Intel for your CPU of choice for product line is stupid.

Re: FPGAs becoming more SoC-like

#50

Post by thesz » Sun, Jun 10, 2018, 9:43 AM UTC

TomVDB wrote: post #32

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?

Because if it is ot pure you will have trouble having differrent implementations of same ISA. Imagine implementing same feature for superscalar OoO or for version where pipeline length is only two or one cycle.

Being a software dev I also designed CPUs. I know what I am talking about.

For you having 4K IRAM - use stack machine. You'd be better off.