IntegralStick preliminary review / remarks related to STM32F777NIH6

Remarks related to STM32F777NIH6‎:

Replace the MCU by an STM32H750 Value Line they are clearly cheaper/faster/better especially for such amazing project
- I think a good candidate will be stm32h750xb the drawback is you need to change the routing/package (STM32F777NIH6‎/TFBGA216 13X13X0.8 vs STM32H750XB/TFBGA240+25L 14X14X1.2 P 0.8)
Add USB FS at least in order to flash it easily with DFU
Add SWD/JTAG pins for debug
Create an STM32CubeMX project to better understand/check the design/function especially between STM32/FPGA

MCU replacement: Not happening in the first PCB iteration, I specifically wanted very large flash for several of my projects. I can't rule out making "A/B" variants where the FPGA side is kept the same and the MCU is redone (probably possible to keep some compatibility with host modules) in the future if there's sufficient interest.

USB: PB13 (OTG_HS_VBUS) is used by the RMII interface to the FPGA so USB HS isn't available without major rerouting. The external pin connector does have:

PA8 (OTG_FS_SOF)
PA10 (OTG_FS_ID)
PA11 (PTG_FS_DP)
PA12 (OTG_FS_DM)
PA9 (OTG_FS_VBUS)

I believe this is everything required for USB FS. The DP/DM pairs are not routed differentially, but USB FS is so slow we can probably get away without doing that?

For my own projects I was planning to do initial manufacturing firmware load via JTAG, then field update over Ethernet. The FPGA would run a TFTP client or server and pull a combined update file over gig-e, write the first part to the FPGA boot flash then push the second part to the MCU at 100M. The MCU would then write that portion of the update image to internal flash.

SWD is intentionally not supported since the FPGA only supports JTAG and I didn't want to waste too many pins on programming interfaces. The FPGA and STM32 are on a single 3.3V JTAG chain (J2 pins 64/66/70/72) which allows both to be debugged/programmed using a single JTAG adapter.

I was planning to just use ARM gcc to build binaries for the STM32 (without using any of the ST blob tools) and flash using libjtaghal - I have no knowledge of, or plans to use, the ST vendor tools. If somebody else (you just volunteered!) wants to use the vendor tools to sanity check the design and/or develop firmware for it, I have no problem with that.

Thanks for the details and your comments

About MCU replacement:

stm32h750XB has less internal flash (128KB) than STM32F777NIH6‎(2MB) but it can use external flash with Dual mode Quad-SPI memory interface running up to 133 MHz and it support code execution from that ext flash which is really better and it has huge internal RAM (1MB vs 512KB STM32F777NIH6‎) which can be used to load code from external flash to SRAM for critical code which shall run at maximum speed.
- I do not speak about peripherals/memory architecture as the STM32H7 have big/major improvements on lot of things versus STM32F7.

About USB:

The idea was just to use USB1 USB LS/FS not HS (as anyway it is not supported natively by any STM32 MCU and requires ULPI for HS) and so it requires only FS_DP/FS_DM and VBUS pins the other are not mandatory, advantage is to use it for flash and to have a "VT100 Terminal" for dev/debug/test purposes see hydrabus/hydrafw for more details, of course such feature is mainly interesting for developers.

About STM32CubeMX project:

It was not intended to be used to generate code/ST lib but mainly to check pin/features used (it is mainly to be used as "visual" documentation/design to be sure of choices & constraints mainly for peripherals ...) and I'm totally agree that a bare metal GCC ARM project is better than using all ST lib which are quite big especially when it is not required...

What will be amazing is to have details of what is planned especially between MCU/FPGA and how they are intended to be used in this design (even if I think this board is only dedicated to FPGA Oscilloscope and can be used for anything in theory):

