I2C slave module in Verilog does not acknowledge












-1















I wrote this I2C slave module in Verilog:



module I2CSlave(
input iSCL,
input iI2C_CLK,
inout bSDA,
output reg [7:0] odata,
output reg oread,
output wire oactive
);

reg incycle = 1'b0;
reg pSDA;
reg pSCL;
always @(posedge iI2C_CLK) begin
if ((pSCL) && (iSCL) && (pSDA) && (~bSDA)) begin
incycle <= 1;
end
if ((pSCL) && (iSCL) && (~pSDA) && (bSDA)) begin
incycle <= 0;
end
pSDA <= bSDA;
pSCL <= iSCL;
end

assign oactive = incycle;

localparam STATE_IDLE = 0;
localparam STATE_ADDR = 1;
localparam STATE_RW = 2;
localparam STATE_ACK = 3;
localparam STATE_DATA = 4;
localparam STATE_ACK2 = 5;

reg [7:0] i = 0;
reg [7:0] state = STATE_IDLE;
reg [6:0] addr = 7'h03;
reg addr_match = 1;
reg rw;

reg lSDA;
always @(posedge iSCL) lSDA <= bSDA;

assign bSDA = ((state == STATE_ACK) || (state == STATE_ACK2)) ? 0 : 1'bz;
assign oread = (state == STATE_ACK2);
assign ostate = i;

always @(negedge iSCL or negedge incycle) begin
if (~incycle) begin
state <= STATE_IDLE;
addr_match <= 1;
end
else if (addr_match) begin
case (state)
STATE_IDLE: begin
state <= STATE_ADDR;
i <= 7;
end
STATE_ADDR: begin
if (addr[i-1] != lSDA) addr_match <= 0;
if (i == 1) begin
state <= STATE_RW;
i <= i - 1;
end
else i <= i - 1;
end
STATE_RW: begin
rw <= lSDA;
state <= STATE_ACK;
end
STATE_ACK: begin
state <= STATE_DATA;
i = 7;
end
STATE_DATA : begin
odata[i] <= lSDA;
if (i == 0) state <= STATE_ACK2;
else i <= i - 1;
end
STATE_ACK2: begin
state <= STATE_DATA;
i = 7;
end
endcase
end
end

endmodule


As of now it should just read the data sent by master. It seems to work well in simulation, but when I upload it into the FPGA, sometimes everything is OK, however sometimes it does not acknowledge the data sent by master and it just seems to ignore them. I am newbie in Verilog, so I hope, this is not a silly question.










share|improve this question

























  • How thoroughly does your simulation testbench check your design? Do you have 100% coverage?

    – toolic
    Nov 23 '18 at 19:27











  • The testbench only tries to initiate the communication by sending the address and then it sends 1 byte of data. Also the communication must be sped up in simulation, because there is only 100 us available in Quartus Lite.

    – Martin Schmied
    Nov 23 '18 at 19:51
















-1















I wrote this I2C slave module in Verilog:



module I2CSlave(
input iSCL,
input iI2C_CLK,
inout bSDA,
output reg [7:0] odata,
output reg oread,
output wire oactive
);

reg incycle = 1'b0;
reg pSDA;
reg pSCL;
always @(posedge iI2C_CLK) begin
if ((pSCL) && (iSCL) && (pSDA) && (~bSDA)) begin
incycle <= 1;
end
if ((pSCL) && (iSCL) && (~pSDA) && (bSDA)) begin
incycle <= 0;
end
pSDA <= bSDA;
pSCL <= iSCL;
end

assign oactive = incycle;

localparam STATE_IDLE = 0;
localparam STATE_ADDR = 1;
localparam STATE_RW = 2;
localparam STATE_ACK = 3;
localparam STATE_DATA = 4;
localparam STATE_ACK2 = 5;

reg [7:0] i = 0;
reg [7:0] state = STATE_IDLE;
reg [6:0] addr = 7'h03;
reg addr_match = 1;
reg rw;

