Closed bvernoux closed 5 years ago
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:
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:
About USB:
About STM32CubeMX project:
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)
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)
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:
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
Remarks related to STM32F777NIH6: