|
|
|
|
|
by nonrandomstring
1006 days ago
|
|
Interesting that as well as speed, there's more to "transparency"
than meets the eye. Thanks very much to you and the other commenters.
So most of the FPGA tools are proprietary, as they were when I looked
at them 10 years ago? Wonder why there is little FOSS movement. I see there is a gap, between fun hobby projects like building a CPU
from discrete gates on 10 breadboards, and an actual viable (but
slow), microprocessor (and SBC) that can be totally audited and
provably secure (at least to a good logician). |
|
Where the only real open toolchain (Yosys) fails hard is in hard IP blocks, and timing analysis. These are two critical parts of using modern FPGAs, and they require far more information than is ever documented anywhere. Without timing analysis you can't do timing driven synthesis, which is sort of like closing the control loop for optimizing the design.
Device support in Quartus for a simple FPGA family like the Cyclone 3/4/10LP (they are just die shrinks) takes several hundred megs. Most of that is in the timing model dbs. The rest lies in the hard IP models.
So, not that Yosys et al is not great work (outstanding really), but they can only really practically target the easiest low hanging fruit as it relates to FPGA compilation.
Finally, nobody uses softcore CPUs for any substantial processing. They are inefficient and waste precious fabric space. As an example, using up routing wiring for a softcore can negatively impact your Fmax on the rest of the design. As a rough guide, a cheap low end FPGA could run some simple arch like MIPS at maybe 150mhz with a tailwind, but that would quickly decrease if you were to do anything else useful with the FPGA. Higher end chips like the Intel 10 series could maybe hit 400 mhz or a bit more, so really not super impressive compared to dedicated silicon.
The one place you will typically see softcores are
1. System bring up in very large designs
2. Babysitting more complex IP blocks (DDRx ram controller calibration and register programming), HDMI/Display port IP clocking calculations and supervisions etc
3. Toy/research applications
It is virtually always cheaper and more practical to throw on a STM32 or any microcontroller that talks to the FPGA, and it is very rare to not have both in a system.