Memory Mapping an FPGA from an STM32

(serd.es)

67 points | by hasheddan 44 days ago

5 comments

  • buescher 44 days ago
    This is really crisp work and nice to see. Before the Zynq era I worked with some designs that used a DSP or StrongARM along with a medium-sized FPGA, where the FPGA would be both the glue logic for RAM as well as custom peripherals, but I've been out of that world for a while. It would be fun to find an application for a big FPGA and a modern microcontroller.
  • 15155 44 days ago
    I recommend checking out SpinalHDL generally - I do a ton of this very same kind of work with these same chips (7 series, US+) and would never look back to Verilog!

    AXI (and all memory-mapped bus protocol schemes) becomes very very pleasant. SV interfaces get you 5% of the way there, though!

    Also - I was under the impression that S1000-2M is a higher-end material, not cost-optimized? (But not Rogers, of course.)

    • azonenberg 44 days ago
      S1000-2 is quite cheap and lossy (Df 0.016), slightly better than Isola 370HR (0.021) but nowhere near the stuff I usually use. At my usual Chinese board house it's one of the lowest cost substrates available for prototypes since it's always in stock and there's no need to special order.

      For higher end digital work I typically reach for Taiwan Union TU872SLK (Df 0.009) which also has a better range of prepregs and glass styles available to help minimize fiber weave effect. Still quite a bit lossier than e.g. RO4350B but far less expensive and if you have decent equalizers on your SERDES the difference is typically not significant unless you're making some kind of humongous backplane. I get wide open eyes with just a tiny bit of post-cursor emphasis on the TX FFE at 10.3125 Gbps on TU872SLK for my typical shortish high speed tracks (FPGA to SFP+ cage).

      • buescher 44 days ago
        Also S1000-2 is not rated/controlled past 1GHz. It shouldn't vary that much so for small runs the risk is minimal. But for volume production that's exactly the sort of thing you never want to have to investigate in hindsight.
      • 15155 44 days ago
        Curious who you are using in CN for higher-speed FPGA boards, if you can share!

        I haven't seen these as directly-advertised options at any of my usual suspects.

        • azonenberg 44 days ago
          Multech (multech-pcb.com) is my preferred manufacturer these days for high end stuff. I've done six layer HDI any-layer via stackups, ten layers with filled via-in-pad, RO4350B, TU872SLK, flex, 75 micron trace/space, etc. And that's nowhere near the limit of their capabilities, I just haven't needed higher end yet.

          I have some 25/100G stuff in the pipe for probably some time next year that I plan to make with them too.

          Their website undersells, I get the impression most of the actual sales contacts are word of mouth. I talk to my sales rep by skype mostly (the alternatives are expensive international phone calls or wechat).

          The really cool thing is that you get a 10+ page QA report with every order including measured copper/dielectric/soldermask thicknesses, hole sizes, ionic contamination measurements, and a ton of other metrics. And they send the TDR strips and polished cross section with every order as their way of saying "look, we actually did the QA, double check our measurements if you don't trust us". (I actually have repeated some of the measurements to spot-check and got results within a few percent of their QA department, no surprises there).

          And they don't make silent gerber changes or anything. They do a full CAM review and send you working gerbers and a list of suggested DFM tweaks for you to sign off before beginning manufacture. If something doesn't look right you have a chance to say "wait there's a problem".

          For example, one time they wanted to make a really large width adjustment for impedance on some RF traces that I had carefully modeled in an EM solver. But they didn't make a bad board without telling me, they flagged it on the CAM review and we went back and forth before realizing the mistake was on their end (they had calculated impedance assuming solder mask over the traces, while they were actually exposed copper). They re-ran the numbers which then closely matched my simulations, I signed off on the modified design, and the board was manufactured without issue.

  • throwawayabcdef 44 days ago
    This is dope. I work with Zynq/Versal quite a bit and respect and understand (conceptually) the decisions you have made!

    You get to own every aspect of your toolchain and with that will come a lot of power.

    Are you familiar with:

    https://github.com/corundum/corundum

    Perhaps you can build a support package for your platform.

  • Already__Taken 44 days ago
    real quite high level sorry, most of your embedded projects going forward are MCU+fpga to do what? I thought a custom router but 284mbps isn't nearly fast for a network.
    • azonenberg 44 days ago
      The intent is for the high performance datapath to live entirely in FPGA (and the project you're probably thinking of is switching, not routing).

      The MCU is for control plane only. Several hundred Mbps between the control and data plane is more than enough for a SSH management CLI and poking registers on the FPGA to move a port to a different VLAN in response to a CLI command or add an ACL rule or something.

    • UncleOxidant 44 days ago
      It's a good question. A lot of FPGA projects I see (including some real life products I've looked into recently) don't really need an FPGA. One I was asked to evaluate recently could easily have been done with a microcontroller with PWM outputs. The frequencies involved were well under 40MHz. Yes, there were a couple of multiplications going on in the FPGA, but there those could've been easily handled by a micorcontroller. An RP2040 would've sufficed instead of what they had - a microcontroller + an FPGA.
      • azonenberg 44 days ago
        The projects in question include things like a 48 port gigabit Ethernet switch with packet datapath in the FPGA, and dual 10/25G SFP28 uplinks. You're not doing that on a MCU. Also higher end oscilloscope work (e.g. 10 Gsps 12-bit JESD204B)

        But a STM32 is more than sufficient for the management interface on both.

      • rvense 44 days ago
        I think a lot of people don't fully appreciate how fast a modern "microcontroller" is. That 'H735 is probably faster than every computer I had up to and including the iBook G4 I until early 2009.
        • buescher 44 days ago
          I keep running into that also. It's like the common mental model of a microcontroller froze around Y2K as a sort of headless VIC-20. I had an FAE, and a good one, from a major supplier tell me "you can't implement a filter" on a low-end micro that was roughly as powerful as an early nineties DSP.
  • chillingeffect 44 days ago
    Neat! I love that H7 chip and its gargantuan inatruction manual... ...and you didn't even mention its 2nd core :)
    • azonenberg 44 days ago
      H735 is one of the single core SKUs. Just a 550 MHz M7.

      Would not surprise me if the M4 was there and fused off (i.e. same die as multicore H7 offerings), but it's not active.