3 ms·

Full Disclosure, I work for an FPGA company. The mind blowing part of all of this is the fact that they were able to close timing at 771MHz. That is insanely f

Full Disclosure, I work for an FPGA company. The mind blowing part of all of this is the fact that they were able to close timing at 771MHz. That is insanely fast for an FPGA. For perspective, most modern FPGAs run their designs at around 300MHz* While most of the heavy lifting in this design use hardened components like DSPs and FPUs, it's still very impressive to see! What I didn't see talked about much was how memory is loaded in and out of the processor. I'm curious to see what the memory bandwidth numbers look like as well as the resource utilization of the higher level routing. *For most hardware designs that aren't things like CPUs and GPUs, you don't always need a super high clock speed. You have a lot more flexibility to compute in space rather than in time (think more threads running slower.) The pros and cons of such tradeoffs are a bit of a complicated topic, but should at least be noted.

mathisfun123 3y ago
> The mind blowing part of all of this is the fact that they were able to close timing at 771MHz It's true but I mean this is Intel in-house research right? If they can't get absolute peak fmax on their own parts that would be a really bad look right? Plus these stratix parts have hard FP blocks (not just DSPs) so they're basically mostly scheduling stuff rather building the whole datapath. But admittedly I haven't read the paper... >Full Disclosure, I work for an FPGA company I currently do too (as an intern, maybe even the same one as you) and I haven't looked very hard but I'm sure we have similar fmax achieving projects (maybe even GPUs since we're fighting hard to compete with Nvidia...).
- aseipp 3y ago
  I think it's more that the compile was unconstrained, so no floorplanning or handholding synthesis anything (aside from the usual bullshit to e.g. make sure DSPs map correctly). Which is pretty good; yeah, the architecture is also good and you'd expect that at minimum from a team like this, but they also didn't have to beat the tool into submission either which seems nice. IME, until fairly recently at least, Quartus loved to get fiddly on even the most basic designs when using Stratix class parts where you wanted to rely on, say, hyper-registers or retiming. Like a thing that should clearly be pipelined just... doesn't, and falls over from a gust of wind. It seems to have gotten quite a bit better in the last few versions, though, so seeing an unconstrained compile go this high is pretty good I think. Too bad they don't seem to have released their code, though.
  - mathisfun123 3y ago
    > I think it's more that the compile was unconstrained, so no floorplanning or handholding synthesis anything i mean they don't say anything about how long they let it run for - constraints are to narrow the search space for human-time-scale benefit right? i'm sure if i let vivado run (i'm not an intel person) until heat death of the universe it would also give me some fantastic fmax numbers too. > Too bad they don't seem to have released their code, though. and they never will. i don't know what it is about this kind of research (or how you can even get away with this) but it's almost unheard of for the commercial groups to release their code/rtl/tcl scripts. i have emailed around before and i just continually get shined on - "oh we're planning to release but it has to go through legal". and this is from my capacity as a phd student ie not direct competitor. and it's funny to me because if you're selling these boards/part/fpgas aren't you strongly incenvitized to throw as much sample code over the fence as possible so that people buy your hardware in order to use your code?
    - minetest2048 3y ago
      >if you're selling these boards/part/fpgas aren't you strongly incenvitized to throw as much sample code over the fence as possible so that people buy your hardware in order to use your code? I wish... this is a problem for general embedded things. We just recently bought a cubesat bus and the only way to interface our hardware with it is to send CAN bus frames to it. We asked them for an SDK and they don't have it. Instead they sent us a bunch of ICDs with screenshots of readthedocs snippets containing the frame structures. The unfortunate answer to that question is that unfortunately we don't make purchasing decisions based on whether sample code exists, or detailed documentation quality for niche embedded hardware. Maybe because everyone is not giving those things.
mytailorisrich 3y ago
> The mind blowing part of all of this is the fact that they were able to close timing at 771MHz. That is insanely fast for an FPGA. For perspective, most modern FPGAs run their designs at around 300MHz I could not find the datasheet of the exact FPGA they used (did not spend much time) but Google says that Intel Agilex FPGAs (which is what they used) rated at 600MHz+ are available. I'm not saying that they did something easy but they obviously used a fast FPGA.

mathisfun123 3y ago

> The mind blowing part of all of this is the fact that they were able to close timing at 771MHz It's true but I mean this is Intel in-house research right? If they can't get absolute peak fmax on their own parts that would be a really bad look right? Plus these stratix parts have hard FP blocks (not just DSPs) so they're basically mostly scheduling stuff rather building the whole datapath. But admittedly I haven't read the paper... >Full Disclosure, I work for an FPGA company I currently do too (as an intern, maybe even the same one as you) and I haven't looked very hard but I'm sure we have similar fmax achieving projects (maybe even GPUs since we're fighting hard to compete with Nvidia...).

aseipp 3y ago
I think it's more that the compile was unconstrained, so no floorplanning or handholding synthesis anything (aside from the usual bullshit to e.g. make sure DSPs map correctly). Which is pretty good; yeah, the architecture is also good and you'd expect that at minimum from a team like this, but they also didn't have to beat the tool into submission either which seems nice. IME, until fairly recently at least, Quartus loved to get fiddly on even the most basic designs when using Stratix class parts where you wanted to rely on, say, hyper-registers or retiming. Like a thing that should clearly be pipelined just... doesn't, and falls over from a gust of wind. It seems to have gotten quite a bit better in the last few versions, though, so seeing an unconstrained compile go this high is pretty good I think. Too bad they don't seem to have released their code, though.
- mathisfun123 3y ago
  > I think it's more that the compile was unconstrained, so no floorplanning or handholding synthesis anything i mean they don't say anything about how long they let it run for - constraints are to narrow the search space for human-time-scale benefit right? i'm sure if i let vivado run (i'm not an intel person) until heat death of the universe it would also give me some fantastic fmax numbers too. > Too bad they don't seem to have released their code, though. and they never will. i don't know what it is about this kind of research (or how you can even get away with this) but it's almost unheard of for the commercial groups to release their code/rtl/tcl scripts. i have emailed around before and i just continually get shined on - "oh we're planning to release but it has to go through legal". and this is from my capacity as a phd student ie not direct competitor. and it's funny to me because if you're selling these boards/part/fpgas aren't you strongly incenvitized to throw as much sample code over the fence as possible so that people buy your hardware in order to use your code?
  - minetest2048 3y ago
    >if you're selling these boards/part/fpgas aren't you strongly incenvitized to throw as much sample code over the fence as possible so that people buy your hardware in order to use your code? I wish... this is a problem for general embedded things. We just recently bought a cubesat bus and the only way to interface our hardware with it is to send CAN bus frames to it. We asked them for an SDK and they don't have it. Instead they sent us a bunch of ICDs with screenshots of readthedocs snippets containing the frame structures. The unfortunate answer to that question is that unfortunately we don't make purchasing decisions based on whether sample code exists, or detailed documentation quality for niche embedded hardware. Maybe because everyone is not giving those things.

mytailorisrich 3y ago

> The mind blowing part of all of this is the fact that they were able to close timing at 771MHz. That is insanely fast for an FPGA. For perspective, most modern FPGAs run their designs at around 300MHz I could not find the datasheet of the exact FPGA they used (did not spend much time) but Google says that Intel Agilex FPGAs (which is what they used) rated at 600MHz+ are available. I'm not saying that they did something easy but they obviously used a fast FPGA.