VHDL to Verilog Conversion Issue - Blocking vs. Non-blocking?

[Gizmotoy]

VHDL to Verilog Conversion Issue - Blocking vs. Non-blocking and Register Delays?

Hello. I have a good amount of experience in VHDL, but I'm trying to learn Verilog. I thought it might be worthwhile to hand-convert some of my VHDL designs into Verilog in order to learn the language. I have one procedure in particular that I can't get converted properly, as it is producing incorrect output. DATA and data_z are coincident on the same clock, and data_2z follows on the rising edge of the next clock.

What I'm looking for is like the VHDL produces: If DATA transitions low to high on clock cycle 1, then on the next clock rising edge data_z transitions, then data_2z on the rising edge after that.

Here's the VHDL that works:

  Reg_Data: process(CLOCK)
  begin
    if rising_edge(CLOCK) then
      if (CLEAR = '1') then
        data_z    <= '0';
        data_2z   <= '0';
        enable_z  <= '0';
        enable_2z <= '0';
        gen_crc_z <= '0';
      else
        data_z    <= DATA;
        data_2z   <= data_z;
        enable_z  <= ENABLE;
        enable_2z <= enable_z;
        gen_crc_z <= GEN_CRC;
      end if;
    end if;
  end process Reg_Data;

And the "equivalent" Verilog that's not quite working right:

always @(posedge CLOCK)
  begin
    if (CLEAR == 1'b1) begin
      data_z    <= 1'b0;
      data_2z   <= 1'b0;
      enable_z  <= 1'b0;
      enable_2z <= 1'b0;
      gen_crc_z <= 1'b0;
    end else begin
      data_z    <= DATA;
      data_2z   <= data_z;
      enable_z  <= ENABLE;
      enable_2z <= enable_z;
      gen_crc_z <= GEN_CRC;
    end
  end

Why does the Verilog perform like this? I seem to be missing something. All signals are defined as Regs, but DATA is an input port for the module if that makes any difference.

 

[FvM]

I'm not aware of a thing like "language specific timing". Also the question of "blocking versus non-blocking" isn't involved here, because the Verilog text is an exact equivalent of the VHDL code as far as I see, correctly using non-blocking assignments, except for the iteration loop variable, which must be blocking by function.

There may be a problem related to the definition of involved signals/variables. As a first step, I would try to determine in which regard the code is behaving differently.

 

[Gizmotoy]

I'm not aware of a thing like "language specific timing". Also the question of "blocking versus non-blocking" isn't involved here, because the Verilog text is an exact equivalent of the VHDL code as far as I see, correctly using non-blocking assignments, except for the iteration loop variable, which must be blocking by function.

There may be a problem related to the definition of involved signals/variables. As a first step, I would try to determine in which regard the code is behaving differently.

Thanks for the reply. For those that are now confused, I changed the first post, apparently as FvM was replying. I eventually came to the same conclusion, and by just some luck happened upon what the actual issue was, which is what is now in the first post. Sorry for switching things around.

In summary, signal registering doesn't occur quite as I have come to expect in VHDL, so I'm now a bit confused.

 

[FvM]

It would be in fact better to add the newer, more simple code in a second post instead of deleting the first one.

But the basic point in my post holds. It's a correct translation from VHDL to Verilog, I don't see any hidden trapdoors.

How do you see the claimed different behaviour? What's your synthesis respectively simulation tool?

 

[Gizmotoy]

It would be in fact better to add the newer, more simple code in a second post instead of deleting the first one.

But the basic point in my post holds. It's a correct translation from VHDL to Verilog, I don't see any hidden trapdoors.

How do you see the claimed different behaviour? What's your synthesis respectively simulation tool?

It was actually a completely different section of code, and I swapped it out pretty fast so I thought I was good. Lesson learned.

I did narrow down the problem.

always @(posedge CLOCK)
  begin
    if (CLEAR == 1'b1) begin
      data_z    <= 1'b0;
      data_2z   <= 1'b0;
      enable_z  <= 1'b0;
      enable_2z <= 1'b0;
      gen_crc_z <= 1'b0;
    end else begin
[B]      data_z    <= DATA;[/B]
      data_2z   <= data_z;
 [B]     enable_z  <= ENABLE;[/B]
      enable_2z <= enable_z;
[B]      gen_crc_z <= GEN_CRC;[/B]
    end
  end

The bold lines of code causes no delay (Ex: From DATA to data_z). DATA and data_z are identical to each other. All are defined as reg, though DATA, ENABLE, and GEN_CRC are also an input ports. If I do the following, and ignore the "dummy*" signals, it works properly.

always @(posedge CLOCK)
  begin
    if (CLEAR == 1'b1) begin
      data_z    <= 1'b0;
      data_2z   <= 1'b0;
      enable_z  <= 1'b0;
      enable_2z <= 1'b0;
      gen_crc_z <= 1'b0;
      
      dummy_data    <= 0;
      dummy_enable  <= 0;
      dummy_gen_crc <= 0;
    end else begin
      dummy_data    <= DATA;
      data_z        <= dummy_data;
      data_2z       <= data_z;
      dummy_enable  <= ENABLE;
      enable_z      <= dummy_enable;
      enable_2z     <= enable_z;
      dummy_gen_crc <= GEN_CRC;
      gen_crc_z     <= dummy_gen_crc;
    end
  end

So I guess the question I have is why doesn't that data_z <= DATA; assignment incur a clock cycle delay? It seems to be common to being input ports, but I don't understand why that would matter.

To answer your question, no synthesis yet. I'm just simulating in Active-HDL.

 

[FvM]

If these are simulated input signals, you need to look at their exact timing. Input signals that change before the setup and hold window of the respective register will be seen in the output after the present clock cycle, signals that change after the window in the next. Signals changing within the window result in an unknown state.

But there should be no difference between VHDL and Verilog code in this regard.