New Verilog: Incrementing without getting continous assignment conflict

[NivagSwerdna]

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: [Select]

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)
begin
video_out = video_iob;
end

endmodule
That 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: [Select]

always @(posedge tri_i)
begin
video_out = video_out+8'b1;
end
but that results in...

Error (10028): Can't resolve multiple constant drivers for net "video_out[1]" at MyThing.sv(24)
Error (10028): Can't resolve multiple constant drivers for net "video_out[0]" at MyThing.sv(24)

I can see why that might be a problem but cannot think my way around it... Any hint appreciated.

[ataradov]

Something like

Code: [Select]

always @(posedge tri_i or posedge latch_i)
begin
  if (latch_i)
      video_out <= video_iob;
  else
video_out <= video_out+8'b1;
end
It 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.

[NivagSwerdna]

The other bus is active regardless of whether tri is high or low.

[ataradov]

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.

[NivagSwerdna]

Looking good



The intention with the Zs was to make video_iob an input.  Maybe I got that bit wrong?

[ataradov]

Ok, yes, it would work as long as video_iob is connected to the outside pins.

[tom66]

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.

You 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. 

[SiliconWizard]

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.

You 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.

FPGAs 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.