Some help with code

[antonto]

Hello,

I have two boards, one fpga intel max10 de lite and one microcontroler atmel samd21.
I read some data like the temperature from the microcontroller and i am sending it to the  fpga. The fpga then must display the temperature on the seven segment display.
I am struggling a bit because the number that are displayed on the fpga are very different than the actual temperature.  

What I am basicaly doing is reading some values for example 24.56 then i make this into a 4 digit number so that would be 2456 then i convert it into a 13 bit binary which i send it as an output from pins D0 to D13.
The fpga now gets a 13 bit input where it seperates each digit, so in that example it would be 2 4 5 6 and then display them in each segment, for example in the first segment from the right sight  it will display 6 after that it should display 5 then a 4 with a dot and after that a 2 , but it doesnt!
The values that are displayed are different i have checked many times if the connections are correct from the microcotroller to the fpga. 
Just to mention i tried it with a different method aswell. I tried it with seperating the 13 bit into a 6 bit and a 7 bit. It didnt work either, again different values from the correct ones.
This is my SystemVerilog code, please correct me  if u see something or if you have a different way to approach it!

module testTemp (input logic  [12:0] inBoard,

  output logic   [6:0] sevSeg0,

  output logic   [6:0] sevSeg1, 

  output logic   [6:0] sevSeg2,

  output logic   [6:0] sevSeg3,

  output logic dp);

logic k;

logic [12:0]  inBoard_Decimal;

logic  [3:0] digit0;

logic  [3:0] digit1;

logic  [3:0] digit2;

logic  [3:0] digit3;

initial

  begin

    k = 0;

  end  

always_comb

  begin

    inBoard_Decimal =  inBoard;

digit0 = inBoard_Decimal % 10 ; //first segment 

digit1 = (inBoard_Decimal % 100 ) / 10 ; //  second segment

digit2 = (inBoard_Decimal % 1000 ) / 100;// third segment

digit3 = inBoard_Decimal / 1000; // fourth segment

    case (digit0)

      0: sevSeg0 = 7'b000_0001; // 0 = on  1 = off 

      1: sevSeg0 = 7'b100_1111;

      2: sevSeg0 = 7'b001_0010;

   3: sevSeg0 = 7'b000_0110;

   4: sevSeg0 = 7'b100_1100;

   5: sevSeg0 = 7'b010_0100;

   6: sevSeg0 = 7'b010_0000;

   7: sevSeg0 = 7'b000_1111;

   8: sevSeg0 = 7'b000_0000;

   9: sevSeg0 = 7'b000_1100;

      default: sevSeg0 = 7'b111_1111; 

    endcase

    case (digit1)

      0: sevSeg1 = 7'b000_0001; 

      1: sevSeg1 = 7'b100_1111;

      2: sevSeg1 = 7'b001_0010;

   3: sevSeg1 = 7'b000_0110;

   4: sevSeg1 = 7'b100_1100;

   5: sevSeg1 = 7'b010_0100;

   6: sevSeg1 = 7'b010_0000;

   7: sevSeg1 = 7'b000_1111;

   8: sevSeg1 = 7'b000_0000;

   9: sevSeg1 = 7'b000_1100;

      default: sevSeg1 = 7'b111_1111; 

    endcase  

    case (digit2)

      0: sevSeg2 = 7'b000_0001; 

      1: sevSeg2 = 7'b100_1111;

      2: sevSeg2 = 7'b001_0010;

   3: sevSeg2 = 7'b000_0110;

   4: sevSeg2 = 7'b100_1100;

   5: sevSeg2 = 7'b010_0100;

   6: sevSeg2 = 7'b010_0000;

   7: sevSeg2 = 7'b000_1111;

   8: sevSeg2 = 7'b000_0000;

   9: sevSeg2 = 7'b000_1100;

      default: sevSeg2 = 7'b111_1111; 

    endcase

    case (digit3)

      0: sevSeg3 = 7'b000_0001; 

      1: sevSeg3 = 7'b100_1111;

      2: sevSeg3 = 7'b001_0010;

   3: sevSeg3 = 7'b000_0110;

   4: sevSeg3 = 7'b100_1100;

   5: sevSeg3 = 7'b010_0100;

   6: sevSeg3 = 7'b010_0000;

   7: sevSeg3 = 7'b000_1111;

   8: sevSeg3 = 7'b000_0000;

   9: sevSeg3 = 7'b000_1100;

      default: sevSeg3 = 7'b111_1111; 

    endcase

    dp <= k;

  end

endmodule 

[roeekalinsky]

Numerous things to point out here, but I don't want to start picking apart issues in your code because the bigger issue is methodology, first and foremost.

