Verilog testbench help!! (bit urgent)

[sonika111]

I would appreciate if you can please help me; doing this way although the error is gone but the bus remains X throughout.....

- - - Updated - - -

I would appreciate if you guys can please reply; as I followed the suggestions in this thread; though the error goes away but in thw waveform the s bus remains X throughout. Many thanks

 

[sonika111]

Just waiting for your help please. Please respond

 

[sonika111]

Honestly bit stuck without your help

The probelm I am talking about is "I can now compile but while simulating I get the following error Illegal inout port "(posted on post 17,18,19,20,21). Please have a look at those posts for me. Many thanks

 

[ThisIsNotSam]

Honestly bit stuck without your help

The probelm I am talking about is "I can now compile but while simulating I get the following error Illegal inout port "(posted on post 17,18,19,20,21). Please have a look at those posts for me. Many thanks

Had you used all the time you spend posting here to google the problem and find a solution -- exactly like what is expected of an engineer -- you would be done by now. Listen, no one is here to do your homework for you. The issues you keep facing are RIDICULOUSLY basic, I flunk undergrads if they can't solve these on their own.

 

[ads-ee]

Honestly bit stuck without your help

The probelm I am talking about is "I can now compile but while simulating I get the following error Illegal inout port "(posted on post 17,18,19,20,21). Please have a look at those posts for me. Many thanks

I decided to NOT help you because you never post your code in context. Snippets of code don't help us debug your issue, which most of the time is outside the code a user posts.

Also start following forum rules with use of code tags, one of your earlier posts is full of code snippets that start and stop all over the post and takes way too much effort to read (so I didn't). Also don't try to bump your thread with useless posts like Please respond. It is highly likely that your lack of detailed information on the problem results in less than helpful replies telling you to search on google. I for one will seldom answer posts where the user doesn't supply any detailed information about the problem (like the code or a testcase of code, if they can't post the real code). If they make that much of an effort I make an effort to help, otherwise why should I bother...

Now that I read your multi-snippet post (and added code tags).

---

Code Verilog - [expand]
1
2
// in testbench to access the output_enable
tb_inout_sig = !dut.output_enable ? tb_driving_inout_sig : 'bz;

---

That will only drive the inout from the tb when the output enable is not active in the FPGA. This assumes dut is the instance name of your design in the testbench.

- - - Updated - - -

Now due to the lack of detail you've given...

Why does your TB not know when it can drive the inout? Seems to me there is a hole in your entire design's architecture if the external device has no idea when it should drive or High-Z it's output pins.

 

[sonika111]

The problem is that the output_enable of the dut is not propagated at top level and I am not allowed to change the design

I came across this post Is this my solution( Hi ThisIsSam) I did google it.... plesae help

https://www.edaboard.com/showthread.php?t=42207

I have couple of inouts?? Do I treat them as in this post and I would get correct stimulus??

