Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How FPGAs work, and why people will buy them (2013)

embeddedrelated.com

Post reply on HN
Print view View original

61–70 of 119 posts

Re: How FPGAs work, and why people will buy them (2013)

#61

Post by floatboth »

pmalynin wrote: post #30
floatboth wrote: post #21

I wonder if FPGAs would make good crypto devices, e.g. for disk encryption? If you implement AES on an FPGA, is it fast enough to keep up with at least a SATA 3 SSD?

I thought that CPU’s with AES-NI can already keep up. EDIT: in fact I just looked up some benchmarks for Ryzen and it can do 3GB/s per core. So that should be enough

It's not about performance. (Perf is necessary, not the goal.)

Doing crypto on a separate chip lets you keep they key away from system RAM and CPU cache, removing any possibility of leaks into other programs.

Re: How FPGAs work, and why people will buy them (2013)

#62

Post by floatboth »

aseipp wrote: post #31
floatboth wrote: post #21

I wonder if FPGAs would make good crypto devices, e.g. for disk encryption? If you implement AES on an FPGA, is it fast enough to keep up with at least a SATA 3 SSD?

Yes, they can do traditional cryptography pretty well (depending on the algorithm, of course.) AES-128 in an FPGA can encrypt a full 16-byte block every clock cycle when done right. With 100Mhz clock that's about 2.3Gbp/s, well within SATA 3 transfer speeds. You can achieve that with a last-last-gen FPGA that will cost you a couple bucks out of pocket, and it will use a fraction of the power/thermal footprint of any…

The FPGA advantage I was thinking of is that FPGAs are not covered by any crypto export regulations in any country.

As well as the possibility of the crypto "code" (HDL) being open source.

Re: How FPGAs work, and why people will buy them (2013)

#63

Post by esmi »

davemp wrote: post #20
sfifs wrote: post #10

Earlier quoted context omitted.

Actually I recently bought a Spartan 7 based FPGA board after taking the nand2tetris course and started playing with the free version of the Vivado suite. If your complaint is principle based on the stuff being non free software, then it holds. If it's on usability - not sure it does. While lengthy, the process of compiling and getting something running on silicon didn't seem any more complicated than Grade/Maven etc…

For basic implementations in ways intended by the vendor, I'm sure the supplied tools are fine. When you want to leave the sandbox and do interesting things, it's hard. I was thinking along the lines of writing your own tools that would require information about timings and chip resources/layouts. EDIT: your cpu ISA is open, but fpga layout/bit-stream is not--locking you to your vendor's innovation and ideas for how…

What does leaving the sandbox mean when implementing an FPGA?

I'm not aware of any soft resource one can't completely control in Vivado/Xilinx as every hard resource can be completely described in your own design via the primitive library. That doesn't mean it is always a good idea, but one can do it.

Re: How FPGAs work, and why people will buy them (2013)

#64

Post by user5994461 »

analognoise wrote: post #60
user5994461 wrote: post #48

Earlier quoted context omitted.

Maven is just right click + build to build. Or file + import to import a project. The last time I worked with Vivado, I remember our interns couldn't manage to create a project or use an existing project after a whole week. It doesn't help that there are no tutorials from the vendor or the internet, or that projects can't be stored in source control.

I went on an interview once where part of the process was "here is a development board. Here is a computer and the internet. Make a full adder, connect the inputs to push buttons and the outputs to LEDs. You have all day, by yourself, in a cubicle." I was told it cut out something like 95% of candidates who looked good on paper. It was an interesting approach.

That's what the interns were trying to do. Get a push button to a LED working, on a Xilinx SoC, with the Vivado IDE. They couldn't figure it out in days.

I don't blame them. I tried and couldn't get it working in a day either. We were lucky we found another guy in the company who worked with that board on a different project. He showed us and he had extensive notes to get the environment working.

Embedded development really sucks.

Re: How FPGAs work, and why people will buy them (2013)

#65

Post by ChuckMcM »

davemp wrote: post #5

> FPGAs are a programmable platform, but one designed by EEs for EEs rather than for programmers. This is the problem with FPGAs. Their performance and utility is not really disputed. Working with them is so un-ergonomic that it's frankly embarrassing. The EE world is notoriously closed/proprietary making it incredibly difficult to explore novelty or customize tooling to suit specific needs. The situation is reminisc…

I too decry the lack of openness with respect to the data file encoding which would allow for more open source tools to be created. I had a hilarious discussion with Xilinx's VP of tools about this[1].

The interesting thing about HDLs and HDL work flows is that they can "look" like software and yet not be software. VHDL and Verilog are the only "languages" I know where you can write something that is both syntactically correct and cannot by inferred into logic by the synthesis part of the tool (equivalent of the code generator in a compiler). I am not aware of any equivalent to the Turing definition of computability which would prove for any legal construct in language X there was an implementation of synchronous logic Y that could implement it. Most of the bugs are easy to avoid once you know them though, things like a register value being assigned two different values in the same process block.

That said, I've been playing lately with an "Ultra96"[2] board which is pretty freakin' cool. quad core 64 bit ARM CPU and a nice chunk of FPGA fabric to play with as well. I think it can be the basis for a pretty sweet SDR setup.

