<Hammdist>
anyone know how to instantiate just the litex uart so I can include that as a module in my design? I don't want to generate a full SoC, but just the uart
Degi_ has joined #litex
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
<_florent_>
zyp: that would be great!
<_florent_>
Otherwise, I'm trying to allocate some time to write doc, that's still parse but should improve progressively.
<_florent_>
By collecting the different supports questions/answers (emails/github issues), it should already be possible to improve the doc without too much efforts. Then I should probably really block like some time in my agenda to write doc (sadly there are generally always other priorities...)
<swetland>
I'm happy to do some review/feedback on doc stuff if that's useful (also I'll try to take some notes as I decipher things that maybe could turn into docs)
<_florent_>
swetland: review/feedback is always useful yes (being familiar with the project, I no longer see some gaps in doc, etc...). Some notes of the difficulties you can have when adapting the code would also be useful (to know where to put the focus on for the doc).
<_florent_>
mithro: thanks for the litex-hub profile page!
<_florent_>
Hammdist: not exactly what you are looking for, but an example of JTAG-UART standalone core from LiteX components:
<swetland>
some notes (maybe not correct!) on adding a second ethphy+ethmac to a board
<swetland>
I am still finding that depending on where I place the ethernet pmod I may or may not need the clock skew trick. Seems like a combination of gateware layout, baseboard trace lengths, and pmod trace lengths interacting, perhaps. I haven't fired up the fast scope to try to take pictures yet
<_florent_>
swetland: thanks
<swetland>
this is one of those things where it'd be cool if the framework were a little more automatic (like it had the concept of peripheral instances so adding a second or third timer or gpio bank or whatever were a little more plug-and-play), but if not or until that, having some recipes/examples for how to do that might save folks time
<_florent_>
the chip can do more since "only" 54% of the CLBs are used, but Vivado was crashing with 12 000 cores and 64GB of RAM, I would need to switch to 128GB (and switch to 32GB sticks) but not sure I have real need for this...
<swetland>
I am hoping that the next time I do work on xilinx parts I will be able to skip the Vivado experience...
<swetland>
Though last I checked all my makefiles and tcl scripts I use to drive their nonsense without using the UI still worked. So at least there's that.
<_florent_>
swetland: When used in batch mode, I don't really have to complain that much about Vivado. It's sure slower than open-source toolchains on small designs but it scales well on large designs and once you are familiar with it you generally don't have that much surprises.
<_florent_>
But the UI/BlockDesign/IP migration between versions is another thing yes... that I try to avoid
<swetland>
yeah their IP block stuff is pretty amazingly awful
<swetland>
It sounded neat when I first saw it, but it is so incredibly convoluted and ugly under the hood that it just is not worth dealing with
<swetland>
to the point where I ended up writing scripts to generate wrappers around the PS7's like 700 nets ^^
<swetland>
(was doing MIPI2 CSI frontend stuff for machine vision on Zynq at the time. learned a lot about AXI 3 and 4)
<leons>
It's all nice when your system locale is set to English, but otherwise you're in for a treat
<swetland>
I can't even imagine
<leons>
Their weird tcl / java wizards generating XMLs with dots as decimal separators, but the actual synthesis engine expecting commas, etc...
<swetland>
oh no
<swetland>
I look at the house of cards of these vendor tools and you can see the eras of technology stack up...
<swetland>
like back in the day TCL was basically *the* scripting/automation language and everyone adopted it
<swetland>
and then in the early 2000s people started trying to overhaul their GUIs and got sold on Java and XML
<swetland>
but of course kept all the TCL for compatibility
<swetland>
and bolted in piles of native shared libs for performance
<leons>
I have already developed somewhat of a Stockholm syndrome when it comes to Vivado :) At least with that toolchain I have a rough idea where to punch it to get it to work ^^
<swetland>
I'm sorta fearing a next generation where they keep ALL OF THAT and then wrap a new UI built on Electron/JS or Flutter/Dart on top of it, and bridge between JSON, XML, and TCL
<swetland>
what I'm *hoping* for is we'll eventually see the foss software stacks win out like they did in the C/C++ compiler arena
<leons>
For instance, just recently the gtwizard magically took care of automatic rerouting of a refclk input for me, but then set the clock selection to complete garbage. For these bugs their device view to look at the actual implemented design is actually quite nice :)
<swetland>
and have the vendors finally give up on trying to make the core toolchain the "value add"
<swetland>
oh I do like the visualization tools
<leons>
Sure, if they would have working wizards all of this wouldn't be needed, but eh
<swetland>
It's a lot easier to look at what vivado turned your verilog into than yosys/nextpnr
<leons>
Assuming it doesn't segfault, that is :)
<swetland>
well, vendor tools. if they worked all the time where would the adventure be?
<leons>
true
<swetland>
I wasted a day and a half doing bringup on a mcu/radio because the vendor only gives access to the radio via a blackbox library and you need to use their IDE/Wizard to configure it and generate a big 'ol slam table the radio_init() ingests
<swetland>
and I realized that I had started using their out of date IDE, so installed the new multi-GB monstrosity, and then everything went to shit
<swetland>
until I figured out that the importer for the radio config changed the part family (which is NOT VISIBLE ANYWHERE in the CONFIG UI) so it was generating a slam table for the wrong part
<leons>
uh, just realized the latest Vivado is an >70GB download. Not fit for German broadband...
<swetland>
swetland@dontpanic:~$ du -ks /work/app/* | sort -n
<swetland>
34052 /work/app/yosys
<swetland>
99776 /work/app/verilator
<swetland>
81552 /work/app/prjtrellis
<swetland>
530320 /work/app/nextpnr
<swetland>
112504 /work/app/icestorm
<swetland>
not quite 3/4 GB!
<swetland>
or just over maybe (math is hard when I'm half alseep)
<leons>
smaller than Vivado for sure, not that that'd be hard to accomplish I suppose
Abhishek_ has joined #litex
FabM has quit [Ping timeout: 258 seconds]
<mithro>
swetland: -H :-)
<jevinskie[m]>
Bah, I think I’m going to go down another rabbit hole and try to implement RLE for litescope - it would really be nice to get a dozen seconds worth of USB UTMI data instead of sub milliseconds :) anybody else need this and want to help? :) https://github.com/enjoy-digital/litescope/issues/7
<Hammdist>
VexRiscv generated by GenSmallestNoCsr seems to get stuck on an `sb` instruction. did I do something wrong or is it possible the core is so minimal it only supports word-sized memory access?
<Hammdist>
actually it gets stuck on the preceding `li` instruction .. now I'm stumped
<swetland>
what does that exactly disassemble to (is it maybe a constant load through a global register that's uninitialized?)
<somlo>
I'll go ahead and bookmark that for myself, should come in handy in the future :)
<somlo>
but `li` is an alias for a `lui` + `addi`, and does *not* touch any other register but the intended load target
<swetland>
it was my understanding that the assembler treats li as a pseudo op for "most efficient way to get the constant into the register"
<swetland>
so for small constants it could be just an addi target, x0, imm etc etc
<somlo>
which happens to be `lui` followed by `addi` if needed
<swetland>
per the RISCV Unprivileged ISA, li is an alias for "myriad sequences". I do agree that lui+addi or just addi seem most likely.
<somlo>
true, one can do an immediate load just by adding x0 to something... guess the only way to tell is to disassemble whatever is running (e.g. with objdump)
<swetland>
my instinct on "core is hanging on instruction at <addr>" is "check exactly what instruction that is"
<Hammdist>
24: 04200693 li a3,66
<Hammdist>
perhaps I didn't build a correct toolchain
<swetland>
that's addi a3, zero, 66... so certainly seems like the cpu should be plenty happy with it
<swetland>
nah, objdump helpfully disassembles addi target, zero, imm as a li to make it more human friendly
<Hammdist>
notice how the last time iBus_cmd_valid is high is for fetching pc 0x24
<Hammdist>
maybe the dBus didn't acknowledge correctly
<swetland>
00d701a3 sb a3,3(a4)
<Hammdist>
that too but it's never actually requested by the cpu
* swetland
nods
<Hammdist>
indeed 04200693 somehow causes a dBus command that doesn't get acknowledged. I'm not clear on why it's causing a dBus command even but probably more digging will reveal the reason
<Hammdist>
ah it's from an instruction earlier in the pipeline
<Hammdist>
https://paste.ee/p/J9G7A ... don't understand why it's generating such complex code ... and why there is a load of the TXREG