32 bit uart

athulyapg wrote:
>>athulyapg wrote:
>>
>>>Hi
>>>Im trying to implement an 32bit Uart in cyclone 2 fpga(ep2c8t144).
>>>My requirements are as follows:
>>>speed: 9600bps
>>>In built fifo(depth 8)at transmitter and receiver side.
>>>DMA and Modem controller not required.
>>>
>>>Can anyone help me with a vhdl code.
>>
>>Homework / study project?
>>
>>Do you mean that the characters sent between
>>start and stop bits are 32 bits long?
>>
>>-- 
>>
>>Tauno Voipio
>>tauno voipio (at) iki fi
>>
>>
> 
> 
> data is 32 bit long,excluding start,parity& 2 stop bits.

This will tighten your clock tolerance, to probably exclude ceramic 
resonators, but crystals will be OK.

Is this some existing product ? - 9600bd and 32 bits is an unusual 
pairing. I can see merit in longer data blocks, as you know it is
then atomic. (even if non-std)

What stops you simply editing std 8 bit UART VHDL code ?
That's a fairly safe edit. Start with an 8 bit one, and
do the full build/simulate, to have a known reference, and
then just widen it ?

-jg

On Thu, 18 Oct 2007 18:22:24 GMT, Tauno Voipio
<tauno.voipio@INVALIDiki.fi> wrote:

>Grant Edwards wrote:
>> On 2007-10-18, jetmarc@hotmail.com <jetmarc@hotmail.com> wrote:
>> 
>>>>data is 32 bit long,excluding start,parity& 2 stop bits.
>>>
>>>You can't use a standard rs232 type UART for this.
>> 
>> 
>> That's probably why he's implementing his own using an FPGA.
>> I would think that modifying the VHDL for an 8-bit UART to make
>> it handle 32-bits wouldn't be that hard.
>
>
>The main problem would be in receiving:
>It is harder to stay in sync with the
>transmitter if there are four time as
>many bits between the sync points.

The longer data word only requires a four times better frequency match
between the transmitting and receiving bit rate generators (compared
to 8 bit UARTs), since you need to keep the receiver sampling point
close to the center of each data bit also at the end of the
transmitted word. This should not be a big problem with proper crystal
oscillators, at least if both equipment are in the same temperature.

Detecting the start bit reliably and accurately is as hard for 32 as
well as 5 bit data words.

>I made such a thing in software about
>25 years ago: An old Rohde & Schwarz
>VHF direction finder sent the results
>in 35 bit async frames. It proved to
>be necessary to re-synchronise the
>sampling point from all transitions
>to keep in sync.

Most likely the software implementation caused these problems. Even if
you could get the exact number of instruction execution times between
the sampling points e.g. using busy loops, you still would have to
account for interrupts, different cache hits etc. 

After all using an on-chip CPU clock oscillator is going to cause
frequency drift due to varying CPU temperature, caused by varying
processing loads. 

Of course, if the transmitting bit rate was fluctuating, then there is
not much to be done than searching for transitions to update the
receiver bit rate frequency.

Paul

>