What remains to be done for the Prop 2?
JRetSapDoog
Posts: 954
What features/things remain to be implemented/done for the Prop 2? For example, SerDes is one. What are the others? Maybe a list would be helpful.
Legend: Finished, Planned, Very likely, Likely, Being Considered, Increasingly Unlikely, Unlikely, Rejected, Suggested
1. [P] SerDes to be used for general purpose serial handling, such as USB {Chip is committed to adding this}
2. [L] Non-hub flags accessible by all cogs without going through the hub {Chip asked to be reminded about this}
3. [L] More Prop 1 style locks than the 8 existing in the Prop 1 {likely still hub-based, as opposed to the non-hub-based flags in #2}
4. Hardware-based Random Number Generator from thermal noise {Chip mentioned this possibility a while back}
5. [V] Hub slot sharing mechanism to allow cogs to yield/accept other cogs' time slots
6. [V] Preemptive multitasking facilities {already possible in some form and may be extended, plus debugging features may be added}
7. [V] USB FS helper instructions including a CRC generator (maybe simple bit-at-a-time instructions)
8. Instant Decoding of a pair of bits in D, SETZC D/#, #0..31 {see Cluso99's post below}
...
BTW, the intent of this list is to compile features that are known to be forthcoming or have been seriously talked about, not simply a list of desired features, such as features that might appear in a Prop 3. If you're providing a feature, feel free to give a brief phrase describing it. Also, layout, synthesis or other tasks/steps can be included in the list. BTW, Ken has provided an informative schedule update for the P2.
Legend: Finished, Planned, Very likely, Likely, Being Considered, Increasingly Unlikely, Unlikely, Rejected, Suggested
1. [P] SerDes to be used for general purpose serial handling, such as USB {Chip is committed to adding this}
2. [L] Non-hub flags accessible by all cogs without going through the hub {Chip asked to be reminded about this}
3. [L] More Prop 1 style locks than the 8 existing in the Prop 1 {likely still hub-based, as opposed to the non-hub-based flags in #2}
4. Hardware-based Random Number Generator from thermal noise {Chip mentioned this possibility a while back}
5. [V] Hub slot sharing mechanism to allow cogs to yield/accept other cogs' time slots
6. [V] Preemptive multitasking facilities {already possible in some form and may be extended, plus debugging features may be added}
7. [V] USB FS helper instructions including a CRC generator (maybe simple bit-at-a-time instructions)
8. Instant Decoding of a pair of bits in D, SETZC D/#, #0..31 {see Cluso99's post below}
...
BTW, the intent of this list is to compile features that are known to be forthcoming or have been seriously talked about, not simply a list of desired features, such as features that might appear in a Prop 3. If you're providing a feature, feel free to give a brief phrase describing it. Also, layout, synthesis or other tasks/steps can be included in the list. BTW, Ken has provided an informative schedule update for the P2.
Comments
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1236832&viewfull=1#post1236832
C.W.
That's right. There are a lot of things that could stand some real-world testing before we commit to silicon.
ctwardell mentions in the link he gave having both signaling flags and the locks, but perhaps they could use the same atomic mechanism:
Chip commented, "I'll see what I can do. This is pretty simple, but if you don't hear anything from me, please remind me." C.W.'s suggestion seems like a clean and convenient way of helping cogs/tasks communicate/cooperate (in addition to the more general way), knitting them closer together. Of course, every little bit (pun intended) we add does take space and time.
Edit: Actually, I don't know if the flags would be atomic, and implementing atomic access outside of the round-robin access of the hub is likely more difficult.
Chip, I was curious if there were any areas you felt might need extra testing. Critical timing paths, parts you might be less confident about, combinations that could raise issues, etc. in some cases uninformed users are good testers as they experiment in other cases some focus helps.
Just now, looking back, I see that Heater made an executive decision to go with straight round-robin access and suggested freezing the design, the latter of which was predictably echoed by Ken. But seeing all the delicious changes happening, Ken seems to be getting more tolerant these days (last 2-4 months). It must be a real challenge in self-control, though.
About hitting the April shuttle run deadline, I hate to say it, but it's looking more-and-more doubtful. That's worrisome, but there's so much good "polishing" going on (if not outright addition of power) that one is reluctant to say anything. Edit: Check out Ken's thorough schedule update!
I think it's all very understandable; it's hard to rush a work of art, especially one that has really just started to gel over the last four months. As I see it, Chip fully intends to add things like SerDes, but he's finalizing the underlying infrastructure (which is more than just tweaking effort, I'd say), and he'll knock off those remaining areas when the time is right. Time sure does fly, though.
It would be a shame if the April shuttle run is missed, but it may be better to plan on a later fab run. Hopefully, the P2 design will stabilize soon and a significant amount of testing can be done with FPGAs (and possibly a simulator) to find any issues before casting the P2 in silicon. It seems like Parallax may be planning on this possibility by working on an FPGA board that would come out about the same time that P2 is planned on being fabricated in the April shuttle run.
Nice summary. You know I pay careful attention to the forum activity though I don't comment all the time on P2 topics in fear of discouraging contribution. One small change I'd make to your list is that:
6. [R] Preemptive multitasking facilitation {this appears to have gone down in flames and will likely be rejected}
becomes more like an [L] as Chip explained to me that it's really not the effort we think it is, and that we already have preemptive multitasking in place, but could easily be done a larger number of programs. Chip can explain it in terms that make sense to engineers pretty soon. I assure everybody he's under a strict deadline to wrap up the design right now.
Ken Gracey
I'm not sure about 2 & 3 being combined.
The current lock system is a hub operation and we need the flags to be non-hub operations so that flags can be set/tested without wasting a hub slot.
C.W.
I thought virtual pins (not bonded to physical pins) allowed this, or is this in addition to virtual/buried pins ?
The flags would be separate from Port D.
Port D has a good number of uses that may preclude having it available for flags.
C.W.
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1224661&viewfull=1#post1224661
(Note I have removed those completed items from the quote below) So we need to add
7. [V] USB FS helper instructions including a CRC generator (maybe simple bit at a time instruction)
At one time I suggested the following (but I think it went MIA)
http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1229521&viewfull=1#post1229521
@ctwardall: Thanks. I revised the wording. And, yes, it seems that we should assume that Port D will be kept busy in many designs.
@Cluso99: Thanks. I added your addition for the USB FS helper instructions, as well as your suggestion for the decoding instruction for D.