<somlo>
tpw_rules: I think leons was responding to my (much) earlier rant about it being hard to bisect issues that span litex, litedram, and a whole bunch of other repositories that evolve in parallel
<somlo>
leons: thanks, I can try to enable BIST and see what new information (if any) that gets us
<mikek_VA3TEC>
somlo: would you have a gists on that? I would love to learn about it..
<leons>
tpw_rules: hi :)
<leons>
somlo: Sorry, my replies might've been out of context. I was trying to answer mikek_VA3TEC 's question: "is LiteDRAM separate from litex-boards?"
<somlo>
mikek_VA3TEC: gists on what? bisecting across multiple repos with occasional sync points? I don't know how to do that, that's why I'm complaining about it :)
<somlo>
oh, understood -- although it makes sense in my own context as well :)
<mikek_VA3TEC>
:) no more about how you enable the BIST and use it in context.. (Sorry I am still very new to this)
Degi has quit [Ping timeout: 252 seconds]
<mikek_VA3TEC>
so, I am using external hardware SDDRAM and only getting around 50MT/s and was wondering if this is normal..
<leons>
somlo: haha that's great :) regarding DRAM speeds in general, I would always try to test with BIST first. That allows you to get an estimate of the maximum achievable speed when the DRAM controller pipelines are always full, so it's a good strategy to determine an upper optimization bound
<somlo>
I was going to try to figure out how to do that tomorrow (assuming it makes sense in my context) -- so I don't know (yet)
<leons>
Without knowing any specifics, I would guess that if the BIST values seem plausible (I guess within ~70-90% of theoretical bandwidth), the VexRiscv not being able to achieve that is a matter of its pipelining and caching and other magic + the WB transactions + any multi-cycle WB XBAR (if any) not being able to keep the pipelines of LiteDRAM full
Degi has joined #litex
<tpw_rules>
leons: somlo's complaint is one of the reasons i'm exceited about nix-litex
<tpb>
Title: #litex on 2022-09-19 — irc logs at libera.irclog.whitequark.org (at libera.irclog.whitequark.org)
<tpw_rules>
i guess
<leons>
I feel like I should really get on building the bot which automatically updates pkgs, tests and either pushes / sends an email to the ML with the failed build log. Should be easy enough, major parts are in place.
<tpw_rules>
yes
<leons>
I guess with that we'd be halfway there
<tpw_rules>
what is the other half? actual docs? :)
<leons>
tpw_rules: ouch :D but yes :)
<mikek_VA3TEC>
I second that!!!
<mikek_VA3TEC>
actual docs!!
<tpw_rules>
also a cachix repo maybe. anyway i intend to help with the docs once we refactor the main default.nix. but this is all kind of off topic for this channel
<mikek_VA3TEC>
i hope florent not's listen and gets mad...
<leons>
I don't think getting mad about (more or less) on-topic discussions is how IRC's supposed to work
<tpw_rules>
i think that was more complaining about docs. but that wasn't even about the main litex not docs so florent shouldn't be mad
<tpw_rules>
and solving the bisection problems/having a single globally consistent view of the litex ecosystem
<tpw_rules>
(and temporally!)
<mikek_VA3TEC>
OH ok.. never heard of the nix package manager..
<mikek_VA3TEC>
what's wrong with git pull and ./setup --updates
<mikek_VA3TEC>
Wanted your views..
<tpw_rules>
how do you undo that, for instance?
<tpw_rules>
or do the same thing on a different computer?
<mikek_VA3TEC>
you can't I keep multiple copies of Litex, usually goes by months..
<leons>
mikek_VA3TEC: And how to guarantee that you end up with the same results (i.e., that `./setup --updates` is reproducible)?
<mikek_VA3TEC>
it's not.. I had a solution, I never said it was a GOOD solution.. :)
<mikek_VA3TEC>
I got stung with this exact problem last week...
<mikek_VA3TEC>
Litex is too bleeding edge, there a lot of changes... sometimes fundamental... like renaming boards...
<somlo>
huh... so I'm not familiar with nix-litex (or nix in general), but is the idea to grab a bunch of repositories and create a super-repository containing their respective commits, correctly interleaved (in the actual chronological order in which they were applied to the original repos)?
<somlo>
I can imagine a tool that could do that programatically, then I could bisect on the super-repo to my heart's content
<mikek_VA3TEC>
IS this not what GIT was suppose to do????
<tpw_rules>
that's more of a side effect of how nix and nix-litex works, but yes. the holdup now is that leons currently once a month or so updates the list. it would need to be like, daily, to be useful
<somlo>
I can bisect within a git repo, but if what i'm building depends on other repositories that I'd then have to guess where in *their* history I have to go for each intermediate commit picked by bisect in my "main" repo...
<leons>
somlo: Well, first and foremost this is just a way to make LiteX packages available through the Nix package manager, so you can build packages (read: FPGA designs) which depend on the LiteX packages
<leons>
And then the reproducibility, automated tests on the combined package set, etc. comes for free
<mikek_VA3TEC>
CAn software be written for this? example the change log's?
<mikek_VA3TEC>
florent? should maintain a robust change log?
<somlo>
leons: in my case, I *suspect* some generic axi improvements in litex might have something to do with memtest failing in certain cases; but if I pick a "git bisect good" candidate far back enough to be before those changes, I'm *guaranteed* I can't build (and therefore test) my design without guessing how far back to also go in litedram, litesdcard, litex-boards, and so on -- which makes bisect a practical non-starter
<leons>
somlo: ah, yes, this is a very convincing argument. That would've been possible, had I built a bot to update nix-litex regularly :/
<tpw_rules>
nix-litex works by having a list of repos and hashes, and eventually it will be regularly updated to a set which is temporally coherent and passes all the tests. then you would simply bisect nix-litex and all the rest would be done automatically. but this is a relatively new project so CI hasn't been set up yet
<somlo>
so now I will look for a git-adjacent tool to "merge" multiple repositories by interleaving their commits in the right temporal order :)
<somlo>
should be worth something, so maybe someone already did it (like all my greatest ideas, others typically already had them before me :D)
<tpw_rules>
yeah that would pretty much be the only way to do it now. but it will be better in the future :)
<mikek_VA3TEC>
See Git was suppose to do exactly this, different people had different changes to make, then biscet the changes. the problem now is that there are MULTIPLE git repo;s!
<mikek_VA3TEC>
if I said it right..
<leons>
somlo: The problem is that there's commits which are applied to multiple LiteX repos, but it's not necessarily in a fixed order (i.e. corresponding changes are merged into LiteX before it's merged into LiteDRAM or the other way around)
<leons>
So the benefit of nix-litex would be that the bot would only push collections of packages which are known to build along each other and pass all tests of all packages
<mikek_VA3TEC>
Can special codes be entered into the git commit messages?
<mikek_VA3TEC>
or travers?
<somlo>
mikek_VA3TEC: we're going a bit off-topic talking about how git works, but *within* a repo: people can have clones, push and pull and generally trade commits, etc.; But if unrelated repositories need to be used in concert to build something, then bisecting in one of them is only feasible if it's safe to assume the other repositories are OK staying the same across the range of commits in the "repository under test" searched by bisect
<somlo>
which is clearly *not* the case across the Lite* family of repositories. The simplest example is when something about litedram or litesdcard changes, and the bios code to initialize it in litex/litex/soc/software/* changes to match
<somlo>
you need to have the *right* version (commit) of litedram/litesdcard/etc. depending on where in the history of the main litex repo you happen to test
<somlo>
s/right/matching/
<somlo>
iow, bisect works *within* a repository, not across multiple repositories
<mikek_VA3TEC>
I somewhat understand. This is not an easy problem to solve, You have the main tools and all the boards that are used against it. Right so now there has to be new software written that spans accross multiple repo's
<mikek_VA3TEC>
Linus can write that!! :)
<leons>
somlo: I'd go as far as to say the problem is more far-reaching than that. Each repo has it's own CI, which tests a subset of the repos together, exercising a subset of functionality in the other repos' code. There is no way to be sure that a given commit in one repo, where CI passes, just caused the next CI run in another repo to fail
<leons>
I don't know of a trivial way to fix this, except for an external CI which tracks known good compositions of packages, which is essentially what nix-litex is set out to become (as soon as I find some time...)
<mikek_VA3TEC>
leons: this is why I was saying messages in the commits. you can view the messages and see if things match u this way??
<mikek_VA3TEC>
match up this way?
<leons>
mikek_VA3TEC: I guess you could try and match up commits across multiple repos, but then again the whole point of CI is that it does not rely on maintainers doing the right thing(TM), and it being automatic
<mikek_VA3TEC>
OH i totally agree.... more software has to be written, I was just giving a intern solution..
<mikek_VA3TEC>
But i guess that's what Linux was.... is.. work arounds work arounds until someone writes the proper software..
<mikek_VA3TEC>
Ah ok... but yes... if the maintainers are not keeping up the good code practise... then all bets are off.
<mikek_VA3TEC>
How was florent, OR the maintainers doing this before?
bl0x has joined #litex
bl0x_ has quit [Ping timeout: 268 seconds]
mikek_VA3TEC has quit [Quit: Leaving]
nickoe has quit [Quit: Client closed]
nickoe has joined #litex
VC707 has quit [Ping timeout: 252 seconds]
nickoe has quit [Quit: Client closed]
nickoe has joined #litex
nickoe has quit [Quit: Client closed]
nickoe has joined #litex
<_florent_>
The situation regarding repo split/CI/doc is clear far from perfect, but it should be improving over time (I hope :)). It's mostly time/resource/dev/budget issues that also have their own constraints.
<_florent_>
I'm personally more interested to build a nice community of developers finding the project useful and wanting to contribute than a big project/business, so things are growing/improving slowly, but I think with feedback from each other we'll go in the right direction :)
<_florent_>
For development, the repo split make things easier, but we should indeed continue removing some inter-dependencies (like having gateware/software for some cores in the same repo).
<_florent_>
litex_setup.py was initially used for development and has been improved a bit for deployment (with --tag support for example to install releases), but we should indeed improve pip or nix installation support
mlaga97 has quit [Quit: No Ping reply in 180 seconds.]
peepsalot has quit [Remote host closed the connection]
nats` has quit [Ping timeout: 240 seconds]
hrberg has quit [Quit: No Ping reply in 180 seconds.]
peeps[zen] has joined #litex
mlaga97_ has joined #litex
trabucayre has quit [Ping timeout: 268 seconds]
TMM_ has quit [*.net *.split]
RaYmAn has quit [*.net *.split]
hrberg_ has joined #litex
shoragan[m] has quit [*.net *.split]
cr1901 has quit [*.net *.split]
jryans has quit [*.net *.split]
mikolajw has quit [*.net *.split]
indy has quit [*.net *.split]
genpaku has quit [*.net *.split]
minute has quit [*.net *.split]
a3f has quit [*.net *.split]
Crofton[m] has quit [*.net *.split]
amstan has quit [*.net *.split]
Finde has quit [*.net *.split]
tpb has quit [*.net *.split]
_franck_ has quit [*.net *.split]
jevinskie[m] has quit [*.net *.split]
Wolfvak has quit [*.net *.split]
ilia__s05 has quit [*.net *.split]
zyp has quit [*.net *.split]
xenador77[m] has quit [*.net *.split]
TrailingEdge has quit [*.net *.split]
gruetzkopf has quit [*.net *.split]
sorear has quit [*.net *.split]
hrberg_ has quit [*.net *.split]
josuah has quit [*.net *.split]
pbsds has quit [*.net *.split]
embargo has quit [*.net *.split]
jk- has quit [*.net *.split]
tpw_rules has quit [*.net *.split]
DoubleJ has quit [*.net *.split]
FabM has quit [*.net *.split]
Degi has quit [*.net *.split]
toshywoshy has quit [*.net *.split]
leons has quit [*.net *.split]
pepijndevos[m] has quit [*.net *.split]
keesj1 has quit [*.net *.split]
G33KatWork has quit [*.net *.split]
mupuf has quit [*.net *.split]
novenary has quit [*.net *.split]
Melkhior has quit [*.net *.split]
tumbleweed has quit [*.net *.split]
fpga_zealot[m] has quit [*.net *.split]
shenki_ has quit [*.net *.split]
pavelow has quit [*.net *.split]
benh has quit [*.net *.split]
esden has quit [*.net *.split]
tnt has quit [*.net *.split]
mtretter has quit [*.net *.split]
vup has quit [*.net *.split]
anuejn has quit [*.net *.split]
tcal has quit [*.net *.split]
_florent_ has quit [*.net *.split]
oter has quit [*.net *.split]
RowanG[m] has quit [*.net *.split]
DerekKozel[m] has quit [*.net *.split]
CarlFK has quit [*.net *.split]
lambda has quit [*.net *.split]
key2 has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
gatecat has quit [*.net *.split]
sajattack[m] has quit [*.net *.split]
Stary has quit [*.net *.split]
mobius has quit [*.net *.split]
shoragan has quit [*.net *.split]
jtf has quit [*.net *.split]
peeps[zen] has quit [*.net *.split]
mlaga97_ has quit [*.net *.split]
bl0x has quit [*.net *.split]
gurki has quit [*.net *.split]
acathla has quit [*.net *.split]
MoeIcenowy has quit [*.net *.split]
somlo has quit [*.net *.split]
shorne has quit [*.net *.split]
nickoe has quit [*.net *.split]
jryans has joined #litex
trabucayre has joined #litex
hrberg_ has joined #litex
mlaga97_ has joined #litex
peeps[zen] has joined #litex
FabM has joined #litex
nickoe has joined #litex
bl0x has joined #litex
Degi has joined #litex
tpb has joined #litex
indy has joined #litex
toshywoshy has joined #litex
genpaku has joined #litex
josuah has joined #litex
_franck_ has joined #litex
minute has joined #litex
cr1901 has joined #litex
oter has joined #litex
leons has joined #litex
a3f has joined #litex
pepijndevos[m] has joined #litex
RowanG[m] has joined #litex
CarlFK has joined #litex
amstan has joined #litex
Crofton[m] has joined #litex
DerekKozel[m] has joined #litex
sajattack[m] has joined #litex
mupuf has joined #litex
Finde has joined #litex
jk- has joined #litex
acathla has joined #litex
MoeIcenowy has joined #litex
Wolfvak has joined #litex
zyp has joined #litex
ilia__s05 has joined #litex
DoubleJ has joined #litex
G33KatWork has joined #litex
tpw_rules has joined #litex
keesj1 has joined #litex
embargo has joined #litex
pbsds has joined #litex
sorear has joined #litex
TrailingEdge has joined #litex
tumbleweed has joined #litex
Melkhior has joined #litex
novenary has joined #litex
_florent_ has joined #litex
tcal has joined #litex
anuejn has joined #litex
mtretter has joined #litex
vup has joined #litex
esden has joined #litex
tnt has joined #litex
benh has joined #litex
pavelow has joined #litex
gatecat has joined #litex
shenki_ has joined #litex
key2 has joined #litex
kbeckmann has joined #litex
jtf has joined #litex
lambda has joined #litex
gurki has joined #litex
shoragan has joined #litex
mobius has joined #litex
Stary has joined #litex
shorne has joined #litex
somlo has joined #litex
fpga_zealot[m] has joined #litex
xenador77[m] has joined #litex
mikolajw has joined #litex
jevinskie[m] has joined #litex
gruetzkopf has joined #litex
hrberg_ has quit [Max SendQ exceeded]
hrberg has joined #litex
shoragan[m] has joined #litex
TMM_ has joined #litex
RaYmAn has joined #litex
zjason` has quit [*.net *.split]
msh has quit [*.net *.split]
lexano has quit [*.net *.split]
SpaceCoaster has quit [*.net *.split]
geertu has quit [*.net *.split]
Crofton[m] has quit [Ping timeout: 250 seconds]
jevinskie[m] has quit [Ping timeout: 250 seconds]
CarlFK has quit [Ping timeout: 264 seconds]
jryans has quit [Ping timeout: 268 seconds]
pepijndevos[m] has quit [Ping timeout: 268 seconds]
shoragan[m] has quit [Ping timeout: 264 seconds]
sajattack[m] has quit [Ping timeout: 240 seconds]
amstan has quit [Ping timeout: 250 seconds]
a3f has quit [Ping timeout: 250 seconds]
RowanG[m] has quit [Ping timeout: 264 seconds]
mikolajw has quit [Ping timeout: 268 seconds]
zjason` has joined #litex
msh has joined #litex
SpaceCoaster has joined #litex
lexano has joined #litex
geertu has joined #litex
DerekKozel[m] has quit [Ping timeout: 264 seconds]
leons has quit [Ping timeout: 268 seconds]
fpga_zealot[m] has quit [Ping timeout: 268 seconds]
xenador77[m] has quit [Ping timeout: 268 seconds]
pepijndevos[m] has joined #litex
Crofton[m] has joined #litex
jevinskie[m] has joined #litex
a3f has joined #litex
sajattack[m] has joined #litex
RowanG[m] has joined #litex
CarlFK has joined #litex
jryans has joined #litex
mikolajw has joined #litex
shoragan[m] has joined #litex
DerekKozel[m] has joined #litex
fpga_zealot[m] has joined #litex
leons has joined #litex
xenador77[m] has joined #litex
amstan has joined #litex
<leons>
_florent_: I agree and the conversation wasn't supposed to be a rant about the current situation, just thinking about how someone downstream can ensure that a given collection of LiteX packages will work together.
mikek_VA3TEC has joined #litex
nickoe has quit [Quit: Client closed]
nickoe has joined #litex
<somlo>
as it turns out, I had a typo associating the wrong verilog to the "problematic" rocket cpu variant -- git bisect would have never caught it (I would have failed to find a "good" commit, no matter how far back I went) :)
<somlo>
not that the whole argument about bisect-ability isn't valid in the big scheme of things, just not applicable to this particular issue
<tpb>
Title: Imgur: The magic of the Internet (at imgur.com)
<somlo>
(at least for a short time before it crashed, but progress!)
<mikek_VA3TEC>
Sweet! :)
<leons>
somlo: That is very cool! I have actually just gotten access to a Nexys Video board, mind sharing how to reproduce / pushing the code somewhere?
<mikek_VA3TEC>
Yes, i second that!
<somlo>
so building the bitstream is easy (now that `fulld` rocket variant is no longer broken):
<somlo>
then there's downloading the latest fedora-riscv64 image, and prepping a special initrd, dts/dtb, and opensbi firmware blob, and the writing all that to a sdcard
<somlo>
I'll have to write all that down in a way that is intelligible (from various notes I took while hacking on it) -- that might take a day or two (need some peace and quiet from $DAYJOB to focus :D)
<somlo>
using `full4d` (4x SMP) crashes *before* getting a login prompt; using `full` (1x single-core) with the 4x DTB (I was lazy) crashes *after* the login prompt
<somlo>
I still need to try the single-core with the correct DTB (that doesn't claim there are 4 cores available :) and see if maybe I get it to work *without* crashing
<somlo>
gotta go, lunch break is almost over and I spent it on hacking instead of eating -- I'll be back later with more useful details
<mikek_VA3TEC>
Thanks Somlo! :)
mikek_VA3TEC has quit [Remote host closed the connection]
zjason` is now known as zjason
mikek_VA3TEC has joined #litex
nickoe has quit [Quit: Client closed]
nickoe has joined #litex
FabM has quit [Ping timeout: 268 seconds]
nickoe has quit [Quit: Client closed]
nickoe has joined #litex
<tnt>
Mmmm ... the error messages of migen are a bit obscure ... "assert (node.stop - node.start) >= 1"
mikek_VA3TEC has quit [Remote host closed the connection]
<tnt>
"""ERROR: [Synth 8-3391] Unable to infer a block/distributed RAM for 'storage_49_reg' because the memory pattern used is not supported. Failed to dissolve the memory into bits because the number of bits (528384) is too large. Use 'set_param synth.elaboration.rodinMoreOptions {rt::set_parameter dissolveMemorySizeLimit 528384}' to allow the memory to be dissolved into individual bits"""