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.

[SOLVED] How to set output pin state of a module?

Status
Not open for further replies.

kenleigh

Member level 1
Joined
Jan 3, 2011
Messages
36
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,288
Activity points
1,525
I'm a noob in verilog.
I have a module that has 2 outputs, RESET and PWDN amongst others.

I want to make RESET output high level(3.3V) and PWDN output low level (0V).

In a microcontroller I would have done something like this

RESET = 1;
PWDN = 0;

Can I do similar in Verilog , something like

Code:
module test(RESET, PWDN)

output RESET, PWDN;

RESET = 1;
PWDN = 0;

end module

However I get error on the line where I have used "="
 

Possibly you mean something like this:

Code:
module test (
    output RESET,
    output PWDN
    );

assign RESET = 1'b1;
assign PWDN  = 1'b0;

endmodule // test


If you're just starting out, then asic-world has some pretty good examples and tutorials.

hope that helps!
 
Possibly you mean something like this:

Code:
module test (
    output RESET,
    output PWDN
    );

assign RESET = 1'b1;
assign PWDN  = 1'b0;

endmodule // test


If you're just starting out, then asic-world has some pretty good examples and tutorials.

hope that helps!

Yes! this works, however I'm unable to understand what was the problem with "=" and "<=".
Why didn't they work out?

Many thanks for the tutorials!
 
Last edited:

What I gave you was a quick quick example. It basically does a continuous assignment to the RESET and PWDN output. As in static outputs. Usually your module will have a clock input, that is for a synchronous design.


As for why the "<=" was not working ... well, the "<=" is typically used inside of an "always" block.

So something like:

Code:
always @(*) begin
    RESET <= 1'b1;
    PWDN  <= 1'b0;
end

will give you the same result as the previous example. Not very useful, functionally speaking... But hey, you asked. :p

Anyways, if you go through some of the examples I'm sure you will see what the general idea is.
 
What I gave you was a quick quick example. It basically does a continuous assignment to the RESET and PWDN output. As in static outputs. Usually your module will have a clock input, that is for a synchronous design.


As for why the "<=" was not working ... well, the "<=" is typically used inside of an "always" block.

So something like:

Code:
always @(*) begin
    RESET <= 1'b1;
    PWDN  <= 1'b0;
end

will give you the same result as the previous example. Not very useful, functionally speaking... But hey, you asked. :p

Anyways, if you go through some of the examples I'm sure you will see what the general idea is.

Thanks for the explanation. That sure was helpful.
What about "=". That sure should have worked, shouldn't it?
And you said that the "assign" keyword does a continuous assignment, does that mean it does it at every clock cycle or only once at power up?
 

And you said that the "assign" keyword does a continuous assignment, does that mean it does it at every clock cycle or only once at power up?

None of the above.

"at every clock cycle"? What clock? The hint is "did you provide a clock signal to your module?". You didn't. So this "test" module is an example of an asynchronous module. Now since all the outputs are static, that somewhat messes up the synchronous vs asynchronous. But basically, everything that is not clocked into registers at the (usually positive) edge of a clock is async. Async modules do have their place, but usually you want modules to have registered outputs.


So quick quick example of the same thing, but then as synchronous module. Note that I add a clock, otherwise not much to be synchronous to...

Code:
module test_synchronous (
    input      clk,
    output reg RESET,
    output reg PWDN
    );

initial begin
    RESET = 1'b0;
    PWDN  = 1'b0;
end


always @(posedge clk) begin
    RESET <= 1'b1;
    PWDN  <= 1'b0;
end

endmodule // test_synchronous
 
Last edited:
Code:
module test_synchronous (
    input      clk,
    output reg RESET,
    output reg PWDN
    );

initial begin
    RESET = 1'b0;
    PWDN  = 1'b0;
end


always @(posedge clk) begin
    RESET <= 1'b1;
    PWDN  <= 1'b0;
end

endmodule // test_synchronous

Thanks again for the wonderful examples.
In this code snippet you have set RESET and PWDN in the initial block and then in the always block you keep setting it at every positive edge.
I guess you used the always block to make this module synchronous, right? otherwise even the initial block would have done for this case, right?
 

Right. Here's something that actually does something, so maybe that makes it a bit clearer...

Code:
module test_counter (
    input            clk,
    output reg [7:0] count
    );

initial begin
    count = 0;
end


always @(posedge clk) begin
    count <= count + 1'b1;
end

endmodule // test_counter

Now you see that the "initial" statement is used only to provide the register with a initial value. In the case of an fpga implementation that means the state of the flip-flop right after the configuration bitstream has been loaded, and before the global set/reset deasserts the reset.

Essentially it does 2 things. 1) make sure you know what state your physical hardware actually starts out with. 2) make sure you know what your simulation starts out with. And as you may find out, it is rather important to have simulation be as close as possible to what your actual hardware is going to do.

If for example you don't specify the initial state of the flip-flop, the actual hardware will start out with the flip-flops set at 0. So no problem there. In simulation however the simulation engine is of the opinion that "count" is undefined at t=0.

And since "undefined" + 1 is still undefined, this module would be a little disappointing if you neglected to specify the initial conditions.

Hope that clears things up somewhat...
 
Right. Here's something that actually does something, so maybe that makes it a bit clearer...

Code:
module test_counter (
    input            clk,
    output reg [7:0] count
    );

initial begin
    count = 0;
end


always @(posedge clk) begin
    count <= count + 1'b1;
end

endmodule // test_counter

Now you see that the "initial" statement is used only to provide the register with a initial value. In the case of an fpga implementation that means the state of the flip-flop right after the configuration bitstream has been loaded, and before the global set/reset deasserts the reset.

Essentially it does 2 things. 1) make sure you know what state your physical hardware actually starts out with. 2) make sure you know what your simulation starts out with. And as you may find out, it is rather important to have simulation be as close as possible to what your actual hardware is going to do.

If for example you don't specify the initial state of the flip-flop, the actual hardware will start out with the flip-flops set at 0. So no problem there. In simulation however the simulation engine is of the opinion that "count" is undefined at t=0.

And since "undefined" + 1 is still undefined, this module would be a little disappointing if you neglected to specify the initial conditions.

Hope that clears things up somewhat...

Many thanks that helped immensely.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top