<sb0>
_florent_, I don't understand why you need a 20x (!) clock for serwb
<sb0>
IMO there should be only 2 clocks in addition to the system one: a 2x clock and a 10x clock
<sb0>
and those should be generated in the system CRG, just like it's done for SDRAM, without a second PLL
<sb0>
this also solves the problem of the PLL being in the platform-independent phy.py while it is actually platform-dependent (ultrascale needs bufgce_div, a7 bufg)
<sb0>
for operating at half-rate (625Mbps) you need a 5x clock instead
<sb0>
well you may need a second PLL since the clock ratios don't work out
<sb0>
also I'd focus on half-rate only to simplify things
<sb0>
_florent_, have you noticed that Sayma has the -1 speed grade with a maximum MMCM VCO frequency of 1200MHz, and so your 1250 is out of specs?
mumptai_ has joined #m-labs
<GitHub166>
[smoltcp] dlrobertson commented on pull request #167 ee77812: I was hesitant to include this, because we are beginning to test the packet is well formed if we use `==` here. We do need to do additional checks based on the type. Otherwise `check_len` will not return `Error::Truncated` for a option with `data[field::LENGTH] == 1` and `data[field::TYPE] == Type::PrefixInformation`, which could panic later if the pr
<GitHub73>
[smoltcp] dlrobertson commented on pull request #167 ee77812: Used impl block docs :smile: As a whole I did not prefix type specific methods with the option type name. Let me know if this would be a good addition. https://github.com/m-labs/smoltcp/pull/167#discussion_r168939174
<GitHub189>
[smoltcp] dlrobertson commented on pull request #167 ee77812: Wasn't sure how to break up the groupings of constants. If this is not readable, I'm more than happy to iterate on this. https://github.com/m-labs/smoltcp/pull/167#discussion_r168939163
mumptai has quit [Ping timeout: 256 seconds]
<sb0>
oh I see, this 20x clock is because the serdes only has ratios of 4 and 8
<sb0>
well, in that case, there is no way around non-integer gearboxes
<sb0>
this is dumb
<sb0>
_florent_, in this case, what about operating at 1000Mbps? then we can simply recycle the sys4x clock from the sdram.
<sb0>
uses less fpga resources, plus fewer clocks = fewer things that can go wrong
<sb0>
cr1901_modern, 15pF is a lot even with relatively simple circuits
<GitHub175>
[smoltcp] dlrobertson commented on pull request #168 03c3f55: `data[3] & 0x7` if you want to maintain the reserved bits. If you don't want to maintain the reserved bits `0x1` should be fine right? https://github.com/m-labs/smoltcp/pull/168#discussion_r168939471
<GitHub3>
[artiq] hartytp commented on issue #908: @enjoy-digital Not sure what your current priorities are, but it would really help me if you could prioritise fixing the serwb issues that @sbourdeauducq highlighted this week. https://github.com/m-labs/artiq/issues/908#issuecomment-366519864
<sb0>
_florent_, I thought that was just setting some divider at the output of the VCO itself
<sb0>
let me check
<sb0>
you're right, that's in the clkin input path
<sb0>
okay, so there isn't the vco out of specs problem, but still - the clocking is overly complicated, and doesn't allow the use of the recommended BUFGCE_DIV
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<cr1901_modern>
sb0: Since mithro and I were talking about this in #openfpga, what do you think about something like this for adding assertion support to migen? https://github.com/cr1901/misoc-spi-tb
<cr1901_modern>
I tried adding it directly to migen, but I ran into too many issues trying to get it to work w/ modifying migen directly
<cr1901_modern>
In the linked repo, you write your asserts in Verilog, but I provide some macros using pyexpander which will automatically convert the equivalent signal to its verilog name
<sb0>
okay, we have DRTIO on kasli
<sb0>
the GTP PLL is another piece of trash, if you send it anything other than 0 or a valid clock, even when it is in reset/power-down state, it enters fucked-up mode where it indicates lock but makes sure that nothing in the rest of the transceiver works
<sb0>
typ
<sb0>
ical xilinx design
<cr1901_modern>
it's prob written in the manual somewhere that it's UB if you do anything other than send 0 or valid (not that this justifies the behavior)
<sb0>
while you assert the reset pin of something, you don't want it to look at any other pin
<sb0>
speaking of things that are trash, systemd-coredump is also worth a mention
<sb0>
it's hosing my computer right now, because it coredumps a process, crashes while doing that, then starts another systemd-coredump that also crashes, etc. etc.
* cr1901_modern
inserts uninspired "systemd and trash is redundant" quip
attie has quit [Ping timeout: 252 seconds]
attie has joined #m-labs
<sb0>
you can't even disable this thing entirely, the best you can do is tell it not to store the output it has generated (while driving the load average to 30+)
<GitHub70>
[artiq] hartytp commented on issue #854: @gkasprow @marmeladapk Can you make this the absolute top priority for this week, please? Ethernet and a small number of other issues have stopped us from getting Sayma working for way too long now, and I'd love to see them resolved so I can start testing Sayma properly! https://github.com/m-labs/artiq/issues/854#issuecomment-366543437
mumptai has joined #m-labs
attie has quit [Ping timeout: 256 seconds]
attie has joined #m-labs
<rjo>
there is still something wrong with the clock constraints. rtio_internal <-> rtio_external and derivatives should be false paths.