Be veeeery careful. STM32H QSPI peripheral is <i>FULL OF</i> very nasty bugs, especially the second version (supports writes) that you find in STM32H0B chips . You are currently avoiding them by having QSPI mapped as device memory, but the minute you attempt to use it with cache or run code from it, or (god help you) put your stack, heap, and/or vector table on a QSPI device, you are in for a world of poorly-debuggable 1:1,000,000 failures. STM knows but refuses to publicly acknowledge, even if they privately admit some other customers have "hit similar issues". Issues I've found, demonstrated to them, and wrote reliable replications of:<p>* non-4-byte-sized writes randomly lost about 1/million writes if QSPI is writeable and not cached<p>* non-4-byte-sized writes randomly rounded up in size to 2 or 4 bytes with garbage, overwriting nearby data about 1/million writes if QSPI is writeable and cached<p>* when PC, SP, and VTOR all point to QSPI memory, any interrupt has about a 1/million chance of reading garbage instead of the proper vector from the vector table if it interrupts a LDM/STM instruction targeting the QSPI memory and it is cached and misses the cache<p>Some of these have workarounds that I found (contact me). I am refusing to disclose them to STM until they acknowledge the bugs publicly.<p>I recommend NOT using STM32H7 chips in any product where you want QSPI memory to work properly.
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!<p>AXI (and all memory-mapped bus protocol schemes) becomes very very <i>pleasant.</i> SV interfaces get you 5% of the way there, though!<p>Also - I was under the impression that S1000-2M is a higher-end material, not cost-optimized? (But not Rogers, of course.)
While we're talking about this sort of architecture, I'd like to plug Elixir.<p>For some development hardware, we had Elixir running on the ARM of a Zynq Ultrascale, running in tandem with some digital logic. It required one C code "port" that integrated with UIO to expose the registers to our application and then we had a great programming environment.<p>Elixir for embedded doesn't get talked about that much, but that is actually the origin story of Erlang (software component of telephony hardware). Basic language features like binary pattern matching work very well, and the concurrency approach makes it very easy to write clean performant real-time software. We had a lot of functionality that did used digital logic and then had the stateful stuff in software and it worked very well.<p>Plus, I could then do stuff like trivially spin up a Web UI with a graphical display of all the register state, that updated live (Phoenix LiveView). And be happy that that running wasn't going to interfere with the realtime stuff.<p>We did this using Nerves which is a Linux platform set up to boot the BEAM and nothing else (e.g. no init system, just a special pid 0 binary that boots the BEAM and lets that handle all other processes). It had some plus points like making firmware upgrade trivial and simplifying the system, but not being a "normal" linux platform was a bit irritating sometimes. You could equally well just run Elixir as an application normally.
This is dope. I work with Zynq/Versal quite a bit and respect and understand (conceptually) the decisions you have made!<p>You get to own every aspect of your toolchain and with that will come a lot of power.<p>Are you familiar with:<p><a href="https://github.com/corundum/corundum">https://github.com/corundum/corundum</a><p>Perhaps you can build a support package for your platform.
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.
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.