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: 265 seconds]
X-Scale has joined #m-labs
<sb0>
hartytp, thanks
<sb0>
that makes sense
<sb0>
why does the ultrascale serdes in native mode have a *minumum* data rate?
<sb0>
do I even want to know...
rohitksingh_work has joined #m-labs
<sb0>
_florent_, in the JESD core, the elastic buffers are enabled in the transceivers, and it is possible to supply any TXUSRCLK (with an arbitrary phase) as long as it is coming from the same oscillator as the rest of the transceiver and has the correct frequency - correct?
<whitequark>
sb0: what are you working on?
<sb0>
right now some awful admin (audit, taxes, opening backup bank accounts)
<whitequark>
I meant re JESD question
<whitequark>
since that might affect my Allaki work (or maybe not)
<sb0>
it doesn't affect it; that's for using DRTIO in conjunction with JESD204
<sb0>
that will only get merged after the current situation is sorted out
<whitequark>
ok
<sb0>
(or we are certain that this doesn't increase the bug level)
<larsc>
sb0: if you don't care about determinisitic latency you can do that
<larsc>
if you care about it you have to make sure that sysref is transferred to this TXUSRCLK domain
<sb0>
larsc, yes, sure, I'm talking about the JESD data
<sb0>
it can be sent with a lot of timing skew AFAIK
<larsc>
yes, that is usually not a problem
<larsc>
any skew is compenstated for at the DAC
<larsc>
you just need to make sure that all the lanes arrive in the same multiframe
pefclic has joined #m-labs
<pefclic>
Hello, anyone here with some knowledge about migen design simulation ?
<pefclic>
I've got a weird result for an FSM… verilog : reg [3:0] state, simulation-> gtkwave: state[71:0]
<pefclic>
cd ..
<pefclic>
oups…wrong keyboard
rohitksingh_work has quit [Ping timeout: 240 seconds]
rohitksingh_work has joined #m-labs
<rjo>
pefclic: context?
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 256 seconds]
<pefclic>
rjo: simple test to try the simulation
<pefclic>
a counter controlled by a button with three states, one waiting for the button to be pressed, the second to init the counter and finally the third to decrement the counter until restarting the FSM
<rjo>
pefclic: show the code
rohitksingh_wor1 has quit [Ping timeout: 245 seconds]
<pefclic>
from migen import *
pefclic has quit [Excess Flood]
<pefclic>
class Blinker(Module):
<pefclic>
from migen.fhdl.verilog import convert
<pefclic>
from migen.build.platforms import olimex
pefclic has joined #m-labs
<rjo>
pefclic: use a paste side (paste.debian.net, hastebin.com etc etc)
<pefclic>
sorry for the naming etc…it's an ongoing example…
rohitksingh_work has joined #m-labs
<rjo>
and what's the output? what's the error?
<pefclic>
in the vcd trace I've got ste[31:0] et next_state[47:0]
<pefclic>
state
<pefclic>
and only 0 to 215ns of activity
<rjo>
how iss that different from what you expect (and what do you expect)?
<rjo>
s/iss/is/
<rjo>
pefclic: also could you pastebin the verilog so that we are looking at the same thing?
<rjo>
your generator determines the duration of the simulation.
<pefclic>
hum…if I look the verilog result I read reg [1:0] state that is correct
<pefclic>
the vcd gives me reg [31:0] for the state
marmelada has quit [Ping timeout: 260 seconds]
<GitHub-m-labs>
[artiq] whitequark commented on issue #919: I've flashed an old firmware that has been proven to work some weeks ago built based on hashes I recorded then. I've tried using two other Sayma RTMs (and ensured the proper resistor is soldered to DAC_CLK_N). I've tried different cables. I've tried using NVSynth instead of our clock generator (which appears to not have died after all, it does output RF at frequencies
rohitksingh_work has quit [Read error: Connection reset by peer]
<sb0>
whitequark, is the generator connected to the sayma right now and correctly configured?
<sb0>
let me try
<sb0>
whitequark, it works for me (except one time where serwb crapped out)
<sb0>
whitequark, I guess you are not setting the clock switches correctly
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #919: Works for me with the hardware in whatever state you left it. I guess you are not setting the clock switches correctly. Use this patch:... https://github.com/m-labs/artiq/issues/919#issuecomment-381590332
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #919: Works for me with the hardware in whatever state you left it. I guess you are not setting the clock switches correctly. Use this patch:... https://github.com/m-labs/artiq/issues/919#issuecomment-381590332
<sb0>
pebkac? you applied the rf switch change before; I remember I told you to do that and you did it.
<whitequark>
why is this not committed anyway?
<sb0>
eventually this should use the hmc830
<sb0>
in fact, it looks like the code should work already with the hmc830, but there is some weird hardware problem
<whitequark>
of course there is.
<sb0>
whitequark, I remember you found an AMC+RTM combination where serwb init was "done" but then the firmware froze and didn't display the RTM version
<sb0>
can you connect it to the buildserver so that _florent_ can debug it?
<sb0>
the PSU should handle 2 boards powered up at the same time...
<whitequark>
sb0: that doesn't happen anymore with latest firmware and also I left the lab
<whitequark>
I tried all RTMs with this AMC and they all initialize
<whitequark>
not always from the first try, though that's very intermittent
<sb0>
what is the connector situation? did you find decent ones or do we still have the firestarters?
<whitequark>
um, I fixed that immediately upon discovery and before powering it up again
<sb0>
the cables themselves burn at around 6A, I tested them
<whitequark>
I don't remember exactly what I did but at the time I believed I made it safe
<sb0>
there seems to have been some changes to the openmmc port recently, maybe they work in the uTCA rack now
<sb0>
this would be much better than this ghetto setup we've been dragging for many months
<sb0>
surprisingly, the sayma flash success rate with the shitty olimex jtag cable is above 50%
<sb0>
did you try your new fancy jtag cable by the way? does it not suck or is it standard fare?
<sb0>
the serial flasher seems reliable on the other hand, but it is slow and requires this shitty proprietary windows tool that uses hex files
<sb0>
their idea of modern software is phoning home and displaying up-to-date advertisement in the status bar
<whitequark>
I should try it
<sb0>
and if it doesn't work, please kick greg's ass, after all when he pushed for it he claimed the MMC would not cause any problems
<whitequark>
so what do you want me to do exactly with the uTCA crate?
<whitequark>
boot up the Saymas in there?
<whitequark>
this needs openmmc reflash, right? where do I get firmware?
<sb0>
try a board we don't really need e.g. the one that came back from the post
<whitequark>
that actually builds, right?
<sb0>
put it in uTCA and check if the all the power LEDs are on
<sb0>
no idea.
<whitequark>
lol
<whitequark>
okay
<sb0>
ideally we should not touch this but I'm getting irritated by the mess on the table
<whitequark>
what about the clock?
<whitequark>
are we going to feed it via some coax going through the front panel or something?
<whitequark>
do we even have long enough coax?
<whitequark>
(I don't think so)
<sb0>
the clock is a bit of a problem, yes. we can feed it on one board by opening the adjacent AMC slot
<sb0>
I was hoping the hmc830 issue would get resolved soon but this is dragging on, too
<sb0>
*adjacent RTM slot
<whitequark>
well what is the issue with hmc830?
<whitequark>
maybe I can fix it?
<whitequark>
looks like I have to dig into this mess anyway
<sb0>
register values seem OK (work on HMC830 devkit), they seem to be written correctly into the chip (readback OK), chip behavior is completely erratic
<GitHub146>
[smoltcp] podhrmic commented on issue #190: @whitequark please see the new commit. The main issue I found out is that currently, fragmentation requires `std` for the memory swap. The proposed solution is in `ethernet.rs` at line 410. https://github.com/m-labs/smoltcp/pull/190#issuecomment-381748583