bluespec.com

Re: About Reg# write/read conflict

wychen — Wed Dec 31, 2008 1:27 am

Author: wychen

Posted: Wed Dec 31, 2008 1:27 am

"language that doesn't affect the way you think about programming is not worth knowing" - Alan Perlis
It would be much more meaningful if you can design your hardware in a bluespec way. If you want to learn from examples, the MIT WiFi/WiMax design is a better starting point than the MIT H.264 design. The H.264 one seems pretty much like RTL and doesn't make full use of these advantages provided by bluespec.

Re: About Reg# write/read conflict

test001 — Mon Dec 29, 2008 9:16 pm

Author: test001

Posted: Mon Dec 29, 2008 9:16 pm

Thanks your reply!
Excuse me, I do not make oneself understood.
I want make a FSM by hand(learn from MIT's bsv-h264), so I let step for control. and there have two actions when step is (0-3) or (4-. one of set valid in cycles-0, other of read in cycles-4, I think this will work in verilog. I write two rules actions in one rule at the first, it work fine.
Next, I want use two rules to process, it has more pellucidly.
But when I use Reg#, Bsc can not do two rules fire both(I use -aggressive-conditions in my any demo always). I want get fill_data work in cycles(0-3) and check_data do nothing, cycles(4- like, but two rule fire both. this behavior match to verilog's module.
I read the document again, I found that ConfigReg like verilog's reg more. I change step to it, Bsc output as I had expected.

Need more information

jnewbern — Mon Dec 29, 2008 11:08 am

Author: jnewbern

Posted: Mon Dec 29, 2008 11:08 am

Test001,

I think you cut out too much from your example. As you've shown it there is no conflict. Check_data will be scheduled first and fill_data scheduled second. Can you give a complete small example so that we can reproduce your issue?

Are you running bsc with the -aggressive-conditions flag?

Your rules look like they're encoding a state machine on the "step" state. You might prefer to use the StmtFSM facility (documented in the reference manual) instead of writing out the FSM by hand.

Also, a rule that dispatches on a single value of a register like:

rule x;
case (val)
1: ...
endcase
endrule

can be more cleanly written as:

rule x if (val == 1);
...
endrule

Re: About Reg# write/read conflict

test001 — Sat Dec 27, 2008 9:57 pm

Author: test001

Posted: Sat Dec 27, 2008 9:57 pm

Excuse me, I forgot that BSV have "conflict_free" & "ConfigReg", I will try them next week.

About Reg# write/read conflict

test001 — Fri Dec 26, 2008 7:14 am

Author: test001

Posted: Fri Dec 26, 2008 7:14 am

In my test today, I found some Reg# read/write conflict.

Code:

rule fill_data;
case(step)
0: begin
valid <= ...;
end
...
endrule

rule check_data;
case(step)
4: begin
if (valid == 1)
do_somthing;
end
endrule

but after I check the verilog code, the two rule can not FIRE both, how can I solve this?
I found one way that read/write in check_data and use RWire# in fill_data. I think this a bad way, but it can be work fine.
How can I to get better way?