<mithro>
sb0: I'm trying to debug why our firmware (and the bios) seems to have issues on or1k but work fine on lm32
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Quit: Leaving.]
_whitelogger has joined #m-labs
<GitHub156>
[artiq] sbourdeauducq commented on issue #778: I didn't say it wouldn't impact latency, I said it wouldn't impact throughput. The basic idea is to pipeline to FIFO selection system, and increase the underflow margin so that the event has time to make it through that pipeline. The pipeline increases latency by the number of stages it has, but you can submit a new event before the previous one has made it through. The pipeline system would need som
<GitHub170>
[artiq] sbourdeauducq commented on issue #778: I didn't say it wouldn't impact latency, I said it wouldn't impact throughput. The basic idea is to pipeline to FIFO selection system, and increase the underflow margin so that the event has time to make it through that pipeline. The pipeline increases latency by the number of stages it has, but you can submit a new event before the previous one has made it through. The pipeline system would need som
<GitHub62>
[artiq] sbourdeauducq commented on issue #778: I didn't say it wouldn't impact latency, I said it wouldn't impact throughput. The basic idea is to pipeline the FIFO selection system, and increase the underflow margin so that the event has time to make it through that pipeline. The pipeline increases latency by the number of stages it has, but you can submit a new event before the previous one has made it through. The pipeline system would need some
<GitHub66>
[artiq] hartytp commented on issue #778: > I didn't say it wouldn't impact latency, I said it wouldn't impact throughput. The basic idea is to pipeline the FIFO selection system, and increase the underflow margin so that the event has time to make it through that pipeline. The pipeline increases latency by the number of stages it has, but you can submit a new event before the previous one has made it through. The pipeline system would need some heu
<sb0>
mithro, a long time ago
<mithro>
sb0: Is there any reason to use yosys in this mode?
<sb0>
replace the proprietary xilinx counterpart
<sb0>
test yosys performance and bugs
<sb0>
bb-m-labs: force build --branch=pull/806/merge artiq
<bb-m-labs>
build forced [ETA 36m28s]
<bb-m-labs>
I'll give a shout when the build finishes
<mithro>
sb0: I'm trying to debug why our firmware (and the bios) seems to have issues on or1k (lock ups / stop responding) but works fine on lm32
<sb0>
you already asked this. I never used or1k exceptions.
<mithro>
sb0: I was asking about exceptions on the lm32 at that time
<sb0>
but I suppose they work yes
<mithro>
sb0: I guess I could make the firmware do a div by zero to test that?
<sb0>
well yes, try it
<sb0>
I used IRQs, exceptions would be similar
<mithro>
sb0: I only just thought about it that possibility then...
<mithro>
sb0: I'm thinking of hooking up the OpenSoC Debug stuff to the or1k in litex/migen -- would you find jtag debugging / gdb debugging of the or1k soft core useful in your work?
<GitHub115>
[smoltcp] whitequark force-pushed master from 83eaaf3 to a1910ba: https://git.io/vMLjV
<GitHub115>
smoltcp/master a1910ba whitequark: Put the debug_id field first in sockets....
<GitHub143>
[artiq] jbqubit commented on issue #806: @mntng Please include narrative describing what test_spi.py is meant to test. That is, what was missing from ARTIQ prior to your commit and how does your commit address it. https://github.com/m-labs/artiq/pull/806#issuecomment-318660362