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
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale has joined #m-labs
<GitHub52>
[artiq] sbourdeauducq commented on issue #854: Why do you insist on waiting for the FPGA config to be done before setting up the PHY? This adds complexity in a system that is already extremely fragile and buggy. https://github.com/m-labs/artiq/issues/854#issuecomment-357108609
<GitHub87>
[artiq] gkasprow commented on issue #854: I don't remember exactly, but had an impression that PHY didn't wanted to work in RGMII mode without valid TX clock. I wrote about it in some of issues... https://github.com/m-labs/artiq/issues/854#issuecomment-357110540
<GitHub174>
[artiq] sbourdeauducq commented on issue #888: > I just noticed the mention of the artiq-dev package in the instructions for version 3 I didn't realize those were available, would that be enough to build the gateware with an updated FIFO depth?... https://github.com/m-labs/artiq/issues/888#issuecomment-357120968
<GitHub143>
[artiq] sbourdeauducq commented on issue #888: > We need to build a modified version of the gateware with the output FIFO depth increased to 1024. We did this for ARTIQ version 2 and it reduced the number of underflow errors we we're getting. We tried running a few experiments using the gateware provided in the ARTIQ version 3 conda packages but that resulted in underflow errors that did not occur using the version
<GitHub34>
[artiq] sbourdeauducq commented on issue #854: But this is not an issue with MII, where the PHY is always generating clocks, and this would eliminate another potential source of bugs. https://github.com/m-labs/artiq/issues/854#issuecomment-357125597
<GitHub58>
[artiq] sbourdeauducq closed pull request #889: firmware: make read leveling robust for KUS SDRAM (master...robust-kus-read-leveling) https://github.com/m-labs/artiq/pull/889
cedric has quit [Read error: Connection reset by peer]
cedric has joined #m-labs
cedric has quit [Changing host]
cedric has joined #m-labs
rohitksingh_work has joined #m-labs
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
<GitHub5>
[artiq] sbourdeauducq commented on issue #854: This new firmware exhibits exactly the same bug as before: the link is up at power-up, then it goes down and does not go back up when the FPGA is configured. Please keep things simple and configure the PHY once at startup and regardless of the state of the FPGA.... https://github.com/m-labs/artiq/issues/854#issuecomment-357144317
<GitHub81>
[artiq] sbourdeauducq commented on issue #854: This new firmware exhibits exactly the same bug as before: the link is up at power-up, then it goes down and does not go back up when the FPGA is configured. Please keep things simple and configure the PHY once at startup and regardless of the state of the FPGA. We do not need Ethernet access to the MMC for now, you can implement it and debug it later.... https://gith
<GitHub163>
[smoltcp] hjr3 commented on pull request #116 aa52656: i thought about doing this, but it will cause a lot of change in the parser. before trying to parse a ipv4 address, i would have to `self.accept_char(b':')?;`. should the parser fail, the check down below looks ahead of `b':'` and errors if one is not present. i would also have to remove the `self.accept_char(b':')?;` in the `None` case for the double colon
larsc has quit [Remote host closed the connection]
wolfspra1l has quit [Read error: Connection reset by peer]
<GitHub25>
[artiq] jordens commented on issue #888: And the documentation also clearly states that that approach to installing from source is irrelevant to you. Just use the conda packages pulled in by artiq-dev. https://github.com/m-labs/artiq/issues/888#issuecomment-357165688
rohitksingh_work has quit [Read error: Connection reset by peer]
lars_ has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
lars_ has joined #m-labs
<rjo>
sb0: the power supply was off. don't know whether the OCP/OVP tripped (set to 16V, 2A, while the supply is at 12V, 1.6A) or whether there was some power glitch. The other channel had also turned off i.e. I'd gravitate towards suspecting the latter.
<rjo>
sb0: kasli is back up. please don't try to use the xilinx cable. i need that for urukul.
<rjo>
sb0: if it helps you i can connect SFP0 to SFP2 either by copper (SFP-to-SFP hard link) or by 1000Base-BX
<rjo>
sb0: and there is a networked DP832 at 'hoots' that powers kasli, on channel 1, if you need to power cycle it.
<sb0>
keep it on the switch
<sb0>
does your switch have diagnostic modes that let you see info about the bare received signal?
<rjo>
whitequark: are you using the performance counters in the kernel cpu or can i disable them? they lead to terrible timing paths with ~23 levels of logic which fail on kasli.
hartytp has joined #m-labs
<hartytp>
sbo, _florent_: looking at HMC830. Output is garbage; very noisy and roughly at 750MHz. Buest guess is that the VCO auto cal hasn't worked.
<hartytp>
Will confirm and get back
<_florent_>
hartytp: ok thanks
<sb0>
hartytp, good, thanks for looking into this!
<sb0>
hartytp, should I send you a sayma amc so you can test drtio soon?
<GitHub58>
[smoltcp] phil-opp opened pull request #117: Return `UdpSocket` from `UdpSocket::new` (instead of `Socket`) (master...patch-1) https://github.com/m-labs/smoltcp/pull/117
<sb0>
rjo, how many hp are kasli, urukul, and ttl-sma?
<sb0>
rjo, tried with the new vivado on the HK computer?
<hartytp>
good 100MHz input clock at HMC830: check
<rjo>
4 each
<rjo>
everything is either 4 or 8. only stuff with bnc is 8.
<hartytp>
VCO tuning sensitivity is about 10MHz/V. Frequency error is 250MHz, so tuning voltage that would be needed to lock would be about 25V. So, the VCO must be on the wrong range. So, this does look like a programming issue
<hartytp>
(no, DAC clock should be 2.4GHz, not 1GHz, so the frequency error is worse than that. In any case, definitely not the correct VCO)
<rjo>
sb0: vivado 2017.4 gives the same timing failure.
sb0 has joined #m-labs
<sb0>
the GTP RX still refuses to work
<sb0>
sigh
<sb0>
data is still stuck at 0 or 0x7805c
<sb0>
whitequark, I found out that Andrew wrote a 1000BASE-X core for artix7 that he claims is working. can you integrate it with misoc as a backup plan, in case the xilinx transceiver trash continues to act up?
<sb0>
in simulation rx_data is also stuck at zero, which would be straigforward to debug if the xilinx fuckers did not encrypt their idiotic IP
<sb0>
I had the keys somewhere (they were leaked) but I cannot find them atm
<hartytp>
_florent_, sb0 can you send me binaries for sayma_test to save me from building it myself?
<sb0>
hartytp, what is sayma_test? florent's repo?
<sb0>
I don't have anything installed (except vivado, which I believe you also have) to compile it...
<hartytp>
yes florent's repo
<hartytp>
also needs litex, but I can install that. Just wanted to save some time by avoiding a build
<sb0>
...and of course, problems like rx_data stuck at 0 would have been avoided altogether if the transceiver RX were a dumb deserializer with a CDR, as it should be
<sb0>
now the only two debugging techniques I can think of is 1) decrypt the secureip bullshit or 2) simulate one of their cores, mix it with my code, then bisect which of their dozens of undocumented parameters is set wrong
<hartytp>
_florent_ can you send me binaries to save time
<sb0>
hartytp, btw do you have a copper SFP cable for testing DRTIO on Sayma?
<hartytp>
IIRC yes, but will have to check
<hartytp>
can buy one in any case
<hartytp>
okay: HMC830 SPI transactions look fine. Dumped the default contents of the registers before and programming
<hartytp>
all as expected
<sb0>
hartytp, and SATA/SFP adapter for Ethernet?
<sb0>
and media converter?
<sb0>
I wonder if you'll get a link with Greg's MII firmware
<sb0>
by the way, you can flash this MMC using a cheap Olimex cable
<sb0>
with openocd and linux
<sb0>
or no cable at all using the UART bootloader but I don't know how this works. right now this feature is just causing bugs on my boards...
<hartytp>
okay, I think I might know what the problem is
<GitHub143>
[smoltcp] dlrobertson commented on pull request #116 3ca5ff2: Might be more readable to just use `Address([values])` since you have to shift some bits. Feel free to ignore this comment. Just a nit. https://github.com/m-labs/smoltcp/pull/116#discussion_r161253889
<GitHub81>
[smoltcp] dlrobertson commented on pull request #116 3ca5ff2: Actually my example was bad. `0:0:0:0:1:FFFF:192.168.1.1` is still parsed as a correctly formatted IPv4 mapped IPv6 address, but it shouldn't be. I think we need to check to ensure that the value of the head part contains only zero. https://github.com/m-labs/smoltcp/pull/116#discussion_r161256453
<hartytp>
a couple of observations about the HMC830:
<hartytp>
1. The soft reset seems to be *very* slow. The data sheet says that 0x00 must be set to 0x00 for normal operation. But, this bricks the chip unless there is a long delay between write(0x00, 0x20) and write(0x00, 0x00)
<ohsix>
whitequark: are there any restrictions on how you ultimately want to use what you find? like wanting to be able to do it via usb and not ddc
<ohsix>
can't work on it more until the weekend, but what i've done is come from the displayport side looking for incidental documentation on the chips and displayport to get register locations and order of operations; most of the 'code' stuff i found looking around was initializing some string tables and takes a ton of time to get to the useful spots
<ohsix>
some of the stuff is standardized but haven't found definitive indication that cabc is at a not-vendor-specific location, there's some code in the kernel for intel stuff to change it
<GitHub26>
[smoltcp] whitequark commented on pull request #116 33a30de: Um, I am against depending on slice_patterns. slice_rotate is *almost* stable. slice_patterns is a complex feature that's basically abandoned. https://github.com/m-labs/smoltcp/pull/116#discussion_r161297714
mumptai has quit [Remote host closed the connection]
<ohsix>
whitequark: k, it reads those from the ini file in the dell update, and the keys in the ini reader, it's easy to find the reference to the constructor for the table; the hard part is finding references to the table
<key2>
anyone using openocd to flash a bin file into a NOR FLASH here ?
<key2>
I am experiencing something weird, when having a blank flash, if I use openocd, it will write the bitstream but it won't work. If I use impact with the same bin file, it works. from then, if I use openocd it works too. sounds like impact is adding or doing something openocd doesn't, and as long as it's not done, it won't boot on flash
<key2>
having a flash that only works if hardware manager of xilinx writes on it
<key2>
?
<key2>
I am trying with 3 different boards and have the same behavour
<rjo>
hardware manager?
<key2>
it's a persistent bit in the flash that tells if if it's working in 1x or 4x
key2_ has joined #m-labs
<key2_>
QE bit. The Quad Enable (QE) bit, non-volatile bit, while it is "0" (factory default), it performs non-Quad and WP#, RESET# are enable. While QE is "1", it performs Quad I/O mode and WP#, RESET# are disabled. In the other word, if the system goes into four I/O mode (QE=1), the feature of HPM and RESET will be disabled
<key2_>
rjo: so I guess I need to find a way to read/write the status reg of the flash
<rjo>
if you can't reset the flash or keep your fingers from that xilinx tool, probably.
<GitHub87>
[smoltcp] dlrobertson commented on issue #110: Based `SystemTime` conversions off of `UNIX_EPOCH`. I also added `Instant::now`, removed the use of `checked` functions, and removed the `MILLIS_PER_SEC` constants. https://github.com/m-labs/smoltcp/pull/110#issuecomment-357377342
<GitHub1>
[artiq] jbqubit commented on issue #856: For the logs just reported I built .bit for RTM and amc stand alone. And flashed using ```~/github/m-labs/sinara$ artiq_flash --srcbuild ./misoc_standalone_sayma_amc -t sayma```.... https://github.com/m-labs/artiq/issues/856#issuecomment-357377828