Smallest GPL UART

Giuseppe Marullo wrote:
> Jan, Frank, Tim, Nico and Andy,
> many thanks for your answer. I would like to stick with Verilog, at the
> moment I am trying with the following code:

Looks good, it uses the same idea I've used, sampling in the middle of a
bit after the start bit detection. This is not perfect, better receivers
use e.g. 8 times oversampling and a majority algorithm, but should work,
if your signal is not too noisy.

But you should latch the rx input, to avoid metastability problems. I
don't know how to do this in Verilog, something like declare another reg
with the name "rx", rename the raw input signal and copy it on rising
clock edge to "rx".

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Frank Buss <fb@frank-buss.de> wrote:

(snip)
> But you should latch the rx input, to avoid metastability problems. I
> don't know how to do this in Verilog, something like declare another reg
> with the name "rx", rename the raw input signal and copy it on rising
> clock edge to "rx".

Can you explain the problem that you are considering?

Not that slow logic can't have metastability problems, 
but in this case I wouldn't expect it.

-- glen

glen herrmannsfeldt wrote:
> Frank Buss <fb@frank-buss.de> wrote:
> 
> (snip)
>> But you should latch the rx input, to avoid metastability problems. I
>> don't know how to do this in Verilog, something like declare another reg
>> with the name "rx", rename the raw input signal and copy it on rising
>> clock edge to "rx".
> 
> Can you explain the problem that you are considering?

http://www.altera.com/literature/wp/wp-01082-quartus-ii-metastability.pdf

> Not that slow logic can't have metastability problems, 
> but in this case I wouldn't expect it.

My experience differs: I've used my simple UART receiver in a design
with 115,200 baud, and without the buffer, the state machine halted
(going to an invalid state, as I debugged with an "other" case branch,
which was logically impossible) once every some hour. There was lots of
high-speed logic behind the receiver and I've used only the classic
timing analyzer of an old version of Quartus, so maybe in simpler
designs, and with proper timing constraints for the rx signal, there
would be no problem.

But it is good design practice to buffer just any signal, which is fed
asynchronously to the FPGA, then you don't have such problems, even if
you didn't calculate and define all timing constraints.

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

On Wed, 02 May 2012 00:46:56 +0200, Frank Buss wrote:

> glen herrmannsfeldt wrote:
>> Frank Buss <fb@frank-buss.de> wrote:
>> 
>> (snip)
>>> But you should latch the rx input, to avoid metastability problems. I
>>> don't know how to do this in Verilog, something like declare another
>>> reg with the name "rx", rename the raw input signal and copy it on
>>> rising clock edge to "rx".
>> 
>> Can you explain the problem that you are considering?
> 
> http://www.altera.com/literature/wp/wp-01082-quartus-ii-
metastability.pdf
> 
>> Not that slow logic can't have metastability problems, but in this case
>> I wouldn't expect it.
> 
> My experience differs: I've used my simple UART receiver in a design
> with 115,200 baud, and without the buffer, the state machine halted
> (going to an invalid state, as I debugged with an "other" case branch,
> which was logically impossible) once every some hour. There was lots of
> high-speed logic behind the receiver and I've used only the classic
> timing analyzer of an old version of Quartus, so maybe in simpler
> designs, and with proper timing constraints for the rx signal, there
> would be no problem.
> 
> But it is good design practice to buffer just any signal, which is fed
> asynchronously to the FPGA, then you don't have such problems, even if
> you didn't calculate and define all timing constraints.

It might be a good practice to have that "other" case statement feeding a 
master reset or some other more sensible response to a bad state than 
wedging the FPGA, too.

Just sayin'

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

In article <jnpp51$2vn$1@newsreader4.netcologne.de>,
 Frank Buss <fb@frank-buss.de> writes:

>My experience differs: I've used my simple UART receiver in a design
>with 115,200 baud, and without the buffer, the state machine halted
>(going to an invalid state, as I debugged with an "other" case branch,
>which was logically impossible) once every some hour. There was lots of
>high-speed logic behind the receiver and I've used only the classic
>timing analyzer of an old version of Quartus, so maybe in simpler
>designs, and with proper timing constraints for the rx signal, there
>would be no problem.

It doesn't take metastability to do that.  You will miss setup/hold
if the signal has different timing paths to different FFs.  One
FF will see the old version of the signal and another FF will see
the new version.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Tim Wescott <tim@seemywebsite.com> wrote:
> On Wed, 02 May 2012 00:46:56 +0200, Frank Buss wrote:
>> glen herrmannsfeldt wrote:
>>> Frank Buss <fb@frank-buss.de> wrote:
 
>>> (snip)
>>>> But you should latch the rx input, to avoid metastability problems. I
>>>> don't know how to do this in Verilog, something like declare another
>>>> reg with the name "rx", rename the raw input signal and copy it on
>>>> rising clock edge to "rx".
 
>>> Can you explain the problem that you are considering?

(snip)
>>> Not that slow logic can't have metastability problems, 
>>> but in this case I wouldn't expect it.
 
>> My experience differs: I've used my simple UART receiver in a design
>> with 115,200 baud, and without the buffer, the state machine halted
>> (going to an invalid state, as I debugged with an "other" case branch,
>> which was logically impossible) once every some hour. 

OK, I suppose I could have looked at the actual logic before writing.

Yes, if one isn't careful with a state machine, it can have
metastability problems even with a slow clock.

There is also that Quartus likes to rearrange state machines logic,
such that it isn't like it is written. Some years ago, I found a
bug in Quartus where it converted to a one-hot state machine even
though I was using the state value in the design. (It had four
states, and as written two state bits. Quartus converted to one-hot
and gave two of the four as state bits.) 

