I connected two Startkits (SK1 and SK2) via 20cm ribbon cable using Link C Pins as labeled on the bottom of the boards:
SK1
SK2
1OU
1IN
0OU
0IN
0IN
0OU
1IN
1OU
I am running the code from AN01024, transmit code on one startkit, receive code on the other one. I also changed LINK_NUM to 0 since I didn't get any "got credit" message with LINK_NUM 3. I am sending characters but I am not receiving the correct data most of the time. Also the rate is way too low.
Any ideas on what I am doing wrong? I was really looking forward to using Xconnect.
Thanks for your help!
Edit: All 9 lights of the LED Matrix are switching on and off at a high frequency (looks like low brightness)
1) The signals are quite fast on this interface so if using with a direct cable - the cables must be kept short. Review the related docs on the interface for guidance.
2) Alternatively to use longer cables, you must insert lvds transceivers and that is what we did for a pending Startkit compatible sliceboard. Then you should be able to cascade as many kits as you wish. We used RJ45 connectors on our version with lvds transceivers. Have not yet assembled the boards.
I found this document, which states that a setup with a 15cm ribbon cable is working without errors. Maybe 15cm is the maximum possible length without LVDS and shielded cables.
That is the document I had in mind to reference :)
Hey - have a great idea - are you interested in beta testing our LVDS board we designed last year ? It will be our next lifetime before we get the 'free time' to do the same with our current schedule. Let us know and we can dig around on the last status of these PCBs. Fairly sure we have the bare PCBs in house and also some required ganged RJ45 connectors. The premise is to use off the shelf CAT5 / CAT6 cable to interconnect between StartKits. The slice board we designed features the referenced LVDS transceivers. Where are you located ? In North America or Europe or ??
With just StartKits and nothing else, you may not get very good results past about 6cm, unless you slow the link down a great deal; that was my experience anyway. With decent buffers, and termination resistors, you may get to 15cm or more even at relatively high rates.
In our production application we keep things to about 80MBPS (divider 5 IIRC) for safety. Our cable lengths are mostly quite short -- 3-4cm. We do have a longer cable though it is running "native" Xlink and not a dynamic version as described in that app note.
data wrote:With just StartKits and nothing else, you may not get very good results past about 6cm, unless you slow the link down a great deal; that was my experience anyway. With decent buffers, and termination resistors, you may get to 15cm or more even at relatively high rates.
In our production application we keep things to about 80MBPS (divider 5 IIRC) for safety. Our cable lengths are mostly quite short -- 3-4cm. We do have a longer cable though it is running "native" Xlink and not a dynamic version as described in that app note.
Thanks for your help.
How can I slow down the link? I found this document about the link architecture, it tells me to look in the data sheet of the chip for the link-register map. Which data sheet do I need for startkit? Is there any other documentation I need to program the link appropriately?
Is there an application note for the native Xlink? Or can you give me a minimalistic example?
If you are using a "normal" link, you can set the link speed by editing the XN file. The <Link> node has an attribute called Delays, which is two numbers separated by a comma, for example 4,4. The first number is the inter-token delay, which sets the delay between tokens. The second is the intra-token delay, which sets the delay between bits (symbols) within tokens. The delay time is (AFAIK) the number of system clock cycles, so if you have a 400MHz system, a delay of 4 will get you 400MHz / 4 = 100MHz.
With the dynamic link, you set this up yourself, by hand. In AN01024 you will find the intra-token and inter-token delays configured in link.xc, using the defines INTER_DELAY and INTRA_DELAY. In my copy these are set to 1 which may result in something like 400MHz clocks -- you would almost certainly want to set these to something a bit more reasonable, like 4 or 5 (we usually use 5). At my company we have written a library which deals with this a bit more elegantly, but AN01024 does demonstrate the basic elements.
in the dynamic xlink demo, I get a resource exception (ET_ILLEGAL_RESOURCE). Seems like I only can receive bytes one by one. I found the following table in the xCONNECT Architecture pdf:
Name
Value
Description
READN
0x80
Read data
READ1
0x81
Read one byte
READ2
0x82
Read two bytes
READ4
0x83
Read four bytes
READ8
0x84
Read eight bytes
WRITEN
0x85
Write data
WRITE1
0x86
Write one byte
WRITE2
0x87
Write two bytes
WRITE4
0x88
Write four bytes
WRITE8
0x89
Write eight bytes
CALL
0x8a
Call code at the specified address
If I understand correctly, there is a way to write and read integers by sending 0x83 and 0x88 as control tokens to the switch. I used outct to do this, but then I get an ET_LINK_ERROR. Am I doing this completely wrong? I don't want to send my data cut into bytes and put them back together on the receiving end. Would be very nice, if someone had an elegant solution.
The ET_ILLEGAL_RESOURCE exception in this case may indicate that there is something wrong with the chanend variable. Make sure that it is properly initialised.
Also, when using statically-routed chanends as is done in the demo, you will usually not have much luck with the input and output operators, because those expand to extra instructions which are designed to work as part of a synchronisation protocol.
Instead, you should use the outuint / outuchar / inuint / inuchar functions defined in xs1.h. These expand to IN and OUT instructions and do not attempt any extra synchronisation with the other end. outuint is probably what you are looking for in this case; it will transmit 32 bits at once.
data wrote:The ET_ILLEGAL_RESOURCE exception in this case may indicate that there is something wrong with the chanend variable. Make sure that it is properly initialised.
Also, when using statically-routed chanends as is done in the demo, you will usually not have much luck with the input and output operators, because those expand to extra instructions which are designed to work as part of a synchronisation protocol.
Instead, you should use the outuint / outuchar / inuint / inuchar functions defined in xs1.h. These expand to IN and OUT instructions and do not attempt any extra synchronisation with the other end. outuint is probably what you are looking for in this case; it will transmit 32 bits at once.
The chanend variable works with char data; c:> data; . How can I initialize c to work with int?
Thank you for the inuint/outuint suggestion! But I believe I need to initialize the chanend accordingly to work with integers. Is there a manual on how to do this for different cases?