<_florent_>
disasm[m]: Migen is the short the abbreviation of Milkymist generator, so Mi - gen
<_florent_>
LiteX is pronounced Lite - X
<disasm[m]>
_florent_: thanks!
<somlo>
daveshah: thanks! -- fingers crossed it's not too horrible to fix...
FFY00 has joined #litex
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 260 seconds]
<daveshah>
rocket is such a PITA to debug I don't know, I have spent the whole day looking at it and made little progress
<daveshah>
ideally something that is not such a mess will also hit the same bug and be easier to debug
<daveshah>
OK, when adding -flatten to synth_xilinx to make the first stages of synthesis the same as ECP5, it seems to fail in the same way (with Vivado PnR)
<daveshah>
Makes sense as that commit was mostly changing generic stuff
<somlo>
daveshah: I like rocket from a "dumb downstream user" standpoint -- feature-complete rv64gc. Pity it's so "outsider-resistant": I did the chisel tutorial and comprehended most of it at the time, but then I try to look at the sources of Rocket, and it takes hours and days to figure out how the simplest things are conected :(
<daveshah>
wait until you look at the generated Verilog...
<somlo>
I have, and the only marginally comprehensive thing is to follow the module interfaces to try to reverse engineer some of the "schematics"; the body of each module is practically line noise...
<Finde>
I'm a little surprised no one's got ariane into litex
<somlo>
back about two years ago, I needed a linux-capable rv64gc core in litex, and I remember looking at both, and rocket won because it appeared more mature. Being a "dumb downstream user" like I said earlier, I wanted the cheapest (in terms of my own brain cell expenditure) way of getting 64-bit linux working on litex :)
<somlo>
side rant: I know lots of people who know a thing or two about digital design like to trash-talk Verilog, just like a lot of modern software types like to trash-talk C; to me, both have the same main quality, of allowing an outsider to follow the "design thread" of something written in either, with comparative ease
<daveshah>
I actually don't have a problem with higher level HDLs per se, just Chisel's output tends to be particularly impenetrable
<somlo>
unlike the cool OOP-style languages (chisel for HDL, all the go/rust/whatever on the software side) where figuring out what's going on is made harder for any outsider by virtue of OOP's wherever you're looking, what you seek happens somewhere completely different style of source layout :)
<somlo>
I get that chisel treats verilog the way high-level software languages treat raw binary opcodes :)
<daveshah>
It just seems to generate some particularly strange patterns
<somlo>
and they don't want you looking at the verilog to troubleshoot what's wrong with it, at least not from what I remember from the official party line :)
<daveshah>
I find both Migen and nMigen a lot easier to debug than Chisel - little different to debugging Verilog tbh
<daveshah>
hard to avoid looking at the verilog when debugging the synthesis tool though ;)
<somlo>
to me, [n]Migen is like a Python-augmented "generate-on-steroids" verilog enhancement
<daveshah>
Yeah
<somlo>
whereas Chisel is to Verilog like Haskell is to assembly opcodes :D
<daveshah>
I personally prefer that, but I may be a biased perspective because I spend most of my life debugging toolchains rather than writing HDL
<daveshah>
so arguably not the typical end user of these thigns
<somlo>
that's my whole point (in defense of C and verilog, against the language-ninja trend of the current times)
<somlo>
when shit hits the fan, it's just less painful to figure out what's going on :)
<somlo>
and this whole conversation reminds me, I haven't updated Litex's rocket verilog in a good number of months either, wonder what will happen when I do that...
<daveshah>
I was playing around with yoloRISC today randomly and I found some stuff had broken
<daveshah>
don't know if that will affect LiteX too, but if you get strange errors try that
<somlo>
good to know, thanks!
<somlo>
daveshah: hadn't thought about yoloRISC in a long time (that was before I discovered LiteX)
<daveshah>
yeah, I wanted to try it as a simple test with a testbench but it doesn't break
<somlo>
was wondering about that...
<daveshah>
even the simplest LiteX SoC (no DDR3/ethernet/sdcard, default rocket config, 20MHz clock) fails though
<somlo>
daveshah: that simplest LiteX SoC should also fit on a versa (45k ecp5). Wondering if it fails there as well...
<somlo>
not that I see why it shouldn't
<daveshah>
I think it probably would, given it fails on the Arty too using Yosys+Vivado
<somlo>
right, you did say that
<somlo>
interesting, upgrading rocket to #58a0e1052 works fine on the nexys4ddr (64-bit wide variant), but fails dram initialization on trellisboard (256-bit wide variant). "old" yosys (the one I used to successfully build working trellisboard bitstream using the old rocketchip)