<awygle>
promach: how many bits is "1"? how many bits is "0"?
<promach>
one bit '1' and one bit '0'
<awygle>
that's not what you wrote
<promach>
you mean I should have
<promach>
shift_reg <= {1'b1, i_data, 1'b0};
<promach>
??
<awygle>
yes
<awygle>
unqualified numeric constants in verilog are 32 bits wide
<promach>
I recompile, but still same error at line 62
<promach>
:|
<awygle>
you can often get away with ignoring this, because verilog will truncate, but you're concatenating before truncating in this case so you probably get the wrong result
<promach>
awygle: I will come back in half an hour
<promach>
seems to me line 29 is not the real source bug ?
<awygle>
promach: i'm not sure how the math rules work out for that assert, but i'd bet it's the same issue - ~0 is 32'hFFFFFFFF
<awygle>
i'd recommend being more explicit that you mean 10'h3FF
<promach>
awygle: let me try later. I got your message
<awygle>
... also, nothing actually resets shift_reg to ~0 when enable is low, at least in that image you sent me.
<promach_>
does this mean line 18 is the only culprit ?
<promach_>
awygle: I have got past this problem.
dys has joined #yosys
<ZipCPU>
promach: If you change the check on shift_reg to a check of whether or not it is equal to {(INPUT_DATA_WIDTH+PARITY_ENABLED+2){1'b1}} you will get past the problem of last night.
<ZipCPU>
Not sure if you did that or not.
<ZipCPU>
The next problem I had, looking at your code, was that you never constrained the enable line with any assumptions. Had you been meaning to do that?
<promach_>
ZipCPU: no, that if statement and assert() is wrong
<promach_>
I should not have done that assert()
<ZipCPU>
Remember what I said: assume inputs, assert internal state and outputs.
<promach_>
and awygle is right about 1'b1 and 1'b0
<promach_>
for lines 29 and 34
<promach_>
now I am stuck at another assert() in another module
<promach_>
:|
<ZipCPU>
Smile. This is just how development goes. ;)
cr1901_modern1 has joined #yosys
cr1901_modern has quit [Ping timeout: 240 seconds]
<promach>
ZipCPU: induction test is really frustrating
<ZipCPU>
Smile. This is just how development goes. ;)
<ZipCPU>
Yes, it can be.
<ZipCPU>
It's also a very fundamental part of formal verification, so ... it is worth understanding well.
<promach>
I am so irritated with how one bug comes after another
<ZipCPU>
Relax ... there's only one bug left. :)
<ZipCPU>
(There's always *only* one bug left ...)
<promach>
I do not feel and think so
<ZipCPU>
No, it's true. Why? Because it's the fundamental assumption of all debugging: there is never more than one bug in your code. If you didn't make that assumption, then you'd *really* struggle to debug *anything*.
<ZipCPU>
Basically: assume(a); assert(a); where (a) is (no_more_than_one_bug). It's always true--because you are always assuming it.
<promach>
maybe assuming such way would make me feel better in debugging
<ZipCPU>
Sure, go ahead! You are already assuming it any way, might as well acknowledge it.
<promach>
using hamster method to compute busy signal give me problems in induction test :|