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
<cyrozap> In a Migen FSM, what's the difference between "NextValue(foo, bar)" and "foo.eq(bar)"? Is it just for ease-of-reading or does it alter behavior?
<cyrozap> Also, in simulation, my code seems to be hanging somewhere. Is there any way to probe to figure out where the hang is happening? The logic is not very complicated, and it's stalling within one clock cycle, so I'm not sure what's going wrong.
<cyrozap> Oh, wow, those two questions ended up being related--changing my ".eq()"'s to NextValue's fixed the hanging issue.
<cyrozap> Is there a way to set a custom timescale for a simulation?
<cyrozap> Ah, found it.
<whitequark> sb0: I just re-checked moninj again
<whitequark> every TTL
<whitequark> OE doesn't work on any single one...
<whitequark> sb0: got your SFPs
<whitequark> sb0: why is DMA base address 64-bit?..
<sb0> whitequark, (moninj) ok, can you have a look at it?
<sb0> (SFPs) thanks!
<sb0> (DMA) for the analyzer I guess? let me check...
<whitequark> the "byte count" seems to make sense, assuming it is never cleared
<whitequark> base address though not so much
<sb0> hm, how large is the KC705 memory again?
<whitequark> 1G I think
<whitequark> I mean, it makes no sense given that mor1kx is 32-bit
<whitequark> even if you could DMA beyond 4G I can't access it
<whitequark> actually mor1kx might have a 64-bit option but the LLVM backend doesn't
<whitequark> sb0: speaking of 64-bit stuff I've recently discovered that or1k has native 64-bit mul
<whitequark> though it's sort of awkward
<sb0> the root cause is misoc has a 30-bit memory address signal (in 64-bit words) for some reason
<whitequark> should we add that, for faster RTIO math?
<whitequark> ah
<sb0> _florent_ did that port I think. maybe that's for supporting the larger SODIMMs?
<sb0> ah, no
<sb0> that's because it uses the default wishbone address size of 30 bits
<sb0> which then gives you more than 2GB if the data width is >32
<sb0> well, that's without serious consequences.
<whitequark> yeah
<whitequark> I noticed because rust has no implicit integer casts
<whitequark> uuuugh
<whitequark> Rust has no way to make an aligned struct
<whitequark> well, the issue is https://github.com/rust-lang/rust/issues/33626 but the workaround doesn't work.
<whitequark> sb0: does the DMA buffer have to be aligned to 64 bytes?
<whitequark> and nothing less?
rohitksingh_work has joined #m-labs
<sb0> yes, it needs to be aligned
<sb0> to a SDRAM word
<whitequark> ok
<sb0> in particular, on the KC705, the 6 LSBs need to be 0
<sb0> this is board dependent
<sb0> whitequark, how exactly do you read OE back=
<sb0> ?
<sb0> did you check if overriding an input TTL set it to output, at the electrical level?
<whitequark> sb0: how did I check:
<whitequark> csr::rtio_moninj::mon_probe_sel_write(1);
<whitequark> csr::rtio_moninj::mon_value_update_write(1);
<whitequark> if csr::rtio_moninj::mon_value_read() != 0 {
<whitequark> and no
<whitequark> I didn't look at this in depth yet
<whitequark> the gateware for moninj says:
<whitequark> Software has to ensure proper timing of any strobe signal etc.
<whitequark> what does this mean exactly?
<sb0> that's just for CDC, won't be the issue here
<sb0> you are setting a stable OE, it will get through eventually even with a broken CDC
<whitequark> ok
<sb0> so, with this check technique OE makes a round trip through the PHY
<sb0> can you read back the injector value correctly?
<whitequark> let me commit analyzer and check
<sb0> did you set override_en?
<whitequark> yes
<whitequark> and I can read that back
<sb0> the probes are populated at the end
<sb0> are you reading back OE immediately or with some delay? with the PHY readback it takes a bit of time for it to go through the CDCs so there's a race. it's unlikely the CPU will be that fast, but who knows
<whitequark> with network delay
<whitequark> I'm just waiting for the next Monitor request
<whitequark> so a few millis
<sb0> ok, that's definitely more than the CDC delay
sb0 has quit [Quit: Leaving]
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 264 seconds]
<GitHub194> [artiq] whitequark pushed 1 new commit to master: https://git.io/vPG9R
<GitHub194> artiq/master 0a29c00 whitequark: Rust: implement analyzer.
<whitequark> ok, analyzer's done,l ooking at moninj now
<bb-m-labs> build #97 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/97
<bb-m-labs> build #379 of artiq-win64-test is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/379 blamelist: whitequark <whitequark@whitequark.org>
<bb-m-labs> build #987 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/987 blamelist: whitequark <whitequark@whitequark.org>
<whitequark> sb0: I can read back the O/OE/OVERRIDE_ENABLE values from injector
<whitequark> let me look at the physical TTL no
<whitequark> sb0: I'm confused. which LED on KC705 should RTIO channel 19 light up?
<whitequark> GPIO_LEDS 2 ?
<whitequark> that doesn't happen even from an experiment...
<whitequark> and no, it doesn't happen if I do it via the injector
<whitequark> so maybe RTIO is just broken?
<whitequark> hm, no, this can't be, TestLoopback succeeds
<whitequark> wtf
kuldeep has quit [Ping timeout: 252 seconds]
kuldeep has joined #m-labs
bentley` has quit [Ping timeout: 252 seconds]
bentley` has joined #m-labs
<GitHub104> [artiq] jordens pushed 6 new commits to phaser: https://git.io/vPZYW
<GitHub104> artiq/phaser bd901e8 Robert Jordens: ad9154: status test
<GitHub104> artiq/phaser 9771fb2 Robert Jordens: phaser: cleanup startup kernel
<GitHub104> artiq/phaser 34b5227 Robert Jordens: ad9154_reg: portable helpers
<rjo> vivado: INTERNAL ERROR on input pin '.:top/i_7:top__GCB7/I19[14]', trying to recover ...
<rjo> i can't decide which makes me more uneasy. the fact that this smells like ICE or the fact that it even tries to recover from it...
<_florent_> larsc: for jesd, I'm using the verilog scrambler you shared some time ago to check mine. But I'm simulating the Xilinx jesd core and the first scrambled data seem different (looking at the first datas just after ILAs and with input data =0). I'm trying to understand, maybe I'm doing something wrong in my simulation of the Xilinx core but I just want to know
<_florent_> if I can use your verilog scrambler as a reference? Do you eventually have the first data outputed by the scrambler? (is it 0x0c000200, 0xf0002800, 0xc00c2002, 0x02ff802a, 0x280c0c02, 0x22f2f028, ...?)
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
<bb-m-labs> build #98 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/98
<GitHub96> [artiq] jordens force-pushed phaser from dfa8f3b to 0472ab6: https://git.io/vi7qh
<GitHub96> artiq/phaser 91e502e Robert Jordens: rtio: add input-only channel
<GitHub96> artiq/phaser 846df12 Robert Jordens: i2c: cleanup includes
<GitHub96> artiq/phaser 21a5dbc Robert Jordens: rtio: support differential ttl
<_florent_> larsc: in fact the seed is probably not the same...
<bb-m-labs> build #99 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/99
<larsc> _florent_: If I understand it correctly the standard recommends 0x7f80 as the seed
<larsc> the version I gave you didn't have this yet
<_florent_> larsc: yes thanks I'm testing that
<_florent_> larsc: it seems the Xilinx core is not using the one recommended by the standard
<larsc> _florent_: what is your input into the scrambler?
<_florent_> larsc: it's using 7e7c, but at least using this seed I'm able to get the same sequence than with the simulation
<larsc> ok
<_florent_> larsc: 0 to simplify things
rohitksingh has joined #m-labs
kuldeep has quit [Ping timeout: 265 seconds]
<GitHub144> [artiq] jordens force-pushed phaser from 0472ab6 to 4a0eaf0: https://git.io/vi7qh
<GitHub144> artiq/phaser 2bc5dc4 Robert Jordens: i2c: cleanup includes
<GitHub144> artiq/phaser a91ed83 Robert Jordens: rtio: add input-only channel
<GitHub144> artiq/phaser 279f0d5 Robert Jordens: rtio: support differential ttl
sb0 has joined #m-labs
kuldeep has joined #m-labs
<GitHub152> [artiq] whitequark pushed 1 new commit to master: https://git.io/vPZ6D
<GitHub152> artiq/master 4cfc4e8 whitequark: Rust: add basic RPC support.
bentley` has quit [*.net *.split]
kuldeep has quit [Ping timeout: 264 seconds]
kuldeep has joined #m-labs
bentley` has joined #m-labs
<bb-m-labs> build #100 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/100
<bb-m-labs> build #988 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/988 blamelist: whitequark <whitequark@whitequark.org>
EvilSpirit has joined #m-labs
mumptai has joined #m-labs
<GitHub88> [artiq] jordens pushed 1 new commit to phaser: https://git.io/vPnkS
<GitHub88> artiq/phaser c54b6e2 Robert Jordens: phaser: add README
<GitHub130> [artiq] jordens pushed 1 new commit to phaser: https://git.io/vPnkj
<GitHub130> artiq/phaser 3871a47 Robert Jordens: phaser: fix README
<GitHub74> [artiq] jordens force-pushed phaser from 3871a47 to d13f67c: https://git.io/vi7qh
<GitHub74> artiq/phaser d13f67c Robert Jordens: phaser: fix README
EvilSpirit has quit [Ping timeout: 265 seconds]
rohitksingh has quit [Quit: Leaving.]
mumptai has quit [Remote host closed the connection]
mumptai has joined #m-labs