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 

regarding declaration of fifos using for with different size

 
Post new topic   Reply to topic    bluespec.com Forum Index -> Designing with BSV's Rules, Interfaces, ...
View previous topic :: View next topic  
Author Message
seeker_123



Joined: 26 Sep 2013
Posts: 8

PostPosted: Wed Nov 06, 2013 1:42 am    Post subject: regarding declaration of fifos using for with different size Reply with quote

hiii everybody,
I want to declare fifo having different size like this
FIFO #(Bit#(1)) q_s1 <- mkFIFO;
FIFO #(Bit#(2)) q_s2 <- mkFIFO;
FIFO #(Bit#(3)) q_s3 <- mkFIFO;
FIFO #(Bit#(4)) q_s4 <- mkFIFO;
.
.
.
FIFO #(Bit#(53)) q_s53 <- mkFIFO;

as it is little bit hectic
cant we write it with for loop
I tried it like this
for(integer i=53;i>0;i=i-1)
FIFO #(Bit#(53-i)) q_s[i] <- mkFIFO;

it is giving
Error: "./src_BSV/Fpu_divider.bsv", line 51, column 21: (P0005)
Unexpected `-'; expected type parameters, `,', or `)'
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 496

PostPosted: Wed Nov 06, 2013 3:37 pm    Post subject: Re: regarding declaration of fifos using for with different Reply with quote

Good question. There are several issues here.

First, note that numeric types and numeric values are two separate domains, that can't usually be mixed. Numeric types can only be used in the parts of the syntax that are types, and numeric values can only be used in the parts of the syntax that are value expressions. In your for-loop example, "FIFO" is a type and it takes an argument which also has to be a type. The variable "i" is a value, so you can't use "i" in the argument.

Also, the type and value contexts also don't use the same operators. For values, the "+" and "-" operators are used for addition and subtraction. But for types, you have to use the type constructors "TAdd" and "TSub". So in the argument to "FIFO", you can't use the "-" operator. That's why you get the syntax error. If you want to subtract numeric types, then you would need to use the "TSub" type constructor (or an "Add" proviso).

I said that the two domains can't usually be mixed. The one exception is that you can cast numeric types into numeric values using the special function "valueOf" that takes a type as an argument and returns a value. You can only cast in this direction (types to values) and not the other way (values to types). This is because numeric types are resolved during type checking and numeric values are computed later during the evaluation of the design. At the point where type checking happens, the Integer "i" doesn't have a value because we haven't started evaluating the code; when we get to evaluation, we can access the types, but it is too late to pass values back into the type checker.

OK, back to the question of how to write this as a loop. But before we can answer that, we have to look at the issue of scope. When you write code like this:
Code:
FIFO #(Bit#(1)) q_s1 <- mkFIFO;

you are really doing two things in one statement. You are declaring a new name "q_s1" with the type "FIFO#(Bit#(1))" and you are simultaneously assigning a value to it (here, the interface from instantiating the "mkFIFO" module). This could have been done in two steps:
Code:
FIFO #(Bit#(1)) q_s1;
q_s1 <- mkFIFO;

When you declare a new name, that variable is now available to be used by any statement in the rest of the block. But the name is only in scope for that block. So you can't write this:
Code:
for (Integer i=0; i<4; i=i+1) begin
   // this declares a new name "q"
   FIFO #(Bit#(1)) q <- mkFIFO
   // the name "q" is only in scope here
end
// at this point the name "q" is gone
… q.enq(0) … // this reference to "q" is invalid

But what you can do is to declare the name before you enter the sub-block. So this is a common Vector example:
Code:
Vector#(4, FIFO#(Bit#(1))) q_s;
for (Integer i=0; i<4; i=i+1) begin
   // we only assign a value here,
   // there is no type because we are not declaring a new name
   q_s[i] <- mkFIFO;
end

However, as you probably noticed, the elements of a Vector must all be of the same type. That is, we declared "q_s" to be a Vector of FIFO interfaces of Bit#(1).

There are a number of ways to work around this, however it depends on how this set of FIFOs is going to be used. That is, you've only shown me how you want to construct the value "q_s", but can you show me how you plan to use the value once you have it? Somewhere in your code, you want to write "q_s[i].enq" and "q_s[i].deq", and what do those places look like?

Because you're going to have type issues there, too. Every expression in BSV must have fixed type. When you write "q_s[i]", this must have a single type -- whether it's FIFO#(Bit#(1)) or FIFO#(Bit#(8)), but it can't be either, depending on the value of "i".

