bluespec.com

New Release 2012.01.A is posted

kczeck — Fri Feb 03, 2012 11:18 am

Author: kczeck

Posted: Fri Feb 03, 2012 11:18 am

The latest Bluespec release 2012.01.A is available to registered users of the forum via Software Releases at http://bluespec.com/forum/viewtopic.php?t=306. You must be logged in to the forum to see and download the files.

Bluespec Tools & Doc Release - 2012.01.A (LATEST)

crimsoncardinal — Mon Jan 30, 2012 6:06 pm

Author: crimsoncardinal

Posted: Mon Jan 30, 2012 6:06 pm

Minimum Recommended System:

CPU -- 1 GHz Pentium x86 processor (32 bit or 64 bit)
RAM -- 512 MB memory for labs, 1 GB memory for design work
Disk -- 512 MB free disk space
OS -- 32-bit or 64 bit RedHat Enterprise 4.0

Bluesim has the additional requirement:
32-bit or 64 bit: gcc 3.4 - 4.6

Verilog simulation tool
Verilog synthesis tool

FlexLM License Server Host
Solaris (32-bit only) or Linux Enterprise, (32 or 64 bit)
Flex Software included with Bluespec Release.

BSV-to-SystemC requirements:
32 bit: gcc 3.4-4.6, SystemC 2.11, 2.2.0
64 bit: gcc 3.4-4.6, SystemC 2.2.0

Development Workstation Graphs requirement:
TclDot 2.21 or later

build utility requirement:
python 2.4 or later

Note: the above is the "standard" platform, but the Bluespec tools
also work on other Unix-like platforms; please contact us for details
if necessary.

License

Bluespec is licensed using the FlexLM system. To enable the Bluespec
environment, you should have received (in a separate email) a license
file, which must be installed on the license manager host. The
util/flexlm directory contains additional instructions on installing
the license manager and license file.

BSV Training Labs

kczeck — Tue Jan 24, 2012 3:26 pm

Author: kczeck

Posted: Tue Jan 24, 2012 3:26 pm

This lab leads you through basic aspects writing a BSV program by building a DMA controller. The lab uses the Bluespec Development Workstation for Bluesim and Verilog simulations.

BSV Tutorials

seshukumar6039 — Sat Jan 21, 2012 5:03 am

Author: seshukumar6039

Posted: Sat Jan 21, 2012 5:03 am

package seshu;

