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
<GitHub107>
[artiq] sbourdeauducq commented on issue #778: The major source of additional latency in SRTIO is the output/sorter stage after the FIFOs (a few RTIO clock cycles as I mentioned in the first post). DRTIO latencies are not significantly affected by SRTIO, and are dominated by the transceivers. https://github.com/m-labs/artiq/issues/778#issuecomment-325521057
<GitHub77>
sinara/master 9019ee5 Greg: HW ready for production
<GitHub150>
[artiq] sbourdeauducq commented on issue #813: It seems we can just switch the RTM FPGA to slave serial mode by changing the Mx resistors, and then the Xilinx-designed daisy chain loading should work. @gkasprow do you confirm? https://github.com/m-labs/artiq/issues/813#issuecomment-325524871
halfr has joined #m-labs
<sb0>
whitequark, what's the current status of TCP?
<whitequark>
sb0: I did everything I could do except a) segment reassembly b) a change in the way input packets are handled that I'm fixing right now c) the bug in the retransmit handling code that was the reason I reverted the last ARTIQ commit
<whitequark>
sb0: I'm not so convinced about ACPI anymore
<whitequark>
the server ARM market is moving from devicetree to ACPI because vendors want a stable interface they can provide, not track kernel versions indefinitely
<whitequark>
maybe ACPI isn't perfect here, but you can write DSDT right, and it's debatable whether one-off code with workarounds only relevant to one specific board should be maintained forever in the kernel
<whitequark>
russell king certainly isn't happy about that
<whitequark>
even EFI has an elegant foundation in it if you look, it's mostly that it's not designed to be implemented by morons and still work reliably and safely, and the vendor people writing firmware *are* morons
rohitksingh_work has joined #m-labs
<GitHub76>
[smoltcp] whitequark commented on pull request #34 18bd3d6: I'm uncomfortable about this ambiguity, having two separate paths for resetting and creating a default member. How about making `Resettable` imply `Default` instead? https://git.io/v5Zoj
<GitHub40>
[smoltcp] whitequark commented on pull request #34 18bd3d6: I'd prefer having a single method and optionally compiling in including the `ManagedSlice::Owned` branch. https://git.io/v5Zoh
<GitHub145>
[smoltcp] whitequark commented on pull request #34 18bd3d6: This seems to go completely against the spirit of a ring buffer. Why do you need this? https://git.io/v5Zop
<GitHub20>
[smoltcp] whitequark commented on pull request #34 18bd3d6: Weird to have `capacity()` but not `len()`. ... https://git.io/v5ZKe
<GitHub109>
[smoltcp] whitequark commented on pull request #34 18bd3d6: Do you need `Copy`? I think `mem::swap` or even `slice::swap` is enough to implement the expansion. https://git.io/v5Zox
<GitHub92>
[smoltcp] whitequark pushed 1 new commit to master: https://git.io/v5ZKk
<GitHub92>
smoltcp/master 2354e0b whitequark: Clarify a function name.
<travis-ci>
m-labs/smoltcp#182 (master - 2354e0b : whitequark): The build passed.
<GitHub48>
[smoltcp] whitequark commented on pull request #34 18bd3d6: I guess that's twice as much work so the Copy bound is fine. https://git.io/v5ZKn
<whitequark>
sb0: btw hk weather is finally bearable so I'll try to get to SSP and pick up sayma stuff today
<whitequark>
anything else you need besides media converter?
<GitHub18>
artiq/sinara 60ad36e Florent Kermarrec: gateware/serwb: generate wishbone error on wishbone slave when access while link is not ready
<GitHub18>
artiq/sinara 89558e2 Florent Kermarrec: gateware/serwb: for the initial version set delay in the center of the valid sampling window and don't use phase detectors...
<_florent_>
sb0: I've commited a serwb version that should work while I'm investigating on the phase detectors (delays are found by looking at the valid sampling window and set sampling in the middle of it)
<_florent_>
sb0: test_etherbone simulation taken from artiq is working here
rohitksingh_work has quit [Read error: Connection reset by peer]
<_florent_>
larsc: thanks for the ADI JESD204 link.
key2 has quit [Ping timeout: 260 seconds]
rohitksingh has joined #m-labs
<sb0>
_florent_, test_etherbone working after your two commits, or was it working before (at 26a11a2)?
<sb0>
_florent_, what happens if the link goes down in the middle of a wishbone transaction?
<sb0>
okay the test completes. my computer is just slow
<sb0>
self.comb += serwb_etherbone.wishbone.ready.eq(serwb_init.ready) << was that something that i missed out and could cause the code not to work on the boards?
<sb0>
also this sort of thing should be pushed into serwb and not be user exposed
<GitHub110>
artiq/sinara 9ba5009 Florent Kermarrec: gateware/test/serwb: use unittest for in test_etherbone
<key2>
whitequark: where is the link to the compressor, the one u put on twitter is not the kit
<whitequark>
key2: click on the 4th small rectangle with pic under the product name
<key2>
ahhh
<key2>
and what gas do you use with that ? i mean what is it for originally ?
<whitequark>
originally?
<whitequark>
it's designed for this kind of use
<whitequark>
andit's r134a
<key2>
r314a is used in ACs
<key2>
have to find something to make a can chiller :)
<whitequark>
well yes it's a typical vapor compression refrigeration system
<key2>
actually I had a project in which i was looking for a cooling system. I wanted to use gallium in order to see if it's possible to make PCB: make it melt with heat, and flat like a sheet, then cool it so it harden. at that stage use a photoresist film/painting and do the classical lythography. once done, try to deposit a layer of copper using copper electrolysis. and finally use a laptor or some fiberglass matterial on which you stick t
<key2>
finally heat it up so the gallium melt and you remove your sheet
<key2>
do you think it could be possible to have high definition pcb this way ? as there is no etching involved
<key2>
s/laptor/kapton
<whitequark>
I think that's a horrible idea, and also you don't need any sort of cooling system there
<whitequark>
just use a bucket of ice
<key2>
why is it horrible ? :)
<whitequark>
what's the problem with etching?
<key2>
you can't go < 0.1mm clearance
<key2>
because the copper get etched from under the photoresist
<rjo>
whitequark: is any of the saymas connected to lab powered?
<whitequark>
rjo: I have not been to the lab yet, was working on smoltcp today
<whitequark>
so probably not
<whitequark>
if you want it urgently I can take a taxi I think
<rjo>
whitequark: no. not urgent. but tomorrow would be good.
<whitequark>
okay
<key2>
I really wonder how they make those 300A pcb in graphic cards. power dissipation is really a problem
<cr1901_modern>
Three HUNDRED amperes?!
<whitequark>
that's common for CPUs too...
<key2>
yeah
<whitequark>
think about 200W at Vcore=0.7V or 1.2V or something
<key2>
1v > 300A
<cr1901_modern>
yes, but I thought current is the major indicator of how much a trace can handle. So going across a pcb would need fat traces
<cr1901_modern>
(very fat*)
<key2>
YES !
<whitequark>
or thick traces
<key2>
and even in 3Oz
<whitequark>
or you could deposit solder over it
<whitequark>
or you could have like 12 layers and massive planes
<cr1901_modern>
In any case, fair points. Just don't really think about it
rohitksingh has quit [Quit: Leaving.]
sb0 has quit [Ping timeout: 246 seconds]
sb0 has joined #m-labs
early has quit [Quit: Leaving]
early has joined #m-labs
mumptai has joined #m-labs
<sb0>
_florent_, I'm fine without the phase detector, but does your delay-finding code handle all cases e.g. when the delay is already in the working region upon startup, and wraparounds
<sb0>
can we have some test bench for that? (doesn't need to actually use the xilinx idelay, some mockup e.g. in pure migen is fine)
<whitequark>
sb0: item (b) done
<GitHub60>
[smoltcp] whitequark pushed 2 new commits to master: https://git.io/v5cOO
<GitHub60>
smoltcp/master 39464a5 whitequark: Compute soft deadline in poll() and use nonblocking sockets....
<GitHub60>
smoltcp/master 4663060 whitequark: Reset the timer transitioning from TCP FIN-WAIT-1 to FIN-WAIT-2....
<whitequark>
ok, let me see item (c)
<whitequark>
I think I've seen the solution to it in a dream yesterday, but forgot
<whitequark>
Kekule must be turning in his grave
<travis-ci>
m-labs/smoltcp#183 (master - 39464a5 : whitequark): The build passed.
<GitHub60>
[smoltcp] batonius commented on pull request #34 18bd3d6: I don't think we can do it, otherwise, I would have gone with `Default` when I refactored `RingBuffer` out. Currently, we're using `RingBuffer` to store `PacketBuffer` for UDP and Raw sockets, and these contain `Managed<'a, [u8]>`, meaning we can't just `Default::default()` them, so we use `Resettable` to reset the other fields. Yet for 90% of the potential use cases `Default::default()`
<GitHub197>
[smoltcp] whitequark opened issue #35: Use a newtype instead of u64 for timestamps https://git.io/v5ccS
<GitHub42>
[smoltcp] whitequark commented on pull request #34 18bd3d6: > Now I think of it, maybe we should just get rid of Resettable and initialization of elements in the constructors altogether?... https://git.io/v5cch
<GitHub159>
[smoltcp] batonius commented on pull request #34 18bd3d6: I was using `RingBuffer` as a queue of dirty sockets and I needed to delete sockets from the queue once they're removed from the main container. I agree its usefulness isn't evident, but it could be handy to have. https://git.io/v5cWv
<GitHub110>
[smoltcp] whitequark commented on commit 39464a5: @batonius By the way, after this commit:... https://git.io/v5cWr
<GitHub105>
[smoltcp] batonius commented on pull request #34 18bd3d6: We only reset elements in the `RingBuffer`'s constructor tho, `try_enqueue` explicitly takes a function to reset the new element, and `enqueue` doesn't do it at all. https://git.io/v5clI
<GitHub195>
[smoltcp] whitequark commented on pull request #34 18bd3d6: Exactly. Suppose application A put key material all over the socket. Then, the socket, without being reset, is passed to application B. This application can now call `.enqueue()` and read from the buffer what it should have never seen. Ideally we'd have something like `&write [u8]` but alas. https://git.io/v5c8e
<GitHub195>
[smoltcp] whitequark commented on issue #19: OK, I've very much warmed up to your smart pointer idea after thinking more about it. Essentially, existing interface (`socket_set.get_mut().as_socket::<>()`) already places the exact same restrictions (a `&mut` borrow of `SocketSet`) and is somewhat more ugly. So, let's get a few gradual, uncontroversional changes in!... https://git.io/v5c8D
<GitHub182>
[smoltcp] batonius commented on pull request #34 18bd3d6: This is an interesting point I didn't think about, but I think we should just make `RingBuffer`'s methods pub(crate) since a user doesn't need to use them directly. It's impossible to get access to the old data via sockets' methods because they all limited by the length of the data in the buffer. Besides, I think memsetting buffers all the time would be too costly. https://git.io/v
<GitHub177>
[smoltcp] whitequark commented on pull request #34 18bd3d6: Of course it's possible, just use `tcp_socket.send()`, which directly calls `enqueue()`... https://git.io/v5c4N
<travis-ci>
batonius/smoltcp#49 (master - 39464a5 : whitequark): The build passed.
<GitHub69>
[smoltcp] batonius commented on pull request #34 18bd3d6: `TcpSocket` doesn't use `RingBuffer` right now, but you're right, you can get access to the old data via `UdpSocket::send()`. So the current problem is twofold - we don't call `reset` on element reuse and we don't memset the buffer in `reset`. I guess I'll do it then. This means the `Resettable` bound is now container-wide and there's no point in `with_default` constructor.... https:
<GitHub10>
[smoltcp] whitequark commented on pull request #34 18bd3d6: It's only legal for memset to be removed right before deallocation, and we don't have that, so it's not a concern. https://git.io/v5c08
ohama has quit [Ping timeout: 240 seconds]
mumptai has quit [Remote host closed the connection]
<GitHub19>
[smoltcp] batonius commented on issue #34: - Removed `remove` method and `with_default` constructor.... https://git.io/v5c2P
ohama has joined #m-labs
<sb0>
rjo, for combining multiple PCB SPI buses into one inside the FPGA, I guess I can broadcast clk/mosi lines to all devices, put pulldowns on miso lines, and OR all miso lines before sampling the result
<sb0>
sounds good?
<sb0>
whitequark, if we have a CPU with separate memories for data and code, can rust/llvm target it? e.g. reading the program memory would not be allowed
<sb0>
mithro, there is ac97 core in milkymist, you could rewrite it if that helps