<zyp>
one thing that I feel is not captured very well by the generated functions are arrays of registers, or arrays of groups of registers even
tpb has joined #litex
<zyp>
e.g. I'm currently working on a usb core, which will have a couple of registers per endpoint and a number of endpoints
<zyp>
I also already have a software stack supporting a couple of different usb cores in normal mcus which I'll be porting to this, so I already have a notion of how I want it to look from a software perspective
<zyp>
and since the number of endpoints will be configurable, I'd prefer to leave the register addresses for those endpoints reserved rather than having the software adapt to it
<zyp>
it's conceivable that I might want to instance more than one instance in the same SoC, with differing numbers of endpoints, and I'd like them to still be supported by the same driver
scanakci has joined #litex
_whitelogger has joined #litex
CarlFK has joined #litex
<Skip>
@zyp: is your USB core a USB device or a USB host? I'm interested in adding USB host support for the Pano platform.
<tpb>
Title: GitHub - ultraembedded/core_usb_host: Basic USB 1.1 Host Controller for small FPGAs (at github.com)
rohitksingh has quit [Ping timeout: 240 seconds]
<xobs>
@zyp I'm not aware of any way to do that currently, but I'd like to see it added. The easiest way to do it, architecturally, would be to add a special kind of CSR that has a width of 0 and no data backing.
<xobs>
Actually, I wonder if you couldn't just append a series of CSRs, since those are all the csr_buswidth and don't appear to have their length checked. So for each gap, you add one CSR with no actual backing to it.
benh has joined #litex
<john_k[m]>
Skip: I’d love to see USB host on the PanoG2! I did some of the initial print work but could never get DDR or Ethernet to work and it went to the shelf - I’ll have to pick it up again soon after I’m done with some icebreaker and ULX3S projects
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined #litex
Degi has quit [Ping timeout: 265 seconds]
Degi has joined #litex
proteusguy has quit [Ping timeout: 258 seconds]
proteusguy has joined #litex
HoloIRCUser has joined #litex
HoloIRCUser2 has joined #litex
HoloIRCUser1 has quit [Ping timeout: 260 seconds]
HoloIRCUser has quit [Ping timeout: 256 seconds]
<benh>
_florent_: hola
<benh>
I email-bombed you today about microwatt :-)
gregdavill has joined #litex
<_florent_>
Hi benh!
<_florent_>
i just saw the emails :)
<_florent_>
the Microwatt support in the BIOS has not been tested (i wanted to be able to simulate the SoC and test it in simulation, but haven't finish testing synthesis with GHDL), so there are probably a few issues software in it as you spot
<_florent_>
but if you want to help on the software, i can make sure the LiteX SoC is bulding fine with Microwatt on Arty
<benh>
_florent_: ok cool, yes I can help with the software
<benh>
if you can help me make it build with arty on vivado using Anton's current master
<benh>
see my emails for *some* of the issues I already found !
<_florent_>
benh: thanks, i'm going to look at that
Skip has quit [Remote host closed the connection]
<benh>
_florent_: excellent, hopefully once Paul is done getting Linux up we'll have that in LiteX too :)
<benh>
_florent_: as for standalone microwatt with litedram, I'm hacking my generator so it can either let litedram init itself with its own built-in core, which at least still works, or do the native inits which is currently broken
<benh>
_florent_: and I'll default to using vexriscv... talking of which, I noticed there are several variants of vexriscv now, do you reckon the "lite" one is enough to run the sdram init BIOS ?
<_florent_>
benh: that would be great to integrate a Linux capable Microwatt in LiteX, we are already doing efforts on that with the other CPUs (VexRisvc, Rocket are already able to boot Linux on hardware, BlackParrot is able to boot it in simulation).
<_florent_>
benh: this is also a good way to improve the infrastructure to be able to integrate various CPUs
<_florent_>
benh: for LiteDRAM standalone, the Lite variant of VexRiscv is enough yes, SERV has also been integrated recently and would be a good candidate for this: https://github.com/olofk/serv
<tpb>
Title: GitHub - olofk/serv: SERV - The SErial RISC-V CPU (at github.com)
<benh>
_florent_: yup, though I do like doing our own self inits :0
<benh>
anyway, we'll see, let's fix LiteX+MW up first
<benh>
then get back to these things
<benh>
I also sent some comments to whoever was trying to upstream LiteX drivers, but I got bounces so I don't know if they went through
<benh>
not too fan of how the CSRs work, we should probably fix that in HW
<benh>
it's silly to have to access a 32-bit CSR via 4x32-bit access that carry 8 bits at a time
<benh>
at the *very least* those should be 8-bit accesses so there's no weird endian issue and one can use the standard accessors
<benh>
but it wouldn't be hard for the HW bridge to generate 4-beat accesses on the CSR bus so they appear as atomic 32-bit ops instead, which would speed things up as well
<_florent_>
yes sure, one thing at a time, let's focus on basic MW support with LiteX for now
HoloIRCUser has joined #litex
HoloIRCUser2 has quit [Read error: Connection reset by peer]
<_florent_>
for the CSRs, the data_width is configurable. we were using a 8-bit CSR bus previously, but we can support 8-bit, 32-bit and we will probably use 32-bit as default soon, but this should be discussed yes
<benh>
_florent_: I can understand wanting a smaller one to save space, but it would be easy in that case to have the bus<->csr interface do multi-beat access so it still appears accessible as 32-bit
<benh>
_florent_: however ever if we decide against this, the accesses in SW should then be 8-bit accesses, not 32-bit access with weird endian games :)
CarlFK has quit [Quit: Leaving.]
<_florent_>
benh: from the recent test bunnie and xobs did, using a 32-bit CSR bus vs a 8-bit CSR one does not seem to degrade resource usage/timing, so that's why we are considering switching to 32-bit as default. The CSR bus is meant to be something really simple, so not sure we should add multi-beat support for it, also if this could simplify the Linux drivers, we could consider a that Linux SoC have a CSR bus of 32-bit and
<_florent_>
avoid 8-bit support.
<xobs>
_florent_: yeah, it ended up as a net performance gain due to 32-bit accesses being 4x faster.
<benh>
_florent_: I'm ok with avoiding 8-bit
<benh>
(in linux)
<benh>
_florent_: that said, as I said, if we decide to keep it, at the very least, the linux code should do actual 8 bit accesses to addr+3 so that it works endian neutral and avoid the __raw stuff that lacks all the necessary memory barriers
<bunnie>
it also seemed to increase our timing slack because reducing the number of registers also reduces the fan-in of the register decoders and thus shortens a critical path on the address-to-data fetch decoders
<benh>
_florent_: anyways, no biggie now :-) Ping me when you can show me how to build an Arty LiteX MW SoC ... I've failed with vivado as you see in my emails, once that's sorted I'll get SW going. As for Linux, Paulus is working on it, we have a basic MMU, he has hcked it to the point where it crashes somewhere afer initializing timers, which is good progress :)
<benh>
bunnie: interesting, I didn't think of that aspect
<benh>
_florent_: at some point I'd really like to tackle pipeline wishbone to litedram... maybe once we can sim if ever
<bunnie>
it only manifests in designs with lots of CSRs, when you e.g. overflow the granurality of a 6-LUT to decode the address and have to add another stage to the pipe (at least on the 7-series)
<daveshah>
I remember going through all these kind of crashes when making Antmicro's supposed vexriscv linux port _actually_ work
<benh>
daveshah: most probably :-) though not in Linux, more likely bugs in microwatt :)
<_florent_>
xobs, bunnie: interesting, we should indeed probably switch to 32-bit as default, 8-bit was an assumption that it would improve resource usage/timing but it does not seem to be the case
<_florent_>
benh: i just fixed the MW build and i've been able to generate a bitstream for the Arty
<_florent_>
benh: i haven't tested your crt0.S changes for now, do you want to look at this?
<benh>
_florent_: sure
<benh>
_florent_: so I update from git and run arty.py as I was doing before or did I miss some magic ?
<_florent_>
benh: yes update from git, make sure the pythondata for microwatt is installed (if not it will complain and provide you the pip command to install it) and then just go to litex/boards/targets and do ./arty --cpu-type=microwatt
<benh>
yeah it's installed, I actually updated the files in there with a newer version
<benh>
_florent_: vivado fails miserably, similar log to what I sent by email as fat as I can see
<benh>
ah no
<benh>
ignore me
<benh>
my fualt
<benh>
newer microwatt has new files I need t oadd
<_florent_>
benh: for pipeline wishbone with Microwatt, we are working on similar things with VexRiscv SMP that has direct access to LiteDRAM native ports
<benh>
_florent_: ok, we will also need to figure out how to do cache coherency vs. DMA ... powerpc64 really wants that
<benh>
_florent_: it's a bit awkward that the list of source files resides in litex/soc/cores/cpu/core.py, shouldn't it be in the pythondata somewhat ? otherwise when I import a new microwatt that has different source files I also need to update litex
<_florent_>
benh: the pythondata are external sources, the files in LiteX are related to the integration. You are expect to have version that match, but it's also now possible to just plug your custom CPU in LiteX
<_florent_>
that's still a bit experimental, but this allows all the CPU files to be located in an external repository
<benh>
ok
CarlFK has joined #litex
<benh>
_florent_: I'm getting a bitfile. Loading top.bit and I see no movement on serial but at that point it could be normal, I'll investigate
<benh>
_florent_: I assume serial is the arty's built-in one via the same USB as jtag ?
<benh>
_florent_: defaulting at 115200 8n1 ?
<_florent_>
benh: yes the UART is the second port of the FTDI and 115200 8n1
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Ping timeout: 265 seconds]
<benh>
_florent_: I notice a lot of these (building a LiteX Arty + VexRiscV for testing something)
<benh>
WARNING: [DRC REQP-1580] Phase alignment: Unsupported clocking topology used for ISERDESE2 ISERDESE2_5. This can result in corrupted data. The ISERDESE2_5/OCLK / ISERDESE2_5/CLKDIV pins should be driven by the same source through the same buffer type or by a BUFIO / BUFR combination in order to have a proper phase relationship and the ISERDESE2_5/CLK pin should be driven similarly to the ISERDESE2_5/OCLK pin. Please refer to the Select I/O User Guide for
<benh>
supported clocking topologies of the chosen INTERFACE_TYPE mode.
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Ping timeout: 240 seconds]
<benh>
_florent_: so if I make the bios just write "ABCDEFGH" to 0xc0001800 (should be UART) in a loop, I don't get anything on the UART (I was trying to check which byte lane would land on the CSR to make sure it was as expected)
<benh>
_florent_: so I *suspect* at this point we aren't getting instructions properly
<benh>
_florent_: or maybe something with reset... what would be handy would be to get the jtag debug module going, I'll try to figure out a way by hacking the wrapper to hook it up
<shuffle2>
is there a way to tell diamond "USE PRIMARY NET" for a clock(via litex/migen)? or do you just rely on top ranked clocks using primary nets?
<daveshah>
I suspect it just relies on promotion. ime Diamond tends to grumble if a clock doesn't end up using dedicated resources so it should be pretty safe
<benh>
_florent_: oh btw... did you see this in my emails
<shuffle2>
currently i'm seeing "Found syn_preserve on register arp_table_cached_timer_count[0] which prevents the register from being packed into DSP"(across a few nets), which then fail to meet timing
<daveshah>
That doesn't sound related to clock promotion?
<shuffle2>
which seems odd, as nothing in the path seems to actually be using syn_preserve...
<shuffle2>
yea, sorry, different topic
<daveshah>
Sounds like synplify is inserting it automatically tbh
<daveshah>
(or LSE, whatever is being used)
<benh>
_florent_: I see there's a converter when I look at the verilog between the 64-bit microwatt bus and the 32-bit SoC bus, so things will be slow ... ok
<benh>
it's using sel [7:0] instead of [3:0] ... is that normal ? I'm not too familiar with verilog when it comes to assigning signals of different size...
<daveshah>
It will be truncated
<daveshah>
Verilog isn't strongly typed like VHDL
<benh>
daveshah: yeah but truncated how ? :-)
<daveshah>
bits [3:0] will be used
<benh>
if foo[3:0] gets assigned to bar[7:0] ? ah ok
<daveshah>
[7:4] will be thrown away
<benh>
so that should work then
<daveshah>
yeah
<benh>
I'll have to dig more
<benh>
Anybody ever tried to sim LiteX using vivado sim ?
<benh>
the verilog/vhdl mix does indeed make debugging ... somewhat hard
<benh>
:-)
<daveshah>
If you want to keep using Verilator, you can use ghdl+yosys to "synthesis" the VHDL to verilog
<_florent_>
benh: nothing to do to initialize the UART, you can just write data to the rxtx CSR
<benh>
_florent_: yeah ok, so I shoved my jtag debug module inside the wrapper
<benh>
_florent_: the core is somewhat moving but doing weird stuff
<benh>
_florent_: I'll add some debug regs to capture the instructions executed
<_florent_>
benh: ok, BTW for the wishbone bus: LiteX uses a 32-bit wishbone bus for now and the 64-bit bus from Microwatt is automatically converted to 32-bit when the CPU is added
<_florent_>
When building, you should see: INFO:SoCBusHandler:cpu_bus0 Bus converted from 64-bit to 32-bit.
<benh>
_florent_: I saw the converter in the verilog yes
<benh>
I have 0 experience with yosys etc... so I'll continue debugging using my jtag for now but feel free to beat me :)
<benh>
_florent_: I'm struggling a bit with the whole pythondata business :-)
<benh>
so if I change microwatt, I modify the pythondata but I then need to "install" the changes right ?
<benh>
(it doesn't seem to pick them up otherwise)
<_florent_>
not sure you need to reinstall it, i'm going to check
<benh>
now, doing python setup.py install --user works for a bit then fails with errors related to unicode codec that I am not sure I understand
<benh>
allright, it seems to have done the install before those errors happened so the files in .local are now updated, let's try again
<_florent_>
benh: i just tried corrupting a MW file and run a synthesis: it failed.
<benh>
_florent_: I don't know then ... I can tell you here it wouldn't get the updated files from where I did the original litex_setup.py
<_florent_>
benh: when installed with litex_setup.py, it uses python3 setup.py develop, so you can do the modification in the cloned repositories
<benh>
_florent_: I had to go modify .local/lib/site... stuff
<benh>
hrm... I must have done something wrong
<benh>
I don't know much of that python install stuff
<benh>
I find it just makes things horribly confusing unless you're a python expert :-)
<_florent_>
benh: we'll have to improve that then. We were using git submodules before and doing a --recursive clone, but it made LiteX pretty big due to the large number of CPU now supported, with the switch to pythondata, you'll be able to do a minimal LiteX install and just install the data for the CPU you are going to use
<benh>
_florent_: ok so instructions are coming in in the wrong order and addresses look odd as well
<benh>
_florent_: minus my debug stuff being a bit flawky :-)
<_florent_>
benh: wrong order = endianness issue on the data bus? or issue on the address bus?
<benh>
looks like address bus, maybe the converter
<benh>
it's a bit odd, see privmsg
<benh>
that "latch last insn executed" might be a tad confusing, I'll add more debug to also catch what's coming out of icache for NIA
<benh>
to be sure
<_florent_>
benh: do you want i prepare a design for the Arty (IIRC that's the board you are using) with LiteScope on the Microwatt interface and replace the ROM with a SRAM you could reload easily? This would give you a lot more visibility
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
<benh>
_florent_: ROM vs. SRAM is probably not strictly necessary but sure
<benh>
how easy is litescope to use ? :-)
<_florent_>
it will be easy; just do litex_server --udp --udp-ip=ip_address and use the scripts i will prepare
<_florent_>
will 192.168.1.50 work on your network? (i would also add a parameter to allow you to easily change the ip address)
<benh>
a parameter would be good, I have a funky network... also will have to wait til I'm back home, no network cables here :)
<_florent_>
also, if you just want to see how the CPU starts, no need to use the UART, so i could just use LiteScope over UART?
<_florent_>
would it be fine?
<shuffle2>
in my design, i have clk100 which is only used as input for pll, which outputs 125mhz used for sys_clk. there are also some other 125mhz clocks active (for io)
<shuffle2>
any idea why then, diamond would complain about paths to/from sys_clk, for 'Preference: FREQUENCY NET "clk100_c" 100.000000 MHz' (there is nothing in the path actually using clk100, and in fact clk100_c isn't used for _anything_)
<benh>
_florent_: yes
<benh>
_florent_: so unless there's a problem with my jtag debug module (it works in sim though... stepping through the same code)
<benh>
_florent_: it appears that I'm getting the right instructions in a weird order and at weird addresses
<_florent_>
benh: ok, i'm preparing a design
<benh>
_florent_: from cpu reset, it looks as follow (address of the instructions I'm getting instead of 0,4,8,c,...)
<benh>
4,0,4,8,c,8,c,10
<benh>
so there's a pattern of some sort...
<_florent_>
interesting
<benh>
I wonder if something's wrong with the 32-64 bit converter
<benh>
how well is that tested ? :-)
<benh>
unless there's something odd with how microwatt does it's wishbone data layout, I'll double check things later
<benh>
or a combo of both rather
<daveshah>
Microwatt is LE right?
<daveshah>
I imagine this has all been tested with rocket before
<_florent_>
yes this has been tested with Rocket
<benh>
hrm... the icache stores wb-size (64-bit) quantities
<benh>
and wb-data goes straight into the cache bran
<benh>
bram
<benh>
when we read from it, we use bit 2 of the address
<benh>
return data(31+word*32 downto word*32);
<benh>
so address 0 should be wb_dat(31...0) and address 4 should be wb_dat(63...32)
<benh>
which is correct for little endian
<benh>
_florent_: in core.py you instanciate the Wishbone interfaces with adr_width=28, why is that ?
<benh>
_florent_: the core emits 32, though 3 aren't used, so it should be 29 no ?
<benh>
_florent_: also your wrapper outputs 31 as well, isn't the cropping incorrect in that case ?
<benh>
cropping the high bits instead of low bits ?
<benh>
_florent_: won't that set the top bits to 0 ? or am I missing something ? Not familiar with migen...
<benh>
_florent_: I'm changing instead the wrapper to output a 29 bits bus and instanciate 29 bits WB in core.py so no Cat is needed
<benh>
lets see what happens
<_florent_>
the wishbone in LiteX is aligned on words, not bytes
<benh>
we should probably remove the bottom bits of address in our wishbone types anyway
<benh>
_florent_: and addr_width is thus the number of words ?
<_florent_>
benh: yes
<benh>
_florent_: word as in data_width or 32-bit ?
<_florent_>
the data_width
<benh>
_florent_: if data_width then it should be 29 bits right ?
<benh>
_florent_: ie, microwatt emits 29 useful bits and 000 at the bottom
<_florent_>
yes this seem fine
<benh>
_florent_: so I'm changing adr_width to 29
<benh>
and I'm making the wrapper output 29 bits too (so I know exactly which bits I'm bringing up :-)
<benh>
we can "cleanup" later, let's see if that helps
<benh>
yes, it does
<benh>
I can see my crap in the UART now
<benh>
let's remove my debug and see if I can get the rest of the message
<benh>
_florent_: when using my jtag debug thingy there's still an odd off-by-1
<benh>
_florent_: it looks like I execute instructions 4,8,c ... instead of 0,4,8,...
<benh>
ie, at address 0 I excecute addr 4, at address 4, I execute addr 8 etc..
<benh>
I *think*
<benh>
again, it could be something odd with mu hacked up debug instruction capture (though it does output the right thing in ghdl sim)
CarlFK has quit [Quit: Leaving.]
<benh>
_florent_: it's up and running :-)
<_florent_>
Great!
<benh>
SDRAM now under hardware control
<benh>
Memtest OK
<benh>
Memspeed Writes: 129Mbps Reads: 215Mbps
<benh>
could be better with a 64-bit pipelined wishbone :)
<benh>
(also we have improvements to do on the core side too to better pipeline stores etc... )
<_florent_>
it will be easier to improve now it does something :), congrats
<benh>
_florent_: right. I need to fix a few more things to future proof it (the right IO instructions for examples, you shouldn't just do load-stores to CSRs)
<benh>
_florent_: I'll send you patches but probably not tonight, it's getting close to bed time :)
<tpb>
Title: GitHub - enjoy-digital/microwatt_test: MicroWatt test with LiteX (at github.com)
<benh>
_florent_: thanks
<benh>
_florent_: I might use it to scope some of my debug signals, something's odd there :-)
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
<somlo>
_florent_: I noticed three untracked (by git) files showing up under `litex/soc/software`: `bios/boot-helper.S`, `libbase/crt0-crt.S`, and `libbase/crt0-xip.S`
<somlo>
should those be added to .gitignore maybe ?
<somlo>
what I mean is, they show up each time I run a build (for litex with rocket, in my particular case)
CarlFK has joined #litex
<_florent_>
somlo: yes it's copied from the CPU directory, we could add them to the .gitignore or find a way to avoid this copy.
<somlo>
and I'm thinking they either should go somewhere under `soc_basesoc_<board>/software`, or be in .gitignore so we don't end up accidentally committing them
<_florent_>
somlo: putting them in soc_basesoc_<board>/software would be fine yes
<_florent_>
shuffle2: for you case, maybe diamond tries to keep a phase relationship between the input clock of the pll and the output by default
<tpb>
Title: software/*/Makefile: no need to copy .S files from CPU directory by gsomlo · Pull Request #496 · enjoy-digital/litex · GitHub (at github.com)
<somlo>
turns out $(assemble) works without having to copy things over
<_florent_>
somlo: ok thanks, that's better then
Skip has joined #litex
gregdavill has quit [Quit: Leaving]
<zyp>
Skip, at the moment I'm focussing on FS device with plans to add HS later when I've got FS working reliably, but it could also be interesting to do host at some point
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<Finde>
benh: is there somewhere to follow microwatt development other than just the github issues?
futarisIRCcloud has joined #litex
<dkozel>
_florent_: managed to snag those CEL-215 boards at a low price. What do you think about the possibility of making it work with the USB PIPE interface? or do you know of a Thunderbolt M.2 interface that would work with LitePCIe?
<daveshah>
Not m.2 (but passive adapters to PCIe are available, I think SQRL even make one), I plan to try a Sonnet eGFX box with litepcie soon
<daveshah>
I already have checked that the Xilinx bitstream preloaded to the card enumerates (that is an Alveo card that come with a pcie "shell" thingy)
<daveshah>
as litepcie uses the same primitives I imagine it will work fine too
<dkozel>
daveshah: cool. That new card of yours is really shiny
<daveshah>
it sure is :p
<dkozel>
Are there any low hanging tasks to improve the support for Artix 7s in nextpnr? One of my stretch goals is to be able to partially reconfig DSP blocks within these boards, so the PCIe interface isn't taken down.
<daveshah>
Testing is probably the most important thing tbh
<daveshah>
If you want PCIe, you will need to add transceiver and PCIe hard IP support to prjxray
<daveshah>
then the nextpnr side shouldn't be too hard
<dkozel>
Hmm. happy to help there as I can
<daveshah>
Cool! The first thing would probably just be making sure that a simple demo works with nextpnr, prjxray and that card
<dkozel>
any reference to start with? I'm eager to learn but rapidly digging out of my depth
<daveshah>
Personally the next few weeks are going to be implementing the RippleFPGA routeability driven placer and continuing to improve router2, to make nextpnr a more viable option in terms of runtime for bigger xc7/ultrascale designs. Then I am happy to go back to improve some Artix-7 stuff if you need.
<dkozel>
Ok. I'll see what I can get to in that time. I have some work left on the GNU Radio module for wrapping LitePCIe and LiteX.
<daveshah>
The other good test is to make sure that the design works in Yosys+Vivado (this is an option in LiteX iirc) before moving to look at nextpnr/prjxray
<dkozel>
hmm!
<dkozel>
I have a working LiteX+Vivado design, but presumably you mean a simpler test design without the PCIe
<daveshah>
Simple designs should hopefully work OK, but noone has tested litepcie with the Yosys+Vivado flow iirc
<dkozel>
Happy to try it
HoloIRCUser1 has joined #litex
<daveshah>
I can't remember the exact way to enable it, but it is basically a case of setting synth_mode to yosys in the litex build options
HoloIRCUser has quit [Ping timeout: 258 seconds]
<_florent_>
dkozel: good for the CLE-215, it should be possible to use the USB3 PIPE with it yes, but there are still some work to do on the USB3 Core to have something really usable. Kate Temkin will probably work on a new USB3 core to replace the Daisho one, so there should be interesting things coming in the next months.
<dkozel>
Cool. I'll backburner a variant of the PCIeish for m.2.
darren099 has quit [Read error: Connection reset by peer]
darren099 has joined #litex
<_florent_>
daveshah: the PCIe hard block on Ultrascale(+) is a bit different than the one 7-Series, it has already been ported to LitePCIe and validated on KCU105: https://github.com/enjoy-digital/litepcie/blob/master/examples/kcu105.py, but it's still a bit experimental and has been only been tested with PCIe Gen2 X4. I plan to improve performance in the next weeks/months.
<daveshah>
Yep, I saw it needed tweaking to support UltraScale+ (at least Virtex U+) instead of UltraScale but I don't have time for that atm
mattytrentini has quit [Remote host closed the connection]
FFY00 has quit [Read error: Connection reset by peer]