OpenCores

OpenCores

a VHDL 16550 UART core & Wishbone LPC Host and

no use

no use

1/1

no use

no use

a VHDL 16550 UART core & Wishbone LPC Host and by Hharte on Oct 1, 2008			Hharte Posts: 1 Joined: Sep 30, 2007 Last seen: Oct 14, 2009
hello Marcus, Can you please provide more information on your LPC host? I've been wanting to test the LPC bridge with a third-party host. Glad to hear you are using the core. Any feedback is appreciated. -Howard ----- Original Message ----- From: marcus.erlandsson at opencores.org<<A HREF="http://www.opencores.org/mailman/listinfo/cores">marcus.erlandsson at o...</A>> To: Date: Wed Oct 1 17:10:02 CEST 2008 Subject: [oc] a VHDL 16550 UART core & Wishbone LPC Host and Peripheral Bridge [q] Hi Matt, Please send an email to the maintainer/s of this cores and describe the issue so that it can be upgraded/fixed. It is very important that we track potential bugs. Regards Marcus ----- Original Message ----- From: Matt Ettus<matt at e...> To: Date: Wed Oct 1 08:14:02 CEST 2008 Subject: [oc] a VHDL 16550 UART core & Wishbone LPC Host and Peripheral Bridge [q]> Thomas at opencores.org wrote: [q] > Hi! > > I have a problem when implementing the 16550 UART [/q] together [q]> with the wb [q] > to lpc peripheral (using gh_vhdl_lib). I use a Endura [/q] TP945 [q]> board as a [q] > host and implement the design on a xilinx starter board. [/q] The [q]> problem [q] > is that when I try to read from the MSR register the data [/q] is [q]> wrong and [q] > the other registers is resetted. If the register is set [/q] to a [q]> constant [q] > value, everything works fine. If, for example (for bit 0 [/q] in [q]> the MSR [q] > register) the value in to the jkff is set to a constant [/q] '0', [q] > everything works fine. But otherwise, the iDCTS goes high [/q] > during a [q] > read, indicating that the value on CTSn has changed (CTSn [/q] is [q]> set to '1'). [q] > This is not really a big problem since the register is [/q] not [q]> used, but I [q] > would really like to understand this. > I have also tried to implement extra wait states without [/q] > result. [q] > [/q] > I have found several problems in that core, but I didn't [/q] notice the [q]> issues you have. You can get my fixed version here: > svn co > > [/q] <A HREF="http://gnuradio.org/svn/gnuradio/trunk/usrp2/fpga/opencores/uart16550">http://gnuradio.org/svn/gnuradio/trunk/usrp2/fpga/opencores/uart16550</A> [q]> Among the bugs are problems with the FIFOs and a bad wishbone > interface. > Matt > > [/q] [/q] hello Marcus, Can you please provide more information on your LPC host? I've been wanting to test the LPC bridge with a third-party host. Glad to hear you are using the core. Any feedback is appreciated. -Howard ----- Original Message ----- From: marcus.erlandsson at opencores.orgmarcus.erlandsson at o...> To: Date: Wed Oct 1 17:10:02 CEST 2008 Subject: [oc] a VHDL 16550 UART core & Wishbone LPC Host and Peripheral Bridge Hi Matt, Please send an email to the maintainer/s of this cores and describe the issue so that it can be upgraded/fixed. It is very important that we track potential bugs. Regards Marcus ----- Original Message ----- From: Matt Ettus To: Date: Wed Oct 1 08:14:02 CEST 2008 Subject: [oc] a VHDL 16550 UART core & Wishbone LPC Host and Peripheral Bridge > Thomas at opencores.org wrote: > Hi! > > I have a problem when implementing the 16550 UART together > with the wb > to lpc peripheral (using gh_vhdl_lib). I use a Endura TP945 > board as a > host and implement the design on a xilinx starter board. The > problem > is that when I try to read from the MSR register the data is > wrong and > the other registers is resetted. If the register is set to a > constant > value, everything works fine. If, for example (for bit 0 in > the MSR > register) the value in to the jkff is set to a constant '0', > everything works fine. But otherwise, the iDCTS goes high > during a > read, indicating that the value on CTSn has changed (CTSn is > set to '1'). > This is not really a big problem since the register is not > used, but I > would really like to understand this. > I have also tried to implement extra wait states without > result. > > I have found several problems in that core, but I didn't notice the > issues you have. You can get my fixed version here: > svn co > > http://gnuradio.org/svn/gnuradio/trunk/usrp2/fpga/opencores/uart16550 > Among the bugs are problems with the FIFOs and a bad wishbone > interface. > Matt > >

no use

no use

1/1

no use

no use

© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.