11:40 <lkcl__> does anyone know how to get litex to add a 16550 UART - in simulation - at an address 0xc0002000 ?

11:41 <lkcl__> so far i have tracked down (by looking at the generated csr.h) that UART (of an indetermined type, possibly not a 16550) is added by default at 0xc0001800 ("uart allocated at location 0")

11:49 <daveshah> I may be wrong but I don't think Litex has a 16550

11:52 <daveshah> It is possible to override the address using csr_map but I haven't done that for a while

11:55 <lkcl__> daveshah: mmm... drat. yeah i over-rode csr_map["sram"]... oh wait, no that was self.mem_map["sram"], it has allowed me to put an integrated RAM at 0x0000000 so i can run microwatt unit tests

11:55 <lkcl__> csr_map, i will try that, see what happens.

11:56 <lkcl__> ah the format is, csr_map['uart'] = 4 # Location 4

11:56 <lkcl__> holy shit it worked

11:57 <lkcl__> .oOOo.

11:57 <lkcl__> ; .mw. ; Microwatt, it works.

11:57 <lkcl__> ." ".

11:57 <lkcl__> :)

11:57 <lkcl__> wow, wow, that's incredible, it works for libresoc as well!

11:59 <daveshah> Great!

11:59 <daveshah> Did it turn out to be 16550 enough for the tests?

11:59 <lkcl__> basically yes

12:00 <lkcl__> i can't type at it via the simulation

12:00 <lkcl__> so keyboard interaction is out (the simulation of hello_world.bin is supposed to echo)

12:00 <lkcl__> but i don't need that right now

12:01 <lkcl__> it's enough so that i can try adding XICS interrupt handling without rewriting the microwatt tests/xics.bin

12:05 <lkcl__> right. sorry. next question.

12:05 <lkcl__> i have two peripherals, XICS-ICP and XICS-ICS. both of them are wishbone

12:05 <lkcl__> i have two options to connecting them up:

12:06 <lkcl__> 1) create a nmigen wishbone arbiter, set the addresses there, basically "hooking" into the dcache bus coming from the CPU

12:06 <lkcl__> 2) DoSomeVoodooMagicWith litex

12:08 <lkcl__> for (2) i'm guessing i'd need to bring out both WB buses via core.py

12:08 <lkcl__> and add them to periphh_buses (which currently is [self.dbus, self.ibus])

12:09 <lkcl__> however wiring them up *as* peripherals - specifying the address that they're to be on? no clue

12:11 <lkcl__> soc/integration/soc.py adds them like this (as WB masters):

12:11 <lkcl__> self.bus.add_master(name="cpu_bus{}".format(n), master=cpu_bus)

12:11 <lkcl__> ah.

12:12 <lkcl__> so i'm not adding the XICS peripherals (which are slaves) to periph_buses, then :)

12:14 <daveshah> The liteeth integration might be a useful clue

12:14 <daveshah> https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1302-L1303

12:14 <tpb> Title: litex/soc.py at master · enjoy-digital/litex · GitHub (at github.com)

12:14 <daveshah> https://github.com/enjoy-digital/liteeth/blob/master/liteeth/mac/wishbone.py#L15-L47

12:14 <tpb> Title: liteeth/wishbone.py at master · enjoy-digital/liteeth · GitHub (at github.com)

12:14 <lkcl> ahh ;0

12:14 <lkcl> thank you

12:15 <lkcl> apologies, shift key is damaged, got jammed down there when typing a smiley

12:15 <daveshah> lol

12:15 <daveshah> This adds a sub-Wishbone-bus for accessing the Ethernet rx/tx buffers, into a region of main memory

12:16 <lkcl> it's got score-lines in it, almost worn completely the way through, from my nails (!)

12:16 <lkcl> ok excellent

12:16 <daveshah> XICS-ICP/XICS-ICS are devices, not initiators, right?

12:16 <lkcl> specifies the size... not cached...

12:16 <lkcl> yes, they're devices (wb slaves)

12:17 <lkcl> the processor will read/write to them to query the actual interrupt that occurred (and reset/acknowledge it)

12:17 <daveshah> Yep, makes sense

12:18 <lkcl> after receiving one single "global interrupt occurred" hardware flag being raised

12:18 <lkcl> it's a good system, basically identical to RISC-V PLIC

12:20 <lkcl> daveshah: so... SoCRegion will take the origin from the map (0xC0008000 or whatever), then self.bus.add_slave adds the peripheral at that memory location (with the size)?

12:21 <daveshah> yeah, that's how I understand it

12:21 <lkcl> ok great.

12:21 <lkcl> so this *might* be dead simple.

12:21 <lkcl> self.bus = wishbone.Interface()

12:22 <lkcl> that's what gets added from self.bus.add_slave(name=name, slave=ethmac.bus,

12:23 <lkcl> the rest of LiteEthMACWishbone is not needed, i have that via the externally-generated code (nmigen libresoc), all i need to do is create a map in core.py onto a litex wishbone.Interface() and that's identical to how the dbus / ibus works

12:24 <lkcl> ok, thank you, i have a way forward :)

12:31 <lkcl> daveshah: at some point it'd be nice to put some of NLnet's donations your way, you've saved me an awful lot of time.

12:35 <Felkin> Hello, guys! I'm looking for a little bit of advice. I've currently embarked upon a project of trying to get the PYNQ board running with litex.

12:37 <Felkin> I've asked florent about this a few months back, but had to then focus on something else so had to put the project on hold. Now I'm finally ready to get back to it and, well. It's proving challenging.

12:41 <Felkin> To summarize where I'm at: I know that the correct approach would be to generate zynq's processing system IP .xic file, use that in a similar fashion as the zybo_z7.py example in the litex-board repo, also prepare a platform board file with the pins outlined and go from there. The issue is that I'm having trouble wrapping my ahead around how

12:41 <Felkin> xilinx is handling these .xic files

12:43 <Felkin> If I was only trying to get a sort of 'pynq_processing_system7.xci' file, it seems doable, I've found these tucked away in the pynq image repo, but thing is, a pynq's selling point is the overlay system

12:45 <Felkin> What I think is interesting is being able to work on the design side in python with litex but then also interact with the designs using the overlay that xilinx designed. It'd be an interesting loop of everything sitting in the same python scripts for some rapid prototyping

12:47 <Felkin> Issue is, the overlay diagram is, well, huge and it's not clear to me at all if vivado is even generating a single .xci for this base overlay. It lists all these ips with their respective .xci's for each component of the overlay, but is there even a single 'final' .xci that it makes. Is it possibly the case that I should rather be looking for the

12:47 <Felkin> final verilog file it generates? I did find one that 'kind of' looks like what the full overlay is

20:40 <lkcl> daveshah: xics added (i had to fudge the size of the CSR memmap because microwatt drops the XICS memmap @ 0xc0004000 and 0xc0005000)

20:40 <lkcl> thank you for that

20:41 <lkcl> i even added the uart interrupt line... aand of course the litex uart doesn't support UART_REG_IER_RLSI as a way to enable interrupts, doh :)

20:42 <lkcl> so i can see XICS wishbone addresses wiggling on the vcd trace, but not the external interrupt line.

22:41 <Finde> I think that microwatt was using another open source uart 16550

23:00 <lkcl> Finde: yes, the opencores one.

23:01 <lkcl> issue is, right now, i'm looking to test the libresoc XICS controller (equivalent to RISC-V PLIC)

23:01 <lkcl> with as simple a test infrastructure as i can make