Modify AN01024

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
fabian
Member++
Posts: 23
Joined: Wed Apr 12, 2017 9:13 pm

Re: Modify AN01024

Postby fabian » Thu Aug 23, 2018 8:28 am

Hi, all.
Hi, mon2.

Regarding plink status register and channel ends:

AN01024 is implemented and tested on two L16 sliceKIT core boards. Each core board uses a XS1-L16-128-QF124 device. If you take a look into the XS1-L16A-128-QF124 datasheet you will find a chapter "C Tile Configuration" which introduces the register 0x10 .. 0x13 "PLink status" and 0x80 .. 0x9F "Chanend status". Be aware of: they are related to the tile configuration and not to the node configuration. These registers cannot be found in the XEF232-1024-FB374-Datasheet.

But in the application software of AN01024 you will find some print-Functions in link.xc, which read the contents of these register. It is not possible to compile the application software when adapting it to custom boards which use devices like XEF232-1024-FB374. The print-Functions are only implemented but not used in the application, though. Ok, it is not a big deal, since the print-Functions aren't used anyway, you just uncomment these code-parts.

But what are the registers good for and why are they not needed anymore in XEF232 ?
Is it needed to understand that to get the application software running on my custom boards?
I do not know.

If you take a look into the registers you will notice, that these are about processor links, ChannelEnds, network identifier switches etc .... My topic is about all of this, so I believe it might matter to know about all this stuff.

And mon2, I'm aware of Section D.16 and D.18 of the XEF232 Datasheet which you mentioned in one of your posts in this thread. The registers described there are related to the node configuration not to the tile configuration. Though, these registers
touches communication by xlinks, definitly.

Again, a lot of text. But still the questions:
What is going on with xlinks?
How to adapt the application note to get used by XEF232?
And many more ....

Best regards.
fabian
Member++
Posts: 23
Joined: Wed Apr 12, 2017 9:13 pm

Postby fabian » Fri Aug 24, 2018 8:55 pm

Hello, all.
Hello, mon2.

1) Noted above in your post that you are using LVDS transceivers. Can you post the relevant schematic or wiring details? Are these correct and in the proper direction between XMOS CPU # 1 to the remote PCB with XMOS CPU # 2?


The connection between the two XMOS CPUs is correct. There are a lot of testpoints on every board and test-signals are measured by oscilloscope. Hardware is ok.

2) Do not believe the project has any dependency to the XN file for your interconnect. Instead, you will be assigning the static links (ie. non routed) as per AN01024 for the reasons raised in section 2.2 of the same document. You will manually select the point to point communication parameters, just like this application note.


I'm still not sure about the link configuration. I'm using xlink1 so registers 0x21, 0x81 and 0xA1 of the node configuration are applied.

In Register 0x21 the direction needs to be set in bits 11:8. The software in the application node sets this to 0x1 for app_links_b1 and to 0x0 for app_links_b2. I have no idea what "direction" means in this context and which values are valid.

In Register 0xA1 Bit 8 needs to be set to 1 because tile 1 is used on every board.
Bits [4:0] are set to 0x0 because channel 0 is in use.
And of course Bit 31 is set to 1 to enable static forwarding.

3) Suggesting to start with the same example code from this appnote. On the node id,


I use two terminals. One for board 1 which runs app_links_b1 and the other for board 2 which runs app_links_b2. After downloading the two software on the corresponding boards, both terminals show "Got credit". So I believe the link setup is correct and communication is working on that level.
This can also be measured at the testpoints: during that state there are reasonable signals on the wires.

But the channel setup seems not to be correct. The report shows "Communication rate: 0 bytes per sec ..." and there is also no traffic on the wires measured by the oscilloscope anymore.

What I'm wondering is, that app_links_b1 and app_links_b2 are both allocating chanend 0x80110002. Well I'm not wondering about the id, that seems totally correct to me. In the XN-File the RoutingId of node 0 is set to 0x8010 and the processor in use is tile 1 of that node. So 0x8011 is ok. Channel 0 is used and the resourceId is 0x2. So the id 0x80110002 is correct.
But in app_links_b1 this id is also used as the destination id of the chanend itself. That means to me that on app_links_b1 the allocated channel is sending data to itself.
Am I wrong? Can anyone explain this to me?

Best regards.
fabian
Member++
Posts: 23
Joined: Wed Apr 12, 2017 9:13 pm

Postby fabian » Sun Aug 26, 2018 11:38 am

Hello, all.

What is that "RoutingTable" all about?

In "Manually-specify-xCONNECT-link-network-routing_A.pdf" you can read about "routing Id" and "routing table" which must be configured for each node on the network. It's telling about "Bit numbers" and "directions". But no word about what that all means and what values are available.

There is a thread
viewtopic.php?f=26&t=1891&hilit=DrNo
in which the member "segher" is writing
There are two things you need to set up for the links: the routing, and the links
themselves.
And he is showing a little example, but no chance to see where all the values are coming from?

Is there anyone out there who is capable of that topic and willing to explain it to me?

Thanks and best regards.
User avatar
mon2
XCore Legend
Posts: 1282
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Mon Aug 27, 2018 2:44 am

fabian
Member++
Posts: 23
Joined: Wed Apr 12, 2017 9:13 pm

Postby fabian » Mon Aug 27, 2018 11:13 pm

Hello, all.
Hello, mon2.

Thank you for the links to the documentation. Though, I already know that documentation and believe it or not: the content of the document is something like a checklist but no explanation to what I want to know. For example look to
"XN Bit element": it has an attribute "direction" and the description is "The direction to route message" ?? So what is a direction? Is it "in" or "out", "left" or "right", "up" or "down" etc. ? What is the explanation of the attribute "direction"? What does it mean? Which values does it take? Why is it needed?

After all the posts in this topic, I still have no answers to my questions. I'm wondering if anyone in the forum is capable to answer my questions. If so, and I really believe in that there must be someone, why is no one answering my questions in a manner which is straight forward.

I actually want to know what to do to hot plug two XEF232. AN01024 does not work. And I can't find any solution. So I ended up in asking question like: "What does direction mean?" And all the other questions in the posts before.
There are other threads like
viewtopic.php?f=44&t=5893
which are dealing the same problem and in which the users are running into the same problems, without any solution described here in the forum.

Is there any kind of information barrier in this topic?

Best regards.
fabian
Member++
Posts: 23
Joined: Wed Apr 12, 2017 9:13 pm

Postby fabian » Sun Sep 09, 2018 8:41 pm

Hello all.
At least I got it to work. It was all about understanding the meaning of "direction", how to set up individual routingIds and how to get the direction out of a nodeId/routingId.

But for me a "direction" is more like a routing id, because in the end "direction" names or identifies a certain connection or way or routing between two nodes. This was quite confusing and put me in the wrong track for a while.

After understanding that it actually was quite easy to find a solution. It was just about finding the right direction (id).

Regards.

Who is online

Users browsing this forum: No registered users and 27 guests