06:27 <barmstrong> i'm having a lot of fun putting a five-stage DLX together with migen

06:28 <barmstrong> i've been using python's unittest module to run the Simulator on my modules, and it's been really nice getting immediate feedback

06:29 <barmstrong> i've used FPGAs a little in the past, but writing testbenches and then trying to verify them by eye was such a huge pain

06:29 <barmstrong> thanks again for this amazing lib!

07:00 <barmstrong> It presently only supports 'addi', but at least it has five stages, and it executes that one like a champ :)

07:51 <barmstrong> huh. if you assign a too-big signal to another, it just silently truncates? i just spent half an hour tracking down an off-by-one bit width issue :(

16:48 <sb0> barmstrong, yes, it silently truncates. would be easy to add a warning though.

16:49 <sb0> thanks for the feedback :)

16:49 <sb0> (the problem with the warning, however, is it would trigger on x.eq(x + 1), since the addition adds a carry bit)

16:51 <sb0> so... if you want to do it right, it's not that easy. only the "compare source and dest width" warning is easy.

16:56 <wpwrak> maybe have two sizes ? one the current one and the other the "user-selected" size. they would normally be the same but operations like +1 would not increase the "user-selected" size

16:57 <wpwrak> a warning could then by default check the "user-selected" size only. (and maybe add options for more or less severity)

21:50 <barmstrong> ok, yeah, I hadn't even thought of that. i guess if you wanted to be very explicit about width issues, you could set migen to a strict mode where you have to slice any add like that e.g. x.eq((x + 1)[0:32]) or whatever