Hi Everyone!
I've got an issue with my new board, that is based on the Evaluation board XP-SKC-L2(with some modifications). The Evaluation boards work fine for my application, but now I got a prototype consisting in two XS1-L16A-128-QF124. They are chained for my application(cores 0-3). Unfortunately the JTAG is not recognising the board.
The only issue that I found on the new board is related to the XMOS Link. On the XP-SKC-L2 the Tile 1 is connected to the Tile 2, but on my prototype it is connecting the Tile0 to the Tile 3. Would be a design issue? Please see the files attached with the Link and the Connection of the Cores.
Could you verify if my .xn file is OK? Please see file attached.
I've checked the startup sequencing of the power supplies and it seems to be OK.The 25MHz for the Cores looks fine .
For the xSYS Interface I'm using just the following buffered signals: M_SEL, DEBUG_N, TRST, TMS, TCK. The signals TDI and TDO are not buffered, but they are connected directly to the XMOS Core.
Thanks for your help on this!
Chained Slicekits are not being recognized
-
NicXmos
- Junior Member
- Posts: 5
- Joined: Wed Sep 30, 2015 8:42 am
Chained Slicekits are not being recognized
You do not have the required permissions to view the files attached to this post.
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Hi. From a quick 2 second review, R221 (10k) should be a PULL-UP (not pull-down as shown in the schematic). The reason being that the driving buffer is open drain (U212) so the buffer can provide for a low already but will tri-state (HI-Z) when input is high. Respectively, an external pull-up resistor is required to pull the output to a logic high.
As shown now, the output will never see this logic high level. Check the datasheet for the open drain buffer (U212) for more details.
As shown now, the output will never see this logic high level. Check the datasheet for the open drain buffer (U212) for more details.
-
NicXmos
- Junior Member
- Posts: 5
- Joined: Wed Sep 30, 2015 8:42 am
Hi. Thanks for your quick Response! I fix this hw issue with a 10K Pull-Up. The Pull-Down was removed. Unfortunately it is still not working. The RST_N Signal seems to be OK now.
Do you know if the XMOS link that I have on my board would work? I am still thinking about the Tile 0 and 3.
Thanks!
Do you know if the XMOS link that I have on my board would work? I am still thinking about the Tile 0 and 3.
Thanks!
-
NicXmos
- Junior Member
- Posts: 5
- Joined: Wed Sep 30, 2015 8:42 am
Hi. Another Information that could help: The TDO Output from the XMOS L1(the last on the chain) is always grounded. Please see picture attached.
You do not have the required permissions to view the files attached to this post.
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
I would focus on attempting to get JTAG to detect the first physical XMOS device correctly before moving to link the 2 devices together.
Try the following ideas:
a) cut the reset trace to XMOS device L1 (2nd device in your circuit) in your schematic.
b) after this cut, hard strap the reset trace on L1 (only) to ground. The purpose is to force this L1 device into reset mode which will tri-state the component and effectively remove from circuit.
Then monitor the activity on TDO of L0 while connected to your XTAG tool. Do you see activity on this pin ? Assuming you do, connect the TDO trace to TDO of your XTAG connection. This wiring should allow you to bypass the L1 device from the circuit.
Now, XTAG should be able to ping the L0 component properly and if you have a local SPI flash, you could apply some simple blink LED or similar code for testing. Confirm that L0 is working correctly and is able to power up without XTAG connected using the local SPI flash.
Once this is confirmed, then move on to pair the XMOS devices together.
Some concerns are that of your reported link wiring but have not had time to review. The first device is required to boot from local SPI flash and the L1 device is required to boot through Link B pins so the mode pins must be reviewed for each device. Start with the L0 validation before moving to this configuration.
Another concern is that your reset line is being driven by TRST which is not correct. Rather, the TRST is supplied from the XTAG tool and RESET_N was to be generated by local hardware after the power supplies are confirmed to be stable. You do not show that part of the circuit so best for you to review. From the posted circuit, it would appear that if XTAG is removed, your circuit has no method to reset the XMOS CPU ? This must also be reviewed.
Do your power supply rails power up correctly ? Do you monitor for their voltage threshold and properly sequence the rails ? After confirmed to be stable, the reset signal must be pulsed.
Try the following ideas:
a) cut the reset trace to XMOS device L1 (2nd device in your circuit) in your schematic.
b) after this cut, hard strap the reset trace on L1 (only) to ground. The purpose is to force this L1 device into reset mode which will tri-state the component and effectively remove from circuit.
Then monitor the activity on TDO of L0 while connected to your XTAG tool. Do you see activity on this pin ? Assuming you do, connect the TDO trace to TDO of your XTAG connection. This wiring should allow you to bypass the L1 device from the circuit.
Now, XTAG should be able to ping the L0 component properly and if you have a local SPI flash, you could apply some simple blink LED or similar code for testing. Confirm that L0 is working correctly and is able to power up without XTAG connected using the local SPI flash.
Once this is confirmed, then move on to pair the XMOS devices together.
Some concerns are that of your reported link wiring but have not had time to review. The first device is required to boot from local SPI flash and the L1 device is required to boot through Link B pins so the mode pins must be reviewed for each device. Start with the L0 validation before moving to this configuration.
Another concern is that your reset line is being driven by TRST which is not correct. Rather, the TRST is supplied from the XTAG tool and RESET_N was to be generated by local hardware after the power supplies are confirmed to be stable. You do not show that part of the circuit so best for you to review. From the posted circuit, it would appear that if XTAG is removed, your circuit has no method to reset the XMOS CPU ? This must also be reviewed.
Do your power supply rails power up correctly ? Do you monitor for their voltage threshold and properly sequence the rails ? After confirmed to be stable, the reset signal must be pulsed.
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
More comments...
a) most definitely work on confirming the L0 device is able to communicate with the XTAG tool before moving to use L0 & L1 with XTAG.
b) the links should not (in theory) have any issues at this stage of testing with XTAG since XTAG is using only the JTAG (XSYS) connections. Respectively, it should be very possible to confirm L0 (first) and then L0 & L1 using XTAG connections only.
c) the role of the links will be raised after your remove the XTAG tool and are in boot from SPI (L0 CPU) and then force L1 to boot through links.
For now, focus again on the L0 validation using XTAG / XSYS connections only. Suspecting your reset has some role in this case as well.
a) most definitely work on confirming the L0 device is able to communicate with the XTAG tool before moving to use L0 & L1 with XTAG.
b) the links should not (in theory) have any issues at this stage of testing with XTAG since XTAG is using only the JTAG (XSYS) connections. Respectively, it should be very possible to confirm L0 (first) and then L0 & L1 using XTAG connections only.
c) the role of the links will be raised after your remove the XTAG tool and are in boot from SPI (L0 CPU) and then force L1 to boot through links.
For now, focus again on the L0 validation using XTAG / XSYS connections only. Suspecting your reset has some role in this case as well.
-
mon2
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Ok, more comments :)
a) the links are not wired correctly to allow for L1 to boot through links from the L0 device. This is because L1 is using the X1 core and should be X0 core pins.
b) however, XTAG should properly be able to communicate with L0 device (as per earlier posts) and certainly L0 & L1 together once the XTAG chain is confirmed to be operational. The XTAG use is not impacted by the link wiring. Be sure to confirm this interface.
c) the design is using 5w interface so suspecting you want high speed communication between devices ? The recommended correction is to properly wire up the links as noted by XMOS notes (using X0 core on L1 device) - also be sure to review the power supply sequencing + the need for the independent reset_n support. The 2nd free open drain buffer was to be used for this task - pin 3 = power supply initiated reset_n.
For the reasons noted above, a revised PCB is your best option. If you have long traces between the devices, be sure to review the notes on series termination resistors on the XMOS devices. Or if necessary, introduce LVDS transceivers if the trace lengths are very long (doubt you need this but please confirm).
Other options are, still validate XTAG is working and you could customize the boot rom to boot from the links you have actually wired up. However, this topic is not in our comfort zone so left as a reader exercise :) The XMOS supplied boot rom is requiring you to use the links they have noted in the datasheets.
Another option is to, still validate XTAG is working and apply a local SPI flash on L1. Not sure if you have bonded out the pins for the SPI interface for L1 but if you have then you could write independent code for L0 and again for L1 devices - each device will host a local SPI flash. Then you are free to communicate between devices with the links you have in place now. There is an article on this topic posted by srnie and worth a read:
http://www.xmos.com/de/support/appnotes/AN01024
Summary of this article is that any XLINK can chat with another XLINK of another device but you must first have coded for this support which means you must have local SPI flash hosting this code. You cannot do this unless your XTAG is working and you must wire up local SPI flash devices for each mated physical XMOS CPU.
Believe that the cleanest solution is to confirm XTAG & reset concerns for both devices and then revise the PCB layout to match the XMOS boot rom code.
My usual disclaimer - the posted details are from massive readings so please do confirm the details on your own but are believed to be correct but use at your own risk.
a) the links are not wired correctly to allow for L1 to boot through links from the L0 device. This is because L1 is using the X1 core and should be X0 core pins.
b) however, XTAG should properly be able to communicate with L0 device (as per earlier posts) and certainly L0 & L1 together once the XTAG chain is confirmed to be operational. The XTAG use is not impacted by the link wiring. Be sure to confirm this interface.
c) the design is using 5w interface so suspecting you want high speed communication between devices ? The recommended correction is to properly wire up the links as noted by XMOS notes (using X0 core on L1 device) - also be sure to review the power supply sequencing + the need for the independent reset_n support. The 2nd free open drain buffer was to be used for this task - pin 3 = power supply initiated reset_n.
For the reasons noted above, a revised PCB is your best option. If you have long traces between the devices, be sure to review the notes on series termination resistors on the XMOS devices. Or if necessary, introduce LVDS transceivers if the trace lengths are very long (doubt you need this but please confirm).
Other options are, still validate XTAG is working and you could customize the boot rom to boot from the links you have actually wired up. However, this topic is not in our comfort zone so left as a reader exercise :) The XMOS supplied boot rom is requiring you to use the links they have noted in the datasheets.
Another option is to, still validate XTAG is working and apply a local SPI flash on L1. Not sure if you have bonded out the pins for the SPI interface for L1 but if you have then you could write independent code for L0 and again for L1 devices - each device will host a local SPI flash. Then you are free to communicate between devices with the links you have in place now. There is an article on this topic posted by srnie and worth a read:
http://www.xmos.com/de/support/appnotes/AN01024
Summary of this article is that any XLINK can chat with another XLINK of another device but you must first have coded for this support which means you must have local SPI flash hosting this code. You cannot do this unless your XTAG is working and you must wire up local SPI flash devices for each mated physical XMOS CPU.
Believe that the cleanest solution is to confirm XTAG & reset concerns for both devices and then revise the PCB layout to match the XMOS boot rom code.
My usual disclaimer - the posted details are from massive readings so please do confirm the details on your own but are believed to be correct but use at your own risk.
-
NicXmos
- Junior Member
- Posts: 5
- Joined: Wed Sep 30, 2015 8:42 am
Hi! Thanks for the clue. I will Focus to get JTAG running with L0 only. Unfortunately the TDO Signal from L0 is not accessible, because is on the middle layer of the board ... ;=(
I have to try another approach ... maybe removing L1(unsoldering).
Concerning the reset, it is supplied by local Hardware after the power supplies are stable. It is connected to the X_RST_N Signal.
I have to try another approach ... maybe removing L1(unsoldering).
Concerning the reset, it is supplied by local Hardware after the power supplies are stable. It is connected to the X_RST_N Signal.
-
jerryXCORE
- Experienced Member
- Posts: 65
- Joined: Tue Apr 30, 2013 10:41 pm
I was thinking to design a board with two XS1-L16A-128-QF124, and "core[0]-core[1]---core[3]-core[2]",
But I am afraid that it may not work,
So eventually I stick to original design "core[0]-core[1]---core[2]-core[3]".
But I am afraid that it may not work,
So eventually I stick to original design "core[0]-core[1]---core[2]-core[3]".
-
NicXmos
- Junior Member
- Posts: 5
- Joined: Wed Sep 30, 2015 8:42 am
Hi mon2,
The JTAG with L0 is working now. The reason for that was the crossed lines between TCK and TMS on the layout. Thanks for your help on this.
Next step is to bring L0 and L1 together via JTAG. I have 2 SPI Flash on board, but both are connected to L0. I will try to wire it up and connect to L1.
Thanks! ;=)
The JTAG with L0 is working now. The reason for that was the crossed lines between TCK and TMS on the layout. Thanks for your help on this.
Next step is to bring L0 and L1 together via JTAG. I have 2 SPI Flash on board, but both are connected to L0. I will try to wire it up and connect to L1.
Thanks! ;=)