reg lSDA;
always @(posedge iSCL) lSDA <= bSDA;

assign bSDA = ((state == STATE_ACK) || (state == STATE_ACK2)) ? 0 : 1'bz;
assign oread = (state == STATE_ACK2);
assign ostate = i;

always @(negedge iSCL or negedge incycle) begin
if (~incycle) begin
state <= STATE_IDLE;
addr_match <= 1;
end
else if (addr_match) begin
case (state)
STATE_IDLE: begin
state <= STATE_ADDR;
i <= 7;
end
STATE_ADDR: begin
if (addr[i-1] != lSDA) addr_match <= 0;
if (i == 1) begin
state <= STATE_RW;
i <= i - 1;
end
else i <= i - 1;
end
STATE_RW: begin
rw <= lSDA;
state <= STATE_ACK;
end
STATE_ACK: begin
state <= STATE_DATA;
i = 7;
end
STATE_DATA : begin
odata[i] <= lSDA;
if (i == 0) state <= STATE_ACK2;
else i <= i - 1;
end
STATE_ACK2: begin
state <= STATE_DATA;
i = 7;
end
endcase
end
end

endmodule


As of now it should just read the data sent by master. It seems to work well in simulation, but when I upload it into the FPGA, sometimes everything is OK, however sometimes it does not acknowledge the data sent by master and it just seems to ignore them. I am newbie in Verilog, so I hope, this is not a silly question.










share|improve this question

























  • How thoroughly does your simulation testbench check your design? Do you have 100% coverage?

    – toolic
    Nov 23 '18 at 19:27











  • The testbench only tries to initiate the communication by sending the address and then it sends 1 byte of data. Also the communication must be sped up in simulation, because there is only 100 us available in Quartus Lite.

    – Martin Schmied
    Nov 23 '18 at 19:51














-1












-1








-1








I wrote this I2C slave module in Verilog:



module I2CSlave(
input iSCL,
input iI2C_CLK,
inout bSDA,
output reg [7:0] odata,
output reg oread,
output wire oactive
);

reg incycle = 1'b0;
reg pSDA;
reg pSCL;
always @(posedge iI2C_CLK) begin
if ((pSCL) && (iSCL) && (pSDA) && (~bSDA)) begin
incycle <= 1;
end
if ((pSCL) && (iSCL) && (~pSDA) && (bSDA)) begin
incycle <= 0;
end
pSDA <= bSDA;
pSCL <= iSCL;
end

assign oactive = incycle;

localparam STATE_IDLE = 0;
localparam STATE_ADDR = 1;
localparam STATE_RW = 2;
localparam STATE_ACK = 3;
localparam STATE_DATA = 4;
localparam STATE_ACK2 = 5;

reg [7:0] i = 0;
reg [7:0] state = STATE_IDLE;
reg [6:0] addr = 7'h03;
reg addr_match = 1;
reg rw;

reg lSDA;
always @(posedge iSCL) lSDA <= bSDA;

assign bSDA = ((state == STATE_ACK) || (state == STATE_ACK2)) ? 0 : 1'bz;
assign oread = (state == STATE_ACK2);
assign ostate = i;

always @(negedge iSCL or negedge incycle) begin
if (~incycle) begin
state <= STATE_IDLE;
addr_match <= 1;
end
else if (addr_match) begin
case (state)
STATE_IDLE: begin
state <= STATE_ADDR;
i <= 7;
end
STATE_ADDR: begin
if (addr[i-1] != lSDA) addr_match <= 0;
if (i == 1) begin
state <= STATE_RW;
i <= i - 1;
end
else i <= i - 1;
end
STATE_RW: begin
rw <= lSDA;
state <= STATE_ACK;
end
STATE_ACK: begin
state <= STATE_DATA;
i = 7;
end
STATE_DATA : begin
odata[i] <= lSDA;
if (i == 0) state <= STATE_ACK2;
else i <= i - 1;
end
STATE_ACK2: begin
state <= STATE_DATA;
i = 7;
end
endcase
end
end

