Shop OBEX P1 Docs P2 Docs Learn Events
Variation on the New Hub Hub Scheme - Page 2 — Parallax Forums

Variation on the New Hub Hub Scheme

2»

Comments

  • dMajodMajo Posts: 855
    edited 2014-05-26 04:00
    Cluso,
    from your design it seems that the fifo to cog data path is 32b wide which means that only one long per clock can be transferred into the cog. More-over the direct connection of the cog to the 0-31 data lines means that the coc can directly(random) read only one long every 16 (only the first long of the 16 addressed at any given time) as in other case this needs a direct connection to all the 512 hub data lines and a mux/shifter eg to read the second, third, fourth... long of the 512bits addressed at any single time.
    I think this is what Chip want to avoid and that all this shift/mux is what he consider power hungry.




    Consider this extravagant idea, perhaps for P2099 ... or even never .... Is just one I have thought once while reading the many others suggestions/ideas, newer analyzed its implications so it well be completely wrong (thus this is NOT a suggestion, it's only to chat a bit and perhaps learn something new from the forum):
    1. If I remember correctly (from Chip) the cog ram is quad port in the sense that in chip design each port is single direction and that moving from parallax hand designed ram to verilog (onsemi) the standard building block is 1 read and 1 write so to have 2 read you have also 2 write even if you do not need the second one. If this is not the case skip the rest.
    2. So you need 1 read port to fetch the opcode, than 2 read ports to read S-D registers and finally 1 write port to write the result (if needed)
    3. Currently I believe the write-result is overlapped to the next opcode fetch to make it all happen in two clock cycles
    4. So during this cycle this leaves one read and one write port not utilized
    5. What if now all the memory is only cog memory so eg (16/32/64 KB) and the hub is only a switch arbitrar (like an ethernet switch) where any cog is able tor read/write any other's memory using these unused read/write ports?
    6. Eg. cog1 can read cog2 while at the same time cog7 can read cog3, if two cogs addresses the same read/write target the source cog id can set the priority. This will allow every cog memory to be available to others every second cycle. If a cog is not used, stopped (cpu/alu only) than its memory is available to others every cycle. Since the read of the other cog probably needs to be done (replace) the S-D fetch and the write is done one stage later this will introduce a one clock stall when passing from between read and write at first access if the destination cog is running while it will be completely transparent if the destination cog is not used or paused.
    7. I think that this requires (Number of cogs)/2 32b data busses in the hub and only to/from cogs gating to the busses.
    8. Perhaps it can be even realizable on a single interconnection between adjacent cogs on the current design ... or a single register can in this way circulate around the cogs (like token ring) to coordinate user functions among various cogs without the need for a hub access.
Sign In or Register to comment.