tigard-tools / tigard

An FTDI FT2232H-based multi-protocol tool for hardware hacking
Other
560 stars 65 forks source link

explore feasibility of ice40 programming interface #15

Closed securelyfitz closed 3 years ago

securelyfitz commented 4 years ago

ice40 needs ICE_CDONE and ICE_CRESET not currently connected:

from top to bottom, from FTDI perspective:

Potential solution:

Note - downside: Can't use UART at the same time because RX would be clobbered. Alternative would mean adding a pin somewhere. Perhaps just use one of the spare LA (trig/clk/etc) pins?

esden commented 3 years ago

I have taken tigard V0.1 board and applied the modifications as proposed above.

Exactly as shown in this picture below: Screenshot_20200730-214648_Squid

I used a 2k2 resistor for the connection between BDBUS7 to BTBUS5.

I can confirm that this setup works and allows the use of iceprog to program an iCE40 Flash. Example command invocation:

iceprog -I B bitstream.bin

A flywiring connection from Tigard to a ice40 target for the purpose of bitstream FLASH programming would be the following:

Also tested if programming directly into the iCE40 SRAM works. I can confirm that it does. The following iceprog command can be used:

iceprog -I B -S bitstream.bin

Do not forget to disconnect the Flash CS jumper on your iCE40 target and to swap CIPO/COPI order, either with jumpers on your target or through wire swap. A wire swap would result in the following fly wire mapping from Tigard to iCE40 target:

Regarding the pin mapping. It would be lovely to have a dedicated connector for this, but space is limited and ice40 is a fairly small target subset all things considered. I think the compromise where it is possible to make a logic analyzer connector to ice40 programmer cable is a reasonable trade off.

But in case a connector is considered in the future I would like to propose the following icebreaker-bitsy connector pinout:

render-ortho-bot

This connector is a 0.1" (2.54mm) pitch 2x4 connector.

securelyfitz commented 3 years ago

Seems like a small enough change that it's worth implementing the additional routing but not the header, though good to document it in case someone forks or revises. @fharding1 let me know if it's not as straightforward as it looks or it's not feasible for other reasons.

fharding1 commented 3 years ago

@esden were you able to take a look at 0e0eb68?

esden commented 3 years ago

I have just tested with the newest version of the hardware and programming works as intended. Following is the wiring table:

Tigard Header Tigard Pin Number Tigard Pin iCE40 Signal
J2/JTAG/FTDI Bus B 1 VTGT (Optional) 3v3. If not connected set Tigard to 3v3 VTGT
J2/JTAG/FTDI Bus B 2 GND GND
J2/JTAG/FTDI Bus B 3 TCK CLK
J2/JTAG/FTDI Bus B 4 TDI/MOSI/SDA MOSI/COPI
J2/JTAG/FTDI Bus B 5 TDO/MISO/-- MISO/CIPO
J2/JTAG/FTDI Bus B 6 TMS/SS/-- Not Connected
J2/JTAG/FTDI Bus B 7 TRST/--/-- CS/ICE_SS_B
J2/JTAG/FTDI Bus B 8 SRST/--/-- CRESET
J2/JTAG/FTDI Bus B 9 !? CDONE

The programming command using iceprog is the following:

iceprog -I B yourbitstream.bin

If you want to program the iCE40 bitstream directly to the FPGA SRAM instead of programming the FLASH. You have to do the following things:

The resulting direct to SRAM programming command will then look something like this:

iceprog -I B -S yourbitstream.bin

Do not forget that when you load your bitstream directly to SRAM that bitstream will be lost when you power cycle your FPGA, you have to put the bitstream into the FLASH if you want it to persist.

securelyfitz commented 3 years ago

awesome. assigning this to me to add to the docs.

securelyfitz commented 3 years ago

documented in b602d86