Update:
I'm making progress with the Max10 P1V and I have managed to get hub ram back to 32K.
My current configuration is a 3 cog 64IO No Video 32K Hub 4K ROM 4 counters per cog variant.
I'm currently modifying the booter to support the 2Mb x 8 SPI flash (external) to hold spin/pasm code.
I'll post the new files this weekend.
Cheers
Brian
Build stats:
Total logic elements ; 7,150 / 8,064 ( 89 % )
Total combinational functions ; 6,444 / 8,064 ( 80 % )
Dedicated logic registers ; 2,721 / 8,064 ( 34 % )
Total registers ; 2721
Total memory bits ; 344,064 / 387,072 ( 89 % )
This chip family, with the EQFP package option, combined with the P1V will offer those needing just a little more from a P1 a viable option for the future. Thanks to your project we will all have a head start on adding them to our designs.
Now if Altera would just release one of the mid range versions. 10M25 Come on down!
I'm currently modifying the booter to support the 2Mb x 8 SPI flash (external) to hold spin/pasm code.
Is that 4K ROM, initialised RAM (boot) or have you found a way to map the Flash memory, and boot from that ?
The Flash seems to have delays, but does have a Valid flag, which could nicely hook-into the WAIT structure of the Prop.
That design approach should tolerate the variable flash access streams across the MAX10 variants.
I guess a down-side of Flash, is you need to (slower) pgm that with the boot code, but that code should be stable once sorted, so faster RAM download development cycles would be possible ?
Hi Lachlan
No I haven't taken any readings yet, not a bad idea though.
Just got the modified booter running so spin/pasm code loads/runs from BeMicro's M25P16 SPI flash.
Tidying up all my notes and code next and hope to post some more code/docs in the next couple of days.
Cheers
Brian
So after some mucking about this weekend I was able to get the P1V booting from internal MAX10 user flash memory blocks (UFM0/UFM1), and I've modified the booter to enable writing applications to it as well, instead of needing the separate i2c eeprom as you normally would. Ran into plenty of issues with converting file formats, MIF/HEX/binary, 8 bit, 32 bit, endianness, Quartus strangeness etc, but finally sorted it out in the end.
I've made the flash readable/writable from a single COG 0, mapping into an upper memory space at $90000000, and use it at boot time to bring the application into memory. Because it operates 32 bits wide and can run at hub speed for its reads, it's really, really fast to load hub memory from it and also to erase/rewrite this 32kB flash. So overall it takes a tiny fraction of a second to fill memory now (8192 longs to hub in 16384 hub cycles in my loop below), and is even faster if you pull Rx pin low to skip the serial timeout interval during boot. The flashing with PropTool (actually Brad's Spin Tool) is way faster too compared to the regular i2c eeproms. The limiting factor is basically the serial transfer itself as the flashing/verify part only takes about 1 second or so.
It would be nice to open up more of the available flash for other purposes but as Brian found, on the MAX10 if you use FPGA images containing initialized memory regions for ROM you appear to lose access to the extra 140kB of potential flash space and it reduces down to 32kB (which admittedly is still a perfect fit for the prop).
So this is great on the inexpensive MAX 10 board for making a little self contained standalone system that you can flash at will like a regular propeller system. Combined with some of my other previous stuff it works out quite nicely.
Also, by jettisoning the redundant i2c code in the boot code I was also able to free up room in the upper memory to potentially get another entire 1KB memory block back and with some more work this could even be used as RAM instead of ROM. So perhaps it could be useful for creating a more fully featured (i.e. spin) based booter/upgrader interface or maybe some non-intrusive debugging/monitoring code could run from there. Not sure yet but I'm sure there will be some good use for it one day.
I gather you are using the MAX10 on-chip Flash as the EEPROM replacement and can read that directly into the Hub RAM on power up.
Can you address/map the Flash as Hub Flash ???
If so, could you use this as ROM and change the booter code. BTW I have done some modifications to the booter code as well as the Spin Interpreter, so I could perhaps help here.
I gather you are using the MAX10 on-chip Flash as the EEPROM replacement and can read that directly into the Hub RAM on power up.
Can you address/map the Flash as Hub Flash ???
If so, could you use this as ROM and change the booter code. BTW I have done some modifications to the booter code as well as the Spin Interpreter, so I could perhaps help here.
Yes it maps to hub addresses for a COG and it would be possible to use it to boot from and to free up more flash space. That was my next idea to play with in fact. It opens up a few more possibilities too.
Comments
I'm making progress with the Max10 P1V and I have managed to get hub ram back to 32K.
My current configuration is a 3 cog 64IO No Video 32K Hub 4K ROM 4 counters per cog variant.
I'm currently modifying the booter to support the 2Mb x 8 SPI flash (external) to hold spin/pasm code.
I'll post the new files this weekend.
Cheers
Brian
Build stats:
Total logic elements ; 7,150 / 8,064 ( 89 % ) Total combinational functions ; 6,444 / 8,064 ( 80 % ) Dedicated logic registers ; 2,721 / 8,064 ( 34 % ) Total registers ; 2721 Total memory bits ; 344,064 / 387,072 ( 89 % )This chip family, with the EQFP package option, combined with the P1V will offer those needing just a little more from a P1 a viable option for the future. Thanks to your project we will all have a head start on adding them to our designs.
Now if Altera would just release one of the mid range versions. 10M25 Come on down!
Is that 4K ROM, initialised RAM (boot) or have you found a way to map the Flash memory, and boot from that ?
The Flash seems to have delays, but does have a Valid flag, which could nicely hook-into the WAIT structure of the Prop.
That design approach should tolerate the variable flash access streams across the MAX10 variants.
I guess a down-side of Flash, is you need to (slower) pgm that with the boot code, but that code should be stable once sorted, so faster RAM download development cycles would be possible ?
Adding up the memory bits - it seems the ROM is being shadowed in the ram (262144 bits hub + 3*16384 cogs + 4096*8 rom).
You haven't taken any current consumption readings, by any chance have you?
I need to purchase a decent USB A power (voltage & current) meter from somewhere, not the cheap and nasty ones.
No I haven't taken any readings yet, not a bad idea though.
Just got the modified booter running so spin/pasm code loads/runs from BeMicro's M25P16 SPI flash.
Tidying up all my notes and code next and hope to post some more code/docs in the next couple of days.
Cheers
Brian
I've made the flash readable/writable from a single COG 0, mapping into an upper memory space at $90000000, and use it at boot time to bring the application into memory. Because it operates 32 bits wide and can run at hub speed for its reads, it's really, really fast to load hub memory from it and also to erase/rewrite this 32kB flash. So overall it takes a tiny fraction of a second to fill memory now (8192 longs to hub in 16384 hub cycles in my loop below), and is even faster if you pull Rx pin low to skip the serial timeout interval during boot. The flashing with PropTool (actually Brad's Spin Tool) is way faster too compared to the regular i2c eeproms. The limiting factor is basically the serial transfer itself as the flashing/verify part only takes about 1 second or so.
:loop rdlong data, flash add flash, #4 wrlong data, address add address, #4 djnz count, #:loopIt would be nice to open up more of the available flash for other purposes but as Brian found, on the MAX10 if you use FPGA images containing initialized memory regions for ROM you appear to lose access to the extra 140kB of potential flash space and it reduces down to 32kB (which admittedly is still a perfect fit for the prop).So this is great on the inexpensive MAX 10 board for making a little self contained standalone system that you can flash at will like a regular propeller system. Combined with some of my other previous stuff it works out quite nicely.
Also, by jettisoning the redundant i2c code in the boot code I was also able to free up room in the upper memory to potentially get another entire 1KB memory block back and with some more work this could even be used as RAM instead of ROM. So perhaps it could be useful for creating a more fully featured (i.e. spin) based booter/upgrader interface or maybe some non-intrusive debugging/monitoring code could run from there. Not sure yet but I'm sure there will be some good use for it one day.
I haven't been following too closely.
I gather you are using the MAX10 on-chip Flash as the EEPROM replacement and can read that directly into the Hub RAM on power up.
Can you address/map the Flash as Hub Flash ???
If so, could you use this as ROM and change the booter code. BTW I have done some modifications to the booter code as well as the Spin Interpreter, so I could perhaps help here.
Yes it maps to hub addresses for a COG and it would be possible to use it to boot from and to free up more flash space. That was my next idea to play with in fact. It opens up a few more possibilities too.