New Product - BlackIce Mx

[Folknology]

BlackIce Mx - composite

It is time to reveal more about the first product to emerge from the BlackEdge project, it is called BlackIce Mx and it inherits it's name from the existing myStorm BlackIce board, the 'Mx' part refers to it's use of Mixed signal Modules (MixMods) support which supercedes the original BlackIce Pmod support. MixMods have backward compatibility with Pmods but introduce new analogue input support. BlackIce Mx composition is based around a carrier and Core module, the carrier in this case is MixMod based and the initial bundled core is the new IceCore (The fastest Ice40 - HX). Both parts of the composite use a standard 100 pin interconnect allowing them to be interchanged with other carriers/cores present and future, this protects investment, adds value and increases flexibility.

Lets take a look at the features of BlackIce Mx (IceCore version):

IceCore specific
* Ice40 HX4K - 4K Luts (8K for Yosy), 80/(128)Kbits BRAM, 2 PLLs, NVCM
* 16Mbit SDRAM 16 bits wide (143Mhz)
* 16Mbit Flash QSPI/SPI (100Mhz)
* 56 General purpose IOs, SPI, Uart, I2C/Can
* Stm32F730 200Mhz, 256KB Ram, 64KB Flash
* Triple 2.5MSPS ADCs (interleaved to 7.2MSPS)
* Dedicated Programming and debug USB 2.0FS
* Uart/Application specific USB2.0FS
* Digital video connector
* SDCard connector
* 4 Statusr LEDs
* 4 User LEDs
* 2 User buttons

Carrier specific
* 3 MixMods (including 6 double Pmods) each supporting 16 GPIO and 5 Analogue inputs.
* RPI header similar to BI II - I2C, Uart, SPI, JTAG and SWIO debugging connector

In comparison to the existing BlackIce II boards here are the main improvements:
* Modular - Different Carriers and easier to integrate into your own projects
* Flash on board 16Mbits for FPGA bit config and/or application storage
* 16Mbit SDRAM replaces 4Mbit SRAM allowing greater OS and framebuffers support etc..
* Built in digital video display connector eliminating need for external video module
* Mixed signal Module support rather than just digital Pmods allow analogue and digital expansion

This thread is for the discussion and progress of BlackIce Mx, please feel free to ask any questions around this, I expect to ship these in early May, any orders for BlackIce II on Tindie will be automatically upgraded at no extra cost with BlackIce Mx as there are no literally no BI II left! If you want in early BlackIce Mx action at BI II pricing add yourself to the waitlist on BII product page on Tindie you will be the first to receive the new kits...

[lawrie]

I have signed up for an early board on Tindie.

I am wondering what can be done on this board that couldn't be done on the BlackIce II.

The implementation of the BBC Micro, Acorn Atom etc. will need to be redone to use the SDRAM and the HDMI connector.

My MuraxArduino system would probably be best converted to use the Murax XIP (eXecute In Place) feature, so that it uses the Flash memory for program execution rather than the SRAM, which the BlackIce version uses.

I would have thought the Commodore Amiga port that runs on the ULX3S board, should work on this, using the HDMI output. And is should be easier to convert other retro computers, game console and arcade implementations that use SDRAM, e.g. those from the Mister project that are written in Verilog.

It does not have enough memory for Linux, but other operating systems such as the Zephyr OS which SaxonSoC uses, should work well on it. Also the Vexriscv Briey SoC should run with very little change as it already uses SDRAM and has VGA output.

[piers]

Interesting choice of mcu, I'm working with it's big brother (733) in my day job - the larger / bga version of the 730 (and 723 / 733) have a built-in USB high-speed phy. Not really in the spirit of the blackice to add that large a mcu though!

Can a ULPI phy be added to the 64 pin version or are some / all of the pins used for other purposes? If they were routed to a mixmod that would be cool ... Or even just routed to the 100pin headers so a future baseboard could add support.

I thought that one of the USB controllers on the 730 was a high-speed core, but this can only be set up as a full-speed controller if the phy is limited to that speed.

Are you using ST's CubeMx to auto-generate code, or crafting something using their low level / HAL drivers?

For the version I'm working on we used CubeMx, but have had to tweak a few of the HAL and ll drivers (in part as I'm adding limited support for compressed video input via high-speed USB, but also to fix a couple of bugs). The generated code we're using uses FreeRTOS. Zephyr looks interesting, but may take a bit more effort to get working.

I'd be interested to know more about what you're planning on the mcu software side.

