Shop OBEX P1 Docs P2 Docs Learn Events
Ease of use - P2 vs P1 variant - Page 2 — Parallax Forums

Ease of use - P2 vs P1 variant

2»

Comments

  • jmgjmg Posts: 15,140
    edited 2014-04-06 15:02
    reply moved
  • kwinnkwinn Posts: 8,697
    edited 2014-04-06 15:22
    cgracey wrote: »
    ..........
    .......................................................
    I just thought of something... rather than put a CORDIC in every cog, making them expensive like the Prop2 cogs are, maybe we could just make a pipelined CORDIC that any cog could make a deposit into and then pick up the results umpteen clocks later. That way, the cog stays clean and doesn't get overloaded. I'm thinking of what I'd miss in a Prop1-based chip that the Prop2 has. CORDIC is really useful for signal processing and would be missed. We could make the divider work this way, too, as well as the big multiplier.

    Whether it is used in a P1+ or the P2 I think think this is a fantastic idea. These functions are nice to have at times, but rarely (if ever) required by every cog. Having a single shared functional block keeps the cogs simple, maintains cog equality, and may even allow some extra functionality.
  • potatoheadpotatohead Posts: 10,253
    edited 2014-04-06 15:24
    This:
    If you made a 16-stage CORDIC solver that was shared among 16 cogs, each cog could get an opportunity every 16 clocks to stick something in it during his turn. The hardware cost per cog, aside from the conduit, would be just 1 stage worth of the CORDIC circuitry - three adders. He would have to wait his turn, but the result would come out as soon afterwards as if the CORDIC was his own.

    Is a winner. We, in effect get nearly the same behavior as we did including it in all the COGS, but with one circuit. That's the path forward. Has to be.

    Would the COG have to be stalled? Seems to me, one could just run for a while, then pick up the result later on. Or, do have the stall, but the programmer could make the deposit, run a few instructions, then trigger the stall, if they were really needing the execute time, sort of how waitvid works.
  • mindrobotsmindrobots Posts: 6,506
    edited 2014-04-06 16:02
    potatohead wrote: »
    This:

    Is a winner. We, in effect get nearly the same behavior as we did including it in all the COGS, but with one circuit. That's the path forward. Has to be.

    Would the COG have to be stalled? Seems to me, one could just run for a while, then pick up the result later on. Or, do have the stall, but the programmer could make the deposit, run a few instructions, then trigger the stall, if they were really needing the execute time, sort of how waitvid works.

    Any way the worker engine could just drop the results in a "mailbox" in that cog's memory space? D+1, D+2 if needed?
Sign In or Register to comment.