7 ms·

This talk struck me as conflicting in a sort of have-your-cake-and-eat-it-too kind of way. The wrinkles part[1] summarizes a lot of what this individual is advo

This talk struck me as conflicting in a sort of have-your-cake-and-eat-it-too kind of way. The wrinkles part[1] summarizes a lot of what this individual is advocating. Paraphrasing (with equivalent liberal handwaving of details as the talk does): I want to write FPGA code like any other high-level programming language (but quickly dismiss that the hard part of developing native HDL is in fact that it's fundamentally a lot more akin to architecting physical hardware). I want to use FPGAs because they're powerful (but only when a conceptual design aligns with a traditional microcontroller architecture). I want to use FPGAs because they're flexible (but I need to nerf proprietary building blocks that endow specific devices with competitive edge, or trade significant performance in other ways to do so). I want to commodify the development peripheral market (but only if they conform to a certain commercially trademarked and weakly defined spec[2] inherently constrained to low-frequency applications where sloppy SI is presumed to be inconsequential). I want to standardize high-performance interfaces (so arbitrarily "abandon standards you don't like" and simply write your own, but only if they're not "annoying"...and look like a custom FIFO with specific signal labels). I'm sure this will be an unpopular opinion, but the positive feedback loop generated around this topic needs a stability check. [1] https://youtu.be/ME_e06ApxJA?t=2080 https://youtu.be/ME_e06ApxJA?t=2080 [2] https://digilentinc.com/Pmods/Digilent-Pmod_%20Interface_Specification.pdf https://digilentinc.com/Pmods/Digilent-Pmod_%20Interface_Spe...

pclmulqdq 5y ago
FPGA evangelists like this really need a reality check. Programming in RTL is not easy, and it's not really a skill that most people need, so it doesn't make a lot of sense as an educational tool. The "killer app" for hobbyist FPGAs might be some sort of "SoC builder" tool that lets you build a specific microcontroller around a few high-performance cores, and then program it like software. But don't worry. Since 2000, mainstream FPGA programming has been right around the corner.
- mypalmike 5y ago
  The SoC builder you describe might be the MiSTer project for console hardware emulation. But even then, the number of people who develop verilog for that project is rather tiny. However, it's the first platform that has gotten me, a long time software developer, to really look into how it works. As in, I've been working through verilog tutorials, etc. and formulating a project to build on it. Compare to when I first bought a Xilinx FPGA dev board some 20 years ago, I found that I had no idea what to do with it, and there were not many resources to learn from compared to today. I don't think it's going to be mainstream soon, but there's definitely been some progress.
- canada_dry 5y ago
  > Since 2000, mainstream FPGA programming has been right around the corner. As an avid technologist I dabble in everything from electronics to assembler. But, every time I try dipping my toe into FPGA programming I quickly retreat! The tools are too complex and the whole process has a learning curve that far out weigh using a stock CPU/SoC.
  - FPGAhacker 5y ago
    > The tools are too complex and the whole process has a learning curve that far out weigh using a stock CPU/SoC. Sadly this is true, although the open source tools are gaining ground pretty quickly from what I understand. https://symbiflow.github.io/getting-started.html https://symbiflow.github.io/getting-started.html
- blihp 5y ago
  https://github.com/enjoy-digital/litex https://github.com/enjoy-digital/litex
- FPGAhacker 5y ago
  Personally I think "programming" RTL is dead simple. It's so simple, in fact, that it's not even interesting. But I've been doing it forever so my perspective is skewed.
  - pclmulqdq 5y ago
    I think you are thinking of different types of tasks. A lot of RTL is brainless, but if you are actually trying to compute with it, it can get tough. A mediocre C++ programmer can write a (bad) hash table in C++ in a few hours. How fast can you give me one in Verilog?
    - IQunder130 5y ago
      You're not writing a hash table in verilog, you're writing a hardware configuration that can hold and manipulate a hash table. It's a different ball game.
    - FPGAhacker 5y ago
      I have to make a lot of assumptions, but a couple hours doesn't seem unreasonable for the core function. Among the many assumptions are the hash function, what is actually being hashed, what processor interface is, desired performance, etc.
- swiley 5y ago
  Meh. HDL isn't that hard and there are good books on it. The main reason FPGA programming is unpopular is because the tools are pretty hideous. Icestorm makes things a lot better but it supports like 5 parts and they're not very powerful ones.
  - exikyut 5y ago
    How cheap are the devkits, can I easily source <10 unit quantities for <$ouch, and what are the limitations? - Fundamental questions I imagine a semi-interested tinkerer would be asking
    - swiley 5y ago
      devkits compatible with icestorm? I have an icestick that I've messed with, at 1x it costs $20 (at least when I bought it off amazon.)
- detaro 5y ago
  Accessibility of FPGAs has made massive strides since 2000. You can nowadays get people build a really basic FPGA demo in an hour, starting with a dev board and their unprepared laptop, and even I remember times where you'd struggle to get the tooling installed in that time. (Not going to go into "mainstream", because that's a) incredibly vague (is microcontroller programming "mainstream"?) and b) IMHO not that interesting - it's fine for specialist things to be accessible but not mainstream)
