COMMA_ALIGN_MSB being ignored?

Hi there,

We have a design that uses 3 MGTs, which we use 16 bits wide. To ensure we have byte alignment properly, we set the ALIGN_COMMA_MSB to true on the GT_CUSTOM instances. When not sending any data, we simply send comma signals over the line.

However, it would appear that something is wrong. When we start the system, the MGTs seem to be aligned only to 8 bits, so 50% of the time the data is a byte out of phase. I can see this by dumping the output of the MGT over the serial line (as past as it copes) - for each MGT it's either consistantly the comma value or consistantly the comma value rotated 8 bits.

To make things more confusing, when we send packets (as delimited by a start and end packet symbol) on the MGTs that aren't aligned will ignore/lose/drop the first packet, and then subsequently by correctly byte aligned, and all subsequent packets get through perfectly.

Does anyone have any suggestions to what might be causing this? Losing the first packet really isn't tollerable, as in our system the lines will run through a switch which will mean that the MGTs will have to clock synchronise/detect alignment on a very regular basis, and losing the first packet will cause problems.

In case it's of relevance, the component decleration of the GT_CUSTOM part species the generic parameter ALIGN_COMMA_MSB as boolean, defaulting to true, and in the instantiation this is overridden with the value true as well.

Cheers,

--
Michael Dales
University of Cambridge Computer Laboratory
http://www.cl.cam.ac.uk/~mwd24/
Reply to
Michael Dales
Loading thread data ...

After posting this it occurred to me that this isn't comp.arch.xilinx, and I should point out we're usign a Virtex-II Pro (xc2vp20), on an AFX FF1152 board. We don't see this problem under simulation.

--
Michael Dales
University of Cambridge Computer Laboratory
http://www.cl.cam.ac.uk/~mwd24/
Reply to
Michael Dales

I assume you're asking if we give it long enough to lock, and I think the answer here is yes. If I leave it running for several seconds nothign much changes, and the comma symbol is being constantly sent. There's plenty of transitions, as I can see this from attaching a scope to the output.

I'm not sure it's particularly a clock sync problem, more an alignment problem, as I constantly see the 16 bit symbol we send, just some times it'll be out of alignment by 8 bits.

We send:

-- comma sequence: send K28.5 (BC) and D16.2 (50) constant C_comma_data : std_logic_vector (15 downto 0) := X"BC50"; constant C_comma_charisk : std_logic_vector (1 downto 0) := B"10";

And after a reset, I see either a constant stream of 0xBC50 on the rxdata or 0x50BC.

In the case where I see 0x50BC it remains like that indefinitely until I send a packet. The packet is ignored by our design (as the start of packet symbol will be unaligned, and thus not read properly), but after the packet has gone through the channel is aligned properly, and rxdata reads 0xBC50 between packets, and all packets get across fine.

--
Michael Dales
University of Cambridge Computer Laboratory
http://www.cl.cam.ac.uk/~mwd24/
Reply to
Michael Dales

small hint, just connect ChipScope the rocketio outputs and you an analyzer at no extra cost :)

are you sure that MGT should be capable to correctly receive first packet after regaining lock (after loss of signal) - as soon as there ar 75 non transition data bits the lock is lost, and locking again takes time, so you need to supply some valid stream for lock-in before the first packet

there are some weirdos with RocketIO, as example an open input (also in case of short circuit of the input connectors) the MGT will receive a garbage with 4 bit repeating pattern. This is not only my observation but others have seen it as well. Also if the input DC balance is not kept constantly then after a DC balanced stream starts there maybe quite a large time for the input AC coupling caps to restore DC balance, during that time either constant 0 or 1 will be received.

I have used GT_CUSTOM in Serial ATA OOB testing, as much as I remember it locked and aligned ok, but there quite long repetive pattern for sync-in

Reply to
Antti Lukats

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.