New Verilog: Incrementing without getting continous assignment conflict - Page 1
Forum section: electronics / general

author: NivagSwerdna
author_rank: Super Contributor
timestamp: March 30, 2023, 08:55:34 pm
content: I'm trying to code my logic and struggling due to my lack of verilog experience...So in a simplified version... I have two buses... one always outputs the value of the video_out register... the other bus can be either in or out... when it is out it outputs the video_out register... when it is in it is Z and a new value can be presented and latched in on a +ve edge of latch_i.Code:module MyThing(data_iob, video_iob, tri_i, latch_i);// Input Port(s)input tri_i;input latch_i;// Output Port(s)inout [7:0] data_iob;// Inout Port(s)inout [7:0] video_iob;reg [7:0] video_out = 8'h01;assign data_iob = video_out;assign video_iob = tri_i ? 8'bZZZZZZZZ : video_out;always @(posedge latch_i)beginvideo_out = video_iob;endendmoduleThat all works fine... but I have a new and slightly obscure requirement...Additionally I need the value of the video_out register to increment on +ve edge of tri_i.i.e. You can get it to increment simply by toggling tri_i and you will get the output on data_iob immediately and then on the same value presented on video_iob when it flips to output.I tried adding...Code:always @(posedge tri_i)beginvideo_out = video_out+8'b1;endbut that results in...Error (10028): Can't resolve multiple constant drivers for net "video_out" at MyThing.sv(24)Error (10028): Can't resolve multiple constant drivers for net "video_out" at MyThing.sv(24)I can see why that might be a problem but cannot think my way around it... Any hint appreciated.

author: ataradov
author_rank: Super Contributor
timestamp: March 30, 2023, 09:30:14 pm
content: Something likeCode:always @(posedge tri_i or posedge latch_i)beginif (latch_i)video_out <= video_iob;elsevideo_out <= video_out+8'b1;endIt is not exactly the same, since latch would have a priority over tri.Also note non-blocking assignments for the sequential logic.But the whole logic is strange. If you are implementing that in FPGA, then you can't use Z for anything other than signals going outside of the device. So, latching video_iob into video_out when tri_i is high, does not make sense.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: March 30, 2023, 10:50:26 pm
content: The other bus is active regardless of whether tri is high or low.

author: ataradov
author_rank: Super Contributor
timestamp: March 30, 2023, 11:07:15 pm
content: If tri_i is high, then wire video_iob would be 8'bZZZZZZZZ. When posedge latch_i happens, it would have to do "video_out = video_iob;", which would require it to latch ZZZ into internal latch. This is not possible in FPGA.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: March 30, 2023, 11:13:32 pm
content: Looking goodThe intention with the Zs was to make video_iob an input. Maybe I got that bit wrong?

author: ataradov
author_rank: Super Contributor
timestamp: March 30, 2023, 11:20:12 pm
content: Ok, yes, it would work as long as video_iob is connected to the outside pins.

author: tom66
author_rank: Super Contributor
timestamp: March 31, 2023, 10:00:54 am
content: Quote from: ataradov on March 30, 2023, 09:30:14 pmYou can use Z in Vivado for internal logic, it will allow you to implement something similar to a multiplexed bus where only one 'talker' is active. Bus state is logical OR if more than one is active. Is it a good idea? No, but I used it in one of my first projects when I was a clueless newb, and it did work just about.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 01, 2023, 01:54:16 am
content: Quote from: tom66 on March 31, 2023, 10:00:54 amFPGAs usually don't have any *internal* "high impedance" state, so if you use Z in HDL, it will be in fact implemented as a multiplexer. Which you can otherwise write in a more explicit way.Just a matter of code style - the end result should be the same.