07:33 <MoeIcenowy> got a Tang Mega 138K ES from Sipeed

07:34 <MoeIcenowy> going to do some basic LiteX port to test it

08:54 <josuah> whoa :D I was curious about arora

08:55 <josuah> MoeIcenowy: I have not this board, but would be happy to help with the bringup

10:44 <josuah> I have the distant impression that LiteX could be made much more generic at many places

10:45 <josuah> in particular in the target board definition, where chunk of codes are typically copy-pasted from board to board

10:47 <josuah> for instance, to add a `with_jtagbone` to a board, there are several places where to inject the support

10:48 <josuah> it could be done programatically for all boards who declare a JTAG interface

10:48 <josuah> is this all by design, or is this a matter of slowly geting there as LiteX gets built further?

10:50 <josuah> board definitions would be reduced to declaring the hardware (pins, hardened cores, clocks) and surrounding tooling (platform, command line flags for the adapter...)

10:51 <josuah> hmm, somehow, LiteX board definitions are already that

10:51 <josuah> https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/muselab_icesugar.py#L82-L84 for instance

10:52 <josuah> it would only be a matter of managing the "if with_xxx: add_xxx()" globally rather than per-board: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/muselab_icesugar.py#L95

10:55 <josuah> changes that affect all boards are always difficult unless owning the whole hardware

10:56 <whitequark[cis]> there is a desire to improve board definitions dramatically in the next amaranth release

10:56 <josuah> so it could need to be done incrementally: supporting "auto-feature" in enjoy-digital/litex, and make it an opt-in per board

10:56 <josuah> whitequark[cis]: if I get enough time, I'd want to try add a `litex_boards/targets/amaranth_boards.py` :]

10:57 <josuah> which would be a proxy to reuse all of Amaranth boards from LiteX

11:05 <whitequark[cis]> this approach could result in friction, so it's something that needs to be evaluated carefully

11:20 <josuah> I see how bugs in project X reported in project Y could be bothering

11:20 <josuah> might be more fit as an evil experiment in basement lab than an official proposal

11:34 <zyp> the problem I'd like to see a better solution for is when I've got a project that's buildable for multiple different boards that vary in what drivers they need

11:38 <zyp> e.g. if I've got one board with a ddr3 memory and one board with a hyperram and I've got a project that doesn't really care what memory technology is available, how do I abstract over the differences?

11:40 <whitequark[cis]> I think you need two toplevels

11:41 <whitequark[cis]> there is no abstraction here that would not be worse than having two toplevels, I think

11:41 <whitequark[cis]> since the difference between the toplevels would be basically "which memory adapter you instantiate"

11:47 <zyp> it gets more complex if you start considering a matrix of generic footprint compatible modules and project specific carriers

11:48 <zyp> like the colorlight stuff -- i5, i9 and i9+ are effectively ecp5-25, ecp5-45 and xc7a50 modules that are footprint compatible

11:49 <josuah> where "two toplevels" could be a single toplevel with "if" branching?

11:49 <zyp> I've put one of them in a fanuc robot arm, and at some point I'll probably put another in a plasma cutter

11:51 <zyp> I figure the project should be the toplevel, since it'll have different functionality depending on the device it's going into, but I'd like to be able to build each of the projects for either of the three modules

11:53 <josuah> They look like having quite the variants themselves https://aloi.com/wp-content/uploads/2016/06/FANUC-ROBOTS.jpg

11:53 <josuah> nice project, this looks to be!

11:54 <zyp> mine is from 1995 or so, probably much older than those :)

12:19 <whitequark[cis]> zyp: you probably still do not want to exercise the entire matrix

12:19 <whitequark[cis]> because there's no real way to find out if your design works properly other than simulation and extensive hardware testing

13:01 <zyp> indeed, I don't need every combination in practice, but I still want it to be easy to make arbitrary combinations

13:31 <whitequark[cis]> this still seems to me like something that can be solved with a bunch of toplevels, or one toplevel and a switch

13:31 <whitequark[cis]> rather than inventing a new abstraction

14:16 <josuah> in that regard, it would help to allow toplevel be made very concise, making them look much more like a configuration file than anything

14:16 <josuah> with most of the heavy lifting handled downstream, in what is called from them

15:58 <MoeIcenowy> how to debug rgmii?

15:59 <MoeIcenowy> (well a very bad question, but I don't know how to ask it better)

17:25 <josuah> MoeIcenowy: do you have any transceiver attached to it on hardware along with an Ethernet cable plugged to it?

17:25 <josuah> MoeIcenowy: or do you have an RGMII interface on your design, and want to send packets to it in simulation?