Smallest GPL UART

I

Including a "when others =3D> state

Reply to
Andy
Loading thread data ...

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.

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

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
 Click to see the full signature
Reply to
Martin Thompson

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.
Reply to
Hal Murray

(snip)

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.

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

-- glen

Reply to
glen herrmannsfeldt

...

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.
Reply to
Hal Murray

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.

Reply to
j.m.granville

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

Reply to
Giuseppe Marullo

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

Reply to
glen herrmannsfeldt

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.

Reply to
j.m.granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.