09-19-2012 02:45 AM
I am now using the usb prot to receive 8 bit data in 9600 baud rate from PC. My design will simply echo # when upper case vowel is typed and echo N when others are typed. However, the result will only echo N whatever I typed. I assumed that it was the edian problem on receiver side. May I know that If the PC send 01010101 to the board, will the Nexy's 3 board automatically change it to 10101010 or remains the same? Anyway, I have tried both way but the result only echo N but not #. I have also check the clock frequency. It is 100MHz on board and 9600 baud from PC. Therefore I made a counter to count every 100M/9600 = 10416 clk cycle to read one bit. Could any one help me to get out this situation? Thanks.
09-19-2012 05:11 AM - edited 09-19-2012 05:12 AM
take a look at your design.
You have some UART there, with a Receiver and a Transmiter part.
Is there also some BaudRate Counter?
If so, what Input clock frequency is it expecting?
You have made a Clock divider of your own to clock the design.
Good attempt, but did you do it right?
UART Receivers often use 16 times overclocking to sample the data in the middle of a bit-intervall.
It's hard to tell without seeing the sources.
Did the transmitter work properly in any configuration?
How coult it send "N" chars with the 100MHz clock?
The Data Format of a RS232 transmission is properly defined .
The LSB cames after the start bit.
Have a nice synthesis
09-20-2012 08:27 AM
Thank you so much for your reply. I have tried your suggestion but still only echo N. For receiver, I made a clock divider and read data at the middle of each bit. For transmitter, I transmit each bit every 10416 clock cycles. (100M/9600 baud). I assume that the clock rate for receiver and transmitter are the same as 100MHz in Nexy's 3 board? I simulate my design using ModelSim which could get the correct result. But when I implement the design on the board and use tera-term / Hyperterminal to control it, the result is unexpected. I am wondering why the transmitter could work fine but receiver could not even I am using the similar design. I have attached my design code below. Most appreciate if you could take a look and debug anything wrong inside.
09-20-2012 09:03 AM
A classic error in UARTs is in the start bit detection. The serial data input is an asynchronous signal. If a state machine is branching on an asynchronous signal (for example, waiting for start bit), the state machine will be corrupted in very short order.
The countermeasure is to synchronise the serial input to the state machine's clock before feeding the signal to the state machine. The general principle is: no async inputs to state machines.
-- Bob Elkind
09-21-2012 05:09 AM
My design works with RS232 serial port but not the UART. Is there any difference between these two? Moreover, I am not quite understand how to synchronize the serial input. Would you mind to explain a bit more? Thank you.
09-21-2012 06:56 AM
My design works with RS232 serial port but not the UART. Is there any difference between these two?
Have you described to us the difference between "RS232 serial port" and "the UART"? I did not see where in this thread you described these two items, or the correctly operating combination of serial interfaces in the FPGA and PC.
Moreover, I am not quite understand how to synchronize the serial input. Would you mind to explain a bit more?
Please read this thread which discusses a similar problem. It explains the need to align asynchronous inputs to clocked logic.
-- Bob Elkind
09-24-2012 03:29 AM
it took me some time to take quick look at your code because of an illness.
It looks good at first glance, but seems somehow complicated .
Then I saw one of the big mistakes:
Your FSMs (e.g. in the serrx module) are totally buggy.
Compare your code to the FSM examples in the Language templates, and you will seee the difference.
Your only clocked proces does not have the state variable in it.
And the combinatorical process for the branch logic therefore goes wild.
Maybe it works in the simulation, but please check if this isn't so because of some missing signals in the sensitivity lists. (e.g r.srcontx_state).
There should be warnings in the simulator since you build some combinatorical loop. I wonder how Modelsim could accept this.
Synthesis does not care about sensitivity lists, so there things will work different than seen in the misleading wrong simulation.
So please take a look at the ISE Language Templates and read some threads about FSM coding and synchronous design.
Besides the real errors your design could need some simplification. You should also read about how to use Clock Enable for reducing the running speed of some synchronous design.
Have a nice synthesis