search

icebreaker-fpga / icebreaker

Small and low cost FPGA educational and development board
547 stars 73 forks source link

Explore options for FTDI replacement #14

Open esden opened 5 years ago

esden commented 5 years ago

There are very low cost STM32 that don't even require an external oscillator to be used with USB.

Note: We are not making this change for the V1.0 hardware. The Crowd Funding campaign will rely on the FTDI chip. This issue is part of the V2.0 milestone. <- To whomever will skim over this issue and not read the details. ;)

STM32F042K6T6 for example can be purchased on aliexpress for a really good price. I have also compared prices of similar parts from other vendors. The STM32 turns out to be lower cost than any alternative chip with this kind of specifications. With added bonus of being easily available from a lot of vendors on aliexpress.

List of advantages of the STM32:

List of disadvantages of the STM32:

List of things we retain:

Alternatives to the STM32:

This issue is here to track the testing of that part. Close it if we decide not to go down that path, or we realize that it has some big flaw that is worth the 4x price difference of the FTDI chip. Or when we decide to use this approach and decide that this is our main path.

esden commented 5 years ago

Added a list of alternative chips to the STM32.

I am still planing to continue down the road with STM32 as I know that chip family very well. They are abundant and easy to get from many sources. The price is comparable with the other chips. And I have many projects to source code from. Also STM32 is best supported by Black Magic Probe and I like to be able to be able to debug the things I build. :)

esden commented 5 years ago

After a discussion with @cliffordwolf here is a collection of thoughts about how we want to build the USB interface on the device:

Requirements:

Resulting design decisions:

mithro commented 5 years ago

FYI - You can perfectly emulate a FTDI chip with these low cost STM32 chips (just a matter of software :-)

On Mon., 10 Sep. 2018, 3:02 pm Piotr Esden-Tempski, < notifications@github.com> wrote:

After a discussion with @cliffordwolf https://github.com/cliffordwolf here is a collection of thoughts about how we want to build the USB interface on the device:

Requirements:

  • Has to be easy to setup on all the major three OS, with no driver installation if possible:
    • Linux
    • Windows
    • MacOS X
  • Has to have a simple protocol but preferably not bitbang as it is super inefficient
  • Provide FLASH programming (SPI)
  • Provide USB-Serial for simple FPGA designs (UART) (this is much simpler than adding a full USB stack to the design that is why an external chip is being considered at all)
  • The programming protocol has to support the following features:
    • Flash the SPI FLASH containing the FPGA bitstream
    • Upload bitstream directly to the FPGA SRAM cells
    • Reset FPGA
    • Reset FLASH and get it out of QSPI mode for flashing

Resulting design decisions:

  • Due to how ugly Windows driver situation is we prefer to use a builtin virtual serial driver instead of going raw libusb protocol.
  • The device presents the following hybrid USB interface to the PC:
    • CDC-ACM (Virtual Serial) port No. 1 for FPGA flashing
    • CDC-ACM (Virtual Serial) port No. 2 for USB-Serial adapter interface
    • DFU stub, gives access to the DFU bootloader of the STM32 for programmer firmware upgrade.
  • Base the programming protocol on the FTDI MPSSE engine opcodes. This way adding support for this programmer to iceprog will be relatively simple. How viable this is, depends on how much extra functionality we will want to add that is currently not possible with the FTDI programmer solution.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/icebreaker-fpga/icebreaker/issues/14#issuecomment-420076323, or mute the thread https://github.com/notifications/unsubscribe-auth/AABS3EUpfX5woMipXKEb1HZrhVHhYh76ks5uZuGMgaJpZM4Wh5NN .

esden commented 5 years ago

@mithro I bet this is possible. I am not sure what benefit it provides besides the direct reuse of existing programmer desktop software. I do like the idea, it might be either the default or an alternate use of the stm32 programmer.

What I like even more is to be able to do things that the FTDI chip does not provide. For example being able to program the flash chip or the FPGA sram directly without having to set jumpers. Having a feature like this would somewhat offset the loss of high speed USB and FIFO modes.

mithro commented 5 years ago

@esden Emulating the FTDI chip is kind of silly -- except it stops people complaining about you not using the FTDI chip.....

ekawahyu commented 5 years ago

@esden what would be the USB library you have in mind? I did some code with STM32 library for CDC-ACM and DFU capability on F072. It was like 48kB+, so probably it won't fit in F042K6T6. It was compiled with GCC, it would probably much less with paid compilers.

esden commented 5 years ago

I will definitely prefer to implement it using libopencm3. I am somewhat biased about that. ;)

And for sure I will not want to use or depend on a proprietary compiler for this, this is a definite NO GO.

