Hi, How do i access the internal signals in the top module to testbench program.The change in internal signals causes main signals to change.
Hareesh M. wrote: > How do i access the internal signals in the top module to testbench > program. Wht do you mean with "access"? Just to view the signals? Or to force them to a desired state? And most important: What simulator do you use? > The change in internal signals causes main signals to change. Indeed thats usually the desired behaviour of almost every HDL design.
Lothar M. wrote: > Hareesh M. wrote: >> How do i access the internal signals in the top module to testbench >> program. > Wht do you mean with "access"? Just to view the signals? Or to force > them to a desired state? > > And most important: What simulator do you use? > >> The change in internal signals causes main signals to change. > Indeed thats usually the desired behaviour of almost every HDL design. i want to force them to a desired state, and forcing them causes the changes in other signals too. Currently i'm using modelsim simulator.
Hareesh M. wrote: > Lothar M. wrote: >> Hareesh M. wrote: >>> How do i access the internal signals in the top module to testbench >>> program. >> Wht do you mean with "access"? Just to view the signals? Or to force >> them to a desired state? >> >> And most important: What simulator do you use? >> >>> The change in internal signals causes main signals to change. >> Indeed thats usually the desired behaviour of almost every HDL design. > > i want to force them to a desired state, and forcing them causes the > changes in other signals too. Currently i'm using modelsim simulator. i'm writing the main code and testbench for the same ////////////////////////////////////////////////////////////////////
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
///////////////////////////////////////////////////////////////////// and the testbench is
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
Usually you do NOT force an internal signal because you will not be able to do that in a real design. So apply the stimuli data (inputs) in a way you get the desired internal signals. A few words to that design: At all the simulation of this code will not match the reality due to a wrong and incomplete sensitivity list. Here in simulation it will look like the process depends on the clock, but in real life it is only a completely combinatorial process:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
And much more worse: you implement a latch here. That is 1. not necessary, 2. not desired and 3. no good design practice. I suggest to write it without any process (using the concatenate operator '&') this way:
1 | |
2 | |
3 | |
And one word to that here:
1 | |
Thats not a fine trick. Write it this way, it is "more usual" and better readable:
1 | |
If you want you can skip the parenthesis also:
1 | |
BTW: Pls use the [vhdl] tokens around VHDL code (as described above every text edit box).
thanks for your suggestion. Actually the values of HS_PG00D_PLD, BD_SEL_PLD and HS_FLT_PLD might change while execution.The width of ifc_dout is 7, for simulation i made it 3. That's why i wrote like that. And i'll change the line as per your suggestion if((cpld_cs and cpld_oe)= '1') then. and what about the testbench?
Hareesh M. wrote: > Actually the values of HS_PG00D_PLD, BD_SEL_PLD and HS_FLT_PLD might > change while execution. Then those signals must be in the sensitivity list! If you want to march on with the process, then this is the correct sensitivity list:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
Hareesh M. wrote: > and what about the testbench? You already startet stimuli generation. Just go on with all the possible states:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
BTW1: obviously all of your select signals are low active due to the _n at the end of their names. Therefore this is rubbish:
1 | |
2 | |
3 | |
But at all this complete "control signal process" is not necessary at all. Instead it is leading to a kind of clocked bus handling. But that you will find out in simulation further on. A hint: you MUST set the inout bus to HiZ when you don't use it for output! BTW2: That looks very, very confusing to me: ifc_ad0_7: inout std_logic_vector(2 downto 0); Must it be ifc_ad2_0 instead?
Hi...i am a new user here.As per my knowledge you do NOT force an internal signal because you will not be able. To do that in a real design. So apply the stimuli data in a way you get the desired internal signals.
Reply
Please log in before posting.