sb0 changed the topic of #m-labs to: https://m-labs.hk :: Mattermost https://chat.m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
attie has joined #m-labs
attie has quit [Ping timeout: 276 seconds]
ohsix has quit [Ping timeout: 265 seconds]
<_whitenotifier> [nmigen] RobertBaruch opened issue #245: Unused signal seems not to change - https://git.io/JeClk
ohsix has joined #m-labs
ohsix has quit [Ping timeout: 276 seconds]
ohsix has joined #m-labs
bradbqc has quit [Ping timeout: 260 seconds]
bradbqc_ is now known as bradbqc
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
<mtrbot-ml_> [mattermost] <sb10q> huh
<mtrbot-ml_> [mattermost] <sb10q> why is OSC1 (50MHz XO to RTM FPGA) not populated?
<mtrbot-ml_> [mattermost] <sb10q> hm, osc2 via gtp, ok
_whitelogger has joined #m-labs
<mtrbot-ml_> [mattermost] <sb10q> okay the RTM FPGA is alive!
<mtrbot-ml_> [mattermost] <sb10q> [ 0.000005s] INFO(satman): ARTIQ satellite manager starting...
<mtrbot-ml_> [mattermost] <sb10q> [ 0.004585s] INFO(satman): software ident 5.0.dev+628.g1bc5d44a.dirty;satellite
<mtrbot-ml_> [mattermost] <sb10q> [ 0.012051s] INFO(satman): gateware ident 5.0.dev+628.g1bc5d44a.dirty;satellite
<mtrbot-ml_> [mattermost] <sb10q> panic at src/libcore/result.rs:945:5: cannot initialize Si5324: "PCA9548 failed to ack write address"
<mtrbot-ml_> [mattermost] <sb10q> current issues are serwb is broken, and loading from AMC doesn't work (missing resistors on the AMC is what I'd guess)
<mtrbot-ml_> [mattermost] <sb10q> let me check this PCA thing..
<mtrbot-ml_> [mattermost] <sb10q> si5324 is up now
<mtrbot-ml_> [mattermost] <sb10q> ...and DRTIO also
<mtrbot-ml_> [mattermost] <sb10q> so we have kasli>amc>rtm drtio working now
<mtrbot-ml_> [mattermost] <sb10q> serwb pisses me off and I'm tempted to just remove it and run everything over the drtio link
<mtrbot-ml_> [mattermost] <sb10q> the DRTIO solution would also support the luxury of RTM hotplugging with the AMC still powered
<mtrbot-ml_> [mattermost] <sb10q> well, if we reload the RTM FPGA on hotplug events, which doesn't sound crazy
_whitelogger has joined #m-labs
<mtrbot-ml_> [mattermost] <sb10q> @rjo @hartytp from your experience with the dodgy "SPI" interface of the HMC chips, can this https://github.com/m-labs/artiq/blob/master/artiq/firmware/libboard_artiq/hmc830_7043.rs#L31-L77 be replaced with calls to this https://github.com/m-labs/artiq/blob/master/artiq/firmware/libboard_artiq/spi.rs ?
<_whitenotifier> [nmigen] whitequark commented on issue #245: Unused signal seems not to change - https://git.io/JeC8K
<mtrbot-ml_> [mattermost] <sb10q> HMC830 and HMC7043 are found, and HMC830 locks (to the Si5324 output)
<mtrbot-ml_> [mattermost] <sb10q> both AD9154s are also found
<mtrbot-ml_> [mattermost] <sb10q> DAC SERDES PLLs are locking
<_whitenotifier> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JeC4c
<_whitenotifier> [m-labs/nmigen] whitequark 2512a9a - back.rtlil: don't crash legalizing values with no branches.
<_whitenotifier> [nmigen] whitequark closed issue #239: Indexing into a 0-length array - https://git.io/JeZSU
<_whitenotifier> [nmigen] whitequark commented on issue #239: Indexing into a 0-length array - https://git.io/JeC4W
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/594153490?utm_source=github_status&utm_medium=notification
<_whitenotifier> [nmigen] Failure. 82.34% (-0.02%) compared to 964c674 - https://codecov.io/gh/m-labs/nmigen/commit/2512a9a12d2c062b8f34330c379ec523b125f38d
<_whitenotifier> [nmigen] Failure. 0% of diff hit (target 82.35%) - https://codecov.io/gh/m-labs/nmigen/commit/2512a9a12d2c062b8f34330c379ec523b125f38d
<_whitenotifier> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/594153490?utm_source=github_status&utm_medium=notification
<mtrbot-ml_> [mattermost] <sb10q> RTM FPGA loading works now, also, DRTIO at 150MHz
<mtrbot-ml_> [mattermost] <sb10q> things are going quite smoothly so far
<mtrbot-ml_> [mattermost] <sb10q> https://hastebin.com/nadatotote.php booting RTM with DRTIO gateware
mauz555 has joined #m-labs
attie has joined #m-labs
attie has quit [Ping timeout: 240 seconds]
mauz555 has quit []
sb0 has joined #m-labs
<sb0> what is this for?
<sb0> we're not using the DAC IRQ feature, are we?
marble[m] has quit [Remote host closed the connection]
jryans has quit [Write error: Connection reset by peer]
synaption[m] has quit [Remote host closed the connection]
xobs has quit [Remote host closed the connection]
rjo has quit [Read error: Connection reset by peer]
jfng has quit [Remote host closed the connection]
jayaura has quit [Read error: Connection reset by peer]
<sb0> so, dac_monitor() can go, and I don't see why the JESD core should be turned off and on?
gruetzkopf has left #m-labs ["http://quassel-irc.org - Chat comfortably. Anywhere."]
jayaura has joined #m-labs
attie has joined #m-labs
rjo has joined #m-labs
<rjo> @sb10q if the parameters are the same then yes.
<mtrbot-ml_> [mattermost] <sb10q> I don't see anything that changes the parameter in that code - is there?
<mtrbot-ml_> [mattermost] <sb10q> it's the DAC init function - it turns the JESD core on, init the DAC, then turns the JESD core off and on - why?
<mtrbot-ml_> [mattermost] <sb10q> that function not changing the parameters within itself, is it?
<rjo> no idea what snippet is for. probably follows the datasheet sequence.
<mtrbot-ml_> [mattermost] <sb10q> who wrote that?
marble[m] has joined #m-labs
xobs has joined #m-labs
jryans has joined #m-labs
jfng has joined #m-labs
synaption[m] has joined #m-labs
attie has quit [Ping timeout: 245 seconds]
attie has joined #m-labs
mumptai has joined #m-labs
<ZirconiumX> whitequark: can you look at my comment for nmigen #178?
<whitequark> which?
<whitequark> oh
<whitequark> so that's just an ordinary ResetSynchronizer
<whitequark> we should make that the default behavior I think
<whitequark> in create_missing_domain()
<ZirconiumX> I'll have to investigate when I get to my dorm room
<ZirconiumX> whitequark: just to clarify, do you mean "the default behaviour for Altera" or "the default behaviour for everything"?
<whitequark> everything
<whitequark> the current behavior is just completely unsynchronized reset
<whitequark> which is probably wrong quite a lot of time
<ZirconiumX> Do you want to do that yourself, or should I take a crack at it?
<whitequark> doing it myself is as much effort as reviewing it
attie has quit [Read error: Connection reset by peer]
sb0 has quit [Quit: Leaving]
<whitequark> ZirconiumX: so it looks like i can't get de0cv anywhere.
<electronic_eel> whitequark: is https://www.digikey.com/products/en?mpart=P0192&v=771 not an option for you?
<electronic_eel> or is that also the wrong one?
<whitequark> electronic_eel: i cna't afford $100 shipping from digikey
<electronic_eel> huh, don't they offer free shipping above 50$ worth of parts?
<whitequark> not to russia afaik
<tpw_rules> are you in russia or HK
<whitequark> former
<emily> whitequark: have you considered using a reshipper?
<emily> like shipito
<emily> pretty sure it'd be a lot cheaper than $100 for electronics that aren't too heavy
<emily> they do have annoying ID requirements though... you can use my shipito address if you want >_>
<whitequark> emily: i was hoping to merge altera support like, a week ago
<emily> I feel like reshippers might be faster than whatever digikey does...
<electronic_eel> don't know what digikey is using to russia, but IIRC they are using UPS and Fedex to other countries
<electronic_eel> and I don't think a reshipper will beat that
<ZirconiumX> Not in speed, but in price, maybe
<ZirconiumX> I shipped some stuff to whitequark a year-ish ago and that was ~£10
<electronic_eel> I just looked up what a small parcel from shipito to Germany would could and it was about $40
<ZirconiumX> And I reckon the FPGA would be about the same weight, and maybe a bit more valuable
<electronic_eel> ZirconiumX: similar to what it would cost from Germany
<ZirconiumX> On the other hand I got my FPGA airmailed from America, so
<ZirconiumX> Speaking of my FPGA, I just realised that I brought along only one mini-USB cable, so I can flash XOR read serial
<ZirconiumX> Well done me
<ZirconiumX> whitequark: So the DE-10 Nano comes with an Arduino Uno compatible header with things like serial and SPI. Would this be a Connector or a Resource?
<ZirconiumX> Since they're connected directly to the FPGA and not required to be these things, I'm inclined to call it a Connector.
<whitequark> ZirconiumX: they could just be both
<ZirconiumX> whitequark: So, the DE10 Nano also uses an ADV7513 HDMI chip, which takes in a 24-bit data input. Do I pick the "correct" option of exposing all 24 data bits, or do I split them into RGB24 like a sane person?
<whitequark> let me see
<whitequark> would there ever be a reason to not put RGB24 on them?
<whitequark> i do realize this question requires you to stare at the HDMI spec most likely
<ZirconiumX> The chip can take YCbCr at up to 12-bit 4:2:2, but I don't think there's much to gain from it
<ZirconiumX> I for one don't see myself using anything other than RGB24
<whitequark> ok, use r/g/b and punt on figuring this out properly for when we extract this into a HDMIParallelResource or something like that
<whitequark> if ever
* ZirconiumX doesn't even have a HDR display
mumptai has quit [Quit: Verlassend]
gnufan_home has joined #m-labs
gnufan_home has quit [Quit: Leaving.]