bluespec.com

Instruction set to memory

jnewbern — Wed Mar 03, 2010 8:06 am

Author: jnewbern

Posted: Wed Mar 03, 2010 8:06 am

The interface methods of mkRegFileFullLoad are the same as mkRegFileFull. The only difference is the initialization from the file.

The file format is the standard Verilog memory file format, described in the manual I linked to earlier. You can use @address to specify the address, but addresses are assumed to increment linearly, so it is enough to specify only the first address in a memory region.

TMax type function doesn't exist?

ietsanjay — Thu Feb 25, 2010 10:51 am

Author: ietsanjay

Posted: Thu Feb 25, 2010 10:51 am

If TMax/TMin is not going to be supported, is there a workaround to compute it?

Bluesim linkage failure

kfleming — Tue Feb 23, 2010 1:02 pm

Author: kfleming

Posted: Tue Feb 23, 2010 1:02 pm

I edited my previous, highly unclear post. Sorry about that.

Multiple Resets

kirubi — Thu Jan 28, 2010 5:18 am

Author: kirubi

Posted: Thu Jan 28, 2010 5:18 am

Hello

I have a question

How do I do the following in BSV.

A four bit register say n_reg whose reset values differ based on two different resets say a_rst and b_rst.Both are asynchronous resets.

for example when a_rst is asserted n_reg will be 4'b0000 and b_rst is asserted n_reg 1ill be 4'b1111.

best
Venkat

Pack/Unpack functions

muem — Wed Jan 27, 2010 11:44 am

Author: muem

Posted: Wed Jan 27, 2010 11:44 am

jnewbern wrote:

Incidentally, the declaration above actually specifies 4 registers, each holding 4 single-byte words.

Maybe my description was a little bit irritating but that type is exactly what I wanted to create. With your suggestion (4x4 register array each holding a byte) I would have been able to "operate" on each byte separately but I am only operating on words. Hence the 4 registers each holding 4 single-byte words work perfectly for me.

jnewbern wrote:

The Vector package's readVReg and writeVReg functions are useful for working with these kinds of vectors-of-register declarations, BTW.

Thanks, I already found them in the reference guide. These are really useful functions when operating on vectors.

jnewbern wrote:

As for the pack/unpack variations, these should all generate permutations of wires with no other logic, so I would not expect any area or performance differences between them.

Thanks for confirming my assumptions,
Mike

Mistake both doc & compiler in BVI port

quark — Sun Jan 24, 2010 3:45 am

Author: quark

Posted: Sun Jan 24, 2010 3:45 am

Thank you for bringing this to our attention.

The syntax "1'b0" is equivalent to unpacking a Bit#(1) value into a value of another type. In this code, the other type is not mentioned -- it could be Bool, UInt#(1), Int#(1), etc. The error message indicates that the type is ambiguous.

We will fix the documentation and consider improving BSC to default the type to Bit#(1) in this situation.

problem about method

jnewbern — Wed Jan 20, 2010 10:40 am

Author: jnewbern

Posted: Wed Jan 20, 2010 10:40 am

Hi,

The issue here is one of aggressive conditions.

If you look at your state_start_thread rule, it contains the statement:

thread[counter_trd].start(1);

This means that the rule can call the start method on either of the 2 thread instances. Therefore, the rule will pick up the conditions from *both* instances' start methods -- it will only fire if state == 0 in both instances! You can see this by looking at the WILL_FIRE_RL_state_start_thread signal in the generated Verilog.

There is an option to bsc, which most people use all the time, called -aggressive-conditions. It will cause the compiler to be more aggressive about qualifying the conditions for method calls in rules. If you compile with -aggressive-conditions and look at the WILL_FIRE_RL_state_start_thread signal, you will see the resulting Verilog code now takes the counter_trd value into account. And indeed, the simulation will behave as you expected, starting the second thread in parallel with the first.

Jeff

a doubt in Register array

jnewbern — Wed Jan 20, 2010 10:16 am

Author: jnewbern

Posted: Wed Jan 20, 2010 10:16 am

You would use a RegFile#(UInt#(6),Bit#(32)). The UInt#(6) allows you to address registers 0-63, and each register will hold 32 bits.

Jeff

SBOX with two indices

muem — Tue Jan 12, 2010 5:20 am

Author: muem

Posted: Tue Jan 12, 2010 5:20 am

Hi!

I am currently implementing a substitution box (SBOX) which should be accessible by two indices (e.g. row - and column - index).

Right now I am not sure what's the best way to realize this (just a 2 dimensional register array, a vector of registers, a register file, a ram, etc...?). Furthermore I was asking myself if there are any differences in performance in all these possibilities?

tia, Mike

Multiple-clocks and ancestor_of attributes

kirubi — Tue Dec 29, 2009 10:56 am

Author: kirubi

Posted: Tue Dec 29, 2009 10:56 am

Hello

How do I go about doing this in blue-spec

I have two clocks say clk1khz and clk100khz which are inputs.clk1khz can be treated as default_clock and I have reset input reset_in

