Consolidated hub slot table mapping
kwinn
Posts: 8,697
There are so many threads on this topic that it's getting hard to follow them. I am starting this thread hoping that all of the suggestions for using a table to assign hub access slots to cogs can be consolidated here. To that end I have made three posts briefly describing the four proposals (as I understand them) so far, and reserved four more for future additions. Feel free to post any corrections, comments, or additional ideas.
Comments
Your 3 & 4 seem a little mangled ?
I do not recall any with split size secondary table, nor any with a separate reload Secondary counter.
The size of 32x4x2 seems to be the common one, with 64 suggested. It is possible to make 32x4x2 <-> 64x4 if that is needed.
Correction would be -> 1 counter (5b or 6b) and 1 Reload.
Verilog of a 32x4x2 is here
http://forums.parallax.com/showthread.php/155561-A-32-slot-Approach-(was-An-interleaved-hub-approach)?p=1266768&viewfull=1#post1266768
In the cases I can think of, with a low-jitter, but low use, high demand Primary, you would want to choose a pairing with that, that was (eg) a HubExec/LMM COG - a Dual counter design would rotate pairings to be almost random ?
Loading choices to write are Nibble, Byte, or Quad, but the faster FPGA RAM Blocks would exclude Quad writes, as they do not support asymmetric DualPort.
Here is the corrected item 4, not quite the same as shown in #1
HUB Alloc, value in [] is the COG given HUB access, drawn from one of Primary(first choice) or Secondary(Primary not used this scan) Primary Table Secondary Table [ReLoad] not |@0 taken [Counter] 0 -> [COGa] -> [COGm] 1 -> [COGb] -> [COGq] 2 -> [COGa] -> [COGn] 3 -> [COGc] -> [COGr] 4 -> [COGa] -> [COGo] 5 -> [COGb] -> [COGs] 6 -> [COGa] -> [COGp] 7 -> [COGc] -> [COGt] | | 31 -> [COG-] -> [COG-] ScanCtr incs at fSys or 200MHz Example shows COGa with 50% Alloc on Primary, (no jitter) 10ns Spacing Reload of 7 (can be 0..31 to allow better matching with COG code rates.) COGb and COGc have 25% Alloc on Primary, (no jitter) 20ns spacing COGa does [B]not[/B] have to use all slots, those that are unused fall-over to Secondary members. Secondary members get a System-known (Slot%-PrimaryUsage) Default is 1:16 (All COGS have same 100ns Slot Repeat Rate at 160MHz ) Alternative methods can exist for Secondary Decision, but same-row is easy to follow, and avoids COG crosstalk issues. Typically Primary is HW critical IO, and Secondary is LMM/HubExec partner. SW can modify Table at any time, and one use case for burst data ping-pong, would swap Primary-secondary(each number represents the cog getting access)
0 1 2 0 1 3 0 1 4 0 1 5 0 1 6 0 1 7 0 1 8 0 1 9 0 1 10 0 1 11 0 1 12 0 1 13 0 1 14 0 1 15
In the above example, the table counter should only count up to 42 (er, 41 if starting from 0)
In the following example, the counter needs to run up to 52 before resetting:
0 1 2 3 0 1 2 4 0 1 2 5 0 1 2 6 0 1 2 7 0 1 2 8 0 1 2 9 0 1 2 10 0 1 2 11 0 1 2 12 0 1 2 13 0 1 2 14 0 1 2 15
EDIT: I'm guessing that's what the "reload register" is for? Sorry for my oversight if so.
I thought someone suggested a dual 16 nibble table and a secondary table for round robin access to slots the first table did not use. I added the reload counter since it would be needed.
I am sure there were proposals for 32 bit primary 16 bit secondary tables with various suggestions for how the secondary table would be used.
As far as I can see the 32 bit primary with user assigned access seems to be the one with the most support so shall we start with that and see which if any of the secondary assignment ideas get the most support even though it may be a moot point now that Chip has proposed an access method?
See my #6 example, a second ReLoad is not needed, but the Primary one certainly is.
The Dual 16 was equal-sizes.
Not that I noticed - there is little point in having a different sized secondary table, and certainly with a shared ReLoad, they are always the same.
Ah, there were options to double in one mode, so a 16xP/16xS <=> 32xP, so maybe that was where you got a split from ? These have same Nibbles, & choice of how they are scanned.
True, but a lot of this drove the new access method.