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
stekern_ has joined #m-labs
stekern has quit [Read error: Connection reset by peer]
stekern has joined #m-labs
stekern_ has quit [Read error: Connection reset by peer]
forrestv has quit [Read error: Connection reset by peer]
<mithro>
sb0: the CSR CSV format is used heavily by litescope - I've also got some very hacky tools which look at the csv file too
<mithro>
Hrm sb0 isn't here...
<mithro>
sb0: '::' isn't really a valid Python identifier, so its likely that litescope would have to translate it back into '_' or something...
<rjo>
mithro: the idea would be to make it *not* a valid python identifier to be able to unambiguously distinguish a.b from a_b
<mithro>
Yeah, that seems reasonable
<rjo>
mithro: i guess that litescope could just `Mock()` that hierarchy very quickly and intuitively.
<mithro>
rjo: yeah, at the moment it just provides a flat namespace
<mithro>
At some point I need to talk to you all about device tree generation again..
sb0 has joined #m-labs
<rjo>
mithro: by the way. we really should get a bit of documentation into migen/misoc. litex would profit equally. from what we have seen in the last weeks especially migen Platform/constraints/connector/build documentation appears to be high value.
<mithro>
What has happened in the last few weeks?
<rjo>
conferences, lots of meetings
<mithro>
rjo: I was chatting with sb0 about being able to annotate platform stuff with human comments which can be exposed to the firmware. Things like silkscreen labels for LEDs and connectors.
<mithro>
So in your firmware you can provide stuff like "led on <silkscreen label>" without having to have the firmware be specific to every board
<rjo>
mithro: yes. i saw that. but that's there, right? just needs documentation on best practices and API.
<rjo>
mithro: "usual" pcb tools give you a refdes for an led and a label. i.e. you will use the label in the platform def.
<rjo>
LD8, P5V0_GOOD etc
<rjo>
label=value for LEDs.
<mithro>
Well, sb0 wasn't all that convinced of the idea - I was thinking that the PlatformInfo thingy was for that but he suggested that should be removed
<mithro>
Sorry, I'm on my phone so might disappear at any moment
<rjo>
i never noticed/needed PlatformInfo and was always happy with the 'platform signal name == pcb label/value' method.
<mithro>
I have a tool which takes the Opsis KiCad schematic and generates a UCF file with comments
<rjo>
mithro: aren't you duplicateing stuff that should be in the schematic? or just comments?
<rjo>
whitequark: mntng is sb0's intern from hkust
<rjo>
sb0: he should introduce himself here!
<rjo>
she!
<rjo>
whitequark: another thing. could you leave one sayma connected (micro-usb to lab and power)?
<rjo>
whitequark: i'll play with spi/jtag/openocd
mumptai has quit [Quit: Verlassend]
<whitequark>
rjo: okay
sb0 has joined #m-labs
<sb0>
whitequark, while you're there you can also prepare the zotino card (hook up power, and if you have better ones replace the hex standoffs and screws)
<sb0>
there is a 12V power adapter on the board table that in theory is suitable AFAICT. but if you need it for sayma then sayma has priority.
<GitHub123>
[artiq] sbourdeauducq commented on pull request #818 fdf7887: Also, 3249 is already used by another ARTIQ service. Better pick another port, e.g. 7777 as used in test_pc_rpc.py. https://github.com/m-labs/artiq/pull/818#discussion_r135154869
<GitHub1>
[artiq] sbourdeauducq commented on pull request #818 fdf7887: This will fail if ``sys.executable`` contains a space character. Better pass the arguments with a list and use ``create_subprocess_exec`` as done elsewhere. https://github.com/m-labs/artiq/pull/818#discussion_r135154504