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
mumptai has quit [Quit: Verlassend]
rohitksingh has joined #m-labs
rohitksingh_work has joined #m-labs
<sb0>
whitequark, can you fix the release-3 makefiles?
futarisIRCcloud has joined #m-labs
<GitHub17>
[artiq] sbourdeauducq commented on issue #860: @gkasprow @jbqubit Can you install ARTIQ, try this on your boards, report whether your HMC830 works well, and do some oscilloscope testing of the kind @hartytp is suggesting?... https://github.com/m-labs/artiq/issues/860#issuecomment-354949785
<sb0>
bb-m-labs, force build --props=package=artiq-sayma_rtm artiq-board
<bb-m-labs>
build forced [ETA 18m47s]
<bb-m-labs>
I'll give a shout when the build finishes
<sb0>
bb-m-labs, force build --props=package=artiq-sayma_amc-standalone artiq-board
<sb0>
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>
rjo, among the obnoxious properties of xilinx jtag cables, they need fxload firmware. did you set that up already? is vivado dealing with that by itself and without bugs or is it still the same mess as in ISE times?
<rjo>
sb0: i set it up but disabled it again because it crashes the cable. /etc/udev/rules.d/99-xusbdfwu.rules
<rjo>
sb0: how would this happen on kasli (with spi flash): ROM_BASE=0x00af0000, FLASH_BOOT_ADDRESS=0xb40000 and ROM_SIZE=0x510000 ?
<rjo>
is that related to whitequark's rewrites?
<sb0>
what is the problem exactly?
<rjo>
sb0: i'd expect the spi flash to be at 0x0
<sb0>
isn't there the bitstream before?
<rjo>
that doesn't move the flash around.
<sb0>
but it moves the bootloader address
<sb0>
FLASH_BOOT_ADDRESS is the runtime
<sb0>
ROM_BASE would be the bootloader I suppose
<sb0>
does that explain it?
<rjo>
a bit weird to adjust ROM_SIZE but well.
<sb0>
*_BASE and *_SIZE are used to generate the linker script, at least originally
<rjo>
yes. but wouldn't it be nicer to clean those names up? ROM_SIZE=16<<20, ROM_BASE=0x0, BIOS_ADDRESS=0xaf0000, FIRMWARE_ADDRESS=0xb40000
<sb0>
so it made sense to shrink the section by the size of the bitstream
<sb0>
yes, agreed
<rjo>
sure. that's fine. can't the linker script be told that there is already stuff in 0-0xaf0000?
<sb0>
maybe
<sb0>
it should also be told that there is stuff after FIRMWARE_ADDRESS
<rjo>
yes.
<rjo>
maybe just generated three properly named rom regions for clarity
<sb0>
since you're at it, we may want to add a section after the firmware for the RTM FPGA bitstream
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<rjo>
i am not at it ;)
<whitequark>
regarding linker scripts, I agree, we should ideally have more automation in that
<whitequark>
rightnow it needs annoying adjustments
<sb0>
whitequark, do you want to refactor this code and add support for flashing another bitstream (also using the FBI format, and loaded into the RTM FPGA by the AMC firmware) after the firmware?
<sb0>
though we may want to do that after 3.2
<sb0>
also maybe artiq_flash should do the fbi encapsulation on-the-fly, for both runtime and rtm bitstream
<rjo>
xc3sprog and the cable don't go too well together. you'll need to reload the cable firmware (using fxload and the correct usb device) from time to time.
<sb0>
I wrote that code, so I should be relatively productive with bringing it up. will add some microscope probes etc.
<rjo>
/dev/serial/by-id/usb-FTDI_Quad_RS232-HS-if01-port0 is the uart
<sb0>
rjo, I'll add some cooling to sayma tonight. that will hopefully fix the 1v8 issue. do you want to look into JESD?
<rjo>
i'll wrap up initial support for Urukul-AD9910 first and then look at jesd. but i am at a loss what i can do there. if the current code does not output the ramps I added when SAWG is disabled, it is not SAWG's fault.
<sb0>
rjo, PRBS?
<rjo>
i thought that was already working.
<sb0>
rjo, have you tried the ramp code? I didn't
<rjo>
you should really documented how all the things are set up: scope, probes, allakis, saymas. i have no idea what the lab looks like right now.
rohitksingh1 has quit [Read error: Connection reset by peer]
<sb0>
rjo, so there is one allaki on "AFE Channel 1" with the two outputs going to the first two scope channels
<rjo>
sb0: no. i didn't say i'd implement it. you said that prbs is waiting on florent ;)
<rjo>
sb0: and you checked that the rf switches and the attenuators are set to something useful?
<sb0>
rjo, note that I am not setting up the RF attenuator - I'm assuming that whatever the attenuation is should not kill the signal completely with the scope set to a sensitive range (10's mV/div)
<rjo>
the reset condition for the attenuators is -31.5 dB.
<sb0>
rjo, the RF switches are supposed to be set up correctly
<rjo>
so that's more like few mV
<sb0>
hm, ok, then it needs to be set up, the noise is higher than that
<sb0>
I did the math for -31.5dB, but apparently I was wrong
<rjo>
your math was right. there should be some 20-30 mV rms
<rjo>
i forgot the preamp
<rjo>
sb0: and if you test the phy, you can check the other end link status with snmpget -cpublic -v2c oscar IF-MIB::ifOperStatus.9
<sb0>
okay, thanks
<sb0>
are we doing lockfiles?
sb0 has quit [Quit: Leaving]
<rjo>
no.
<whitequark>
sb0: I want the new bootloader to have the notion of a partition table
<whitequark>
actually, can we do something like this...
<whitequark>
have a partition table defined with a proper format (with /generated/part.{rs,ld} etc) in misoc, once, and then have it as a single source of truth for the linker, the bootloader, whatever else needsto access that
<whitequark>
ack on doing fbi encapsulation on the fly
<GitHub154>
[smoltcp] pothos opened issue #111: FIN within the window closes the connection but the sequence number indicates unseen data https://github.com/m-labs/smoltcp/issues/111
<whitequark>
sb0: ^ that should go into 3.2 too maybe
<GitHub75>
[smoltcp] pothos commented on issue #111: Yes, just meant that it would be consistent with the assembler to remember it for a faster acknowledgement in the end. But for the beginning it makes sense to handle it the same way as those not in the receive window i.e. `segment_in_window = false`? https://github.com/m-labs/smoltcp/issues/111#issuecomment-354997463
<GitHub177>
artiq/release-3 3ba82cf whitequark: firmware: clean up makefiles.
Gurty has joined #m-labs
Gurty has quit [Changing host]
Gurty has joined #m-labs
<GitHub142>
[smoltcp] pothos opened pull request #112: Do enter CLOSE-WAIT if FIN arrives before data (master...reordered-fin-keeps-open) https://github.com/m-labs/smoltcp/pull/112
<sb0>
that would mean the design is quite fragile...
<rjo>
why? it's meant to be in the howling uTCA crate.
<sb0>
would it still work with a FPGA loaded with plenty of SAWG channels and all JESD links running at maximum speed?
<rjo>
that's the question.
<sb0>
the threshold temperature seems also surprisingly low, nothing on the AMC gets particularly hot
<sb0>
if it were those rtm regulators i'd understand, but they're not the problem...
<rjo>
weird. is there really nothing that feels hot on the AMC?
<sb0>
i'll double check. maybe i should invest in one of those flir cameras. would also spare me from burning mosfets etc. in other projects...
<sb0>
if it's just a small SMD part that gets hot, it can be hard to find
hartytp has joined #m-labs
<hartytp>
sb0: "that would mean the design is quite fragile... " not really. If it really is the thermal issue then nothing we've seen so far suggests that this is an issue with Sayma
<hartytp>
a little forced air cooling can make a huge difference.
<hartytp>
IIRC, Greg already posted some IR images of Sayma, showing the board temp and was happy that they agreed with simulations and that it would work.
<hartytp>
That was with cooling on.
<hartytp>
So, AFAICT, there doesn't seem to be any cause for concern yet
<hartytp>
PS on a related note, it would be *great* if you could tone down the whining about Sayma considerably. The vast majority of the features on that board work perfectly, even if a few of the silly mistakes have wasted your time.
<hartytp>
The whining starts to seem particularly silly once it turns out that at least some of the things you're bitching about are simple user error
<sb0>
hartytp, that's not "simple user error", nothing on the AMC really seems to overheat without a fan
<sb0>
hartytp, how's the hmc830?
hartytp has quit [Ping timeout: 260 seconds]
hartytp has joined #m-labs
<hartytp>
Those things burn off a lot of heat, and are only designed to work with a fan, so it isn't a surprise if they don't work without one. That's why Greg used on in all his tests.
<hartytp>
I would have suggested thermal issues long ago, but I assumed that you were already using a fan (it didn't occur to me that you wouldn't have tried this)
<hartytp>
But, anyway, my frustration with the level of constant whining is separate to the thermal issue (if that really is what's happening here)
<hartytp>
the bitching is unproductive
<sb0>
well as I said, nothing gets particularly hot on AMC, so I'm still surprised
<hartytp>
and insulting to those who put work into it
<hartytp>
the level of bugs we've found is pretty low at the moment
<hartytp>
do you think the first KC705 they built worked?
<hartytp>
(e.g. the 10GBPS links all seem to work, which is really impressive -- welcome to the world of impedance-matched vias)
<hartytp>
and, even on things like the ethernet, it's frustrating to here you bitching. AFIACT, you were paid as a design consultant on these boards. So, even though the ethernet wasn't designed the way you would ideally have liked, you should still take some responsibility for simple mistakes like clock-capable pins going missing
<hartytp>
you asked why I didn't listen to your warnings about the AD9914. The reason is because you bitch about everything.
<sb0>
my suggestions regarding ethernet were thoroughly ignored, so...
<hartytp>
Well, there were reasons why Greg didn't want to do the ethernet the way you originally wanted (it wouldn't have worked for other non-ARTIQ users of Sayma IIRC). But, having your first idea rejected doesn't mean that you get to wash your hands of it completely
<hartytp>
again, you could have spotted the missing cc pins as well as anyone else. And, if that wasn't your job, then what were you paid for.
<sb0>
also I don't bitch about everything. the si5324 for example is a well designed chip and works perfectly.
<sb0>
but those are rare
<hartytp>
not everything but a lot. How much traffic on this channel could be replaced by a script that generates messages like "FFS {Sayma, Vivado, ...} is a {trash-fire, pile of garbage, disgusting priprietary bs, ...}"
<sb0>
the clock-capable pins on ethernet are only one part of the problem, there's also this sata connector (which I'm happy that greg is fixing properly now, with the PCB adapter), the phy not working in mii mode, and the mmc reflashing issues
<hartytp>
sure. But, my point is that at least some parts of the problem can/should have been spotted by you during design reviews in your roles as a paid consultant.
<hartytp>
I'm not generally into assigning blame for these kinds of things, but I get frustrated when you're constantly complaining about Greg/Joe's mistakes without showing any acknowledgement that you worked on this too
<hartytp>
or, how well Sayma generally seems to work if you take out those 3-4 small ish mistakes. If someone who'd never heard of Sayma was following this channel they'd think it was some complete POS which was complete junk. That's not close to being the case IMO
<sb0>
when did I say that Sayma is a {pile of garbage, disgusting priprietary bs, ...}? I do say that regularly about vivado, yes, but not sayma
<hartytp>
Anyway, rant over, just please do me a favour and tone the complaining down a bit.
<hartytp>
Well, look back in the logs. Not those words exactly. But, take for example, 2017-12-23 where your comments lead whitequark to conclude that "Sayma sounds like a complete disaster". Anyway, that's enough time spent on this. Basically, you're being paid a lot of money to work on this, so please try to act a bit more professionally -- the bitching is annoying people
hartytp_ has joined #m-labs
<hartytp_>
sb0: you asked re HMC830. I haven't looked at that again. I'm not planning to look at until someone does some sanity checking with a scope. I'll probably do that next week if no one does it before then
hartytp has quit [Ping timeout: 260 seconds]
hartytp_ has quit [Client Quit]
hartytp has joined #m-labs
<hartytp>
the "locked indicator" is only binary, so it doesn't give one enough information to successfully debug this. It will be much much quicker once we have a scope trace and can quickly see things like: is the loop oscillating? is the input clock okay? is the output frequency roughly correct (if it's far off then the auto-cal on the step-tuned VCO isn't working properly)? Do the SPI transactions look okay? etc etc
<hartytp>
without access to those kinds of diagnostics, we're in the dark so it could take quite a while to figure this out.
hartytp has quit [Client Quit]
<sb0>
yeah, sure, so far you complained more about the hmc830 ("these chips are just full of undocumented test features", "not so surprising [it doesn't work] given how ambiguous some parts of that data sheet are") than I did...
hartytp has joined #m-labs
<sb0>
anyway let's just get this thing to work
<hartytp>
well, that's not really how that comment was intended to be read (hopefully that's clearer when one reads the rest of the comment). I like that chip a lot, and so far don't think we made any design mistakes to do with it
<hartytp>
my point was just that I'm not surprised that I didn't get it right first time from reading the data sheet. Some debugging is needed, but when isn't it
<hartytp>
the data sheet is a bit unclear in parts, but when aren't they for these kinds of chips?
<sb0>
I'm also not excluding user error, it could be my clock generator again. the trace looked a bit noisy on the scope when I looked at it, and this needs investigation
<sb0>
having multiple hardware setups/testers would also help figuring out this sort of error
<sb0>
the si5324 datasheet is pretty clear and this chip works with little debugging
<hartytp>
well, I'm not drawing any conclusions until I've seen some better diagnostics such as scope traces.
<hartytp>
Yes, more people working on the project would definitely speed it up
<sb0>
Si also make some sensible design decisions, e.g. power up everything by default, unlike many chip designers
<_florent_>
sb0: i'll do some tests probably tomorrow with hmc830 and my simple design that control it over uart. It will be faster than with full artiq design.
<sb0>
I received another 100MHz generator yesterday, which does produce a clean trace (in another setup, with another scope), will look into that soon...
<hartytp>
"little debugging" I'd argue that so far the HMC830 has had very little debugging -- no one has put a scope on it, which should be the first step. But, yes, the HMC830 chips aren't the most user friendly, as they have left in all the debugging features that most users will never use and they didn't document them so well
<bb-m-labs>
build #1906 of artiq is complete: Failure [failed python_coverage_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1906 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
<hartytp>
_florent_ sounds good. Do check that the loop filter will be stable in the configuration you use (CP, divider settings). I can send you a model you can play with if you want
<_florent_>
hartytp: yes sure, any information you think can be useful is welcome
<hartytp>
sb0 can you send me _florent_'s email and I'll pass him on Weida's model that can be used with the ADI PLL simulator
<hartytp>
sb0: :( (re Sayma1). Hopefully Greg will finish the diagnostics for that Exam SMPS soon and then this will be easier to track down for sure.
<hartytp>
PS To be clear: your contributions to all of this are very welcome (and often relied on) just please try to keep them a little more constructive/proportionate
<GitHub106>
[artiq] hartytp commented on issue #727: Did you try asking about this on the ADI forums? They might be able to tell you if it's expected behaviour for these chips (or a known bug). They're generally pretty helpful, so definitely worth a post.... https://github.com/m-labs/artiq/issues/727#issuecomment-355099414