Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

verilog code regarding sequencing of instantiation help!!

Status
Not open for further replies.
I

Indrajit Ghosh

Junior Member level 2
Joined
Feb 17, 2015
Messages
21
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
170
Code: 
p1_p2_initial_calc  c1(.p_max(p_max),.p1_ini(w1),.p2_ini(w2),.clk(clk),.cs(cs),.rdy(cs_pi));


SINR_PU_CALCULATOR  c3(.p1(p1),.p2(p2),.si(si_c),.clk(clk),.cs(cs_si),.rdy(high));



p1_p2_new_calc  c2(.si(si_c),.p1_n(z1),.p2_n(z2 ),.cs(cs_p1_p2),.clk(clk),.rdy3(ok));


now I have three instantiations as you can see, what i want to do is to make a control unit which will do the following jobs


1>initially p1,p2 of sinr should be the signals w1,w2 respectively (where p1,p2 are input to sinr,and w1,w2 are output)
2> after that p1,p2 of sinr should be z1,z2 of p1_p2_new_cal..,
3>after that only signal exchange between sinr and p1_p2_new_cal should happen when sinr is enabled p1_p2_new should be
disabled and vice-versa ALSO (p1_p2_initial permanently disabled)

here cs=control signal i,e the instantiation will only work if cs=high and rdy is the ready signal i.e it will generate a high signal when the output of that instantiation is ready.

help me out to write it in verilog!
 

You cannot change the connections that way. Once they are connected they will stay that way throughout.
But what you can do is define intermediate wires and change the assignments to these wires based on your requirement. Connect these wires to your module after that.
 
Indrajit Ghosh,

All the problems you've been posting, over multiple threads, all have to do with the same issue. You keep trying to treat Verilog like it is C (i.e. like a software language) and you haven't done a high level architectural design of the algorithm.

Verilog is a Hardware Description Language (i.e. HDL). It therefore represents a digital circuit. Instances in your code are like ICs placed on a PCB and the connections between instances are like the traces on the PCB that interconnect everything, therefore if you want to modify connections while the circuit is operating you need to add hardware to the design to do that switching, because, like a PCB, the interconnections between instances can't be changed after it's built.

At this point I'm not sure if you know what the detailed block diagram of your circuit looks like and how the blocks interface with each other. From what I can tell you are trying to hack together something without actually designing it up front, which is a sure fire way to end up with a mess.
 

it would had been helpful of at least giving solutions or idea on how to go about this specific problem rather than giving HDL philosophy....
 

Indrajit Ghosh said:
it would had been helpful of at least giving solutions or idea on how to go about this specific problem rather than giving HDL philosophy....
Click to expand...

No it wouldn't. If we just gave you the solution you would never learn and you will keep making the same mistakes.

You didn't post any code to fix anyway.
 

I tried to design a mux, to make a data communication path between p1_p2_new_calc ans sinr ,the code is having some problem help me out.....



Code: 
 module control_unit(p1,p2,clk,si,cs_si,cs_p1,op_nd_p12_in,op_si_in);

output reg [63:0] p1,p2,si;
input clk;
output reg cs_si,cs_p1;

//reg cs_reg;

//initial cs_reg=1;

wire [63:0] si_c,p1_n,p2_n,si_s;

output reg op_nd_p12_in,op_si_in;

reg [63:0] si_p,p1_s,p2_s;



p1_p2_new_calc c1 (
    .si(si_p), 
    .p1_n(p1_n), 
    .p2_n(p2_n), 
    .cs(cs_p1), 
    .clk(clk),  
    .rdy3(rdy3), 
    .op_nd_p12_in(op_nd_p12_in)
    );




