New Product - BlackIce Mx

[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.

[Folknology]

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?

Booting from the default (0) image/bitfile in flash from power on would make the best sense

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.

Although not determined yet and open for discussion how we operate this there is a mode button, this could toggle between modes of direct program and program flash for example. I am open to suggestions what do you think?

[lawrie]

I am open to suggestions what do you think?

I think the normal way of working should be to preload a multi-boot configuration into the flash memory and for the default programming mode to overwrite the default, cold boot, configuration in flash, and then get the ice40 to boot to it.

If you want to stick with the "cat bitfile >/dev/ttyACM0" configuration method, we could add a header with address and length to the bitfile, or better, have a series of chunks with address and length headers, so that you could write new configurations and roms and other data to the flash in one go.

I am not sure when you would want to do the direct programming rather than writing to flash, but you could have a flag in the header to say do direct programming rather than flash programming.

[Folknology]

I think the normal way of working should be to preload a multi-boot configuration into the flash memory and for the default programming mode to overwrite the default, cold boot, configuration in flash, and then get the ice40 to boot to it.

I concur.

If you want to stick with the "cat bitfile >/dev/ttyACM0" configuration method

Definitely would like to keep this

we could add a header with address and length to the bitfile, or better, have a series of chunks with address and length headers, so that you could write new configurations and roms and other data to the flash in one go.

I'm rusty on the Lattice bitfile contents and meta data, much of what you are suggesting may already designed in, we would just have to check for it (semi parse the meta data)?

I am not sure when you would want to do the direct programming rather than writing to flash, but you could have a flag in the header to say do direct programming rather than flash programming.

It maybe possible to automagically do this is the meta data is parsed..

[lawrie]

I'm rusty on the Lattice bitfile contents and meta data, much of what you are suggesting may already designed in, we would just have to check for it (semi parse the meta data)?

There is some information in this thread on experiments I did with multi-boot configurations on the TinyFPGA BX. Luke Valenty added an extra layer of his own metadata to the flash memory for that board, using security sectors in the flash memory.

I think you need the address and length headers to support writing roms and other data to the flash memory, but bitfiles and multi-boot configurations are self identifying in the first few bytes so you could make such headers optional. Bitfiles seem to start 0xF00F7E99AAFE and multi-boot configurations (produced by icemulti) start 0x7E99AAFE. A multi-boot configuration would normally be written to address 0, and a bitfile to address 0xE0 (the coldboot image of a multi-boot configuration).

[lawrie]

I think a couple of use cases we should support are:

1. Writing a bitfile and associated data (usually ROMs) to the flash memory in one go as done by Ice40Atom and Ice40Beeb, currently using dfu-util.

2. Writing a multi-boot configuration and associated data in one go for a boot menu and multiple programs, e.g. a reto-computer boot menu that lets you choose if you want to run an Acorn Atom or a BBC Micro or another retro computer. These would all have separate bitstreams and separate ROMs.

These would need multiple chunks and headers with address and length to say where to write each piece of data.

[Folknology]

I have been playing with the new BlackIceMx lego...

[Folknology]

Writing a multi-boot configuration and associated data in one go for a boot menu and multiple programs, e.g. a reto-computer boot menu that lets you choose if you want to run an Acorn Atom or a BBC Micro or another retro computer. These would all have separate bitstreams and separate ROMs.

This is an interesting idea, I was just thinking how this could be implemented, Lattice quotes :

If Cold Boot is enabled, the FPGA reads the logic values on pins CBSEL[1:0]. The FPGA uses the value as a vector and then reads from the indicated vector address.

Given that I can control CBSEL[1:0] from the STM32 it could offer a menu to select which vector. However I could only change CBSEL1 in practice as this is connected to wp on the flash, the other is connected to the hold pin which would mess with loading from the flash if enabled..

It might be possible to overcome this by monitoring the Ice40 SS pin and releasing hold when it changes or after a fixed time from Ice40 reset perhaps.

Actually we could only fit 3 full images in the 4Mbit flash, also one is likely to require some runtime flash in addition to Ice40 bit images so maybe limiting it to fewer choices makes more sense, 2 choices is perhaps best..

[lawrie]

I used the multiboot capability for something similar on the TinyFPGA BX. That board uses a multiboot configuration with 2 bit images by default. It colds boots to the USB bootloader at address 0xe0, and writes the user image to 0x28000, which the usb bootloader uses SB_WARMBOOT to boot to.

I modified the configuration to have 4 images - see https://github.com/lawrie/TinyFPGA-Bootloader/blob/master/boards/TinyFPGA_BX/Makefile

I then implemented a multi-boot menu for the FPGC games console that used the image at 0x28000 as the menu, leaving the USB bootloader at 0xe0. The games menu reads the ice40 bitfile and the picorv32 program from an SD card and writes them both to the flash memory. The bitfile is written to 0x78000 which is the 4th multiboot configuration and it uses SB_WARMBOOT to boot to it - see https://discourse.tinyfpga.com/t/bx-portable-game-console-project-collaboration/553/154

So that uses 3 bit images, but as the Blackice Mx does not use a USB bootloader, it could do this with two images. The TinyFPGA BX has 8Mbit of flash, so it supports 4 images in flash, plus a lot more space for programs or other data.

[lawrie]

I have been playing with the new BlackIceMx lego...

Test point adapters similar to the Digilent ones would be useful for those mixed signal connectors so that you could look at the digital or analog signals with an oscilloscope or logic analyser while a Pmod is connected.

[Folknology]

BlackIceMx is getting ready for manufacture this week, I started the file uploads, feel free to take a peek..

[lawrie]

Ah, I hadn't realised that the COMS/DBG header was essentially the same as the Raspberry Pi header on the Blackice II.