Re: rs232 uart: testbench vs real world, and the missing first letter.

On Thu, 05 Feb 2009 00:42:41 +0000, Jonathan Bromley wrote:

> I've written a data 
>generator to create your message strings
[...]
>And I've rewritten the top module to use this alongside
>your existing UART transmitter.  You should be able to
>try it out rather easily and tell me whether it works -
>I've only tried it in simulation so far, but I'll try 
>it on my little demo board tomorrow.

Yup, it worked just fine.  Luckily I remembered to 
correct the baud rate divider to account for the 
50MHz clock on my dev board, so I actually got it 
to work first time.  Ah, the joys of simulation.

Sincere apologies to all you seasoned engineers
on comp.arch.fpga for my self-satisfaction here.
I don't do so much with real hardware these days, 
so it's always nice to discover that I haven't 
completely lost my touch :-)

Three noteworthy points:

1) My design appears to spit out one character of
   garbage at startup.  This isn't real; it's caused
by my PC's UART receiver seeing breaks or other junk
as a result of the Tx line thrashing about while the
FPGA is configured.   As Antti and I pointed out,
you need to leave plenty of settling time on the
serial line after all the indeterminate stuff that
happens at power-up and configuration.  Depending
on exactly how the RS-232 hardware is wired up on
your platform, you may be able to engineer your 
way around this by ensuring that the line floats
to its idle, marking state during configuration.
On my cheap board, the Tx line goes to a space
condition (=break) during configuration; I can't 
fix that unless I hack the board.

2) I note that you run all your UART and data logic
   from a 16.67MHz clock that you get by dividing 
your 100MHz system clock by 6.  Have you checked that
the divided clock is correctly using the clock
distribution network?  I'd be amazed if not, but
if for any reason that has gone wrong, you could
get some pretty strange behaviour.

3) I used the UART's TX_BUFFER_HALF_FULL signal
   to stall my data generator.  I did that because
your strange "15 works, 16 doesn't" symptoms suggested
that the 16-deep FIFO might not be working quite right.
To test this I switched over to using TX_BUFFER_FULL
to throttle the data generator, and everything still
works just fine.  So the FIFO in Ken Chapman's UART
design is blameless (no surprise there).
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

On Feb 5, 11:50 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Thu, 05 Feb 2009 00:42:41 +0000, Jonathan Bromley wrote:
> > I've written a data
> >generator to create your message strings
> [...]
> >And I've rewritten the top module to use this alongside
> >your existing UART transmitter.  You should be able to
> >try it out rather easily and tell me whether it works -
> >I've only tried it in simulation so far, but I'll try
> >it on my little demo board tomorrow.
>
> Yup, it worked just fine.  Luckily I remembered to
> correct the baud rate divider to account for the
> 50MHz clock on my dev board, so I actually got it
> to work first time.  Ah, the joys of simulation.
>
> Sincere apologies to all you seasoned engineers
> on comp.arch.fpga for my self-satisfaction here.
> I don't do so much with real hardware these days,
> so it's always nice to discover that I haven't
> completely lost my touch :-)
>
> Three noteworthy points:
>
> 1) My design appears to spit out one character of
>    garbage at startup.  This isn't real; it's caused
> by my PC's UART receiver seeing breaks or other junk
> as a result of the Tx line thrashing about while the
> FPGA is configured.   As Antti and I pointed out,
> you need to leave plenty of settling time on the
> serial line after all the indeterminate stuff that
> happens at power-up and configuration.  Depending
> on exactly how the RS-232 hardware is wired up on
> your platform, you may be able to engineer your
> way around this by ensuring that the line floats
> to its idle, marking state during configuration.
> On my cheap board, the Tx line goes to a space
> condition (=break) during configuration; I can't
> fix that unless I hack the board.
>
> 2) I note that you run all your UART and data logic
>    from a 16.67MHz clock that you get by dividing
> your 100MHz system clock by 6.  Have you checked that
> the divided clock is correctly using the clock
> distribution network?  I'd be amazed if not, but
> if for any reason that has gone wrong, you could
> get some pretty strange behaviour.
>
> 3) I used the UART's TX_BUFFER_HALF_FULL signal
>    to stall my data generator.  I did that because
> your strange "15 works, 16 doesn't" symptoms suggested
> that the 16-deep FIFO might not be working quite right.
> To test this I switched over to using TX_BUFFER_FULL
> to throttle the data generator, and everything still
> works just fine.  So the FIFO in Ken Chapman's UART
> design is blameless (no surprise there).
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

"3) I used the UART's TX_BUFFER_HALF_FULL signal
    to stall my data generator.  I did that because
   your strange "15 works, 16 doesn't" symptoms suggested
   that the 16-deep FIFO might not be working quite right."


I did that yesterday to, using the same thought process.  I
hope that means I'm at least thinking in the right directions.

Thanks again for your time in this.

Sincerely,

Jonathan