bluespec.com

Defining HW Constraints in Bluespec

kevin5k — Thu May 10, 2012 7:13 am

Author: kevin5k

Posted: Thu May 10, 2012 7:13 am

quark wrote:

The Bluespec compiler doesn't work this way. The compiler isn't making design choices for you; the BSV language gives you complete control over the generated hardware.

If you want your design to only use 4 multipliers, then you would write the BSV source to only use 4 multipliers. So there are no directives to the compiler.

However, BSV does allow you provide automation, but it is done as part of the language and not as a compiler directive: If you want the number of multipliers to be a parameter that you can change, then you write the BSV code to be able to support differing numbers of multipliers and have the choice of architecture be chosen by a parameter. There are various ways to do this: (1) formal arguments to the module, (2) global parameters, (3) preprocessor macros (which can be provided to the compiler command-line). Options 1 and 2 are common, and there are various ways to go about them, too.

So, for instance, the PAClib library is written to provide convenient parameterized building blocks, to automate work for the designer. But the automation is written in the code for the PAClib, not by any special directives from the compiler.

If you're using library elements written by someone else, and it has been written with parameters, then you would provide the parameters in the way that they have chosen.

quark - Thank you for answering my question and help to clarify my perception on Bluespec's capabilities. Hope my post will be useful for others in a similar situation as me.

Clock gating BSV library modules

ewc — Wed May 09, 2012 3:32 pm

Author: ewc

Posted: Wed May 09, 2012 3:32 pm

Clock gates include more than just CLOCK_GATE ports. When analyzing the bluespec verilog library, many tool interpret, the EN signal (or ENQ or DEQ, etc) as a clock gate. If you consider the BRAM.v module , the EN signal is really a clock gate.

If you have a different specification for a BRAM with clock gateing in mind, then you will need to create your own "import BVI" module.

Ed.

Generate bounded random numbers (Randomizable?)

Mohsen — Mon Apr 30, 2012 10:47 am

Author: Mohsen

Posted: Mon Apr 30, 2012 10:47 am

Hi hadar_agam,

Thank you so much.

It was extremely helpful.

Regards
Mohsen

2012.01.A BRAMs are no longer inferred by Quartus II

ShepSiegel — Tue Apr 17, 2012 9:27 pm

Author: ShepSiegel

Posted: Tue Apr 17, 2012 9:27 pm

We observed and reported this on or about Feb 3. It is a thorny issue as the BRAM{1,1BE,2}.v modules provided must not just be IEEE standard Verilog; but they must satisfy the sometimes non-standard inference of the (imperfect, changing) FPGA vendor synthesis tools.

In our case the design "exploded" with Quartus wanting to make registers our of each MRAM word.

We have worked around the issue by using old copies of BRAM{1,1BE,2}.v for Quartus only. Your mileage may vary.

-Shep

Opaque types in interfaces

mcadler — Tue Apr 17, 2012 3:06 pm

Author: mcadler

Posted: Tue Apr 17, 2012 3:06 pm

I'm trying to break apart the current interface's insert() method into two parts so that the test() and set() are separate pieces. I could then use test() as a predicate to a rule.

The current interface allows that too, with the notSet() method, at the cost of doing the equivalent of test() twice and crossing fingers that the optimizer will remove the potentially large redundant code from notSet() and insert().

Here is the current code:

Code:

//
// Copyright (C) 2009 Intel Corporation
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License
// as published by the Free Software Foundation; either version 2
// of the License, or (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
//

// Library imports.

import Vector::*;
import RWire::*;

//
// Counting filters can be used to determine whether an entry is present in
// a set. All counting filters have both insert() and remove() methods.
// This module provides multiple implementations for sets of varying sizes.
// Smaller sets can use direct decode filters. Larger sets can use Bloom
// filters, which have more logic to deal with hashes but have good false
// positive rates with relatively small filter vector sizes.
//
// For automatic selection of a reasonable filter, use the mkCountingFilter
// module. It picks decode filters for smaller sets and Bloom filters for
// larger sets.
//

// ========================================================================

// COUNTING_FILTER
//
// All counting filters provide this basic interface.
//
// ========================================================================

interface COUNTING_FILTER#(type t_ENTRY);
// Clear filter
method Action reset();

// Attempt to insert a new entry. Returns true on success. If the filter
// already has the entry or a counter would overflow returns false.
method ActionValue#(Bool) insert(t_ENTRY newEntry);

