01:11 <cr1901_modern> whitequark: https://github.com/m-labs/migen/commit/3d8a58033ea0e90e435db0d14c25c86ee7d2fee2#diff-d6382a12ba33dcf1acee54c4d36afb52R113 Why not change the template directly? The substitution vars are mainly for variables that the build function creates as part of file generation

01:12 <cr1901_modern> you can always set synth_opts directly

01:12 <cr1901_modern> so adding synth_opts just feels like an extra step as opposed to modifying the template

08:01 <rjo> sb0: i have a few more bits pending. some groundwork has already landed. give me until sunday to commit a couple things. then we can divide up the rest.

12:02 <GitHub-m-labs> [artiq] ljstephenson opened issue #1205: SUServo: allow setting offset independently https://github.com/m-labs/artiq/issues/1205

12:03 <GitHub-m-labs> [artiq] ljstephenson commented on issue #1205: Oops - pressed enter early, please allow time for edit! https://github.com/m-labs/artiq/issues/1205#issuecomment-444849094

15:42 <sb0> whitequark: what do you think of adding stack overflow detection to mor1kx/misoc/rust/artiq firmware?

15:43 <sb0> you can still trash memory right now by putting a large buffer on the stack ...

15:49 <whitequark> sb0: we were supposed to do that

15:49 <whitequark> you even made a guard page module

15:49 <whitequark> the problem is that mor1k does not trap on reads

15:49 <whitequark> i.e. it just ignores bus error on reads

15:49 <whitequark> I think I even have a branch with stack overflow detection somewhere... the problem is that it didn't really work well

15:50 <whitequark> because of that mor1k issue, that is

16:12 <GitHub-m-labs> [artiq] tballance commented on issue #1205: This sounds like a simple feature but would help with usability. From my point of view it would be nice for experiment code to be able to seamlessly use Urukul or SUServo. https://github.com/m-labs/artiq/issues/1205#issuecomment-444927749

16:23 <sb0> whitequark: can't there be a designated stack pointer register in the CPU, with an exception raised if it goes outside certain boundaries?

16:24 <sb0> raised in hardware that is

16:37 <whitequark> sb0: in principle, yes, but do we want to run a fork of mor1kx?

16:38 <whitequark> there is already a designated stack pointer register...

16:38 <whitequark> R1 I think?

16:38 <whitequark> LLVM (and so Rust) always assume that R1 has a sane value, and rely on it, and preserve this invariant

16:38 <whitequark> so it would be possible to add some logic that raises an exception if R1 goes out of range

16:39 <whitequark> I'm not sure if I want to hack this into mor1kx though, it has a lot of pretty gross Verilog and such

16:39 <whitequark> also not sure about timing

16:47 <sb0> regarding timing, you can probably pipeline it

16:51 <whitequark> so the register file stays in BRAM (it's in BRAM now, right?) and there is a comparator that extracts R1 accesses specifically?

16:55 <sb0> yeah, that's an option. i don't know if it's in BRAM.

16:56 <sb0> you can probably shave some bits from the comparator and improve timing/area by imposing that the stack limits should be some powers of 2

16:56 <sb0> *aligned to some powers...

16:56 <whitequark> so it would be a compile time parameter?

16:56 <sb0> yes

16:56 <whitequark> that works