[1] His assertion was that things had to be hidden so that they could protect the value of the software, when I countered they could put a 5% tax on every chip they sold and allocate it to software which would give his team more money than it had today, he argued he would lose sales to cheaper FPGAs, and I asked how the people trying to sell C compilers were holding up, and would anyone buy chips if they had to pay extra for their tools when a top chip maker gave away their tools for free? And then he said it needed to be proprietary to keep the quality up, and I went back and asked what C compiler he used, and he admitted they used GCC (when they were compiling for Petalinux etc) and I asked why they didn't use a proprietary C/C++ compiler? And he said they didn't keep up with the standards and gcc generated just as good code generally as the proprietary ones did. He was left with "just because" as his only rational for not making all of the documentation freely available and using the cost of the chips to leverage the tools cost (which I told him would go away as soon as the open source community had caught up with and surpassed Vivado)

[2] http://zedboard.org/product/ultra96

Re: How FPGAs work, and why people will buy them (2013)

#66

Post by jjoonathan »

dmitrygr wrote: post #47
Cyph0n wrote: post #17

Earlier quoted context omitted.

IEEE tracks a vast number of open standards and specifications (e.g., Ethernet, WiFi, Bluetooth). I guess the comment was pointing out that there is a degree of openness in EE.

> IEEE tracks a vast number of open standards And demands mega-bucks for a PDF of any of those standards

So that organizations with money that benefit from the standards pay for their creation. For everyone else, there's scihub.

Re: How FPGAs work, and why people will buy them (2013)

#67

Post by esmi »

atq2119 wrote: post #43
TomVDB wrote: post #38

Earlier quoted context omitted.

> The EE world is notoriously closed/proprietary making it incredibly difficult to explore novelty or customize tooling to suit specific needs. The EE world could use novelty tooling to increase the efficiency by which you create RTL. But that can easily be done today if you consider Verilog to be an intermediate representation. So I think you're talking about the tooling on the steps to go from RTL to bitstream? Wha…

There's potentially tremendous value in having an open bitstream. To get the most out of hardware, you need feedback on how many LUTs each part of your design uses, where the critical dependencies are for the achievable clock rates, and so on. It's difficult to get this information in a usable way in practice today even when you're writing Verilog. Using Verilog as an intermediate language makes the problem significa…

Why do you think this information is unavailable today?

I can get the critical paths, device utilization, power, etc. from every vendor's software suite I'm aware of. And they are all fully scriptable from the TCL interface. Once I have a mostly stable design, I usually run Xilinx/Vivado from the command line. Same with Lattice. The reports the vendors provide are much better than what would get from the raw bitstream because it has all the symbol information. What you're proposing is akin to decompiling c from object code.

Also keep in mind there is huge variation in architectures between vendors, products, and the various product categories. For example, few things LUT based anymore. Now we have macrocells, "logic elements," and slices, etc. and that's just the soft stuff.

People have been working on implementing FPGA in higher level languages for years. Even LLVM to RTL has been tried a few times. I've observed matlab to RTL is starting to catch on in the DSP/control-system crowd.

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

Re: How FPGAs work, and why people will buy them (2013)

#68

Post by esmi »

monocasa wrote: post #27
simias wrote: post #16

Earlier quoted context omitted.

FPGAs have been used in the industry for decades, basically every time you need high throughput and/or very low latencies and you don't have the volume to justify making an ASIC then FPGAs and CPLDs are the way to go. The article is not really talking about that though, it's more about having FPGAs in mainstream desktop computers. This is still far from a reality, even if Intel seems to be pushing for it.

I mean, I know, I've professionally written HDL for FPGAs. My point is that back then (a decade or so ago and farther back) it was relegated to low volume, high margin products, explicitly as a replacement for an ASIC. This was due to the cost of the FPGAs. The point of this article is that by embracing the reprogrammable nature, they'll make their way into places that in fact have the volumes required for an ASIC (w…

Keep in mind ASIC fabrication and tool prices are way down compared to 10 years ago so "cheaper than an ASIC" is a moving target too.

Re: How FPGAs work, and why people will buy them (2013)

#69

Post by Timmah »

pmalynin wrote: post #30
floatboth wrote: post #21

I wonder if FPGAs would make good crypto devices, e.g. for disk encryption? If you implement AES on an FPGA, is it fast enough to keep up with at least a SATA 3 SSD?

I thought that CPU’s with AES-NI can already keep up. EDIT: in fact I just looked up some benchmarks for Ryzen and it can do 3GB/s per core. So that should be enough

Just because it can doesn't mean it's tolerable to have one core of their CPU eaten up just working on AES all day. Plus if it wasn't task set to a CPU you'd see massive latency hits on disk access even the CPU could keep up. The kernel still has to schedule the task and load balance.

Re: How FPGAs work, and why people will buy them (2013)

#70

Post by Shikadi »

sfifs wrote: post #10
davemp wrote: post #5

> FPGAs are a programmable platform, but one designed by EEs for EEs rather than for programmers. This is the problem with FPGAs. Their performance and utility is not really disputed. Working with them is so un-ergonomic that it's frankly embarrassing. The EE world is notoriously closed/proprietary making it incredibly difficult to explore novelty or customize tooling to suit specific needs. The situation is reminisc…

Actually I recently bought a Spartan 7 based FPGA board after taking the nand2tetris course and started playing with the free version of the Vivado suite. If your complaint is principle based on the stuff being non free software, then it holds. If it's on usability - not sure it does. While lengthy, the process of compiling and getting something running on silicon didn't seem any more complicated than Grade/Maven etc…

Maybe for personal projects, but I find I spend more time dealing with vivado bugs than I do vhdl bugs. I spent four hours today just getting a simulation to run correctly in 2017.3 upgraded from 2016.1. My Co worker was simultaneously dealing with a bug where deleting a net in ECO was silently deleting other nets, and not necessarily causing an error. EE tools are the worst.
Post reply on HN