elcritch 5y ago
Good points! His talk is full of enthusiasm, and I am partial to the overall notion of better integration of data and peripherals. Still it seems much of what he's wanting could be handled by approaches like the RP2040 chip from the RPi folks that let's you define your own low level pin level protocols using assembly to program state machines. Also many newer MCUs allow you define almost any function on any pin via internal IO muxes. Some MCU's even contain a small FPGA / CPLD. Also, I prefer the "Mikroe Click" add-on / peripheral board from Mikroe Electronics. It's got a decent ecosystem and it handy for making quick "proto-pcb"'s that integrate sensors but allow you to iterate smaller circuits (even with hand made proto boards https://www.mikroe.com/proto-click https://www.mikroe.com/proto-click). There's a few other non-Mikroe vendors as well. Given how difficult FPGA's seem to be to program, there's lots of alternatives to achieve the same goals. Things like RISC-V or OpenPOWER and the leveling off of improving semiconductor node sizes will probably lead to a lot more "customizable peripherals" in the next decade, but programmed using the MCU.
haberman 5y ago
What constrains PMod to low-frequency applications with sloppy SI? What inherently limits the frequency? I have been dabbling in FPGA programming on a Xilinx Nexys A7. Through some PMod ports, I've managed to drive the shift registers on an LED matrix display at 20MHz. Is this considered high frequency? My oscilloscope shows that the signal is somewhat messy at this frequency. But the data sheet for the shift register suggests that the thresholds are 0.7xVcc and 0.3xVcc for high and low, so it seems to be good enough. Is this shift register unusually accepting of sloppy SI? I'm not understanding how a PMod port would constrain the usable frequency. If my clock is going at 100MHz inside the FPGA, what prevents signals of this frequency being sent through PMod wires? Is a PMod port different than the normal I/O pins offered on a board like TinyFPGA?
- metaphor 5y ago
  Not trying to be unhelpful, but if the assertion was not immediately evident, then you're missing a huge chunk of basic undergrad EE theory that cannot be dismissed as merely academic. I'd recommend reading the spec (it's only 10 pages) and coming to your own conclusions. To your shift register question---which is the only one with enough detail to afford a quick answer---referencing JEDEC JESD8C.01 § 2.3 Table 2 as basis of comparison: yes wrt VILmax, and no wrt VIHmin...at face value, it doesn't comply with industry standard, but is nevertheless permissible by Pmod spec because, well, it's a shit spec by a sample size of 1 engineer's measure. To your TinyFPGA question, I don't care to ponder the design considerations (or lack thereof) of arbitrary hobbyist dev boards in the wild. In the nicest way possible, it's a complete waste of my time, sorry. Suffice it to say the spec's interconnect choice is the primary limiter, compounded by permissiveness in some aspects, poor specificity in others, and the general ease of abusing objective interoperability while still complying with normative language. I leave it to the passerby as an exercise to consider the implications of the following notions in this context: 1. All real conductors exhibit certain parasitic properties which deviate from an ideal model; whose characteristics are largely a function of physical geometries, relevant material properties, and the signals that flow in/around them; and whose significance is almost entirely dependent on the application under consideration. 2. An arbitrary signal that satisfies the 3 Dirichlet conditions can be summarily expressed as the linear sum of its fundamental and harmonic sinusoidal components. 3. As a back-of-the-envelope measure, transmission line effects cannot be so easily neglected when, in a point-to-point system, the ratio of the distance that a signal must traverse to the wavelength of the propagating signal itself exceeds roughly 1%.

pclmulqdq 5y ago

FPGA evangelists like this really need a reality check. Programming in RTL is not easy, and it's not really a skill that most people need, so it doesn't make a lot of sense as an educational tool. The "killer app" for hobbyist FPGAs might be some sort of "SoC builder" tool that lets you build a specific microcontroller around a few high-performance cores, and then program it like software. But don't worry. Since 2000, mainstream FPGA programming has been right around the corner.

mypalmike 5y ago
The SoC builder you describe might be the MiSTer project for console hardware emulation. But even then, the number of people who develop verilog for that project is rather tiny. However, it's the first platform that has gotten me, a long time software developer, to really look into how it works. As in, I've been working through verilog tutorials, etc. and formulating a project to build on it. Compare to when I first bought a Xilinx FPGA dev board some 20 years ago, I found that I had no idea what to do with it, and there were not many resources to learn from compared to today. I don't think it's going to be mainstream soon, but there's definitely been some progress.
canada_dry 5y ago
> Since 2000, mainstream FPGA programming has been right around the corner. As an avid technologist I dabble in everything from electronics to assembler. But, every time I try dipping my toe into FPGA programming I quickly retreat! The tools are too complex and the whole process has a learning curve that far out weigh using a stock CPU/SoC.
- FPGAhacker 5y ago
  > The tools are too complex and the whole process has a learning curve that far out weigh using a stock CPU/SoC. Sadly this is true, although the open source tools are gaining ground pretty quickly from what I understand. https://symbiflow.github.io/getting-started.html https://symbiflow.github.io/getting-started.html
blihp 5y ago
https://github.com/enjoy-digital/litex https://github.com/enjoy-digital/litex
FPGAhacker 5y ago
Personally I think "programming" RTL is dead simple. It's so simple, in fact, that it's not even interesting. But I've been doing it forever so my perspective is skewed.
- pclmulqdq 5y ago
  I think you are thinking of different types of tasks. A lot of RTL is brainless, but if you are actually trying to compute with it, it can get tough. A mediocre C++ programmer can write a (bad) hash table in C++ in a few hours. How fast can you give me one in Verilog?
  - IQunder130 5y ago
    You're not writing a hash table in verilog, you're writing a hardware configuration that can hold and manipulate a hash table. It's a different ball game.
  - FPGAhacker 5y ago
    I have to make a lot of assumptions, but a couple hours doesn't seem unreasonable for the core function. Among the many assumptions are the hash function, what is actually being hashed, what processor interface is, desired performance, etc.
swiley 5y ago
Meh. HDL isn't that hard and there are good books on it. The main reason FPGA programming is unpopular is because the tools are pretty hideous. Icestorm makes things a lot better but it supports like 5 parts and they're not very powerful ones.
- exikyut 5y ago
  How cheap are the devkits, can I easily source <10 unit quantities for <$ouch, and what are the limitations? - Fundamental questions I imagine a semi-interested tinkerer would be asking
  - swiley 5y ago
    devkits compatible with icestorm? I have an icestick that I've messed with, at 1x it costs $20 (at least when I bought it off amazon.)
detaro 5y ago
Accessibility of FPGAs has made massive strides since 2000. You can nowadays get people build a really basic FPGA demo in an hour, starting with a dev board and their unprepared laptop, and even I remember times where you'd struggle to get the tooling installed in that time. (Not going to go into "mainstream", because that's a) incredibly vague (is microcontroller programming "mainstream"?) and b) IMHO not that interesting - it's fine for specialist things to be accessible but not mainstream)

