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

Memory Mapping an FPGA from an STM32

serd.es

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Memory Mapping an FPGA from an STM32

#31

Post by 15155 »

azonenberg wrote: post #28
azonenberg wrote: post #23

Earlier quoted context omitted.

As far as using QSPI memory, one thing I have planned (and will be thoroughly testing) is using an external SPI flash as configuration data storage. Right now if I want to store any nonvolatile settings with power loss protection I need to burn two 128 kB erase blocks (one primary and one secondary, so I can ping-pong data between them and not lose anything if I have a power loss during a write cycle or similar) of t…

But if I can memory map the FPGA via the FMC, I can simply put an APB memory mapped QSPI controller on the FPGA and store my config there, using the same flash for the FPGA bitstream as well. This saves a chip on the board, reduces the amount of PCB routing required, and eliminates use of the sketchy OCTOSPI peripheral entirely. Testing that out is on my list of things to do on this board eventually.

I almost always include I2C EEPROM - just too cheap and pretty easy to route.

Re: Memory Mapping an FPGA from an STM32

#32

Post by azonenberg »

15155 wrote: post #27
UncleOxidant wrote: post #3

Earlier quoted context omitted.

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 micorcontr…

Zynq 7010s are $2.50 and are a hell of a lot more chip than an RP2040. If you already have the design (or copy one of the 50 available), it's a good option when you don't want to fight the chip. PIO has extraordinarily sloppy timing (skew in all categories) compared to the cheapest and smallest FPGAs.

Where are you getting them for $2.50?? The XC7Z010-1CLG225C is $74.83 at Digikey in qty 1.

Checking sketchier places Win-Source has the CLG400 package for $22.20 and even the cheapest aliexpress seller wants $4.84 for something marked as a 7Z010 that may or may not be legit.

Also "fight the chip" is pretty much the definition of what I did last time I did a zynq project. Just give me a plain FPGA and MCU with no wizards or GUIs or automatic code generation.

Re: Memory Mapping an FPGA from an STM32

#33

Post by 15155 »

azonenberg wrote: post #32
15155 wrote: post #27

Earlier quoted context omitted.

Zynq 7010s are $2.50 and are a hell of a lot more chip than an RP2040. If you already have the design (or copy one of the 50 available), it's a good option when you don't want to fight the chip. PIO has extraordinarily sloppy timing (skew in all categories) compared to the cheapest and smallest FPGAs.

Where are you getting them for $2.50?? The XC7Z010-1CLG225C is $74.83 at Digikey in qty 1. Checking sketchier places Win-Source has the CLG400 package for $22.20 and even the cheapest aliexpress seller wants $4.84 for something marked as a 7Z010 that may or may not be legit. Also "fight the chip" is pretty much the definition of what I did last time I did a zynq project. Just give me a plain FPGA and MCU with no wiza…

https://www.aliexpress.us/item/3256803970893483.html

I've ordered trays (and they send the OEM tray) - unique barcodes, legit.

> Just give me a plain FPGA and MCU with no wizards or GUIs or automatic code generation.

You can pretty much cut out all of their tools and get a pure Yocto/Vivado TCL build for the bitstream for the 7 series Zynqs. Very low touch.

Their IO planner (in the Vivado IP integrator) is somewhat necessary for complex peripheral scenarios and is one of the few things I ever use Xilinx GUI applications for anymore.

Re: Memory Mapping an FPGA from an STM32

#34

Post by dmitrygr »

mips_r4300i wrote: post #22
dmitrygr wrote: post #19

Be veeeery careful. STM32H QSPI peripheral is FULL OF 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,…

Thanks for the heads up. I have a design at fab that uses the H7's OctoSPI so this concerns me. I steered away from the memory mapped mode because it seemed too good to be true - wanted to be able to qsort() and put heaps in this extra space. I suspect ST only ever tested it with their single PSRAM they intend this mode for. My intent is to use indirect mode and manually poke the peripheral, though DMA will have to h…

it is worse: i think they also did not test random access. I suspect their test was to: fill PSRAM linearly and then read it back and verify linearly. Random word accesses in unachached mode also randomly lose writes. I am unable to replicate quickly on purpose, only randomly, so i guess it is under 1/100mil so it is not in my list above. My workarounds avoid these crashes too though.

Re: Memory Mapping an FPGA from an STM32

#35

Post by hmry »

mystified5016 wrote: post #25
dmitrygr wrote: post #19

