Shop OBEX P1 Docs P2 Docs Learn Events
P1V - with Lattice ECP5 FPGAs? - Page 7 — Parallax Forums

P1V - with Lattice ECP5 FPGAs?

123457

Comments

  • RaymanRayman Posts: 13,767
    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...
  • Rayman wrote: »
    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?
  • jmgjmg Posts: 15,140
    TinyFPGA wrote: »
    Ariba wrote: »
    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 ?
  • roglohrogloh Posts: 5,119
    edited 2018-03-07 22:06
    TinyFPGA wrote: »
    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.
  • RaymanRayman Posts: 13,767
    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...
  • jmgjmg Posts: 15,140
    Rayman wrote: »
    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...

    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.
  • AribaAriba Posts: 2,682
    Rayman wrote: »
    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).

    Andy
  • Rayman wrote: »
    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.

  • jmgjmg Posts: 15,140
    edited 2018-03-07 01:02
    TinyFPGA wrote: »
    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 ?
  • jmg wrote: »
    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.
  • jmgjmg Posts: 15,140
    TinyFPGA wrote: »
    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.

  • jmg wrote: »

    ~ 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.
  • jmgjmg Posts: 15,140
    edited 2018-03-07 01:59
    TinyFPGA wrote: »
    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.
  • What size board is required for P1v and is it available yet?
  • David Betz wrote: »
    What size board is required for P1v and is it available yet?

    Looks like the 25k LUT4 part will do the trick. It’s not available quite yet. A few more months at least.

  • Is there another size ecp5 board that you have ready to go, Luke?
  • Tubular wrote: »
    Is there another size ecp5 board that you have ready to go, Luke?

    I really wish I did :D

    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.
  • Here’s a video of the programmer in action with an uncompressed ECP5 25K image: https://drive.google.com/open?id=15lV0qPTYc_ZODd8CqYCpwxMsmClIP2XL
  • roglohrogloh Posts: 5,119
    edited 2018-03-07 22:11
    Pretty fast turnaround time with the 25K image flashing Luke, nice one. :thumb:
  • jmgjmg Posts: 15,140
    TinyFPGA wrote: »
    Here’s a video of the programmer in action with an uncompressed ECP5 25K image: https://drive.google.com/open?id=15lV0qPTYc_ZODd8CqYCpwxMsmClIP2XL

    Nifty, and python too.. is there a link to source for that somewhere ?
  • jmg wrote: »
    Nifty, and python too.. is there a link to source for that somewhere ?

    Thanks!

    https://github.com/tinyfpga/TinyFPGA-Bootloader
  • RaymanRayman Posts: 13,767
    I think I read that Lattice is only FPGA with open source loader, right?
  • jmgjmg Posts: 15,140
    TinyFPGA wrote: »
    jmg wrote: »
    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 ?

  • Look in __init__.py
  • jmgjmg Posts: 15,140
    rosco_pc wrote: »
    Look in __init__.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 ?
  • rosco_pcrosco_pc Posts: 448
    edited 2018-03-08 05:48
    (from https://docs.python.org/3/tutorial/modules.html#packages)
    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)

    (from https://docs.python.org/3/library/__main__.html)
    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.

    And all of this applies to python 2 and 3
  • 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.
  • jmgjmg Posts: 15,140
    TinyFPGA wrote: »
    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 ?
    TinyFPGA wrote: »
    David Betz wrote: »
    What size board is required for P1v and is it available yet?

    Looks like the 25k LUT4 part will do the trick. It’s not available quite yet. A few more months at least.

    Any updates on deliveries ?


    I'll bump this thread, as there are now stocks of the smaller packages (from another thread )
     Part Number            Stock             Price               LAB       LE      RAM bits I/O     Package
    LFE5U-12F-6BG256C	119 - Immediate  $5.05000/1	ECP5  3000	12000	589824	 197	 256-CABGA (14x14)
    LFE5U-25F-6BG256C	104 - Immediate  $9.29000/1	ECP5  6000	24000	1032192	 197	 256-CABGA (14x14)
    LFE5U-45F-6BG256C	  0 9 Weeks     $15.86000/1	ECP5  11000	44000	1990656	 197	 256-CABGA (14x14)
    LFE5U-85F-6BG381C	64 - Immediate  $31.26000/1 	ECP5  21000	84000	3833856	 205	 381-CABGA (17x17)
    
    and  at the 3k column that's nudging price parity with P1, and ahead if you factor in $/Memory or $/io
    P8X32A-Q44	        Parallax Inc.	IC MCU 32BIT 32KB ROM  32io  44LQFP	        2,827 - Immediate  $7.48800/3k
    LFE5U-25F-6BG256C	Lattice 	IC FPGA	              197io  256-CABGA (14x14)    104 - Immediate  $7.85170/3k
    
    LFE5U-12F-6MG285C	12K LUTS, 118io   $4.98940/168   285-CSFBGA (10x10)    Mouser : 160 1 $5.85  25 $5.13  100 $4.75
    LFE5U-25F-6MG285C	24.3K LUTS, 118io $9.23042/168   285-CSFBGA (10x10)    Mouser : 283 1 $12.00 25 $10.55 100 $9.75
    
    
    Eval Boards
    FE5UM-45F-VERSA-EVN	DEV KIT FOR ECP5 VERSA	14 - Immediate $208.77000	
    LFE5UM5G-85F-EVN	ECP5 EVALUATION BOARD	19 - Immediate  $99.99000
    


  • 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.
  • jmgjmg Posts: 15,140
    I'll bump this, as I see an update here
    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 ?

    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.
    
    
Sign In or Register to comment.