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
_Jack__ has joined #m-labs
ylamarre has quit [Read error: Connection reset by peer]
ylamarre has joined #m-labs
_Jack__ has left #m-labs [#m-labs]
<sb0>
whitequark, from a user perspective, what is the conda problem now?
Mon_ has joined #m-labs
Mon_ is now known as Guest85373
Guest85373 has quit [Quit: This computer has gone to sleep]
Guest85373 has joined #m-labs
Guest85373 has quit [Quit: This computer has gone to sleep]
<whitequark>
sb0: from a user's perspective, you cannot easily rollback to a prior artiq version and also there is no insurance that the bitstream package and the main artiq package are in sync
<sb0>
rollback is doable with environments, no?
<sb0>
and this 'insurance' is secondary, as we cannot make sure that users flash their boards anyway
<sb0>
so yes. i'd say remove any bug-tickling dependency between the artiq and bitstream packages, update the manual, and finish the compiler
Mon_1 has quit [Quit: This computer has gone to sleep]
Mon_1 has joined #m-labs
Mon_ has joined #m-labs
Mon_ is now known as Guest73886
stekern has quit [Ping timeout: 260 seconds]
stekern has joined #m-labs
Guest73886 has quit [Quit: This computer has gone to sleep]
Mon_1 has joined #m-labs
Mon_1 has quit [Client Quit]
ylamarre has quit [Quit: ylamarre]
Mon_1 has joined #m-labs
Mon_1 has quit [Quit: This computer has gone to sleep]
Mon_ has joined #m-labs
Mon_ is now known as Guest24799
Guest24799 has quit [Quit: This computer has gone to sleep]
Mon_1 has joined #m-labs
Mon_1 has quit [Client Quit]
Mon_1 has joined #m-labs
Mon_1 has quit [Client Quit]
Mon_1 has joined #m-labs
<mithro>
sb0: Do you know anyone who is skilled with misoc/migen (like yourself / _florent_) that currently has bandwidth for contracting work?
<sb0>
mithro, sounds difficult, but what contracting work is it exactly?
<cyrozap>
What serial output should I expect if MiSoC is running properly?
<cyrozap>
i.e., boot information, "Hello World!", etc.
<mithro>
sb0: Video IP related stuff but the exact work would highly depend on the skills, costs and time availability. There is a bunch of stuff I need done specifically for the Opsis and some stuff which would shared between the HDMI2USB, apertus and snickerdoodle projects.
Mon_1 has quit [Quit: This computer has gone to sleep]
<sb0>
cyrozap, you should try a simple target with just serial and everything in block RAM
<sb0>
mithro, ah, so sounds like quite substantial work then.
Mon_1 has joined #m-labs
<cyrozap>
sb0: That's what I'm doing right now--I'm even using an external FTDI dongle instead of the built-in USB-serial adapter due to its unreliability.
<cyrozap>
sb0: Oh, wait it works!
Mon_1 has quit [Quit: This computer has gone to sleep]
Mon_1 has joined #m-labs
<sb0>
cyrozap, cool!
<cyrozap>
Aaaaaand rebuilding the bitstream to use the built-in serial port doesn't work at all, as expected
<cyrozap>
Oh, wait, the RX and TX might be flipped...
<cyrozap>
Yup, Tx and Rx are swapped. I guess that will be my first patch to Migen...
<sb0>
cyrozap, "swapped" depends on what perspecive you are taking :)
<sb0>
and the choice has to be arbitrary.
<cyrozap>
sb0: The schematics for the device list Tx and Tx from the USB serial adapter's (a PIC uC) perspective, not the FPGA's. While the assignments in the platform file were "correct" according to the schematic, they had to be swapped to get any output.
<cyrozap>
Ideally, the schematic should have listed the pins as "PIC-RX_FPGA-TX" and "PIC-TX_FPGA-RX"
<cyrozap>
But I have some known-good verilog + UCF for this board, so I just went off of that :)
<sb0>
cyrozap, the misoc uart core expects tx/rx in a different direction
<sb0>
and this, for every platform
<sb0>
statistically, this should be the opposite of the schematics of 50% of the platforms ...
<sb0>
to avoid confusion, those could be called e.g. fpga_to_remote and remote_to_fpga, but that's somewhat long
<cyrozap>
sb0: Or it could be standardized in documentation
<cyrozap>
But I'm not mad or anything since I've already learned my lesson from the last time I wasted a few hours debugging that :)
<cyrozap>
I assume SDRAM isn't supposed to initialize forever, right?
fengling has quit [Ping timeout: 245 seconds]
<sb0>
no, that should take less than a second
<cyrozap>
sb0: Yup, that's what I thought. I guess I have some clock fiddling to do...
fengling has joined #m-labs
<cyrozap>
How do I determine what `rd_bitslip` and `wr_bitslip` should be?
<cyrozap>
^ In the context of using S6HalfRateDDRPHY
cr1901_modern has quit [Ping timeout: 260 seconds]
fengling has quit [Ping timeout: 245 seconds]
fengling has joined #m-labs
cr1901_modern has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 264 seconds]
fengling has quit [Ping timeout: 245 seconds]
rohitksingh has joined #m-labs
<_florent_>
cyrozap: the values used on the pipistrello aren't working? (same DDR: MT46H32M16)
rohitksingh has quit [Ping timeout: 264 seconds]
<GitHub134>
[artiq] sbourdeauducq pushed 3 new commits to master: http://git.io/vWH7d
<cr1901_modern>
mithro: I have bandwidth for contracting work
<cr1901_modern>
After I'm done with implementing a GUI widget for ARTIQ. Or I could do both at once after this lol
<cr1901_modern>
I just love when government form B depends on A, but A didn't give me all the required information and so I have to make a phone call. And it's not business hours.
rohitksingh has joined #m-labs
fengling has joined #m-labs
travis-ci has joined #m-labs
<travis-ci>
m-labs/artiq#553 (master - ec328cf : Sebastien Bourdeauducq): The build has errored.
<cyrozap>
_florent_: Well, I have no idea if its those values or the PLL that's configured incorrectly, and I'm not sure how to test which it would be.
<_florent_>
ok so with 50MHz clock that's not working?
<cyrozap>
Nope
starbuster has joined #m-labs
<_florent_>
and what is going on? memtest fails or sdram initialization does not stop?
ylamarre has quit [Ping timeout: 268 seconds]
starbuster has left #m-labs [#m-labs]
<cyrozap>
_florent_: SDRAM init hangs
<_florent_>
ah strange
<_florent_>
you should try to add printfs in the bios to see where it is hanging exactly
ylamarre has joined #m-labs
<cyrozap>
_florent_: The farthest it gets is the memtest
<_florent_>
ok, can you try to see in memtest where it stops?
<_florent_>
but that's a bit strange since none of the functions in memtest should block...
<cyrozap>
Ok, I'm waiting for it to build now
<cyrozap>
_florent_: I may be an idiot
<cyrozap>
I just noticed that the boot process hangs when I release the reset button
<cyrozap>
And it progresses normally when I leave it pressed
<cyrozap>
I forgot to invert the button signal before using it as a reset -_-'
<_florent_>
ah yes :), but do you have a memtest result when keeping the reset button pressed?
<cyrozap>
_florent_: Yup, "Memtest failed: 532477/532736 words incorrect"
rohitksingh has quit [Quit: Leaving.]
ylamarre has quit [Remote host closed the connection]
ylamarre has joined #m-labs
ylamarre has quit [Ping timeout: 240 seconds]
bentley` has joined #m-labs
<cyrozap>
_florent_: I've altered the DDR clock phase and now I'm only getting about half of the words incorrect
<cr1901_modern>
Now h5py refuses to build because of course it does
<cr1901_modern>
I do not have a high opinion on the ease-of-installation for HDF5 and friends
ylamarre has joined #m-labs
<GitHub16>
[artiq] whitequark pushed 1 new commit to master: http://git.io/vWbvG
<GitHub16>
artiq/master c0e040c whitequark: conda: give up on build strings in dependencies.
<cr1901_modern>
It's like the h5py devs are clueless on how to solve Windows build problems. The software didn't even build until I changed setup_build.py b/c it was looking for nonexistant libraries.
<cr1901_modern>
And now I get "ImportError: DLL load failed: The specified module could not be found." The fuck?
<cr1901_modern>
okay, that second one is probably my fault lol, but still
ylamarre has quit [Read error: Connection reset by peer]
ylamarre has joined #m-labs
travis-ci has joined #m-labs
<travis-ci>
m-labs/artiq#556 (master - c0e040c : whitequark): The build passed.