Honored Contributor
Honored ContributorMike you mean that the electrical layer is not the source of the problem ? it must be inside the fpga ? if so .. yes i agree with you.
well currently i am not shure if the software engineers have tried the fpga version with locked baudrate. sorry i cannot tell you what happens if the uart is locked by sopc to run at 115200 8N1 :-( but to be shure i need this information. Our new IP is much more than just a uart. it carries the signal with 16MBit/sec with a clock speed of 64MHz. what means that this uart could transfer 1,6MByte/sec minus the protocol. This IP core can work with duty cycles of 60:40 to 40:60, jitter on the signal. it always resync's inside the stream. the rxd is filtered so spikes and glitches won't disturb. This has been designed with our full custom asic tools on our SUN over worst case situations and successfully implemented on our target. so each device is a master and the ip core handles arbitration with a guranteered maximum bus cycle time. so no software overhead. The first thing i will look after inside the uart core is, if the rxd signal is filtered. i would expect that the rxd signal is piped into a shift register where a 3 out of 4 detection triggers a SRFF. 3 one's will set and 3 zero's will clear this filtered rxd. if there is no filtering any glitch could trigger. In some of our ip cores we go a bit further and check if the first half of the startbit is zero with each clock cycle. This is needed if the signal comes from a rf-transmission where every little "fly" can disturb and modify the signal. Yes for industrial inviroment we need a uart that is some kind of "bullet proof". And the fact that other uarts (not the sopc uart) detects the transmitted 0x02 and only the sopc uart delivers wrong data ......... (i will not comment this any further)
