PISA codegen syntax issues

[raghup17]

Starting this issue to track all PISA codegen issues. Not sure how this worked before, but I found a few issues with control syntax in ArgInOutDesign:

• 1. tokenDownLUT: Why does this array of maps have 8 maps? Also, each map has a "mux" input. Is this the mux in front of the tokenDownLUTs aka syncTokenMux? If so, the first mux has a config value of 11. This mux is currently picking only between input tokens, so it should be <= 7?
• 2. 'doneXbar' has an empty list ("outSelect" : []). Why is that? Is this supposed to be a don't care?

[yaqiz01]

1. We have 16 tokenOuts in ctrlBox and there are 8 and 8 TokenDownLUTs and TokenOutLUTs. That's why there are 8 maps. The mux is the mux in first input of TokenDOwnLUTs. I forgot to update the name to syncTokenMux. In example pisa syncTokenMux is in parallel with tokenOutLUT entree. But we need 1 such mux per TokenOutLUT. That's why I put it inside map of tokenDownLUT.
2. Yeah that's don't care but was a bug not outputting list of "x"s.

---

1. change "mux" to "syncTokenMux". Let me know what format you are expecting here
2. change don't care to a list of "x"s.

---

We can keep tracking of my codegen bugs this way. I might not be able to get to future issues until after my midterm tonight. But will be available after 9pm.

[raghup17]

• Syntax

  for "top":

"top" : {
    "done" : "[0-9x]"                  # Input control signal corresponding to "design's done"
    //"argOutValid" : "[0-9x]"       # Input control signal corresponding to Pipe writing argOut
    "argOut" : "[0-9x]"               # Data bus corresponding to argOut
}

All signals are numbered by the switch numbers from left-to-right, bottom-row to top-row.

[raghup17]

• Syntax

  for "mu" (memory unit / memory controller):

"mu" : [
  { "isWr" : "[01]",  "scatterGather" : [01] },   # isWr: Is it configured for a write
  { "isWr" : "[01]",  "scatterGather" : [01] },   # scatterGather: Is it configured for a scatter-gather
  "x",      # If the MU is not used
  "x"   
]

'0' signifies off, '1' signifies on.
MUs are numbered from 0 to numMemoryUnits-1. Numbering is from bottom to top, left to right. Specifically, the MUs on the left are numbered 0..(numMemoryUnits/2)-1 (bottom to top), and the ones on the right are numbered (numMemoryUnits/2)..(numMemoryUnits-1) (bottom to top).

[raghup17]

• "doneXbar"

  code generation:

Number of outputs from this crossbar is equal to 2 * (numTokenOut - numTokenDownLUTs), per the diagram. In our current case, this would be 2 * (8 - 2) = 12 outputs. Looks like it is being generated as though it has 8 outputs, which happens to be numTokenOut.

[yaqiz01]

For "doneXbar" at the moment I'm generating 16 outputs. I thought we decided to double the control bandwidth so right now there are 16 outputs from and 16 inputs to ctrlBox in each C. There are 8 TokenOutLUTs and 8 TokenDownLUTs. So far I've seen 3 tokenDown from the same CU so 2 TokenDownLUT would not be enough.

[raghup17]

• Syntax for dataSwitch and controlSwitch:

"dataSwitch/controlSwitch": [
     { "outSelect" : [...] }, # Missing the curly braces
     { "outSelect" : [...]}
   ]

[raghup17]

• Crossbar configuration for incXbar:
  Number of elements in incXbar must be 2 * numUpDownCounter, or 16. Currently, only 8 values are being generated

[raghup17]

• Data and Control switch configuration
  In the ArgInOutDesign example, the first dataSwitch (0,0) has a '4' in one of its configs. The peripheral switches have only 4 inputs: 0 (W) , 1(N) , 2(E) , 3(S). 4 would be invalid.

[yaqiz01]

TokenOutXbar Order:
[0..3 (fifoNotFull)] ++ [4..11 (tokenDownLUT+pulse)] ++ [12-19 (tokenOutLUTs)] ++ [20-27 (enableLUT)]