NHML AER address specification (PIN layout)

[federicohyo]

I am trying to figure out how to have the following address specification in the NHML file. The problem is that PIN layout is different for different address ranges as in the attached image.

The address specification in pyNCS has the same pin layout for all the addresses while in my case the same pin layout might have different functions.

can I specify a new address specification? and then, how can I tell the constructor which address specification to use?

[federicohyo]

for a pinlayout described in this way:

Z9 Z8 Z7 Z6 Z5 Z4 Z3 Z2 Z1 Z0 X7 X6 X5 X4 X3 X2 X1 X0

where X is neu and Z is syntype
It is possible to define fake broadcast synapses, for every neuron, like this:

<synapse type="BROADCAST SYNAPSES" id="broadcast">
    <dim id="syntype" range="range(520,776)"/>
</synapse>

the real broadcast address range would then be available in this form:

pop_broadcast = pyNCS pop of neurons ids -> np.linspace(0,255,256)

a = range(256)
pop_broadcast[a].synapses['broadcast'][0::256].paddr -> will return [133120,133120+256](all learning syn broadcast columns)
pop_broadcast[a].synapses['broadcast'][1::256].paddr -> will return [133376,133631+256](all programmable syn broadcast columns)

but this is, of course, only a hack. I guess one should rewrite the STas.py file in pyNCS and make it capable of handling different pinlayouts for the same chip.

[fabioedoardoluigialberto]

I'm not sure I understand your solution but yeah, as long as it works :)

I think the ideal solution would be to be able to define as many address specifications as one needs for every address range (two in your case, but I know that your chip has an even more sophisticated address specification definition table).

Let me try here with some NHML:

<chip chipclass="MYCHIPCLASS">
  <addressSpecification type="aerIn">
    <dim id="x" type="soma">
      <range>range(128)</range>
      <description/>
      <decoder>X</decoder>
    </dim>
    <dim id="s" type="synapse">
      <range>range(32)</range>
      <description/>
      <decoder>Y</decoder>
    </dim>
    <pin id="X">
      <decoder>x</decoder>
    </pin>
    <pin id="Y">
      <decoder>s</decoder>
    </pin>
    <pinlayout>X0 X1 X2 X3 X4 X5 X6 Y4 Y3 Y2 Y1 Y0</pinlayout>
  </addressSpecification>

  <addressSpecification type="aerInBroadcast">
    <dim id="c" type="synapse">
      <range>range(256)</range>
      <description/>
      <decoder>X</decoder>
    </dim>
    <pin id="X">
      <decoder>c</decoder>
    </pin>
    <pinlayout>X8 X7 X6 X5 X4 X3 X2 X1 X0</pinlayout>
  </addressSpecification>

  [... ]

and then STas should be able to parse this and compile it properly to dynamically allocate an "fc" and "fe" (constructor and extractor functions) for each addr spec. I have the feeling it will work straight away in fact. However, it is still not clear to me how the different addrSpec will be used for the different address ranges. In other words, they are there but how does PyNCS know how to use them?

We have to try this since it's opening a whole new range of capabilities for PyNCS.

Thanks for posting.

[fabioedoardoluigialberto]

I will (try to) summarize a recent discussion happened between amw, sheiksadique and myself on this issue. I will first formalize the problem.

The 2^N possible addresses are grouped into separate chunks. Each chunk requires a separate en/decoding scheme, i.e., address specification (AS). The ranges can have different sizes. It is clear that the AS cannot be simplified into bit fields, i.e., there exist in general no single bit that uniquely identifies one of the chunks. (If that was the case, then it would be enough to assign identifiers to these bits and the chunks would all have the same sizes. For example, 2 chunks of 256 addressess can be distinguished by looking at the 9th bit).
The problem is: how to write the address specification? Does pyNCS support such strategy via the NHML?

Provided that any address specification encoding and decoding can be expressed as single boolean instructions (i.e., a combination of mask, shift and so on), we concluded the following:

• there seem to exist two possible solutions, one (a) requiring to express the sophisticated address specification encoding into the single instruction in the appropriate NHML field, the other one (b) splitting the different address specification strategies into separate NHML fields
• regarding solution (a), it is unclear how the AS functions for encoding and decoding would treat their arguments (e.g., should we pass all of them and assign None to the unused ones? Example: addressSpec.PhysicalConstruct([9, 0, None, None, 10])?)
• solution (a) must be not more then a mere translation of the digital circuits implementing the AER en/decoding physically
• regarding solution (b) it is unclear how pyNCS or the front-end would be able to select the desired AS
• last point: it seems to be clear that at some point up in the application process the chunk must be explicitly selected

So? What do we do? :)

Hope I haven't missed anything.

[amwhatley]

Seems more or less fair, as far as you go. I'd just clarify that when you write single boolean instructions you're really referring to a single boolean expression, but even that is actually more restrictive than it need be, because you can actually have any anonymous function there.

My suggestion was that each range be assigned a label, and that label corresponds to one of the ids in the NHML (<dim id="label" ...) from which the offset can be known and hence the physical address can be calculated.

If I understood your (a) and (b) correctly, I don't see them as mutually exclusive. Because of your 'last point', it's clear that at some level we need a type (b) solution, but this can map to a type (a) solution at a lower level.

[sheiksadique]

Some of these issues with address specification are too complex to tackle with the current address specification modules.

The current address specification scheme is limited to the kinds of multi chip setups we have been using. TO elaborate we use a different specification scheme for addressing different chips aka channels and a separate one for internal chip addressing. This to some extent forces us to stick to the channel specifications which as we know take up a lot of address space. (Despite a chip for instance only requires 32 addresses for its 32 neurons, we assign a full 20/16 bit address space to the corresponding two input/output channels)

So in some sense the two issues of channel addressing and offset usage for addressing within the chip are interconnected. So we hope to have a more generic software addressing framework that can address both these issues.

A new branch addrspecv2 has been initialized to address this.
Work flow will be as follows:

• Addresses will be divided into blocks bounded by min-max (or offset perhaps).
  • Each address block will be defined as was always done before.
• These blocks will be arranged/sorted internally in pyNCS using a tree structure.
• This tree structure could formulate the address specification of a single chip or a complete setup, where one of the branches/sub-tree corresponds to single chip's address specification.

This kind of accommodates @fabioedoardoluigialberto suggestion of having multiple address specifications within a chip and makes it easier to describe the chip specifications.

Further comments will be added as to how this translates to actual implementation. Any suggestions are welcome. Please do share any technical issues I might have overlooked.

[fabioedoardoluigialberto]

I think the issue there was to figure out 'who' tells PyNCS which addressing scheme to use. As far as I can tell now it would be a two - steps process: get binary -> get int -> retrieve corresponding addrSpec.
Regarding the encoding, I guess the user should always be aware of the type of addrSpec PyNCS is going to use, to some extent. For example, some addrSpec may require (neuron,synapse) fields while some others (x,y,type,weight,delay).

Am I getting it right?