Yes, we need to get SERDES defined and then we'll be able to figure the countdown to real chips. It would be good to get some testing time in, as well.
Is SERDES going to operate on a single pin only? Or, maybe a differential pair?
Might be interesting if it could do nibble on 4 pins or byte on 8 pins...
Is SERDES going to operate on a single pin only? Or, maybe a differential pair?
Might be interesting if it could do nibble on 4 pins or byte on 8 pins...
I'm pretty sure QuadSPI is quite high up the list, IIRC Chip said the main issue was mapping the pins.
Pushing the QuadSPI as a higher-priority, are new parts like the just announced FTDI FT900, which is from $3.90/10k, and has 480MBd USB, Ethernet(+PHY), 10ns CPU, 256K code, 64K data, USB DFU Bootloader, and says SPI master supports single/dual/quad modes
Pushing the QuadSPI as a higher-priority, are new parts like the just announced FTDI FT900, which is from $3.90/10k, and has 480MBd USB, Ethernet(+PHY), 10ns CPU, 256K code, 64K data, USB DFU Bootloader, and says SPI master supports single/dual/quad modes
I didn't wanted to be the first to mention that new IC, but because it have arised I want to comment two ideas:
1) It has been only an announcement. The IC is not available yet. I hope the finally make what they announced, but we don't know. I remember that also lattice made on sep 2013 the announcement of a gigabit hard IP machXO3 FPGA with 22K LUTs and a lot of features but 5 months later they forgot every improvement over machXO2 and released a crippled MachXO2 with only 2 times reprogramable memory. (There is a thread in this forum explaining this)
2) It would be a competitor to P2. It doesn't have a multicore as P2 or XMOS, but they follow the "easy of use" idea. Don't know if this changes any plan or schedule with P2, or if it has even been considered by Parallax.
2) It would be a competitor to P2. It doesn't have a multicore as P2 or XMOS, but they follow the "easy of use" idea. Don't know if this changes any plan or schedule with P2, or if it has even been considered by Parallax.
I'm not sure it is too directly a competitor - but it certainly does set buyers expectations, which is why I mentioned it.
I should have added, as well as QuadSPI, it also has I²S master/slave interface (24.57/22.57 MHz)
With Dual HighSpeed USB, the FT900 goes into spaces the P2 cannot, and I could imagine designs using both devices.
The FT900 looks a pretty impressive universal serial bridge, at a price not much above FT2232H.
ie anyone who was going to bolt-on a HighSpeed USB chip anyway, can now also look at the FT900.
Their FT51 is also a P2 companion candidate, as it looks to land in the USB-UART space at $1.46/10k, but much more flexible.
That's slightly above the price of the overlapping SiLabs C8051F38C
What's the status of C/C++ for Prop2? Anything working yet?
Ray,
There was a working version shortly after the first emulation release. Then the instruction set started going through so much churn and feature addition that it was hard to keep up. Now, from what David said, since it has settled, work can begin again. I don't think anyone has mentioned time frames, though.
I think I remember that it could compile for cog mode only... But, now with hubexec, you'd think that cog mode could be pretty big...
It would be really, really nice to have PropGCC working with hubexec mode...
I think I remember that it could compile for cog mode only... But, now with hubexec, you'd think that cog mode could be pretty big...
It would be really, really nice to have PropGCC working with hubexec mode...
PropGCC for P2 worked in COG, LMM, and CMM modes. I never implemented XMM model. I'd like to dive into this again immediately but unfortunately I'm now in a mode with my day job where I have to spend Tuesday-Friday in Philadelphia. I don't really want to lug the DE2-115 board back and forth so I have to work on P2 GCC on the weekends. In any case, my first task is to get binutils ported which mostly means GAS.
In any case, my first task is to get binutils ported which mostly means GAS.
I have zero experience doing assembler porting and also don't have free time. Anyway, how can we help you? What version (from ftp://sourceware.org/pub/binutils/snapshots) will you port?
I have zero experience doing assembler porting and also don't have free time. Anyway, how can we help you? What version (from ftp://sourceware.org/pub/binutils/snapshots) will you port?
No, I'll just use the same code we have in the current P1 PropGCC Google Code repository. Most of the parsing of P2 instructions is already there from the first time I did the port. I just have to enter all of the new instruction encodings. The harder part (but also more fun) will be modifying the code generator to use the new hub execution mode.
Chip,
In the latest code, IIRC we have a 4 deep (18bit) LIFO for each of the 4 possible tasks. Is this correct?
Might it be possible to chain these to give a 16 deep LIFO when multitasking is not used? Perhaps it could be the default mode until a SETTASK is executed?
I have just found how useful and simple it is to use the CALL/RET instructions without any setup being required. But 4 deep is not very big and currently I am not multitasking.
Chip,
In the latest code, IIRC we have a 4 deep (18bit) LIFO for each of the 4 possible tasks. Is this correct?
Might it be possible to chain these to give a 16 deep LIFO when multitasking is not used? Perhaps it could be the default mode until a SETTASK is executed?
I have just found how useful and simple it is to use the CALL/RET instructions without any setup being required. But 4 deep is not very big and currently I am not multitasking.
Chip
I'm currently chasing a intermittent bug in Nano Invaders which I now believe is a LIFO stack overflow.
Is it possible to include a new instruction to check the LIFO status for this scenario.
e.g CHKLIFO WC,WZ returns C=1 if stack overflow, Z=1 if stack underflow. (resets both flags after execution)
A four deep stack has caught me out a couple of times. A configurable LIFO is an interesting idea Ray
Chip
I'm currently chasing a intermittent bug in Nano Invaders which I now believe is a LIFO stack overflow.
Is it possible to include a new instruction to check the LIFO status for this scenario.
e.g CHKLIFO WC,WZ returns C=1 if stack overflow, Z=1 if stack underflow. (resets both flags after execution)
A four deep stack has caught me out a couple of times. A configurable LIFO is an interesting idea Ray
Cheers
Brian
Brian,
Because it is just a 4 deep LIFO, and it wraps, probably you just want to know its current depth which could be returned as 2 bits (in C & Z or written to a destination register).
What I thought is that by chaining the 4 x 4 LIFOs would give a 16 deep LIFO. I would think this just requires the counter to be able to be 2 or 4 bits for task#0, and gates/multiplexors to chain the 4 sets of LIFOs together. I guess a lot depends on how the LIFOs have been constructed.
Agreed. If it's not tough, having the extra depth in single task mode would be worth it, as would the overflow flag.
These LIFO stacks don't have pointers. They are built from flops that load from the lower level on a push or from the higher level on a pop.
I'll think about how to divide them among tasks. Four levels is adequate for cog execution, but not enough for hub execution. Maybe they should be given 8 levels per task.
A lot depends on the space the LIFOs take up. If they could be chained together if tasks don't require them (ie not multitasking) then we get extra usage from them. Is this possible and does it take much silicon?
Maybe I shouldn't be so lazy, and just use PTRX/Y.
Maybe I shouldn't be so lazy, and just use PTRX/Y.
This made me laugh out loud!
<Patton voice>
All these new features and instructions are making us soft! We're assemmbler programmers, men! Don't sit around feeling sorry for yourself, point to your AUXRAM and feel sorry for the P1 programmer that doesn't have any stack! Now, get out there and write some code before I have to slap you!!
</Patton voice>
PropGCC for P2 worked in COG, LMM, and CMM modes. I never implemented XMM model. I'd like to dive into this again immediately but unfortunately I'm now in a mode with my day job where I have to spend Tuesday-Friday in Philadelphia. I don't really want to lug the DE2-115 board back and forth so I have to work on P2 GCC on the weekends. In any case, my first task is to get binutils ported which mostly means GAS.
Why would one want to use cog execution mode when hub execution mode is available?
Only thing obvious to me is that cog mode code can't be corrupted by other cogs...
Why would one want to use cog execution mode when hub execution mode is available?
Only thing obvious to me is that cog mode code can't be corrupted by other cogs...
Because the P1 isn't going away and PropGCC needs to be able to handle both architectures.
So many people seem to be seeing a P1 or P2 world instead of a P1 AND P2 world. The tools need to be able to handle both chips equally and seamlessly as much as possible. While Spin and Spin2 will have different features, I sure don't want to have a Spin development tool and a Spin2 development tool. PropGCC isn't going to have a flavor for each, P1GCC and P2GCC (at least I hope not). Anything done to include the features needed to support P2 can't be done by excluding the P1 it's not going away.
The Spin debate is headed the same way - "You can't do that for Spin2 because then Spin won't work!" - well if somebody is foolish enough to let that happen, then they shouldn't be here. Spin is Spin - there just need to be features and enhancements for Spin2 and P2 added capabilities....nobody says you have to use them and if the tools make you use them or exclude the P1, then somebody made a BIG mistake.
I play with software a lot and that will probably move more and more toward the P2 but when I do hardware stuff, I'll probably use the P1 more unless I really need a P2 feature. I'd rather smoke an $8 dip than a $15-$20 little surface mount bugger on a minimum development board that cost me $50, thank you very much! If the application doesn't need the P2, why use it? Sometimes it's better to dance with the horse that brung ya!
Cog mode is still faster and more/easier deterministic. It depends on what is being done. Hubexec requires a bitmore thought and care.
Remember we have a small cache for hub instructions, and hub data access will stall cache loads.
Comments
Might be interesting if it could do nibble on 4 pins or byte on 8 pins...
I'm pretty sure QuadSPI is quite high up the list, IIRC Chip said the main issue was mapping the pins.
Pushing the QuadSPI as a higher-priority, are new parts like the just announced FTDI FT900, which is from $3.90/10k, and has 480MBd USB, Ethernet(+PHY), 10ns CPU, 256K code, 64K data, USB DFU Bootloader, and says SPI master supports single/dual/quad modes
I didn't wanted to be the first to mention that new IC, but because it have arised I want to comment two ideas:
1) It has been only an announcement. The IC is not available yet. I hope the finally make what they announced, but we don't know. I remember that also lattice made on sep 2013 the announcement of a gigabit hard IP machXO3 FPGA with 22K LUTs and a lot of features but 5 months later they forgot every improvement over machXO2 and released a crippled MachXO2 with only 2 times reprogramable memory. (There is a thread in this forum explaining this)
2) It would be a competitor to P2. It doesn't have a multicore as P2 or XMOS, but they follow the "easy of use" idea. Don't know if this changes any plan or schedule with P2, or if it has even been considered by Parallax.
I'm not sure it is too directly a competitor - but it certainly does set buyers expectations, which is why I mentioned it.
I should have added, as well as QuadSPI, it also has I²S master/slave interface (24.57/22.57 MHz)
With Dual HighSpeed USB, the FT900 goes into spaces the P2 cannot, and I could imagine designs using both devices.
The FT900 looks a pretty impressive universal serial bridge, at a price not much above FT2232H.
ie anyone who was going to bolt-on a HighSpeed USB chip anyway, can now also look at the FT900.
Their FT51 is also a P2 companion candidate, as it looks to land in the USB-UART space at $1.46/10k, but much more flexible.
That's slightly above the price of the overlapping SiLabs C8051F38C
There was a working version shortly after the first emulation release. Then the instruction set started going through so much churn and feature addition that it was hard to keep up. Now, from what David said, since it has settled, work can begin again. I don't think anyone has mentioned time frames, though.
It would be really, really nice to have PropGCC working with hubexec mode...
In any case, HUBEX and the specific instructions needed should make C really sing on this chip, no LMM needed.
I have zero experience doing assembler porting and also don't have free time. Anyway, how can we help you? What version (from ftp://sourceware.org/pub/binutils/snapshots) will you port?
In the latest code, IIRC we have a 4 deep (18bit) LIFO for each of the 4 possible tasks. Is this correct?
Might it be possible to chain these to give a 16 deep LIFO when multitasking is not used? Perhaps it could be the default mode until a SETTASK is executed?
I have just found how useful and simple it is to use the CALL/RET instructions without any setup being required. But 4 deep is not very big and currently I am not multitasking.
Chip
I'm currently chasing a intermittent bug in Nano Invaders which I now believe is a LIFO stack overflow.
Is it possible to include a new instruction to check the LIFO status for this scenario.
e.g CHKLIFO WC,WZ returns C=1 if stack overflow, Z=1 if stack underflow. (resets both flags after execution)
A four deep stack has caught me out a couple of times. A configurable LIFO is an interesting idea Ray
Cheers
Brian
Because it is just a 4 deep LIFO, and it wraps, probably you just want to know its current depth which could be returned as 2 bits (in C & Z or written to a destination register).
What I thought is that by chaining the 4 x 4 LIFOs would give a 16 deep LIFO. I would think this just requires the counter to be able to be 2 or 4 bits for task#0, and gates/multiplexors to chain the 4 sets of LIFOs together. I guess a lot depends on how the LIFOs have been constructed.
These LIFO stacks don't have pointers. They are built from flops that load from the lower level on a push or from the higher level on a pop.
I'll think about how to divide them among tasks. Four levels is adequate for cog execution, but not enough for hub execution. Maybe they should be given 8 levels per task.
Maybe I shouldn't be so lazy, and just use PTRX/Y.
This made me laugh out loud!
<Patton voice>
All these new features and instructions are making us soft! We're assemmbler programmers, men! Don't sit around feeling sorry for yourself, point to your AUXRAM and feel sorry for the P1 programmer that doesn't have any stack! Now, get out there and write some code before I have to slap you!!
</Patton voice>
Where is your latest Debug code? I thought I would give it a whirl.
Here is the current release
P2 Test Toolbox
I'm just testing another update right now. Hopefully I can post it tomorrow.
Cheers
Brian
Hub execution will become the norm for the P2. Cog execution will be used only by a few crusty old forumistas who fondly remember the P1 :
Ross.
No, of course not. Just that fewer people will use it.
Ross.
Only thing obvious to me is that cog mode code can't be corrupted by other cogs...
Because the P1 isn't going away and PropGCC needs to be able to handle both architectures.
So many people seem to be seeing a P1 or P2 world instead of a P1 AND P2 world. The tools need to be able to handle both chips equally and seamlessly as much as possible. While Spin and Spin2 will have different features, I sure don't want to have a Spin development tool and a Spin2 development tool. PropGCC isn't going to have a flavor for each, P1GCC and P2GCC (at least I hope not). Anything done to include the features needed to support P2 can't be done by excluding the P1 it's not going away.
The Spin debate is headed the same way - "You can't do that for Spin2 because then Spin won't work!" - well if somebody is foolish enough to let that happen, then they shouldn't be here. Spin is Spin - there just need to be features and enhancements for Spin2 and P2 added capabilities....nobody says you have to use them and if the tools make you use them or exclude the P1, then somebody made a BIG mistake.
I play with software a lot and that will probably move more and more toward the P2 but when I do hardware stuff, I'll probably use the P1 more unless I really need a P2 feature. I'd rather smoke an $8 dip than a $15-$20 little surface mount bugger on a minimum development board that cost me $50, thank you very much! If the application doesn't need the P2, why use it? Sometimes it's better to dance with the horse that brung ya!
Remember we have a small cache for hub instructions, and hub data access will stall cache loads.