Does the MCU do minor things or some critical things ? (for me it should be the master and send/receive orders to the FPGA for hard real-time things)
- The FPGA will do low level hard real-time things like 10Gb Oscilloscope ...
Does the FPGA is intended to be used as an independent processor (with a soft core... which I think could be a waste of precious resource for the FPGA and will complexify the software as it will requires a firmware for the FPGA soft core & a firmware for STM32 in addition to Verilog/VHDL for FPGA hard real-time low level stuff)
- I see you mention that you plan FPGA would run a TFTP client or server ... It seems such use case will requires a soft core inside FPGA when such task could be probably better to be done from MCU side except if you wan to lower latencies to maximum especially with 1Gb Ethernet...
- In that case I do not really understand what is the aim of the MCU ?

Maybe it is good to update your https://github.com/azonenberg/integralstick/wiki/Design-Notes (or to create a new Wiki related to SW/HW Architecture/Design) towards those remarks and close this issue as it is not really an issue but more questions ...

Like I said, I may do a second board variant down the road but for the moment I'm keeping the F777 to avoid redoing layout (among other reasons).

Sounds like USB is OK the way it is probably? The signals are routed close together, just not differentially coupled but that should be OK at 12 Mbps.

I've never used the STM32CubeMX tool. If you want to sanity check capabilities with it, please reply in the thread with your comments and any issues found :)

INTEGRALSTICK was not originally designed for FREESAMPLE, actually. The initial use case was for LATENTRED, with the MCU running the management CLI and the FPGA used for I/O expansion on the main switch FPGA (basically no communication between MCU and small FPGA). I decided that the combination seemed useful and refactored the block diagram to put it into a separate board that I could reuse elsewhere. Currently planned projects:

FREESAMPLE (the MCU may well go entirely unused, FPGA will run the hard realtime stuff then stream sample data over Ethernet to host PC)
LATENTRED (FPGA for I/O expansion, MCU for management CLI)
CREAKYLADDER (exact task breakdown between chips TBD)

The board doesn't specify a HW/SW architecture, it's meant to be a generic MCU+FPGA module that you can drop down in a project and do whatever you want. In general my designs have the opposite architecture you propose, the FPGA is the master and I push complex non-realtime state machines to the MCU as a "state machine coprocessor". I have no intention of running a softcore CPU on the FPGA.

Regarding Ethernet, the 1G PHY is connected to the FPGA and there is a 100M RMII link from FPGA to MCU. The FPGA will contain a 3-port Ethernet switch internally, bridging some traffic to the MCU and dropping or internally processing the rest, depending on the use case. If you don't need to do any processing on the FPGA, you can just run a simple converter from RGMII to RMII instead of a full switch.

I have a SystemVerilog IP stack that includes UDP (https://github.com/azonenberg/antikernel-ipcores/blob/master/protocol/udp/UDPProtocol.sv?ts=4#L35) and (WIP) TCP support, with no CPU - just pure RTL state machines. It's intended to do 10+ Gbps on a Kintex-7 and will have no problem doing 1G on an Artix. TFTP is a super tiny protocol so I'd just do that in RTL on top.

The Ethernet is intended to be the primary communication path between the MCU and FPGA. Additional communication paths are a UART (tentative plan is to hook that up to the TCP offload engine on the FPGA and provide a telnet console during debug, but it could also be out-of-band control, bootloader, etc), SPI, and the digital camera interface. I have no plans for the DCMI but it's the highest-bandwidth interface available for pushing data into the MCU so I figured I'd wire it up. If the DCMI ends up not being used, you can use those pins as uncommitted GPIOs between MCU and FPGA instead.

Thanks for your comments and details your antikernel-ipcores is very impressive especially the case it is not a soft core congratulations I confirm the routing of PA11/PA12 are ok especially it is only FS (and in addition it is not far to be impedance/length matched so clearly perfect for USB 2.0 LS/FS)

I do not have any other comment, I'm impatient to see the result and final price for that beast

azonenberg / integralstick

IntegralStick preliminary review / remarks related to STM32F777NIH6 #1