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
<whitequark>
sb0: looks like I can't work on the camera right now, so I'll tackle #845 for the time being
<davidc__>
FYI re: https://github.com/m-labs/sinara/issues/444 - I've had issues with crosstalk on the JTAG side of FTDI cables (basically, noise on TCK as other lines transition resulting in double-clocking)
attie has quit [Remote host closed the connection]
attie has joined #m-labs
[X-Scale] has joined #m-labs
X-Scale has quit [Ping timeout: 256 seconds]
[X-Scale] is now known as X-Scale
attie has quit [Ping timeout: 246 seconds]
attie has joined #m-labs
rohitksingh_work has joined #m-labs
attie has quit [Ping timeout: 256 seconds]
attie has joined #m-labs
sb0 has joined #m-labs
<sb0>
rjo, what is the plan for sampler and zotino development? can I or whitequark help?
sb0 has quit [Client Quit]
attie has quit [Ping timeout: 264 seconds]
attie has joined #m-labs
mumptai has joined #m-labs
Hartytp_ has joined #m-labs
<Hartytp_>
Sb0: Zotino is done (contract paid iirc)
<Hartytp_>
Needs trivial port to Kasli which I'll try to push today
<Hartytp_>
I'd *really* appreciate it if you could help _florent_ get the sdram on sayma working
<Hartytp_>
As absolute top priority
sb0 has joined #m-labs
<sb0>
hartytp, it's mostly done, not paid yet, and needs testing that the DAC doesn't burn etc.
<sb0>
plus a few details like DAC_CLR
<Hartytp_>
Okay well Can you work on sdram first?
<Hartytp_>
Kill get the dad no smoke tested while you do that
<Hartytp_>
I'll not kill
<Hartytp_>
Dac... sigh
<sb0>
Hartytp_, is there a board other than yours on which SDRAM doesn't work?
<sb0>
whitequark, can you go to the lab, take sayma-2 (the one in the microTCA crate) and test the SDRAM with the latest binaries I posted?
<Hartytp_>
Look at the eye scans. Afacit all the eye scans posted look like crap
<sb0>
yes, on your board
<Hartytp_>
With errors in the middle of the dead zone
<Hartytp_>
Not just on mine
<Hartytp_>
Afacit the fact me test passes on other boards is more luck than anything else
<Hartytp_>
We've tested the hw to death so this really does feel like a missing constraint etc
<Hartytp_>
Can you give florent a hand on this as it's getting silly how long this has gone on for
<sb0>
the timing is supposedly fixed - the IOSERDES are dedicated per-pin resource, and I had already locked the MMCM to deal with the ethernet issues
<Hartytp_>
Well it's not working robustly on any board afacit so we
<Hartytp_>
Need to get it fixrd
<Hartytp_>
Are you sure the idelay scan works correctly?
sb0 has quit [Quit: Leaving]
<Hartytp_>
Sbo this feels a lot like all those lwip bugs which in hindsight probably had a lot to do with liteeth being a bit buggy
<Hartytp_>
My guess is that we're hitting a corner case in the ram phy due to timing closure difficulty with sawg
<Hartytp_>
And the phy doesn't handle it well
<Hartytp_>
I'm all for using the misoc cores if you can get them to work
<Hartytp_>
But if they're flaky like this then maybe it would be better to wrap the xilibx core into Imogen and use that
<Hartytp_>
Migen damn autocorrect :)
<Hartytp_>
Either way we really need this to work
<Hartytp_>
And as there doesn't seem to be any hw issue, that seems to mean fixing the gateware
Hartytp_ has quit [Ping timeout: 260 seconds]
Hartytp_ has joined #m-labs
<Hartytp_>
Sb0: look at it this way. Afaict everythibg else on sayma now basically works from an artiq perspective
<Hartytp_>
So if you fix this then you can be rid of sayma :)
Hartytp_ has quit [Ping timeout: 260 seconds]
sb000 has joined #m-labs
<sb000>
this argument is just as valid as me saying 'everything on sayma is flaky'
<sb000>
greg is also complaining about lwip (on mcu) by the way
<sb000>
misoc and smoltcp work really well on kc705 and kasli.
sb000 has quit [Ping timeout: 260 seconds]
sb000 has joined #m-labs
<sb000>
but yea, we'll look into integrating the xilinx mig for sayma
<sb000>
_florent_ can you email me a quote?
sb000 has quit [Ping timeout: 260 seconds]
attie has quit [Ping timeout: 240 seconds]
attie has joined #m-labs
mumptai has quit [Remote host closed the connection]
<rjo>
whitequark: ok
<rjo>
sb0: #950 is a big issue imho
<rjo>
sb0: and the sdram. you have a bunch of boards in HK.
<rjo>
hartytp: please stop with the "everything on sayma basically works".
<rjo>
hartytp: do we have the exar fixes?
<rjo>
hartytp: that's not helpful.
<rjo>
hartytp: who has tested the ethernet rework?
<rjo>
hartytp: and there is zero indication that there is any problem with timing closure with sawg.
<rjo>
copy-pasting INFO-level stuff from vivado as issues and using them as arguments for anything doesn't hold water. that's just a distraction.
<hartytp>
rjo: okay, well there is also zero indication that the SDRAM is a hw issue
<hartytp>
if you can think of any more tests you want done on that then please do suggest them
<rjo>
hartytp: yes. ack.
<rjo>
hartytp: do you remember what the pll phase margin with urukul-ad9910 as-built was?
<hartytp>
rjo: "copy-pasting INFO-level stuff from vivado as issues and using them as arguments for anything doesn't hold water. that's just a distraction."
<hartytp>
that's really not an accurate description
<hartytp>
at all
<hartytp>
firstly, none of that was info-level
<hartytp>
secondly, there were a couple of genuine bugs highlighted in the vivado warnings I posted that needed fixing
<hartytp>
and, I'm not using those warnings as an "argument" for anything
<hartytp>
I'm not arguing that this *is* because of timing closure on the SAWG.
<hartytp>
If you guys want to fix this without any input from me, that would be *great*
<hartytp>
sb0: so, are you giving up on getting the migen ram core to work, and planning to switch to the xilinx one?
<hartytp>
I don't really care too much either way so long as you find a solution that works.
<hartytp>
fwiw though:
<hartytp>
1. the fact that misoc works well on the KC705 doesn't show that anything we're seeing here is an issue with Sayma
<hartytp>
buggy software tends to work in the scenarios it was designed for and tested under. The important point is how well it handles corner cases
<hartytp>
2. No one is saying that LWIP is great or even particularly good. We're better off with smoltcp, which is nice
<hartytp>
the point is that at least some of our problems with LWIP were probably due to liteeth bugs
<rjo>
hartytp: #944 is INFO level.
<rjo>
hartytp: that's what i am referring to.
<hartytp>
but, rather than fixing those (e.g. fuzzing the mac) all the blame went to lwip
<hartytp>
the pattern here seems to be that rather than fixing misoc it's easier to just blame components of the hw/sw stack that were developed by other people
<hartytp>
3. When there are issues with the hw, greg tackles them in a very proactive, research-minded way
<hartytp>
he develops the diagnostics he needs to understand the root cause of the issue and then fixes it
<rjo>
hartytp: i am not disagreeing with the other statements.
<hartytp>
okay, he's a little slow, but that's somewhat our fault for throwing so many projects at him at once
<hartytp>
In contrast, in many cases, I don't see that research-minded approach being taken here. there seems to be quite a bit of poking things, rebuilding and hoping that all works well
cjbe has joined #m-labs
<hartytp>
it's not a very effective stratergy for fixing these things
<hartytp>
4. I think it should be quite clear that none of this is a very good advertisment for the misoc stack
<hartytp>
to those of us who might consider investing our time and funding into it in the future
<hartytp>
5. From the logs I can see, it's not even clear to me how seriously you're taking this. _florent_ seems to be working on it on a very part-time basis
<hartytp>
and most of your energy on this seems to be spent complaining about Sayma
<rjo>
hartytp: things like posting #944 keep people from wanting to have anything to do with.
<hartytp>
who's actually working to try to break the problem down into pieces that can be tested and understood
cjbe_ has quit [Ping timeout: 256 seconds]
<hartytp>
rjo: ack
<hartytp>
I'm not defending that
<hartytp>
it's not helpful
<hartytp>
I'm working on it
<hartytp>
it would be much easier to prevent that kind of input if there were a better attitude from M-Labs towards tackling this
cjbe_ has joined #m-labs
<hartytp>
rjo: about 35deg IIRC
<hartytp>
lower than predicted because of the extra RCs on the AD9910 which aren't in the data sheet
rohitksingh_work has quit [Ping timeout: 246 seconds]
<hartytp>
(for Kasli)
rohitksingh_work has joined #m-labs
[X-Scale] has joined #m-labs
attie has quit [Ping timeout: 240 seconds]
attie has joined #m-labs
X-Scale has quit [Ping timeout: 268 seconds]
[X-Scale] is now known as X-Scale
<rjo>
hartytp: it would be great (for planning, orga, lobbying, answering that very question of who uses it, i.e. certainly not for "pride") if we could hear about everybodies plans to use sayma! we have heard very little.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<hartytp>
rjo: ack
<hartytp>
atm it's a lot of people who aren't very invovled, but want something with Sayma's capabilities
<hartytp>
it's hard to galvanize that community until there is a working demo
<hartytp>
once we have that, I expect a lot more feedback from users
<rjo>
hartytp: yeah. but even where there has been a working demo for years, people keep their stuff to themselves. e.g. i just heard yesterday that the stylus guys apparently have (and are very proud of) a code layer on top of the dataset management that sounded like it overlaps a lot with what klickverbot is working on.
<hartytp>
rjo: ack
<hartytp>
but, that's a separate conversation
hartytp has quit [Quit: Page closed]
rohitksingh_work has quit [Read error: Connection reset by peer]
hartytp has joined #m-labs
<hartytp>
rjo: fyi, we're working on sampler code for artiq
<hartytp>
expect a pr in a few days
<hartytp>
plan is to replace the novogorny on opticlock with sampler (eem3 IIRC). if it would be more helpful, we can put it somewhere else, it doesn't make much difference to me
<rjo>
hartytp: ack. make it another variant.
<hartytp>
okay
<hartytp>
called?
<hartytp>
(basically, do you want me to put that in an oxford master variant? Or, will you use it for opticlock? )
<hartytp>
(if the ox version, this will be the same one in one of our contracts)
<GitHub-m-labs>
[artiq] jordens commented on issue #955: Yeah. Maybe a nice tweak. But you still need to set all kinds of other information. And commissioning Kasli is more than that. Write the FT4232H eeprom with the serial number and correct settings, set the writable part of the eeprom, commission the other devices on the tree. https://github.com/m-labs/artiq/issues/955#issuecomment-372660935
<rjo>
whitequark: i don't think artiq master is currently installable under windows. could you please fix the buildbot so we can reason about that?
<rjo>
hartytp: i don't think opticlock will use it but there are ~6 other systems in the pipeline that will use sampler.
<rjo>
hartytp: and we'll need a variant for nu-servo anyway.
<GitHub-m-labs>
[artiq] mingshenli commented on issue #956: the IP address is corect and hub is fine too. What is 'use flterm on the appropriate USB port' means and how to make sure that 'The KC705 is booting properly, and the configuration is correct '?... https://github.com/m-labs/artiq/issues/956#issuecomment-372692519
<GitHub-m-labs>
[artiq] cjbe commented on issue #956: If you run `python -m serial.tools.list_ports -v` you should see an entry `CP2103 USB to UART Bridge Controller` - this is the KC705 serial terminal. If you don't see this, make sure you have a USB mini cable connected to the UART port on the KC705, and that the driver is installed (https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers)..
<cr1901_modern>
So you'll see that my PR was accepted to extend litex' behavior. I had intended to make a similar PR back to migen for feature parity, but...
<cr1901_modern>
mithro found a few bugs and suspects my patch is broken in other subtle ways >>
<cr1901_modern>
I was wondering if you'd consider accepting _this_ patch into Migen for feature parity
<cr1901_modern>
cc: mithro Could you explain exactly what your patch does and how it breaks migen behavior?
<cr1901_modern>
(Different type signature is the obvious one)
<cr1901_modern>
s/type/function/
<rjo>
cr1901_modern: please don't do those multiline exceptions. that's not right. use logging for that.
<cr1901_modern>
Ack. Is there anything else that would block you from accepting this extension?
<rjo>
cr1901_modern: i wonder how useful it is to try to abstract over vivado/ise. why not just do vivado.settings(path="/opt/Xilinx/Vivado", ...) and ise.settings(path="/opt/Xilinx", ...)
<rjo>
cr1901_modern: the 32/64 thing is definitely good.
<cr1901_modern>
rjo: B/c a number of mithro's repositories are supposed to work on platforms with ISE and Vivado. We don't know ahead of time which toolchain will be selected b/c the platform is specified by the user on the command line
<cr1901_modern>
(along with a root path to search for Xilinx tools which can be specified on the command line)
<cr1901_modern>
We _could_ keep a list of platforms and toolchain mappings in a separate file that is consulted before make calls python3, but something about that feels off to me.
<cr1901_modern>
IMO the platform should uniquely specify the toolchain, and each vendor should have a user-specifiable single directory where we look for tools.
<cr1901_modern>
(well for Xilinx, and Altera anyway. Icestorm I just assume the tools are already on the path)
<rjo>
i don't think the platform should spec the toolchain. that would break a couple of nice use cases. but the toolchain should just know where to look for its various versions given a root directory. i don't get the point of trying to cram the Vivado/XXXX.Y and XX.Y/ISE_DS stuff into name_first/version_first.
<rjo>
but it's minor. there are more important things that could be improved in migen.build. like style.
<cr1901_modern>
I understand it's minor/bikeshedding. But bumping litex has been causing pain for the reasons I stated above, so that's why I'm bikeshedding now.
<cr1901_modern>
What use cases would be broken by tying a platform to a toolchain?
<rjo>
cr1901_modern: we were happily using switching between vivado and ise for ddx on kc705 for example. with a mere command line switch.
<cr1901_modern>
Interesting I did not know ISE supported Kintex-7
<cr1901_modern>
Fwiw, I agree w/ this: "but the toolchain should just know where to look for its various versions given a root directory"
<cr1901_modern>
Just my initial patch didn't work (tm), and it broke mithro's CI. So, I'm not sure if trying this approach is broken by design or I just need to try harder (tm). >>
<cr1901_modern>
Wish I could be more specific- mithro went afk before I could ask him what was wrong w/ my/your solution.
<cr1901_modern>
I'll just construct a patch and we can hash out the details whenever we all have time.
<GitHub-m-labs>
artiq/master 2fdc180 Robert Jordens: dsp/fir: outputs reset_less (pipelined)
<whitequark>
rjo: okay I will look into windows issues
<rjo>
whitequark: thanks.
<rjo>
whitequark: i had a look at the buildbot logs. how are you activating the environment after creating it? is 'Scripts' the only item from the env that needs to be in the path?
<whitequark>
rjo: possibly not anymore
<rjo>
whitequark: and why do you need --no-update-deps and why is it not harmful?
<whitequark>
rjo: I think that was a workaround for some ancient conda bug
felix_ has quit [Quit: leaving]
felix_ has joined #m-labs
<GitHub-m-labs>
[buildbot-config] whitequark pushed 1 new commit to master: https://git.io/vxU5x
<GitHub-m-labs>
buildbot-config/master f390596 whitequark: Add miniconda root to %PATH% on Windows.
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
<bb-m-labs>
I'll give a shout when the build finishes
<GitHub-m-labs>
[artiq] whitequark commented on issue #845: @kesht123 It seems highly likely that the recent liteeth fix would solve this issue. Can you please upgrade to the latest release in 3.x series (or master) and retry? https://github.com/m-labs/artiq/issues/845#issuecomment-372756253
<GitHub-m-labs>
[artiq] cjbe commented on issue #940: With the below experiment (which runs for a while and then underflows) I see the error once every 5 or so runs. There is no startup or idle kernel, and there are no errors in the core log. I am using Artiq 2edf65f57b86fa9797d5f9cb300191cec31e50ba.... https://github.com/m-labs/artiq/issues/940#issuecomment-372767169
<rjo>
_florent_, sb0: i'm wolking myself through the sdram phys and controller.
<rjo>
i'll ask a few questions to see what we have tried and where we could reasonably look. (1) ug571 talks about waiting for IDELAYCTRL.RDY + 64 cycles. anyone tried just tying sys_rst to IDELAYCTRL.RDY + 64?
<rjo>
(2) with FIFO_ENABLE=FALSE, it says that "FIFO_RD_CLK should not be connected". we drive it low. but that is most likely a Xilinx red herring IME
<rjo>
(5) and on top of the RST from 3., maybe the addr/cmd/clk ODELAYE3s also need CLK
<rjo>
_florent_, sb0: do we have a way to reliably reproduce the sdram issue on one of our boards? does it need SAWG? litex/sayma_test or misoc or artiq? what's state of the art currently?