FPGA, XN, Xscope and other stuff

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
Post Reply
avignani
Member
Posts: 8
Joined: Tue Oct 07, 2014 3:21 pm

FPGA, XN, Xscope and other stuff

Post by avignani »

Hello,

I made a custom board with an XS1-L8-64-TQ128 connected through link B with an Altera FPGA.
I ported the existing Verilog code, and it works fine.

Now for the XMOS-side problems:

1) How to specify in an XN file that a link is attached to something non-XMOS?
If the FPGA is defined as an XMOS node, then one has to provide code for it and integrate it in the JTAG chain, which is not the case.
Should I use a service? Or there's some routing trick like the one for Xscope?

2) On this board, link A is also brought externally. I connected it to an XTAG2 and Xscope works (should of..) with this link alone.
If I try to initialize link B directly (as in the FPGA example code) the processor hangs waiting for an ACK from the switch (maybe because Xscope disables writes to the switch registers?).
If I try instead to add link B to the XN file I get an error message XN11156 "a normal link node cannot contain a sod endpoint", that I interpret as "Xscope reserves the switch for itself and will not let you use other links".
What can I do?

3) In my case Xscope works only the first time after power-up. When I try to restart a terminated or interrupted program, it fails at 57% with "First stage multi-node boot failed" etc.

4) Warning - the link signals on the 20-pin connector in the XTAG-2 Hardware Manual v1.0 have been SWAPPED; they are instead correct in the schematics.
In detail:
pin 6 of the connector goes to pin 5 of the XTAG-2 processor (link A out1) which is X0D7 and not X0D4 as stated in the XTAG-2 manual
pin 10 of the connector goes to pin 7 of the XTAG-2 processor (link A out0) which is X0D6 and not X0D5
pin 14 of the connector goes to pin 10 of the XTAG-2 processor (link A in0) which is X0D5 and not X0D6
pin 18 of the connector goes to pin 11 of the XTAG-2 processor (link A in1) which is X0D4 and not X0D7
thus pins 6-10 are "Host to Target" and pins 14-18 "Target to Host"
Please correct the manual.

5) And as a bonus, I continue to receive the infamous warning about mode pins not set for JTAG boot. This makes no sense (otherwise how could you run a program from JTAG?)
In my current setup, TRST_N from JTAG is buffered by a 7409 and goes to the corresponding pin of the XS1 and to MODE2 and MODE3 pins; RST_N is ANDed with a power-on signal with a 7408. This should be straightforward, but I haven't been able to remove that warning no matter what I tried,so I came to believe that despite what the manual says the mode bits are sampled not at every reset but ONLY AT POWER-ON.
This fact seems to be confirmed by grounding TRST_N at power-on: as soon as I remove the short the processor starts from SPI but the mode bits stay forever low and the warning disappears.
Curiously, on the DSP4You AVB board I see no JTAG boot warnings; I saw that they put a couple of schottky diodes driving both RST_N and TRST_N from the power-good signal of the supply. But that board has a dual-core processor; maybe the warning only appears on single-core chips?
I tried to connect my power-on signal to TRST_N but the only effect was to put the XS1 in JTAG boot mode, so the mystery goes on...


Alberto


User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am
Contact:

Post by segher »

5)
The mode pins are sampled on every reset. "JTAG boot mode"
means the ROM boot code just halts. Starting a program via
JTAG works in that mode just as in any other mode; but the
good thing about JTAG boot mode is that all resources (ports,
timers, threads, etc.) will still be reset, so you have a pristine
(and known!) state to work from. Having random ports etc.
already enabled leads to very weird problems.

You didn't post schematics, but your symptoms sound like
either you forgot some pullups, and/or your 74xx does not
have enough drive.
richard
Respected Member
Posts: 318
Joined: Tue Dec 15, 2009 12:46 am

Post by richard »

avignani wrote: 1) How to specify in an XN file that a link is attached to something non-XMOS?
If the FPGA is defined as an XMOS node, then one has to provide code for it and integrate it in the JTAG chain, which is not the case.
Should I use a service? Or there's some routing trick like the one for Xscope?
You can define it as an device node (type="device:") in which case it doesn't need to be in the JTAG chain and you don't need to provide code for it. There's an example here:

https://github.com/rlsosborne/sw_servic ... /master.xn

In the startup code the tools will enable the link to this node, send a hello, wait to receive credit and then send another hello.
2) On this board, link A is also brought externally. I connected it to an XTAG2 and Xscope works (should of..) with this link alone.
If I try to initialize link B directly (as in the FPGA example code) the processor hangs waiting for an ACK from the switch (maybe because Xscope disables writes to the switch registers?).
If I try instead to add link B to the XN file I get an error message XN11156 "a normal link node cannot contain a sod endpoint", that I interpret as "Xscope reserves the switch for itself and will not let you use other links".
What can I do?
I'm not sure what FPGA example code you are referring to, would you be able to post a link to it?
avignani
Member
Posts: 8
Joined: Tue Oct 07, 2014 3:21 pm

Post by avignani »

segher:

I eventually found the source of my troubles: see
http://www.xcore.com/questions/2833/xs1 ... cu-problem

When designing my board I followed a FAULTY DATASHEET!! And I connected the PCU pins to ground.. of course it didn't work, the chip ignores the RST_N signal in these conditions.
And I cannot cleanly repair the board since the faulty connections are under the chip.. :-(((
avignani
Member
Posts: 8
Joined: Tue Oct 07, 2014 3:21 pm

Post by avignani »

richard:

following your suggestions I wrote an XN file which enables both links without errors and works (at least on Xscope, I will test the FPGA channel later but from the LEDs it seems OK).
By the way, the package I used is called "xlink_fpga", it's not on GitHub, and I don't have a link at hand; one has to look for it on Google.

segher:

with some microsurgery on the pins I removed the connections to ground and made the right ones, now all is working correctly.

Thank you both
Alberto
Post Reply