endmodule


As of now it should just read the data sent by master. It seems to work well in simulation, but when I upload it into the FPGA, sometimes everything is OK, however sometimes it does not acknowledge the data sent by master and it just seems to ignore them. I am newbie in Verilog, so I hope, this is not a silly question.










share|improve this question
















I wrote this I2C slave module in Verilog:



module I2CSlave(
input iSCL,
input iI2C_CLK,
inout bSDA,
output reg [7:0] odata,
output reg oread,
output wire oactive
);

reg incycle = 1'b0;
reg pSDA;
reg pSCL;
always @(posedge iI2C_CLK) begin
if ((pSCL) && (iSCL) && (pSDA) && (~bSDA)) begin
incycle <= 1;
end
if ((pSCL) && (iSCL) && (~pSDA) && (bSDA)) begin
incycle <= 0;
end
pSDA <= bSDA;
pSCL <= iSCL;
end

assign oactive = incycle;

localparam STATE_IDLE = 0;
localparam STATE_ADDR = 1;
localparam STATE_RW = 2;
localparam STATE_ACK = 3;
localparam STATE_DATA = 4;
localparam STATE_ACK2 = 5;

reg [7:0] i = 0;
reg [7:0] state = STATE_IDLE;
reg [6:0] addr = 7'h03;
reg addr_match = 1;
reg rw;

reg lSDA;
always @(posedge iSCL) lSDA <= bSDA;

assign bSDA = ((state == STATE_ACK) || (state == STATE_ACK2)) ? 0 : 1'bz;
assign oread = (state == STATE_ACK2);
assign ostate = i;

always @(negedge iSCL or negedge incycle) begin
if (~incycle) begin
state <= STATE_IDLE;
addr_match <= 1;
end
else if (addr_match) begin
case (state)
STATE_IDLE: begin
state <= STATE_ADDR;
i <= 7;
end
STATE_ADDR: begin
if (addr[i-1] != lSDA) addr_match <= 0;
if (i == 1) begin
state <= STATE_RW;
i <= i - 1;
end
else i <= i - 1;
end
STATE_RW: begin
rw <= lSDA;
state <= STATE_ACK;
end
STATE_ACK: begin
state <= STATE_DATA;
i = 7;
end
STATE_DATA : begin
odata[i] <= lSDA;
if (i == 0) state <= STATE_ACK2;
else i <= i - 1;
end
STATE_ACK2: begin
state <= STATE_DATA;
i = 7;
end
endcase
end
end

endmodule


As of now it should just read the data sent by master. It seems to work well in simulation, but when I upload it into the FPGA, sometimes everything is OK, however sometimes it does not acknowledge the data sent by master and it just seems to ignore them. I am newbie in Verilog, so I hope, this is not a silly question.







verilog i2c






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 25 '18 at 12:36







Martin Schmied

















asked Nov 23 '18 at 18:28









Martin SchmiedMartin Schmied

148




148













  • How thoroughly does your simulation testbench check your design? Do you have 100% coverage?

    – toolic
    Nov 23 '18 at 19:27











  • The testbench only tries to initiate the communication by sending the address and then it sends 1 byte of data. Also the communication must be sped up in simulation, because there is only 100 us available in Quartus Lite.

    – Martin Schmied
    Nov 23 '18 at 19:51



















  • How thoroughly does your simulation testbench check your design? Do you have 100% coverage?

    – toolic
    Nov 23 '18 at 19:27











  • The testbench only tries to initiate the communication by sending the address and then it sends 1 byte of data. Also the communication must be sped up in simulation, because there is only 100 us available in Quartus Lite.

    – Martin Schmied
    Nov 23 '18 at 19:51

















How thoroughly does your simulation testbench check your design? Do you have 100% coverage?

– toolic
Nov 23 '18 at 19:27