gsteiert commented 5 years ago

How about MSC with UF2 instead of DFU? There is an STM port: https://github.com/mmoskal/uf2-stm32f It really simplifies the windows driver issues and you don't have compile a programming app for every OS.

mithro commented 5 years ago

I agree that having support for UF2 would be excellent.

The great thing about having an ARM micro is that you could potentially support all these modes. UF2, DFU, FTDI serial, etc.... It's just different software code running on the microprocessor.

UweBonnes commented 5 years ago

The FT2232H allows to pump data to the PC with up to 30 MByte/s. Some Full-Speed device like the STM32F042 can only do up to 1.5 MByte/sec...

esden commented 5 years ago

@UweBonnes that is true. But the speed is not the most important part of this issue.

Note: We are not making this change for the V1.0 hardware. The Crowd Funding campaign will rely on the FTDI chip. This issue is part of the V2.0 milestone. <- To whomever will skim over this issue and not read the details. ;)

I am aware that the STM32 will not have the transfer speed of the FTDI chip. I think the more important thing to keep in mind is keeping the cost of the iCEBreaker low rather than a high speed data pipe. Also FTDI really does not want our business, their prices are stupid high, until you reach 10k or more units per purchase. (Still then the price of the FTDI chip is higher than I would want it to be) I talked to them about that and they have no interest. Currently the FTDI chip is the most expensive iCEBreaker BOM item. Even the FPGA is less expensive. If you know of a low cost ARM Cortex microcontroller with USB HS PHY built in I would love to hear about it. It might be an alternative to this solution.

The chips that I am aware of are TM4C129x, K27 and K28. Those are still prohibitively expensive for this application. We need a chip that is <$3 in 1k quantity. We might consider the FX2 but I am really not a fan of the 8051 :(

That said, even when we have a lower cost solution, we will continue making the FTDI iCEBreaker for those that need the high speed data transfer rates. But we also need a lower cost solution that does not rely on the FTDI chip as this is an educational platform and we need to be aware of limited class budgets.

osterwood commented 5 years ago

The ATSAMG55 looks promising. The G package gets down to $2.92 in QTY 1k when purchased direct from Microchip. Impressive specifications and have USB HS. SKUs are:

G are 49/WLCSP package and J are 64/LQFP (they are a little more expensive). I've never used them before, but might be worth considering.

esden commented 5 years ago

@osterwood are you sure they have USB HS? From the datasheets it seems they only have a FullSpeed transceiver built in. But I might be missing something. There are plenty of ARM Cortex chips that have HighSpeed support but require an external PHY. I was hoping to avoid that.

UweBonnes commented 5 years ago

STM32F723 has HS Phy on chip, but pricey also...

osterwood commented 5 years ago

Yeah - you're right. Saw "high speed" on the summary page and just assumed. Looks like the only options from Microchip are PIC32MZ ($6 to $7) and SAMS7x/E7x/V7x ($5 and up)

mithro commented 5 years ago

If you want full 480 megabit, the FX2 chip is a decent option and can get down to $3-4 USD each. They are used on our Opsis and Atlys board.

@whitequark has been working on doing FX2 firmware to support UF2, Serial and DFU programming modes for me.

UweBonnes commented 5 years ago

The STM32F730Z8T6 (with integrated OTG HS phy) comes need to the 3$@1000 margin.

smunaut commented 5 years ago

Also need to check that whatever uC with HS you use, it not only has high-speed usb, but also some other peripheral to actually transfer all that data to the ice40 and good DMA between usb and it.

esden commented 5 years ago

@UweBonnes That is a good find. Added advantage is that the STM32F730Z8T6 can run down to 1.8V so we could run all the FPGA GPIO at the lower voltage what we can't do at the moment. The only disadvantage I see is that we either have to use the BGA or the 177 LQFP package of the part. But that is not a very big deal, just slightly annoying. I wish it came in a small QFN or something along those lines. ;)

@smunaut yes that is a good question. It seems to have a dedicated DMA for the HS USB, but I think we have to build a prototype and write some test code to know for sure how much performance we can squeeze out of the part.

UweBonnes commented 5 years ago

It is a pity that the smaller STM32F72x packages don't have the USB-HS phy pinned out.

smunaut commented 5 years ago

@esden Note that the STM32F730Z8T6 , I can't buy it here ... digikey/mouser tell me that due to US export restriction, that chip is unavailable. Make sure you don't use something you can't export.

gsteiert commented 5 years ago

Has anyone ever used a Nuvoton mcu? They have cost effective high speed options in a smaller package: https://direct.nuvoton.com/en/m484sidae

esden commented 5 years ago

@gsteiert I personally never did, but I know that people like using nuvoton parts in toys as they are usually very low cost. Good find! :)

