azonenberg changed the topic of ##openfpga to: Open source tools for FPGAs, CPLDs, etc. Silicon RE, bitfile RE, synthesis, place-and-route, and JTAG are all on topic. Channel logs: https://libera.irclog.whitequark.org/~h~openfpga
Hoernchen_ has joined ##openfpga
Hoernchen has quit [Ping timeout: 268 seconds]
Raito_Bezarius has quit [Ping timeout: 252 seconds]
Degi has quit [Ping timeout: 240 seconds]
Degi has joined ##openfpga
cr1901 has quit [Remote host closed the connection]
cr1901 has joined ##openfpga
cr1901 has quit [Remote host closed the connection]
cr1901 has joined ##openfpga
Raito_Bezarius has joined ##openfpga
Raito_Bezarius has quit [Max SendQ exceeded]
Raito_Bezarius has joined ##openfpga
<ZipCPU>
sensille: Are you prepared to maintain it?
<ZipCPU>
That's sort of the rule of any open source component you wish to include into your project, is it not?
<ZipCPU>
You have no promise of maintenance, just the existence of (potentially) working IP. If it (almost) works, are you then willing to fix it in order to get your project done on time?
<sensille>
ZipCPU: that's a good question. this is just a hobby project, but the learning curve of litex is quite steep, mainly due to missing documentation
<sensille>
it has working etherbone IP for both target boards
<gurki>
sensille: there is no generic answer. it boils down to "can you deal with such a complex ecosystem, even if it shits itself" (which might or might not happen, as ZipCPU mentioed)
<gurki>
the plus of a hobby project is that it doesnt hurt if you need to hit it with a hammer for three weeks. the downside is that your hobby might turn into a rabbit hole.
<gurki>
i like to use the most simple option that can precisely do what i need when im doing hobby projects
<gurki>
now "most simple" is quite personal - im used to tool x, so things that are simple with tool x might not be simple for a person used to tool y
<sensille>
it is not the easiest option, but it has the promise to become a new tool my toolbox
<sensille>
i was hoping for optinions like "it's great! i use it for everything, so easy!" or "ugh."
<tpw_rules>
it definitely feels under-maintained and buggy, especially for intel FPGAs.
<tpw_rules>
but i didn't really find it heard to learn or excessively complex per se, maybe because i'm a python and amaranth lover
<tpw_rules>
(or masochist)
<sensille>
reading source helps
<sensille>
are there any alternative open source multi-platform frameworks?
<ZipCPU>
Yeah ... I'm not a python lover, so ... I've generally not used it
<ZipCPU>
sensille: What are you looking for specifically? LiteX has lots of subprojects
<ZipCPU>
I've examined it for Ethernet and SATA, but always in the end used Verilog models for both
<sensille>
ethernet is the interesting part, across various phys and for xilinx/lattice
<sensille>
i'm looking into a project that uses etherbone, but i'm not sure i want to keep it. it is quite convenient, though
* ZipCPU
googles etherbone
<ZipCPU>
Crypto currency?
<tnt>
it's just a way to generate bus transaction (wishbone / ...) through ethernet packets.
<ZipCPU>
Oh.
<ZipCPU>
Well ... that's not all that hard ...
<tnt>
etherbone/uartbone/spibone/jtagbone/usbbone/ ... a bunch of way litex wraps the same protocol to kind of provide some "debug" access to an internal bus from the outside. It's convenient for sure, but indeed, not rocket-science.
<sensille>
i think etherbone originated from cern, so just particle-science :)
<tnt>
:D
<sensille>
some udp hack for low latency
<sensille>
generate the answer before the request packet is received completely
<sensille>
but basically just another rdma-protocol
_florent_ has left ##openfpga [##openfpga]
<somlo>
fwiw, I wanted/needed to build a "computer from scratch on an fpga"; started with lowRISC, then realized it's using Xilinx's proprietary dram controller, and relies on vivado :)
<somlo>
LiteX's LiteDRAM was the answer to that, bonus points for supporting completely free/open yosys/trellis/fpga on lattice ecp5 FPGAs
<somlo>
going through the migen tutorial helped a bit; I'm nowhere near close to having a solid handle on all of it, but at least I can drill into any individual piece if I *really* have to :)
<somlo>
then it turned out to be much easier to adopt all of LiteX rather than just "paste" the litedram controller into a verilog+duct tape design around a cpu
<gurki>
somlo: isnt the concept of litex more or less being duct tape
<somlo>
so I'm firmly in the "litex is awesome" camp now, for whatever it's worth. But a working understanding of migen is a big step toward beginning to understand what's happening
<somlo>
well, lowRISC was basically a "bunch of IP blocks connected by verilog"
<somlo>
in that sense, litex is being methodical about it, at least :)
<gurki>
but you also have to understand a lot more things once it breaks
<gurki>
usual tradeoff to have in mind :)
<somlo>
in addition to providing sources for everything one might need, without punting to "well, this bit we're just importing from xilinx's vivado library"
<somlo>
right, like I said, migen is the first step, then one can go on an archaeological dig through the sources, and ask lots of questions in github issues and/or #litex :)
<somlo>
as for documentation, it's another interesting tradeoff. For a bit of analogy, I'm pretty OK (not great, but very much OK) with programming in C. But I could stare at Linux sources till the cows come home, and didn't make much sense of it -- until I took an OS course, where I had to slow down and methodically internalize the conceptual moving parts
<somlo>
then suddenly things got easier and began to make sense :)
<somlo>
it's probably similar with litex and digital design concepts (plus migen, can't repeat that enough)
<somlo>
so what I'm getting at is: writing documentation is hard, because it's hard to decide what level to write it at: try to be too inclusive and you're writing yet another digital design textbook; target experts, and writing the manual is redundant as they'll just make sense of the sources
<somlo>
Anything in between, and I wouldn't know how to start and what to write :D
<gurki>
somlo: well. have a friend who has never used $thing before try to set it up and ask questions
<gurki>
bonus points if he knows about as much about hdl dev as the guys you intended your tool for :3
<gurki>
write down everything he needs to get started.
* gurki
has done this quite a few times
<somlo>
gurki: that sounds like a full time job in and of itself :D
<gurki>
yes, thats why a lot of projects suck at documentation :D
<gurki>
i wish i could say that i did this for everything i do, but just like everyone else i dont have unlimited time ^^