How thoroughly does your simulation testbench check your design? Do you have 100% coverage?

– toolic
Nov 23 '18 at 19:27













The testbench only tries to initiate the communication by sending the address and then it sends 1 byte of data. Also the communication must be sped up in simulation, because there is only 100 us available in Quartus Lite.

– Martin Schmied
Nov 23 '18 at 19:51





The testbench only tries to initiate the communication by sending the address and then it sends 1 byte of data. Also the communication must be sped up in simulation, because there is only 100 us available in Quartus Lite.

– Martin Schmied
Nov 23 '18 at 19:51












2 Answers
2






active

oldest

votes


















0














One possible cause for random fails while running on real hardware is that you didn't synchronize inputs.



You are sampling slowly changing signals (i2c bus will have a long slopes) that are truly asynchronous to your design's clock. Depending on your luck, you will have random violations for setup/hold times of your fpga's d-flops, which results in metastability issues. The same value in the register might be treated differently in multiple parts of the chip. That will wreak havoc in your i2c slave's logic.



You must synchronize asynchronous inputs, in the simplest case passing it through a couple of registers before feeding it to the module's fsm.






share|improve this answer































    0














    You have several issues with your code which could cause mismatch in behavior in simulation and synthesis. For example, the following is not synthesizable and is ignored by synthesis tools. So, your initial state would be different. Check your logs for warnings. Do not use declaration assignments for regs. (ok for wires).



    reg [7:0] i = 0;
    reg [7:0] state = STATE_IDLE;
    reg [6:0] addr = 7'h03;
    reg addr_match = 1;


    The above means that you initialization does not work.



    You messed up blocking and non-blocking assignments in the state machine. Make sure that you use nbas in all places where 'i = 7'. it should be



    i <= 7;


    And make sure that you test enough initialization and different conditions in simulation.






    share|improve this answer
























    • Why not synthesizable? Yes, in ASIC you must reset registers explicitly, but sram-based fpga will definitely initialize registers to a specified values, and synthesizer will not complain. Or maybe it's only Altera/Xilinx allows this?

      – Vlad
      Nov 24 '18 at 8:09













    • Ok, found a good answer to this: electronics.stackexchange.com/a/340338/127801

      – Vlad
      Nov 24 '18 at 8:24











    • Thanks for tip. I replaced the incorrect blocking assignments by the non-blocking ones. Then I removed the unnecessary initializations and I moved the needed ones into initial block. So the uninitialized registers should be equal to 0, right? The problem is, that the FPGA still behaves in the same way. What else exactly should I test in the simulation?

      – Martin Schmied
      Nov 24 '18 at 9:23











    • @Vlad I am using Altera, so it probably should work even the way I had it in my original design, as you have written, but I have also tried to avoid it, as Serge has written, nevertheless it behaves the same way in both cases.

      – Martin Schmied
      Nov 24 '18 at 9:30











    • @MartinSchmied you have to remember that initial blocks are not synthesizable as well. You need to create a reset condition where you can initialize your variables.

      – Serge
      Nov 25 '18 at 13:48











    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53451470%2fi2c-slave-module-in-verilog-does-not-acknowledge%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    One possible cause for random fails while running on real hardware is that you didn't synchronize inputs.



    You are sampling slowly changing signals (i2c bus will have a long slopes) that are truly asynchronous to your design's clock. Depending on your luck, you will have random violations for setup/hold times of your fpga's d-flops, which results in metastability issues. The same value in the register might be treated differently in multiple parts of the chip. That will wreak havoc in your i2c slave's logic.



    You must synchronize asynchronous inputs, in the simplest case passing it through a couple of registers before feeding it to the module's fsm.






    share|improve this answer




























      0














      One possible cause for random fails while running on real hardware is that you didn't synchronize inputs.



      You are sampling slowly changing signals (i2c bus will have a long slopes) that are truly asynchronous to your design's clock. Depending on your luck, you will have random violations for setup/hold times of your fpga's d-flops, which results in metastability issues. The same value in the register might be treated differently in multiple parts of the chip. That will wreak havoc in your i2c slave's logic.



      You must synchronize asynchronous inputs, in the simplest case passing it through a couple of registers before feeding it to the module's fsm.






      share|improve this answer


























        0












        0








        0







        One possible cause for random fails while running on real hardware is that you didn't synchronize inputs.



        You are sampling slowly changing signals (i2c bus will have a long slopes) that are truly asynchronous to your design's clock. Depending on your luck, you will have random violations for setup/hold times of your fpga's d-flops, which results in metastability issues. The same value in the register might be treated differently in multiple parts of the chip. That will wreak havoc in your i2c slave's logic.



        You must synchronize asynchronous inputs, in the simplest case passing it through a couple of registers before feeding it to the module's fsm.






        share|improve this answer













        One possible cause for random fails while running on real hardware is that you didn't synchronize inputs.



        You are sampling slowly changing signals (i2c bus will have a long slopes) that are truly asynchronous to your design's clock. Depending on your luck, you will have random violations for setup/hold times of your fpga's d-flops, which results in metastability issues. The same value in the register might be treated differently in multiple parts of the chip. That will wreak havoc in your i2c slave's logic.



        You must synchronize asynchronous inputs, in the simplest case passing it through a couple of registers before feeding it to the module's fsm.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 24 '18 at 11:32









        VladVlad

        3,6921511




        3,6921511

























            0














            You have several issues with your code which could cause mismatch in behavior in simulation and synthesis. For example, the following is not synthesizable and is ignored by synthesis tools. So, your initial state would be different. Check your logs for warnings. Do not use declaration assignments for regs. (ok for wires).



            reg [7:0] i = 0;
            reg [7:0] state = STATE_IDLE;
            reg [6:0] addr = 7'h03;
            reg addr_match = 1;


            The above means that you initialization does not work.



            You messed up blocking and non-blocking assignments in the state machine. Make sure that you use nbas in all places where 'i = 7'. it should be



            i <= 7;


            And make sure that you test enough initialization and different conditions in simulation.






            share|improve this answer
























            • Why not synthesizable? Yes, in ASIC you must reset registers explicitly, but sram-based fpga will definitely initialize registers to a specified values, and synthesizer will not complain. Or maybe it's only Altera/Xilinx allows this?

              – Vlad
              Nov 24 '18 at 8:09













            • Ok, found a good answer to this: electronics.stackexchange.com/a/340338/127801

              – Vlad
              Nov 24 '18 at 8:24











            • Thanks for tip. I replaced the incorrect blocking assignments by the non-blocking ones. Then I removed the unnecessary initializations and I moved the needed ones into initial block. So the uninitialized registers should be equal to 0, right? The problem is, that the FPGA still behaves in the same way. What else exactly should I test in the simulation?

              – Martin Schmied
              Nov 24 '18 at 9:23











            • @Vlad I am using Altera, so it probably should work even the way I had it in my original design, as you have written, but I have also tried to avoid it, as Serge has written, nevertheless it behaves the same way in both cases.

              – Martin Schmied
              Nov 24 '18 at 9:30











            • @MartinSchmied you have to remember that initial blocks are not synthesizable as well. You need to create a reset condition where you can initialize your variables.

              – Serge
              Nov 25 '18 at 13:48
















            0














            You have several issues with your code which could cause mismatch in behavior in simulation and synthesis. For example, the following is not synthesizable and is ignored by synthesis tools. So, your initial state would be different. Check your logs for warnings. Do not use declaration assignments for regs. (ok for wires).



            reg [7:0] i = 0;
            reg [7:0] state = STATE_IDLE;
            reg [6:0] addr = 7'h03;
            reg addr_match = 1;


            The above means that you initialization does not work.



            You messed up blocking and non-blocking assignments in the state machine. Make sure that you use nbas in all places where 'i = 7'. it should be



            i <= 7;


            And make sure that you test enough initialization and different conditions in simulation.






            share|improve this answer
























            • Why not synthesizable? Yes, in ASIC you must reset registers explicitly, but sram-based fpga will definitely initialize registers to a specified values, and synthesizer will not complain. Or maybe it's only Altera/Xilinx allows this?

              – Vlad
              Nov 24 '18 at 8:09













            • Ok, found a good answer to this: electronics.stackexchange.com/a/340338/127801

              – Vlad
              Nov 24 '18 at 8:24











            • Thanks for tip. I replaced the incorrect blocking assignments by the non-blocking ones. Then I removed the unnecessary initializations and I moved the needed ones into initial block. So the uninitialized registers should be equal to 0, right? The problem is, that the FPGA still behaves in the same way. What else exactly should I test in the simulation?

              – Martin Schmied
              Nov 24 '18 at 9:23











            • @Vlad I am using Altera, so it probably should work even the way I had it in my original design, as you have written, but I have also tried to avoid it, as Serge has written, nevertheless it behaves the same way in both cases.

              – Martin Schmied
              Nov 24 '18 at 9:30











            • @MartinSchmied you have to remember that initial blocks are not synthesizable as well. You need to create a reset condition where you can initialize your variables.

              – Serge
              Nov 25 '18 at 13:48














            0












            0








            0







            You have several issues with your code which could cause mismatch in behavior in simulation and synthesis. For example, the following is not synthesizable and is ignored by synthesis tools. So, your initial state would be different. Check your logs for warnings. Do not use declaration assignments for regs. (ok for wires).



            reg [7:0] i = 0;
            reg [7:0] state = STATE_IDLE;
            reg [6:0] addr = 7'h03;
            reg addr_match = 1;


            The above means that you initialization does not work.



            You messed up blocking and non-blocking assignments in the state machine. Make sure that you use nbas in all places where 'i = 7'. it should be



            i <= 7;


            And make sure that you test enough initialization and different conditions in simulation.






            share|improve this answer













            You have several issues with your code which could cause mismatch in behavior in simulation and synthesis. For example, the following is not synthesizable and is ignored by synthesis tools. So, your initial state would be different. Check your logs for warnings. Do not use declaration assignments for regs. (ok for wires).



            reg [7:0] i = 0;
            reg [7:0] state = STATE_IDLE;
            reg [6:0] addr = 7'h03;
            reg addr_match = 1;


            The above means that you initialization does not work.



            You messed up blocking and non-blocking assignments in the state machine. Make sure that you use nbas in all places where 'i = 7'. it should be



            i <= 7;


            And make sure that you test enough initialization and different conditions in simulation.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 23 '18 at 22:04









            SergeSerge

            3,57921014




            3,57921014













            • Why not synthesizable? Yes, in ASIC you must reset registers explicitly, but sram-based fpga will definitely initialize registers to a specified values, and synthesizer will not complain. Or maybe it's only Altera/Xilinx allows this?

              – Vlad
              Nov 24 '18 at 8:09













            • Ok, found a good answer to this: electronics.stackexchange.com/a/340338/127801

              – Vlad
              Nov 24 '18 at 8:24











            • Thanks for tip. I replaced the incorrect blocking assignments by the non-blocking ones. Then I removed the unnecessary initializations and I moved the needed ones into initial block. So the uninitialized registers should be equal to 0, right? The problem is, that the FPGA still behaves in the same way. What else exactly should I test in the simulation?

              – Martin Schmied
              Nov 24 '18 at 9:23











            • @Vlad I am using Altera, so it probably should work even the way I had it in my original design, as you have written, but I have also tried to avoid it, as Serge has written, nevertheless it behaves the same way in both cases.

              – Martin Schmied
              Nov 24 '18 at 9:30











            • @MartinSchmied you have to remember that initial blocks are not synthesizable as well. You need to create a reset condition where you can initialize your variables.

              – Serge
              Nov 25 '18 at 13:48



















            • Why not synthesizable? Yes, in ASIC you must reset registers explicitly, but sram-based fpga will definitely initialize registers to a specified values, and synthesizer will not complain. Or maybe it's only Altera/Xilinx allows this?

              – Vlad
              Nov 24 '18 at 8:09













            • Ok, found a good answer to this: electronics.stackexchange.com/a/340338/127801

              – Vlad
              Nov 24 '18 at 8:24











            • Thanks for tip. I replaced the incorrect blocking assignments by the non-blocking ones. Then I removed the unnecessary initializations and I moved the needed ones into initial block. So the uninitialized registers should be equal to 0, right? The problem is, that the FPGA still behaves in the same way. What else exactly should I test in the simulation?

              – Martin Schmied
              Nov 24 '18 at 9:23











            • @Vlad I am using Altera, so it probably should work even the way I had it in my original design, as you have written, but I have also tried to avoid it, as Serge has written, nevertheless it behaves the same way in both cases.

              – Martin Schmied
              Nov 24 '18 at 9:30











            • @MartinSchmied you have to remember that initial blocks are not synthesizable as well. You need to create a reset condition where you can initialize your variables.

              – Serge
              Nov 25 '18 at 13:48

















            Why not synthesizable? Yes, in ASIC you must reset registers explicitly, but sram-based fpga will definitely initialize registers to a specified values, and synthesizer will not complain. Or maybe it's only Altera/Xilinx allows this?

            – Vlad
            Nov 24 '18 at 8:09







            Why not synthesizable? Yes, in ASIC you must reset registers explicitly, but sram-based fpga will definitely initialize registers to a specified values, and synthesizer will not complain. Or maybe it's only Altera/Xilinx allows this?

            – Vlad
            Nov 24 '18 at 8:09















            Ok, found a good answer to this: electronics.stackexchange.com/a/340338/127801

            – Vlad
            Nov 24 '18 at 8:24





            Ok, found a good answer to this: electronics.stackexchange.com/a/340338/127801

            – Vlad
            Nov 24 '18 at 8:24













            Thanks for tip. I replaced the incorrect blocking assignments by the non-blocking ones. Then I removed the unnecessary initializations and I moved the needed ones into initial block. So the uninitialized registers should be equal to 0, right? The problem is, that the FPGA still behaves in the same way. What else exactly should I test in the simulation?

            – Martin Schmied
            Nov 24 '18 at 9:23





            Thanks for tip. I replaced the incorrect blocking assignments by the non-blocking ones. Then I removed the unnecessary initializations and I moved the needed ones into initial block. So the uninitialized registers should be equal to 0, right? The problem is, that the FPGA still behaves in the same way. What else exactly should I test in the simulation?

            – Martin Schmied
            Nov 24 '18 at 9:23













            @Vlad I am using Altera, so it probably should work even the way I had it in my original design, as you have written, but I have also tried to avoid it, as Serge has written, nevertheless it behaves the same way in both cases.

            – Martin Schmied
            Nov 24 '18 at 9:30





            @Vlad I am using Altera, so it probably should work even the way I had it in my original design, as you have written, but I have also tried to avoid it, as Serge has written, nevertheless it behaves the same way in both cases.

            – Martin Schmied
            Nov 24 '18 at 9:30













            @MartinSchmied you have to remember that initial blocks are not synthesizable as well. You need to create a reset condition where you can initialize your variables.

            – Serge
            Nov 25 '18 at 13:48





            @MartinSchmied you have to remember that initial blocks are not synthesizable as well. You need to create a reset condition where you can initialize your variables.

            – Serge
            Nov 25 '18 at 13:48


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53451470%2fi2c-slave-module-in-verilog-does-not-acknowledge%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Berounka

            Sphinx de Gizeh

            Different font size/position of beamer's navigation symbols template's content depending on regular/plain...