A counter is incremented based on clk1khz and when it reaches 999 it wraps around.

During this counting there are two values of count when count is 10'b0000000000 or count is 10'b0111110101 a gate enable- say clk1_enable is set for a clock clock1.

This clock1 is gated version of clk100khz.

I have a second clock clock2 which is gated version of clock1 and the gate condition is enabled by clk2_enable which is a sample of clk1_enable at clk100khz.

I have a third clock clock3 which is invertor of clock2.

Only clock3 must be an output from the module.

Rest of the clocks(clock1 and clock2) are generated and used internally.

What could be the best way to code the above in blue-spec?

More-specifically how do we use the ancestor_of_attributes.Is it necessary that all these must be available at the interface?

(If it must be so my basic requirement that the clocks generated inside must not appear as verilog ports get defeated.)

How do I check the value of count and issue an enable when count is incrementing based on certain count values.? Can I do that in a single rule? or Do I need to increment count in one rule and check the count value in another rule and get the enable? I could use two rules.My problem is passing the enable asserted in clock domain to another where it becomes a gate enable condition.

Also How do I pass the values of various enables from one clock domain to the above.

Can I use the same reset for all these enables/count etc?

Will this be reported as warning by blue-spec owing to same reset being used across clock domains(even though if they are gated version of the other)?

best
Venkat

Resets

quark — Mon Dec 28, 2009 10:37 pm

Author: quark

Posted: Mon Dec 28, 2009 10:37 pm

If you do not export the reset in the interface, then BSC should only emit a warning and not a an error. So you should be able to leave the reset out of the interface and still be able to compile.

The warning is there because unexpected behavior can happen when a rule involves state that is reset by different signals; if some state is in reset and some is not, the rule might still fire but only update some of the state. But if you know that you are handling the rules and reset properly and you are sure that this situation will never happen, then you can ignore the warning.

Error

quark — Mon Dec 28, 2009 3:11 pm

Author: quark

Posted: Mon Dec 28, 2009 3:11 pm

This error comes from inside the module "mkNullCrossingWire". The input to this module must come from a registered value, that does not have implicit conditions. The value cannot come from the output of another rule, through a wire, for example. The error is saying that there is another rule which has to happen first, which is not allowed.

You can either try to adjust the rules so that a rule doesn't schedule first. Or you might also try rewriting the design to not use mkNullCrossingWire -- in general, you should avoid using this module, unless you are doing something that requires working at this low-level.

What does this error mean?

quark — Mon Dec 28, 2009 2:34 pm

Author: quark

Posted: Mon Dec 28, 2009 2:34 pm

This error occurs when you misuse the mkNullCrossingWire module. The input to the module must come from a registered value, that does not have implicit conditions. The value cannot come from the output of another rule, through a wire, for example.

You might also try rewriting the design to not use mkNullCrossingWire, unless you are doing something that requires working at this low-level.

bluesim segfault

patil.nikhil — Fri Dec 18, 2009 5:25 pm

Author: patil.nikhil

Posted: Fri Dec 18, 2009 5:25 pm

quark wrote:

I don't see why there would any side-effects, so I am not sure why the string versions of these functions have an Action component. I can find out. However ... this should not be a problem, because you should always be in an Action context when you need the value. For instance, when using $display or $fopen etc, which have Action components.

Wholeheartedly agree. It just complicates code when passing a pseudo-String in module-level arguments through synthesis boundaries. In the general case I would need an always firing rule with a wire connected to the interface argument. But in most cases a register initialized in the first clock will suffice. Well anyway, I suppose all this can be encapsulated in a module.

Please don't think I am complaining here . I think I have already come up with a solution I am happy with, but removing the ActionValue constraint would make it even nicer.

Basically, I define VString as Bit#(1024) and Twine as ActionValue#(VString) and use Twine everywhere. (I thought Noose would be morbid). There is a typeclass IsString, for which String, Fmt, VString and Twine all have instances. The class defines functions fromString, toTwine and strcat. The idea is to use Twine consistently everywhere. (Polymorphic modules can use type variable s, with an IsString#(s) provisos on the method.) AFAICT the only place Twine cannot be used fully transparently is a synthesis boundary and a BDPI function -- in either case, all I have to do is to appropriately pull out the inner VString.

Bad things happen when I overflow the Bit#(1024) though; I will probably make this bigger.

nikhil

conv_integer

kirubi — Wed Dec 16, 2009 12:54 am

Author: kirubi

Posted: Wed Dec 16, 2009 12:54 am

Hello nikhil

The discussion is about getting blue-spec equivalent of conv_integer library function in vhdl.

There is no conv_integer in verilog and hence blue-spec yes.. but some $ functions like $bitstoreal are supported ..

The issue is to generate a hardware from a blue-spec code similar to the one generated by a vhdl code that uses conv_integer function.
***************************
Hello quark

I think I will re-visit the vhdl code *again* to see which part of the code contributed to a different hardware.

best
Venkat