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 

Loop Back Problem

 
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: Mon Oct 14, 2013 2:37 am    Post subject: Loop Back Problem Reply with quote

Iam writing a Testbench for MAC module ,in that iam trying to connect the tx_gmii (input method of MAC) to rx_gmii(value method of MAC) both are of same MAC module and of same type i.e. Tuple3(Bit#(8),Bool,Bool) ,

I tried three different ways separately
code:
1. mkConnection(mac.tx_gmii,mac_rx_gmii);
2. rule gmii_connect;
let x = mac.tx_gmii;
mac.rx_gmii(x);
endrule
3. rule gmii_connect;
txOut<=mac.tx_gmii; // txOut is reg
mac.rx_gmii(txOut);
endrule

Error for 2nd case:


Error: "src_BSV_m/Testbench.bsv", line 114, column 8: (G0004)
Rule `RL_gmii_connect' uses methods that conflict in parallel:
mac.rx_gmii({mac.tx_gmii_fst, mac.tx_gmii_snd_fst, mac.tx_gmii_snd_snd})
and
mac.tx_gmii_fst()
Error: "src_BSV_m/Testbench.bsv", line 114, column 8: (G0004)
Rule `RL_gmii_connect' uses methods that conflict in parallel:
mac.rx_gmii({mac.tx_gmii_fst, mac.tx_gmii_snd_fst, mac.tx_gmii_snd_snd})
and
mac.tx_gmii_snd_fst()
Error: "src_BSV_m/Testbench.bsv", line 114, column 8: (G0004)
Rule `RL_gmii_connect' uses methods that conflict in parallel:
mac.rx_gmii({mac.tx_gmii_fst, mac.tx_gmii_snd_fst, mac.tx_gmii_snd_snd})
and
mac.tx_gmii_snd_snd()
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 496

PostPosted: Wed Oct 23, 2013 4:56 pm    Post subject: Re: Loop Back Problem Reply with quote

The error message is saying that the methods "tx_gmii" and "rx_gmii" cannot be called together in the same rule. (There is some complication in the names, though, because the parts of Tuple types are -- for historic reasons -- expanded into separate methods. You can avoid this by defining your own struct in place of using Tuple3, if you prefer.)

The BSC compiler analyzes the definitions for the module's methods to determine whether they use common state. This analysis is used to determine the scheduling relationships between the methods, which are recorded alongside the synthesized module. When a design instantiates and uses this module, BSC will check that the uses obey the scheduling constraints. In this case, BSC has found that a single rule (gmii_connect) is trying to call both methods, but the scheduling analysis has determined that this is not allowed.

Or is the MAC a Verilog module that has been imported with the import-BVI syntax? In that case, the import block has specified the requirements with "schedule" statements. Perhaps you need to change the schedule statement to give a different relationship?

Given this we have two options: (1) Change the module so that the methods don't conflict, or (2) change the testbench so that it respects the scheduling restrictions.

To do #2, try this:
Code:
FIFO#(Tuple3#(Bit#(8),Bool,Bool)) f <- mkFIFO;

rule gmii_out;
   f.enq(mac.tx_gmii);
endrule

rule gmii_in;
   max.rx_gmii(f.first());
   f.deq();
endrule

You can also do this with a register instead of a FIFO, however you'll have to initialize the register with some initial dummy value. If possible, I would prefer that the output value be an ActionValue method; with a value method, you risk the value being lost if it is not read on every clock cycle, but with an ActionValue method, the taking of the value is acknowledged. With an ActionValue method, I would certainly use a FIFO. With a value method that needs to be read on every clock cycle, then a register would be OK, but just be aware that the whole thing is fragile (which can be OK when interfacing to external IP).

Anyway, the point is that the read and the write have been moved to separate rules. This alleviates the scheduling problem.

The alternative is #1, to change the module so that the methods can be used in a single rule. As I said, if the module is imported, then you can just change the import block. If the module is written in BSV, then we need to understand why BSC has concluded that calls in the same rule are not allowed.

To understand why it is not allowed, we have to look at the module. If I looked at the BSV code for the MAC module, then maybe I could see why. But the BSC compiler and the Bluespec Workstation GUI both have tools for displaying the scheduling analysis. So you can also use those tools find out why. For more information, look in the BSC User Guide. Section 5.4, "Analyzing the schedule", explains how to view scheduling relationships in the Workstation GUI. Section 7.14, "Understanding the schedule", explains some of the command-line flags for dumping this same information. I recommend using the GUI because it is easier to view and doesn't require recompiling the design. For understanding scheduling, I recommend reading the appropriate sections of the "BSV By Example" document (available as a book or as a PDF file in the Bluespec release).
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