Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
853 Views

DE0 board, mysterious LED behavior

I've recently been testing out a daughtercard I made for the DE0 board which includes a motor driver and connector for a quadrature encoder. I was testing some code I wrote to decode the quadrature signals, and it seemed to work fine, but I noticed that as the count value changed (I had it displayed on the 7seg digits), several of the user LEDs were changing state. 

 

According to the documentation on the DE0, these LEDs are controlled directly by the FPGA, but I confirmed that the pins controlling them were not configured in my pin planner. So I tried tying them to ground in my design and trying it again. Now those LEDs were turned off, but a couple other LEDs were now blinking similarly.  

 

I can find no explanation for this weird behavior, and it really bugs me that the FPGA is controlling I/Os in unpredictable ways. Does anyone have any ideas what could be causing this? Thanks in advance.
0 Kudos
5 Replies
Altera_Forum
Honored Contributor I
71 Views

 

--- Quote Start ---  

the FPGA is controlling I/Os in unpredictable ways 

--- Quote End ---  

 

Surely it doesn't. Everything is in your design somehow. First you may want to check in the pinout file of your design what's connected to the LED pins. It may be the case, that unassigned output pins of your design have been connected to these pins. If nothing is connected according to pinout file, a severe hardware problem must be expected however.
Altera_Forum
Honored Contributor I
71 Views

 

--- Quote Start ---  

First you may want to check in the pinout file of your design what's connected to the LED pins. It may be the case, that unassigned output pins of your design have been connected to these pins. 

--- Quote End ---  

 

Do you mean the .pin file? Yeah, it shows that many of the outputs in my block diagram have been assigned to random I/O pins, but they show up as unassigned in the pin planner. It's absurd that quartus would do such a thing, since there is lots of hardware connected to these pins that could potentially be destroyed by this. Is there a way to prevent this, besides manually assigning every single pin?
Altera_Forum
Honored Contributor I
71 Views

 

--- Quote Start ---  

It's absurd that quartus would do such a thing, since there is lots of hardware connected to these pins that could potentially be destroyed by this. Is there a way to prevent this, besides manually assigning every single pin? 

--- Quote End ---  

 

It's not aburd. It's the way, Quartus and design compilers from other vendors usually hande unassigned pins.  

 

Apparently, you are new to basic concepts of these design tools. Basically, the problem is created by defining I/O pins in your top design, that are not intended to be connected externally. Simply, you shouldn't do that.
Altera_Forum
Honored Contributor I
71 Views

What's the reasoning behind randomly assigning signals to pins? 

 

I normally define outputs in my top level schematic for the purpose of simulation, or as placeholders for future connections. It's not too much trouble to remove them, but I'd like to know why it's absolutely necessary.
Altera_Forum
Honored Contributor I
71 Views

Simply consider, that any top design port signal is implemented as I/O pin. I didn't think yet about if it's absolutely necessary, I'm just used to it. Furthermore, Quartus has the option of defining virtual pins that are ignored in I/O assignment, but I fear it may be unavailable in the free Quartus Web edition. I don't use schematic designs, so I can't say if they have a means to specify virtual pins.

Reply