elcritch 5y ago

Good points! His talk is full of enthusiasm, and I am partial to the overall notion of better integration of data and peripherals. Still it seems much of what he's wanting could be handled by approaches like the RP2040 chip from the RPi folks that let's you define your own low level pin level protocols using assembly to program state machines. Also many newer MCUs allow you define almost any function on any pin via internal IO muxes. Some MCU's even contain a small FPGA / CPLD. Also, I prefer the "Mikroe Click" add-on / peripheral board from Mikroe Electronics. It's got a decent ecosystem and it handy for making quick "proto-pcb"'s that integrate sensors but allow you to iterate smaller circuits (even with hand made proto boards https://www.mikroe.com/proto-click https://www.mikroe.com/proto-click). There's a few other non-Mikroe vendors as well. Given how difficult FPGA's seem to be to program, there's lots of alternatives to achieve the same goals. Things like RISC-V or OpenPOWER and the leveling off of improving semiconductor node sizes will probably lead to a lot more "customizable peripherals" in the next decade, but programmed using the MCU.

haberman 5y ago

What constrains PMod to low-frequency applications with sloppy SI? What inherently limits the frequency? I have been dabbling in FPGA programming on a Xilinx Nexys A7. Through some PMod ports, I've managed to drive the shift registers on an LED matrix display at 20MHz. Is this considered high frequency? My oscilloscope shows that the signal is somewhat messy at this frequency. But the data sheet for the shift register suggests that the thresholds are 0.7xVcc and 0.3xVcc for high and low, so it seems to be good enough. Is this shift register unusually accepting of sloppy SI? I'm not understanding how a PMod port would constrain the usable frequency. If my clock is going at 100MHz inside the FPGA, what prevents signals of this frequency being sent through PMod wires? Is a PMod port different than the normal I/O pins offered on a board like TinyFPGA?

