06:31 <_florent_> rjo, sb0: about non power of two memories, it can be optimal for small memories not implemented in block ram, but implemented in block ram there is no magic and we will loose the unused part of the blockram

06:31 <_florent_> rjo, sb0: but sb0 is right, there is no reason to try to do that in the code, that's better to let the synthesis tool do it

12:52 <cr1901_modern> sb0: ping when you get the chance (warning: this question's involved)

12:54 <sb0> cr1901_modern, ask away...

12:56 <cr1901_modern> I'm porting the SPI peripheral from ARTIQ to MiSoC; it's more feature complete than the current core. But it depends on the wishbone ACK signal to stall the bus in case there's a pending transfer from the data register to the shift register >>

12:57 <cr1901_modern> As per rjo's instructions, I want to put a CSR wrapper around the artiq core, but the CSR bus has no provisions for stalling the bus. Is there a way from within MiSoC to intercept Wishbone2CSR during finalization to add custom stalling code?

12:58 <cr1901_modern> I really think silently dropping bytes to be written is a bad idea, and querying a "pending transfer" register each time I write data seems wasteful.

13:02 <sb0> CSRs don't support stalling, for simplicity reason. querying a status register isn't much worse than stalling.

13:05 <cr1901_modern> Alright, very good then. I'll take your word for it. I'm under the impression the wishbone SPI core is designed as fast as possible b/c of ARTIQ's constraints? It only stalls when a very specific condition is met.

13:06 <cr1901_modern> I.e. the extra complexity is worth not stalling when we don't have to :P.

13:07 <larsc> stalling peripherals are terrible

13:12 <cr1901_modern> larsc: Why do you say that?

13:15 <larsc> gives you unpredictable behavior

13:16 <larsc> and if you stall to long you get a sigbus and everything crashes

13:16 <larsc> (if your interconnect has a timeout)

13:16 <larsc> too long

13:16 <cr1901_modern> I'm not sure how signals are implemented in any *nix, tbh :(

13:17 <larsc> what's ok if you pipeline your reply and it e.g. always takes 2 clock cycles

13:17 <cr1901_modern> I suppose branch prediction would offset the penalty for having to query a status register before sending data off

13:17 <cr1901_modern> I'll probably add a "write was eaten" status bit to this core

13:18 <larsc> it depends, do you expect it to be busy or ready most of the time when a write happens?

13:20 <cr1901_modern> I'm guessing the average OS would buffer writes to an SPI peripheral, there's no point in trying to to send more than one byte per time slice, so prob on average it'll be ready.

13:22 <larsc> in the context of the speed of the spi clk the extra read should probably be negligible anyway

13:26 <cr1901_modern> As usual, I'm overthinking this/bikeshedding :

13:26 <cr1901_modern> :/*

14:35 <sb0> i.e. generate non-standard verilog

14:59 <rjo> _florent_: limited BRAM and the synthesis tool being unable to infer non-power-of-two BRAM as such is definitely a reason.

16:01 <sb0> apple used to have interesting content on their website

16:01 <sb0> http://web.archive.org/web/19980713005709/http://webstuff.apple.com/users/chriskra/Private/Laser.htm

16:39 <whitequark> that's not apple, that's apple's free web hosting...

17:00 <sb0> for apple employees

17:25 <whitequark> oh, is it? interesting

18:33 <bb-m-labs> build #212 of artiq-pipistrello-nist_qc1 is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-pipistrello-nist_qc1/builds/212