method Action remove(t_ENTRY oldEntry);

// Test whether entry is busy
method Bool notSet(t_ENTRY entry);
endinterface

//
// mkCountingFilter --
// Pick a reasonable filter based on the entry set size. Uses a Bloom filter
// for large sets and a simple decode filter for smaller sets.
//
// If allowComplexFilters is true then larger filters, such as Bloom filters,
// may be allocated. If allowComplexFilters is false then only decode filters
// will be allocated.
//
module mkCountingFilter#(Bool allowComplexFilters, DEBUG_FILE debugLog)
// interface:
(COUNTING_FILTER#(t_ENTRY))
provisos (Bits#(t_ENTRY, t_ENTRY_SZ));

let filter = ?;

if ((valueOf(t_ENTRY_SZ) > 10) && allowComplexFilters)
begin
// Large sets use Bloom filters
COUNTING_BLOOM_FILTER#(t_ENTRY, 128, 2) bloomFilter <- mkCountingBloomFilter(debugLog);
filter = bloomFilter.countingFilterIfc;
end
else if (valueOf(t_ENTRY_SZ) > 7)
begin
// Medium sized sets share 2 bits per entry
DECODE_FILTER#(t_ENTRY, TDiv#(TExp#(t_ENTRY_SZ), 2)) decodeFilterL <- mkSizedDecodeFilter(debugLog);
filter = decodeFilterL.countingFilterIfc;
end
else
begin
// Small sets get unique bit per entry
DECODE_FILTER#(t_ENTRY, TExp#(t_ENTRY_SZ)) decodeFilterS <- mkSizedDecodeFilter(debugLog);
filter = decodeFilterS.countingFilterIfc;
end

return filter;
endmodule

// ========================================================================
//
// Decode Filter
//
// ========================================================================

//
// nFilterBits should be a power of 2! Decode filter exposes
// a counting filter interface for compatibility with the Bloom
// filter.
//
interface DECODE_FILTER#(type t_ENTRY, numeric type nFilterBits);
interface COUNTING_FILTER#(t_ENTRY) countingFilterIfc;
endinterface

//
// Decode filter with one bit corresponding to one or more entries.
// Insert and remove methods may both be called in the same cycle.
//
module mkSizedDecodeFilter#(DEBUG_FILE debugLog)
// interface:
(DECODE_FILTER#(t_ENTRY, nFilterBits))
provisos (Bits#(t_ENTRY, t_ENTRY_SZ),

Alias#(Bit#(TLog#(nFilterBits)), t_FILTER_IDX));

Reg#(Bit#(nFilterBits)) fv <- mkReg(0);

RWire#(t_FILTER_IDX) insertId <- mkRWire();
RWire#(t_FILTER_IDX) removeId <- mkRWire();

Reg#(Maybe#(t_ENTRY)) lastFailMsg <- mkReg(tagged Invalid);

function t_FILTER_IDX filterIdx(t_ENTRY e);
return truncateNP(pack(e));
endfunction

(* fire_when_enabled *)
rule updateFilter (True);
let fv_new = fv;

if (insertId.wget() matches tagged Valid .id)
fv_new[id] = 1;

if (removeId.wget() matches tagged Valid .id)
fv_new[id] = 0;

fv <= fv_new;
endrule

interface COUNTING_FILTER countingFilterIfc;
method Action reset();
fv <= 0;
endmethod

method ActionValue#(Bool) insert(t_ENTRY newEntry);
let id = filterIdx(newEntry);

if (fv[id] == 0)
begin
insertId.wset(id);
lastFailMsg <= tagged Invalid;
debugLog.record($format(" Decode filter INSERT %0d OK, idx=%0d", newEntry, id));
return True;
end
else
begin
// Only print insert FAIL message once
if (! isValid(lastFailMsg) || (pack(newEntry) != pack(validValue(lastFailMsg))))
begin
lastFailMsg <= tagged Valid newEntry;
debugLog.record($format(" Decode filter INSERT %0d FAIL, idx=%0d", newEntry, id));
end

return False;
end
endmethod

method Action remove(t_ENTRY oldEntry);
let id = filterIdx(oldEntry);
removeId.wset(id);
debugLog.record($format(" Decode filter REMOVE %0d, idx=%0d", oldEntry, id));
endmethod

method Bool notSet(t_ENTRY entry);
let id = filterIdx(entry);
return (fv[id] == 0);
endmethod
endinterface
endmodule

// ========================================================================
//
// Counting Bloom Filter
//
// ========================================================================

interface COUNTING_BLOOM_FILTER#(type t_ENTRY,
numeric type nFilterBits,
numeric type nCounterBits);
interface COUNTING_FILTER#(t_ENTRY) countingFilterIfc;
endinterface

typedef Vector#(nHashes, Bit#(nHashIndexBits))
BLOOM_FILTER_HASH_VEC#(numeric type nHashes, numeric type nHashIndexBits);

//
// Optimal number of hashes is probably 5 or 6, but that takes too much FPGA
// space.
//
typedef 4 BLOOM_COUNTING_HASHES;

//
// Counting Bloom filter up to 256 bits.
//
module mkCountingBloomFilter#(DEBUG_FILE debugLog)
// interface:
(COUNTING_BLOOM_FILTER#(t_ENTRY, nFilterBits, nCounterBits))
provisos (Bits#(t_ENTRY, t_ENTRY_SZ),

// nFilterBits must be <= 256 and a power of 2.
Add#(TLog#(nFilterBits), a__, 8),
Add#(nFilterBits, 0, TExp#(TLog#(nFilterBits))),

Alias#(BLOOM_FILTER_HASH_VEC#(BLOOM_COUNTING_HASHES, TLog#(nFilterBits)), t_HASH_VEC));

// Filter bits (counters)
Reg#(Vector#(nFilterBits, Bit#(nCounterBits))) bf <- mkReg(replicate(0));

// Insert and remove requests are passed on wires to a single rule so
// both methods may be called in the same cycle.
RWire#(t_HASH_VEC) insertVec <- mkRWire();
RWire#(t_ENTRY) removeId <- mkRWire();
RWire#(Tuple2#(Bit#(nFilterBits), Bit#(nFilterBits))) updateBits <- mkRWire();

Reg#(Maybe#(t_ENTRY)) lastFailMsg <- mkReg(tagged Invalid);

//
// computeHashes --
// Calculate the set of hashes for an entry id.
//
function t_HASH_VEC computeHashes(t_ENTRY entryId);
//
// Map however many entry bits there are to 32 bits. This hash function
// is a compromise for FPGA area. It works well for current functional
// memory set sizes. We may need to revisit it later.
//
Bit#(32) idx32;
Bit#(t_ENTRY_SZ) idx_orig = pack(entryId);
Integer b = 0;
for (Integer i = 0; i < 32; i = i + 1)
begin
idx32[i] = idx_orig[b];

b = b + 1;
if (b == valueOf(t_ENTRY_SZ))
b = 0;
end

// Get four 8 bit hashes
t_HASH_VEC hash = newVector();

hash[0] = truncate(hash8(idx32[7:0]));
hash[1] = truncate(hash8a(idx32[15:8]));
hash[2] = truncate(hash8b(idx32[23:16]));
hash[3] = truncate(hash8c(idx32[31:24]));

return hash;
endfunction

//
// updateFilter --
//
// Two part, single cycle rule to update the Bloom filter. The
// first rule consumes this cycle's insert and remove calls and constructs
// a pair of vectors of filter positions that will change. The second
// rule consumes those vectors as wires and updates the Bloom filter.
//
// While these rules are logically a single rule, combining them causes
// the Bluespec optimizer to attempt to figure out exactly which bits
// changed and the combinatorics grow quite large.
//

(* fire_when_enabled *)
rule updateFilter1 (True);
//
// Construct a vector of filter positions to increment.
//
Bit#(nFilterBits) bf_up = 0;

if (insertVec.wget() matches tagged Valid .hash)
begin
for (Integer i = 0; i < valueOf(BLOOM_COUNTING_HASHES); i = i + 1)
begin
bf_up[hash[i]] = 1;
end
end

//
// Construct a vector of filter positions to decrement.
//
Bit#(nFilterBits) bf_down = 0;

//
// Removal request comes in as the index to the filter instead of a
// set of hash buckets. This puts the computation of hashes in a single
// rule. We would do this for the insert request, too, except that
// the insert method returns a response that is a function of the hashes.
//
if (removeId.wget() matches tagged Valid .remId)
begin
let hash = computeHashes(remId);
for (Integer i = 0; i < valueOf(BLOOM_COUNTING_HASHES); i = i + 1)
begin
bf_down[hash[i]] = 1;
end

debugLog.record($format(" Bloom filter REMOVE input state, id=0x%x: %0d (%0d), %0d (%0d), %0d (%0d), %0d (%0d)",
remId,
hash[0], bf[hash[0]],
hash[1], bf[hash[1]],
hash[2], bf[hash[2]],
hash[3], bf[hash[3]]));
end

// Pass the update vectors to the next rule (same cycle)
updateBits.wset(tuple2(bf_up, bf_down));
endrule

(* fire_when_enabled *)
rule updateFilter2 (True);
//
// Consume the result of updateFilter1 and update the Bloom filter.
//

if (updateBits.wget() matches tagged Valid {.bf_up, .bf_down})
begin
Vector#(nFilterBits, Bit#(nCounterBits)) bf_new;

// A filter slot changes if only one of up and down is requested
let bf_changes = bf_up ^ bf_down;

for (Integer i = 0; i < valueOf(nFilterBits); i = i + 1)
begin
if (bf_changes[i] == 1)
// Position gets new value
bf_new[i] = bf[i] + ((bf_up[i] == 1) ? 1 : -1);
else
// Position unchanged
bf_new[i] = bf[i];
end

bf <= bf_new;
end
endrule

interface COUNTING_FILTER countingFilterIfc;
method Action reset();
bf <= replicate(0);
endmethod

method ActionValue#(Bool) insert(t_ENTRY newEntry);
let hash = computeHashes(newEntry);

//
// Update counters for the hashes. Compute two properties:
// all_set -- True iff all hashes were already set in the filter,
// indicating the index is already present.
// overflow -- True iff any counter would overflow.
//

Bool all_set = True;
Bool overflow = False;

debugLog.record($format(" Bloom filter INSERT input state, id=0x%x: %0d (%0d), %0d (%0d), %0d (%0d), %0d (%0d)",
newEntry,
hash[0], bf[hash[0]],
hash[1], bf[hash[1]],
hash[2], bf[hash[2]],
hash[3], bf[hash[3]]));

for (Integer i = 0; i < valueOf(BLOOM_COUNTING_HASHES); i = i + 1)
begin
let bucket = hash[i];

all_set = all_set && (bf[bucket] != 0);

let new_count = bf[bucket] + 1;
overflow = overflow || (new_count == 0);

if (new_count == 0)
debugLog.record($format(" Bloom filter bucket %0d overflow", bucket));
end

if (all_set || overflow)
begin
// Can't insert. Only print insert FAIL message once.
if (! isValid(lastFailMsg) || (pack(newEntry) != pack(validValue(lastFailMsg))))
begin
lastFailMsg <= tagged Valid newEntry;
debugLog.record($format(" Bloom filter INSERT FAIL"));
end

return False;
end
else
begin
debugLog.record($format(" Bloom filter INSERT OK"));
lastFailMsg <= tagged Invalid;
insertVec.wset(hash);
return True;
end
endmethod

method Action remove(t_ENTRY oldEntry);
removeId.wset(oldEntry);
endmethod

method Bool notSet(t_ENTRY entry);
let hash = computeHashes(entry);

Bool all_set = True;
for (Integer i = 0; i < valueOf(BLOOM_COUNTING_HASHES); i = i + 1)
begin
let bucket = hash[i];
all_set = all_set && (bf[bucket] != 0);
end

// Entry is busy iff all hash bits are set
return ! all_set;
endmethod
endinterface
endmodule

Synthesis boundary between BVI wrapper and the Verilog

rasha — Sun Apr 15, 2012 8:47 pm

Author: rasha

Posted: Sun Apr 15, 2012 8:47 pm

Hello;

My general question is about FPGA/ASIC synthesis from Bluespec code.
Is there any preferred/suggested code structure/organization for facilitating this step?

In my specific case, this is what I'd like to do:

I want to write a "partial BVI wrapper". Let's say I have an UART, and I want to wrap only the "parallel side", so that it connects seamlessly to my Bluespec code. However, I want to leave the serial side (serialIn, serialOut) "exposed" in Verilog and accessible for routing constraint files.

(Note: I have matching "full BVI wrappers" for testing within BSV flow.)

Is something like this possible or is there a standard way this is done?

BSV syntax coloring template for Gedit (GNU/Linux)

comododragon — Sun Apr 15, 2012 12:51 pm

Author: comododragon

Posted: Sun Apr 15, 2012 12:51 pm

For those who are using gtksourceview-3.0, a change must me made, since the syntax of comments on C language has changed:

Locate those two lines below:
<context ref="c:comment"/>
<context ref="c:comment-multiline"/>

Change for:
<context ref="def:c-like-comment"/>
<context ref="def:c-like-comment-multiline"/>

I have found those two lines in the file /usr/share/gtksourceview-3.0/language-specs/c.lang

Good programming!

Indexing an array of BRAMs question

comododragon — Sat Apr 14, 2012 1:10 am

Author: comododragon

Posted: Sat Apr 14, 2012 1:10 am

I wasn't using this flag, thank you!

But, in the meantime, i've solved my problem by changing from BRAMServer to BRAMCore...

Using Vectors of Wires and interface methods

anthony_unisa — Thu Apr 12, 2012 6:10 pm

Author: anthony_unisa

Posted: Thu Apr 12, 2012 6:10 pm

During my attempts at solving the issue I came across the readReg function and was thinking "this is almost what I need, but I need vector support". As you've pointed out, turns out there is such a function in readVReg which is exactly what I required (didn't look in the reference manual hard enough:)) A belated reply of thanks for your prompt and comprehensive answer!

Assign Actionvalue Vector

quark — Fri Apr 06, 2012 1:06 pm

Author: quark

Posted: Fri Apr 06, 2012 1:06 pm

What exactly is it that you observe? You only see one $display output? Or you see 4 outputs but with the same value?

What you have written is fine, and I see no reason why the simulation would not do what you intend. I took your example and compiled it to Verilog and the output looks fine:

Code:

always@(negedge CLK)
begin
#0;
$display("x value: %h", v_multiplier$getResult);
$display("x value: %h", v_multiplier_1$getResult);
$display("x value: %h", v_multiplier_2$getResult);
$display("x value: %h", v_multiplier_3$getResult);
end

However, this was a simple example with one clock and one reset. Do you have multiple resets or clock gates? If you're seeing only one $display, then maybe the other modules are in reset. (BSC will warn you if there are multiple resets in one rule, so you would have seen a message during compilation.)

If you're seeing four $display messages, but with the same value, then maybe the inputs to the modules were wrong?

Anyway, what you've written looks fine, so I'd have to see more of the module to know if there's a bug in BSC. If you can send the example to support@bluespec.com, then we can have a look.

Logical partitioning of design/code (split rule precedence)

quark — Wed Apr 04, 2012 8:07 pm

Author: quark

Posted: Wed Apr 04, 2012 8:07 pm

Ah, yes. I don't believe that import-BVI supports concatenating or bit-extraction of ports, although this is something we are considering. So, yes, you would need a wrapper to combine them into one struct.

BVI always_enabled & similar stuff (BVI doubts part 2)

rasha — Mon Apr 02, 2012 11:30 am

Author: rasha

Posted: Mon Apr 02, 2012 11:30 am

Thanks for the explanations quark!
Also: it seems to me that most of this
is not in any of the documents.

ranko

Clock gating in BVI wrappers (BVI doubts part.1)

quark — Mon Apr 02, 2012 1:33 am

Author: quark

Posted: Mon Apr 02, 2012 1:33 am

For #2, the import-BVI wrapper does not have a method like "clockRunning". The only place where "ce" is mentioned is in the ports for "clk_clk", which are declared as "(clk,ce)". So, no, you're not driving "ce" to 1 in the wrapper. But, yes, you would instantiate a mkGatedClock module in the BSV; and that module's interface has a method "setGateCond" as input to the module, and as output the module provides a clock with two ports (an oscillator and a gate). So the mkGatedClock module is doing the work of converting a method call signal into a clock gate. Then, if you instantiate the imported module with that generated clock, BSC will connect the generated output gate to the "ce" input automatically.

This is assuming that "ce" is used as a clock gate inside the imported module. If the "ce" signal really is a control signal that is only indirectly controlling the clocking, then you'll want to use option #1.

SCE-MI2.0

srinivasboppu — Fri Mar 30, 2012 3:06 am

Author: srinivasboppu

Posted: Fri Mar 30, 2012 3:06 am

Can we get all these things ( compiler, BlueSim and SCE_MI) license
as a part of the university program ?

We are from University of Erlangen-Nuremberg, we would like to use it
in our research project.

Regards,
Srinivas Boppu

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.