Forum Discussion
Altera_Forum
Honored Contributor
19 years agoHi Fischer,
the transceiver is a true fail safe type MAX3078xxx with hardware autotermination. The design is a multi master, self arbitrating, 16MBit/sec Bus with priority of different Masters and datatelegramms running as a avalon master. Bevor this design was finished we used the sopc uart as a transport module so the software group could start implementing der code. our nios was running at 64MHz und the uart was not able to run faster than 38400 without delivering wrong bytes at the beginning. Again a long "idle" meaning a "1" on the line and then a data telegram travels along tha bus leading to wrong bytes. the hardware now runs at 16MBit/sec without any modification. If the termination is on we haven't any wrong bit or corrupted telegramm. The "gap" between two transmitting masters is less than 2uSec. taking into account the roundtriptime along a 100m cable of about 60% of c and the delay the tranceivers introduce. The bus hardware is not the source of the problem. It is qualified and testet and signed "bullet proof" for industrial application and the emc disturbances that could happen. All parts like tranceivers, cable, connectors, layout, .... are very well engineered for transmission of up to 16MBit/sec. The signal that comes into the fpga is perfect. External measurements using LeCroy scopes and SignalTap showed a absolut stable signal. we could "see" the correct bit pattern and see what the uart delivers to nios via avalon. The data entering the sopc uart was a perfect and correct serial bitstream, but the parallel data stream was wrong. again .... the start of the data was mostly wrong and it has happend that the data somewhere in the middle was wrong. So if the uart is idle and has nothing to do, the first startbit enteres the uart followed by the 8 databits and a stopbit why does the uart deliver a wrong databyte ? The uart is not used anymore for this bus and replaced by the finished sopc module i have written. it is only used for a terminal interface the softwaregroup wants during debugging. but we will use a uart if a customer wants a good old serial interface as a host connection and then we will deceide what uart will be used. I do not think that the sopc uart will be used as it is currently not reliable. Michael Schmitt