Retrofitting Additional Processors

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
User avatar
aneves
Experienced Member
Posts: 91
Joined: Wed Sep 16, 2015 2:38 pm

Retrofitting Additional Processors

Postby aneves » Thu Nov 30, 2017 6:39 pm

Hello,

We have an existing prototype based on the XU216-512-TQ128. We wish to retrofit additional XMOS processors onto this prototype and connect each processor together via xConnect links. The existing XU216 would be the master and the additional processor we are connecting would be the slaves. The idea is that we could create a small board with our additional XMOS slaves where each slave is connected to each other via xConnect in a single pipeline.

This is where things get fuzzy for me. We would like to be able to connect the first slave's xConnect link, which is the link that would get connected to the master processor, to a female header that is identical to what the XTAG uses. This way, we can just plug in our add-on board onto the existing prototype in place of the XTAG. This would let us use XL0 on the master processor to connect to the first slave on the add-on board.

With me so far? Good.

Now we'd like to be able to connect a female header to an xConnect link on the last slave processor on the add-on board so that we can connect the XTAG to our system. So what where doing is reusing the existing XTAG header to let us establish an xConnect link to an add-on board and then move the XTAG down to the end of the pipeline. This means that instead of the XTAG being connected directly to the master, it is now connected to the last slave processor in the pipeline.

Here are my questions.
Is this feasible? Does the XTAG need to be connected directly to the master processor? Would we be able to load firmware via XTAG and debug as usual in this configuration?

Some side quesitons.
Is the xConnect Architecture document and XS1 Link Performance and Design Guidelines (located here https://www.xmos.com/download/private/x ... 1.0%29.pdf and here https://www.xmos.com/download/private/X ... 2.0%29.pdf respectively) still accurate for the xCore 200 processors?

I remember reading somewhere that with the xCore 200 processors you didn't need to use specific xConnect links for your outward master and maybe even for the slaves. If someone could confirm that or point me in the right direction to figure that out that would be great!

Thanks!!!
User avatar
aneves
Experienced Member
Posts: 91
Joined: Wed Sep 16, 2015 2:38 pm

Postby aneves » Mon Dec 04, 2017 3:37 pm

Could anybody give me some insight on this?
User avatar
aneves
Experienced Member
Posts: 91
Joined: Wed Sep 16, 2015 2:38 pm

Postby aneves » Thu Dec 21, 2017 7:58 pm

Anyone?
User avatar
mon2
XCore Legend
Posts: 1067
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Thu Dec 21, 2017 9:45 pm

Hi. I think the summary is that you wish to allow for the XTAG tool to be mated with individual XMOS processor in your chained design for debugging? Personally would do the same thing. Pretty sure the XTAG3 jig is based on unidirectional lines so it should be straight forward to insert muxes so that you can either cascade the XMOS processor (master-slave links) between each other OR use the mux to steer to a local XTAG3 mating header. As long as your traces are not wild and long, you should be able to do this without the use of LVDS transceivers. For the muxes you can use the FET based bidirectional devices which will allow for not caring for direction flow. For a sanity check, highly recommend this idea till you know for sure on how your design will work. Consider to post the schematic for a review when ready.
User avatar
aneves
Experienced Member
Posts: 91
Joined: Wed Sep 16, 2015 2:38 pm

Postby aneves » Fri Dec 29, 2017 9:53 pm

Hi mon2,

Thanks for your reply. I'm not quite sure I understand your approach. I've diagrammed what our approach would look to hopefully remove and ambiguities.
Image

What this diagram shows is that we are reusing the xSYS header on the original board. Currently, this header is used for the xTAG for debugging, loading firmware, flashing firmware, etc. Our proposal is to mate this header with a header on a daughter board which connect xConnect XL0 on the master to xConnect XL0 on the first slave. The last slave processor in the pipeline exposes xConnect XL7 to a new xSYS header that the xTAG would now mate to. The slave processors on the daughter board are connected to each other via the labeled xConnect links.

My questions are:
  • With these connections implemented as diagrammed, will we be able to debug, flash firmware, load firmware via xTime Composer and the command line tools like we had been doing with the single processor configuration?
  • If the above is true, will we be able to view all of the tiles and their stacks from all processors in the debugging view of the IDE and command line tools as if it were a single processor?
  • Would the processor on the original board be designated as the master even though the xTAG would be connected to the last slave on the daughter board?
  • The diagram only illustrates how the xConnect links are connected. What would we do with the other JTAG connections coming from the header on the original board? Would we have to bring them across from one end of the daughter board to the other so that the xTag can connect to them?

I feel like there is a fundamental piece of knowledge I'm missing that would bring this all home.

Again, any insight is greatly appreciated. I'd rather not spin daughter boards that would never work.

Thanks!!

Who is online

Users browsing this forum: No registered users and 5 guests