Smallest GPL UART

On May 1, 8:11=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Tim Wescott <t...@seemywebsite.com> wrote:
> > On Wed, 02 May 2012 00:46:56 +0200, Frank Buss wrote:
> >> glen herrmannsfeldt wrote:
> >>> Frank Buss <f...@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

Including a "when others =3D> state <=3D reset"; will not help unless you
turn off state machine optimization, or invoke other "safe" state
machine synthesis settings. One of the optimizations most any
synthesizer worth its salt will do is remove "unreachable" states
(those states that do not have a coded assignment or path to them.)
Thus since "others" is not directly reachable, it gets optimized out,
along with anything it was doing.

There are multiple ways of dealing with this, most depend either on
invoking synthesis tool settings or turning off state machine
optimizations and manually handling it yourself in the RTL (such as
with a "when others". Be careful though; some of the simplest to code
methods result in the worst utilization and performance.

However, it is best to handle the root of the problem, which is an
improperly synchronized asynchronous input.

The term for this problem is not "race condition" it is an "improper
parallel synchronizer", or a  circuit that clocks the same
asynchronous input into more than one register in parallel.

A "race condition" is when proper operation requires that one
combinatorial path must be faster than another.

Andy

Tim Wescott <tim@seemywebsite.com> writes:

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

Mandatory, I'd say, unless you can make a cast-iron argument as to why it
doesn't matter if it is sampled differently by two different flops.

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

You'd think, wouldn't you?

But ( at least in VHDL) you also have to be aware that synthesis tools
(unless you do some hoop-jumping) are "clever" enough to "know" that you
can't get to those invalid states (especially in VHDL when using an
enumerated type: in language terms, anything outside the enumeration
doesn't exist!).

So they optimise out your nice recovery logic :(

Quartus has an attribute to make the synth put its own reset logic in for
invalid states, to go back to the reset state.

XST has an attribute to specify the safe state it should go to when
state is invalid.  And another to enable that behaviour.

Synplify has an option to generate logic to put things back to the reset
state if an illegal state is detected.

None of which makes the implementation match the code...

Synplify also has an option to create an "exact" state machine, which
does do precisely what your code says (or so it claims) at the expense
of disabling all its clever optimisations for that machine.

Take your pick :)

Cheers,
Martin





>
> Just sayin'

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

In article <pv5y5p9w6uy.fsf@trw.com>,
 Martin Thompson <martin.j.thompson@trw.com> writes:
>Tim Wescott <tim@seemywebsite.com> writes:
>
>>> 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.
>
>Mandatory, I'd say, unless you can make a cast-iron argument as to why it
>doesn't matter if it is sampled differently by two different flops.

Even if you are sure it doesn't matter, you aren't out of the water yet.

You still have to consider metastability.

You also have to consider the design lifetime.  Will the guy who
changes something in this area several years from now be smart
enough to know that he needs check again?  Will he get it right?

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

Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:

(snip)
>> Mandatory, I'd say, unless you can make a cast-iron argument as 
>> to why it doesn't matter if it is sampled differently by 
>> two different flops.

> Even if you are sure it doesn't matter, you aren't out of the water yet.

> You still have to consider metastability.

In most cases, for slow logic you don't. 

Metastability becomes a problem if the logic after the FF is
long enough, and the FF is likely (ever) to be metastable long
enough to cause problems. 

Note that you can never get rid of metastability, but only
make it unlikely enough to cause a problem. In high speed
designs, the logic delay is a significant part of a clock cycle,
and even a short metastability can be long enough.

> You also have to consider the design lifetime.  Will the guy who
> changes something in this area several years from now be smart
> enough to know that he needs check again?  Will he get it right?

As with metastability, there is no way to avoid that.

-- glen

In article <jo1lgf$e5r$1@speranza.aioe.org>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
...

>> Even if you are sure it doesn't matter, you aren't out of the water yet.
>> You still have to consider metastability.

>In most cases, for slow logic you don't. 

Good point.  Thanks.


The key idea being "slow logic" where the metastability settling time
is small relative to the cycle time.

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

On Wednesday, May 2, 2012 5:43:02 PM UTC+12, Frank Buss wrote:
> 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?

 My preference is to call it an Aperture Effect, as it is actually a small, but finite time window, and you can even calculate the width (in ns/ps) of this Aperture, given a large enough data-set sample size.

>
> Note that this has nothing to do with metastability.
Houston we have a problem.

I am implementing this stuff on a LX9 board that has a direct USB serial 
interface. I tried to run it at 9600 baud, and it seemed to work fine.

I Implemented a small FSM that would echo a char back, maybe with a 
little modification, ie send 'a' get back a 'c' (+2).

It worked but not if I kept sending char (a key always pressed down), 
after about 20 chars there was some strange char back.

Thinking about baud rate tolerance and/or problem sending back fast the 
char it received, I fiddled with the stop bits, hoping that it would 
allow more time to "process" the incoming char.

No dice.

I tried to slow down the pace at which I would send chars, like 1 every 
second or so, but every 15-20 char max, there was a very different char 
back.

I was unable to debug with a LA (there is not much where I could connect 
between the pc and the fpga) I tried to simulate a workbench
to exercise the fsm. It was rather difficult for me (several tasks in 
parallel and so on) but the simulation seemed to work.

I tried to send the char it received from my pc to a serial LCD, and 
there was even more errors on the output of the LCD.


At the end, I added this to the rx pin:

reg [2:0] rx_buffer;
wire rx_clean = rx_buffer[2];
always @(posedge clk)
   rx_buffer <= {rx_buffer[1:0], rx};

It is working perfectly so far. Metastability, noise or whatever there 
is something I don't get here. I have a very fast clock (100MHz) so 
maybe it would benefit from a oversampling approach but the difference 
with this metastabilitywhatever dirty fix is very noticeable.


Giuseppe Marullo

Giuseppe Marullo <giuseppe.marullonospam@iname.com> wrote:

>> Note that this has nothing to do with metastability.
> Houston we have a problem.

> I am implementing this stuff on a LX9 board that has a direct USB serial 
> interface. I tried to run it at 9600 baud, and it seemed to work fine.

> I Implemented a small FSM that would echo a char back, maybe with a 
> little modification, ie send 'a' get back a 'c' (+2).

> It worked but not if I kept sending char (a key always pressed down), 
> after about 20 chars there was some strange char back.

> Thinking about baud rate tolerance and/or problem sending back fast the 
> char it received, I fiddled with the stop bits, hoping that it would 
> allow more time to "process" the incoming char.

Add one more stop bit to the device sending to your board.

Also, your board should start counting bits half way through the
start bit, such that it looks at the center of each bit.

You should be ready to start a new character after the middle of
the stop bit, though there really should be a whole stop bit.

As you note, because of clock tolerance, data might be coming in
faster than you can send it out. You could add a fifo, but eventually
you will fill it up unless you send data slower than it comes back.

-- glen

On Thursday, May 17, 2012 11:00:53 AM UTC+12, Giuseppe Marullo wrote:
> I tried to run it at 9600 baud, and it seemed to work fine.
> I tried to slow down the pace at which I would send chars, like 1 every 
> second or so, but every 15-20 char max, there was a very different char 
> back.
>
> At the end, I added this to the rx pin:
> 
> reg [2:0] rx_buffer;
> wire rx_clean = rx_buffer[2];
> always @(posedge clk)
>    rx_buffer <= {rx_buffer[1:0], rx};
> 
> It is working perfectly so far. Metastability, noise or whatever there 
> is something I don't get here. I have a very fast clock (100MHz) so 
> maybe it would benefit from a oversampling approach but the difference 
> with this metastabilitywhatever dirty fix is very noticeable.

 Did you also add a majority vote on those samples ?

 it does seem strange from a random sampling angle - if you are running 9600 baud, and you get failures of 1 in 25, that suggests an error window equivalent of around 4us.

 Things may not be random, I'd look around for something else wrong.
(ie you may not have fully fixed a problem, just moved it slightly)

  Samples should be ~52us clear of any edges, and Stop bit should flip to start edge polling, at 50% stop time (this gives margin for baud rate skews)
( Shipping UARTS have made this mistake, you can also check by sending two stop bits )
 You could output a pulse when you sample, and another when ready-for-Start, and scope that - at least a 1:25 failure is often enough, to be easy to catch.