interface Samplerd;
method Action loadvalue(Bit#(10) newval);
method Action loaddata(Bit#(1) dat);
method Bit#(10) count();
method Bit#(10) read();
method Action increment();
method Bit#(1) dQrd();
method Bit#(1) dQwr();
method Bit#(1) dQrst();

endinterface

(* synthesize *)

module mkread(Samplerd);
Reg#(Bit#(10)) value <- mkReg(0);
Reg#(bit) busread <- mkReg(0);
Reg#(bit) buswrite0 <- mkReg(0);
Reg#(bit) data <- mkReg(0);
Reg#(bit) busrst <- mkReg(0);

rule level0(value >= 6 && value <= 70);
busread <= 1;
endrule

rule level1(value == 15);
data <= busread;
endrule

rule level11(data == 1);
if(value <= 6)
busread <= 0;
else
begin
busread <= 1;
end
endrule

rule level01(data == 0);
if(value <= 60)
buswrite0<= 0;
else
begin
buswrite0 <= 1;
end
endrule

rule level;
if(value>480)
begin
if(value<550)
busrst <= 1;
else
if(value<580)
busrst <= 0;
else
busrst <= 1;
end
else
busrst <= 0;
endrule

method Bit#(10) count();
return value;
endmethod

method Bit#(1) dQrd();
return busread;
endmethod

method Bit#(1) dQwr();
return buswrite0;
endmethod

method Bit#(1) dQrst();
return busrst;
endmethod

method Bit#(10) read();
return value;
endmethod

method Action increment();
value <= value + 1;
endmethod

method Action loadvalue(Bit#(10) newval);
value <= newval;
endmethod

method Action loaddata(Bit#(1) dat);
data <= dat;
endmethod

endmodule
endpackage
package sss;

interface Samplerd;
method Action loadvalue(Bit#(10) newval);
method Action loaddata(Bit#(1) dat);
method Bit#(10) count();
method Bit#(10) read();
method Action increment();
method Bit#(1) dQrd();
method Bit#(1) dQwr();
method Bit#(1) dQrst();

endinterface

(* synthesize *)

module mkread(Samplerd);
Reg#(Bit#(10)) value <- mkReg(0);
Reg#(bit) busread <- mkReg(0);
Reg#(bit) buswrite0 <- mkReg(0);
Reg#(bit) data <- mkReg(0);
Reg#(bit) busrst <- mkReg(0);

rule level0(value >= 6 && value <= 70);
busread <= 1;
endrule

rule level1(value == 15);
data <= busread;
endrule

rule level11(data == 1);
if(value <= 6)
busread <= 0;
else
begin
busread <= 1;
end
endrule

rule level01(data == 0);
if(value <= 60)
buswrite0<= 0;
else
begin
buswrite0 <= 1;
end
endrule

rule level;
if(value>480)
begin
if(value<550)
busrst <= 1;
else
if(value<580)
busrst <= 0;
else
busrst <= 1;
end
else
busrst <= 0;
endrule

method Bit#(10) count();
return value;
endmethod

method Bit#(1) dQrd();
return busread;
endmethod

method Bit#(1) dQwr();
return buswrite0;
endmethod

method Bit#(1) dQrst();
return busrst;
endmethod

method Bit#(10) read();
return value;
endmethod

method Action increment();
value <= value + 1;
endmethod

method Action loadvalue(Bit#(10) newval);
value <= newval;
endmethod

method Action loaddata(Bit#(1) dat);
data <= dat;
endmethod

endmodule
endpackage

Static elaboration and use of Multiplier Module

kevin5k — Wed Dec 14, 2011 12:28 am

Author: kevin5k

Posted: Wed Dec 14, 2011 12:28 am

Hi, I'm new to Bluespec and am trying to to replace existing MAC operations, for an FIR filter, with a pipelined multiplier which has the following code:

Code:

FixedPoint#(16,16) accumulate =
   c[0] * fromInt(sample)
   + c[1] * fromInt(r[0])
   + c[2] * fromInt(r[1])
   + c[3] * fromInt(r[2])
   + c[4] * fromInt(r[3])
   + c[5] * fromInt(r[4])
   + c[6] * fromInt(r[5])
   + c[7] * fromInt(r[6])
   + c[8] * fromInt(r[7]);

I seek advice as to how can I break apart the single rule (above) into multiple rules. First rule will initiate 9 multiplication operations using the putOperands method for each multiplier instance. Second rule will collect the results using getResult and perform the sum of those. Simple example codes will be most helpful for my understanding. The multiplier code that I'm trying to implement is as follows:

Code:

(* synthesize *)
module mkMultiplier (Multiplier);

FIFO#(FixedPoint#(16, 16)) results <- mkFIFO();

method Action putOperands(FixedPoint#(16, 16) coeff, Int#(16) samp);
results.enq(coeff * fromInt(samp));
endmethod

method ActionValue#(FixedPoint#(16, 16)) getResult();
results.deq();
return results.first();
endmethod

endmodule

Unbound Variable

kevin5k — Wed Dec 14, 2011 12:12 am

Author: kevin5k

Posted: Wed Dec 14, 2011 12:12 am

@quark: Thanks for the advice

quark wrote:

You should change r0 (and r1, r2, etc) to r[0] (and r[1], r[2], etc). The error about "unbound variable" means that you're using a variable name that was never declared anywhere (it was never "bound" to a value). You never declared a variable "r0".

Optional parameters

mcadler — Tue Dec 06, 2011 6:13 pm

Author: mcadler

Posted: Tue Dec 06, 2011 6:13 pm

Yes, that makes sense. We've already done something similar for passing data between modules across a FIFO where we want to be able to plug in different instances of the code at either end and have the flexibility to update the data structure without changing every instance.

Thank you.

BlueSim WaveViewer Problem

ewc — Tue Dec 06, 2011 11:51 am

Author: ewc

Posted: Tue Dec 06, 2011 11:51 am

Hi Kevin,

I am not very familiar with the details of Mentor tools, but I do believe that they support .vcd file. VCD (value change dump) files are an eda standard and I have never seen a eda tool which does not support them. All tools seem to have a proprietary format for improved performance. Bluesim generates a standard vcd file so will be able to used with Mentor's tools.

The feature that is not supported for Mentor's wave view is Bluespec decoration of signals with type and field information.

Ed.

Synthesizable, parametrizable module port width

vennsa — Fri Nov 18, 2011 7:01 pm

Author: vennsa

Posted: Fri Nov 18, 2011 7:01 pm

Okay. Thank you

Renewal of topic - use of AXI IP provided by Bluespec

ganeshgarg — Tue Nov 15, 2011 8:01 am

Author: ganeshgarg

Posted: Tue Nov 15, 2011 8:01 am

Thanks very much. Any help with the AXI issue is vital for me right now.

Use of AXI IP provided by Bluespec

ganeshgarg — Wed Nov 09, 2011 5:42 am

Author: ganeshgarg

Posted: Wed Nov 09, 2011 5:42 am

I forgot to mention in the previous mail - Thanks very much for responding to my query.

Scemi with XUPV5 and PCIe

hadar_agam — Thu Nov 03, 2011 3:31 pm

Author: hadar_agam

Posted: Thu Nov 03, 2011 3:31 pm

XUPV5 is one of our supported platforms, so creating a system like you are describing is fairly straightforward. Our EmVM document (in $BLUESPECDIR/../doc/BSV/emVM.pdf) is the document that you are seeking, which describes the full flow and many options.

You might want to use the build script, specifying xupv5 as a target-platform.
(type "build --doc" in a shell for more info).

Nesting a vector of interfaces

quark — Tue Nov 01, 2011 1:46 pm

Author: quark

Posted: Tue Nov 01, 2011 1:46 pm

If you want to define them in a for-loop, you can declare a local variable which is a Vector of the interface, and assign to each element (in the for-loop) and then, at the end of the module you can define the interface with that local variable:

Code:

interface Ifc;
interface Vector#(8, Reg#(Bool)) regs;
endinterface

module mkMod(Ifc);
...
Vector#(8, Reg#(Bool)) ifcs;
for (Integer i=0; i<8; i=i+1)
ifcs[i] = interface
method Bool _read();
return ...;
endmethod
method Action _write();
...
endmethod
endinterface;
...
interface regs = ifcs;
endmodule

Why is Bit#(type n) more than bits?

chris — Fri Oct 07, 2011 12:38 pm

Author: chris

Posted: Fri Oct 07, 2011 12:38 pm

Quote:

But our customers are so used to the idea (inherited from Verilog) of doing arithmetic with bits, that I think there'd be a near-riot if we forbade it.

That's unfortunate, but I can understand their initial frustration.

Indeed using extended operation on Bits can get very confusing and I never did it before. And although the mere existence of the operations undermines the type system I was never really affected by it. Until I looked into the standard libraries where there are several situations where Arithmetic operations are used on Bits I was even convinced that adding Bits would throw and error.

E.g. I was very astonished when I saw the following (lib/BSVSource/Misc/BRAMFIFO.bsv):

Code:

BRAM_DUAL_PORT#(Bit#(l), t) memory <- mkBRAMCore2(memSize, False );

Reg#(Bit#(d)) rWrPtr <- mkReg(0);

[...]

(* fire_when_enabled, no_implicit_conditions *)
rule portA;
if (pwEnqueue) begin
memory.a.put(True, truncate(rWrPtr), wDataIn);
rCache <= tagged Valid tuple2(rWrPtr, wDataIn); // cache last write
rWrPtr <= rWrPtr + 1;
end
else begin
memory.a.put(False, truncate(rWrPtr), ?);
end
endrule

I even questioned myself if it is useful to use Bits as and BRAM index.

And as far as I know (modern) VHDL also has a very strict numeric type system, where you have std_logic_vector, unsigned and signed (and a few more). You also have to explicitely convert between these types and arithmetic operations are not defined on std_logic_vector, which is the basic bit representation.

I might be wrong here but I still have a very bad feeling about arithmetics on bits. It's true that with it beginners coming from Verilog can use bits intuitively right away, but just imagine somebody trying to assign a negative value to a bit and compare it afterwards with another bit variable. He might have a hard time to find his error especially when he is not yet used to the debug capabilities of bsv. In general it is very hard to get rid of bad practices when you have gotten used to them. Therefore I think we shouldn't implement features into the language that solely (it really is against the whole type safety principle) enable bad habits and should not allow them from the beginning. The example above shows that even core developers are affected by them.

Type system: Not worth to learn the details?

stoy — Fri Sep 30, 2011 9:06 am

Author: stoy

Posted: Fri Sep 30, 2011 9:06 am

Chris wonders whether Bluespec Inc. might be less "discouraging", in the official documentation, about advanced features such as typeclasses. He suggests that to use BSV well one needs to understand it, and that means being aware of all its features and how they are structured together into one coherent whole. Of course, from the ideal point of view he's right. And in fact learning any language is a non-terminating process -- one gets better at it all the time. That's also true about languages like English, or music (compare late Mozart with his earlier writing). The question is, how much is enough to get started effectively? And then, what resources are there, or should there be, for our users to do "lifelong learning", and what can the Company (with its limited resources) do to help?

Our position is that designers can use BSV pretty effectively after a training lasting just two or three days. And that's the kind of training we normally offer -- it sometimes expands to a week or so if we're also helping the trainees get to grips with their first project. In a training that short there's simply not time to cover everything. We feel that the most important thing to emphasize in our training is the concept of atomic transactions, as used in our rules and interface methods; and the idea that although many rules fire in a single clock cycle, the overall effect is as if they happened one at a time, in the so-called "logical execution order". We hope that other high-level features, which we don't have time to cover, will be gradually picked up later, as the designer's experience grows.

Our "BSV By Examples" book, too, is designed to help new users by showing them BSV in action, and giving them templates for dealing with many of the issues that turn up in the course of a design.

It would be quite different if we were teaching BSV over the course of a university term -- perhaps then we could even make understanding types a prerequisite, obtained from an earlier programming languages course. And there'd be time to go into all the details. But normally we don't have that luxury. That's why in the Reference Guide we want to reinforce the notion that a designer can do a whole lot after only the initial training, which is why we put the disclaimers there. But perhaps they could be worded a bit better -- we'll see what we can do.

Incidentally, Chris is correct about our type inspection facilities not dealing adequately with typeclasses and instances. This is something which is already on our enhancements list.

INVITATION

Chris and I have been having what seems to be a dialogue on this (and other topics). Can I invite others to join in? Tell us how we could do the training better; or what post-training resources would be useful. And maybe more pointers to explanations of some language features, not necessarily specific to BSV (such as the two Haskell Type Basics articles Chris pointed to).

TYPECLASSES

It remains the case, of course, that although you can do lots of good things after only the initial training, if you have had the chance to learn some of the advanced features you can do even more fantastic things. And, to come back to the detailed point Chris was making, it's true our documentation doesn't contain any examples of the sophisticated use of typeclasses. So, for interested readers, let me give a few examples.

(1) The DefaultValue package, in our release (see $BLUESPECDIR/BSVSource/Misc/DefaultValue.bsv). For examples of the use of this feature, also in the release, see the $BLUESPECDIR/BSVSource/Axi directory. AxiDefines.bsv contains declarations of some instances of DefaultValue, and AxiMaster.bsv some examples of their use.

(2) A more intricate example, the HList package, also in our release (see $BLUESPECDIR/BSVSource/misc/HList.bsv). This package is essentially transliterated from the equivalent package in the Haskell library, and "H" is for "heterogenous" -- it provides lists in which each element can be of a different type. So, since there are an infinite number of such list types, the set of them all has to be a typeclass. And since each of them has its own "head" and "tail" function types, they have to form typeclasses too. I'm afraid the package isn't very extensively commented -- but see what you make of it!

(3) The attached BuildVector package, which allows you to declare and initialize Vectors, in lines like
Vector#(5, UInt#(4)) = vec(7, 3, 8, 1, 11);
This is perhaps even more complicated, but it's very useful. You might ask why it isn't in our standard library. The answer is that, since it uses "advanced features", mistakes in its use might give rise to error messages which are unintelligible and therefore worrying to many of our users. In fact, I think that our typeclass error messages have improved since that decision was taken, so that we might revisit it. For example, if you get the number of elements different on the two sides of the definition, you still get an error message about provisos -- but now it ends with a strong hint as to what's gone wrong
(try it and see).

CONCLUSION

Finally, please don't hesitate to ask questions about any feature of BSV, advanced or otherwise, either on these forums or (if you prefer) to support@bluespec.com. If it prompts one of us (whether someone inside Bluespec or another user) to write a detailed reply, that might also have the extra value of becoming a draft of a new section of our documentation (subject of course to the permission of the author if non-Bluespec). The more traffic these forums see, the more useful they are!

Regards

joe stoy
Bluespec Inc.