<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()?
<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
<_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.
<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
<_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.
<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
<_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.
<_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