sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
_whitelogger has joined #m-labs
<cr1901_modern>
sb0: Did you get back to olofk or vice versa re: fusesoc? We were discussing integration w/ Migen last night and I think we came up w/ a decent idea (Migen user imports fusesoc, fusesoc returns metadata on the verilog project, migen uses metadata and auto-creates an instance)
<sb0>
cr1901_modern, ok
<cr1901_modern>
sb0: Wait, you agree :o? This implies adding a parser for fusesoc metadata to migen (at least that's how olofk) wants to do it. Not difficult, but... it is extra code/bloat.
<cr1901_modern>
sb0: (Of course there are other ways to do this. I just asked you for feedback on the off chance you'd agree :P)
<sb0>
what is the end goal of this, exactly?
<sb0>
and I still don't see why this can't be put into a package separate from migen and fusesoc
<sb0>
also if fusesoc is a package manager/build tool, it would make sense to do things the other way around, i.e. fusesoc calls migen
<cr1901_modern>
sb0: Goal is automate migen being able to build designs which rely on external verilog code using a common package manager (fusesoc).
<cr1901_modern>
I mean, I think migen's build process is superior for reasons
<cr1901_modern>
but yes that also works
<sb0>
I don't particularly like the migen build process itself, it's more that you can have all sorts of tweaks using python
<sb0>
for a multi-dependency project, something like cargo would be nice
<sb0>
but ok. the problem you are trying to solve is: you have a project which is built using python in the "migen/misoc" way, and that project uses some fusesoc-wrapped cores, and you want those to be downloaded and instantiated automatically?
<cr1901_modern>
Yes.
<sb0>
okay, well I think having that "glue" code in a separate repository is doable
<cr1901_modern>
Okay cool, I'll relay that back then...
<sb0>
and you can get started that way, if popular, clean and well-maintained then it can be moved into a folder in migen ..,
<cr1901_modern>
Fair enough
<cr1901_modern>
Just so I know, what is wrong w/ the migen build process in your eyes, and what behavior would you in theory prefer?
<sb0>
it's not much of a build process, it's just a python script that does things
<sb0>
and also the code in migen/build is messy and ad-hoc
<sb0>
the platform api is also not super nice
<cr1901_modern>
Really? I mean, I almost never want to touch Verilog when I can get migen to make me a top level (even for Verilog modules I'm just routing platform signals thru)
<cr1901_modern>
sb0: "for a multi-dependency project, something like cargo would be nice" <-- you may wish to look into Meson, which has FPGA support in progress. I could just like migen.build b/c I'm used to it. But >>
<cr1901_modern>
I _do_ find the platform api valuable b/c you can write "universal top levels", dependent only on peripherals and adding a board to the platform api
<cr1901_modern>
^That's why I did the blog post in the first place
<cr1901_modern>
Code reuse/portability is good (TM)
<cr1901_modern>
I don't have great social media reach, but I do hope more ppl use migen and port more boards :P
<sb0>
sure, it works, but it's a bit dirty
<cr1901_modern>
sb0: Yes, agreed; in at least one case, I've had to resort to fragments and do_finalize() to get a "universal top level" and I don't like it at all. But at present, it was still less work than anything that required me to write Verilog. Maybe I'll think of a better solution in time.
<cr1901_modern>
sb0: In your experience, have you seen a lot (i.e. more than one) migen user who creates standalone Modules and creates a repo for it (say, for example, a standalone non-MiSoC UART meant to be used in other code)?
<cr1901_modern>
If so, I think I can see why you want something like cargo...
rohitksingh_work has joined #m-labs
<sb0>
cr1901_modern, no
<sb0>
but having something like cargo would be beneficial to python in general and not just migen projects
<sb0>
the current package managers are very crappy
sb0 has quit [Quit: Leaving]
bb-m-labs_ has joined #m-labs
rjo1 has joined #m-labs
rjo has quit [*.net *.split]
bb-m-labs has quit [*.net *.split]
rohitksingh_work has quit [Ping timeout: 260 seconds]
rohitksingh_work has joined #m-labs
sb0 has joined #m-labs
<sb0>
rjo1, boards rebooted and connected to relay
<sb0>
relay is on /dev/ttyACM0
<rjo1>
sb0: ack
<rjo1>
sb0: i guess R253 is not there on the saymas you have?
rjo1 is now known as rjo
<sb0>
rjo, where is it located on the pcb?
<sb0>
do you already know?
sb0 has quit [Quit: Leaving]
_whitelogger has joined #m-labs
<rjo>
sb0: my guess would be the left one of the two above the "T27", underside top left.
rohitksingh_work has quit [Read error: Connection reset by peer]
llopez has joined #m-labs
llopez has quit [Ping timeout: 260 seconds]
llopez has joined #m-labs
<rjo>
_florent_: about getting sines out of the dacs...
<rjo>
_florent_: i am integrating jesd into current artiq but that may take a while to be useful to greg's allaki testing because of ethernet etc.
<rjo>
_florent_: we could just strap a BRAM or a cordic into a channel in your sayma_test repo.
<rjo>
_florent_: what's your take?
<rjo>
_florent_: and is the migen jesd204b repo up to date with your litex jesd204b?
<sb0>
whitequark, surely there are other languages with a modulo operator like python, and they have the proper way to do that with llvm ir?
<whitequark>
ok, I will look at it
<sb0>
what does numba do?
<rjo>
sb0: i can't get the second flash chip to work on any of the three AMCs. could you check whether they are wired like florent's? the photos i uploaded are from florent's.
<GitHub108>
[smoltcp] batonius commented on issue #44: Added `FromStr` implementation for `IpCidr`. https://git.io/vdmQw
mumptai has quit [Remote host closed the connection]
<_florent_>
rjo: no problem to integrate bram or cordic into sayma_test if this can speed up things, just provide me the data generator and I'll prepare something
<_florent_>
rjo: I'll also integrate the last jesd changes in jesd repo