
FPGAs becoming more SoC-like - chclau
http://semiengineering.com/fpgas-becoming-more-soc-like/#.Wxlg0Z4jrWM.facebook
======
lnsru
No. There is a more suitable tools now for every problem. Large volume - ASIC,
and you can also put few ARM cores inside. Something highly integrated - pick
ZynQ. There are dozen different solutions for all the problems starting with
big FPGA with couple softcore processors going to cheap spartan 7 device and
going to tiny and dirt cheap Lattice chip for glue logic or IO expansion.
Tools might be better, but this problem will be solved in the future for sure.

~~~
arghwhat
It wasn't a question.

ASIC isn't the tool for large volume, it's the tool for when you can accept a
several year turnaround time for revisions, vs. a day or two. ASIC > FPGA...
except if your design changes, ever. If anything high-bandwidth or design
intensive is going on, you're definitely going to revise your design many
times.

FPGA's are massively on the rise (although slightly less so than Xilinx would
like), and they _all_ are effectively "SoC like", with DSPs, transceivers,
hard IP's probably being a majority of the chip by now.

Zynq is a cute little chip, but with Intel's coming CPU-embedded FPGA's, thing
will kick off even more.

~~~
codeflo
What's the tooling like for a typical, production-quality FPGA project
nowadays? Last I checked, which is admittedly a couple of years ago (and I
didn't dive in very deeply), it was a horrible mix of badly programmed vendor-
specific Windows-only GUI tools. It seemed a lot like the embedded processor
market where every single vendor has their own lock-in strategy and the whole
ecosystem suffers for it. Has this improved in the meantime?

~~~
aylons
Windows only tools? You must have been using Altera options (I briefly
maintained the page for Quartus compatibility at wine, circa 2004). Even them
have had Linux support for a while, Xilinx has Linux support for as far as I
remember, at least some ten years.

The ecosystem is terrible, I agree with you. However, the lock in is
restricted for the final synthesis part. Simulation is mostly done with (very
expensive) third party tools, such as Mentor Graphics Modelsim, and in
professional settings the build is automated to a point that opening the
vendor's GUI is frowned upon.

There are some quality open sources tools on FPGA build automation, but most
places I had contact with have their own internal tools.

~~~
stochastic_monk
I know someone who’s implemented some string algorithms for FPGA with verilog.
Is writing the code distinct from the tooling you’re referring to, or simply
an open source flavor of deployment? I haven’t done any FPGA work.

~~~
aylons
When he talks about Verilog, he is referring to the language used for
development and implementation. We're talking about a different part of the
chain, something akin to the compiler, make, cmake and alike.

Of course, there's some dynamic between the tool chain and the language
itself. For example, it doesn't matter if the language has the coolest feature
if the compiler does not support it, and the toolchain will help you manage
more complex code safely.

------
oneplane
But isn't it becoming more like "SoCs gaining FPGA cores"? I know traditional
FPGAs got hard CPU cores added, but from the CPU perspective the FPGA core is
the new thing.

~~~
kingosticks
This article mentions that but doesn't give any details. Annoying since that's
the interesting bit.

------
stochastic_monk
What does SoC stand for? I’m assuming not Summer of Code.

~~~
detaro
[https://en.wikipedia.org/wiki/System_on_a_chip](https://en.wikipedia.org/wiki/System_on_a_chip)

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

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

------
thesz
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 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. It is not clear to me
whether Zynq users have to pay for these buses and it may be case that they
have to. Finally, ARM core in the prototype naturally extends into ARM core in
the final product.

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.

Basically, they put outdated (even for 2010) core design and used valuable
silicon area so users have to use that instead of much more capable
contemporary designs. Instead of trying to figure out how to change typical
FPGA elements and layouts for CPUs to be more synthesable (which may bring
benefits in other places), they decided to use that ARM thing.

I am deeply disappointed with that path.

~~~
adwn
> _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.

> _1) ARM is not RISC (multiregister load /store execute in several clocks)_

So? Who cares?

> _2) too much of initial design of first ARM (which was not planned for
> longterm evolution) is visible in ISA._

Ah, yes, technological purism – the quickest way to practical irrelevance.

~~~
planteen
> 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 is largely irrelevant these days. The
high-performance embedded space is dominated by ARM today with x86 and PPC
taking the rest. There's no way Xilinx would choose x86 with Intel owning
Altera.

Maybe in 5-10 years RISC-V will start to eat some of ARM's share, but that
remains to be seen.

~~~
0xcde4c3db
> 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.

