Comments on: Verilog reg, Verilog wire, SystemVerilog logic. What’s the difference? https://www.verilogpro.com/verilog-reg-verilog-wire-systemverilog-logic/ Verilog and Systemverilog Resources for Design and Verification Sun, 26 Jun 2022 07:10:29 +0000 hourly 1 https://wordpress.org/?v=6.5.2 By: MM https://www.verilogpro.com/verilog-reg-verilog-wire-systemverilog-logic/#comment-1441 Sat, 09 Feb 2019 10:50:05 +0000 http://www.verilogpro.com/?p=499#comment-1441 Hi Jason,
Your articles are really helpful.
Can you post something related to UVM?

]]> By: Arianne https://www.verilogpro.com/verilog-reg-verilog-wire-systemverilog-logic/#comment-1412 Sat, 19 Jan 2019 06:05:49 +0000 http://www.verilogpro.com/?p=499#comment-1412 Good article. I certainly appreciate this site. Keep it up!
buy viagra

]]> By: Jason Yu https://www.verilogpro.com/verilog-reg-verilog-wire-systemverilog-logic/#comment-1181 Thu, 18 Oct 2018 20:07:36 +0000 http://www.verilogpro.com/?p=499#comment-1181 In reply to Dmitry.

Hi Dmitry. Using the logic keyword on its own actually declares a 4-state variable, so X’s can also be represented. There is no problem with representing X’s when using UPF, low power simulation, or x-propagation. I have used logic variables successfully on projects that use all these methodologies.

]]> By: Dmitry https://www.verilogpro.com/verilog-reg-verilog-wire-systemverilog-logic/#comment-1180 Thu, 18 Oct 2018 18:46:54 +0000 http://www.verilogpro.com/?p=499#comment-1180 Thank you, Jason, for the article!
One issue I see in replacing reg with logic is that it eliminates X from the variable. That way you may miss initialization problem. I think also using UPF will force X on the registers during power-down for verification. I am not sure that with that practice it will be compatible with UPF. What do you think?

]]> By: Kitesilicon https://www.verilogpro.com/verilog-reg-verilog-wire-systemverilog-logic/#comment-1167 Wed, 10 Oct 2018 01:31:39 +0000 http://www.verilogpro.com/?p=499#comment-1167 Nice write-up, thanks Jason! BTW, its a nice blog, please keep it up !

]]> By: Jason Yu https://www.verilogpro.com/verilog-reg-verilog-wire-systemverilog-logic/#comment-1042 Wed, 01 Aug 2018 07:26:21 +0000 http://www.verilogpro.com/?p=499#comment-1042 In reply to Ptoenkpoalen.

No there isn’t. That just happens to be the example I came up with.

]]> By: Ptoenkpoalen https://www.verilogpro.com/verilog-reg-verilog-wire-systemverilog-logic/#comment-1039 Tue, 31 Jul 2018 04:05:25 +0000 http://www.verilogpro.com/?p=499#comment-1039 Quote:
wire [7:0] my_wire_bus; // implicitly means “wire logic[15:0] my_wire_bus”

Is there a minimal width of 16 bit in SystemVerilog or something?

]]> By: Purushotham https://www.verilogpro.com/verilog-reg-verilog-wire-systemverilog-logic/#comment-749 Wed, 17 Jan 2018 06:51:46 +0000 http://www.verilogpro.com/?p=499#comment-749 Helpful article, thank you Jason.

]]> By: Jason Yu https://www.verilogpro.com/verilog-reg-verilog-wire-systemverilog-logic/#comment-705 Sat, 16 Dec 2017 02:48:25 +0000 http://www.verilogpro.com/?p=499#comment-705 In reply to Jaehyuk.

Hi Jaehyuk. A always@* block will be sensitive to all input signals to the block (with one exception). Therefore, if you use a reg type inside a always@* block, it will become combinational logic and not infer flip-flop or latches.

The one exception is if the always@* calls a function or task, and that function or task contains signals that are external to the function, task, and always@* block. SystemVerilog always_comb avoids this issue, so if you code in SystemVerilog, you should use always_comb instead of always@*. See my other article on always_comb and always_ff

]]> By: Jaehyuk https://www.verilogpro.com/verilog-reg-verilog-wire-systemverilog-logic/#comment-703 Fri, 15 Dec 2017 06:45:22 +0000 http://www.verilogpro.com/?p=499#comment-703 Hi, Jaeson

Thanks for a very nice article.

I have a very basic question about the logic design & Verilog.

As far as I know, it is not recommended to have combinational logic include

memory such as flip-flop and latch because it is combinational!

And that is the reason why inferred flip-flops & latch should be avoided,

which is induced by not including all inputs within sensitivity list in always block, uninitialized output, etc.

My question is if the reg variable inside the always *@ block holds the value until the next assignment, it may induce the flip-flops or latches.

Is it allowed to induce a latch or flip-flop inside the combinational logic with some intentions?

Thanks a lot

]]>