_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
<DerekKozel[m]> The GNU Radio blocks are achieving 7.22 Gbps throughput over Thunderbolt, same as the litepcie_util dma_test. Might improve that when this moves read/write to separate threads this weekend.
<DerekKozel[m]> _florent_: You suggested changing the pcie DMA buffering_depth to 8k last time we talked about throughput. What do you think about adding that parameter to add_pcie()?
<DerekKozel[m]> If thumbs up I can do that PR
Degi_ has joined #litex
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
<cr1901> _florent_: When you get the chance, could you run " python3 -m litex_boards.targets.1bitsquared_icebreaker --cpu-type=serv --build --flash" and report back w/ whether the SoC runs? I cannot get a working firmware, but the gateware seems fine
<cr1901> readelf -A build/1bitsquared_icebreaker/software/bios/bios.elf
<cr1901> Tag_RISCV_arch: "rv32i2p0"
<cr1901> This looks fine too
<cr1901> I can duplicated the SoC not working on both Linux and Windows. So I don't think it's a cosmic ray event
<mc6808> _florent_: I just bisected liteeth: 2b23788 works and 43a2ea8 fails with litescope -v ... . https://github.com/enjoy-digital/liteeth/commit/43a2ea811819c4fa07e9b5db996a58ae8bc5db5d
<mc6808> _florent_: I guess this is marginal timing with gigE on ECP5?
<mc6808> Warning: Max frequency for clock '$glbnet$etherbone_clk': 68.07 MHz (FAIL at 75.01 MHz)
<mc6808> Warning: Max frequency for clock '$glbnet$eth_clocks_rx$TRELLIS_IO_IN': 110.47 MHz (FAIL at 125.00 MHz)
<mc6808> Info: Max frequency for clock '$glbnet$init_clk': 362.32 MHz (PASS at 25.00 MHz)
<mc6808> Info: Max frequency for clock '$glbnet$clk100$TRELLIS_IO_IN': 410.00 MHz (PASS at 100.00 MHz)
<mc6808> Info: Max delay <async> -> <async> : 0.15 ns
<mc6808> Info: Max delay <async> -> posedge $glbnet$etherbone_clk : 3.79 ns
<mc6808> Info: Max delay <async> -> posedge $glbnet$init_clk : 3.20 ns
<mc6808> Info: Max delay posedge $glbnet$clk100$TRELLIS_IO_IN -> posedge $glbnet$etherbone_clk : 4.29 ns
<mc6808> Info: Max delay posedge $glbnet$clk100$TRELLIS_IO_IN -> posedge $glbnet$init_clk : 3.69 ns
<mc6808> Info: Max delay posedge $glbnet$eth_clocks_rx$TRELLIS_IO_IN -> <async> : 6.97 ns
<mc6808> Info: Max delay posedge $glbnet$eth_clocks_rx$TRELLIS_IO_IN -> posedge $glbnet$etherbone_clk : 1.29 ns
<mc6808> Info: Max delay posedge $glbnet$etherbone_clk -> <async> : 10.61 ns
<mc6808> Info: Max delay posedge $glbnet$etherbone_clk -> posedge $glbnet$eth_clocks_rx$TRELLIS_IO_IN: 2.94 ns
<mc6808> Info: Max delay posedge $glbnet$etherbone_clk -> posedge $glbnet$init_clk : 2.33 ns
<mc6808> Info: Max delay posedge $glbnet$init_clk -> <async> : 3.28 ns
<mc6808> Info: Max delay posedge $glbnet$init_clk -> posedge $glbnet$etherbone_clk : 1.68 ns
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
Guest78 has quit [Quit: Client closed]
tnt_ has joined #litex
shenki_ has joined #litex
peepsalot has quit [Remote host closed the connection]
peepsalot has joined #litex
vomoniyi[m] has quit [Ping timeout: 260 seconds]
tnt has quit [Ping timeout: 260 seconds]
shenki has quit [Ping timeout: 260 seconds]
willcode4[m] has quit [Ping timeout: 260 seconds]
vomoniyi[m] has joined #litex
willcode4[m] has joined #litex
<_florent_> DerekKozel[m]: We should indeed expose more parameters to add_pcie, happy to review/merge the PR if you look at it.
tnt_ is now known as tnt
<_florent_> cr1901: It's working here yes, here is the fpga bitstream + bios if you want to check your hardware with it: https://github.com/litex-hub/litex-boards/files/7379097/1bitsquared_icebreaker_fpga%2Bbios_2021_10_20.zip
<_florent_> mc6808: Thanks for looking at it, I opened https://github.com/enjoy-digital/liteeth/issues/86 for this, I'll look at this and will do tests on ECP5 and others FPGAs to see if it's ECP5 specific.
<_florent_> mntmn: For the framebuffer/color issue, you could eventually use the colorbars pattern to investigate more easily by replacing the framebuffer with something like this: https://github.com/litex-hub/litex-boards/blob/5190c9c869ad61c9940a8b8a766b6808382e934c/litex_boards/targets/sipeed_tang_nano_4k.py#L114-L115
ewen has joined #litex
<_florent_> DerekKozel[m], ilia__s: The OpenOCD modification discussed yesterday has been pushed to https://github.com/enjoy-digital/openocd
C-Man has quit [Ping timeout: 265 seconds]
<_florent_> I also created https://github.com/enjoy-digital/litex/wiki/FPGA-and-SPI-Flash-programmers to clarify installation of programmers
<ilia__s> _florent_: why should not this patch be contributed to openocd master?
<DerekKozel[m]> Thanks florent
<DerekKozel[m]> I really appreciate your time here. I'm collecting general notes and will find places for them in the wiki.
<DerekKozel[m]> Do you have any ICAP references or snippets for host to FPGA loading? I found the antmicro code and examples for loading from the softcore.
<_florent_> ilia__s: This would be done yes, I haven't spent the time yet to understand the OpenOCD upstream process, this was just the path of least resistance...
<_florent_> DerekKozel[m]: I haven't used ICAP for this yet but plan to do so soon, I was also going to look at antmicro's code
<DerekKozel[m]> Ok. not a priority, just a nice to have
ewen has quit [Ping timeout: 260 seconds]
futarisIRCcloud has joined #litex
<_florent_> futarisIRCcloud: Thanks for sharing, that's interesting. Since the Acorn has 4 GTP lanes and only one is used by PCIeLeech, it would also be possible to use one of the other lanes for the communication with the Host, like USB3.
<_florent_> This would be a nice usecase of the https://github.com/enjoy-digital/usb3_pipe or Luna, but there is still a bit of work to do to have something usable
C-Man has joined #litex
<cr1901> _florent_: Thank you for the code... your code does not work either. Hmmm, I have a theory... what revision icebreaker do you have?
<cr1901> Mine is v1.0b
<_florent_> v1.0e
<cr1901> I wonder if the SPI flash is different between v1.0b and e
<cr1901> and that they need different parameters
<cr1901> cc: esden is this possible?
<tnt> yes
<cr1901> I can't find a schematic of "e" to confirm
<cr1901> >if you used the wrong flash chip
<cr1901> Can you elaborate? :P
<tnt> There is a bunch of different variants of the windbond 25q128 depending on the letters after the part number.
<tnt> After power up, some have QE=1, some have QE=0. The litex spi flash thing doesn't do any init and so doesn't write the flash mode register to properly set it, it assumes it's all ready. Which depending on the defaults, it might not be.
<cr1901> Shit, I'd rather just have 1-bit width mode than go through this
<cr1901> tnt: Thank you for your patch of course :)
<tnt> I'm assuming your part number ends in 'IM' on the flash ? and not 'IQ' ?
* cr1901 gets a flashlight
<tnt> 2-bit width mode should work too without that bit set. (assuming the litex core suports that).
<tnt> You could also add support for init sequence to the litex core :D
<cr1901> 25q128jvsm
<tnt> Yup.
<tnt> Note that I think the description of the patch is incorrect. There is a non-volatile version of that bit that's apparently OTP writable.
<cr1901> >You could also add support for init sequence to the litex core :D
<cr1901> That would be more ideal I think
<cr1901> with that being said, I just wanted something that works b/c it's been a while since I've followed litex
<cr1901> I had this problem w/ TinyFPGA Bx/B2 a long time ago... I hardcoded the wrong SPI flash parameters and I didn't understand the problem until Luke pointed it out. Months later.
<mntmn> if i use platform.add_verilog_include_path and platform.add_source_dir in a target, do i have to anything else with those files to get them to be picked up during a linux-on-litex-vexriscv build?
<mntmn> ah i see that the include paths are expected to be relative to linux-on-litex-vexriscv
<mntmn> not the target...
<cr1901> gatecat: If I get an error like "ERROR: Bel 'X23/Y0/io0' of type 'SB_IO' is not valid for cell 'SB_IO_1' of type 'SB_IO'
<cr1901> 0 warnings, 1 error", is there a verbose mode that'll tell me why without recompiling to enable the debug output?
<cr1901> Nothing looks odd to me viewing it in the GUI, but I'm not very familiar w/ ice40 internals
<mntmn> yeah, that made it work
<gatecat> cr1901: there's no debug at all for validity checking failures atm :/
<gatecat> it's probably to do with which IO tiles share a clock between two pins
<cr1901> Ahhh hmmm. Guess I'm not getting around looking into this deeply lol
<tnt> Check what's at X23/Y0/io1
<cr1901> It's an I/O port
<tnt> yeah ... the `io1` was a big clue.
<tnt> I meant what you connected there.
<cr1901> Oh, I already blew away those files... hang on...
<tnt> up5k ?
<cr1901> yes
<tnt> So that's miso and mosi
<tnt> weird, I'd expect those to have compatible IO registers.
<cr1901> I changed "self.add_spi_flash(mode="1x", module=W25Q128JV(Codes.READ_1_1_4), with_master=False)" to
<cr1901> "self.add_spi_flash(mode="1x", module=W25Q128JV(Codes.READ_1_1_1), with_master=False)" just to see what would happen
<tnt> Not sure what's that supposed to do TBH.
<tnt> But I'd be interested to see the generated verilog.
<cr1901> line 9789 for the offending I/O connection in json
<cr1901> tnt: Btw, how'd you know it was MOSI/MISO so fast w/o a JSON? :o
<tnt> Ah yeah ... it's an invalid clock config technically.
<tnt> Because from the IO site I could get the pad number for the up5k and those were the flash is.
<cr1901> ahhh, fair
<tnt> So technicaly SB_IO_1 is configured for registerd input. That's what the "PIN_MODE" sets it to.
<tnt> Even though the input path is not actually used.
<tnt> But if it's configured for registered input, then the INPUT_CLK must match ... and here obviously it doesn't since INPUT_CLK is not connected.
<tnt> if input isn't used, pin_type should be set to unregistered input mode.
<cr1901> the INPUT_CLK must match _what_?
<cr1901> Just... being connected is a "match"?
<tnt> must match what's in the other SB_IO that's in the same IO tile.
<tnt> which is SB_IO_2 here.
<tnt> There are two SB_IO per IO tile. And they must share clock_enable / input_clk / output_clk.
<cr1901> Ahhh okay, and in this case
<cr1901> INPUT_CLK is used on one, OUTPUT_CLK is used on the other
<tnt> yes.
<cr1901> but not both
<cr1901> And a way around this is to set the PIN_TYPE on one of the I/O pins to shut up the validity checker?
<tnt> And nextpnr looks at the PIN_TYPE to know if the register is used at all.
<cr1901> set the PIN_TYPE appropriately*
<tnt> if it's not used, then it will ignore mismatched clock connection and just use the clock of the one that's effectively enabled.
<tnt> yes, setting pin_type to 21 should do it.
<cr1901> >just use the clock of the one that's effectively enabled.
<cr1901> "effectively" enabled?
<cr1901> Anyways I get it now
<cr1901> LiteX generates the SB_IOs, so I have to look there
<tnt> yeah, I mean image you feed INPUT_CLK(clk1) to one SB_IO and INPUT_CLK(clk2) to the other SB_IO. But then you have the pin_type set to unregistered input for the first one, it will use clk2 automatically and ignore the ck1 connection.
<tnt> (IIRC .. I wrote that a long time ago)
<cr1901> ahhh neat
<cr1901> tnt: Thanks for the explanation, I haven't really looked at ice40 internals. They're... different compared to ECP5/MachXO2
<tnt> I'm re-reading that code and I'm wondering if I didn't screw up there ... I see the part that ignores the conflict if the register isn't needed. But I'm not sure where it picks the "right" net. It might just pick randomly :/
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<tnt> ok, nm what I said above. It won't pick automatically. If it's not used, it needs to either match or be non-connected.
<mntmn> _florent_: i'm trying to understand the usb_ohci host. if i understand correctly the actual OHCI impl is included as verilog from something generated with spinalHDL? (spinal.lib.com.usb.ohci.UsbOhciWishbone)
FabM has quit [Ping timeout: 252 seconds]
<mntmn> is there an example for using Wishbone2AXILite and friends to integrate an AXI4Lite peripheral in linux-on-litex-vexriscv?
<mntmn> hmm there's also add_adapter in soc.py
<mntmn> ok, this seems to work: usb_wb = self.bus.add_adapter("usb_axi_wb", usb_axi)
<mntmn> but how do i set the address for the converted axi->wb peripheral?
FabM has joined #litex
FabM has quit [Changing host]
FabM has joined #litex
<mntmn> is there a multi-bit version of SDRTristate?
<mntmn> i mean, i have a 8 bit bidi bus with 1 dir bit
<mntmn> ah, migen Instance("Tristate") can do this
<mntmn> i'm trying to connect an Instance()'s axi4lite signals directly to an AXILiteInterface's axi.aw.*, w.*, r.* and so on signals... this fails in synthesis because there are registers missing in between, i think
<mntmn> the axi signals on the Instance() are all wires
<mntmn> i'm getting a bunch of errors like > procedural assignment to a non-register main_r_payload_data is not permitted
<mntmn> ok, possibly i had to specify "s2m" instead of "m2s" for the adapter
<mntmn> now i get > module 'Tristate' not found
<mntmn> ok, solved this too
FabM has quit [Quit: Leaving]
mc6808 has quit [Quit: Client closed]
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
<_florent_> mntmn: Sorry I was away, good if you managed to do what you wanted
<mntmn> _florent_: no problem! i came quite far. currently my problem is that the AXI4Lite interface of the core_usb_host wants to be the same 60mhz input clock coming in from the ULPI PHY, but my sys clk is 100MHz. i'm not sure if i have to do anything special to allow this clock crossing (i.e. 100mhz wishbone <-> 60mhz axi4lite)
<mntmn> _florent_: when i was supplying the core_usb_host with the sysclk, i was able to talk to it (via wishbone->axi4lite). now i connected the ulpi clock instead and it doesn't reply i think (all 0xff). it could also be that the ULPI clock is not running. i would need litescope or some counter to check this, i guess.
<mntmn> _florent_: in case you're curious, this is how my target looks like atm https://gist.github.com/mntmn/44c3396eb4935e36d91eac41e7bd02bf
<_florent_> mntmn: You could probably use the AXILiteClockDomainCrossing for this
<mntmn> _florent_: i see
<_florent_> the slave would be the bus connected to the usb core (running at 60MHz) and master the bus that will be connected to the SoC
<mntmn> _florent_: the master is wishbone in this case though, or created by add_adapter?
<_florent_> BTW, you can directly add an AXILite peripheral with add_slave
<_florent_> LiteX will automatically insert the adapter if required
<mntmn> oh!
<_florent_> (ie converting to Wishbone for a SoC with a Wishbone bus)
<_florent_> it can also automatically adapt the data-width
<mntmn> but how would i insert the AXILiteClockDomainCrossing in this case?
<mntmn> i mean because AXILiteClockDomainCrossing does not wrap a slave, but wants master and slave as arguments... it looks to me like they should not already be connected
<_florent_> Something like this:
<tpb> Title: Snippet | IRCCloud (at www.irccloud.com)
<_florent_> then just use usb_axi_usb as you were doing with usb_axi
<mntmn> _florent_: ohh, i see. thanks a lot
<_florent_> and just remove the usb_wb
<mntmn> yep
<nickoe> Hello guys and girls, it has been a long time I played around with litex now. Any news or changes I shoudl be awere of if I syncanew?
<_florent_> Hi nickoe, you can find the list of the important changes here: https://github.com/enjoy-digital/litex/blob/master/CHANGES
<_florent_> otherwise, a recent change is the switch to picolibc, you can look at https://github.com/enjoy-digital/litex/issues/1045 if issues related to this
<nickoe> Ok, thank you.
* nickoe also needs to check if I am involved in any open issues
<nickoe> _florent_: I remember I had in endianness issue with litex sim and som sdram, did you solve that somehow?
<nickoe> mm, I can't find it in my notes.. I guess I may stuble on it later if it is still a thing
<nickoe> ohh, I found it, it was on th elitedram repo https://github.com/enjoy-digital/litedram/issues/251
<nickoe> _florent_: Is there something I can do to rectivy this mismatch?
<nickoe> *rectify
toshywoshy has joined #litex
<nickoe> LiteX support for programming the flash via JTAG?
<nickoe> Reading XAPP586 it appears that ISE/IMPACT flashes a custom bitstream to the FPGA to route through the SPI mode from the JTAG to sprogram it?
<nickoe> It does appear as if lxterm did support programming the flash, but it was removed in this commit: https://github.com/enjoy-digital/litex/commit/41964f945cee71337e8e0998d597086b2ef94f77 How does one go about to program the flash now?
<nickoe> I am slightly confused by this.
<tpb> Title: 'Re: [OpenOCD-devel] artix-7 + spi flash programming' - MARC (at marc.info)
<ilia__s> sure litex does support flashing spi memories through jtag in various ways, depends on the fpga vendor and accordingly available programmers
mc6808 has joined #litex
<ilia__s> this is for instance how it is handled through vivado: https://github.com/enjoy-digital/litex/blob/master/litex/build/xilinx/programmer.py#L157
<ilia__s> etc