I hope I'll be able to order one of the first batch on tindie - do you know when you're likely to hit the go button (e.g. How long do I have to convince my wife it's a good opportunity to learn more than I can from my early blackice)?

[Folknology]

Thanks for the comments @piers here are my responses

Interesting choice of mcu, I'm working with it's big brother (733) in my day job - the larger / bga version of the 730 (and 723 / 733) have a built-in USB high-speed phy. Not really in the spirit of the blackice to add that large a mcu though!

Yeah I have designs using the 730 BGA version module that uses the higher speed PHY I have been toying with for 2020..

Can a ULPI phy be added to the 64 pin version or are some / all of the pins used for other purposes? If they were routed to a mixmod that would be cool ... Or even just routed to the 100pin headers so a future baseboard could add support.

Unfortunately those pins are needed for other things..

Are you using ST's CubeMx to auto-generate code, or crafting something using their low level / HAL drivers?

Yes

For the version I'm working on we used CubeMx, but have had to tweak a few of the HAL and ll drivers (in part as I'm adding limited support for compressed video input via high-speed USB, but also to fix a couple of bugs). The generated code we're using uses FreeRTOS. Zephyr looks interesting, but may take a bit more effort to get working.

I would be very interested in what you are doing with this do you have a link to the code, is it opensource? Is the code connected with OpenMV's work?

I hope I'll be able to order one of the first batch on tindie - do you know when you're likely to hit the go button..

If you add yourself to the wait list (see announcement above) you will get one shipped from the first batch, scheduled ship is beginning of May.

[piers]

Thanks @Folknology,
Sadly the USB work I've been doing isn't open source. I hope I can do something worthwhile to help, but am very limited for free time.
I've not seen OpenMV before - it looks interesting. I think they are using the dedicated digital video interface (8-14 bit parallel bus) on the STM32F765 for video input, which is 'simpler' than using USB for video input.
I'll aim to get my name on the waiting list before the end of April - I want to make sure I can complete the purchase before committing ... and make good use of the BlackIce Mx too.

[Folknology]

I've not seen OpenMV before - it looks interesting. I think they are using the dedicated digital video interface (8-14 bit parallel bus) on the STM32F765 for video input, which is 'simpler' than using USB for video input.I'll aim to get my name on the waiting list before the end of April - I want to make sure I can complete the purchase before committing ... and make good use of the BlackIce Mx too.

Ok slight misunderstanding I wasn't thinking of using the USB as video into the STM32 (host) rather making the user usb a video usb device which is also a lot simpler and what happens on the OpenMV..

[piers]

I've added my name to the waiting list too - I look forward to having some fun with this new evolution of the BlackIce project

[Folknology]

Assembling and testing the BlackIceMx Prototypes this week, here is the carrrier:

[Folknology]

And here it is loaded..

[aquaratixc]

Cool ! Are there any printed circuit boards (schematics) of both peripheral modules or can they be purchased somewhere?

[Folknology]

The Dual Double Pmod (DDPMOD) Numerical peripheral on the right is currently being redesigned to use Mixmod signals (ADCs) in addition to the digital PMOD signals. The Retro DDPMOD on the left will, however, remain the same, I already have components but need to order PCBs and connectors. I will also make the designs available and opensource, I just need to finish them off, they have been in the works for ages. The small boards on the top are PMOD breadboard adaptors which I am currently out of stock of, I need to order more of these and maybe design a Mixmod version in addition.

Once I get the new BlackIceMx shipping I will focus on getting making these peripherals (and more) available..

[Folknology]

The Core for BlackIce 'IceCore' Prototyped and ready for trouble shooting this weekend..

From the top:

[Folknology]

Ok it's that time - 1st mod wire...

[Folknology]

OK couple of Supply issues fixed:

1) 5V input getting shorted to ground probably via USB connector case contacting VUSB via underneath, DOH! That will teach me not to tent my vias on prototypes (I like to keep them exposed for test points and mod wires, Oh the irony..)

2) VCC switchmode outputting 0.75V instead of 1v2 as required, turns out to be bad solder joint on one of the the feedback resistors..

It now powers up and I can see it on USB as a DFU device (Using BOOT mode button) Yay!

[Folknology]

Just posted a quick Vid of BlackIceMX/IceCore running the new mystorm 0.5 programmed vis the STM32F7 over USB :

Al (folknology)

[lawrie]

Is that running the same iceboot as Blackice II?

[Folknology]

It's a newer version of it, currently a roughly hacked version to enable me to program the Ice40 fot testing etc..

Longer term myStorm will be different due to several factors :
1) Having the QSPI Flash connected to the same pins complicates things somewhat.
2) New programming modes will later need to include programming the Flash
3) Possible use of Flash for extra storage or multiple bitfiles
4) Spi slave functions of STM32 for settings and debugging purposes
5) Inclusion of ADC functions over a separate Dual Spi between STM32 and Ice40
6) Translation possibilities from Ice40 to I2C and CEC for HDMI

a bunch of other stuff I haven't even thought about yet that I am sure you guys will think up..