So if you can give more info about how your design uses this set of FIFOs, I can try to offer a suggestion.

This forum post is about a similar issue, however it doesn't use a FIFO interface, so your example may need a different solution:
http://bluespec.com/forum/viewtopic.php?p=1272#1272

There are also a few related forum posts, but they are about recursive function calls instead of for-loops. They are probably less helpful, but I'll link to them just in case:
http://bluespec.com/forum/viewtopic.php?p=1076#1076
http://bluespec.com/forum/viewtopic.php?p=1350#1350
Back to top
View user's profile Send private message
seeker_123



Joined: 26 Sep 2013
Posts: 8

PostPosted: Thu Nov 07, 2013 2:52 am    Post subject: Reply with quote

thanks

These FIFOs are part of pipeline design
these are just accepting inputs with different size and passes through FIFO and then deq it to maintain piplined design for continious inputs
like
q_s1.enq(a1); //a1 is 1 bit
q_s2.enq(a2); // a2 is 2 bit
q_s3.enq(a3); // a3 is 3 bit
so on

and then deq



so if I am going with vector then size of each q_s will be same. I want that as variable
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 496

PostPosted: Thu Nov 07, 2013 3:59 pm    Post subject: Reply with quote

And how are you writing the pipeline logic between the buffers? If that is being written out manually, then then there's not much advantage to just changing how you write the buffers; you'd want to find a way to concisely write both the buffers and the logic. I'd need to know more about the pipeline stages to offer concrete advice, but my general suggestion would be: think about putting the entire design in a for-loop or a recursive function -- for instance, a pipeline module with N stages is just one stage plus a pipeline module of N-1 stages. That kind of structure is explained in the links that I gave at the end of my previous message (such as the Adder Tree).
Back to top
View user's profile Send private message
seeker_123



Joined: 26 Sep 2013
Posts: 8

PostPosted: Fri Nov 08, 2013 12:47 am    Post subject: Reply with quote

thanks
As you suggested I want to write it into for loop only.
For that FIFO should be declared as vector.
e.g. Vector(n,FIFO#(Bit#(m))) fif;

then in for loop we can use as fif[variable] to access individual fifo.
But as FIFO's who are accepting inputs are of different width(m is different for each FIFO). So i unable to define it as vector. So for defining individual i have to give different names for fifos like q_s1,q_s2,q_s3.....
But if I am defining fifo's name like this then I can not use for loop because then statement which is assigning values to FIFO can not be generic

am i right? please correct me I am wrong .

thanks again
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 496

PostPosted: Fri Nov 08, 2013 1:16 am    Post subject: Reply with quote

Not necessarily. It depends on what you are trying to implement. You may be able to use typeclasses, as described in the forum posts that I linked to.

Also, you seem to describe a situation that has two for-loops:
Code:
Vector#(…) fifos;
for (Integer i=0; i<N; i=i+1)
   fifos[i] <- mkFIFO;

for (Integer i=0; i<N; i=i+1)
   rule r;
      fifos[i].enq(…);
   endrule

To structure the code like this, yes, you need something like a Vector to hold all of the FIFOs. But do you really need this structure? If you don't expose the FIFO outside of the of for-loop, then you don't need to store it in a Vector:
Code:
for (Integer i=0; i<N; i=i+1) begin
   FIFO#(…) f <- mkFIFO;
   rule r;
      f.enq(…);
   endrule
end

This was what I was trying to ask about.

Another option is to instantiate the FIFOs at different sizes, but to wrap them in a common interface that would be the same for all FIFOs (for instance, extend the bit sizes to a the max size). That way, even though the modules may be different types, you can wrap them to be the same type and then they can be stored in a Vector. For example:
Code:
function FIFO#(Bit#(MAXSIZE)) extendFIFO(FIFO#(Bit#(n)) f)
 provisos (Add#(n,k,MAXSIZE));
   return (
      interface FIFO;
          method enq(x) = f.enq(truncate(x));
          method first = extend(f.first);
          method deq = f.deq;
          method clear = f.clear;
      endinterface
   );
endfunction

Finally, there is a package called HList that can be used to store elements of different types. It may be cumbersome to use in this situation, but again it depends on what you're trying to implement.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    bluespec.com Forum Index -> Designing with BSV's Rules, Interfaces, ... 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