09:26 <ashafir> [smoltcp] i see there is timestamp added to the Device receive/transmit fn. TIVA h/w has IEEE 1588 timestamp logic in h/w. is it worth adding of this to the driver?

09:28 <ashafir> also iface.poll(&mut socket_set, clock.elapsed()) shall it be the same time format (from the same h/w system time module)?

10:37 <whitequark> ashafir: the timestamp is mostly so that e.g. PcapWriter and FaultInjector would not have to have a separate way to get system time

10:38 <whitequark> I don't think it's precise enough for IEEE1588

10:38 <whitequark> also, upper layers still have to know about 1588 to leave blank space in the packets

12:02 <key2> hi

12:03 <key2> what is the way with migen to reset a module ? (so Signals take back their reset value) ?

12:32 <attie> key2: the clock domain contains a reset signal

12:33 <attie> it's automatically applied to all registers in the clock domain

12:33 <attie> (sys_rst if you haven't named any domain)

13:45 <key2> my question is more, can I reset just a module from another one

13:45 <key2> a bit like when you do @ceinserter

13:45 <key2> so I could control the reg

13:45 <key2> i mean the signal

14:14 <rjo> ResetInserter

14:20 <GitHub105> [artiq] jbqubit commented on issue #807: I understand that that users-who-care should implement graceful termination. All the same this schizophrenic behavior shouldn't be possible. Full-scale noise may be hazardous in some applications especially given how common it is in physics labs to use wide-band amplifiers to drive sensitive loads. For example, it's not uncommon to operate resonant devices with high gain away near to resonance including pi

14:49 <GitHub154> [artiq] jordens commented on issue #807: Graceful termination is not a safety feature for your hardware constraints. That would be completely mismatched. The number and severity of hardware constraints is irrelevant. Forbidden parameter ranges are arbitrarily complex. You have to take care of them yourself, in software, in gateware, or in hardware.... https://github.com/m-labs/artiq/issues/807#issuecomment-319089910

14:54 <key2> rjo: thx

14:56 <key2> can I tell self.specials.mem = Memory() to not use BRAM but distributed ram ?

15:02 <rjo> key2: no currently. but passing through attributes (we have them on Signal()) to the memory element sounds like a good idea.

15:02 <rjo> then you could do it.

15:09 <key2> rjo: and what happen if I do something like [Signal(8) for _ in range(100)] or Signal(8*100) and read/write using a Case statement

15:09 <key2> would it be what the tools ends up doing when doing distributed ram or it's not optimized

15:14 <rjo> dunno. try it. but i'd assume that it won't be able to recognize this as a BRAM and potentially not even as a resonably fast distributed RAM pattern.

15:14 <rjo> key2: but i remember these things to be recognized as RAM/ROMs in vivado.

15:21 <key2> fact is that I don't want it to be recognized as BRAM

15:21 <key2> as i need my bram

15:21 <key2> i want it to use LUTs

15:23 <key2> basically, in verilog, if I do something lile "reg [7:0] myram [99:0]" is it the same as having 100 "reg [7:0]" ?

15:24 <GitHub140> [artiq] sbourdeauducq commented on issue #807: Is there any use for the overflows, or would it make sense to detect them, report an error, and kill the output (in gateware)? https://github.com/m-labs/artiq/issues/807#issuecomment-319101277

15:47 <GitHub82> [artiq] jordens commented on issue #807: For the phase and frequency interpolators overflows are natural and intuitive. For the amplitude/offset, they would be expensive to detect and report. https://github.com/m-labs/artiq/issues/807#issuecomment-319110530

16:11 <GitHub159> [artiq] jbqubit commented on issue #807: >You have to take care of them yourself, in software, in gateware, or in hardware.... https://github.com/m-labs/artiq/issues/807#issuecomment-319117775

16:22 <sb0> oh, surprising, the TM4C1294 ethernet bootloader in ROM theoretically does something sane

16:23 <sb0> it's just BOOTP/TFTP and not some proprietary NIH thing

18:13 <sb0> Intel NIH: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/leds/leds-lm355x.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/media/atomisp/i2c/lm3554.c

18:13 <sb0> it goes without saying, of course, that the intel driver doesn't work on my machine

18:44 <larsc> atomisp is a over the fence code drop, it will be removed again from the kernel in a few years after nobody was found to clean it up

22:28 <GitHub41> [artiq] llopez32 commented on issue #767: device_db.py was incorrectly configured; we can run scripts now. Thank you!... https://github.com/m-labs/artiq/issues/767#issuecomment-319214614