>> There was lots of
>> high-speed logic behind the receiver and I've used only the classic
>> timing analyzer of an old version of Quartus, so maybe in simpler
>> designs, and with proper timing constraints for the rx signal, there
>> would be no problem.
 
>> But it is good design practice to buffer just any signal, which is fed
>> asynchronously to the FPGA, then you don't have such problems, even if
>> you didn't calculate and define all timing constraints.

Yes, if the design is such that more than one FF latches the same
input, and can fail if different values are latched on the same
clock cycle.

> It might be a good practice to have that "other" case statement feeding 
> a master reset or some other more sensible response to a bad state than 
> wedging the FPGA, too.

That seems to be the easy way to fix it. 

Now, it is likely that one additional clock cycle won't affect much, 
but one does have to consider that in terms of the overall logic.

-- glen

Hal Murray wrote:
> In article <jnpp51$2vn$1@newsreader4.netcologne.de>,
>  Frank Buss <fb@frank-buss.de> writes:
> 
>> My experience differs: I've used my simple UART receiver in a design
>> with 115,200 baud, and without the buffer, the state machine halted
>> (going to an invalid state, as I debugged with an "other" case branch,
>> which was logically impossible) once every some hour. There was lots of
>> high-speed logic behind the receiver and I've used only the classic
>> timing analyzer of an old version of Quartus, so maybe in simpler
>> designs, and with proper timing constraints for the rx signal, there
>> would be no problem.
> 
> It doesn't take metastability to do that.  You will miss setup/hold
> if the signal has different timing paths to different FFs.  One
> FF will see the old version of the signal and another FF will see
> the new version.

Right, this is slightly different from metastability, and maybe was the
reason for the behaviour in my FPGA program, though the bugfix is the
same :-)

Is there a technical term for this special kind of problem?

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

On 05/02/2012 12:46 AM, Frank Buss wrote:

>>> But you should latch the rx input, to avoid metastability problems. I
>>> don't know how to do this in Verilog, something like declare another reg
>>> with the name "rx", rename the raw input signal and copy it on rising
>>> clock edge to "rx".
>>
>> Can you explain the problem that you are considering?
>
> http://www.altera.com/literature/wp/wp-01082-quartus-ii-metastability.pdf
>
>> Not that slow logic can't have metastability problems,
>> but in this case I wouldn't expect it.
>
> My experience differs: I've used my simple UART receiver in a design
> with 115,200 baud, and without the buffer, the state machine halted
> (going to an invalid state, as I debugged with an "other" case branch,
> which was logically impossible) once every some hour. There was lots of
> high-speed logic behind the receiver and I've used only the classic
> timing analyzer of an old version of Quartus, so maybe in simpler
> designs, and with proper timing constraints for the rx signal, there
> would be no problem.

Usually these problems are the result of an incoming asynchronous 
signal, like a UART RxD, going to two different inputs in the FPGA at 
the same time.

When the signal has an undefined voltage right at the clock edge, one 
input could capture it as a '0', and the other input as a '1', 
potentially resulting in inconsistent states.

Note that this has nothing to do with metastability.

In comp.arch.fpga,
Frank Buss <fb@frank-buss.de> wrote:
> Hal Murray wrote:
>> 
>> It doesn't take metastability to do that.  You will miss setup/hold
>> if the signal has different timing paths to different FFs.  One
>> FF will see the old version of the signal and another FF will see
>> the new version.
>
> Right, this is slightly different from metastability, and maybe was the
> reason for the behaviour in my FPGA program, though the bugfix is the
> same :-)
>
> Is there a technical term for this special kind of problem?

Race condition


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Experience varies directly with equipment ruined.

On Apr 30, 7:17=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Mon, 30 Apr 2012 00:22:50 +0000, Nico Coesel wrote:
> > Giuseppe Marullo <giuseppe.marullonos...@iname.com> wrote:
>
> >>Hi all,
> >>I am searching for the smallest/simpler UART in verilog. I need to
> >>release the project under GPL and still confused about what are my
> >>options.
>
> >>I would go with micro UART by Jeung Joon Lee but I am unable to
> >>determine its license.
>
> >>There are others, like osvudu by Timothy Goddard seems released under
> >>(a) MIT license, thus compatible with GPL.
>
> >>I need very simple stuff:
>
> >>baud rate 9600-115200 with a clock of about 100MHz but should be able t=
o
> >>run with other clocks, like 12MHz. No buffers and other fancy stuff.
>
> >>8N1, and possibility (I need some) to have rtx, tx and rx only
> >>capability (I would like to instantiate just the parts I need).
>
> >>Don't know if I need fullduplex, possibly yes.
>
> >>What would you advice to use?
>
> > There is a very simple UART packed togethet with Xilinx's KCPSM. I agre=
e
> > with the others. Open Source UARTs are not always the best solution. I
> > once used the 16550 UART from opencores but it is pretty crappy. Very
> > slow due to an overly complex design.
>
> A design that did a good job of emulating the 16550 would have to be a
> lot more complex than just a good asynchronous receiver-transmitter.
> pair. =A0Particularly if you can hard-code the division ratio, bit count,
> etc., they are easy-peasy thing to write.
>
> Certainly "overly complex" if you just need a serial interface -- but
> maybe not so if you must have compatibility with existing software.
>
> (Note: I don't know at what point in the process one loses the
> "universal" moniker -- but hard-coding all the bits that are normally
> software programmable would seem to be it).
>

one "universal" thing I almost always use when I need a uart in an
FPGA
is to generate the baudrate with a DDS

very simple and able to hit almost any baud rate at any clock rate

-Lasse