I am wondering why inout was not a problem in my VHDL testbench?( I didn't have to treat it like this??) and I didn't get such errors (plaese have a look at post 19,20) Thanks very much... Sorry I am getting used to the rules and methods. Please bear with me

Thanks very much for your reply though. I very much appreciate that.

PLease read the above posts and try giving me a solution please. Many thanks

 

[ads-ee]

I am wondering why inout was not a problem in my VHDL testbench?( I didn't have to treat it like this??) and I didn't get such errors (plaese have a look at post 19,20) Thanks very much... Sorry I am getting used to the rules and methods. Please bear with me

Then give the VHDL example instead of referring to posts WHICH HAVE NO VHDL CODE WHATSOEVER.

I came across this post Is this my solution

https://www.edaboard.com/showthread.php?t=42207

I have couple of inouts?? Do I treat them as in this post and I would get correct stimulus??

How can I or anyone else know if this is the solution for your problem, YOU NEVER POSTED YOUR CODE!

 

[sonika111]

I am unable to post the code but the snippet is in post 20. Thanks.

These illegal inout port errors donot come in VHDL testbench but in the verilog one in question ( which has been converted from it)

I already told the problem with the solution that you suggested :- The problem is that the output_enable of the dut is not propagated at top level and I am not allowed to change the design: Although this is perfect solution but I am unable to implement in my TB. Please give me an alternative or suggest how can i implement it in my TB (which does not see the output enable pins) Many thanks

I would request you guys to please take the time to read the posts (posted on post 17,18,19,20,21). Please ask me any information that is missing and please advice me the solution. Many thanks

I really look forward to the solution,

 

[TrickyDicky]

I read your posts, and they were pretty useless at describing the problem. Plus your bumping posts do not encourage help (and I feel the same way ThisIsNotSam regarding doing your own research) Hence I didnt respond. We need real code IN CONTEXT to work out what the problem is. Also, without the original VHDL, we have NO WAY of knowing how it origionally worked, and only have your word on how it works (which I do not trust given the basic level of understanding of your questions and answers).
The testbench must have some knowledge of who has control of the bi-directional bus. Either the testbench is the master and provides the output enable, or the design is the master and must provide some sort of output enable. Without knowing this in the testbench you have no way of knowing which way data is going.

 

[sonika111]

Right. I am really confused and sorry to cause you guys confusion. The design is the master where output_enable is defined but TB cannot see it. What can I do in TB?

 

[TrickyDicky]

If this really is a bidirectional bus, then the testbench MUST know, with a sideband signal, what direction the data is going. So the DUT MUST output it. Otherwise it CANNOT be a bidirectional bus.

 

[ThisIsNotSam]

Right. I am really confused and sorry to cause you guys confusion. The design is the master where output_enable is defined but TB cannot see it. What can I do in TB?

It's a simulation. Everyone can see everyone. Just create a wire in the tb and make an assign to the dut internal signal.

 

[ads-ee]

It's a simulation. Everyone can see everyone. Just create a wire in the tb and make an assign to the dut internal signal.

Give up, I already showed them how to do that in post #25 (which they obviously ignored...so I'll just do the same from now on). At least they can have hierarchical references to signals in any flavour of Verilog.

OP if this stuff is too confusing, then perhaps this is not the career path for you. What you are dealing with here is ridiculously basic, as stated by ThisIsNotSam in post #24.

- - - Updated - - -

If this really is a bidirectional bus, then the testbench MUST know, with a sideband signal, what direction the data is going. So the DUT MUST output it. Otherwise it CANNOT be a bidirectional bus.

Or defined by the protocol on the bus, e.g. I2C.

- - - Updated - - -

I am unable to post the code but the snippet is in post 20. Thanks.

Then post a full testcase like I already suggested that exhibits the exact same problem.

...Of course you never read post #25

I for one will seldom answer posts where the user doesn't supply any detailed information about the problem (like the code or a testcase of code, if they can't post the real code).

- - - Updated - - -

sonika111, FYI, you should understand the 4 main posters to this thread probably have a combined experience of about 100 years.

If you had supplied adequate information starting with your first post you would have had your answer some 20 posts ago and probably sometime last week.

Given that you couldn't post your code (never explicitly stated before post #28) then you could have made the effort to create a testcase that exhibits the problem (not your real code) then you would have saved yourself a lot of time.

 

[sonika111]

Thanks very much for your replies.

// in testbench to access the output_enable
tb_inout_sig = !dut.output_enable ? tb_driving_inout_sig : 'bz;

1. I am unable to access output_enable of the dut as (In the design output_enable is defined as VHDL signal and is not in the port list) hence I cannot access it hierarchically or otherwise (If I can then please let me know)

2. So I have define the following in test bench. I don't know if it is the right way to deal with it.Please correct me

 logic oe;
wire [31:0] data_bus_sig;
logic [31:0] data_bus;

assign data_bus_sig = (oe)  ? data_bus : 32'bz;


initial
begin
oe <= 1'b0

end

initial
begin
oe <= 1'b1;
data_bus <= f_data;

end

I had couple of such signals and have tried dealing it like this

Please correct me if I am wrong.

Again thanks very much for all your help

PS: I have not yet figured out to tag the code...

 

[TrickyDicky]

Why not post what the original VHDL testbench did? then maybe we'll have so idea of how that worked? Your code now implies oe is driven from two initial blocks - and that will cause oe to be X, just like if you were driving it from two processes in VHDL.

code tags are available as a button when you click "go advanced". Or wrap the code in [ code] [ /code] blocks. You could have found this out by googling "code tags forum". https://forum.unity.com/threads/using-code-tags-properly.143875/

 

[ads-ee]

You could have found this out by googling "code tags forum". https://forum.unity.com/threads/using-code-tags-properly.143875/

That has different code tagging as they also allow some form of syntax highlighting which is handled differently here.

Hmm, the link to the tutorial on code tags from the rules page is broken. But can still be found via the "Forum=>The Classifieds=>About EDAboard.com=>How to apply CODE and SYNTAX tags" sticky post.

- - - Updated - - -

sonika111, can you tell us what kind of bus is data_bus (a.k.a. io_data_bus)?

Is this bus some super secret non-standard proprietary bus that is a complete mess (all indications so far say it is).

If it is a defined bus then it must have some sort of protocol to allow devices to decide when they can drive the io_data_bus/data_bus I/O pins. Unless you tell us what bus it is or what the protocol is, we can't help you fix the simulation issue. We can only tell you that you can't do that (you can't drive oe from two initial blocks). We certainly can't tell you how you should drive it as we don't know what it is supposed to do.

If you are working at a company, go ask a senior engineer to help you. If you are at a school go ask one of your fellow students and/or your instructor for help. Without information we (edaboard members) can't help you.

 

[sonika111]

Why not post what the original VHDL testbench did? then maybe we'll have so idea of how that worked? Your code now implies oe is driven from two initial blocks - and that will cause oe to be X, just like if you were driving it from two processes in VHDL.

code tags are available as a button when you click "go advanced". Or wrap the code in [ code] [ /code] blocks. You could have found this out by googling "code tags forum". https://forum.unity.com/threads/using-code-tags-properly.143875/

Thanks very much. Actually in these initial blocks there are if statements and some waits for posedge(clk) too. It doesn't happen at the same time

In that case is it alright to deal like this

Many thanks

 

[TrickyDicky]

Thanks very much. Actually in these initial blocks there are if statements and some waits for posedge(clk) too. It doesn't happen at the same time
In that case is it alright to deal like this
Many thanks

You cannot drive any variable from more than 1 initial block as non-block assignments. It gives you X's when both drive together. Driving them as blocking assignments will just give you a race condition.
See post #35!

 

[sonika111]

You cannot drive any variable from more than 1 initial block as non-block assignments. It gives you X's when both drive together. Driving them as blocking assignments will just give you a race condition.
See post #35!

Thanks very much for all your help everyone

I think I need to assign output enable which is defined as the signal in one of design modules in my testbench to do as suggested in post # 34
(Please remember this is in an attempt to remove the error of illegal inout port dir we have been talking about
: The hierarchy is as follows top.xbus.xd_oe

Please note this is a signal (not available on port list pf xbus)....Will I be able to access and assign in my testbench? Please advice( if yes exactly how?? Many thanks

---

Code Verilog - [expand]
1
2
// in testbench to access the output_enable
tb_inout_sig = !dut.output_enable ? tb_driving_inout_sig : 'bz;

---

- - - Updated - - -

I tried doing this is my code to address the prob in question

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
initial begin
   .....
    ...
       tb.uut.u_inst.oe = 1'b0;
        tb.uut.oe2 = 1'b0;
    if(cmd=) begin
       .......
       ........
       tb.uut.u_inst.oe = 1'b1;
 
     @(posedge clk);
        ........
        .........
        tb.uut.oe2 = 1'b1;
 
      ......
      end
  end

---

assign tb_1_sig = tb.uut.u_inst.oe ? tb_1: 32'bz;
assign tb_2_sig = tb.uut.oe2 ? tb_2 : 1'bz;


But while simulating I get the errors loading design
This or another usage of 'tb.uut.oe2' inconsistent with 'VHDL SIGNAL' object.
This or another usage of 'tb.uut.u_inst.oe ' inconsistent with 'VHDL SIGNAL' object.

Can you plesae have a look and suggest me a solution. Mnay thanks

 

[TrickyDicky]

You should not be driving a signal inside the DUT from the testbench. That was clearly not how the DUT was designed. If it was supposed to be driven externally, it would have been brought to a port. I highly suggest you read up on your DUT, speak to original designer, find out how it is suppose to work. ONLY THEN, come back to your testbench. You are wasting loads of time messing around with things that are clearly incorrect.

Why cant you just copy what the orignal testbench did? if that was working, then that will show you how the interface worked.