Even better would be if there was an authoritative P1V github repository that was maintained. I imagine it would keep the basic P1V and all that is required to get it working it on the many different FPGA's and boards that people are using. With the various configurations of number of COGS and amount of RAM available.
I couldn't agree more.
My repository at https://github.com/JacGoudsmit/P1V is far ahead of the original Parallax repo. My "master" branch contains several important improvements such as removal of duplicate source files, and bugfixes that were posted in the forums but not posted in the Parallax repo. I filed a pull request for those changes more than three years ago, see https://github.com/parallaxinc/Propeller_1_Design/pull/1. But apparently no-one at Parallax is even monitoring the repo so I decided to abandon the master branch.
I've made many improvements in my own branches, my main release branch is "rel" (short for "release"). Thanks to submissions from others, the code now supports more hardware including Xilinx. But by default, when you build the "rel" branch, you will get a standard Propeller. I would be happy to integrate improvements by others too if I knew where they were. I know Ariba made several interesting improvements and ported P1V to other platforms too.
I'm considering separating the hub memory module from the logic modules to make it possible to use alternative memory solutions (such as the SDRAM chip on the DE0-Nano which otherwise doesn't have enough RAM available for the font ROM), and I have some other ideas stacked up, but I'm a little thinly spread between hobby projects lately. Nevertheless, I would be happy to put more time into this, if someone at Parallax would ask.
Thanks! I'm finally getting around to trying out P1V.
Just downloaded from your GitHub.
Right now, trying to port to DE10-Lite. I think others have done this already...
I'm starting from the DE2-115 files...
Of course, it would be better if there were a simple, low cost ECP5 board setup you could get from Digikey or something...
Yeah there's a big hole in the market for a low cost Lattice ECP5 board with wide distribution. Ironic given the cost of the devices, though I expect Altera and perhaps Xilinx heavily subsidise their low cost boards, which distorts things
I notice Trenz in Germany does have a low cost ICE board designed to mate to Rasp Pi Zero, but only 4k LEs
Yeah there's a big hole in the market for a low cost Lattice ECP5 board with wide distribution. Ironic given the cost of the devices, though I expect Altera and perhaps Xilinx heavily subsidise their low cost boards, which distorts things
I notice Trenz in Germany does have a low cost ICE board designed to mate to Rasp Pi Zero, but only 4k LEs
No, it's not a subsidy. It is just realistic pricing.
Altera and Xilinx have gigantic discounts if they deem your product worthy, meaning the base price has a humongous markup. This has the effect of restricting their market but they don't seem to care. And it is almost impossible to get a decent quote from them via their distributors, and you cannot get to them direct either.
Saw that mode with Rockwell in the 90's where they sold to Taiwan and China for way less than elsewhere in the world causing the collapse of most other modem manufacturers because we could buy complete boards with the chips for less than we could buy just the modem chipset. Karma came back to bite, and resulted in Rockwell selling off its modem and gps divisions cheaply.
I have some TinyFPGA EX prototypes in 12K, 25K, 45K, and 85K LUT capacities. Anyone interested in getting the prop design up and running on one and sharing the project on GitHub?
By the way, the boards are 4-layers. They have dedicated ground and power planes. A decent 2-layer design would have been impossible. The HyperRAM was chosen to keep costs low while still providing a decent sized RAM at high speed. LPDDR was attempted at first and was extremely difficult to route while still routing signals to the SD card connector and other user IOs at the bottom end of the board. It would have required a 6-layer board.
I post a lot on Twitter, if you want to follow TinyFPGA development my handle is @tinyfpga. I mostly post about what I’m working on with TinyFPGA as well as open source FPGA toolchain development. Otherwise I’m also on Hackaday.io as Luke Valenty.
I have some TinyFPGA EX prototypes in 12K, 25K, 45K, and 85K LUT capacities. Anyone interested in getting the prop design up and running on one and sharing the project on GitHub?
By the way, the boards are 4-layers. They have dedicated ground and power planes. A decent 2-layer design would have been impossible. The HyperRAM was chosen to keep costs low while still providing a decent sized RAM at high speed. LPDDR was attempted at first and was extremely difficult to route while still routing signals to the SD card connector and other user IOs at the bottom end of the board. It would have required a 6-layer board.
I post a lot on Twitter, if you want to follow TinyFPGA development my handle is @tinyfpga. I mostly post about what I’m working on with TinyFPGA as well as open source FPGA toolchain development. Otherwise I’m also on Hackaday.io as Luke Valenty.
The TinyFPGA boards look cool. How much does the 85K LUT unit cost?
It has been significantly refined for the BX and EX boards. It can also be modified to act as a custom USB device for your design. You could implement a USB host as well, but I haven’t tried this.
Welcome, Luke. We were just saying there's a bit of a dearth of official Lattice boards in support of those ECP5 devices. Looks like your boards fit that need nicely.
It has been significantly refined for the BX and EX boards. It can also be modified to act as a custom USB device for your design. You could implement a USB host as well, but I haven’t tried this.
That USB loader is nifty, how much logic fabric does this need ?
I guess boards should always have a means to clip-onto the SPI, for first-program pass, and for should the thing ever be totally bricked ?
That USB loader is nifty, how much logic fabric does this need ?
I guess boards should always have a means to clip-onto the SPI, for first-program pass, and for should the thing ever be totally bricked ?
The USB bootloader uses about 700 LUT4s on the ECP5 FPGAs. It has its own location in the SPI flash separate from the user design.
When the TinyFPGA EX first powers on, the FPGA loads the primary image. In this case, the primary image contains the design for the USB bootloader. The bootloader is really just a USB-SPI bridge with a few extra features.
There’s a Python programmer that can talk to the bootloader and program your design into the user configuration area of the SPI flash. You can optionally program your own user data to SPI flash as well.
After you program your design onto the flash, the bootloader pulls the PROGRAMN pin of the FPGA low causing a soft reset of the FPGA. The bootloader image is configured so that the FPGA will now load image number 2. Image number 2 is the user design.
By default, the USB bootloader doesn’t use any FPGA resources. Of course you can always instantiate the bootloader into your design if you want.
The button on the board also pulls PROGRAMN low. Pressing the button toggles the FPGA between the bootloader and the user design.
The bottom of the board has some test points for JTAG, SPI flash, and a few other nets specific to functional testing of the boards. I use those test points to load the bootloader onto the flash and test the board functionality.
Corrupting the bootloader should be rare. The programmer will prevent you from accidentally writing to the bootloader area. If it does happen, you can use the test points on the bottom.
I'm very interested to get the P1V to work on your board. I would need a version with a 25k LUT FPGA for a full 8 cog Propeller.
I already have working code for the FleaOhm board, so it should not be too much work.
What concerns me a bit about your USB solution is that you always need to write to the Flash to try out a new version of the code. But I have also a Lattice JTAG adapter that I can connect to the pads on the TinyFPGA Ex board if necessary.
Corrupting the bootloader should be rare. The programmer will prevent you from accidentally writing to the bootloader area. If it does happen, you can use the test points on the bottom.
Should that happen, can one TinyFPGA board be used to recover another TinyFPGA board ?
I guess there is also a USB loader firmware update pathway, of the *do not remove power* kind
Welcome, Luke. We were just saying there's a bit of a dearth of official Lattice boards in support of those ECP5 devices. Looks like your boards fit that need nicely.
Thanks Tubular
My goal with the boards I’ve developed so far is low-cost and small size. I would like to introduce more makers and hobbyists to FPGAs using these boards.
Your board sounds interesting Luke. I wonder if it could be extended to support a USB - serial bridge to emulate some VCP capable USB device on a host PC. If that were possible, then FPGA updates could potentially be managed by some custom propeller boot software itself. Though that does bring about the issue of the initial load/corruption problems I guess unless the whole dual image boot process is followed the same way you do it.
While I sort of like the idea of not needing the extra JTAG programmer stuff, I think I'd probably need one eventually by doing something wrong somewhere in the flash.
Your board sounds interesting Luke. I wonder if it could be extended to support a USB - serial bridge to emulate some VCP capable USB device on a host PC...
The commonly used FT2232H parts can manage VCP and JTAG/SPI - but they are large and expensive.
There is a FT4222H that looks appealing, with HS-USB, but is SPI and i2c, no UART. Attraction is smaller than FT2232H in 32vfqn, and cheaper at $1.48/3k
In FS-USB speeds, there is new EFM8UB3, 40k of code in a 3x3 qfn20 package, for 93c/1k, and it could manage any mix of UART/SPI/JTAG/i2c
Your board sounds interesting Luke. I wonder if it could be extended to support a USB - serial bridge to emulate some VCP capable USB device on a host PC. If that were possible, then FPGA updates could potentially be managed by some custom propeller boot software itself. Though that does bring about the issue of the initial load/corruption problems I guess unless the whole dual image boot process is followed the same way you do it.
While I sort of like the idea of not needing the extra JTAG programmer stuff, I think I'd probably need one eventually by doing something wrong somewhere in the flash.
The USB bootloader is very modular. You could re-use it to implement any other type of USB device.
As for the SPI flash getting corrupted, the bootloader is stored in its own location on the flash. I could even write-protect it to help ensure it cannot be accidentally overwritten, erased, or corrupted.
The ECP5 FPGAs have significant CRC checking on their bitstreams. There are additional options I can use so that the FPGA will automatically load a “golden” bootloader image that is written once and write-protected. This golden image would only be used if loading of the regular bootloader fails due to corruption.
That being said, if you like getting into the nitty-gritty details of the FPGA and having complete control over it, the JTAG interface is always available.
The JTAG pads are the four test points in a row just above the “TinyFPGA EX” text.
I'm very interested to get the P1V to work on your board. I would need a version with a 25k LUT FPGA for a full 8 cog Propeller.
I already have working code for the FleaOhm board, so it should not be too much work.
What concerns me a bit about your USB solution is that you always need to write to the Flash to try out a new version of the code. But I have also a Lattice JTAG adapter that I can connect to the pads on the TinyFPGA Ex board if necessary.
Andy
Programming the SPI flash for the 25k part is pretty fast, no more than 7 seconds. If you compress the bitstream it’s even faster depending on the size of your design and blockram initialization.
The SPI flash chip is NOR flash and has significantly higher endurance than what we find in consumer devices with NAND. The minimum program-erase cycles of the flash I’m using is 100,000 cycles with a minimum retention of 25 years.
Send me a DM if you want to implement the P1V design on a 25K part I can send a prototype to you.
Your board sounds interesting Luke. I wonder if it could be extended to support a USB - serial bridge to emulate some VCP capable USB device on a host PC...
The commonly used FT2232H parts can manage VCP and JTAG/SPI - but they are large and expensive.
There is a FT4222H that looks appealing, with HS-USB, but is SPI and i2c, no UART. Attraction is smaller than FT2232H in 32vfqn, and cheaper at $1.48/3k
Valentin's Flea board uses the FT230X which is quite small and reasonably cheap (similar to the FT4222 prices) and can do double duty as a backup JTAG programmer (bit-bang) with a utility. SRAM download in ~15s, flash in ~5mins without a USB hub. Great support for VCP and that's ideal for propeller serial interface anyway so I think that is a pretty good compromise on cost/versatility. Only downside is that is breaks out RTS instead of DTR reset but I've found that can be managed too. Having the ability to re-init the board from the user logic is nice though, and that's one thing the FleaFPGA Ohm board doesn't support. If it did you'd have a fully field upgradable P1V without necessarily needing to re-power it. Though if you do re-power I guess his board is still essentially field-upgradable too via a flash image download of some variety.
Corrupting the bootloader should be rare. The programmer will prevent you from accidentally writing to the bootloader area. If it does happen, you can use the test points on the bottom.
Should that happen, can one TinyFPGA board be used to recover another TinyFPGA board ?
I guess there is also a USB loader firmware update pathway, of the *do not remove power* kind
It would be easier to just use a FTDI programming cable and reprogram the SPI flash the old-fashioned way.
Currently the only time you could corrupt the firmware is if you are bypassing the regular programming tool and attempting to either erase the entire SPI flash, or modify the bootloader in the SPI flash.
Programming a user design onto the board using the bootloader will not corrupt the bootloader, even if the board is disconnected part-way through.
The USB bootloader is very modular. You could re-use it to implement any other type of USB device.
...
That being said, if you like getting into the nitty-gritty details of the FPGA and having complete control over it, the JTAG interface is always available.
The JTAG pads are the four test points in a row just above the “TinyFPGA EX” text.
It's really good you added that JTAG in. I think for a Propeller it would make sense to get USB to serial in there anyway, certainly in the P1V image, otherwise you'd need another USB-serial (propplug) to download P1V code.
Programming the SPI flash for the 25k part is pretty fast, no more than 7 seconds. If you compress the bitstream it’s even faster depending on the size of your design and blockram initialization.
The SPI flash chip is NOR flash and has significantly higher endurance than what we find in consumer devices with NAND. The minimum program-erase cycles of the flash I’m using is 100,000 cycles with a minimum retention of 25 years.
This is good to know as we can also write into this flash from the Propeller at these high speeds and potentially upgrade FPGA images on the Flea board much faster than the aforementioned utility supports. Although if it is a corrupted one it would then need to be re-done over JTAG, but that's a given anyway with this board because it only supports a single image. Your own board has plenty enough flash fitted for dual images which can be handy too.
Your board sounds interesting Luke. I wonder if it could be extended to support a USB - serial bridge to emulate some VCP capable USB device on a host PC...
The commonly used FT2232H parts can manage VCP and JTAG/SPI - but they are large and expensive.
There is a FT4222H that looks appealing, with HS-USB, but is SPI and i2c, no UART. Attraction is smaller than FT2232H in 32vfqn, and cheaper at $1.48/3k
Valentin's Flea board uses the FT230X which is quite small and reasonably cheap (similar to the FT4222 prices) and can do double duty as a backup JTAG programmer (bit-bang) with a utility. SRAM download in ~15s, flash in ~5mins without a USB hub. Great support for VCP and that's ideal for propeller serial interface anyway so I think that is a pretty good compromise on cost/versatility. Only downside is that is breaks out RTS instead of DTR reset but I've found that can be managed too. Having the ability to re-init the board from the user logic is nice though, and that's one thing the FleaFPGA Ohm board doesn't support. If it did you'd have a fully field upgradable P1V without necessarily needing to re-power it. Though if you do re-power I guess his board is still essentially field-upgradable too via a flash image download of some variety.
Hmm, I’m surprised at the speed of the FT230X. The USB bootloader can program the SPI flash faster (7 seconds) than the FT230X can program the SRAM (15 seconds)! I think this lower speed is due to the chip having to bit-bang JTAG.
Even a full uncompressed 2 megabyte image for the 85K ECP5 part takes 27 seconds to flash with the bootloader. I think I understand why there was a concern with the bootloader only being able to program the flash.
I don’t mean to knock on the FleaFPGA Ohm boards, I think they aren’t pretty awesome and a super good price.
Hmm, I’m surprised at the speed of the FT230X. The USB bootloader can program the SPI flash faster (7 seconds) than the FT230X can program the SRAM (15 seconds)! I think this lower speed is due to the chip having to bit-bang JTAG.
...
Yeah all the bit-bang slows it down quite a bit. The documentation says that flashing can be reduced to 40seconds if you use a USB hub in the path. Haven't tried it myself so I suffer the 5mins - but I can at least test things out in RAM too which is thankfully a bit faster turnaround.
... otherwise you'd need another USB-serial (propplug) to download P1V code.
I'm not following - do you mean for RAM image loading, rather than P1V booting from SPI ?
For P1V booting from SPI, it is ok to just use the USB-SPI_FLASH pathway.
I guess here it could help if the PC Side code, could toggle the P1V reset pin, when done, so the P1V can boot from SPI - is that possible ?
I can see that USB-Serial is useful for debug/messages, but I think the SPI pathway is ok for download.
... otherwise you'd need another USB-serial (propplug) to download P1V code.
I'm not following - do you mean for RAM image loading, rather than P1V booting from SPI ?
For P1V booting from SPI, it is ok to just use the USB-SPI_FLASH pathway.
I guess here it could help if the PC Side code, could toggle the P1V reset pin, when done, so the P1V can boot from SPI - is that possible ?
I can see that USB-Serial is useful for debug/messages, but I think the SPI pathway is ok for download.
I mean loading normal P1V Propeller code into either RAM or SPI flash (as EEPROM replacement), outside FPGA development itself. For that to work with PropTools you are probably going to want to incorporate a serial port of some variety. Ideally on this board with that USB port already fitted, to avoid another cable etc, the USB port itself could host a serial port over USB (VCP), and the prop sees the USB as P30/P31 along with some reset pathway to emulate DTR I guess.
Also once that serial port piece is done then in theory with this same USB serial interface you could use some custom Propeller boot code to support a new FPGA image download/upgrade capability too (there's still quite a bit of room left in the boot ROM), assuming there is some initial way to get Propeller code in there for the first time (via JTAG header pins I guess). You may not even need a separate bootloader FPGA image (aka golden master), though having that is definitely safer and becomes a fallback if something gets corrupted or whenever your P1V image breaks which would otherwise stop further downloads without using JTAG again.
I mean loading normal P1V Propeller code into either RAM or SPI flash (as EEPROM replacement), outside FPGA development itself. For that to work with PropTools you are probably going to want to incorporate a serial port of some variety. Ideally on this board with that USB port already fitted, to avoid another cable etc, the USB port itself could host a serial port over USB (VCP), and the prop sees the USB as P30/P31 along with some reset pathway to emulate DTR I guess.
Also once that serial port piece is done then in theory with this same USB serial interface you could use some custom Propeller boot code to support a new FPGA image download/upgrade capability too (there's still quite a bit of room left in the boot ROM), assuming there is some initial way to get Propeller code in there for the first time (via JTAG header pins I guess). You may not even need a separate bootloader FPGA image (aka golden master), though having that is definitely safer and becomes a fallback if something gets corrupted or whenever your P1V image breaks which would otherwise stop further downloads without using JTAG again.
The bootloader will always be present in the SPI flash to load onto the FPGA by pressing the program/reset button. You can load the initial propellor code onto the SPI flash using the programmer and bootloader I provide.
Your user design could also incorporate the USB serial device as a prop peripheral. And you could develop a propellor bootloader that is compatible with the prop tools.
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.
If programming an uncompessed FPGA image takes only 7 seconds then I have no longer concerns about the missing access to the SRAM cells. I hope I will not need 100'000 tries to make it work.
Will send you a PM soon.
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.
If programming an uncompessed FPGA image takes only 7 seconds then I have no longer concerns about the missing access to the SRAM cells. I hope I will not need 100'000 tries to make it work.
Will send you a PM soon.
Andy
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.
Comments
I second that motion!
I couldn't agree more.
My repository at https://github.com/JacGoudsmit/P1V is far ahead of the original Parallax repo. My "master" branch contains several important improvements such as removal of duplicate source files, and bugfixes that were posted in the forums but not posted in the Parallax repo. I filed a pull request for those changes more than three years ago, see https://github.com/parallaxinc/Propeller_1_Design/pull/1. But apparently no-one at Parallax is even monitoring the repo so I decided to abandon the master branch.
I've made many improvements in my own branches, my main release branch is "rel" (short for "release"). Thanks to submissions from others, the code now supports more hardware including Xilinx. But by default, when you build the "rel" branch, you will get a standard Propeller. I would be happy to integrate improvements by others too if I knew where they were. I know Ariba made several interesting improvements and ported P1V to other platforms too.
I'm considering separating the hub memory module from the logic modules to make it possible to use alternative memory solutions (such as the SDRAM chip on the DE0-Nano which otherwise doesn't have enough RAM available for the font ROM), and I have some other ideas stacked up, but I'm a little thinly spread between hobby projects lately. Nevertheless, I would be happy to put more time into this, if someone at Parallax would ask.
===Jac
Just downloaded from your GitHub.
Right now, trying to port to DE10-Lite. I think others have done this already...
I'm starting from the DE2-115 files...
Of course, it would be better if there were a simple, low cost ECP5 board setup you could get from Digikey or something...
I notice Trenz in Germany does have a low cost ICE board designed to mate to Rasp Pi Zero, but only 4k LEs
Altera and Xilinx have gigantic discounts if they deem your product worthy, meaning the base price has a humongous markup. This has the effect of restricting their market but they don't seem to care. And it is almost impossible to get a decent quote from them via their distributors, and you cannot get to them direct either.
Saw that mode with Rockwell in the 90's where they sold to Taiwan and China for way less than elsewhere in the world causing the collapse of most other modem manufacturers because we could buy complete boards with the chips for less than we could buy just the modem chipset. Karma came back to bite, and resulted in Rockwell selling off its modem and gps divisions cheaply.
By the way, the boards are 4-layers. They have dedicated ground and power planes. A decent 2-layer design would have been impossible. The HyperRAM was chosen to keep costs low while still providing a decent sized RAM at high speed. LPDDR was attempted at first and was extremely difficult to route while still routing signals to the SD card connector and other user IOs at the bottom end of the board. It would have required a 6-layer board.
I post a lot on Twitter, if you want to follow TinyFPGA development my handle is @tinyfpga. I mostly post about what I’m working on with TinyFPGA as well as open source FPGA toolchain development. Otherwise I’m also on Hackaday.io as Luke Valenty.
It has been significantly refined for the BX and EX boards. It can also be modified to act as a custom USB device for your design. You could implement a USB host as well, but I haven’t tried this.
That USB loader is nifty, how much logic fabric does this need ?
I guess boards should always have a means to clip-onto the SPI, for first-program pass, and for should the thing ever be totally bricked ?
The USB bootloader uses about 700 LUT4s on the ECP5 FPGAs. It has its own location in the SPI flash separate from the user design.
When the TinyFPGA EX first powers on, the FPGA loads the primary image. In this case, the primary image contains the design for the USB bootloader. The bootloader is really just a USB-SPI bridge with a few extra features.
There’s a Python programmer that can talk to the bootloader and program your design into the user configuration area of the SPI flash. You can optionally program your own user data to SPI flash as well.
After you program your design onto the flash, the bootloader pulls the PROGRAMN pin of the FPGA low causing a soft reset of the FPGA. The bootloader image is configured so that the FPGA will now load image number 2. Image number 2 is the user design.
By default, the USB bootloader doesn’t use any FPGA resources. Of course you can always instantiate the bootloader into your design if you want.
The button on the board also pulls PROGRAMN low. Pressing the button toggles the FPGA between the bootloader and the user design.
The bottom of the board has some test points for JTAG, SPI flash, and a few other nets specific to functional testing of the boards. I use those test points to load the bootloader onto the flash and test the board functionality.
Corrupting the bootloader should be rare. The programmer will prevent you from accidentally writing to the bootloader area. If it does happen, you can use the test points on the bottom.
I'm very interested to get the P1V to work on your board. I would need a version with a 25k LUT FPGA for a full 8 cog Propeller.
I already have working code for the FleaOhm board, so it should not be too much work.
What concerns me a bit about your USB solution is that you always need to write to the Flash to try out a new version of the code. But I have also a Lattice JTAG adapter that I can connect to the pads on the TinyFPGA Ex board if necessary.
Andy
I guess there is also a USB loader firmware update pathway, of the *do not remove power* kind
Thanks Tubular
My goal with the boards I’ve developed so far is low-cost and small size. I would like to introduce more makers and hobbyists to FPGAs using these boards.
While I sort of like the idea of not needing the extra JTAG programmer stuff, I think I'd probably need one eventually by doing something wrong somewhere in the flash.
The commonly used FT2232H parts can manage VCP and JTAG/SPI - but they are large and expensive.
There is a FT4222H that looks appealing, with HS-USB, but is SPI and i2c, no UART. Attraction is smaller than FT2232H in 32vfqn, and cheaper at $1.48/3k
In FS-USB speeds, there is new EFM8UB3, 40k of code in a 3x3 qfn20 package, for 93c/1k, and it could manage any mix of UART/SPI/JTAG/i2c
The USB bootloader is very modular. You could re-use it to implement any other type of USB device.
As for the SPI flash getting corrupted, the bootloader is stored in its own location on the flash. I could even write-protect it to help ensure it cannot be accidentally overwritten, erased, or corrupted.
The ECP5 FPGAs have significant CRC checking on their bitstreams. There are additional options I can use so that the FPGA will automatically load a “golden” bootloader image that is written once and write-protected. This golden image would only be used if loading of the regular bootloader fails due to corruption.
That being said, if you like getting into the nitty-gritty details of the FPGA and having complete control over it, the JTAG interface is always available.
The JTAG pads are the four test points in a row just above the “TinyFPGA EX” text.
Programming the SPI flash for the 25k part is pretty fast, no more than 7 seconds. If you compress the bitstream it’s even faster depending on the size of your design and blockram initialization.
The SPI flash chip is NOR flash and has significantly higher endurance than what we find in consumer devices with NAND. The minimum program-erase cycles of the flash I’m using is 100,000 cycles with a minimum retention of 25 years.
Send me a DM if you want to implement the P1V design on a 25K part I can send a prototype to you.
Valentin's Flea board uses the FT230X which is quite small and reasonably cheap (similar to the FT4222 prices) and can do double duty as a backup JTAG programmer (bit-bang) with a utility. SRAM download in ~15s, flash in ~5mins without a USB hub. Great support for VCP and that's ideal for propeller serial interface anyway so I think that is a pretty good compromise on cost/versatility. Only downside is that is breaks out RTS instead of DTR reset but I've found that can be managed too. Having the ability to re-init the board from the user logic is nice though, and that's one thing the FleaFPGA Ohm board doesn't support. If it did you'd have a fully field upgradable P1V without necessarily needing to re-power it. Though if you do re-power I guess his board is still essentially field-upgradable too via a flash image download of some variety.
It would be easier to just use a FTDI programming cable and reprogram the SPI flash the old-fashioned way.
Currently the only time you could corrupt the firmware is if you are bypassing the regular programming tool and attempting to either erase the entire SPI flash, or modify the bootloader in the SPI flash.
Programming a user design onto the board using the bootloader will not corrupt the bootloader, even if the board is disconnected part-way through.
It's really good you added that JTAG in. I think for a Propeller it would make sense to get USB to serial in there anyway, certainly in the P1V image, otherwise you'd need another USB-serial (propplug) to download P1V code.
This is good to know as we can also write into this flash from the Propeller at these high speeds and potentially upgrade FPGA images on the Flea board much faster than the aforementioned utility supports. Although if it is a corrupted one it would then need to be re-done over JTAG, but that's a given anyway with this board because it only supports a single image. Your own board has plenty enough flash fitted for dual images which can be handy too.
Hmm, I’m surprised at the speed of the FT230X. The USB bootloader can program the SPI flash faster (7 seconds) than the FT230X can program the SRAM (15 seconds)! I think this lower speed is due to the chip having to bit-bang JTAG.
Even a full uncompressed 2 megabyte image for the 85K ECP5 part takes 27 seconds to flash with the bootloader. I think I understand why there was a concern with the bootloader only being able to program the flash.
I don’t mean to knock on the FleaFPGA Ohm boards, I think they aren’t pretty awesome and a super good price.
Yeah all the bit-bang slows it down quite a bit. The documentation says that flashing can be reduced to 40seconds if you use a USB hub in the path. Haven't tried it myself so I suffer the 5mins - but I can at least test things out in RAM too which is thankfully a bit faster turnaround.
For P1V booting from SPI, it is ok to just use the USB-SPI_FLASH pathway.
I guess here it could help if the PC Side code, could toggle the P1V reset pin, when done, so the P1V can boot from SPI - is that possible ?
I can see that USB-Serial is useful for debug/messages, but I think the SPI pathway is ok for download.
What would be the time to program the 32k Prop code image ?
I mean loading normal P1V Propeller code into either RAM or SPI flash (as EEPROM replacement), outside FPGA development itself. For that to work with PropTools you are probably going to want to incorporate a serial port of some variety. Ideally on this board with that USB port already fitted, to avoid another cable etc, the USB port itself could host a serial port over USB (VCP), and the prop sees the USB as P30/P31 along with some reset pathway to emulate DTR I guess.
Also once that serial port piece is done then in theory with this same USB serial interface you could use some custom Propeller boot code to support a new FPGA image download/upgrade capability too (there's still quite a bit of room left in the boot ROM), assuming there is some initial way to get Propeller code in there for the first time (via JTAG header pins I guess). You may not even need a separate bootloader FPGA image (aka golden master), though having that is definitely safer and becomes a fallback if something gets corrupted or whenever your P1V image breaks which would otherwise stop further downloads without using JTAG again.
About a second.
The bootloader will always be present in the SPI flash to load onto the FPGA by pressing the program/reset button. You can load the initial propellor code onto the SPI flash using the programmer and bootloader I provide.
Your user design could also incorporate the USB serial device as a prop peripheral. And you could develop a propellor bootloader that is compatible with the prop tools.
If programming an uncompessed FPGA image takes only 7 seconds then I have no longer concerns about the missing access to the SRAM cells. I hope I will not need 100'000 tries to make it work.
Will send you a PM soon.
Andy
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.