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
rohitksingh has joined #m-labs
rohitksingh1 has joined #m-labs
rohitksingh has quit [Ping timeout: 276 seconds]
rohitksingh has joined #m-labs
rohitksingh1 has quit [Ping timeout: 255 seconds]
sb0 has quit [Quit: Leaving]
<ohsix>
whitequark: does 'ddcutil interrogate' find anything? my laptop is too old, and i've got no newer monitors around to try with the displayport adapter i have
<ohsix>
i know but there's some related stuff in there
<ohsix>
was hoping to correlate the i2c cmds with the eeprom or one of the vesa specs / code from linux, cuz filling out the structures is taking a lot m ore time than i thought it would :p
<whitequark>
the eeprom doesn't have any particular commands
<ohsix>
almost any information i can find in the problem area can be helpful for filling it out
<ohsix>
k
<whitequark>
ddcutil interrogate doesn't detect anything, it just bails
<ohsix>
check out 409DC4 in tcon.exe
<ohsix>
it's really busy with i2c-looking parameter values https://i.imgur.com/x0AQQe3.png (i2c_read/write may nto be that, only initial basis on one of the flags at another call site)
<ohsix>
will still go at it time permitting, i'm learning a lot on the dead ends :]
<ohsix>
can you define & edit structures and add them to references in binaryninja?
<davidc__>
ohsix: FWIW, I have the i2c read/write commands down with quite high certainty
<ohsix>
on what side?
<ohsix>
tcon calls the wrapper & the actual dpcd(?) commands are driver agnostic outside the wrapper, it just has 3 cases for each gpu and each import library
<davidc__>
should we move this somewhere else so as not to fill up #m-labs? :)
<ohsix>
sure, suggestions?
<davidc__>
#whitequarks-display ?
<whitequark>
there's a #whitequark
<whitequark>
er, ##whitequark
<whitequark>
ohsix: (define&edit) yes you can
<ohsix>
cool, only checked it out a little bit; the ir is pretty good
<whitequark>
rjo: regarding flterms not behaving, that's a well known bug in flterm
<whitequark>
and yes it's obnoxious but that part of asyncio is annoyin
<whitequark>
sb0: now openocd just hangs after:
<whitequark>
Info : clock speed 5000 kHz
<whitequark>
power cycle doesn't help
<sb0>
whitequark, did you press ctrl-c during an openocd run?
<whitequark>
yes
<whitequark>
is that bad?
<sb0>
yes
<sb0>
try again now
<whitequark>
nope
<whitequark>
still hung
<whitequark>
should I press ^C?
<sb0>
whitequark, again
<sb0>
pressing ctrl-c during openocd runs sometimes messes up the ftdi chip, and it hangs on subsequent runs
<whitequark>
excellent, it worked now
<whitequark>
sb0: hm, hangs on "continuing boot" now
<sb0>
yes, sometimes the runtime just hangs on sayma for mysterious reasons
<davidc__>
(the MPSSE engine can get desync'ed/wedged, and IIRC I remember being able to solve it with a USB reset. Not sure if it is the same behaviour you are seeing though)
<sb0>
was that involving serwb?
<whitequark>
hm
<whitequark>
I was reloading serwb, yes
<sb0>
okay. many of those crashes are serwb failures. not sure if it's all of them...
<whitequark>
ok, i finally loaded it
<sb0>
try recompiling the bitstream with sawg enabled and you will see why I keep talking of long/tedious testing cycles :)
<whitequark>
sb0: is ethernet supposed to work on sayma?
<sb0>
no
<whitequark>
oh.
<sb0>
we're going to use MII mode since the FPGA uses non-cc pins for the clocks with seems difficult with RGMII
<whitequark>
right, I've read all the comments
<whitequark>
just never quite connected the dots
<sb0>
but Greg's MMC firmware that puts the PHY in MII mode doesn't work, the PHY doesn't establish a link with either of my media converters
<whitequark>
sb0: ok this is absurd
<whitequark>
let's make AMC program RTM first
rohitksingh has quit [Ping timeout: 276 seconds]
<sb0>
µTCA crate arrived
<sb0>
whitequark, taking sayma boards offline to put them in said crate now
rohitksingh has joined #m-labs
<whitequark>
how ok
<whitequark>
*ok
<whitequark>
sb0: am I reading this right, is RTM FPGA configured hardcoded as master spi?
<whitequark>
M[2:0] = 001
<whitequark>
but also the schematic shows CCLK as an input
<sb0>
whitequark, I think Greg modified the boards
<sb0>
but Greg and Joe added it, and it controls many things on the board (power supply, JTAG, ethernet initialization), and generously seasons them with bugs
<sb0>
JTAG goes to another Rube-Goldberg machine, this SCANSTA112 chip
<sb0>
power on the crate -> 2/3 sayma configure from flash
<sb0>
power cycle -> 0/3
<sb0>
sigh...
<sb0>
this thing can do multicast?
<sb0>
I didn't even know that
<whitequark>
I didn't know multicast jtag exists
<whitequark>
that sounds like completely defeating the point of jtag
<sb0>
it says "multidrop", not "multicast"
<sb0>
afaik it's like a mux, it cannot do things like broadcast
<whitequark>
The 8 Address Inputs Support up to 249 Unique Slot Addresses, an Interrogation Address, Broadcast Address, and 4 Multi-Cast Group Addresses (Address 000000 is Reserved)
<sb0>
Greg added it to close the JTAG chain when the RTM is removed. of course, a simple tri-state CMOS buffer controlled by the RTM detection pin would have done the same, with fewer parts and without at least one MMC bug that did not miss the opportunity to manifest itself
<whitequark>
wtf
<whitequark>
that's an absurdly complex solution
rohitksingh-demo has joined #m-labs
rohitksingh-demo has quit [Client Quit]
<sb0>
the MCH is on 192.168.1.80
<sb0>
it needs a password that I don't have, though
<sb0>
ah it's the default
<sb0>
root/nat
<sb0>
hahaha the MCH doesn't find the ethernet link either
<whitequark>
sb0: what should I use for programming the RTM?
<whitequark>
write a simple serializer?
<sb0>
whitequark, yes
<whitequark>
CSR?
<sb0>
just software bitbang if that's fast enough (do the math) or some gateware
<whitequark>
oh, does the FPGA have internal pullups i can enable?
<whitequark>
bb-m-labs: force build --props=package=artiq-sayma_rtm artiq-board
<bb-m-labs>
build forced [ETA 18m56s]
<bb-m-labs>
I'll give a shout when the build finishes
<whitequark>
bb-m-labs: force build --props=package=artiq-sayma_amc-standalone artiq-board
<bb-m-labs>
The build has been queued, I'll give a shout when it starts
<sb0>
whitequark, looks fine from a cursory inspection. so bitbanging is too slow?
<whitequark>
sb0: not sure about the exact timings of the CSR bus but you can never configure the FPGA too quickly
<whitequark>
didn't took me long to write anyway
<sb0>
exact timings of the csr bus?
<whitequark>
well, how long does it take to do a csr write?
<sb0>
well yes, but it uses a bit of fpga resources (though we have plenty there) and more importantly when there is a bug the cycle is 30+ min of the vivado bloatware grinding its bits
<whitequark>
bb-m-labs: force build --props=package=artiq-sayma_amc-standalone artiq-board
<bb-m-labs>
build forced [ETA 12m42s]
<bb-m-labs>
I'll give a shout when the build finishes
<rjo>
sb0: Wow. You are using at least 2 MMCM and 6 BUFG for that single PHY? You don't seem to be bothered with resources at all. Is that all because of your fear of using the integrated features? Is the level of resource usage going to scale?
<sb0>
rjo, yes, non-BUFG xilinx routing doesn't work very well
<sb0>
this does bother me and tried without before, but after a number of obscure vivado error messages I gave up
<sb0>
they invented all sorts of limitations e.g. according to the doc a transceiver can drive a MMCM directly without a BUFG, but when you put more than one such MMCM then it won't route
<sb0>
and btw all those MMCMs and BUFGs are only there to work around transceiver limitations
<whitequark>
bb-m-labs: force build --props=package=artiq-sayma_amc-standalone artiq-board
<bb-m-labs>
build forced [ETA 12m42s]
<bb-m-labs>
I'll give a shout when the build finishes
<sb0>
in theory, the TX MMCM can be removed rather easily I think, if 1) routing the 125M clock to the fabric and the transceiver simultaneously works without bug or idiotic vivado behavior 2) if there is a component that lets you get 1 and 1/2 clocks (iirc some small clock buffers can do that)
<sb0>
DRTIO doesn't have this problem since we're using 20:1, which is directly supported by the transceiver hardware
<rjo>
using bufh for the tx side works fine here.
<sb0>
ok. you might be able to remove another BUFG between the transceiver and MMCM
<sb0>
and maybe turn the other one into another type of clock buffer
<rjo>
sb0: i don't get the reasoning behind preferring resource inflation and NIH over biting the bullet and using the integrated features. after all, you are copying black box wizard output anyway.
<sb0>
also, 1000BASE-X requires you to look at the running disparity of the 8b10b encoder, and if you use clock correction then you have to pull the integrated 8b10b stuff, then you have to adapt that to the proprietary FPGA du jour, debug it, etc.
<sb0>
and anyway: if we do 1000BASE-X again, we should use the IOSERDES, which is a sane design unlike the GTP, and an external CDR chip. then there are no ugly workarounds or resource waste...
<rjo>
that seems short-sighted. there is the CDR chip risk, inflated resource usage again, inflexibility (that SFP will be unusable for faster DRTIO).
<GitHub191>
artiq/master 3eb882b whitequark: conda: remove openocd version constraint....
<whitequark>
why do we even have version constraints in the first place? let's just recommend nuking the entire ~/miniconda and installing it from scratch every time.
<whitequark>
so what do y'all think about my idea to rewrite conda-build so it's not shit?
<cr1901_modern>
Then I say keep the boards in migen/misoc.
<whitequark>
because I seriously have no idea how to fix any of this
<cr1901_modern>
I'm surprised you didn't write your own package manager yet, tbh
<whitequark>
I did
<whitequark>
long ago
<whitequark>
I was like 16 and it worked far better than conda
<rjo>
whitequark: please don't do that.
<rjo>
whitequark: there are so many construction sites. can we consolidate them first?
<sb0>
how did that break anyway? did you delete the conda state? do you have a backup?
mumptai has joined #m-labs
<whitequark>
yes, I reinstalled it from scratch
<whitequark>
oh
<whitequark>
this one is easy, sec
<whitequark>
okay, next best thing
<whitequark>
cache the conda cache and kill its state every time and recreate it from scratch
<sb0>
how do i turn on the full power supplies to the AMCs in the nat crate? this seems to be the problem...
<sb0>
(ignoring IPMI)
rohitksingh-demo has quit [Quit: Leaving.]
mumptai has quit [Quit: Verlassend]
rohitksingh-demo has joined #m-labs
<rjo>
sb0: that was explained in the issues iirc
rohitksingh-demo has quit [Client Quit]
<sb0>
rjo, my PHY+microscope = 225 LUTs. xilinx phy alone = 518 LUTs. both with autonegociation. that's not a very fair comparison since vivado might simplify the data input in the microscope case, but I see no big issue here.
<sb0>
yes, the clocking is messy and inefficient, but blame that on xilinx, it's their fault if getting something as basic as a 10:1 SERDES is like that...
<sb0>
8b10b is actually very efficient to implement in LUTs
rohitksingh has quit [Quit: Leaving.]
<rjo>
sb0: simplify as in "remove all logic"? but my biggest concern is probably not luts but mmcm/pll/bufgh. how is that going to work when kasli is a drtio master and the other two sfp ports presumable also need resources? aren't you just creating much bigger issues for the future?
<sb0>
it can't remove all logic since there is still the autonegociation and some microscope probes
rohitksingh-demo has joined #m-labs
rohitksingh-demo has quit [Client Quit]
<sb0>
drtio uses 20:1 and that's 1 BUFG for both TX and 1 BUFG for each RX
<sb0>
(in minimum config)
<sb0>
MMCM is optional
<rjo>
ok. so there won't be any complaining about lack of resources when we do that?
<sb0>
no. we have a pretty big FPGA anyway.
<sb0>
MMCM in the RX synchronizer is also replaceable by manually placed/routed structures
<sb0>
that's actually a cleaner way of doing it, but requires digging deeper into vivado
rohitksingh-demo has joined #m-labs
<rjo>
i think it's going to be pretty full with all the rtio channels.
rohitksingh-demo has quit [Client Quit]
rohitksingh-demo has joined #m-labs
<sb0>
what are those RTIO channels made of?
<sb0>
TTL and SPI should not be expensive, especially with SED
<rjo>
go have a look.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<rjo>
with just 24 ttl rtio output channels i am at 30% (20k) LUTs used.
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
<GitHub-m-labs>
[buildbot-config] whitequark pushed 1 new commit to master: https://git.io/vNlgV
<GitHub-m-labs>
buildbot-config/master dd675b8 whitequark: Work around conda bug with --output.
bb-m-labs has joined #m-labs
stekern has joined #m-labs
rohitksingh-demo has quit [Quit: Leaving.]
<hartytp>
rj0: where are your Sayma photos?
<hartytp>
not on the wiki afaict
<rjo>
hartytp: in the repo
<hartytp>
thanks
<key2>
rjo: I modified jtagspi.c in order to add the command to set QE bit. Now it works on flash other than micron.
marmelada has joined #m-labs
<hartytp>
may have found why my JSED links fail....
<marmelada>
hey, everyone
<marmelada>
to test sayma amc with artiq, which gateware should I flash?
<marmelada>
misoc_master_sayma_amc?
<marmelada>
and can I do so with artiq_flash?
<rjo>
key2: ack. what forces you to use the hardware manager?
<rjo>
hartytp: what is it?
<hartytp>
see git hub
<hartytp>
no decoupling on DACs...
<hartytp>
caps not populated properly
<hartytp>
QC failure in a big way
<rjo>
hartytp: that's an erratum by greg. manual work
<rjo>
the footprint is wrong. the decoupling is effectively halved now.
<hartytp>
well, my board is v different to the photos you posted
<hartytp>
looks like the manual rework wasn't done on my board
<rjo>
hartytp: always check with the errata.
<hartytp>
I know its on the errata, but thought Greg had already done it
<hartytp>
anyway, fixing now will then retry
<hartytp>
sec
<rjo>
hartytp: looks exactly like greg wanted it to look.
<rjo>
hartytp: *don't* place them on the footprints. that doesn't help.
<rjo>
marmelada: yes.
<rjo>
marmelada: load the rtm first manually
<rjo>
sb0: ^^ could you describe the procedure?
<sb0>
plugged in Florent's board. it is different than mine. no 1.8V bug so far + serwb works reliably. also a new bug: the board won't power up unless the AMC/SATA adapter is plugged in
<rjo>
sb0: i remember that. same when i had it. that's just some population option or mmc thing. forgot which. greg mentioned it.
<sb0>
so Florent's board is sayma3 now. the µTCA chassis power is still borked.
<sb0>
sayma3 is independently powered
<key2>
rjo: the fact that only hardware manager can put QE bit
<key2>
rjo: without hardware manager, if you burn your file in a non micron flash, your flash won't start in QSPI but simple spi...
<key2>
rjo: and of course the FPGA won't work
<rjo>
key2: the flash boots up in the state set by its non-volatile options. from factory they are all fine and openocd should work. who messed that up on your flash? the hardware manager?
<sb0>
marmelada, and for artiq_flash it's like with the kc705, except that there is this bug https://github.com/m-labs/artiq/issues/890 that you can work around by using -d, --srcbuild or editing artiq_flash.py
<key2>
rjo: no by default only micron are in quad mode
<key2>
rjo: macronix are by default in single mode
<rjo>
key2: works fine on kasli. we have a spansion flash and it is happily doing fast io.
<hartytp>
why are they on the footprints on your photo?
<rjo>
hartytp: they are exactly as off-centered as yours.
<key2>
rjo: that shows that hardware manager does have a role such as detecting if you are using a 1x or 4x spi and set correctly the QE bit when needed
<key2>
rjo: it also states in the datasheet "QE bit. The Quad Enable (QE) bit, non-volatile bit, while it is "0" (factory default)..."
<rjo>
key2: exactly. don't let that change. it's not helping.
<rjo>
hartytp: yes.
<hartytp>
k
<rjo>
hartytp: well. that board has also been called "florent's" and is now in HK with _florent_ and sb0.
<key2>
rjo: "0" = SIMPLE spi
<key2>
rjo: of course I want it to change :)
<key2>
rjo: otherwise we boot 4x slower
<key2>
rjo: "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"
<rjo>
key2: no. read the datasheet. there are other ways to get fast reads.
<marmelada>
however I'll try that now, never hurts ;)
<marmelada>
ok, now it cannot find config files, so that must be it
<sb0>
what config files?
<marmelada>
cpld/xilinx-xc7.cfg
<key2>
marmelada: you're under linux or windows ?
<key2>
ha root...
<key2>
linux sorry
<marmelada>
how can I check if rtm really is programmed?
<sb0>
you should see openocd messages telling you of successful FPGA detection, followed by "loaded bitstream"
<marmelada>
bc it has errors during init, but loads gateware
<sb0>
what errors?
<marmelada>
ok, so it wasn't succesfull
<sb0>
what errors?!
<marmelada>
Error: JTAG scan chain interrogation failed: all zeroes Error: Check JTAG interface, timings, target power, etc. Error: Trying to use configured scan chain anyway... Error: xc7.tap: IR capture error; saw 0x00 not 0x01 Warn : Bypassing JTAG setup events due to errors
<sb0>
okay. yes, that's a sayma hardware bug
<sb0>
try power cycling the board and/or replugging the USB connector
<sb0>
is your 1.8V LED on?
<marmelada>
yes
<marmelada>
power-cycling (3x) didn't help, could this be usb cable?
<marmelada>
I saw that you discussed this
<marmelada>
though same cable worked with kasli on 25MHz
<sb0>
did you also unplug and replug the USB cable?
<marmelada>
yes
<sb0>
part of sayma is USB-powered and subject to bugs that persist when the main power is cycled
<marmelada>
ok, now without unplugging the cable it worked
<sb0>
okay. good to see that typical sayma intermittent bugs also happen at WUT.
<marmelada>
ok, we're investigating it
<rjo>
sb0: why is CSR_BASE = 0x60000000 < 0x80000000 in the cached region now? is that useful?
<sb0>
everything is both in the non-cached and cached regions
<sb0>
but CSRs are always accessed with bit 31 set
<rjo>
sb0: CSR_BASE is used nowhere.
<rjo>
i.e. this is ok.
<marmelada>
sb0: we have now sayma in this "failing" state
<marmelada>
and in /dev I see ttyUSB0 before trying to flash and after trying it disappears
<marmelada>
is this expected, or should ttyUSB0 always be there?
<rjo>
marmelada: no. ttyUSB0 disappears on the first openocd invokation. that's desired.
<marmelada>
ok
<sb0>
marmelada, by the way, do you have a µTCA crate? JTAG seems to systematically fail when the sayma is inserted in there. I'm unsure if this is due to solely to a power configuration issue as Greg believes
<travis-ci>
batonius/smoltcp#118 (master - cb5be48 : whitequark): The build passed.
<hartytp>
marmelada: great! Once you get that up and running, can you try running the DACs with the external 1.2GHz clock (need to change the mux settings and rebuild the gateware)
<hartytp>
would be good to see if this works on your board
<sb0>
hartytp, how are you driving that external clock differentially?
<hartytp>
sb0: what do you mean?
<sb0>
how did you generate a 1.2GHz differential clock?
<hartytp>
synth
<hartytp>
single ended
<hartytp>
50R terminate other SMP
<hartytp>
that's fine (see ADCLK948 data sheet)
<sb0>
ok thanks
<sb0>
for the 50R termination I guess I can solder a SMD resistor onto the connector pads on the RTM
<sb0>
_florent_, ^
<rjo>
who has the clock mezzaine that i added the pigtail to?
<marmelada>
sb0: I think we have one utca crate
hartytp has quit [Ping timeout: 260 seconds]
<rjo>
marmelada: while i have you here, could you give me a quick update which boards have been sent to technosystem? urukul v1.1, dio_bnc v1.2, dio_sma v1.2, zotino v1.1?