Board/Rev0/pico-ice.kicad_sch - 2022/06/20

[josuah]

https://github.com/tinyvision-ai-inc/pico-ice/blob/main/Board/Rev0/Output%20Files/pico-ice.pdf

[josuah]

RP2040 without QSPI for ICE40 flash:
Just a remark to state out that there is no QSPI interface between the RP2040 and the ICE40 flash.
This makes sense as there is no general purpose QSPI peripheral on the RP2040, and there were remarks that SPI was considered enough for programming the flash.

[josuah]

What I personally like about QSPI is it is half duplex. Request-response protocols, like most bus interfaces or flash I/O, are half-duplex anyway. This means for only 2 extra pins added, QSPI offers a ×4 throughput instead of a ×2.

If some day we would like to switch a faster protocol for programming the flash, it is much easier to anticipate it now, than after the production has started.

[vr2045]

So the request is to add the full qSPI to the ICE flash to the RPi as well so it can be used to program/read the ICE flash faster. I think this makes sense. Given that we wont be running this interface very fast anyway, this should work out.

[josuah]

I have no idea of how fast things would go.
Time for a test!

[josuah]

It looks like it is the W25Q32JVSSIM on the datasheet, so: https://www.winbond.com/resource-files/w25q32jv_dtr%20revh%20010172019%20plus.pdf

[josuah]

They have a 133MHz clock:

66MB/s in QSPI.
33MB/s in Dual SPI.
16.5MB/s in SPI.

Maybe a bit less if the RP2040 cannot hold-up to 133MHz...

It is currently (Rev0.2) still possible to switch to dual SPI (×2 speed) without changing the pinout at all.

[josuah]

RGB LED direction:
is it common to have the LEDs (D2, D4) oriented in that direction? It would mean having to set a pin down to turn the led on.

At least on the raspberry pico board, it is the opposite for the on-board LED.

[vr2045]

I'm trying to minimize the number of different parts on the board.
The RGB LED can be driven only with a common connection by the ICE40 the way its drawn as its a current sink only and not a current source.
As a result, the PICO will have to adjust :(

[josuah]

Thank you for explaining. I prefer how you did it.

[josuah]

Pico-FPGA BUS pins - RP2040:
Here are the pins chosen of the RP2040 to discuss with the ICE40, and what they can be used for:
https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf#page=237

port	f1	f2	f3	f4	f5	f6	f7	f9
GPIO1	SPI0 CSn	UART0 RX	I2C0 SCL	PWM0 B	SIO	PIO0	PIO1	USB VBUS DET
GPIO2	SPI0 SCK	UART0 CTS	I2C1 SDA	PWM1 A	SIO	PIO0	PIO1	USB VBUS EN
GPIO3	SPI0 TX	UART0 RTS	I2C1 SCL	PWM1 B	SIO	PIO0	PIO1	USB OVCUR DET
GPIO4	SPI0 RX	UART1 TX	I2C0 SDA	PWM2 A	SIO	PIO0	PIO1	USB VBUS DET
GPIO5	SPI0 CSn	UART1 RX	I2C0 SCL	PWM2 B	SIO	PIO0	PIO1	USB VBUS EN
GPIO6	SPI0 SCK	UART1 CTS	I2C1 SDA	PWM3 A	SIO	PIO0	PIO1	USB OVCUR DET
GPIO7	SPI0 TX	UART1 RTS	I2C1 SCL	PWM3 B	SIO	PIO0	PIO1	USB VBUS DET
GPIO8	SPI1 RX	UART1 TX	I2C0 SDA	PWM4 A	SIO	PIO0	PIO1	USB VBUS EN

[josuah]

Note that there is a single pin of SPI1, and all other for SPI0.

This is because the GPIO0 is used for the clock, and shifts everything by 1 row.

What about starting at GPIO4, to have either SPI0 and SPI1 to choose from?

The FPGA Programming Interface is using GPIO16 through GPIO21, which is SPI0.

[vr2045]

Done, have allocated GPIO0-3 to ICE programming, GPIO4-11 to the RP-ICE channel, 1x dual PMOD gets GPIO 12-19, ICE_CLK is on GPIO21. This should make things much easier to deal with. RGB is also next to each other. Please see rev 0.2 of the schematic.

[josuah]

PICO PMOD B:
The pin description show PICO_22_SCK0 .. PICO_25_SSn0, but PICO_25 seems to be bound to SSn1, not 0.

The shifts seems to occur due to the two pins ICE_RSTn and ICE_DONE, which are the the missing pins from SPI0.

[josuah]

SRAM_SSN and PICO_LED_B:
There might be a reason why the PICO_LED_B was put as far as GPIO29 away, but I cannot see it...

If it stays on GPIO15 (where SRAM_SSN currently is), then the four RGB LEDs are aligned, and then the SRAM_SSN can move to GPIO29.

With SRAM_SSN on GPIO29, it would also have GPIO29 exposed on the Pico J2 SPARE PMOD. GPIO29 being is the 4th ADC, this would make all 4 ADCs exposed onto that J2 SPARE PMOD.

[josuah]

ICE_CLK:
The clock coming from the RP2040 toward the FPGA. It is set to GPIO0.
Note that the RP2040 supports exporting a clock to some of its GPIO pins, but not all:

CLOCK GPOUTx
General purpose clock outputs. Can drive a number of internal clocks (including PLL outputs) onto GPIOs, with optional integer divide.
-- https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf#page=15

[josuah]

Pins supporting clock output:

• GPIO21 (currently ICE_DONE),
• GPIO23 (currently PICO_23_MOSI0),
• GPIO24 (currently PICO_24_MISO0),
• GPIO25 (currently PICO_25_SSn0)

The GPIO21 seems the easiest to move in case we want to use a variable speed PLL from the RP2040.

[vr2045]

You're right, I misread the datasheet and for some strange reason, assumed GPIO0 was the right pin to use for the clock! Will need to fix this and move things around.

[josuah]

TODO: How about the RUN, SWD and SWCLK pins? How can we put those in an easily accessible spot for the user?
One frequent way to put it is just placing a pin header on a side of the board, so the user can add a up-faced pin header, like it is done for quite any board around.

It is likely going to be a jumper cable plugged between the board and a debugger in all cases.

[vr2045]

Yes, this is a dedicated and standard 10 pin header on the board now.

[josuah]

TODO: Unify parts to minimize BoM

[vr2045]

So should we use TypeC or MicroUSB? I have a lot of MicroUSB cables but not many TypeC...

[josuah]

I do not really know. I read different opinions about it. It seems a bit like IPv4 vs IPv6.
What about a poll in a few places? I will ask on a few IRC channels and count the votes. :)

