Shop OBEX P1 Docs P2 Docs Learn Events
We're looking at 5 Watts in a BGA! - Page 32 — Parallax Forums

We're looking at 5 Watts in a BGA!

1293032343537

Comments

  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-05 22:36
    Hub bandwidth, no caching.

    Every op code fetch, even non-hub ops, will take a full hub cycle.

    Eight way unrolled LMM loop executes simple (non-hub) instructions in 18 clock cycles (16 + 16/8 loop overhead)

    Due to no cache, simple non-hub ops would be executed in 16 clocks on a P16E32

    As the loop overhead is 2 clocks / 16, 1/8th, that gives hubexec a 12.5% advantage.

    If there are cog helper routines (the usual suspects, FCALL, FJMP, FRET, CONSTxxx) those will not need hub cycles and run faster, but still much slower than having all the nice LOC*, JMP* CALL* 16 bit hub address instructions.

    I guesstimated that would raise the P1 simple hubexec advantage to 25% over LMM.

    Once you add back caching, the nice hubexec instructions, you are 50% the way back to the P2, which is why it is a bad idea to go to a P16E32 first.
    David Betz wrote: »
    Why do you say only 25% faster?
  • koehlerkoehler Posts: 598
    edited 2014-04-05 23:02
    koehler,

    I run a real consulting / design company - that is my "day" job, and I do not reveal sales numbers. It is none of anyone's business.

    With all due respect, what have you contributed? What right do you have to say that Ross' or my advice is valueless?

    I've contributed LMM. many optimizations, a lot of contribution to the P2 design, partially responsible for saving at least one shuttle run. On a P1, I have made a product with 256 color high resolution bitmapped graphics with 20MB/sec external memory on a Propeller 1 - something that was considered impossible. I am not going to waste time going into more detail, as I do not have to justify anything to you..

    Ross has also contributed a LOT over the years, including the Catalina C compiler.

    In the forums, the normal rule is, make technical arguments, not ad hominem attacks.

    Bill, for someone who's detailed repeatedly how logical you are, you seem to have missed the actual context of my comment. EDIT- Actually, I messed up.
    However, both it, and your opinion should have read:
    However, both it, and your opinion, mine, and everyone else's.
    I'm smart enough at least to know that you probably do know the Prop inside out, sideways, and backwards and forwards.
    Thats one reason I find your exchanges with rmg so interesting to follow. You both are obviously professionals in a sea of enthusiasts.

    However, my specific comment is I think, still valid.
    For the most part, your's, Ross's, mine, and everyone else's 'opinion' on what path is best is useless to Parallax.
    I did CYA though, insofar as and unless someone here were in fact buying commercial quantities, as (1) and only (1) person in this thread has attested too. And since you don't want to reveal whether or not you are such a customer, you can't complain that you're not accounted as one either.

    You may 'want' to have the next product be a 4,5,6 P2 Cog device, thats fine. That doesn't mean that its actually the best plan for Parallax.
    Its quite possible a lot of the commercial quantity customers find the downgrade to 4 Cogs, addition of multi-threading to be enough to not embrace.
    What does Parallax do then? What of comparable value do all the forumista pushing for P2 or death lose?


    You have no problem dishing-out 'sarcasm' and make a mountain out of a mole hill regarding what was really a fair, open to everyone poll.
    But someone dare ask you a legitimate question in a bit of a cheeky manner, and its all all out ad hominem attack...


    I think if you read the next post after that one, you'd see where I also commented that someone's post about Ross seemed a rather poor strawman ambush on someone who has demonstrably given real value back to the Prop community.

    I think a number of folks including myself have already given the advise that Ken was already probably going to be doing next week anyways.
    Disregard consensus polls, and opinions on the forum, and see what path your current large customers are willing to go along with.

    Feel free to ignore my posts in the future.
  • koehlerkoehler Posts: 598
    edited 2014-04-05 23:15
    No problem here either.
    Wasn't trying to speak for Ross either, it did honestly just seemed like one thread you were frustrated with your FPGA not being used/updated, and the previous one where generic terms were given impossible dates that were then knocked down, and the name of Ken accidentally invoked.

    I am apparently a no-body, so never mind what I think anyways....

    Cheers,

    Fred


    mindrobots wrote: »
    It was not meant as an unfair attack at Ross. I greatly respect Ross for the selfless and thankless contributions he makes to the community, Catalina is a brilliant piece of work and were I a C programmer, I would be using it. The terms of "now", "soon", "easy" and other ambiguous terms have been thrown around by many, he was the last poster I read using those terms. I should have prefaced my definitions with "This is what I think" and closed it with "What do you mean by those terms?" If that caused Ross any offense, I am sorry for not wrapping my post properly. I am sorry for getting frustrated by all the technical bickering.

    Good night!
  • RossHRossH Posts: 5,336
    edited 2014-04-05 23:20
    David Betz wrote: »
    Why do you say only 25% faster?

    Yes, I thought Bill had established that the P16X32B would be between 2 and 5 times faster. We can argue whether it is closer to 2 than 5, but it is certainly not just "25%"

    In any case, after reading through the last page or two of posts here, I believe I can honestly say two things:
    1. I am not offended by anyone's posts. Everybody here has the right to disagree with my opinions, no matter how silly that makes them appear! :lol:
    2. The P16X32B would appear to be a perfect fit for the immediate needs Parallax's customers have evinced - i.e. a code-compatible P1 with faster speed, extra RAM, extra I/O pins and better analog capabilities.
    Ross.
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-05 23:34
    koehler,

    I have no trouble believing that you may not have meant to convey the message that your original posting did.

    Please re-read your message, as originally written, and keep in mind that I tend to be quite literal minded, unless I *KNOW* something is meant in jest.

    You specifically stated that you found my opinion was valueless. That is not a "nudge-nudge wink-wink ha-ha" statement. There was no indication of humour.

    Thus, you received a response appropriate to what you wrote - even if that is not what you meant.

    Edit: I never said you are a nobody.

    If you question someones business, and state their opinions are valueless, don't be surprised if they are not pleased, and question you in turn.

    koehler wrote: »
    Bill, how many thousand units/yr can Parallax then expect you to order?

    Ross's thread ( I assume he started it ) is a pretty useful measure as anyone for/against on the forum can say aye/nay.

    However, both it, and your opinion as to what Parallax should actually commit to doing, and spending another $50-100,000 on, are equally-- value-less.
    Actually, unless you actually do routinely order large numbers of P1's, or will do so with P2's, Ross's thread has more merit on sales alone.

    What really matters, ethically speaking, is what the customers who make up the bulk of Parallax's revenue are looking for, correct?
    If this were Atmel or Microchip with the deep pockets, then it'd be fine.
    Parallax is at least somewhat Capitol constrained, so having them make a decision based on what is probably less than a couple thousand units is not in their best, long term interests.
    Especially if anyone wants an eventual P3.

    koehler wrote: »
    Bill, for someone who's detailed repeatedly how logical you are, you seem to have missed the actual context of my comment. EDIT- Actually, I messed up.
    However, both it, and your opinion should have read:
    However, both it, and your opinion, mine, and everyone else's.
    I'm smart enough at least to know that you probably do know the Prop inside out, sideways, and backwards and forwards.
    Thats one reason I find your exchanges with rmg so interesting to follow. You both are obviously professionals in a sea of enthusiasts.

    However, my specific comment is I think, still valid.
    For the most part, your's, Ross's, mine, and everyone else's 'opinion' on what path is best is useless to Parallax.
    I did CYA though, insofar as and unless someone here were in fact buying commercial quantities, as (1) and only (1) person in this thread has attested too. And since you don't want to reveal whether or not you are such a customer, you can't complain that you're not accounted as one either.

    You may 'want' to have the next product be a 4,5,6 P2 Cog device, thats fine. That doesn't mean that its actually the best plan for Parallax.
    Its quite possible a lot of the commercial quantity customers find the downgrade to 4 Cogs, addition of multi-threading to be enough to not embrace.
    What does Parallax do then? What of comparable value do all the forumista pushing for P2 or death lose?


    You have no problem dishing-out 'sarcasm' and make a mountain out of a mole hill regarding what was really a fair, open to everyone poll.
    But someone dare ask you a legitimate question in a bit of a cheeky manner, and its all all out ad hominem attack...


    I think if you read the next post after that one, you'd see where I also commented that someone's post about Ross seemed a rather poor strawman ambush on someone who has demonstrably given real value back to the Prop community.

    I think a number of folks including myself have already given the advise that Ken was already probably going to be doing next week anyways.
    Disregard consensus polls, and opinions on the forum, and see what path your current large customers are willing to go along with.

    Feel free to ignore my posts in the future.
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-05 23:40
    I gave a detailed response to David's question, sorry, I don't have the link handy, will try to find it for you later see #932, five messages up.

    A simple hubexec (no cache lines in hardware, only 32 bit wide hub bus, exactly like on a P1, which is the stated goal of P16E32) could only be slightly faster than LMM. Quite simply it is due to hub windows, and no cache.

    Add WIDE bus, 4 lines of icache, one of dcache to P16E32 (just like the P2 design already has) and of course hubexec performance on it will improve greatly!

    Add the nice LOC* / JMP / CALL instructions with embedded 16 bit hub addresses, and the performance for a 200MHz P16E32 for hubexec will be close to a P2 @ 100Mhz

    Add the rest of the P2 instructions (PTRA/B/X/Y, INDA/B, AUX) and the performance will be basically identical.

    But that was not the intent of P16E32. My calculations were based on a minimally changed P16E32... after all, the basic stated goal was to keep it the same as a P1 cog.
    RossH wrote: »
    Yes, I thought Bill had established that the P16X32B would be between 2 and 5 times faster. We can argue whether it is closer to 2 than 5, but it is certainly not just "25%"

    In any case, after reading through the last page or two of posts here, I believe I can honestly say two things:
    1. I am not offended by anyone's posts. Everybody here has the right to disagree with my opinions, no matter how silly that makes them appear! :lol:
    2. The P16X32B would appear to be a perfect fit for the immediate needs Parallax's customers have evinced - i.e. a code-compatible P1 with faster speed, extra RAM, extra I/O pins and better analog capabilities.
    Ross.
  • RossHRossH Posts: 5,336
    edited 2014-04-05 23:44
    I gave a detailed response to David's question, sorry, I don't have the link handy, will try to find it for you later, showing why a simple hubexec (no cache lines in hardware, only 32 bit wide hub bus, exactly like on a P1, which is the stated goal of P16E32) could only be slightly faster than LMM. Quite simply it is due to hub windows, and no cache.

    I don't know what a P16E32 is. I am talking about Chip's proposed 200Mhz, P16X32B. That will easily be much more than twice as fast as the P1.

    Ross.
  • msrobotsmsrobots Posts: 3,701
    edited 2014-04-05 23:45
    add a

    3. Cheaper to get tested/produced because proven design and existing DevTools/Tutorials/Documentation. Just do not add to much to it.

    This could go faster to production as reworking the P2. And as Chip stated the P1 cogs are 'simple' and 'clean' to him. So I guess without adding Hubexec and all the fancy P2 stuff doing 16 with 512kb ram MAY be doable way more easier as with adding all of this.

    This will just delay P2. But can go into production and ease the pressure on Parallax and some of their customers holding back since years or simple using 'other' chips...

    And it would give Chip a break going back to the roots of P1, to recreate the excitement he had producing the first 'wonder'.

    Because I have to disagree a little bit with Ken. Chip is not using magic. I know that. But he is just building magical chips.

    Enjoy!

    Mike
  • pedwardpedward Posts: 1,642
    edited 2014-04-05 23:57
    Ken Gracey wrote: »
    Those customers have asked for:

    - more RAM
    - faster speed
    - code protect
    - A/D

    . . .and those who didn't use it due to language choices would like efficient use of C.

    Ken Gracey

    And this is why I'm going to say again: Reduce the complexity of the P2 COG so that you can reduce power footprint.

    I can't imagine the power envelope wasn't modeled before the last shuttle run, so if the last shuttle run was PEP compatible with the old package, why the heck are we talking 4 cogs and potentially 4-5W at this time?

    It seems so obvious to me that all the cheerleading has lead the chip off course and into an area where all of these neat theoretical features have hamstrung the rest of the development objective.

    I strongly recommend paring back the logic to just have hubex with a single cache line, get rid of the hubex logic for the other 3 threads, get rid of the task switching, and rollback any of the instruction complications that compromise manufacturability.

    Right now there is talk of 4 cogs for the P2, 16 cogs for the P1B, this dichotomy is unreal. Yes the P2 has multi-threading, but do I have to remind everyone that this is achieved by interleaving the 4 pipeline stages? You divide the base instruction clock by 4, plus overhead due to threading (jumps, etc).

    Hubex with 1 thread makes C really accessible and allows code to be generated easily -- making efficient use of multiple pipeline threads with compiled C code is going to be much more difficult and may not be achievable with the current GCC resources available. (I said *efficient*)

    Having 4 cogs is going to mean just 4 processes the vast majority of users that just want to use the chip. Accessing the threading from a high level language will be possible, but it won't be clean looking at all.

    I am quite disheartened that the P2 development seems to have derailed due to a crazy amount of suggestions since the last shuttle run. The objective of this period was to *fix* the P2 from the last shuttle run and remedy a couple of shortcomings.

    I was initially against the hubex because I told Chip it would sideline development for 4 months to get it right. Well, in those 4 months a *lot* more has happened than just hubex, the kitchen sink made it into the P2, and now you can use it as a coffee warmer!!!

    Yeah, Bill is going complain about what I've written above, maybe jmg will weigh in too, but the bottom line is that the P2 as envisioned right now is *NOT MANUFACTURABLE*.

    Simply cutting off appendages to make it fit a PEP is cutting away the trademark that made the Propeller special: 8 cogs. There is tons of code right now that depends on having 8 resources. Cutting them in half, then having to figure out how to mix 4 of your previously separate cogs into 1 cog is just making life more difficult for developers, the customers who buy the product. Let's not forget that if you divide the cogs by 2, you get half the counters, so for applications that previously required a lot of counters, they may not fit the 4 cog P2.
  • jmgjmg Posts: 15,140
    edited 2014-04-06 00:03
    pedward wrote: »
    There is tons of code right now that depends on having 8 resources. Cutting them in half, then having to figure out how to mix 4 of your previously separate cogs into 1 cog is just making life more difficult for developers, the customers who buy the product. Let's not forget that if you divide the cogs by 2, you get half the counters, so for applications that previously required a lot of counters, they may not fit the 4 cog P2.

    That is sounding like a strong argument for 4 COG P2 plus (at least) 4 P1E COGS to give 8 (or more) :)
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-06 00:06
    See #932

    For cog-only code, you are absolutely correct. five times faster, if there are no hub instructions.

    Twice as fast, if performing hub-synchonized code such as LMM, maybe 2.3x as fast with the LMM helper instructions in the cog.

    Roughly 2.25x to 2.5x faster than p1 lmm using simple hubexec (no new hub jump/call/ret instructions, no cache, 32 bit wide long hub access, just like p1)

    Definitely no faster, due to lack of any caching, and every single hub access taking 8 mip-cycles (16 clock cycles at 200Mhz, but 8 dual-clock instruction cycles)

    I know you will understand once you read #932, and my other response to you.

    P16E32 is the nickname I found in the pro-P1 16 cog thread has come up with to describe the proposed 200Mhz, two clocks per instruction, 16 exact P1 cog chip they would like. I simply adopted their terminology, as it is descriptive, nice, and short. (or my memory has a parity error, and replaced an X with an E)
    RossH wrote: »
    I don't know what a P16E32 is. I am talking about Chip's proposed 200Mhz, P16X32B. That will easily be much more than twice as fast as the P1.

    Ross.
  • koehlerkoehler Posts: 598
    edited 2014-04-06 00:22
    Bill, I'm a big boy, I have no problem admitting my mistakes.

    However, lets be honest, because literal minded-ness doesn't explain your post.
    If it did, it would have been a bit different as its pretty clear from my post that my comment related to the value of posters vis-a-vis the big picture for Parallax, ie Revenue. and big capitol outlays.
    Its clear in the sentence directly after my naming yourself and Ross, and twice again in the paragraph below that.
    Being literal, the sentence where I also explicitly say that it is so, unless you happen to be a big commercial customer would have driven that home.

    More likely what happened is your one of the top guys on the forum.
    Its acceptable to you, to publicly dis someone else's poll as rigged or duplicitous.
    However if someone dares to question you, you take umbrage.
    If you are literally minded, you should recognize this as a bit double-standard-ish.

    No worries, I fly off the handle sometimes before fully comprehending something too.

    We can discuss/argue/ignore off thread.
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-06 00:24
    I need to go sleep, so I'll try to make this short :)

    1) I've certainly never heard Chip mention that the last shuttle run modeled the power envelope, or any figures. That does not mean there was no such analysis. Chip is the only one who knows for sure.

    2) hubexec with a single cache line will immediately cut hubexec performance in half (pre-fetch not possible, small loops don't fit, more)

    3) you are correct, the four tasks are interleaved pipeline stages. The threads are a software layer on top, to easily add hubexec threads.

    4) the current minimal support for threads is the same as the enhanced debug support, and would make implementing pthreads much more efficient

    5) your coffee warmer only consumes 3W and has eight 100MHz cogs? (humour)

    6) Good point about counters.

    Nope. Not complaining.

    Showing result of suggested feature removal (2), adding info (1,3,4), trying to inject humour (5), agreeing with one of your points (6)

    See my other posts. 4 P2 cogs is way more than 8 p1 cogs.

    (Note: I would like 8 P2 cogs, but Chip says they don't fit, so I am happy with 4)
    pedward wrote: »
    And this is why I'm going to say again: Reduce the complexity of the P2 COG so that you can reduce power footprint.

    I can't imagine the power envelope wasn't modeled before the last shuttle run, so if the last shuttle run was PEP compatible with the old package, why the heck are we talking 4 cogs and potentially 4-5W at this time?

    It seems so obvious to me that all the cheerleading has lead the chip off course and into an area where all of these neat theoretical features have hamstrung the rest of the development objective.

    I strongly recommend paring back the logic to just have hubex with a single cache line, get rid of the hubex logic for the other 3 threads, get rid of the task switching, and rollback any of the instruction complications that compromise manufacturability.

    Right now there is talk of 4 cogs for the P2, 16 cogs for the P1B, this dichotomy is unreal. Yes the P2 has multi-threading, but do I have to remind everyone that this is achieved by interleaving the 4 pipeline stages? You divide the base instruction clock by 4, plus overhead due to threading (jumps, etc).

    Hubex with 1 thread makes C really accessible and allows code to be generated easily -- making efficient use of multiple pipeline threads with compiled C code is going to be much more difficult and may not be achievable with the current GCC resources available. (I said *efficient*)

    Having 4 cogs is going to mean just 4 processes the vast majority of users that just want to use the chip. Accessing the threading from a high level language will be possible, but it won't be clean looking at all.

    I am quite disheartened that the P2 development seems to have derailed due to a crazy amount of suggestions since the last shuttle run. The objective of this period was to *fix* the P2 from the last shuttle run and remedy a couple of shortcomings.

    I was initially against the hubex because I told Chip it would sideline development for 4 months to get it right. Well, in those 4 months a *lot* more has happened than just hubex, the kitchen sink made it into the P2, and now you can use it as a coffee warmer!!!

    Yeah, Bill is going complain about what I've written above, maybe jmg will weigh in too, but the bottom line is that the P2 as envisioned right now is *NOT MANUFACTURABLE*.

    Simply cutting off appendages to make it fit a PEP is cutting away the trademark that made the Propeller special: 8 cogs. There is tons of code right now that depends on having 8 resources. Cutting them in half, then having to figure out how to mix 4 of your previously separate cogs into 1 cog is just making life more difficult for developers, the customers who buy the product. Let's not forget that if you divide the cogs by 2, you get half the counters, so for applications that previously required a lot of counters, they may not fit the 4 cog P2.
  • RossHRossH Posts: 5,336
    edited 2014-04-06 00:25
    Roughly 2.25x to 2.5x faster than p1 lmm using simple hubexec (no new hub jump/call/ret instructions, no cache, 32 bit wide long hub access, just like p1)

    Ok, 2.5 for "bare-bones" LMM. I still think it will be more with caching and for CMM, but I'm not going to argue it since we can't actually benchmark it.

    But 2.5x means it is significantly faster than the P1, and so it would seem that the P16X32B is exactly what Parallax's customers are clamoring for.

    Ross.
  • potatoheadpotatohead Posts: 10,253
    edited 2014-04-06 00:31
    Everybody here has the right to disagree with my opinions, no matter how silly that makes them appear!

    One of the reasons I like you Ross! Nice zinger! Filed away for future use. :) Carry on all.
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-06 00:37
    With FCACHE, totally agreed, but that depends on how well the compiler handles FCACHE, and flib (or equivalent). Please read the first post of my benchmark thread, I also gave numbers with FCACHE. I gave the source code, showed the cycle calculations.

    If the P16xxxxx cogs are kept exactly the same as the P1 cogs, no caching, etc., then we can later run the exact same P1 LMM binaries on emulated P16 cogs, and get a nice set of results for different benchmarks. My calculations indicate that the code running on a P16 @ 200Mhz will be 2X (hub bound code) - 5X (almost no hub access, 99% of time spent in cog FCACHE'd code - ie FFT) the speed of the same code running on a P1 @ 100Mhz.

    With "decent" non-trivial fcache utilization of something that fits totally in the fcache, and makes no hub references, it can approach pasm speed. If the pasm code hits the hub cycle every hub cycle, even in an fcache, not a huge win. So, FFT - much faster. STRCPY - 2x P1 speed.

    I think David Hein's simulator could be converted to model the P16X32B (P16E32) and run benchmarks.

    I tried to provide a fairly simple, middle of road benchmark, however I suspect few actually read the code, and many just disbelieved the results without checking the provided source and calculations.

    FYI, not a jab, just the questions I have been answering indicate that, as the answers usually were already in my admittedly long post.
    RossH wrote: »
    Ok, 2.5 for "bare-bones" LMM. I still think it will be more with caching and for CMM, but I'm not going to argue it since we can't actually benchmark it.

    But 2.5x means it is significantly faster than the P1, and so it would seem that the P16X32B is exactly what Parallax's customers are clamoring for.

    Ross.
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-04-06 00:55
    koehler,

    I've been having a very busy day. I interpreted your posting literally. My response was valid.

    Regarding the post I am responding to, in it:

    - you imply that I lied when I said that I interpreted your post literally
    - you imply I "dis" people who do not "dis" me first
    - you imply there is a double standard
    - I did not fly off the handle, I responded to a verbal attack

    I strongly advise you to drop this, I do not have time to continually correct you.
    koehler wrote: »
    Bill, I'm a big boy, I have no problem admitting my mistakes.

    However, lets be honest, because literal minded-ness doesn't explain your post.
    If it did, it would have been a bit different as its pretty clear from my post that my comment related to the value of posters vis-a-vis the big picture for Parallax, ie Revenue. and big capitol outlays.
    Its clear in the sentence directly after my naming yourself and Ross, and twice again in the paragraph below that.
    Being literal, the sentence where I also explicitly say that it is so, unless you happen to be a big commercial customer would have driven that home.

    More likely what happened is your one of the top guys on the forum.
    Its acceptable to you, to publicly dis someone else's poll as rigged or duplicitous.
    However if someone dares to question you, you take umbrage.
    If you are literally minded, you should recognize this as a bit double-standard-ish.

    No worries, I fly off the handle sometimes before fully comprehending something too.

    We can discuss/argue/ignore off thread.
  • Heater.Heater. Posts: 21,230
    edited 2014-04-06 02:07
    Bill
    No...AUX is needed for...


    And that is why the P2 is in a bit of a Chernobyl melt-down.


    Everything is required for everything:)


    In this case, who needs CLUT? Only those who want video. Who want's video?. Not so many. Fast stack is nice but I would rather my C/C++ has it's stack in HUB. No idea bout the LIFO/FIFO.

    koehler,
    The premise of the Prop has been simplicity, and interruptless, single-threading functionality.
    Yes, that's one if it's most major attractions. That and the ease of doing I/O. "All pins are equal" and all that.
    The P2 option now available appears to jettison that simplicity, and require multi-threading. Without useful interrupts at that.
    I don't think it's so bad. In theory hardware scheduled threads, instruction by instruction interleaved as they are on the P2, are indistinguishable to the programmer from parallel processors. Apart from speed of course.


    We may not have reached that degree of transparency with the PII threads but I imagine Spin could be tweaked to start threads as easily as it starts COGs. Same in C/C++.


    Interrupts are not required or even useful in any case. What we have here is a much simpler "event driven" programming model.
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2014-04-06 03:03
    I'm really bummed right now, because going down to 4 cogs pretty much kills the P2 for me. :/

    I really hate the idea of having to do the multitasking thing to get enough parallel stuff happening. Squeezing 4 cog drivers into 1 cogs memory is a drag. You also have to constantly be aware of the multitasking issues and limitations. It's going to be really un-fun to code.

    Most of the "real" P1 projects I have worked on (or am working on) utilize 6-8 cogs, and several of them are using most or all of the cogs memory. I'd MUCH prefer nuking a bunch of features and reducing HUB memory to keep 8 cogs on the P2.

    For me 8 verses 4 cogs is the difference between coding the on the P2 being fun verses it being a chore (that I don't want to do, and probably wont).
  • cgraceycgracey Posts: 14,133
    edited 2014-04-06 03:12
    Roy Eltham wrote: »
    I'm really bummed right now, because going down to 4 cogs pretty much kills the P2 for me. :/

    I really hate the idea of having to do the multitasking thing to get enough parallel stuff happening. Squeezing 4 cog drivers into 1 cogs memory is a drag. You also have to constantly be aware of the multitasking issues and limitations. It's going to be really un-fun to code.

    Most of the "real" P1 projects I have worked on (or am working on) utilize 6-8 cogs, and several of them are using most or all of the cogs memory. I'd MUCH prefer nuking a bunch of features and reducing HUB memory to keep 8 cogs on the P2.

    For me 8 verses 4 cogs is the difference between coding the on the P2 being fun verses it being a chore (that I don't want to do, and probably wont).


    I agree. Four cogs feels very claustrophobic. It can be argued that they are so much more powerful than Prop1 cogs, but you'd have to carefully mix programs into them - which would NOT be fun. I like the feeling of being able to fire up another cog without any other contingencies.

    Tonight I looked through the Prop2 Verilog to see about reducing the WIDEs back to QUADs, to facilitate an efficient 4-clock hub cycle. It turns out it would be very disruptive to do that, and it would be moving the design in a direction that it shouldn't be going in. That thing just needs a way smaller process to be viable. Trying to do it in 180nm is a mess of compromises.
  • jmgjmg Posts: 15,140
    edited 2014-04-06 03:19
    cgracey wrote: »
    I agree. Four cogs feels very claustrophobic. It can be argued that they are so much more powerful than Prop1 cogs, but you'd have to carefully mix programs into them - which would NOT be fun. I like the feeling of being able to fire up another cog without any other contingencies.

    Then why not add some P1E Cogs to a group of P2 COGS ?
    Users get a superset of P1 they can easily ramp, and power users get some P2 COGs.
    Hubexec come in P2, so is not needed in P1E, keeping things simple.
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2014-04-06 03:32
    Chip,
    I truly think the best path for P2 is to keep everything including all 8 cogs, and figure out a path that gets you down to the smaller process that will make it workable.

    If that path means making the stepping stone P1E (or whatever it's called today), then fine. if it means something else, then fine. I'll help either way.
  • Brian FairchildBrian Fairchild Posts: 549
    edited 2014-04-06 04:16
    cgracey wrote: »
    Four cogs feels very claustrophobic. It can be argued that they are so much more powerful than Prop1 cogs, but you'd have to carefully mix programs into them - which would NOT be fun...
    ...That thing just needs a way smaller process to be viable. Trying to do it in 180nm is a mess of compromises.

    Doesn't this encapsulate the P2 problem in a nutshell?

    To be a viable chip the P2 has to move onto a smaller process and making that move will cost $$$.
  • roglohrogloh Posts: 5,122
    edited 2014-04-06 04:22
    jmg wrote: »
    Then why not add some P1E Cogs to a group of P2 COGS ?
    Users get a superset of P1 they can easily ramp, and power users get some P2 COGs.
    Hubexec come in P2, so is not needed in P1E, keeping things simple.

    I've been wondering the same recently but there are some issues to consider....

    For example if you had a device with 4 P2 + 4 P1 COGs combined

    Pros:
    Could potentially reuse existing some P1 codebase giving an instant step up for P2. Though I/O needs consideration and complicates this a whole lot.
    Extra P1 COGs could still do all deterministic I/O stuff, no hubexec, no tasking, leaving P2 COGs for more powerful things
    Eases/delays the transition to P2 for existing P1 users

    Cons:
    How on earth do you boot the thing? How to spawn P1 COGs from P2 code and vice versa?
    Tools could be a total nightmare to manage if not integrated well, needing both P1 and P2 objects in your app using two instruction sets which is very weird indeed
    Non-uniform system, requires careful planning to partition between P1 and P2 COGs for best performance
    New P2 users have to learn old P1 stuff as well as the new P2 stuff, quite a lot of potential baggage to deal with
    Might be a very complex hardware development to integrate COGs together, with more opportunities for mistakes/problems
    Still may not fit die size/budget

    I think the cons do significantly outweigh the pros there. I don't like it much at all.
  • jmgjmg Posts: 15,140
    edited 2014-04-06 04:22
    To be a viable chip the P2 has to move onto a smaller process and making that move will cost $$$.

    I would phrase that a little more precisely.
    To be viable as a [8 x P2 COG] chip (using current P2 COGS) it has to move onto a smaller process and making that move will cost $$$.
    There are other solutions possible at 180nm, that still deliver a P2 COG.
  • Heater.Heater. Posts: 21,230
    edited 2014-04-06 04:24
    Mixing up P1 and PII style COGS is a total nightmare of an idea.
  • ColeyColey Posts: 1,108
    edited 2014-04-06 04:26
    Heater. wrote: »
    Mixing up P1 and PII style COGS is a total nightmare of an idea.

    Why?
  • cgraceycgracey Posts: 14,133
    edited 2014-04-06 04:29
    Coley wrote: »
    Why?

    ugly.jpg
    320 x 314 - 31K
  • jmgjmg Posts: 15,140
    edited 2014-04-06 04:31
    rogloh wrote: »
    I've been wondering the same recently but there are some issues to consider....

    For example if you had a device with 4 P2 + 4 P1 COGs combined

    Pros:
    Could potentially reuse existing some P1 codebase giving an instant step up for P2. Though I/O needs consideration and complicates this a whole lot.
    Extra P1 COGs could still do all deterministic I/O stuff, no hubexec, no tasking, leaving P2 for more powerful things
    Eases/delays the transition to P2 for existing P1 users

    Cons:
    How do you boot the thing?
    Tools could be a total nightmare to manage if not integrated well, needing both P1 and P2 objects in your app using two instruction sets which is very weird indeed
    Non-uniform system, requires careful planning to partition between P1 and P2 COGs for best performance
    New P2 users have to learn old P1 stuff as well as the new P2 stuff, quite a lot of potential baggage to deal with
    Might be a very complex hardware development to integrate COGs together, with more opportuntities for mistakes/problems
    Still may not fit die size/budget

    I think the cons do significantly outweigh the pros there.

    You have missed the biggest issue : 8 x P2 COGS is not a solution and 8 x P1 COGs is not a large enough step.
    None of the cons you list are brick walls, in the same way a Power Envelope is a brick wall.

    COGS timeslice into the HUB just like they do now, A P2 cog does not care if his neighbour is P1E or P2
    Yes it is non uniform, that is the strength - it allows a device to exist, that otherwise would not.
    Yes, Software does the housekeeping stuff, that is what it is good at.
  • cgraceycgracey Posts: 14,133
    edited 2014-04-06 04:33
    jmg wrote: »
    You have missed the biggest issue : 8 x P2 COGS is not a solution and 8 x P1 COGs is not a large enough step.
    None of the cons you list are brick walls, in the same way a Power Envelope is a brick wall.

    COGS timeslice into the HUB just like they do now, A P2 cog does not care if his neighbour is P1E or P2
    Yes it is non uniform, that is the strength - it allows a device to exist, that otherwise would not.
    Yes, Software does the housekeeping stuff, that is what it is good at.


    I agree it would be a way forward, but I'm afraid it could overwhelm people who'd be faced with two different things to learn. It could really complicate the tools, like Heater pointed out.
This discussion has been closed.