[lawrie]

Longer term myStorm will be different due to several factors

Are you now calling the iceboot software, mystorm?

Having the QSPI Flash connected to the same pins complicates things somewhat

Does that mean that you can configure the ice40 either from the STM32 (with the ice40 in SPI slave mode) or from the QSPI flash (with the ice40 acting as the SPI master) and that SB_WARMBOOT will be available?

New programming modes will later need to include programming the Flash

So will it be possible to have the FPGA configuration to boot from either in the STM32 flash memory (as with Blackice II) or in the QSPI flash memory?

Possible use of Flash for extra storage or multiple bitfiles

On the TinyFPGA BX, I have mainly used the QSPI flash, either to hold multiple FPGA configurations that can be started with SB_WARMBOOT or Risc-V or other programs. So I presume it should be possible to write to the QSPI flash either from the STM32 or from the ice40. For retro computer programs like Ice40Atom and Ice40Beeb, it would simplify things if ROMs could be written straight to the QSPI flash, rather than having to be sent across an SPI link from the STM32 flash, which is what happens on Blackice. With MuraxArduino I would want the bootloader to write the Arduino program to the QSPI flash and to execute it from there.

Spi slave functions of STM32 for settings and debugging purposes

So, I think you are saying that iceboot (or mystorm) on the STM32 will run an SPI slave that the ice40 can send data to for settings and debugging. Is that right?

Inclusion of ADC functions over a separate Dual Spi between STM32 and Ice40

So this will use Dual SPI rather than QSPI?

Translation possibilities from Ice40 to I2C and CEC for HDMI

Sound interesting. So the HDMI connector is connected to the ice40 and has i2c DDC and single wire CEC. Are you saying there could be a way to run a slave on the ice40 so you could send commands from the STM32 to the device that the HDMI is connected to to via CEC or DDC?

[Folknology]

This IceCore module diagram might help here :

And to answer your questions:

Are you now calling the iceboot software, mystorm?

iceboot is just a c file really, the firmware reports back as 'mystorm verxx' I am using the name mystorm for now however I am open to a long term name..

Does that mean that you can configure the ice40 either from the STM32 (with the ice40 in SPI slave mode) or from the QSPI flash (with the ice40 acting as the SPI master) and that SB_WARMBOOT will be available?

Yes prog from STM32 directly like BlackIce II (actually bitbanged) or have the Ice40 load it's image file from the SPI flash directly.

So will it be possible to have the FPGA configuration to boot from either in the STM32 flash memory (as with Blackice II) or in the QSPI flash memory?

We will not store the bitfile in the STM32 flash moving forward, not much point in that, especially with the SPI flash attached.

So I presume it should be possible to write to the QSPI flash either from the STM32 or from the ice40

Yes

For retro computer programs like Ice40Atom and Ice40Beeb, it would simplify things if ROMs could be written straight to the QSPI flash, rather than having to be sent across an SPI link from the STM32 flash, which is what happens on Blackice. With MuraxArduino I would want the bootloader to write the Arduino program to the QSPI flash and to execute it from there.

I think you are asking if a synthesised core can write to the flash directly itself, if so the answer is yes..

So, I think you are saying that iceboot (or mystorm) on the STM32 will run an SPI slave that the ice40 can send data to for settings and debugging. Is that right?

Yes after programming the Ice40 it can switch into slave spi mode controlled by synthesis (SPI Master) running on the Ice40.

So this will use Dual SPI rather than QSPI?

Yes I could not use QSPI due to feature limitations on the STM32F730 64 pin device, but the DSPI is capable of 200Mbit/sec more than adequate for the triple 2.4MSample per sec (or 7.2Msample/sec interleaved) ADC

Sound interesting. So the HDMI connector is connected to the ice40 and has i2c DDC and single wire CEC. Are you saying there could be a way to run a slave on the ice40 so you could send commands from the STM32 to the device that the HDMI is connected to to via CEC or DDC?

The HDMI TMDS comes direct from the Ice40 (limited resolution obviously) but the HPD,CEC and I2C have to be 5 volt tolerant hence I connect them to the STM32 which supports this. We can then write a translate module in the mystorm firmware to convert data between Ice40 SPI and these protocols.

[lawrie]

Thanks for the diagram (which is changing before my eyes) and all the answers.

Yes prog from STM32 directly like BlackIce II (actually bitbanged) or have the Ice40 load it's image file from the SPI flash directly.

What will control which of these methods is used? If I have a multi-boot configuration in the flash memory will it boot straight into that on power on?

I am interested in what the user interface for writing from the host to the flash memory is. Presumably there will be ways to write a bitfile which is a single or multi-boot configuration, and other data such as roms to different addresses in the flash memory. Writing a concatenation of a bitfile and other data from one host file is also useful.