[vr2045]

Look forward to that... I see some new maker boards are using USBC. I dont think there is a significant cost differential between micro USB and USBC. I do like that the cable can be flipped and I think the connector is better designed than micro USB.
All things being equal, I'd prefer USBC as a result.

[josuah]

I did not have enough feedback for it to be significant, but the three person who answered were in favor of Type-C.

Here is a link posted earlier on #upduino_3 about Type-C:
https://www.scorpia.co.uk/2016/03/17/using-usb-type-c-on-hobyist-projects/

Adafruit offers breakout clearly exposing the compatibility between Type-C and other USB connectors:
https://www.adafruit.com/product/4090

I wonder if two 10k resistors in parallel would be a good enough 5.1k resistor.

[josuah]

https://www.usb.org/sites/default/files/USB%20Type-C%20Spec%20R2.0%20-%20August%202019_0.pdf#page=38#6

USB Type-C plugs associated with the “A” end of a legacy adapter cable are required to have Rd (5.1 kΩ ± 20%) termination incorporated into the plug assembly – see Section 4.5.3.2.1.

That ±20% is good news, maybe we are good with a pair of 10 kΩ in parallel

[josuah]

RP2040 Bootsel mode:
https://datasheets.raspberrypi.com/pico/pico-datasheet.pdf#page=25 (see "BOOTSEL" on the left)
As shown on the Raspberry Pico datasheet, in addition to the NRESET pin (called RUN in the RP2040 datasheet), a BOOTSEL button is used to turn the pico into the "flash-me" mode.

This button is to be connected to the same pin as QSPI_SS. At this early point of booting, the QSPI is not yet configured, and the built-in BOOTROM might be using this pin as general purpose GPIO input to check if pressed or not, and then only configure the QSPI interface.

Without such a button, it might not be possible to turn the RP2040 into that BOOTSEL "flash-me" mode.

[josuah]

My bad it is present! It is J? Conn_01x02 on the Pico Flash area.
I suggest naming it "BOOTSEL" as present in the datasheet, and as visible oon the Raspberry Pico board silkscreen.

[josuah]

Was there a reason for making it a connector instead of a switch?

[vr2045]

I presume this will be used very infrequently. Switches take up space and cost more than 2 holes on the board which is what this becomes.

[josuah]

Thank you, that sounds good and I learned about a new way to save-up board space.

[josuah]

Typos:
Finger just won't do what we tell them to.

[josuah]

I have not found any, except maybe some "?" in symbol names, which a Ctrl+F might kill swiftly.