Live data from Hacker News

FPGAs becoming more SoC-like

semiengineering.com

51–58 of 58 posts

Re: FPGAs becoming more SoC-like

#51
post #37
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.

To use with ARM CPU, not to implement. When I worked with SoC design back in 2008, the situation was just like that - use A* buses freely unless you have an ARM CPU in your design (even if that CPU is implemented by you). Then you need a license.

Leon family of CPUs used AXB, I think, for example.

Re: FPGAs becoming more SoC-like

#52

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…

And don't get me started on trying to version control a Vivado project. It's like they didn't even consider the possibility of committing a project to source control! I last used Vivado about 2 years ago but doubt things have changed much. It really makes me wonder how Xilinx does it in-house.

I was just about to say this! We’ve recently hacked our Vivado project into git. This requires unpacking all packages and ignoring compiled packages. Plus a bunch of bat files to handle house keeping.

A big part of the issue is compiling packages. I think this is a thing because synthesis takes so long.

Until synthesis time is reduced, I think we’ll see these hack-y solutions.

Re: FPGAs becoming more SoC-like

#53
post #49

Earlier quoted context omitted.

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

Can you list some reasons why please?

Re: FPGAs becoming more SoC-like

#54
post #51
post #37

Earlier quoted context omitted.

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

To use with ARM CPU, not to implement. When I worked with SoC design back in 2008, the situation was just like that - use A* buses freely unless you have an ARM CPU in your design (even if that CPU is implemented by you). Then you need a license. Leon family of CPUs used AXB, I think, for example.

So if you buy an architecture license to design your own core and you want to use AMBA in your design, you have to pay extra? I find that very surprising, but having never worked for an architecture licensee, I don’t have any information to contradict it.

Can you share a sense of how expensive the bus license is relative to the architecture license?

Re: FPGAs becoming more SoC-like

#55
post #47
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. >…

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

> RISC-V started 2010, the year Zynq was dreamed up.

Exactly: much too late for Zynq, and still a minuscule market share even 8 years later.

> for your substantial money you get inferior CPU

Wrong, and furthermore, you still didn't get the point: It's not about theoretical technological perfection, but about the surrounding ecosystem, tooling, related IP, available expertise, and support.

> CPU you cannot improve much

Also wrong, and irrelevant for 99% of use cases.

> with highly aggressive pricing when you want to run ASIC

Irrelevant for 99% of FPGA designs.

Re: FPGAs becoming more SoC-like

#56
post #49

Earlier quoted context omitted.

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

I see.

Would you mind pointing me to a single competitive pure RISC CPU?

Re: FPGAs becoming more SoC-like

#57
post #34

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.

Most software tools are provided for free, sometimes even open source. If money is involved, and we're not talking about things like IDA Pro, prices are usually negligible.

With Xilinx toolchains, you're paying both for extremely expensive toolchain licenses, and paying quite steep prices for the FPGA units themselves. We're basically shoveling money at Xilinx as fast as we can.

Re: FPGAs becoming more SoC-like

#58
post #10

Earlier quoted context omitted.

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.

I don't write much VHDL or Verilog for my work. Most of it is combining cores together that are either from the vendor or are generated using Simulink. Occasionally there needs to be some glue logic to link some blocks together and all the code in the softcore processor needs to be written in C but most of the development is based on wiring up blocks in Libero's GUI.
Post reply on HN