bluespec.com

typeclass BitExtend usage

patil.nikhil — Sun May 11, 2008 3:41 am

Author: patil.nikhil

Posted: Sun May 11, 2008 3:41 am

I think truncateLSB could only be used on Bit#() since there is no typeclass (like BitExtend) defined to overload it, but then of course, unpack(truncateLSB(pack(x))) will do the job. Despite being told that I'm not supposed to, I still love pack/unpack

How to use RevertingVirtualReg?

jnewbern — Tue May 06, 2008 10:34 am

Author: jnewbern

Posted: Tue May 06, 2008 10:34 am

RevertingVirtualReg is a very specialized module which is only rarely needed. It implements a register interface but does not create a flop in the synthesized hardware. It is used in cases where you want the scheduling constraints of a register (usually to work around the lack of scheduling attributes on methods) but do not want any hardware generated.

The "Reverting" part of the name indicates that the value at cycle boundaries is a constant (if there are multiple writes within a cycle, the last one always reverts to the initial value). The "Virtual" part of the name indicates that there is no underlying hardware (it is synthesized as a constant, not a flop). The "Reg" part of the name indicates that it provides a Reg interface.

Bit#(0) weirdness

jnewbern — Tue May 06, 2008 10:26 am

Author: jnewbern

Posted: Tue May 06, 2008 10:26 am

This was determined to be a bug in the compiler, where the implicit condition associated with a zero-width value is being lost.

A workaround for now is to explicitly include the condition using the FIFOF interface's notFull and notEmpty methods for zero-width FIFOs.

floating point

jnewbern — Tue May 06, 2008 9:56 am

Author: jnewbern

Posted: Tue May 06, 2008 9:56 am

The next release of the tool will include support for floating-point values (specifically the SystemVerilog "real" type) as compile-time values. Support for synthesis of floating-point hardware circuits from "real" types is not included.

internal error caused by BVI and Tuple2

jnewbern — Tue May 06, 2008 9:46 am

Author: jnewbern

Posted: Tue May 06, 2008 9:46 am

The problem arises when attempting to return an interface from a method in a BVI import (tuples are treated internally like interfaces). We plan to fix the issue with tuples in the future, but a work-around for now is to return some other type in the Bits class from the imported method, such as a Bit#(2) or Vector#(2,Bit#(1)) and then make a wrapper module in BSV which unpacks the value into the desired tuple.

What does "restricted" mean?

patil.nikhil — Sun May 04, 2008 4:21 am

Author: patil.nikhil

Posted: Sun May 04, 2008 4:21 am

As I understand it, it means that it is illegal to have these two methods in the same rule, but if they are in different rules, the rules will be allowed to fire in the same cycle, sequenced as specified.

Code:

interface X;
method Action one();
method Action two();
endinterface
(*synthesize*)
module mkX(X);
Reg#(int) a <- mkReg(0);
method Action one();
a <= a + 1;
endmethod
method Action two();
a <= 2;
endmethod
endmodule

(*synthesize*)
module mkT();
let x <- mkX;
rule r1;
x.one();
endrule
rule r2;
x.two();
endrule
//rule r3;
// x.one();
// x.two();
//endrule
endmodule

