Amalgam board options

[lawrie]

@Folknology Several points came up from last night's discussion on the Amalgam board - the new ECP5 board with the Blackedge connector.

The main issues seem to be Wifi, USB and an RTC with battery back-up.

It is my experience with the Ulx3s ECP5 board which drives my views on this. I have implemented 30 or more significant projects on the Ulx3s board (see https://github.com/lawrie/ulx3s_bit_streams) and I would like to see those, and more, working on the Amalgam board.

I have also been involved in getting SaxonSoc Linux using all the hardware on the Ulx3s, and I would like to see it run at least as well on the Amalgam board.

I like the proposed change to use micropython or circuitpython on the host microcontroller, as that makes it much easier to program and would make it much easier to port stuff from the Ulx3s.

One concern I have is usb and uart connections.

If the main usb connection goes to the STM32 running micropython or circuitpython, will it be possible for it to pass data through to the fpga uart like the icecore software does? If not how will we get a uart connection to the fpga?

With circuitpython there are multiple usb endpoints including a serial one and a disk drive. The ideal configuration would be to add another endpoint for the uart to the fpga, so you could talk to both the microcontroller and the fpga uart from the PC host at the same time.

An alternative might be to use the second usb connector to connect to the fpga uart and leave the first one dedicated to the STM32.

But the second usb connector is also needed for usb and ps/2 connections to the fpga, where the fpga is the host. If the second usb connector was not available for this, then using full-size usb host connectors on a carrier board would be an alternative.

[lawrie]

On the issue of Wifi and Bluetooth access to the STM32, it looks as if adding this will complicate and add expense to the board.

An Amalgam board without wireless access would still be very useful, but I think wireless access makes the board much more useful.

Some of the things Wifi is used for on the Ulx3s board are:

• over the air access to micropython, mainly by use of web repl
• over the air ftp access to read and write to the microcontroller flash memory and to the sd card and even to write new images to the sd card
• Using the ESP32 for pppd networking from SaxonSoc Linux and other SoC projects
• An OSD that gets game roms directly from internet sites
• Running applications on a Linux machine to send keystrokes and mice events to virtual keyboards and mice that connect through to a SoC on the fpga
• Installing software over the air using upip

Using Wifi allows access to the board when it is not connected to the computer or when the usb connection is being used for other things. It can also be much faster than using the usb connection (particularly on the Ulx3s board).

Recently the new set of users on the Ulx3s after its successful Crowdsupply campaign having started using Bluetooth LE via the ESP32 to do things like connect heart monitors and to control games using a mobile phone. It is less used than Wifi.

[lawrie]

On the third issue, a reat time clock (RTC). with battery back-up:

It does not look as if this is very difficult to add. It is useful to maintain the time for SoCs such as SaxonSoc Linux when the board is powered off.

It can also be used to put the board to sleep and wake it up, using RTC alarms. For example on the Ulx3s board, SaxonSoc has an option to power off the board when it shuts down.

[Folknology]

Wow thanks for all the Feedback @lawrie, I'm still thinking about these things and will respond shortly to them

[Folknology]

I like the proposed change to use micropython or circuitpython on the host microcontroller, as that makes it much easier to program and would make it much easier to port stuff from the Ulx3s.

I concur

If the main usb connection goes to the STM32 running micropython or circuitpython, will it be possible for it to pass data through to the fpga uart like the icecore software does? If not how will we get a uart connection to the fpga?

This is certainly possible although I would want to overload the CP/MP USB connector, rather use another perhaps..

But the second usb connector is also needed for usb and ps/2 connections to the fpga, where the fpga is the host. If the second usb connector was not available for this, then using full-size usb host connectors on a carrier board would be an alternative.

This might even be a third connector..

On the issue of Wifi and Bluetooth access to the STM32, it looks as if adding this will complicate and add expense to the board.

An Amalgam board without wireless access would still be very useful, but I think wireless access makes the board much more useful.

I think it is worth adding, yes there is a cost however the Amalgam board will be upper cost bracket rather than lower anyhow.

On the third issue, a reat time clock (RTC). with battery back-up:

It does not look as if this is very difficult to add. It is useful to maintain the time for SoCs such as SaxonSoc Linux when the board is powered off.

It can also be used to put the board to sleep and wake it up, using RTC alarms. For example on the Ulx3s board, SaxonSoc has an option to power off the board when it shuts down.

I think we can do something here the RTC hardware is built into the STM32 so we should reuse it..

[Folknology]

Ok here is the new Amalgam layout including the changes we discussed on the myStorm Stream last night:

Main changes since last stream:

• Move from BlackEdge dual header connector to single 80 Pin dual row 1.27 pitch on base.
• 2 x Mechanical screws to secure board down on carrier on top part of Module.
• Replacement of the STM32 with ESP32-S2, providing CP and Wifi benefits (from alloy stable)
• Indication of possible board naming "Alloy Core" to reflect new design
• Addition of 8 x RGB LED array, great for indicating bit/bus values and new "Trail" patterns..
• Dual CSI Camera FPC connectors allowing stereo vision. Infrared/regular overlays or just 2 cams..
• USB connector dedicated to ECP5 FPGA, may use Luna for this, plus game control..
• QWIIK/STEM connector for I2C as these seem popular and useful
• Mipi FPC LCD interface for digital video output on hi res screens.
• RTC support including 32K crystal for the ESP32-S2
• ESP/ECP Interconnect - OctoSPI + CLK and Int/cntr
• USB 2.0FS (ESP-S2) CDC/FS (TinyUsb/CP),

Previous features inherited : Mini Digital Video connector, ESP32 has 8MB QSPI RAM and >=4MB Flash, ECP5 has QSPI 2MB Flash and DDR2 Ram (options), supplies of 1v2,1v8,2v5,3v3 regs.
Dimensions are ~52mm x 40mm

BTW Green is top layer, Blue is bottom layer, board is actually a 6 layer to break out the ECP5 balls.

Let me know your thoughts folks.

[electrified]

Looks good @Folknology. How many pins of FPGA IO are brought out on the connector?

[Folknology]

Ok so connector wise it is :
Power pins 1 & 2 = Gnd, pin 3 = +5v and pin 4 = +3v3
Then there are 12 mixed signal pins 5-16 which are either ADC or low speed digital (ESP32 pins)
The rest of the them 17 - 80 (64 pins) are all high speed digital FPGA IO and paired either A/B or C/D in case you need dif signals

Pretty simple setup really for max flexibility, that was the goal.

[Folknology]

Here is the current schematic BTW, it's still under development...

Let me know if you see any issues or changes or even just questions..

[lawrie]

One thing I am unsure about with both this and the Alloy board is how we get a uart connection from the FPGA to the host. With the Blackice Mx, there was a bridge between the usb cdc acm and the fpga uart pins, implemented in C using DMA. I am guessing that if we did that in python it would be too slow.

Another option is to use the usb connector directly connected to FPGA pins. But implementing uart to usb in gateware takes a lot of code and a lot of LUTs. (The Luna project contains an nmigen implementation of that). Another problem with using that usb connector is that it might be needed for driving usb host devices.

The Blackice II solution to this was to use an extra usb connector and a usb to uart chip.

[Folknology]

I was thinking that using Usb directly from the ECP5 might be better to avoid stealing cycles from the Micro, I am not sure what that adds up to Lut wise. As for using the USB for gaming ports it's still easy to include a couple of USB A host ports on the carrier of course. It is also possible to do the Uart/Usb thing on the ESP-32, the Uart part would be done in C and could use DMA, how one would hook that up to the existing USB when running CP (TinyUsb?) however might be tricky. I guess alternatively you could always pass the output over Wifi using telnet or something..

BTW I am trying to avoid adding parts if possible..

[lawrie]

I was thinking that using Usb directly from the ECP5 might be better to avoid stealing cycles from the Micro, I am not sure what that adds up to Lut wise.

The other issue in doing usb to uart in gateware is that it tends to need multiple clock domains, which complicates projects. The Verilog implementation on the TinyFPGA needed a 12Mhz and a 48Mhz clock domain. I am not sure what the Luna nmigen implementation needs.

The number of LUTs used is more an issue for the alloy up5k board than it is for the Ecp5 board.

This is not that big an issue, Some boards such as the TinyFPGA BX manage with just one usb connector and that connected to FPGA . The OrangeCrab is similar in having just the one usb connector, connected to FPGA pins.

[Folknology]

If you aren't using the ESP32 (maybe for retro gaming on the ECP5/ICE40) then you probably don't need to worry about cycles so much I guess it depends on the particular application..

[Folknology]

There is also nothing stopping us develop something more specific in C for the ESP32-S2 (Arduino support is nearly there BTW) for these sorts of applications? I wonder if maybe using one of the newer bootloaders both CP and Arduino might be able to be supported concurrently perhaps.

[electrified]

Just a couple of thoughts.

For me the IceCore format has been ideal - the only things I would have changed would be:
Working HDMI
Example code of how to use the SDRAM from the start (great work from @lawrie on that front)

So if the new board has working HDMI and some example DDR controller verilog, that would be a winner!

Any thoughts on which FPGA you'll pick re LUT count?

Cheers

[Folknology]

So if the new board has working HDMI and some example DDR controller verilog, that would be a winner!

I would imagine that Litex support will likely be first for the DDR Controller and yes Digital video will work this time!!

Any thoughts on which FPGA you'll pick re LUT count?

My plan is for both 12K and 45K Lut options

[lawrie]

I would imagine that Litex support will likely be first for the DDR Controller

The LiteX version may require some modification to work on the Amalgam board, so we might need to learn some migen as well as nmigen.

There is also a SpinalHDL DDR controller, and we will probably be able to get that working with SaxonSoc on the board.

There has also been some discussion with @daveshah on the Ulx3s gitter lately about DDR RAM controllers for retro computers. Dave thinks that a controller with the predictable latency required should be possible, but that might require a different design for the controller.

[daveshah]

If DDR2 is still planned, then some modification will be needed to litedram as currently the ECP5 PHY is for DDR3 only.