Verilog problem: two processes writing to the same register

[Maxlor]

After the recent introduction to the ICE40 FPGAs in the guest video from OpenTechLabs, I've started playing with Verilog. However, I've run into a problem that I can't figure out, trying to make a serial bus interface with a chip select and a clock line. I've built a minimal example:

Code: [Select]

module test(input cs, input clk, output counterbit);
    reg [3:0] counter;
   
    // without at least some output, yosys optimizes everything away!
    assign counterbit = counter[0];
   
    always @(posedge cs) begin
        counter = 0; // it works if this is commented out
    end
   
    always @(posedge clk) begin
        if (cs == 0) counter = counter + 1;
    end
endmodule


If line 8 (where it says "counter = 0") is commented out, this appears to work; yosys builds a blif file and reports that 3 cells were used. If the same line is not commented out, yosys still runs without error, but appears to produce an empty design where 0 cells are used.

So, am I doing something illegal here, writing to counter from two separate processes? If so, what's a good way to do this instead? Any insight you can give me would be appreciated.

[Buriedcode]

The sensitivity list must contain all inputs that are to be evaluated in the always block.  For purely synchronous logic, then only 'clk' needs to be there, but as the reset is to be asynchronous it can be included.  You can add "cs" to the sensitivity list, then use an if statement to check for a reset. 

Code: [Select]

module test(cs, clk, counterbit);
    input cs;
    input clk;
    output counterbit;
    reg [3:0] counter;
    assign counterbit = counter[0];
   
    always @(posedge cs or posedge reset) begin
        if (reset)
            counter = 0;
        else
            counter = counter + 1;
    end
   
   
endmodule

[ataradov]

So, am I doing something illegal here, writing to counter from two separate processes?

Yes, absolutely.

If so, what's a good way to do this instead? Any insight you can give me would be appreciated.

From a Verilog point of view - do all the stuff in one always block.

On a higher level - think what is going to happen in the hardware. Draw your circuit from basic logic gates (high level only), and you will see that what you want here is impossible.

[Maxlor]

Thank you guys, that made things clearer for me. I guess I need to get more comfortable with the concept of describing states, as opposed to reacting to events like I do with regular software engineering.

[rstofer]

I'm surprised the tool didn't flag a 'multiple source' error against counter.  I don't know anything about Verilog but I know for a fact (and a reason) that Xilinx ISE will flag it when I try it with VHDL.

[hamster_nz]

You might find it helpful to think of it this way. In general your logic will have three different types of signals.

The first are those where the signal edges matters. These only provide timing information and are called 'clocks'.

The second are those where the value of the signal matter. These hold data, and when the data changes should depend on only the timing information from one 'clock' signal.

In general you want to use these type types of signals for FPGA work, and you should stick to these two as much as possible.

The third class is called "nightmares", "accidents waiting to happen", "async reset signals" and many other names.
They control both what will happen and when it will happen, and are always problematic and require careful analysis.

In your case, you used "cs" as a clock ("always @(posedge cs) begin"), and as data ("if (cs == 0)..."), and were updating "counter" based on timing information from two different clock signals ("cs" and "clk"). You needed to be clearer in your design about which signals are clocks, and signals are data (don't worry, everybody does this at the start!)

Sometimes the EDA tools are able to give you exactly what you asked for, but unless you have a very good reason and are very careful about it the results are not usually what you want, or contain hidden timing errors, seem to work non-deterministically, and/or have glitches.

[Maxlor]

I'm surprised the tool didn't flag a 'multiple source' error against counter.  I don't know anything about Verilog but I know for a fact (and a reason) that Xilinx ISE will flag it when I try it with VHDL.

Don't be, these aren't professional tools I'm using, but Yosys and Icarus Verilog, the tools mentioned in that EEVBlog guest video:

I'm guessing they're fairly limited in what they do, but they're also small und much easier to grok than the ginormous and feature/slang-packed vendor tools.

[rstofer]

The non-factory toolchains are fine as far as they go which is generally up through simulation.

The thing is, I'm not interested in simulation, I want to build hardware.  More specifically, I want to take advantage of the features of the specific chip I bought (actually, I buy development boards).  I want to instantiate Xilinx proprietary features like PLLs, DCM, BlockRAM, etc.  I want to see blinking LEDs!  The more switches, knobs, dials and LEDs on the board, the better I like it!

You are correct, the factory toolchains are ginormous.  But they produce real images for real hardware and that's what I am after.

There is no chance I am going back to work but if there was the most remote possibility, I would want to learn one or more vendor toolchains.  Xilinx and Altera for sure, Lattice if I had time.

[ataradov]

The non-factory toolchains are fine as far as they go which is generally up through simulation.

Yosys is a full toolchain for some limited subset of ICE40 FPGAs.

It is pretty amazing how far they carried this. But yes, for anything practical, I would stick with vendor tools for now.