Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20777 Discussions

Issue with Seven Segment

antonto
Novice
834 Views

Hello, i have the max10 de-10 lite and im having a small issue with the seven segments. 
My code is below, so when given input the board works fine, just like expected but when it has no input the seven segment displays 63.null 7  (null, doesnt display anything). Is my default wrong on the case? I tried  this 7'b000_000;  but it displays 63.87, basically the same instead of the null, do u have some ideas maybe what is happening? 
Thank you for your time.

 

module ptErg (input logic  [6:0] inBoard,
  input logic [5:0]  inBoard2,
  output logic   [6:0] sevSeg0,
  output logic   [6:0] sevSeg1, 
  output logic   [6:0] sevSeg2,
  output logic   [6:0] sevSeg3,
  output logic dp);
 
 
logic [6:0]  inBoard_Decimal;
logic [5:0]  inBoard2_Decimal;
logic  [3:0] digit0;
logic  [3:0] digit1;
logic  [3:0] digit2;
logic  [3:0] digit3;
 
 
 
 
  
    
  
always_comb
  begin
  
  
    
    inBoard_Decimal =  inBoard;
inBoard2_Decimal = inBoard2;
 
  
digit0 = inBoard_Decimal % 10 ;   
digit1 = inBoard_Decimal / 10 ; 
digit2 = inBoard2_Decimal % 10; 
digit3 = inBoard2_Decimal / 10;   
 
 
 
    
   
    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 <= 1'b0;
 
 
  end
 
endmodule 
  
0 Kudos
1 Solution
roeekalinsky
Valued Contributor I
773 Views

If the inputs are unconnected and there's no pull-down resistors or other physical means to pull them down to the a low state, then you have no reason to expect that they would default to a low state. The state of a floating input should be regarded as unpredictable. In fact, with some devices, floating inputs can float to the transition region and/or oscillate, which can cause all kinds of problems including excessive power consumption and noise. Letting inputs float without some physical means to pull them definitively in one direction or the other is generally bad practice that should be avoided.

 

Fortunately for you, the FPGA's I/O cells have a build-in means to do this, including internal weak pull-ups that can be optionally enabled. The fact that your inputs seem to be defaulting to the high state when unconnected suggests that you might already be enabling these pull-ups, whether you knew it or not.

 

If I may make a suggestion about how to handle this in your design, you should make sure to enable these pull-ups, first and foremost. But then, also, you can actually take advantage of the fact that they pull your input vector to this numerically invalid state of all high. You can have your logic detect this as a way to determine that your inputs are unconnected, in which case you could put up an appropriate indication on the 7-seg displays, like "----" or "Err" or some such thing.

View solution in original post

6 Replies
roeekalinsky
Valued Contributor I
813 Views

What do you mean when you say the board has "no input"?  Are the input pins to the FPGA simply floating?  Are there pull-ups?

 

Anyhow, the output pattern you're describing is exactly what you'd expect to see from your code if your inputs are all high, i.e. if inBoard = 7'b1111111 and inBoard2 = 6'b111111.  This will result in:

 

digit0 = 127 % 10 = 7

digit1 = 127 / 10 = 12 (which your 7-segment case turns to null)

digit2 = 63 % 10 = 3

digit3 = 63 / 10 = 6

0 Kudos
antonto
Novice
778 Views

Hello, sorry for not giving enough information. 
I basically have a microcontroller that reads some data, to be exact it reads the temperature of its cpu and i send it to the fpga connected with the arduino pins on the fpga. 
Now when i connect the MCU  to the fpga , the seven segment displays exactly what the mcu temp is reading, but when there is nothing connected on the arduino pins on the fpga   i get this number . Just like you described i get all high inputs. Can u explain to me why that happens?? Shouldnt they be low inputs instead of high?

0 Kudos
roeekalinsky
Valued Contributor I
774 Views

If the inputs are unconnected and there's no pull-down resistors or other physical means to pull them down to the a low state, then you have no reason to expect that they would default to a low state. The state of a floating input should be regarded as unpredictable. In fact, with some devices, floating inputs can float to the transition region and/or oscillate, which can cause all kinds of problems including excessive power consumption and noise. Letting inputs float without some physical means to pull them definitively in one direction or the other is generally bad practice that should be avoided.

 

Fortunately for you, the FPGA's I/O cells have a build-in means to do this, including internal weak pull-ups that can be optionally enabled. The fact that your inputs seem to be defaulting to the high state when unconnected suggests that you might already be enabling these pull-ups, whether you knew it or not.

 

If I may make a suggestion about how to handle this in your design, you should make sure to enable these pull-ups, first and foremost. But then, also, you can actually take advantage of the fact that they pull your input vector to this numerically invalid state of all high. You can have your logic detect this as a way to determine that your inputs are unconnected, in which case you could put up an appropriate indication on the 7-seg displays, like "----" or "Err" or some such thing.

antonto
Novice
720 Views

Thank you for your time.
i will try to use pull ups to see how it works
Thanks again!

0 Kudos
antonto
Novice
773 Views

I made some changes on the code
I basically added an always_ff and a clock that checks the inputs
The rest of the code is  the same. Still im wondering why does it get high input. Would be grateful if u can answer that.
Thank for your time.

always_ff @(posedge clk)
begin
if (inBoard == 7'b1111111)
inBoard_Decimal <= 7'b0000000;
else
inBoard_Decimal <= inBoard;

if (inBoard2 == 6'b111111)
inBoard2_Decimal <= 6'b000000;
else
inBoard2_Decimal <= inBoard2;

end



0 Kudos
Ash_R_Intel
Employee
633 Views

Hi,

I see that community users have helped you in your case.

On your query related to undriven input pins, the pins can be read as high or low. It is unpredictable. Occasionally it could be read as high due to some leakage current following through the pins.


Hope this answers your question.


Regards


0 Kudos
Reply