Probably I would say all the people who use and write code in high level languages that want multithreading (eg typical RTOS users) that don't necessarily want to go to the trouble of adding YIELDS all over the place in their source to allow co-operative multithreading. The good thing about preemptive multitasking is you basically can use your original source code as is and don't need to worry (too much) about where you are being switched out. The RTOS does all that for you.
From what I see Chip is adding we still get total control of the switching from the scheduler task so the thread preemption is not completely automatic, software is still involved there. So we can still add more features in software such as thread locking, thread priorities etc layered on top of the scheduler for allowing critical thread sections and to influence thread switching order. It seems the best of all worlds here. We don't need interrupts but get what a lot of an RTOS normally offers along with rapid context switches.
PS. One question for Chip, if multitasking is enabled and a task is waiting on the system counter with WAITCNT (such as the scheduler task might be doing), does the time have to match exactly to wake it up or just that the elapsed time is greater than some calculated amount when WAITCNT executes? Because due to multitasking the clock cycle that exactly matches the WAITCNT instruction may not be exactly the one when it executes and checks the timer, the system ticks might be observed jumping up by 4's for example (with 4 tasks). We don't have some issue there do we?
Roger.
Isn't this just an incredibly complicated way of doing what most processors do with a timer interrupt and restartable instructions?
Not really, because there will be so much NOT in the FPGA, that Debug will always be a fork, and worse, you do not debug the actual silicon.
The what we are doing is a waste of time because we are not vetting the real thing. Nope - I don't agree!
Being able to debug what you ship, on the board you ship, is close to industry standard now. ie just expected.
That is only because it is impossible to emulate those complex chips. Not buying this statement either.
The P2 is the other way around - we are emulating first, then proceeding to silicon. Makes for a fantastic debug platform using the FPGA where we can actually inspect anything we want, even slow it down, as long as we can convince Chip to give us a special fpga build.
Probably I would say all the people who use and write code in high level languages that want multithreading (eg typical RTOS users) that don't necessarily want to go to the trouble of adding YIELDS all over the place in their source to allow co-operative multithreading. The good thing about preemptive multitasking is you basically can use your original source code as is and don't need to worry (too much) about where you are being switched out. The RTOS does all that for you.
From what I see Chip is adding we still get total control of the switching from the scheduler task so the thread preemption is not completely automatic, software is still involved there. So we can still add more features in software such as thread locking, thread priorities etc layered on top of the scheduler for allowing critical thread sections and to influence thread switching order. It seems the best of all worlds here. We don't need interrupts but get what a lot of an RTOS normally offers along with rapid context switches.
PS. One question for Chip: if multitasking is enabled and a task is waiting on the system counter with WAITCNT (such as the scheduler task might be doing), does the time have to match exactly to wake it up or just that the elapsed time is greater than some calculated amount when WAITCNT executes? Because due to multitasking the clock cycle that exactly matches the WAITCNT instruction may not be exactly the one when it executes and checks the timer, the system ticks might be observed jumping up by 4's for example (with 4 tasks). We don't have some issue there do we?
Roger.
How many commercial products are going to use RTOS on the P2?
Are you going to use an RTOS? If so, will it lead to commercial quantities for Parallax?
God only knows the total number of commercial products that would use an RTOS but it would be have to be more than 1. ;-)
I think personally yes I could make use of an RTOS. It could help with porting an IP stack and server thread applications written in high level languages. In the networking world RTOS is pretty common.
What does preemtive multitasking (or hardware task switching) offers to P2?
P2 will have a 4x or 8x increase in (sales, performance, applications, or what?).
If the reason to do this is that some people suggested it (because it will be needed for RTOS, Linux, or any other OS...) Don't trust them! When you finish to implement hardware context switching you will be asked to implement a Memory Management Unit (MMU), or "whatever else".
God only knows the total number of commercial products that would use an RTOS but it would be have to be more than 1. ;-)
I think personally yes I could make use of an RTOS. It could help with porting an IP stack and server thread applications written in high level languages. In the networking world RTOS is pretty common.
These days it seems like most people skip the RTOS and just run Linux on their embedded systems. :-(
That's why it takes several minutes for your DVD player to power on.
Not really, because there will be so much NOT in the FPGA, that Debug will always be a fork, and worse, you do not debug the actual silicon.
Being able to debug what you ship, on the board you ship, is close to industry standard now. ie just expected.
I agree with Cluso.
Having the flexibility to incorporate specialized debug mechanisms in this testing phase would be beneficial.
These features can be left out in the silicon as they are only needed now to verify the P2's stability.
When P2 is deemed OK then we can look forward to pulling our hair out debugging our code!.
Brian
Perhaps I am the only one, but I see great lumps of silicon supporting that very simple tasking that heater originally proposed.
I agree that the tasking is a great feature. But I see it as a way to put multiple device drivers into a single cog, not as a way to make large programs run multiple threads. We have cogs for that.
All that additional silicon has to come from somewhere, so I hope we have enough to support SERDES (USB is 2 simple instructions for supporting sw). To me, SERDES is a lot more that just serial. It is about being able to stream bits in or out of a serialiser so that we can build more complex I/O systems simpler. It should be able to make some really fantastic peripherals not even currently thought of.
I would hate to miss this important pieces due to the extra silicon being devoted to multitasking and preemptive multitasking.
We have the great feature that we can run a cog from hub (hubexec). Many of the obstacles have been overcome by the WIDEs and CACHING. More caching might be a better use of that silicon.
It is a pity the resources cannot add another large performance leap - that of making the COG and AUX RAMs 256bits wide (for WIDE hub transfers, and then AUX-HUB wides too). I realise there are some rather large obstacles due to the "squareness" of the cog and ram blocks, but I am sure there are ways around that with a little more thought. Unfortunately, this was not a foreseen problem until the latest hubexec and wides were added.
The what we are doing is a waste of time because we are not vetting the real thing. Nope - I don't agree!
You miss the point - Emulation in FPGA makes solid sense in 2014, as there is no silicon.
However, telling a customer, in 2017, who is used to having On-Chip-Debug, that to Debug the Prop he has on his PCB, he will have to buy a Complex FPGA board, (and accept a slower clock), is not really going to fly.
That is only because it is impossible to emulate those complex chips. Not buying this statement either.
The P2 is the other way around - we are emulating first, then proceeding to silicon. Makes for a fantastic debug platform using the FPGA where we can actually inspect anything we want, even slow it down, as long as we can convince Chip to give us a special fpga build.
You miss that a FPGA is only partial (and slow) emulation, there is a LOT in a P2, that is NOT in the FPGA, so there is no emulation coverage following your logic there.
I want to be clear that I am only advocating a way for us to be able to easily get the proper context of a single task, save it and restore it with some other saved task context at any time. This is in line with what Chip seems to be talking about with his proposed instructions. And I agree that actual SETTASK tasking model as defined today itself is sufficient to carve up the CPU power for drivers, user threads, scheduler etc. So what I am talking about is just the additional hardware capabilities to get/set state for supporting multithreading within a single task. I would hope this would not need lots and lots of silicon but that's Chip's call.
If we don't have a good way to access the entire state of a task from the scheduler at any given instant in time, then we likely need to do co-operative multithreading at specific code boundaries which entails changing your source to scatter Yields all over the place to make it work. That is what I don't want to have to do. Also simply running different threads that share data on different COGs in parallel is fraught with other dangers in that your can't protect data at the task level, you need a mutex or other lock to prevent parallel tasks on different COGs from clobbering the data. Having a scheduler based taskLock feature in a software thread in a single COG's user task can simplify things there because the code can be run just on a single processor which is simpler.
To be clear I certainly also would want the serdes and USB stuff to not be neglected.
... I hope we have enough to support SERDES (USB is 2 simple instructions for supporting sw). To me, SERDES is a lot more that just serial. It is about being able to stream bits in or out of a serialiser so that we can build more complex I/O systems simpler. It should be able to make some really fantastic peripherals not even currently thought of.
Agreed, SerDes is going to be an important point of difference on P2, if the Hardware can manage the bit-level stuff, and the SW manage the word-level, it will be a great balance of speed and muscle.
USB is appearing almost for free on many small micros, so being able to USB connect on a P2 will be important.
I would also like to see SerDes able to do the FTDI Fast Serial (clocked,half duplex) to 50MHz, for those apps needing above full speed USB.
PS. One question for Chip: if multitasking is enabled and a task is waiting on the system counter with WAITCNT (such as the scheduler task might be doing), does the time have to match exactly to wake it up or just that the elapsed time is greater than some calculated amount when WAITCNT executes? Because due to multitasking the clock cycle that exactly matches the WAITCNT instruction may not be exactly the one when it executes and checks the timer, the system ticks might be observed jumping up by 4's for example (with 4 tasks). We don't have some issue there do we?
Roger.
You wouldn't want to use WAITCNT because it would stall the pipeline, but you could use PASSCNT to loop until some point is elapsed, or past. So, it doesn't need to be exact. At 200MHz you'd have 2^32/200M/2, or about 11 seconds of grace period to meet your next mark. If some other thread locked up the pipeline for that long, there'd be trouble, as you'd have to wait for the 32-bit CNT to wrap, relative to your target, but no task should need more than a few microseconds of contiguous time, I'd think.
I have to say I'm with Cluso and Roy here. This whole preempt debate has me very worried about the P2's future again.
Seems this conversation has been going on all week having consumed ten pages of posts.
All for a feature that seems hardly important given that the P2 can run 32 threads already!
The complexity is overwhelming, what 16 instructions required to support it and 10% more gates, yikes!
Preempt is NOT required to support propgcc and it's pthreads API. See the Pth library for example.
Debugging I thought we had covered. There is the LED of course, the original and best but don't we have that trace facility where one COG can watch another already. At full speed!
Chip,
We are at the edge of the project and it's hard not to put a few more things in...
And I am on the edge of my seat again.
Feature creep is one sure fire, well known, way to kill a good concept and product.
I am now constantly thinking of straws and camels backs, and of the curiously American phrase "Jumping the shark".
ctwardell,
Commercial users would also be pleased with the ability to implement a proper RTOS.
NO, NO and thrice NO!
I have been involved with many products using micro-controllers/microprocessors far less capable than the P2 that don't need or use an RTOS.
Given the parallel processing nature of the Prop, especially the P2 with it's hardware scheduled threads an RTOS is redundant. That simplicity is supposed to be a FEATURE of the P2, like the absence of the need for interrupts.
Nobody is going to be using an RTOS on the P2. In the same way they don't on XMOS.
David Betz,
Isn't this just an incredibly complicated way of doing what most processors do with a timer interrupt and restartable instructions?
Yes. And unlike interrupts on a normal single CPU machine, with no hardware threading, it adds no value.
rogloh,
In the networking world RTOS is pretty common.
That's because they are running on traditional machines with a single CPU and interrupts. It is not a requirement for networking code. uIP and other IP stacks demonstrate that.
Clusso,
...I see great lumps of silicon supporting that very simple tasking that heater originally proposed.
I have no idea how great those lumps of silicon might be but at the point where I suggested the automatic hardware time slicing Chip had already put in place the logic to do it manually with TASKSWITCH. From the way he described it automating that task switch was straightforward, it certainly got done in a short time! It was a natural "simple" progression of what was already in place. Not a big ugly wart that needs lashing on like preempt and interrupts.
"jump the shark" - Indicating the moment when a brand, design, or creative effort's evolution declines.
I second most of the above, and find the RTOS comments particularly lucid. Not just a short while ago, we were discussing how this chip can do those things without needing RTOS software. And this mess for debug? ugh Anyway, seconded.
You wouldn't want to use WAITCNT because it would stall the pipeline, but you could use PASSCNT to loop until some point is elapsed, or past. So, it doesn't need to be exact. At 200MHz you'd have 2^32/200M/2, or about 11 seconds of grace period to meet your next mark. If some other thread locked up the pipeline for that long, there'd be trouble, as you'd have to wait for the 32-bit CNT to wrap, relative to your target, but no task should need more than a few microseconds of contiguous time, I'd think.
But WAITCNT provides an effiective way to cut power consumption. In a multi-threading P1 driver environment a cog is busy only about 10% of the time, and the balance of the time the scheduler keeps it in a WAITCNT until the next thread is dispatched. This really keeps the current low and provides effective battery operation. I am aware that the P2 has large idle currrents, and hence is not suitable for battery operation, so perhaps it's not a big deal.
But as an aside, all this concern about pre-emptive threading to seems like a moot point. With the enormous increase in processing power of the P2, I predict that most folks will have their cogs only 1% busy. Evenso, rapid task switching IS of value however as it reduces undesirable jitter.
What pre-emptive threading DOES give you is a slightly more convenient way of writing your code. No big deal really, and in my opinion not worth the apparent hassle. Commercial users will tweak their code anyway to optimize their application.
Things in the P1 were quite straight forward and relatively simple. I'm really struggling with the complexity of what seems to be evolving. I fear that you may be turning potential users away.
Other opinions will exist of course, and each for their own reasons.
For whatever it's worth, this debug/preemptive circuit actually uses no flops - only mux's to exploit existing storage. It's actually NOT very complicated, at all, and these signals are all just Q-to-D with no logic in-between, so they don't contribute directly to critical paths. I think it's practically free to implement and would be kind of sad to skip.
I have to say I'm with Cluso and Roy here. This whole preempt debate has me very worried about the P2's future again.
Seems this conversation has been going on all week having consumed ten pages of posts.
All for a feature that seems hardly important given that the P2 can run 32 threads already!
The complexity is overwhelming, what 16 instructions required to support it and 10% more gates, yikes!
Preempt is NOT required to support propgcc and it's pthreads API. See the Pth library for example.
Debugging I thought we had covered. There is the LED of course, the original and best but don't we have that trace facility where one COG can watch another already. At full speed!
Chip,
And I am on the edge of my seat again.
Feature creep is one sure fire, well known, way to kill a good concept and product.
I am now constantly thinking of straws and camels backs, and of the curiously American phrase "Jumping the shark".
ctwardell,
NO, NO and thrice NO!
I have been involved with many products using micro-controllers/microprocessors far less capable than the P2 that don't need or use an RTOS.
Given the parallel processing nature of the Prop, especially the P2 with it's hardware scheduled threads an RTOS is redundant. That simplicity is supposed to be a FEATURE of the P2, like the absence of the need for interrupts.
Nobody is going to be using an RTOS on the P2. In the same way they don't on XMOS.
David Betz,
Yes. And unlike interrupts on a normal single CPU machine, with no hardware threading, it adds no value.
rogloh,
That's because they are running on traditional machines with a single CPU and interrupts. It is not a requirement for networking code. uIP and other IP stacks demonstrate that.
+1
Clusso,
I have no idea how great those lumps of silicon might be but at the point where I suggested the automatic hardware time slicing Chip had already put in place the logic to do it manually with TASKSWITCH. From the way he described it automating that task switch was straightforward, it certainly got done in a short time! It was a natural "simple" progression of what was already in place. Not a big ugly wart that needs lashing on like preempt and interrupts.
Yes, what you proposed was so simple. It isn't any more. Some of the support was nice, but it now seems way out of hand. And I am unsure who actually requires the latest round of additions.
Next thing they will be asking for Interrupts. Oops - wash my mouth out with soap!
And I know it is much to ask?
>
BUT it is possible to You made 2 versions of FPGA --- One with and one without Preemptive parts ( only with complete SERDES ) and if added some other hardware/instructions that not are for Preemptive/Debugger parts.
That as I know not need changes to PNut else manual.
For whatever it's worth, this debug/preemptive circuit actually uses no flops - only mux's to exploit existing storage. It's actually NOT very complicated, at all, and these signals are all just Q-to-D with no logic in-between, so they don't contribute directly to critical paths. I think it's practically free to implement and would be kind of sad to skip.
We trust your judgement on how easy, expensive and time consuming it may be to implement.
The complexity of which I speak is not just internal. The bewildering array of obscure instructions and the complexity of their use is something to consider. Especially when they have no practical benefit.
And, well, time is of the essence. Already we are looking at next Christmas for "Chipmas" rather than the one that has just been.
Personally. if the thing does not fit on my nano after having been bloated out with preempt mux's I'm going to be dead in the water until real chips turn up.
Cluso,
"...interrupts..." That might be the "shark" I was talking about.
For whatever it's worth, this debug/preemptive circuit actually uses no flops - only mux's to exploit existing storage. It's actually NOT very complicated, at all, and these signals are all just Q-to-D with no logic in-between, so they don't contribute directly to critical paths. I think it's practically free to implement and would be kind of sad to skip.
If it is practical, and comes at low cost, then the Debug will have solid long term benefits.
FPGA as debug will always be slower, and never cover all that is in the P2 chip, and customers do expect on-chip debug - more than printf.
As an example, Atmel (hardly a leader in debug) have just added Data Breakpoints, and Live watch - this on top of the usual Step/Step Over/ Break/Run to Cursor.
( A P2 can do Data Breakpoints, and Live watch, for free)
If a useful form of task swap comes too, well that's fine, but I think Debug will be used by all users, and only some will do task Swap..
The P1 (after all this time and a request for gold level code from Parallax) doesn't have a Parallax sanctioned and supported set of soft peripherals, one of the great, signature, features of the P1 in any language. The solution for a perspective or new customer is to go look in the OBEX and pick a potential solution.
Now we have talk of an RTOS? How many of those tailored to individual whims will start showing up? Will Parallax pick one and put FE resources behind supporting it and commercial customers that use it? Will P2 launch with a set of standard soft peripherals backed by Parallax? Will perspective large quantity clients be asked to look through the OBEX to pick whick soft peripherals they want to try?
How much time is it going to take to put the entire P2 "package" together to a point that it can impress and win new large quantity engineers and their management? All ghis redesign time and feature creep is eating into that time...and, yes the non-hardware part of this project is significant and a big burden to a small company like Parallax. Yeah, we're all eager to see pet features put in, excited to get our hands on something new to play with, looking forward to see our pet interests in silicon but how many thousand P1 chips has any of us been personally been responsible for purchasing or selling to others. I have more than my share of P1 based developer boards and robots and such...I'm maybe good for 30-35 individual P1 chips...that's not going to sustain the P2.
SERDES and USB support are more critical to what the P2 started out to be than any of the features that have been added lately.
How is all of this going to be tested thoroughly in FPGA? How much time is there going to be for thourough testing? Have all the experienced contributors started to give thought as to how a community test activity should be desgned and run so everything gets tested and all corner cases are tested and the entire P2 can be declared ready for silicon by any indicator other than it's been x months and the next shuttle run is in a week?
How many folks are going to take off with the latest FPGA image and play in their little area of interest an just start reporting back on the cool ghkng they've been able to do with their instructions?
How many folks have a methodical plan thought out for testing? Anybody have any test rigs (hardware or software) that can be shared with the community? Has anyone shared how they have been testing so far?
Am I just talking out of lack of experience and none of these are real concerns in a project like this? It seems to me getting to a final FPGA or silicon is about the 50-60% point on the entire project.
For whatever it's worth, this debug/preemptive circuit actually uses no flops - only mux's to exploit existing storage. It's actually NOT very complicated, at all, and these signals are all just Q-to-D with no logic in-between, so they don't contribute directly to critical paths. I think it's practically free to implement and would be kind of sad to skip.
Great. Sounds good to me if you see it as fairly low hanging fruit and straightforward to add. We all know a fast and full task state get/set feature would be very useful for both debug and preemptive multithreading when developers get interested in these sorts of applications. But I am only a single voice and can easily be shouted down by the ravenous mob of other eager P2 consumers.
For whatever it's worth, this debug/preemptive circuit actually uses no flops - only mux's to exploit existing storage. It's actually NOT very complicated, at all, and these signals are all just Q-to-D with no logic in-between, so they don't contribute directly to critical paths. I think it's practically free to implement and would be kind of sad to skip.
Is there any chance you could post a summary of what is currently planned for debug/preemption? I guess I don't really know the details of what we're talking about and it's hard to piece it together by reading through the hundreds of messages on this topic. Could someone post a brief summary of where we are right now and what alternatives are being considered?
At the risk of being tarred and feathered and then excommunicated I'm going to agree with rogloh.
Two reasons:
Improved debug on chip, we need good debug on the chip, not just something that is FPGA only. That isn't to say we can't have extra debug abilities on the FPGA.
(Preemptive) Multithreading, yeah I know it goes against "the philosophy", but it opens the door for a lot of people to work with the prop and be productive before coming to terms with "the philosophy".
It becomes another tool in the toolkit, sometime useful, sometimes not.
Is there any chance you could post a summary of what is currently planned for debug/preemption? I guess I don't really know the details of what we're talking about and it's hard to piece it together by reading through the hundreds of messages on this topic. Could someone post a brief summary of where we are right now and what alternatives are being considered?
Thanks!
David
There's a mechanism which can read/write a task's critical state information from/to the WIDEs.
By starving a task of time slots, it settles into a quiet mode where its state becomes static and it can be completely altered. When given time slots again, the task resumes execution.
This is realized by two instructions:
RDTASK D/# 'read state of task D/# into WIDEs
WRTASK D/# 'write state of task D/# from WIDEs
These instructions can be coordinated with WRWIDE/RDWIDE to quickly save and restore task state data from hub memory.
I don't know if I had mentioned it, but there was a SETMASK D/# instruction that set a 32-bit byte-write mask for the next WRWIDE. That amounted to another 32 bits of task-state data, so I changed WRWIDE D/PTRA/PTRB to WRWIDE D/#,S/PTRA/PTRB, where D/# provides the 32-bit mask (1's=don't write, 0's=write, so #0 writes all 32 bytes). By making the operation atomic, another 32 bits of task data was eliminated. Now, everything will fit into the WIDEs, with 18 bits to spare.
Multithreading, yeah I know it goes against "the philosophy",
Multi-threading does not go against "the philosophy."
The round-robin hardware scheduled multi-threading is a natural counterpart to the round robin HUB access of COGs. "Wheels within wheels" you might say.
Pre-emptive multi-threading, otherwise known as "interrupt handling", is totally at odds with philosophy. Blasphemous I would say. It's more jamming a crowbar into your spokes!
I never though I would see the day when a Propeller would support interrupts and all the complexity and baggage that comes with them. That day has come.
Comments
Also, it's not really that complicated.
Not really, because there will be so much NOT in the FPGA, that Debug will always be a fork, and worse, you do not debug the actual silicon.
Being able to debug what you ship, on the board you ship, is close to industry standard now. ie just expected.
The P2 is the other way around - we are emulating first, then proceeding to silicon. Makes for a fantastic debug platform using the FPGA where we can actually inspect anything we want, even slow it down, as long as we can convince Chip to give us a special fpga build.
Are you going to use an RTOS? If so, will it lead to commercial quantities for Parallax?
I think personally yes I could make use of an RTOS. It could help with porting an IP stack and server thread applications written in high level languages. In the networking world RTOS is pretty common.
P2 will have a 4x or 8x increase in (sales, performance, applications, or what?).
If the reason to do this is that some people suggested it (because it will be needed for RTOS, Linux, or any other OS...) Don't trust them! When you finish to implement hardware context switching you will be asked to implement a Memory Management Unit (MMU), or "whatever else".
Time is working against testing.
That's why it takes several minutes for your DVD player to power on.
I agree with Cluso.
Having the flexibility to incorporate specialized debug mechanisms in this testing phase would be beneficial.
These features can be left out in the silicon as they are only needed now to verify the P2's stability.
When P2 is deemed OK then we can look forward to pulling our hair out debugging our code!.
Brian
I agree that the tasking is a great feature. But I see it as a way to put multiple device drivers into a single cog, not as a way to make large programs run multiple threads. We have cogs for that.
All that additional silicon has to come from somewhere, so I hope we have enough to support SERDES (USB is 2 simple instructions for supporting sw). To me, SERDES is a lot more that just serial. It is about being able to stream bits in or out of a serialiser so that we can build more complex I/O systems simpler. It should be able to make some really fantastic peripherals not even currently thought of.
I would hate to miss this important pieces due to the extra silicon being devoted to multitasking and preemptive multitasking.
We have the great feature that we can run a cog from hub (hubexec). Many of the obstacles have been overcome by the WIDEs and CACHING. More caching might be a better use of that silicon.
It is a pity the resources cannot add another large performance leap - that of making the COG and AUX RAMs 256bits wide (for WIDE hub transfers, and then AUX-HUB wides too). I realise there are some rather large obstacles due to the "squareness" of the cog and ram blocks, but I am sure there are ways around that with a little more thought. Unfortunately, this was not a foreseen problem until the latest hubexec and wides were added.
Just my frustrated 2c
You miss the point - Emulation in FPGA makes solid sense in 2014, as there is no silicon.
However, telling a customer, in 2017, who is used to having On-Chip-Debug, that to Debug the Prop he has on his PCB, he will have to buy a Complex FPGA board, (and accept a slower clock), is not really going to fly.
You miss that a FPGA is only partial (and slow) emulation, there is a LOT in a P2, that is NOT in the FPGA, so there is no emulation coverage following your logic there.
If we don't have a good way to access the entire state of a task from the scheduler at any given instant in time, then we likely need to do co-operative multithreading at specific code boundaries which entails changing your source to scatter Yields all over the place to make it work. That is what I don't want to have to do. Also simply running different threads that share data on different COGs in parallel is fraught with other dangers in that your can't protect data at the task level, you need a mutex or other lock to prevent parallel tasks on different COGs from clobbering the data. Having a scheduler based taskLock feature in a software thread in a single COG's user task can simplify things there because the code can be run just on a single processor which is simpler.
To be clear I certainly also would want the serdes and USB stuff to not be neglected.
Agreed, SerDes is going to be an important point of difference on P2, if the Hardware can manage the bit-level stuff, and the SW manage the word-level, it will be a great balance of speed and muscle.
USB is appearing almost for free on many small micros, so being able to USB connect on a P2 will be important.
I would also like to see SerDes able to do the FTDI Fast Serial (clocked,half duplex) to 50MHz, for those apps needing above full speed USB.
You wouldn't want to use WAITCNT because it would stall the pipeline, but you could use PASSCNT to loop until some point is elapsed, or past. So, it doesn't need to be exact. At 200MHz you'd have 2^32/200M/2, or about 11 seconds of grace period to meet your next mark. If some other thread locked up the pipeline for that long, there'd be trouble, as you'd have to wait for the 32-bit CNT to wrap, relative to your target, but no task should need more than a few microseconds of contiguous time, I'd think.
Seems this conversation has been going on all week having consumed ten pages of posts.
All for a feature that seems hardly important given that the P2 can run 32 threads already!
The complexity is overwhelming, what 16 instructions required to support it and 10% more gates, yikes!
Preempt is NOT required to support propgcc and it's pthreads API. See the Pth library for example.
Debugging I thought we had covered. There is the LED of course, the original and best but don't we have that trace facility where one COG can watch another already. At full speed!
Chip, And I am on the edge of my seat again.
Feature creep is one sure fire, well known, way to kill a good concept and product.
I am now constantly thinking of straws and camels backs, and of the curiously American phrase "Jumping the shark".
ctwardell, NO, NO and thrice NO!
I have been involved with many products using micro-controllers/microprocessors far less capable than the P2 that don't need or use an RTOS.
Given the parallel processing nature of the Prop, especially the P2 with it's hardware scheduled threads an RTOS is redundant. That simplicity is supposed to be a FEATURE of the P2, like the absence of the need for interrupts.
Nobody is going to be using an RTOS on the P2. In the same way they don't on XMOS.
David Betz, Yes. And unlike interrupts on a normal single CPU machine, with no hardware threading, it adds no value.
rogloh, That's because they are running on traditional machines with a single CPU and interrupts. It is not a requirement for networking code. uIP and other IP stacks demonstrate that.
Clusso, I have no idea how great those lumps of silicon might be but at the point where I suggested the automatic hardware time slicing Chip had already put in place the logic to do it manually with TASKSWITCH. From the way he described it automating that task switch was straightforward, it certainly got done in a short time! It was a natural "simple" progression of what was already in place. Not a big ugly wart that needs lashing on like preempt and interrupts.
"jump the shark" - Indicating the moment when a brand, design, or creative effort's evolution declines.
But WAITCNT provides an effiective way to cut power consumption. In a multi-threading P1 driver environment a cog is busy only about 10% of the time, and the balance of the time the scheduler keeps it in a WAITCNT until the next thread is dispatched. This really keeps the current low and provides effective battery operation. I am aware that the P2 has large idle currrents, and hence is not suitable for battery operation, so perhaps it's not a big deal.
But as an aside, all this concern about pre-emptive threading to seems like a moot point. With the enormous increase in processing power of the P2, I predict that most folks will have their cogs only 1% busy. Evenso, rapid task switching IS of value however as it reduces undesirable jitter.
What pre-emptive threading DOES give you is a slightly more convenient way of writing your code. No big deal really, and in my opinion not worth the apparent hassle. Commercial users will tweak their code anyway to optimize their application.
Things in the P1 were quite straight forward and relatively simple. I'm really struggling with the complexity of what seems to be evolving. I fear that you may be turning potential users away.
Other opinions will exist of course, and each for their own reasons.
Sorry for the rant, but it's just how I see it.
Cheers,
Peter (pjv)
+1
"...struggling with the complexity..."
Yep, And all unnecessary.
Next thing they will be asking for Interrupts. Oops - wash my mouth out with soap!
I as long was not active in last additions.
And I know it is much to ask?
>
BUT it is possible to You made 2 versions of FPGA --- One with and one without Preemptive parts ( only with complete SERDES ) and if added some other hardware/instructions that not are for Preemptive/Debugger parts.
That as I know not need changes to PNut else manual.
We trust your judgement on how easy, expensive and time consuming it may be to implement.
The complexity of which I speak is not just internal. The bewildering array of obscure instructions and the complexity of their use is something to consider. Especially when they have no practical benefit.
And, well, time is of the essence. Already we are looking at next Christmas for "Chipmas" rather than the one that has just been.
Personally. if the thing does not fit on my nano after having been bloated out with preempt mux's I'm going to be dead in the water until real chips turn up.
Cluso,
"...interrupts..." That might be the "shark" I was talking about.
If it is practical, and comes at low cost, then the Debug will have solid long term benefits.
FPGA as debug will always be slower, and never cover all that is in the P2 chip, and customers do expect on-chip debug - more than printf.
As an example, Atmel (hardly a leader in debug) have just added Data Breakpoints, and Live watch - this on top of the usual Step/Step Over/ Break/Run to Cursor.
( A P2 can do Data Breakpoints, and Live watch, for free)
If a useful form of task swap comes too, well that's fine, but I think Debug will be used by all users, and only some will do task Swap..
Now we have talk of an RTOS? How many of those tailored to individual whims will start showing up? Will Parallax pick one and put FE resources behind supporting it and commercial customers that use it? Will P2 launch with a set of standard soft peripherals backed by Parallax? Will perspective large quantity clients be asked to look through the OBEX to pick whick soft peripherals they want to try?
How much time is it going to take to put the entire P2 "package" together to a point that it can impress and win new large quantity engineers and their management? All ghis redesign time and feature creep is eating into that time...and, yes the non-hardware part of this project is significant and a big burden to a small company like Parallax. Yeah, we're all eager to see pet features put in, excited to get our hands on something new to play with, looking forward to see our pet interests in silicon but how many thousand P1 chips has any of us been personally been responsible for purchasing or selling to others. I have more than my share of P1 based developer boards and robots and such...I'm maybe good for 30-35 individual P1 chips...that's not going to sustain the P2.
SERDES and USB support are more critical to what the P2 started out to be than any of the features that have been added lately.
How is all of this going to be tested thoroughly in FPGA? How much time is there going to be for thourough testing? Have all the experienced contributors started to give thought as to how a community test activity should be desgned and run so everything gets tested and all corner cases are tested and the entire P2 can be declared ready for silicon by any indicator other than it's been x months and the next shuttle run is in a week?
How many folks are going to take off with the latest FPGA image and play in their little area of interest an just start reporting back on the cool ghkng they've been able to do with their instructions?
How many folks have a methodical plan thought out for testing? Anybody have any test rigs (hardware or software) that can be shared with the community? Has anyone shared how they have been testing so far?
Am I just talking out of lack of experience and none of these are real concerns in a project like this? It seems to me getting to a final FPGA or silicon is about the 50-60% point on the entire project.
Great. Sounds good to me if you see it as fairly low hanging fruit and straightforward to add.
Thanks!
David
Two reasons:
Improved debug on chip, we need good debug on the chip, not just something that is FPGA only. That isn't to say we can't have extra debug abilities on the FPGA.
(Preemptive) Multithreading, yeah I know it goes against "the philosophy", but it opens the door for a lot of people to work with the prop and be productive before coming to terms with "the philosophy".
It becomes another tool in the toolkit, sometime useful, sometimes not.
C.W.
There's a mechanism which can read/write a task's critical state information from/to the WIDEs.
By starving a task of time slots, it settles into a quiet mode where its state becomes static and it can be completely altered. When given time slots again, the task resumes execution.
This is realized by two instructions:
RDTASK D/# 'read state of task D/# into WIDEs
WRTASK D/# 'write state of task D/# from WIDEs
These instructions can be coordinated with WRWIDE/RDWIDE to quickly save and restore task state data from hub memory.
Code for a thread switch or breakpoint can be seen here: http://forums.parallax.com/showthread.php/125543-Propeller-II-update-BLOG?p=1246748&viewfull=1#post1246748
EDIT: Perhaps we can just have a single instruction SWPTASK D/# which swaps the task's data with WIDEs. That might be more efficient.
The round-robin hardware scheduled multi-threading is a natural counterpart to the round robin HUB access of COGs. "Wheels within wheels" you might say.
Pre-emptive multi-threading, otherwise known as "interrupt handling", is totally at odds with philosophy. Blasphemous I would say. It's more jamming a crowbar into your spokes!
I never though I would see the day when a Propeller would support interrupts and all the complexity and baggage that comes with them. That day has come.