If you look at the schedule generated by this code, method one is sequenced before (restricted) two. This allows rules r1, r2 above to fire every cycle; but rule r3 craps out with: Rule `RL_r3' uses methods that conflict in parallel.

type error (T0020)

wychen — Thu May 01, 2008 12:50 pm

Author: wychen

Posted: Thu May 01, 2008 12:50 pm

Have you tried valueof(n)?
BTW, is Max#(n,0,n) really necessary?

adarsh wrote:

How can I extract the size 'n' of 't' into an integer variable in the following code?

Code:

function Action junk (t x) provisos( Bits#(t,n), Max#(n,0,n));
$display(" n = %d", n);
endfunction

how to use provisos?

wychen — Thu Apr 24, 2008 12:31 pm

Author: wychen

Posted: Thu Apr 24, 2008 12:31 pm

adarsh wrote:

the will fire condition for this rule will have

Code:

assign WILL_FIRE_RL_enqFIFO =
fifoc$FULL_N && fifoa1$EMPTY_N && fifoa2$EMPTY_N &&
fifob1$EMPTY_N &&
fifob2$EMPTY_N ;

here even though cond1 is false, if fifoa1 is empty the rule won't fire. What is the best way to handle such situations? is it possible to suppress implicit predicates?

You can try a command-line parameter of bsc "-aggressive-conditions". User guide contains more explanations.

BSV Application Notes

kczeck — Fri Apr 18, 2008 11:47 am

Author: kczeck

Posted: Fri Apr 18, 2008 11:47 am

The OCP foundation supplies standard libraries for implementing and interacting with OCP interfaces in SystemC models. This application note describes how to use these libraries with a BSV design which contains OCP interfaces or sub-interfaces, so that they can interact at the TLM-level with the SystemC environment in which they are embedded.

A SystemC model can be generated from a BSV design using the -systemc flag during the bsc link stage. The generated SystemC model has a clocked, signal-level interface which reflects the (flattened) top-level interface of the BSV design.

Multi-clock domain question

kapilvar — Fri Apr 18, 2008 7:58 am

Author: kapilvar

Posted: Fri Apr 18, 2008 7:58 am

these days i write the code for PS/2 keyboard interface in bluespec .....i m new in bluespec .....i am facing the problem of multiple clock ...any one can help me regarding this.....
actually i have to transfer the 8 bit of data one clock domain to the differnt clock domain ....

reg Verilog simulator

praghu_cool — Thu Mar 27, 2008 2:20 am

Author: praghu_cool

Posted: Thu Mar 27, 2008 2:20 am

thank you jhshao

Mac OS X version of BSC?

crimsoncardinal — Sun Mar 16, 2008 9:34 pm

Author: crimsoncardinal

Posted: Sun Mar 16, 2008 9:34 pm

We don't currently support a native version for MAC OS X and we don't currently have plans for a native version. We'll certainly give you a heads up if that should change.

I'll be bringing up BSC on Linux on VMWare Fusion on MAC OS X in the next few weeks, though agree it would be nice to have a native version.

Operating system support is largely a matter of market demand -- so we'll note your request.

Type checking on index of Vector

wychen — Wed Mar 12, 2008 2:11 am

Author: wychen

Posted: Wed Mar 12, 2008 2:11 am

Hmm. The example I gave above is not a good one.
The problem I faced is more like this:

Code:

UInt#(3) index = ?;
//(index is modified dynamically)
Vector#(4,Bit#(1)) arr;
let data = arr[index];

Since the index is modified dynamically, there is no way to check the validity in compile-time. However, in the generated Verilog file, the index is truncated to two bits since there are only 4 entries in arr. As a result, this hidden bit truncation and possible source of bug cannot be discovered by using nLint.
In my opinion, either bsc issues a warning or error at runtime indicating the bit-width of index is too wide and will be automatically truncated or just doesn't compile, or keep 3-bit index in generated Verilog file so the down-stream tools have the chance to discover this. I guess most Verilog simulators give X as an output then the index is out-of-range.
The ultimate solution would still be the run-time checking, and I'd like to see it implemented.

allocating more than one resource to a method?

patil.nikhil — Wed Mar 05, 2008 12:27 pm

Author: patil.nikhil

Posted: Wed Mar 05, 2008 12:27 pm

wychen wrote:

This is very similar to the first example. The only difference is that the argument of doit1() can be different, which should be fine. We would expect a 2-to-1 mux be synthesized in front of doit1 port. However, once you put the (* synthesize *) attribute back to mkAdd_2, it won't compile. This behavior is observed from bsc version in early 2007 till now.

I just realized that this is documented in the "known problems and solutions" document (doc/BSV/kpns.pdf) as problem#001: Mutually-exclusive uses of port-limited resources may be allocated inefficiently. The KPNS says that the workaround is to replace the if-else by:

Code:

x <= (z == 0) ? a.doit1(x,x) : a.doit1(z,z);

However, this does not work. Maybe the KPNS document is out-of-date.

Of course, just explicitly making sure doit1 is called exactly once does work.

Parallel compilation

wychen — Tue Mar 04, 2008 8:13 am

Author: wychen

Posted: Tue Mar 04, 2008 8:13 am

It would be cool if multiple cores can be utilized when compiling Bluespec code. This can be manually done by writing a Makefile and automatically generate dependency file like the example below. It would be even better if bsc can natively support this kind of parallelized compilation, so we don't have to write tricky gawk scripts.

Using this technique, the fresh compilation takes around only 40% of original time on a 8 core machine with 5 licenses.

Any comments are welcomed.

Code:

-include .depend

DEP = depend
$(DEP) : .depend
.depend : $(bsvsrcs) Makefile
cat $(bsvsrcs) | gawk '/^package/{sub(/;/,"",$$2);package=$$2;packages[package]=package}/^import/{sub(/:.*/,"",$$2);import[package,++iid]=$$2}END{for(x in import){split(x,sep,SUBSEP);if(packages[import[x]]) print sep[1]".bo : "import[x]".bo" }}' > .depend

BSC_COMP = bsc
BSC_OPTS = -u -elab -show-module-use -verilog -keep-fires -aggressive-conditions \
-relax-method-earliness -cross-info -v -show-schedule -show-range-conflict \
-opt-undetermined-vals -O -wait-for-license
BSC_OPTS2 = +RTS -K1024M

# Run the bluespec compiler

%.bo : %.bsv $(DEP) $(bsvsrcs)
$(BSC_COMP) $(BSC_OPTS) $< $(BSC_OPTS2) 2>&1 | tee $(basename $<).log
grep 'All packages are up to date' $(basename $<).log