gsteiert commented 5 years ago

Here is one that is even smaller, less expensive, and more memory: https://direct.nuvoton.com/en/nuc505dl13y It also includes an SDHC host. That's a lot of data. And only $2.03 @1k

esden commented 5 years ago

@gsteiert that is a really awesome find! It pretty much perfectly matches our needs.

The next question is how good is the documentation of the chip, and if there are existing open-source friendly libraries. If there are no libraries it is not a huge problem but rather a delay as we need to create them, as long as the chip is properly documented. ;) Do you have any experience developing for Nuvoton chips using GCC/LLVM/GDB/Make and all the other typical open source embedded tools? And no Keil or IAR is not an option for the project beyond very basic evaluation tests. ;)

I briefly looked at the reference manual, and it seems to at least contain register definitions and it can be downloaded without much trouble. As long as the chip is well documented I think we might have a winner! :D

gsteiert commented 5 years ago

It doesn't include the NUC505 specifically, but several of their other parts are supported in mbed: https://github.com/ARMmbed/mbed-os/tree/master/targets/TARGET_NUVOTON This is apache 2 licensed and you can build it with gcc. Even if you don't want to use their HAL, it is a good source for the CMSIS libraries.

xelll commented 5 years ago

I look forward to your success

majbthrd commented 5 years ago

The ATSAMD11 is only $1.24 in single quantity and $1.02/3k. I have an open-source DFU protocol bootloader (https://github.com/majbthrd/SAMD11-USB-DFU-Bootloader/) that is only 1kByte in size. Providing a CDC implementation and FPGA initialization in 15kBytes is hardly challenging, and I'm familiar with the iCE40. If your collective hearts are really set on the STM32, I also have example CDC and composite code for the STM32F042/STM32F072 on my github page.

smunaut commented 5 years ago

The SAMD11 is Full Speed only, not High-Speed.

majbthrd commented 5 years ago

I am aware the SAMD11 is FS, thanks. An iCE40UP5K configuration consists of 104,158 bytes. The perceptual difference between a FS and HS for such a download is negligible, particularly if SPI erase and write operations are involved. There would be a difference for writing the entire 16MByte quad flash, but you guys have ask yourselves whether this board is something with good value for money for education or something else.

esden commented 5 years ago

@majbthrd you are missing the point. The USB to serial/SPI function of the interface chip is meant not only for programming of the FPGA, but also to provide a high speed interface between the FPGA and the computer. This is also a very important function in my opinion.

If you only think about the lowest cost solution I would still go for an STM32 because I can get them much cheaper than any of the SAMD chips anyone mentioned in here. (below $1 in small quantities) I am not sure why so many people are so hung up on SAMD... if you check the specs and pricing you very quickly will see it is not the best solution by a long shot. ;)

We are trying to optimize the possible usability of the board while keeping the price low. Having a USB HS interface to the FPGA has many very interesting applications, and we are trying to accommodate them, not just make the cheapest possible board.

majbthrd commented 5 years ago

Good luck with your project. I have designed in both STM32F0x2 and SAMDx1 (both sub-$1 in quantity... the figure I quoted was a snapshot from a US distributor and likely reflects trade tariffs), and both have their particular strengths and weaknesses. About the only thing I would politely disagree with is an assertion earlier in the thread that CDC would take 48kBytes+ in the STM32.

esden commented 5 years ago

@majbthrd thank you. Yes you are probably right that CDC can be put in a much smaller Flash space. It was not my opinion that we can't put that into a tiny chip. Especially when you don't use the vendor libraries that are made to be very generic and tend to be very inefficient. The chip used at the end just has to fit a certain price and peripheral requirement list. (I should update my top post to correct the goals) Whatever fits the bill best is what we will try going for. The Nuvoton part seems to fit that bill best at the moment, although I am very concerned with their sparse documentation. We will see how that goes. :)

majbthrd commented 5 years ago

I acquired a NuTiny-NUC505Y eval board and set about getting USB working on it. It is extremely far from a finished solution, but I've posted a snapshot of a CDC virtual serial port implementation here: https://github.com/majbthrd/NUC505testing Throughput in Linux using dd is about ~9.5+ MBytes/s in each direction (e.g. ~152+ Mbits/s total). Code size is under 9kBytes.

esden commented 5 years ago

That is awesome! Thank you for sharing! That is definitely a great starting point! :D

kehribar commented 5 years ago

Hi All,

That Nuvoton chip sounds really promising.

