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
ohama has quit [Ping timeout: 246 seconds]
ohama has joined #m-labs
<mithro>
For migen, should I send patches to the devel@lists.m-labs.hk list?
<sb0>
yes
<sb0>
rjo, maybe those registers have been pushed into the BRAM?
<sb0>
BRAMs can absorb two registers (and need to have at least one). the second one has ridiculous timing on slowtan6 and generally should not be used.
<sb0>
by "ridiculous" I mean that it improves the clock-to-output delay of the BRAM by a negligible amount, but removes a register that could be a lot more useful within the logic
<sb0>
and since LUTs have dedicated registers, those are not more expensive than the built-in second register of the BRAM
<sb0>
so the bottom line is, the second BRAM register should not be used, unless you have about zero combinatorial logic between the BRAM and some other non-LUT component. unfortunately, it seems that ISE does not implement this behavior...
balrog has quit [Excess Flood]
balrog has joined #m-labs
<rjo>
hmm. i can't see how it can absorb the register out of the loop. the number of cycles around that loop must remain constant during absorbing/balancing afaict.
<sb0>
maybe putting it on the second register will prevent it from absorbing it into the BRAM
mindrunner_off is now known as mindrunner
fengling has quit [*.net *.split]
cfelton has quit [*.net *.split]
[florian] has quit [*.net *.split]
fengling has joined #m-labs
cfelton has joined #m-labs
[florian] has joined #m-labs
fengling_ has joined #m-labs
fengling has quit [Ping timeout: 276 seconds]
<sb0>
whitequark, seems that some of this cheap taobao vacuum gear is made on order
<sb0>
which is interesting, because they can probably customize then
<whitequark>
hmmm interesting
<whitequark>
rjo: do you need persistence in redis?
<rjo>
we need persistence in our databases, yes.
<sb0>
speaking of databases
<sb0>
your influxdb parameter example
<sb0>
b = self.pdb.query("select avg(value) from foo where time > now()
<sb0>
- 1h group by time(1m)")
<sb0>
would break reproducibility...
<sb0>
if you re-run the experiment, now() and therefore the values returned by the DB will have changed
<rjo>
that's ok ;)
<rjo>
you can also do "self.delay(random.random()*100*us)"
<rjo>
everything beyond the current snapshots in the databases will break reproducibility.
<sb0>
rjo, also, how much work should we put into the ad9858 core? just hack the FSM so it passes timing with the kc705/new adapter board, or add a number of CSRs that control timing at runtime and make those parameters part of the DDB?
<rjo>
damn. the problem was actually in the CDC constraints. with the bufgmux, you apparently have to make the paths from either input to sys_clk (and the reverses) TIG. just the output of the bufgmux does not work.
<rjo>
nah. hack it but make the timing a synthesis-time parameter.
<rjo>
afaict there would be a write duration and a read duration, both in cycles, right?
<rjo>
i hacked the READ{12345} things into it before I figured out timeline() and/or the way to du synchronous stuff in FSM.act().
<sb0>
fsm.delayed_enter may also be useful
<sb0>
but I'll have to look at it... haven't touch this code in a while
<whitequark>
slightly different shape and color but yes
<sb0>
those are dirt cheap... that one is 30E
<whitequark>
it has an 1/8" NPT inlet, epoxied in, that I forcibly unscrewed and replaced with a 1/8" to hose barb
<whitequark>
screwed into using teflon tape
<whitequark>
they're noisy, but cheap, and despite being made for A/C duty they can pump for days with no apparent issues
<sb0>
and you back a turbo with that?
<whitequark>
yeah
<whitequark>
I measured pressure at turbo inlet and it's within 1 OOM of ultimate pressure in 2 hrs
<whitequark>
rjo: redis is not a good idea for persistence
<whitequark>
it's sort of acceptable for some use cases as an in-memory store, but do keep in mind it's ultimately single-threaded (it's a feature) and while all of its operations alone have linear or logarithmic complexity...
<whitequark>
... that doesn't help you if you have lots of data, for example
<whitequark>
however, never ever store anything of value in redis, because it has relatively little measures to ensure your data is intact and it will, in fact, lose it
<sb0>
why is that any better than the python built-in types then?
<whitequark>
it's popular among startup webdevs because you usually run several (single-threaded or effectively single-threaded) appserver processes and this lets you share the cache
<whitequark>
there is also usually little data of any value, so...
<whitequark>
rjo: as a first approximation, I would go with postgres.
<mithro>
Has anyone come across migen test "test_replace (migen.test.test_fifo.SyncFIFOCase)" failing? All the other tests seem to pass
<sb0>
passes here
<sb0>
I'm at commit c6904f9d63302daff3b2ae091cde199dac0b8a51
<sb0>
did the pep8 conversion break something?
<mithro>
sb0: it passes on most of my machines
<mithro>
sb0: just fails on the other machine
<mithro>
the place where it seems to diverge is on the second clock cycle where reading top.dut.syncfifo_re returns 0 rather than 1
<sb0>
interesting bug. no, I haven't seen it
<sb0>
same iverilog version?
<mithro>
sb0: looks like it's an older iverilog version - is there a minimum requirement?
<sb0>
yes, but it's a version from early 2012
<sb0>
and with older versions, all simulations break completely
<sb0>
we should rewrite that simulator in python and radically get rid of iverilog issues...
mumptai_ has quit [Remote host closed the connection]
FabM has quit [Quit: ChatZilla 0.9.91.1 [Firefox 37.0.1/20150402191859]]
FabM has joined #m-labs
FabM has quit [Quit: ChatZilla 0.9.91.1 [Firefox 37.0.1/20150402191859]]
<rjo>
whitequark: sounds like redis persistence would be at least as reliable/fast as the one we are doing. and it is not really lots of data. 1e3-1e5 keys <100MB total. resore from backups would be sufficient for us as well afaict.
<rjo>
sb0: i was playing with it, yes. but not a heavy user.
<rjo>
sb0: re s6ddrphy, phase_sel: do you see any way to make this faster apart from changing the phase of the _half clock? sometimes ise misses it by a few ps.
<rjo>
ah. maybe sneaking another cycle and shifting the others.
mumptai has quit [Quit: Verlassend]
aeris_ has quit [Ping timeout: 244 seconds]
aeris_ has joined #m-labs
aeris has quit [Ping timeout: 244 seconds]
aeris has joined #m-labs
antgreen has quit [Read error: Connection reset by peer]