Hello All,

I was wondering if anyone could explain a line in the 16550 code. I'm
trying to do a simple test with this core but wasn't able to get it
working. I know I can't simulate it because it uses the on-chip ram
but I can at least simulate the initialization of the core.

In the wishbone interface file uart_wb, there is a line at the bottom
of the file that practically (at least how I'm reading it) destroys
the address value that is being passed into the core. It takes the
top 3 bits and concats them with a value determined by the data select
lines. This doesn't make any sense to me. The data select lines
should be used to select which portion of the data lines should be
read or written, not to determine what register address to write to.
The bottom two bits of the address are simply wiped out.

Can anyone offer any insight to this?

Thanks,
Chris

On Fri, 2009-02-20 at 18:05 +0100, chris.reeg at gmail.com wrote: Hi Chris, I think wb_adr_int reports what the byte address of the register in the UART would be, allowing for the UART having a different endianism (specified by LITLE_ENDIAN) in its byte addressing to the main processor (for which it is dynamically configurable). I note that in ORPSoC this output is not connected, so the value is irrelevant. I'm not sure if Igor Mohor or Jacob Gorban (the original authors) monitor this mailing list and are able to comment? I note this was a late addition made by Tadej Markovic in 2004. HTH, Jeremy -- Tel: +44 (1202) 416955 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: jeremy.bennett at embecosm.com Web: www.embecosm.com

chris.reeg at gmail.com wrote:

There's no reason you can't simulate a design that uses on-chip ram...

As Jeremy says, it's to do with the code that handles endianity for a 32-bit data bus. The wb_adr_int signal presents a consistent address to the core logic. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266