Be veeeery careful. STM32H QSPI peripheral is FULL OF 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,…

What the hell is going on at ST? Every STM uC I've tried to use in the past few years has had showstopper bugs with loads of very similar complaints online dating back to the release of the part. Bugs that have been in the wild for years and still exist in the current production run. After burning enough company time chasing bugs through ST's crappy silicon, I've had to just swear them off entirely. We're an Atmel ho…

In college, our SoC design instructor told us that to pass the class, our modules should be better than ST's "which is not that high of a bar" :P

Re: Memory Mapping an FPGA from an STM32

#36

Post by azonenberg »

15155 wrote: post #31
azonenberg wrote: post #28

Earlier quoted context omitted.

But if I can memory map the FPGA via the FMC, I can simply put an APB memory mapped QSPI controller on the FPGA and store my config there, using the same flash for the FPGA bitstream as well. This saves a chip on the board, reduces the amount of PCB routing required, and eliminates use of the sketchy OCTOSPI peripheral entirely. Testing that out is on my list of things to do on this board eventually.

I almost always include I2C EEPROM - just too cheap and pretty easy to route.

That can't be memory mapped, so I'd need to rewrite my KVS code which currently expects to be able to return a pointer to the raw on-flash image of the config data. Doable but a pain.

Re: Memory Mapping an FPGA from an STM32

#37

Post by dmitrygr »

azonenberg wrote: post #20
dmitrygr wrote: post #19

Be veeeery careful. STM32H QSPI peripheral is FULL OF 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,…

I have encountered issues with QSPI (mostly caused by the annoying prefetch queue) which is why I am switching to the FMC for FPGA interfacing (i.e. not using OCTOSPI). That was the whole point of this experiment, validating FMC as a replacement for my legacy OCTOSPI based MCU-APB bridge. I have a previous board using QSPI reliably in indirect mode (i.e. not memory mapped) but found it was full of pain when memory ma…

> 100K reads/writes of a 32-bit register

You'll hit almost no bugs if you keep accessing the same address in a loop. Lucky you :)

Re: Memory Mapping an FPGA from an STM32

#38

Post by rvense »

buescher wrote: post #13
rvense wrote: post #10

Earlier quoted context omitted.

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.

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.

Cortex-Ms, man. A lot of 'em you just give 3.3V and a couple of bypass caps, and GCC will use the single-cycle hardware MAC (for M4 and above) if you just write the straight-forward C code and you can put it on there in 600ms with DFU. I'm a hobbyist, not an embedded wizard, but it really seems *pretty* good compared to what I understand about the old days.

(Like I like retro stuff and during COVID I bought an old DSP56k dev board with a book about the assembly language but oh boy, oh dear)

Re: Memory Mapping an FPGA from an STM32

#39

Post by mips_r4300i »

mystified5016 wrote: post #25
dmitrygr wrote: post #19

Be veeeery careful. STM32H QSPI peripheral is FULL OF 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,…

What the hell is going on at ST? Every STM uC I've tried to use in the past few years has had showstopper bugs with loads of very similar complaints online dating back to the release of the part. Bugs that have been in the wild for years and still exist in the current production run. After burning enough company time chasing bugs through ST's crappy silicon, I've had to just swear them off entirely. We're an Atmel ho…

They churn out new parts and don't bring in fixes. See all the chips in their lineup that have a USB host controller. Every one of them (they use Synopsys IP) will fail with multiple LS devices through a hub. We talked to our FAE about this and they have no plans to fix it. The bug has existed for years and the bad IP is being baked into all the new chips still. Solution? Just use yet another chip for its host controller, and don't use a hub.

Re: Memory Mapping an FPGA from an STM32

#40

Post by duskwuff »

azonenberg wrote: post #21
duskwuff wrote: post #18

Earlier quoted context omitted.

Probably not. The dual-core parts are DIE450 (which is shared with some single-core parts like the H750 series!), but STM32H735 is DIE483.

I have a H735 on a retired board slated for decap so we'll find out once I open it up. Do you know if it's fabbed in house, TSMC, or Samsung? I've seen ST silicon from all 3 foundries but the only thing I've seen stated publicly is 40nm. When I get it opened up it should be easy to tell, TSMC and Samsung processes have distinctive features on them that I recognize by sight.

No idea - I'm reading the die IDs out of the STM32Cube DB. I haven't looked at the silicon, but I have no reason to doubt what the DB says, especially since it confirms that a lot of allegedly different parts use the same dies.
Post reply on HN