bluespec.com Forum Index bluespec.com
Bluespec Forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

bluesim segfault

 
Post new topic   Reply to topic    bluespec.com Forum Index -> Tools: Bluesim
View previous topic :: View next topic  
Author Message
patil.nikhil



Joined: 17 Aug 2007
Posts: 69
Location: University of Texas at Austin

PostPosted: Wed Dec 16, 2009 9:04 am    Post subject: bluesim segfault Reply with quote

Hi,

I was trying to roll out my own version of string where a large Bit#(1024) would be passed into every module, when I ran into this weird problem.

Bluesim segfaults when a value larger than Bit#(64) is passed into a module with a synthesis boundary. I have tried with a few older versions too. No such problem with verilog.

Code:

(*synthesize*)
module mkTest
        ();
    mkX(1234);
endmodule

(*synthesize*)
module mkX#(Bit#(65) val)
        ();
    let x <- mkRegU;
    rule r;
        x <= val;
        $display(x);
    endrule
endmodule


nikhil
Back to top
View user's profile Send private message Visit poster's website
quark
Site Admin


Joined: 02 Nov 2007
Posts: 499

PostPosted: Wed Dec 16, 2009 2:25 pm    Post subject: Re: bluesim segfault Reply with quote

Hi Nikhil,

I am able to reproduce this failure. I will investigate and fix the bug (for a future release). I suspect that, unfortunately, there will not be workaround. However, if I discover one while investigating I will let you know.

As to the original reason for this code: is there a reason why String would not work for you? The following design works in Bluesim:
Code:
(*synthesize*)
module mkTest
        ();
    mkX("Hello");
endmodule

(*synthesize*)
module mkX#(parameter String val)
        ();
    rule r;
        $display(val);
    endrule
endmodule
Back to top
View user's profile Send private message
patil.nikhil



Joined: 17 Aug 2007
Posts: 69
Location: University of Texas at Austin

PostPosted: Wed Dec 16, 2009 4:39 pm    Post subject: Reply with quote

Oh, don't worry about the workaround. It does work in Verilog simulations; that's good enough for now.

The problem we've had with String is that bluespec wants to know statically, exactly what it is. That means (in your example), I cannot replace $display(val) with $display(val + "world")... and it makes sense to me why not. One solution I have been looking at involves using $swriteAV functions instead, but that returns a Bit# (and hence this post).

There are a few more issues here. I am still trying to wrap my head around all of them. I will post here once I can talk about all this a bit more coherently. Very Happy

nikhil
Back to top
View user's profile Send private message Visit poster's website
quark
Site Admin


Joined: 02 Nov 2007
Posts: 499

PostPosted: Wed Dec 16, 2009 5:26 pm    Post subject: Reply with quote

Yes, a String has to be a static value, and this has limitations. However, there can be ways to get around this.

patil.nikhil wrote:
That means (in your example), I cannot replace $display(val) with $display(val + "world")...

Interesting! I would have expected this to work. A static value can usually be used anywhere a dynamic value can be used; usually the limitation is that a submodule instantiation which expects a static parameter cannot be supplied with a dynamic value. That is, you can't do this:
Code:
module mkTest ();
    Reg#(Bool) b <- mkRegU;
    mkX(b ? "Hello" : "World");
endmodule


However, there is good news! In your example we can work around the issue by doing this:
Code:
$display("%s world", val);


Probably the reason why "+" doesn't work is that we wouldn't be able to create Verilog to implement the "+". Even though "val" is not dynamic, it's also not known at BSC compile-time. It is computed at an intermediate point, between BSC compile and Verilog run-time: Verilog elaboration time. In theory, we could make "+" work on Strings by generating Verilog elaboration code to implement it.
Back to top
View user's profile Send private message
patil.nikhil



Joined: 17 Aug 2007
Posts: 69
Location: University of Texas at Austin

PostPosted: Fri Dec 18, 2009 3:54 am    Post subject: Reply with quote

Actually, this problem showed up when one of us tried opening a file with that name! $fopen requires a real String as the first argument. (But I don't know the reason for that restriction -- according to the verilog 2001 manual, "filename is a character string, or a reg containing a character string that names the file to be opened.") We would like to do a $fopen(s + ".log", "w"), or even $fopen($format("%s.log, s), "w');

In any case, I think I am going to go for writing my own BDPI fopen, so I can implement a circular buffer in a file. That should check my harddisk usage Smile

I am not sure what the elaboration of the string concatenate in verilog would look like, but I am guessing you would have to go through a foreign function. More generally then, is it possible to remove the restriction that $sformatAV be in an Action context (or expose a non-Action function for converting from an Fmt to a Bit#(n))? Are there any hidden side-effects while doing so?

nikhil
Back to top
View user's profile Send private message Visit poster's website
quark
Site Admin


Joined: 02 Nov 2007
Posts: 499

PostPosted: Fri Dec 18, 2009 4:09 pm    Post subject: Reply with quote

patil.nikhil wrote:
Actually, this problem showed up when one of us tried opening a file with that name! $fopen requires a real String as the first argument. (But I don't know the reason for that restriction -- according to the verilog 2001 manual, "filename is a character string, or a reg containing a character string that names the file to be opened.") We would like to do a $fopen(s + ".log", "w"), or even $fopen($format("%s.log, s), "w');


I see. I tried to write this code:
Code:
module mkTest3 #(parameter String s) ();
   Reg#(Maybe#(File)) f <- mkReg(Invalid);
   rule do_open (!isValid(f));
      let str <- $sformatAV("%s.log", s);
      let x <- $fopen(str, "w");
      f <= Valid(x);
   endrule
endmodule

And this doesn't work because $sformatAV returns type Bit#(n), rather than String which is expected by $fopen. So I see what you mean. It would be useful if $sformatAV returned a String.

Quote:
More generally then, is it possible to remove the restriction that $sformatAV be in an Action context (or expose a non-Action function for converting from an Fmt to a Bit#(n))? Are there any hidden side-effects while doing so?

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.
Back to top
View user's profile Send private message
patil.nikhil



Joined: 17 Aug 2007
Posts: 69
Location: University of Texas at Austin

PostPosted: Fri Dec 18, 2009 5:25 pm    Post subject: Reply with quote

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 Very Happy. 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
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    bluespec.com Forum Index -> Tools: Bluesim All times are GMT - 4 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
bluespec.com topic RSS feed 


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP