>

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

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 Wed, 17 Oct 2007 08:40:31 -0500, in comp.arch.embedded "athulyapg"
<athulyapg@cdactvm.in> 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.
>
As the CAE perpetual novice, I have to ask why are you trying to
emulate a uart, for the system, why not try another method of
encoding, say biphase mark, where you can have at least 10% timing
errors with no ill effect. Ok it will probably increase the bandwidth
of the transmission medium by 2. Would this be a problem?


Martin

On 2007-10-18, Tauno Voipio <tauno.voipio@INVALIDiki.fi> 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.
>
> 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.

Then add a bit-stuffing algorithm to make sure there's a
transition or three in every word, and Bob's your uncle. ;)
IIRC, even the 8-bit UARTs built into Motorola's 68HC11 series
used to resync on all falling edges, but I don't think I ever
used baud rate clocks that were bad enough that it mattered.

-- 
Grant Edwards                   grante             Yow! Here I am in the
                                  at               POSTERIOR OLFACTORY LOBULE
                               visi.com            but I don't see CARL SAGAN
                                                   anywhere!!

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.

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.

-- 

Tauno Voipio
tauno voipio (at) iki fi

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.

-- 
Grant Edwards                   grante             Yow! FROZEN ENTREES may
                                  at               be flung by members of
                               visi.com            opposing SWANSON SECTS ...

> data is 32 bit long,excluding start,parity& 2 stop bits.

You can't use a standard rs232 type UART for this.  You would either
have to transmit the data in chunks of 8 bits each, or you would have
to switch to a custom signalling scheme.  One method would be to
complement each bit with its inverse, so that a valid bit clock can be
recovered at the receiver.  Another method is convolutional coding,
which has the additional benefit of (limited) error correction
capabilities.

Marc

>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.

On Wed, 17 Oct 2007 18:22:41 GMT, Tauno Voipio
<tauno.voipio@INVALIDiki.fi> 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?

Is this a problem ?

For instance the SMC ports on any QUICC I/O coprocessor as used on the
MC68360, MPC960 etc. will support up to 16 bit characters, so the net
character size could be 12-14 bits, depending on if parity is used and
if one or two stop bits are used.

With long data word lengths, the baud rate generator accuracy becomes
critical. 

However, with very long word lengths, it might make sense to move to
synchronous transfer and let the message preamble synchronize the baud
rate PLL.

Paul