metaphor 5y ago
Not trying to be unhelpful, but if the assertion was not immediately evident, then you're missing a huge chunk of basic undergrad EE theory that cannot be dismissed as merely academic. I'd recommend reading the spec (it's only 10 pages) and coming to your own conclusions. To your shift register question---which is the only one with enough detail to afford a quick answer---referencing JEDEC JESD8C.01 § 2.3 Table 2 as basis of comparison: yes wrt VILmax, and no wrt VIHmin...at face value, it doesn't comply with industry standard, but is nevertheless permissible by Pmod spec because, well, it's a shit spec by a sample size of 1 engineer's measure. To your TinyFPGA question, I don't care to ponder the design considerations (or lack thereof) of arbitrary hobbyist dev boards in the wild. In the nicest way possible, it's a complete waste of my time, sorry. Suffice it to say the spec's interconnect choice is the primary limiter, compounded by permissiveness in some aspects, poor specificity in others, and the general ease of abusing objective interoperability while still complying with normative language. I leave it to the passerby as an exercise to consider the implications of the following notions in this context: 1. All real conductors exhibit certain parasitic properties which deviate from an ideal model; whose characteristics are largely a function of physical geometries, relevant material properties, and the signals that flow in/around them; and whose significance is almost entirely dependent on the application under consideration. 2. An arbitrary signal that satisfies the 3 Dirichlet conditions can be summarily expressed as the linear sum of its fundamental and harmonic sinusoidal components. 3. As a back-of-the-envelope measure, transmission line effects cannot be so easily neglected when, in a point-to-point system, the ratio of the distance that a signal must traverse to the wavelength of the propagating signal itself exceeds roughly 1%.