FPGARelated.com
Forums

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

Started by Jonathan Bromley February 6, 2009
On Thu, 5 Feb 2009 21:58:31 -0800 (PST), rickman wrote:

[of the Ken Chapman UART design that jleslie48 is using]

>Wow! I know it is possible and will potentially give you the optimum >size design, but I have never actually seen a unit that was 100% >instantiated. Technically this is VHDL. But for all practical >purposes, this is a schematic expressed in text.
Yes, I was pretty staggered too. It makes heavy use of SRL16s to do the various shifters. It's an amazing piece of bravura optimization, and for something totally re-usable like a UART it's probably a rather good idea to have such a thing handy.
>> the reset to the UART being handled? I don't think it makes a >> difference, I never send one. > >I see that the UART has no reset. The FIFO however, *does* have a >reset which is the signal reset_buffer driven by your signal >UART_RESET_BUFFER. So that needs to be asserted for a while before >the UART is used. Otherwise the FIFO counters may not be in the right >state.
I think jleslie48's design does indeed assert that FIFO reset appropriately for a few clock cycles at startup.
>Actually, I think I have lost the thread of what the problem is. Is >the simulation working 100% and the real chip is *not* working? If >so, looking at the simulation won't tell you a lot.
It might be worth re-stating my data point from yesterday: I created a simple message generator design myself, using the same UART macros that jleslie48 uses, and it works just fine both in simulation and in real hardware (Spartan-3 starter kit, 50MHz system clock; the timing report says it's all good for at least 110MHz). So I really don't think it will do the OP any good to try to understand the very tricksy coding of the UARTs. He can use them out-of-the-box with confidence. I didn't get an answer to my question yesterday about whether the OP's 16.7MHz divided clock is correctly distributed on an internal clock net - i.e., has the Xilinx software correctly recognized it to be a clock. Careless use of a divided or gated clock is a likely culprit for mismatch between simulation and hardware. The OP should consider clocking absolutely everything from his 100MHz system clock, and increasing the baud rate divider to the appropriate value. I'm not saying it would make any difference, but at least it would remove one source of uncertainty (oops, sorry, a "known unknown"). -- 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 6, 3:37 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Thu, 5 Feb 2009 21:58:31 -0800 (PST), rickman wrote: > > [of the Ken Chapman UART design that jleslie48 is using] > > >Wow! I know it is possible and will potentially give you the optimum > >size design, but I have never actually seen a unit that was 100% > >instantiated. Technically this is VHDL. But for all practical > >purposes, this is a schematic expressed in text. > > Yes, I was pretty staggered too. It makes heavy use of SRL16s > to do the various shifters. It's an amazing piece of bravura > optimization, and for something totally re-usable like a UART > it's probably a rather good idea to have such a thing handy. > > >> the reset to the UART being handled? I don't think it makes a > >> difference, I never send one. > > >I see that the UART has no reset. The FIFO however, *does* have a > >reset which is the signal reset_buffer driven by your signal > >UART_RESET_BUFFER. So that needs to be asserted for a while before > >the UART is used. Otherwise the FIFO counters may not be in the right > >state. > > I think jleslie48's design does indeed assert that > FIFO reset appropriately for a few clock cycles at startup. > > >Actually, I think I have lost the thread of what the problem is. Is > >the simulation working 100% and the real chip is *not* working? If > >so, looking at the simulation won't tell you a lot. > > It might be worth re-stating my data point from yesterday: > I created a simple message generator design myself, using > the same UART macros that jleslie48 uses, and it works > just fine both in simulation and in real hardware (Spartan-3 > starter kit, 50MHz system clock; the timing report says it's > all good for at least 110MHz). So I really don't think it > will do the OP any good to try to understand the very tricksy > coding of the UARTs. He can use them out-of-the-box with > confidence. > > I didn't get an answer to my question yesterday about whether > the OP's 16.7MHz divided clock is correctly distributed on > an internal clock net - i.e., has the Xilinx software > correctly recognized it to be a clock. Careless use of > a divided or gated clock is a likely culprit for mismatch > between simulation and hardware. The OP should consider > clocking absolutely everything from his 100MHz system clock, > and increasing the baud rate divider to the appropriate value. > I'm not saying it would make any difference, but at least > it would remove one source of uncertainty (oops, sorry, > a "known unknown"). > -- > 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.
Ok, I took a good look at the code; this is brilliant. You have built a formatted output handler. I can't wait to try this out. "I didn't get an answer to my question yesterday about whether the OP's 16.7MHz divided clock is correctly distributed on an internal clock net - i.e., has the Xilinx software correctly recognized it to be a clock." I took some measurements with both the simulator and the oscilliscope on the ASCII code coming out and the clock time is exactly what was expected: I just realized you can even see me checking that in this screencap (11): http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap11_missingfirstletter.png anyway I'll be building a new project today and analyzing your formatted output generator. Thanks again, Jonathan Leslie