You should do verification and debug of your code in a test bench in the simulator before you go to the hardware. Always. The simulator is where you have full white box visibility into exactly what in your code is or isn't working the way you expect.

And then after that, as for integration and testing on hardware, it would also be wise to divide and conquer before going for the whole chain end to end. For example, start by just putting out a fixed test pattern from the FPGA to the 7-segment displays, from a constant value set in the FPGA instead of taking input from the MCU. When that's all verified and working, walk backwards to integrate another step in the chain, say like driving a constant value from the MCU to the FPGA, still without taking data from your temp sensor. Etc.

There are also issues with your design approach. Potentially sub-optimal partitioning between the FPGA and MCU.

Doing the decimal modulo and division operations in the FPGA is sub-optimal. These are not trivial operations to implement in logic, they would be fairly resource intensive, and there's no need in your application for them to be particularly fast.  And if you did need these operations in the FPGA for some reason, these are not something you would ordinarily code using a simple arithmetic operator, but more likely using pipelined IP. I'm actually not even sure if the synthesis tool will implement those operators for you without complaint. Anyhow, if you have available a couple more bits of I/O between the MCU and the FPGA, it would probably make better sense to handle those operations in the MCU firmware and then send over four BCD digits to the FPGA instead of straight binary. And if you are I/O constrained, then you could serialize the data transfer instead of using a full-width parallel bus, since again, there's no need in this application to be very fast.

Could go down a deep rabbit hole here... don't want to make too many assumptions about what you're trying to do.

So anyway, to reiterate my most important point to your question, taken at its simplest: Start by debugging your code in the simulator, and only then go to hardware and integrate one step at a time!

[antonto]

Thank you for your time i will listen to your advice and go step by step just like you described

[TingJiangT_Intel]

Hi there.

First, You are using pure combinational logic which may makes your design relatively fragile and unstable. It's recommend use clock and reset.

Also, 'initial' is not compilable. We usually apply it only in testbench, please consider using 'always' to assign initial value.

BTW, it's necessary to do simulation before implement on borad for function verification.

[antonto]

Thank you for your time.
I listened to roeekalinsky and did everything step by step. Im sure that the design is not the best but after doing some tests it works.
The problem was with the microcontroller, it didnt give the output it should have.
For example i tried a 4 bit output and therefore a 4 bit input on the fpga for a single7 segment display. After doing some tests
i realized that some pins of the microcontroller werent in the right order, or at least it didnt read it in the correct order.
As i said in this example i have a 4 bit output so i said lets try every number from 0 to 9 and display it on the fpga.
So i tried 0000,0001,00010 etc .  I dont know why but 0010 gave 4 instead of 2, so i had to make some changes on the pin planner which i find it odd because im sure that they should be in the same order right? 
Anyway after some hours i did the right pin assignemed and now works fine. But i tried a bit different method, i seperated the 4 digit number to a 6 bit and a 7 bit output.

[FvM · Accepted solution]

Hi,
in principle, there's nothing against designing a pure combinational FPGA, e.g. a binary to seven-segment decoder as shown above.

By design, unregistered combinational logic has output glitches, but that's not necessarily a problem for a seven-segment decoder.
The worst point of the present design is the ineffective way to implement binary to BCD conversion. In an FPGA implementation, look-up table would be the best resource saving solution. Without block RAM, double dabble algorithm can reduce logic cell count.

Apart from ineffective implementation, I don't see a problem with code. It's producing correct output.

If it's intended as HDL learning project, I agree that synchronous design is preferred.

[antonto]

Thank you for your time.
I listened to roeekalinsky and did everything step by step. Im sure that the design is not the best but after doing some tests it works.
The problem was with the microcontroller, it didnt give the output it should have.
For example i tried a 4 bit output and therefore a 4 bit input on the fpga for a single7 segment display. After doing some tests
i realized that some pins of the microcontroller werent in the right order, or at least it didnt read it in the correct order.
As i said in this example i have a 4 bit output so i said lets try every number from 0 to 9 and display it on the fpga.
So i tried 0000,0001,00010 etc .  I dont know why but 0010 gave 4 instead of 2, so i had to make some changes on the pin planner which i find it odd because im sure that they should be in the same order right? 
Anyway after some hours i did the right pin assignemed and now works fine. But i tried a bit different method, i seperated the 4 digit number to a 6 bit and a 7 bit output.

[TingJiangT_Intel]

Glad to hear that, please let us know if any updates.

[antonto]

Well after some research i have found out that the board that i have sometimes messes up the pins just like i said instead of 2 it gave me 4 on the bit outputs. Just wanted to share it.

[TingJiangT_Intel]

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.