What happens if there are simultaneous writes to different locations - does or will that work?
That one's no issue. The RAM is dual-ported so there is no conflict there.
And can we say for certain yet what will work in the final hardware for different combinations of LUT sharing and simultaneous reading and writing?
Yes, Chip has it implemented in the FPGA. I've tested it. The read data corruption no longer occurs.
A little difficult to prove given the somewhat unknown nature of coordinating two cogs but, supposedly, the reading cog receives the new data being written by the writing cog. This will be done with extra mux circuit to copy around the RAM when the two accesses coincide.
Thanks, Evan. It seems that only simultaneous writes to the same location are uncertain.
Bad news. Coinciding data writes from both cogs sometimes corrupt, sometimes okay. Completely unreliable. Don't do it. Find another solution. I actually wonder if it is setting up an electrical fight.
On a totally unrelated note, something peculiar has shown up with my testing method. The COGATN mechanism seems to have different timings depending on whether it is odd or even numbered. EDIT: I've got bigger differences with other combinations. I'm guessing it's on a hub rotation scheme, like access to the lock bits and cordic.
On a totally unrelated note, something peculiar has shown up with my testing method. The COGATN mechanism seems to have different timings depending on whether it is odd or even numbered. EDIT: I've got bigger differences with other combinations. I'm guessing it's on a hub rotation scheme, like access to the lock bits and cordic.
Does this mean cogs A and B are not in perfect sync after COGATN for A and WAITATN for B? Main interest here is when the cogs are a LUT-sharing pair. What are the differences in this case, if any?
I never expected them to be in lock-step exiting COGATN/WAITATN together but I certainly wasn't expecting interval variances. The way to get into lock-step is use a WAITCTx on both cogs - Which is what I've been doing. The WAITATN did acheive what I wanted which was to notify of job complete and data logged for pickup.
I just happen to be recording the start and finish times for each test. Up until I added the COGATN/WAITATN part, it was very predictably whatever I specified in the WAITCT1 numbers. But that all changed with a WAITATN. The amount of time to completion differed depending on cog order, with a range of eight clocks. The cogs involved were still starting from the same forward marker as before and running identical code on each cog.
Admittedly, the earlier tests were only of the duration of code running on the receiving cog. It was in effect just verifying that no disturbances occurred when the sending cog modified lutRAM. With WAITATN added it is now measuring the sending cog plus COGATN mechanism instead.
But the fact that there is changes in the measured interval which are solely depending on which cog is sending and which cog is receiving is enough to make the claim. The eight clock range is somewhat of a giveaway too. I guess this all reinforces that WAITCTx is the precise timing tool.
Okay, there isn't any COGATN issue. It's fine once I did a clean up without all the lutRAM baggage.
In process I've worked out that the receiving cog exits the WAITATN instruction two clocks after the sending cog exits the COGATN instruction.
Thanks for the info, Evan. Therefore COGATN+NOP in sending cog and WAITATN in receiving cogs synchronizes them. Might be worthwhile adding this to your reference post.
I've been doing a lot of reading on the P2, and I'm ready to start coding a new version of Catalina ... but one thing I have yet to find is a repository of P2 objects, similar to the old P1 OBEX. Is there such a thing? I know there is a P2 Github repository - https://github.com/parallaxinc/propeller - but it doesn't seem to contain much yet.
I believe that many of the simpler P1 objects would work on the P2 with just a few minor tweaks and a recompile ... but I can't find if this has been done yet or not.
Am I just looking in the wrong places? There's a lot of stuff I've yet to read on the P2, and I'm probably still missing a lot!
Thanks, Chip. I will probably be spinning off a few P2 versions of P1 objects as I work on my Catalina update, and I see a few objects being developed in individual threads (VGA drivers etc), so maybe this is a good time to start one?
Thanks, Chip. I will probably be spinning off a few P2 versions of P1 objects as I work on my Catalina update, and I see a few objects being developed in individual threads (VGA drivers etc), so maybe this is a good time to start one?
Maybe it is. I don't know what to do about it, though, other than to ask whoever at Parallax manages the current Obex.
nice that you show up again, even if you needed to get sick to do so. The current development around the P2 is sort of exploding, @ersmith is coming out with new versions almost daily, It is hard to keep up.
Sadly there seems to be no one at parallax to collect and publish all the stuff in one place, like me Parallax is new to git and GitHub, so I do not complain.
We lucky guys who could get one of the evaluation P2's are just hammering them to find flaws and most stuff is still just in the forum pages, the Parallax Link you provided is needed and cool, but not yet used by any of the contributors.
So you basically have to hunt down the newest versions of all dev tools and the currently best space to do so is @DavidZemon's TeamCity Build Server at http://david.zemon.name:8111/?guest=1
Thanks for the very kind offer, but Chip has already sent me a P2-ES development board. It has arrived at my PO Box but I only go into town once a week, so I haven't picked it up yet. Should get it tomorrow.
In the meantime, I have been using my DE-Nano to just just get some basic familiarity and try out a few things. But the Nano is quite limited - e.g. only one cog, not much RAM and the TAQOZ in the boot ROM doesn't work on it (apparently this is because it has no CORDIC functions).
One thing I have learned is that it is currently very difficult for newcomers to get started on the P2. There are very few introductory documents around, and you have to read a lot of separate documents, and also trawl through dozens of forum threads - many of them years old, and containing hundreds of pages of out-of-date information - just to get enough information to get started
I'm sure things will improve once the silicon has stabilized, but it has been hard going, even for someone like me who is very familiar with the P1. An outsider would have no hope at this stage. I wonder if any of the P2 gurus here realize just how difficult it currently is?
One thing I have learned is that it is currently very difficult for newcomers to get started on the P2. There are very few introductory documents around, and you have to read a lot of separate documents, and also trawl through dozens of forum threads - many of them years old, and containing hundreds of pages of out-of-date information - just to get enough information to get started
I'm sure things will improve once the silicon has stabilized, but it has been hard going, even for someone like me who is very familiar with the P1. An outsider would have no hope at this stage. I wonder if any of the P2 gurus here realize just how difficult it currently is?
Ross.
WB Ross!
It's been extremely difficult for me to get started with the P2 as well. I've saved the Parallax Propeller 2 Documentation v32 and Parallax Propeller 2 Instructions v32. Peter's P2 repo is a great place to dig for example code. Quite a wonderful chip but the p2 manual is going to be it's own monster.
Just got my first Catalina C program compiled and running on the P2!
Still a long way to go - this first version is really just a hack of the P1 compiler, and it makes very little use of the new P2 facilities - but at least I can now start having some fun!
Yes, initially it will be exactly the same as the P1 version of Catalina - i.e. a C89 compiler with some C99 additions.
There are some compilers based on LCC that implement compatibility with later ANSI C versions ... I started to look at a few of them. Maybe one day I'll add some of them to Catalina. However, there is so much work to be done just reproducing everything that the P1 version of Catalina could do that I wouldn't hold my breath if I were you!
Been spending a bit of time just tidying up, but I thought I would post a snippet, so attached is an example of a Catalina C program running on the P2 (source, binary and assembly listing). It's a simple multi-cog LED blinker, essentially a C version of Chip's "all_cogs_blink" program. It is intended to run on a bare P2_EVAL board.
This program uses an LMM kernel. I decided to get that working first because it was the easiest, and my propeller and Catalina skills are still both a bit rusty!
Next, I will get the CMM (compact) kernel working. It's the next simplest, and will actually be useful even on the P2 because it will support the largest C programs.
After that, I'll do a P2 native version (i.e. no kernel), which will be the fastest.
Please note there is still a lot of stuff untested, and also that this code has not been optimized. I expect it will get much faster and much smaller in future.
Here is a handy little utility I am working on as part of Catalina. Basically, it adds a C-like preprocessor to p2asm to allow full #include and #ifdef preprocessing. The batch file p2_asm.bat wraps up calling both the preprocessor and then p2asm in a single command. It could be modified for other assemblers if required.
Simply put the enclosed files in the same directory as your p2asm executable, and then use a command like
p2_asm -D symbol -I include_path -o output_file input_file
You can have multiple -D or -I options, but you cannot assign a value to a symbol on the command line (i.e. you can only define it)
Note that I have only tested it enough to get it to do the things I need for Catalina. The sources will be included in the full release of Catalina.
Been spending a bit of time just tidying up, but I thought I would post a snippet, so attached is an example of a Catalina C program running on the P2 (source, binary and assembly listing). It's a simple multi-cog LED blinker, essentially a C version of Chip's "all_cogs_blink" program. It is intended to run on a bare P2_EVAL board.
This program uses an LMM kernel. I decided to get that working first because it was the easiest, and my propeller and Catalina skills are still both a bit rusty!
Next, I will get the CMM (compact) kernel working. It's the next simplest, and will actually be useful even on the P2 because it will support the largest C programs.
After that, I'll do a P2 native version (i.e. no kernel), which will be the fastest.
Please note there is still a lot of stuff untested, and also that this code has not been optimized. I expect it will get much faster and much smaller in future.
Congratulations, Ross! Nice to see Catalina running on P2.
It'd be great if you, @"Dave Hein", and I can come to some agreement on what the Propeller specific libraries should look like for Catalina, p2gcc, and fastspin. @DavidZemon started a thread about language independent APIs for P2 which would be a good place for us to discuss that.
Comments
Thanks, Evan. It seems that only simultaneous writes to the same location are uncertain.
To do a test for simultaneous writes will need more work to compare a read back of each cog ...
On a totally unrelated note, something peculiar has shown up with my testing method. The COGATN mechanism seems to have different timings depending on whether it is odd or even numbered. EDIT: I've got bigger differences with other combinations. I'm guessing it's on a hub rotation scheme, like access to the lock bits and cordic.
Does this mean cogs A and B are not in perfect sync after COGATN for A and WAITATN for B? Main interest here is when the cogs are a LUT-sharing pair. What are the differences in this case, if any?
I just happen to be recording the start and finish times for each test. Up until I added the COGATN/WAITATN part, it was very predictably whatever I specified in the WAITCT1 numbers. But that all changed with a WAITATN. The amount of time to completion differed depending on cog order, with a range of eight clocks. The cogs involved were still starting from the same forward marker as before and running identical code on each cog.
Admittedly, the earlier tests were only of the duration of code running on the receiving cog. It was in effect just verifying that no disturbances occurred when the sending cog modified lutRAM. With WAITATN added it is now measuring the sending cog plus COGATN mechanism instead.
But the fact that there is changes in the measured interval which are solely depending on which cog is sending and which cog is receiving is enough to make the claim. The eight clock range is somewhat of a giveaway too. I guess this all reinforces that WAITCTx is the precise timing tool.
In process I've worked out that the receiving cog exits the WAITATN instruction two clocks after the sending cog exits the COGATN instruction.
Thanks for the info, Evan. Therefore COGATN+NOP in sending cog and WAITATN in receiving cogs synchronizes them. Might be worthwhile adding this to your reference post.
I believe that many of the simpler P1 objects would work on the P2 with just a few minor tweaks and a recompile ... but I can't find if this has been done yet or not.
Am I just looking in the wrong places? There's a lot of stuff I've yet to read on the P2, and I'm probably still missing a lot!
Maybe it is. I don't know what to do about it, though, other than to ask whoever at Parallax manages the current Obex.
nice that you show up again, even if you needed to get sick to do so. The current development around the P2 is sort of exploding, @ersmith is coming out with new versions almost daily, It is hard to keep up.
Sadly there seems to be no one at parallax to collect and publish all the stuff in one place, like me Parallax is new to git and GitHub, so I do not complain.
We lucky guys who could get one of the evaluation P2's are just hammering them to find flaws and most stuff is still just in the forum pages, the Parallax Link you provided is needed and cool, but not yet used by any of the contributors.
So you basically have to hunt down the newest versions of all dev tools and the currently best space to do so is @DavidZemon's TeamCity Build Server at http://david.zemon.name:8111/?guest=1
Enjoy!
Mike
Did you manage to get some hardware?
If not I have some Parallax A7 and A9 Fpga boards that could be sent to you, if useful.
These would let you work on the latest FPGA image for the silicon currently being taped out.
regards
Lachlan
Thanks for the very kind offer, but Chip has already sent me a P2-ES development board. It has arrived at my PO Box but I only go into town once a week, so I haven't picked it up yet. Should get it tomorrow.
In the meantime, I have been using my DE-Nano to just just get some basic familiarity and try out a few things. But the Nano is quite limited - e.g. only one cog, not much RAM and the TAQOZ in the boot ROM doesn't work on it (apparently this is because it has no CORDIC functions).
One thing I have learned is that it is currently very difficult for newcomers to get started on the P2. There are very few introductory documents around, and you have to read a lot of separate documents, and also trawl through dozens of forum threads - many of them years old, and containing hundreds of pages of out-of-date information - just to get enough information to get started
I'm sure things will improve once the silicon has stabilized, but it has been hard going, even for someone like me who is very familiar with the P1. An outsider would have no hope at this stage. I wonder if any of the P2 gurus here realize just how difficult it currently is?
Ross.
WB Ross!
It's been extremely difficult for me to get started with the P2 as well. I've saved the Parallax Propeller 2 Documentation v32 and Parallax Propeller 2 Instructions v32. Peter's P2 repo is a great place to dig for example code. Quite a wonderful chip but the p2 manual is going to be it's own monster.
Just got my first Catalina C program compiled and running on the P2!
Still a long way to go - this first version is really just a hack of the P1 compiler, and it makes very little use of the new P2 facilities - but at least I can now start having some fun!
What level of C support are you aiming for (C89, 99 etc) - Similar to P1?
There are some compilers based on LCC that implement compatibility with later ANSI C versions ... I started to look at a few of them. Maybe one day I'll add some of them to Catalina. However, there is so much work to be done just reproducing everything that the P1 version of Catalina could do that I wouldn't hold my breath if I were you!
This program uses an LMM kernel. I decided to get that working first because it was the easiest, and my propeller and Catalina skills are still both a bit rusty!
Next, I will get the CMM (compact) kernel working. It's the next simplest, and will actually be useful even on the P2 because it will support the largest C programs.
After that, I'll do a P2 native version (i.e. no kernel), which will be the fastest.
Please note there is still a lot of stuff untested, and also that this code has not been optimized. I expect it will get much faster and much smaller in future.
Been having fun too
Simply put the enclosed files in the same directory as your p2asm executable, and then use a command like
You can have multiple -D or -I options, but you cannot assign a value to a symbol on the command line (i.e. you can only define it)
Note that I have only tested it enough to get it to do the things I need for Catalina. The sources will be included in the full release of Catalina.
Designed any multi-P2 boards yet?
I just updated the zip file - seems I had left "echo" on in the batch file (for debugging). Now fixed.
Congratulations, Ross! Nice to see Catalina running on P2.
It'd be great if you, @"Dave Hein", and I can come to some agreement on what the Propeller specific libraries should look like for Catalina, p2gcc, and fastspin. @DavidZemon started a thread about language independent APIs for P2 which would be a good place for us to discuss that.
Regards,
Eric