Anyway, I just wanted to drop my ongoing work with STM32F042 here. May be useful to someone. My goal is to create some sort of low cost "ICE40 programming / basic computer interface" platform with minimal FPGA IO consumption. For real data transfer needs (like raw ADC capture etc.) user can connect an additional FT232H single channel 480Mbps fifo to the GPIOs of FPGA.

Repo link is this: https://github.com/kehribar/ice40helper

Right now the firmware (libopencm3 based) & software can:

Beware:

You can check my reference hardware design from here: schematic pdf

zeroeth commented 4 years ago

A little late to the party, but just want to +1 stm32 because of all the great libopencm3 examples/workflows.

Having the board potentially be dual purpose (and custom usb hid such as usb joystick/midi) would be absolutely jawesome.

related: dadamachines did something similar so the board is directly arduino compatible too https://dadamachines.com/product/doppler/ some food for thought! Especially now that arduino themselves have a mostly closed toolchain fpga hybrid board.

ejhollas commented 4 years ago

Windows drivers can be simplified by making use of Microsoft's WinUSB drivers. These drivers are built-in to Windows 8 and later. A simple INF file can make it work on Windows 7 as well.

To get Windows to attach WinUSB, the ST firmware will just need a few USB descriptors that Windows will read on first plug-in. No drivers need signing using this method. WinUSB supports composite devices, so we can expose a CDC serial interface and a vendor specific interface. This will allow us to use high bandwidth endpoints over bulk or iso.

The WinUSB API has native C bindings. There is support in the libusb project as well as C#, go and python bindings. I'll be happy to help contribute and test the descriptors.

rljacobson commented 4 years ago

I am curious to know if V2.0 is being actively developed, as there does not seem to be much activity on this issue. @majbthrd's experimentation seems to indicate that the Nuvoton chip is in some ways quirky but serviceable. The STM32F730Z8T6 has the advantage of familiarity, runs at twice the clock rate, but costs slightly more and has comparatively little FLASH ("external memory can be used with no performance penalty thanks to the L1 cache").

gsteiert commented 4 years ago

I think there are a few new options since this thread was started. The i.MX RT1064 used on the Teensy 4.0 is even faster, or the RT1010 for a lower cost option. The LPC55xx series has integrated flash. All of these have the high speed USB phy integrated.

On Wed, Nov 27, 2019, 10:47 PM Robert Jacobson notifications@github.com wrote:

I am curious to know if V2.0 is being actively developed, as there does not seem to be much activity on this issue. @majbthrd https://github.com/majbthrd's experimentation seems to indicate that the Nuvoton chip is in some ways quirky but serviceable. The STM32F730Z8T6 has the advantage of familiarity, runs at twice the clock rate, but costs slightly more and has comparatively little FLASH ("external memory can be used with no performance penalty thanks to the L1 cache").

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/icebreaker-fpga/icebreaker/issues/14?email_source=notifications&email_token=AJZ2HJRMLPWPY4LFNM5MNUDQV5SRXA5CNFSM4FUHSNG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFLTT3I#issuecomment-559364589, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJZ2HJW63JFIVFA3F4C7BMDQV5SRXANCNFSM4FUHSNGQ .

UweBonnes commented 4 years ago

Greg Steiert writes:

I think there are a few new options since this thread was started. The i.MX RT1064 used on the Teensy 4.0 is even faster, or the RT1010 for a lower cost option. The LPC55xx series has integrated flash. All of these have the high speed USB phy integrated.

I see one problem in a missing USB HS stack that is open source and works with a makefile

-- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------

tannewt commented 4 years ago

I'd like to add high speed support to TinyUSB (an open source USB stack). @hathach just added full speed support for the i.MX RT series.

hathach commented 4 years ago

@tannewt thanks for mentioning TinyUSB, iMX RT series is actually highspeed USB, it isn't much difference in stack driver software between FS and HS :)

ulixxe commented 2 years ago

Another possibility is to implement USB device stack on the same FPGA fabric. See: https://github.com/ulixxe/usb_cdc

smunaut commented 2 years ago

Did you even read the thread and the requirements listed in it ?

gregdavill commented 2 years ago

There are now WCH parts available* that integrate a USB HS PHY. Like Gigadevices they have both CorteX-M3/RISCV variants, they also have some "RISC" (The ones with HS USB also appear to be RISCV) based devices for implementing interface controllers, these appear to fill a similar market to the FX2 series.

Here are some RISCV based options:

Cortex M3 options:

All of these also include USART+SPI so should satisfy the base requirements for interface to the FPGA.

LCSC has stock of the CH32V307, other parts I imagine you'll have to contact WCH for a sales channel, like Gigadevices.

The main downside these parts have is their size, because they also include a fair few extra interfaces the smallest parts are in LQFP-100/LQFP-64. So might end up making the board a bit dense.