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
<GitHub-m-labs>
[artiq] whitequark commented on issue #919: I've checked with the commit that used to work. RTMs "1" and "2" lock and there is just 3V at the DAC SMPs. RTM "F" does not lock. This happens with either clock generator. https://github.com/m-labs/artiq/issues/919#issuecomment-382236979
<sb0>
whitequark, what does that mean?
<whitequark>
sb0: what does what mean?
<sb0>
the ROP chain thing
<whitequark>
oh
<whitequark>
ROP chains are a technique used by exploit writers to work around W^X page permissions. basically you set up the stack such that you return to an entry point of some function that takes whichever values you also put onto stack or had in registers, and does something you want
<whitequark>
(where "function" could mean system() or could mean a chunk of code in system libs that just happened to do what you want)
<whitequark>
i've happened to measure the impact of return address mispredictions on modern intel CPUs and it's something like 10x costlier than regular retq
<sb0>
whitequark, yes, I looked that up, but I don't see how that applies to vivado
<sb0>
why would it do something like that?
<whitequark>
sb0: they obfuscated some code that deals with encrypted IP core
<whitequark>
but didn't bother to leave a fast path
<sb0>
ah
<whitequark>
it's *also* encrypted on top of that, I looked into some libraries and the actual code is nonsense. they call dl_iterate_phdr and mangle their own executable segment
<sb0>
with some tools the cleartext of said IP is passed to memcpy() and you can grab it with ltrace
<sb0>
not that there is anything valuable in there, it's typical trashy verilog written by "hardware" people, i.e. unmaintainable spaghetti, no coding style, various hacks, etc.
<sb0>
maybe this is why they don't want people to read it x
<sb0>
xD
<whitequark>
that is definitely a part of it
<whitequark>
sb0: any idea what to do with ad9154?
<whitequark>
I'm now left without a reference to compare with
<sb0>
not really. it sounds strange that PRBS etc. pass but then there is no output
<sb0>
maybe the hardware is damaged?
<whitequark>
well I tried 3 RTMs
<whitequark>
one of them would have probably been fine
<whitequark>
though who can say
<sb0>
I'll give it a quick try
<whitequark>
sb0: wtf
<whitequark>
that search query on taobao returns something that the seller calls "imitation eurorack"
<whitequark>
is that like imitation crab meat?
<sb0>
they are just being explicit, with many other vendors "imitation" is implied
<whitequark>
AFAICT none of these actually accept eurocards
<whitequark>
they don't have this rail with captive nuts
<whitequark>
some of them are similar in size (though it's hard to tell without proper drawings), but I think that's as far as it goes
<sb0>
there was one at wipm that did take eurocards and which looked good, but they don't have the exact p/n (and those chinese sources are quite fickle anyway)
<whitequark>
this is probably still not the right keyword
<sb0>
don't bother with mechanical drawings in china, they never match what you receive
<whitequark>
the results are mostly from one seller, which probably used this idiosyncratic phrase
<whitequark>
i would expect many diverse racks to be returned
<GitHub-m-labs>
[artiq] gkasprow commented on issue #860: I did tests with Tom board where I replaced the HMC chip and now it loks.
<sb0>
whitequark, retiming won't necessarily move registers across clock domains, but it may make the output of what was a register the output of a combinatorial function, which has a longer "invalid output" time at each cycle than a register
rohitksingh_work has joined #m-labs
<larsc>
not only that, with a FF when you transiation from 1->1 you should never see a 0 at the output. With comb logic there might be a intermediate result where you have a 0 on output
<cr1901_modern>
rjo: Did the proxy bitstreams change _again_, or are there just issues w/ conda installing the old ones (> 6 months ago) with an openocd that operates on the "new" ones (< 6 months ago)? This has also been an issue w/ HDMI2USB.
<rjo>
just a conda versioning issue
<rjo>
at least from where i stand.
<rjo>
some old openocd versions get sorted before the newer ones.
<cr1901_modern>
Oh, HDMI2USB has the opposite problem, where a new openocd was given the old proxy bitstreams
<rjo>
i don't know what you are doing. are those conda packages?
<cr1901_modern>
Yes
<rjo>
that doesn't happpen anymore afaict.
<rjo>
next time you notice it, please file an issue and if you can, feel free to make an effort to resolve it.
<cr1901_modern>
To clarify, these aren't artiq conda packages, but HDMI2USB packages. I just wanted info since I had a similar issue in the past (> 3 weeks ago), and to see if maybe you had a solution. >>
<cr1901_modern>
In the next few weeks, if I find issues on the HDMI2USB end that I can dup on the artiq end, I'll file an issue/try to resolve it.
<rjo>
but also if the existing openocd/bscan-spi-bitstreams are causing issues in situations where you'd expect them to behave, it's a bug.
<rjo>
cr1901_modern: sure. there are old bitstreams wich only work with the old openocd and there are new ones which only work with newer openocd versions. our conda packages correctly resolve that dependency.
<sb0>
is it a good idea to put two Kasli with DRTIO in a single subrack and connect them with a crossover SATA cable?
<sb0>
or will that cause crossover SATA cable sourcing problems + 2 days of yak-shaving with GTPE2_COMMON and other xilinx idiocies?
<rjo>
sb0: that should definitely be tested. last time i looked for them i had no big issue finding crossover cables but now i can't seem to find any
<GitHub-m-labs>
[artiq] marmeladapk commented on issue #854: Ok, so it turns out that one sfp->ethernet converter we used was not working. I got link and transmission using various combinations of media converter, ethernet and sfp modules. (eg.: sayma -> sata -> sata-sfp -> sfp-ethernet -> media converter - sfp -> sfp -> kasli). https://github.com/m-labs/artiq/issues/854#issuecomment-382361393
<GitHub-m-labs>
[artiq] marmeladapk commented on issue #854: Ok, so it turns out that one sfp->ethernet converter we used was not working. I got link and transmission using various combinations of media converter, ethernet and sfp modules. (eg.: sayma -> sata -> sata-sfp -> sfp-ethernet -> ethernet -> media converter - sfp -> sfp -> kasli). https://github.com/m-labs/artiq/issues/854#issuecomment-382361393
<GitHub-m-labs>
[artiq] gkasprow commented on issue #854: Yes, and Kasli is receiving Ethernet frames correctly with link up led off :D. So we observe similar behaviour on both Sayma and Kasli. Link up - no Ethernet, link down - Ethernet works :D https://github.com/m-labs/artiq/issues/854#issuecomment-382363959
<GitHub-m-labs>
[artiq] gkasprow commented on issue #854: OK, I discovered that PHY on the board that works with Kasli is not configured by MMC but only by pin straps. Another one that shows link up but no traffic is configured by MMC. The PHY gets configured from time to time once per a few power cycles so it looks like floating pinstrap that is normally conntected to the FPGA. https://github.com/m-labs/artiq/issues/854#i
<sb0>
honestly, there are some sayma o that were avoidable (ultrascale, rtm, mmc/µTCA), but others like the hmc830 or those ethernet link problems are really baffling...
<marmelada>
imagine our confusion when it sometimes worked in some configurations (before we knew that one converter doesn't work)
<GitHub-m-labs>
[artiq] jbqubit commented on issue #967: @sbourdeauducq You're right, I didn't roll back ARTIQ when trying to revert back to my archived build from 20180413. The tests with 838.gfe689ab4.dirty were with matching version of ARTIQ. ... https://github.com/m-labs/artiq/issues/967#issuecomment-382470077
sb0 has quit [Ping timeout: 256 seconds]
rohitksingh has quit [Remote host closed the connection]
X-Scale has joined #m-labs
mumptai has joined #m-labs
mumptai has quit [Quit: Verlassend]
<rjo>
rqou: cheaper, smaller, designed for board-to-board, vertical
<rqou>
ah, that's kinda reasonable
<rqou>
(except for all the problems you seem to be having :P )
<rjo>
those have nothing to do with sata
<rjo>
other than "there was no cheap sata-to-sfp adapter"