Links & summary to most recent P16X64A "P2" posts by Chip & Ken
Peter Jakacki
Posts: 10,193
By
yymmdd
Summary --- or view all recent P2 posts by Chip ..or.. Ken
Chip
140728
I chased down the final bug that was inhibiting the fast-write setup for hub streaming - next thing to do is to adapt [it]
Chip
140723
progress update - I came to the final conclusion that ALL memory addresses (both hub and cog) need to be byte-wise
Chip
140702
I've got the assembler modified now for the new instruction set and today I hope to get the boot ROM working properly
Chip
140624
I've got the cog working! The next step is to write the new boot loader. I'm feeling confident about the direction of things
Chip
140616
To reliably accommodate an automatic peripheral in the cog - the FIFO gets priority over RDxxxx/WRxxxx instructions.
Chip
140612
had a meeting with OnSemi today - path to completion is simpler than ever - Hopefully, I'll have an FPGA image soon
Chip
140608
16 cogs compiling with the new egg-beater hub memory - This effort has turned out to be a complete re-design
Chip
140528
PGA Smart Pins - To make something completely flexible, you'd need to get pretty low-level.
Chip
140528
I'm happy to add some circuitry to support a protocol like USB. The only problem is....
Chip
140525
signalling rates of 500MHz - pixel rates of 50MHz. That's 1/3rd the rate needed for 1080p/60.
Chip
140525
doing a reality check on the FIFO - tedious - Once this seems done, I'll integrate it into the cog
Chip
140522
I think I might have the cog FIFO done that talks to the egg-beater hub memory.
Chip
140522
We can have SDRAM on the new chip - at 100MHz - 38 pins - 1 cog
Chip
140521
There will be a video output mode which just takes longs from the hub and outputs them directly to the DACs
Chip
140520
a non-stalling read/write FIFO - longs only though - do we really need byte read and write???
Chip
140518
It's the video that needs the deep FIFO - video pixel timer uses jitter free NCO overflow
Chip
140518
just got back from a father/son campout - 20-stage FIFO - simplify video, hubexec
Chip
140516
new video mechanism tied to system clock - video instructions - 256 LUT
Chip
140515
new memory scheme implemented in Verilog
Chip
140514
New multiple hub scheme - 16 8192x32 memories - distributed addressing
Ken
140512
Hubexec is a possibility but not being designed right now... (time permitting)
Ken
140512
Ken says Chip makes the real decisions about P2
(re hub exec)Ken
140510
P16X64A all the way
Ken
140510
No hub exec? It's a valuable point initially for equal Spin and C support
Ken
140510
P2 = P16X64A
Ken
140510
In favor of simplicity
Chip
140509
what level of simplicity is acceptable? Important features are a must though
Chip
140509
holed up ground-up effort, keeping things as simple and lean as I can
Chip
140501
Going to a 24x24 multiplier increased total ALU area by only 10%
Chip
140501
WAITXX sync to the 2 LSBs of CNT - great idea!
Ken
140430
if it's a snap then throw it in
Chip
140430
differentiate floating point operators
Ken
140429
Floating Point? - we're in this business for Parallax and our customers
Chip
140429
fast multiply instructions (mul/muls) and 64-bit accumulation - neat ideas!
Chip
140429
adding new things via the hub - I'm getting tired of monkeying with cogs
Chip
140429
it might be best to have the cog wait (cordic)
Chip
140429
we could add floating point - all kinds of things are possible
Chip
140428
Every stage can be doing an operation for a different cog (pipelined cordic)
Chip
140412
variable pin threshold
Chip
140412
synchronized smart I/O messages
Chip
140412
every pin is dumb until configured
Chip
140412
running the DAC with level comparator
Chip
140410
open-drain/source mode
Chip
140410
the user doesn't know about the preamble
Chip
140410
You don't have to send a msg to a pin to make it high or low
It seems that Chip and Ken's posts end up being buried in the enthusiasm of forumistas. I am trying to maintain a list for my own sanity and hopefully it will prove useful for others and become a sticky.
Comments
I've given up on that sanity thing but I did save this in my collection of P2(rev2) posts!
Sounds good, I would also include this statement from Chip, as to me is says Hubexec/4 Longs are in the new design
(If I remember later, I will delete later to prevent thread clog)
I didn't suggest that not having hub exec is valuable, but rather that being able to have quick GCC compatibility with the Propeller 2 is valuable to us since we wouldn't need to sink a substantial NRE up front to revise the compiler substantially. Tools are very expensive and having compatibility with prior hardware versions is generally beneficial. Maybe the summary should say "Compatibility with existing GCC work could be fast without hubexec" or something like that.
This is interesting that people think I also have useful contributions to this whole effort. I'm just a normal guy trying to get Chip to finish this project, like you. I guess I see the project from another angle, being inside Parallax, but please understand I have little influence over Chip. Often we're referred to as "Chip and Ken" but it's Chip who makes these decisions - I'm only trying to provide a functional infrastructure to get us where we will go, together.
Maybe another entry in the above log? "Ken says Chips makes the real decisions about P2
Ken Gracey
Chip said this What is going to disrupt simplicity in this design is wide data paths (4 longs) and hub exec. I think those features are important enough, though, that the disruption they cause must be accommodated.
You could check if that means Hubexec has made the cut, as that is how I read that comment ?
Hubexec does not really slow Compatibility with existing GCC, as present P1 modes will still work fine (only better), once ported.
Hubexec will mean slightly more overall work to add the extra 'native' support, but that is not going to affect silicon-time-lines.
Hubexec is already field proven, in multiple FPGA releases.
Hubexec is a possibility but not being designed right now. In speaking with Chip he needed to shelve it for a while to make progress in other parts of the design before he visits this part again. While it's an improvement to GCC (thanks for the explanation) I'd have to understand Chip's actual design time estimate before I'd conclude it's worthwhile for this specific product. These weeks add up.
There were a couple of posts I was thinking of rewording but also at the same time trying to keep it succinct. The idea of a summary at the same time is to also arouse interest in the subject, it's only a click away. I will make some changes but not too many or too wordy.
Chip may be the star player but really he can only succeed because he is part of a team effort and so your input is very valuable, even if you don't think so. Any engineer with his head buried deep in the bowels of a project, especially year after year may not always have the correct perspective. Yes, the decisions are sound within their constraints but one needs to step back and make those decisions with a wholistic and realistic view. This is where the team comes in.
I saw the P3 as a runaway train taking focus away from what P2 was meant to be yet while everyone was busy shovelling coal there was no one actually keeping an eye on where it was going. Faster, faster, faster, the cries could heard while drowning out the signals to stop at the next station. Isn't that where you come in Ken?
Everyone: Bear in mind too that I have only just started this list so I will refine it bit by bit.
It might be best to cut some of the extended features of hubexec to a later revision though.
What He Said! ^^^^^
Yes, this is where I fit in, exactly. While I am charged with supporting an ongoing R&D environment I also have the responsibility of assuring business viability. This means I continually urge Chip to complete the project and avoid forks along the way. We've got to get this done.
Ken Gracey
I do not want to route the decisions in any way, but the hubexec don't brake the GCC compatibility, imho.
If the other opcodes remain more or less standard the GCC compiler can continue to generate binaries with LMM, like today, even if hubexec is available (it's enough to not use it). In second phase, if someone will value the investment worthwhile (gained.speed/costs ratio), it can be reworked ... or simply the hubexec will be for pasm/spin developers only.
sw vs hw. I think that the above is more hardly to say in regards to silicon (except you really haven't already planned new mcu models in a few month after the p16x64a release). If for the next chip (silicon) there will we 2 years or more of waiting perhaps the hubexec should be considered, even if not publicly disclosed, until it can be supported by tools.
Chip:
http://forums.parallax.com/search.php?do=finduser&userid=41126&contenttype=vBForum_Post&showposts=1
Ken:
http://forums.parallax.com/search.php?do=finduser&userid=40442&contenttype=vBForum_Post&showposts=1
View only prop 2 recent posts by:
Chip:
http://forums.parallax.com/search.php?do=finduser&userid=41126&contenttype=vBForum_Post&showposts=1&forumchoice[]=97
Ken:
http://forums.parallax.com/search.php?do=finduser&userid=40442&contenttype=vBForum_Post&showposts=1&forumchoice[]=97
the links you used don't work anymore, because the search IDs from the forum software expire after a while.
Please use these ones instead:
Chip
http://forums.parallax.com/search.php?do=finduser&userid=41126&contenttype=vBForum_Post&showposts=1&forumchoice[]=97
Ken
http://forums.parallax.com/search.php?do=finduser&userid=40442&contenttype=vBForum_Post&showposts=1&forumchoice[]=97
They won't be shown in the browsers url field, but work more reliably since they invoke a true search instead of opening a pre-cached results page.
Thanks, Clemens
Edit: Also the Letterspace between "vB" and "Forum" must be removed from the link. The Forum Software keeps auto-parsing that in, I don't know why...
I've just edited the links and double checked that it is working okay, thanks for that.
Always refer back to the top post for updates.