SINR_PU_CALCULATOR c2 (
    .p1(p1_s), 
    .p2(p2_s), 
    .si(si_s), 
    .clk(clk), 
    .rdy(rdy), 
    .sclr_i(1'b0), 
    .op_si_in(op_si_in)
    );



//assign p1=p1_n;
//assign p2=p2_n;
//assign si=si_c;


always @ (rdy or rdy3 or cs_si or cs_p1 or cs_si or op_nd_p12_in or op_si_in or p1_n or p2_n or si_s )
begin

if (rdy3==1'b1 && rdy==1'b0)
begin
//turn on sinr
cs_si=1'b1;
cs_p1=1'b0;
p1_s=p1_n;
p2_s=p2_n;
si=si_s;
si_p=64'bz;//si of p1,p2
p1=p1_s;
p2=p2_s;
op_nd_p12_in=1'b0;//op_nd of p1,p2 is set low so that rdy goes low
op_si_in=1'b1;//so that rdy of sinr goes high

end

else if (rdy3==1'b0 && rdy==1'b1)
//turn on p1 p2
begin
cs_si=1'b0;
cs_p1=1'b1;
p1_s=64'bz;
p2_s=64'bz;
si=si_s;
si_p=si_s;//si of p1,p2
p1=p1_n;
p2=p2_n;
op_nd_p12_in=1'b1;//op_nd of p1,p2 is set high so that rdy goes high
op_si_in=1'b0;//so that rdy of sinr goes low

end

else  begin
p1=p1_n;
p2=p2_n;
si=si_s;
op_nd_p12_in=1'b1;//op_nd of p1,p2 is set high so that rdy goes high
op_si_in=1'b0;
p1_s=64'bz;
p2_s=64'bz;
cs_si=1'b0;
cs_p1=1'b1;


end 
end













endmodule


the synthesizer is throwing some warnings...how to fix it



Code: 
WARNING:Xst:737 - Found 1-bit latch for signal <PWR_8_o_rdy3_DLATCH_4_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[62]_rdy3_DLATCH_3_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[61]_rdy3_DLATCH_5_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[60]_rdy3_DLATCH_7_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[59]_rdy3_DLATCH_9_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[58]_rdy3_DLATCH_11_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[57]_rdy3_DLATCH_13_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[56]_rdy3_DLATCH_15_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[55]_rdy3_DLATCH_17_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[54]_rdy3_DLATCH_19_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[53]_rdy3_DLATCH_21_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[52]_rdy3_DLATCH_23_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[51]_rdy3_DLATCH_25_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[50]_rdy3_DLATCH_27_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[49]_rdy3_DLATCH_29_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[48]_rdy3_DLATCH_31_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[47]_rdy3_DLATCH_33_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[46]_rdy3_DLATCH_35_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[45]_rdy3_DLATCH_37_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[44]_rdy3_DLATCH_39_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[42]_rdy3_DLATCH_43_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[41]_rdy3_DLATCH_45_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[40]_rdy3_DLATCH_47_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[39]_rdy3_DLATCH_49_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[43]_rdy3_DLATCH_41_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPG    Found 1-bit tristate buffer for signal <si_p<40>> created at line 71
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[38]_rdy3_DLATCH_51_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[37]_rdy3_DLATCH_53_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[36]_rdy3_DLATCH_55_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[35]_rdy3_DLATCH_57_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[34]_rdy3_DLATCH_59_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[33]_rdy3_DLATCH_61_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[31]_rdy3_DLATCH_65_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[30]_rdy3_DLATCH_67_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[29]_rdy3_DLATCH_69_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[28]_rdy3_DLATCH_71_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[27]_rdy3_DLATCH_73_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[26]_rdy3_DLATCH_75_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[25]_rdy3_DLATCH_77_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[24]_rdy3_DLATCH_79_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[23]_rdy3_DLATCH_81_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[22]_rdy3_DLATCH_83_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[21]_rdy3_DLATCH_85_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[20]_rdy3_DLATCH_87_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[19]_rdy3_DLATCH_89_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[18]_rdy3_DLATCH_91_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[17]_rdy3_DLATCH_93_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[16]_rdy3_DLATCH_95_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[15]_rdy3_DLATCH_97_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[14]_rdy3_DLATCH_99_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[13]_rdy3_DLATCH_101_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[12]_rdy3_DLATCH_103_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[11]_rdy3_DLATCH_105_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[10]_rdy3_DLATCH_107_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[9]_rdy3_DLATCH_109_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[8]_rdy3_DLATCH_111_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[7]_rdy3_DLATCH_113_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[6]_rdy3_DLATCH_115_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[5]_rdy3_DLATCH_117_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[4]_rdy3_DLATCH_119_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[3]_rdy3_DLATCH_121_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[2]_rdy3_DLATCH_123_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[1]_rdy3_DLATCH_125_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[0]_rdy3_DLATCH_127_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
WARNING:Xst:737 - Found 1-bit latch for signal <si_s[63]_rdy3_DLATCH_1_q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.

- - - Updated - - -

neglect the comment lines some typos are there....
 

si_s generation is not shown in the code you have posted. That is where most of the warnings originate.
The warnings are self explanatory. You must be generating si_s combinationally by an incomplete if else. Use an else for every if. Use complete case statements also.That should solve your warnings.
 

There is way more wrong with the code than just not showing si_s generation. Fixing that latch won't fix the problems with the mux coding.

Besides having no formatting whatsoever (shows a lack of organized thinking).
Code Verilog - [expand]
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

always @ * begin
  if (rdy3 == 1'b1 && rdy == 1'b0) begin
    //turn on sinr
    cs_si         = 1'b1;
    cs_p1         = 1'b0;
 
    p1_s          = p1_n;
    p2_s          = p2_n;
 
    si            = si_s;
    si_p          = 64'bz;  // si of p1,p2
 
    p1            = p1_s;
    p2            = p2_s;
 
    op_nd_p12_in  = 1'b0;   // op_nd of p1,p2 is set low so that rdy goes low
    op_si_in      = 1'b1;   // so that rdy of sinr goes high
  end else if (rdy3 == 1'b0 && rdy == 1'b1) begin
    //turn on p1 p2
    cs_si         = 1'b0;
    cs_p1         = 1'b1;
 
    p1_s          = 64'bz;
    p2_s          = 64'bz;
 
    si            = si_s;
    si_p          = si_s;   // si of p1,p2
 
    p1            = p1_n;
    p2            = p2_n;
 
    op_nd_p12_in  = 1'b1;   // op_nd of p1,p2 is set high so that rdy goes high
    op_si_in      = 1'b0;   // so that rdy of sinr goes low
  end else begin
    cs_si         = 1'b0;
    cs_p1         = 1'b1;
 
    p1_s          = 64'bz;
    p2_s          = 64'bz;
 
    si            = si_s;
 
    p1            = p1_n;
    p2            = p2_n;
 
    op_nd_p12_in  = 1'b1;   // op_nd of p1,p2 is set high so that rdy goes high
    op_si_in      = 1'b0;
  end 
end

1. p1_s and p2_s LHS signals feed back into the RHS of the assignments. '=' assignments are blocking therefore the assignments p1_s = p1_n; and p1 = p1_s; means p1 = p1_n;

2. always @ * should be used to avoid missing a read signal, a list of signals in the always is very 1984-1995 (it's 2015 so use Verilog 2001 syntax it's supported).

3. p1_s = 64'bz; There aren't any tri-state buffers in any recent FPGA family (are you targeting the obsolete Xilinx 3000 series parts?)

4. the last else clause is missing the si_p assignment (this is the reason you format code in a clean way and why you should use names that don't look like an attempt at obfuscation of code. I had to add white space between associated pairs of signals to see the missing signal.

5. The else if and the else look to be identical, so why did you include the else if branch?

6. This isn't going to control the switching of the inputs and outputs of the two instances, it has no state information. If the bold wasn't enough, use a FSM to control the switching of the inputs.

7. I was 100% right in my assessment in post #3, you haven't done any kind of design you are just hacking the design together in a randomish fashion. I wasn't giving you a HDL philosophy lesson, I was telling you that the first and for most thing you do is design what you will code. Coding in HDL is how you implement what you've designed (i.e. keyword Description). The code you've been writing doesn't match any design because you never designed the circuit in the first place.

I've been doing this a long time, and I'll give you some advice. Doing up front design works better than hacking code together. Those that start coding without a design plan inevitably end up with code that is broken, convoluted, and usually just complete rubbish. They also are usually the least successful engineers (and the primary source of clueless middle level management ;-)).
 
as now you can see,since you pin pointed out where I am going wrong I am able to correct myself....and to tell you the truth I have started learning hdl by "myself" about a month or so without any "teacher" or whatsoever .....so it is obvious i may start out with writing broken code,ask stupid questions....whereas you being an expert is expected to point out where am i going wrong instead of just saying "you are writing bad code"....:wink:
anyways thanks...
 

Indrajit Ghosh said:
I have started learning hdl by "myself" about a month or so without any "teacher" or whatsoever .....so it is obvious i may start out with writing broken code,ask stupid questions....whereas you being an expert is expected to point out where am i going wrong instead of just saying "you are writing bad code"....:wink:
anyways thanks...
Click to expand...
That is why I stressed in post #3 you must understand that HDL means Hardware Description Language. You design the hardware first, then describe it in Verilog. It's obvious you didn't do that up front design work.

That up front work is far more important to learn to do than silly syntax and what template to use to code something, both of which you can find on the numerous web sites that have sample code for various things like multiplexers, counters, etc.

Also it's not my duty as "an expert" to provide any help whatsoever, even to point out obvious mistakes. I never had anyone have to tell me any of what I've told you. I learned all of this on my own, with no help from edaboard, mentors, co-workers, school. I picked up a Verilog book read it and started designing circuits and translating them into RTL code. So if I think that someone needs to be told they write bad code I have every right to say so, as I'm pretty sure if someone did exactly what I did to learn Verilog they would be a halfway decent Verilog coder (or if they can't maybe that means they aren't a good fit for doing HDL based designs).
 

so if there is no trisate, then how will i make a input port not to accept any values ?
And does simulation support tristate?
 

Indrajit Ghosh said:
so if there is no trisate, then how will i make a input port not to accept any values ?
And does simulation support tristate?
Click to expand...

By ignoring the inputs in the code that uses the input (this is a design issue not a coding issue).

simulation supports tri-state but it makes no sense unless it's a pin on a device (no internal tri-states in ANY FPGA I know of that you can buy).
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top