TinyFPGA P1V sounds great to me. I'd like to be able to buy a low cost board that can do full P1V.
I'm not so interested in the "tiny" part though, I'd rather have a lot of I/O...
I’m working on another board that will be larger. How much general purpose IO would you like to see? What kind of connectors? What kind of peripherals?
To make it most compatible without much software modifications, the USB serial device should be a verilog module with a RX input and a TX output that transmits data serially with a certain baudrate (i.e. 115.2 kBaud, 8 data, 2 stopbits). Additionally the module should have a DTR output that can be connected to the RESn of the P1V emulation.
...
The serial interface should be doable. I haven’t yet added support for an actual UART signal, but it’s something that’s not too hard and I’ve been wanting to do it anyways.
Wow, adding a UART would be great. Then you have swallowed a whole FT2232H (well, almost, just not HS-USB) into the fabric !!
The ideal UART supports BAUD settings, and the better USB Bridges have a 24MHz virtual baud clock.
That means applied formula of Baud = 24MHz/N, where N is above some value.
In some bridges, N is 16b limiting lower baud to > 367 or similar. Bridge parts like CP2102N have a RTS/CTS hardware handshake ability, useful for 2,3,4MBd area.
Some SDK's ignore the baud field, which is a pain, but I guess that is less logic and less code....
Perhaps the loader side needs full Baud control, and the user-insert-able verilog could have conditionals to reduce logic impact ?
The serial interface should be doable. I haven’t yet added support for an actual UART signal, but it’s something that’s not too hard and I’ve been wanting to do it anyways.
That would be excellent. It's always good to have serial there because you can use it for multiple things including printf debugging etc during runtime as well as other downloads. The various Propeller Tools are also then well supported and even though you could also use those SPI programming tools you would supply to load P1V images directly into the SPI flash which could be handy with automated Makefiles etc, it is pretty nice to have the standard integrated development environment supported, especially for the beginners. Another benefit is that there exists some proploader tools that allow files to be transferred directly to the SD card on the board and these currently work with serial, though in theory they could be extended to use some raw USB interface stuff too. It's nice to not have to modify any of the tools unless you really want to.
Being able to use the Prop tool over virtual com port from a PC would be great.
That might mean adding a FTDI usb-uart chip though...
P1V should be able to do 64 I/O with Port B. If some of them go to SPI and memory chips, then I guess they don't need to be all brought out to a header.
I guess I'd like at least 32 free I/O at a header...
Being able to use the Prop tool over virtual com port from a PC would be great.
That might mean adding a FTDI usb-uart chip though...
No, no FTDI chip. Lukes bootloader already implements a virtual com port, but he sends the USB data stream over SPI to the Flash. What we need is another backend that sends the data over UART to PA30/PA31.
So the FTDI chip is emulated in the FPGA, just like the P1 is emulated.
P1V should be able to do 64 I/O with Port B. If some of them go to SPI and memory chips, then I guess they don't need to be all brought out to a header.
I guess I'd like at least 32 free I/O at a header...
The tiny board has 41 IOs on the header pins, if I count correct. Then there are 4 or 6 for SDcard, 6 for the flash chip, 2 for the USB-serial, and maybe 12 for the HyperRAM. So you already covered all 64 possible IOs of a P1V with a port B. (not sure if the RAM should be port mapped though).
Being able to use the Prop tool over virtual com port from a PC would be great.
That might mean adding a FTDI usb-uart chip though...
P1V should be able to do 64 I/O with Port B. If some of them go to SPI and memory chips, then I guess they don't need to be all brought out to a header.
I guess I'd like at least 32 free I/O at a header...
The TinyFPGA EX has 42 IOs on the header. Then there are 6 IOs dedicated to the SPI flash, 12 dedicated for HyperRAM, 6 dedicated for the SD card, 3 dedicated to USB, 1 dedicated to PROGRAMN, and 1 dedicated to the indicator LED.
However, my current prototypes only have 41 IOs on the header because one of them has to be tied to the PROGRAMN pin with a bodge wire. Oops.
No external USB-UART chip is required, the USB-UART can fit inside the FPGA fabric alongside the propellor design.
No external USB-UART chip is required, the USB-UART can fit inside the FPGA fabric alongside the propeller design.
Once that is done, it does not have to connect via pins, future options could be register mapping, and debug-fabric use, supporting single step/break/watch etc
What sustained data rate can the USB link support ?
Once that is done, it does not have to connect via pins, future options could be register mapping, and debug-fabric use, supporting single step/break/watch etc
What sustained data rate can the USB link support ?
I’ve seen about 400 kilobytes per second reading from flash. It could be optimized a bit more. I currently have a single buffer for RX and a single buffer for TX. I would like to change it so it is double-buffered each direction. That will maximize performance.
I’ve seen about 400 kilobytes per second reading from flash. It could be optimized a bit more. I currently have a single buffer for RX and a single buffer for TX. I would like to change it so it is double-buffered each direction. That will maximize performance.
~ 4MBd is reasonable. Best I've seen on FS-USB bridges, are on the EXAR parts, which can set up to 12MBd Baud value, and sustain over 9MBd data flows.
Most others are in the 3~4MBd ballpark data flow.
~ 4MBd is reasonable. Best I've seen on FS-USB bridges, are on the EXAR parts, which can set up to 12MBd Baud value, and sustain over 9MBd data flows.
Most others are in the 3~4MBd ballpark data flow.
I just remembered that I could use 64 byte packets instead of the 32 byte packets I’m currently using. That plus double buffering should bring performance up to par with the best of them.
I just remembered that I could use 64 byte packets instead of the 32 byte packets I’m currently using. That plus double buffering should bring performance up to par with the best of them.
Look forward to hearing the final numbers.
Good speeds like that, means this could also be used as a logic capture probe.
Is there another size ecp5 board that you have ready to go, Luke?
I really wish I did
I’m a bit backed up at the moment. I only have the TinyFPGA A-series boards in stock at the moment. I decided to crowd fund my second round of TinyFPGA B-series boards and it’s just taking longer than expected to put the whole campaign together.
Once that campaign finishes I will hopefully be able to manufacture a first run of the TinyFPGA EX boards with the ECP5 FPGA.
The __init__.py files are required to make Python treat the directories as containing packages; this is done to prevent directories with a common name, such as string, from unintentionally hiding valid modules that occur later on the module search path. In the simplest case, __init__.py can just be an empty file, but it can also execute initialization code for the package or set the __all__ variable, described later.
__init__.py has a class Tinyprog (amongst others), so from tinyprog import Tinyprog will use the class Tinyprog specified in __init__.py in the folder tinyprog.
Edit: Same treatment for calling it via -m (but in this case the __main__.py will be used aswell)
For a package, the same effect can be achieved by including a __main__.py module, the contents of which will be executed when the module is run with -m.
If anyone is going to the Maker Faire coming up in May in California I’ll have an exhibit there with projects showcasing some TinyFPGA boards including the EX.
I just remembered that I could use 64 byte packets instead of the 32 byte packets I’m currently using. That plus double buffering should bring performance up to par with the best of them.
Did you manage to increase the link speed, as expected ?
This is good jmg. I had been hoping to see Lattice release the 256 pin 0.8mm BGA at some point.
By the way, speaking from my own personal experience, the ECP5 -25F parts can certainly house a full 8 COG P1V and some extras such as an SDRAM memory controller and DVI/HDMI video output with a bit of room left over. Runs at 80MHz too so it's just about ideal and great for its price. Only downside is it doesn't have the internal flash inbuilt and single supply options like the MAX10 family offer, but I can live with that extra external SPI flash chip and additional voltage rails like most regular FPGAs need. You can always use the FPGA's SPI chip to hold the P1 code as well, replacing the i2c EEPROM.
One appeal here, is I see a new package that has 58io, but is likely 2-4 layer PCB friendly, and getting closer to P1 SMD models.
A secure P1, with more RAM and more IO may have appeal ?
MachXO3D-9400 72 QFN (10 mm x 10 mm) 58io (HC / ZC)
No price on these new ones, but LCMXO3L-9400E-5MG256C (BGA256) with 206 io is $8.72/260
I wonder what can fit into the 9400 LUTs ?
Features MachXO3D-4300 MachXO3D-9400
LUTs 4300 9400
Distributed RAM (kbits) 34 73
EBR SRAM (kbits) 92 432
UFM (kbits) 367/1122 #3 1088/2693 #3
PLLs 2 2
Hardened Security Block 1 1
Oscillator 1 1
On-chip Dual-boot Yes Yes
I3C compatible I/O Yes #1 Yes #1
MIPI D-PHY Support #2 Yes Yes
Core Vcc 2.5 - 3.3V 2.5 - 3.3V
Commercial Temperature Grade Yes Yes
Industrial Temperature Grade Yes Yes
High Performance / Low Power Option HC / ZC HC / ZC
#1. 4 pairs of I/O in bank 3 with I3C dynamic pull up capability.
#2. HC device only.
#3. When dual-boot is disabled, image space can be repurposed as extra UFM.
Comments
I'm not so interested in the "tiny" part though, I'd rather have a lot of I/O...
I’m working on another board that will be larger. How much general purpose IO would you like to see? What kind of connectors? What kind of peripherals?
Wow, adding a UART would be great. Then you have swallowed a whole FT2232H (well, almost, just not HS-USB) into the fabric !!
The ideal UART supports BAUD settings, and the better USB Bridges have a 24MHz virtual baud clock.
That means applied formula of Baud = 24MHz/N, where N is above some value.
In some bridges, N is 16b limiting lower baud to > 367 or similar. Bridge parts like CP2102N have a RTS/CTS hardware handshake ability, useful for 2,3,4MBd area.
Some SDK's ignore the baud field, which is a pain, but I guess that is less logic and less code....
Perhaps the loader side needs full Baud control, and the user-insert-able verilog could have conditionals to reduce logic impact ?
That would be excellent. It's always good to have serial there because you can use it for multiple things including printf debugging etc during runtime as well as other downloads. The various Propeller Tools are also then well supported and even though you could also use those SPI programming tools you would supply to load P1V images directly into the SPI flash which could be handy with automated Makefiles etc, it is pretty nice to have the standard integrated development environment supported, especially for the beginners. Another benefit is that there exists some proploader tools that allow files to be transferred directly to the SD card on the board and these currently work with serial, though in theory they could be extended to use some raw USB interface stuff too. It's nice to not have to modify any of the tools unless you really want to.
That might mean adding a FTDI usb-uart chip though...
P1V should be able to do 64 I/O with Port B. If some of them go to SPI and memory chips, then I guess they don't need to be all brought out to a header.
I guess I'd like at least 32 free I/O at a header...
Checking into low price & small USB parts... should this not fit into the loader fabric
CP2102N in QFN20 3x3mm is English data, USA vendor, mature driver, up to 4MBd, and $1.15/1k
there is also
https://lcsc.com/search?q=CH340 Shows CH340E, in MSOP10, 39c/100 2MBd, and a complete module for 1: $0.8489 - wow...
I've not tried one of those CH340 yet.
So the FTDI chip is emulated in the FPGA, just like the P1 is emulated.
The tiny board has 41 IOs on the header pins, if I count correct. Then there are 4 or 6 for SDcard, 6 for the flash chip, 2 for the USB-serial, and maybe 12 for the HyperRAM. So you already covered all 64 possible IOs of a P1V with a port B. (not sure if the RAM should be port mapped though).
Andy
The TinyFPGA EX has 42 IOs on the header. Then there are 6 IOs dedicated to the SPI flash, 12 dedicated for HyperRAM, 6 dedicated for the SD card, 3 dedicated to USB, 1 dedicated to PROGRAMN, and 1 dedicated to the indicator LED.
However, my current prototypes only have 41 IOs on the header because one of them has to be tied to the PROGRAMN pin with a bodge wire. Oops.
No external USB-UART chip is required, the USB-UART can fit inside the FPGA fabric alongside the propellor design.
Once that is done, it does not have to connect via pins, future options could be register mapping, and debug-fabric use, supporting single step/break/watch etc
What sustained data rate can the USB link support ?
I’ve seen about 400 kilobytes per second reading from flash. It could be optimized a bit more. I currently have a single buffer for RX and a single buffer for TX. I would like to change it so it is double-buffered each direction. That will maximize performance.
~ 4MBd is reasonable. Best I've seen on FS-USB bridges, are on the EXAR parts, which can set up to 12MBd Baud value, and sustain over 9MBd data flows.
Most others are in the 3~4MBd ballpark data flow.
I just remembered that I could use 64 byte packets instead of the 32 byte packets I’m currently using. That plus double buffering should bring performance up to par with the best of them.
Good speeds like that, means this could also be used as a logic capture probe.
Looks like the 25k LUT4 part will do the trick. It’s not available quite yet. A few more months at least.
I really wish I did
I’m a bit backed up at the moment. I only have the TinyFPGA A-series boards in stock at the moment. I decided to crowd fund my second round of TinyFPGA B-series boards and it’s just taking longer than expected to put the whole campaign together.
Once that campaign finishes I will hopefully be able to manufacture a first run of the TinyFPGA EX boards with the ECP5 FPGA.
Nifty, and python too.. is there a link to source for that somewhere ?
Thanks!
https://github.com/tinyfpga/TinyFPGA-Bootloader
I can see something called like this
python2 tinyfpga-programmer-gui.py
which looks like the GUI part, and I can see
TinyFPGA-Bootloader/programmer/tinyprog/__init__.py
TinyFPGA-Bootloader/programmer/tinyprog/__main__.py
but main says
from tinyprog import TinyProg
and no sign of the expected command line tinyprog.py ?
Hmm, my python is rusty, but does not the video's example command line of
python -m tinyprog -p FileName
expect to find a filename tinyprog.py ?
__init__.py has a class Tinyprog (amongst others), so from tinyprog import Tinyprog will use the class Tinyprog specified in __init__.py in the folder tinyprog.
Edit: Same treatment for calling it via -m (but in this case the __main__.py will be used aswell)
(from https://docs.python.org/3/library/__main__.html)
And all of this applies to python 2 and 3
Did you manage to increase the link speed, as expected ?
Any updates on deliveries ?
I'll bump this thread, as there are now stocks of the smaller packages (from another thread )
By the way, speaking from my own personal experience, the ECP5 -25F parts can certainly house a full 8 COG P1V and some extras such as an SDRAM memory controller and DVI/HDMI video output with a bit of room left over. Runs at 80MHz too so it's just about ideal and great for its price. Only downside is it doesn't have the internal flash inbuilt and single supply options like the MAX10 family offer, but I can live with that extra external SPI flash chip and additional voltage rails like most regular FPGAs need. You can always use the FPGA's SPI chip to hold the P1 code as well, replacing the i2c EEPROM.
https://www.crowdsupply.com/tinyfpga/tinyfpga-ex/updates/new-prototypes-and-updated-variants
and there is also this news from Lattice
https://www.edacafe.com/nbc/articles/1/1677816/Lattice-Diamond-3.11-Software-Adds-Support-New-MachXO3D-FPGA
http://www.latticesemi.com/Products/FPGAandCPLD/MachXO3D
One appeal here, is I see a new package that has 58io, but is likely 2-4 layer PCB friendly, and getting closer to P1 SMD models.
A secure P1, with more RAM and more IO may have appeal ?
MachXO3D-9400 72 QFN (10 mm x 10 mm) 58io (HC / ZC)
No price on these new ones, but LCMXO3L-9400E-5MG256C (BGA256) with 206 io is $8.72/260
I wonder what can fit into the 9400 LUTs ?