Strange effect with Stratix FPGA

[Altera_Forum]

Hello! 

 I am using a Stratix EP1S10 device on a NIOS II Development Board. I use it for VHDL programming only. That means, I don't use any NIOS stuff in my project. I made my own user configuration with which I configure the FPGA. Up to now, all works fine.  Now, I have implemented a shift register in my project which works fine, too. It is 850 shifts deep and shifts a 11 bit wide vector. Parallel to the shift register I implemented some logic, which examines the contents of certain shift register parts. That works fine, too, up to the moment, when the parallel logic becomes maybe too complex. Then there are strange effects on my board I can`t explain myself. For example there is a dot in the seven segment displays on my board wich is connected to the pin D19 of the FPGA, which gets active, although I never assigned the PIN D19 in the pin assignment editor. Another effect is, that the output of the FPGA is no more compatible with the output of the simulator in Quatus II, where all works as expected.  When I remove some logic off the shift register, it is all right again.  I know, it is hard for you to answer that, when you don't know my project, but it could be, that somone of you had similar experience (especially with the dot, which is active although it is not assigned or somethink like that), and can give me some hints, why this happens.  Greets Maik

[Altera_Forum]

Are all the pins assigned? That's one possibility, that something that is not assigned gets put onto D19(although not that likely to repeat). If you go to Assignments -> Device -> Device and Pin Options -> Unused Pins(tab), what is this set to? Basically this controls the pins you haven't assigned, including D19. If it's set to Outputs Driving an Unspecified Signal, then it's possible that it is toggling. There was an earlier thread with a list of things to look at when starting a project, and I believe this was on there. 

 As for the rest of it not matching the simulation, how many clocks do you have in your design? A useful thing I do is open the report file, go to Fitter -> Resource Section -> Control Signals and sort on Usage. This will list all the clocks in your design together. Note that this is slightly different to timing analysis clocks, as it shows every node that drives the .clk port of a register. So gated clocks will show up here, while during timing analysis the gated clocks are usually just part of the domain that drives them.  If everything is synchronous and passes timing, then you may need to pull out SignalTap. I believe almost every FPGA design should plan on using SignalTap, as once you get the hang of it, it's a blessing for debugging your logic. (I say this as you need to plan to use some logic and a decent amount of memory resources to do SignalTap).

[Altera_Forum]

Good reply above. Another possibility is that when your shift-register size increases beyond a threshold the synthesis tool could be replacing the logic-element implementation with a RAM block based implementation. To disable this go into "Assignments / Settings / Analysis & Synthesis Settings" then select the "More Settings" box. Set the "Auto Shift Register Replacement" and "Auto Ram Replacement" both to "Off".

[Altera_Forum]

@Rysk: Thank you for your extended answer. Honestly, I didn't expected something like that on my vague question. 

I set all my unused pins to "As input tri-stated". Otherwise, I had some more strange effects with a lot of pins toggeling, which lead to periodic re-configuring of the device. Unfortunatly for my problem, this means, that you don't have a clue, either, about this D19 problem . . . In my Control Signals tab, I have only one 'Clock'. The other stuff is all 'Clock enable' and 'Sync. clear' which, I guess, is logic implemented by the synthesis. Signal Tap is completly new to me. However, if you recommend to use it, I have to take a look at it, to figure out what it even does.  @endian: Thank you for your answer, too. In fact, I always thought, that the RAM-block based implementation of my shift register is the better way. Moreover, I noticed an opposite effect. I extended my shift register for a test with 10 more shift lines, and after that it was implemented in logic-elements. After reducing the shift register size, it was in RAM, again. The advantage of the RAM implementation is, that simulation is a lot faster, than with the logic elements. . . Anyway, what in your eyes is the advantage of a shift-register in logic-elements than in RAM-blocks?  (I just tried to implement the shift-register in legic-elements. Now, I have a total logic-elemts usage of 10551/10570 (100%). That means I don't have much left to implement some additional logic . . . :rolleyes: )  Greets Maik

[Altera_Forum]

Is there a pull-up on that pin? If the FPGA is input tri-stated, then there is no driver on the line, so it's floating and can randomly do anything. That's part of the reason input tri-stated is not the default, as there needs to be an external driver on the pins. Otherwise they can sit near the threashold, which causes the input to toggle and waste power. If you can add a pull-up(maybe have all unused inputs as pull-ups), that could resolve it. 

 As for shift registers out of memories, there's an algorithm based on width-depth and memory sizes in the part(Stratix devices with M512s are much more likely to put small shift registers into memory than Cyclone with M4Ks as its smallest size). The only reason I've seen to turn it off is a) you're running out of memories or b) you have a timing issue related with that specific shift-register(since the input and output registers are in a fixed location, so the shift-register can't be spread across the device.  As for SignalTap, it's almost a must-have for debugging. If you don't have a lot of memory available after implementing your design, I recommend to people to build a proto-board with a larger device(assuming vertical migration is possible in that package), just for SignalTap. Note that in the Incremental Flow(where it just refits the SignalTap block rather than doing full compiles from scratch), it is recommended to only tap registers(because combinatorial logic gets synthesized into LUTs and doesn't look the same or can't be accessed). Even registers sometimes have quirks, like not-gate-pushback, which causes the register to look like it's in the opposite state of what you expect. It looks that way to you, but works correctly in the design. But once you use it, you can see what's going on in real time on the board, rather than running a billion sims.

[Altera_Forum]

Hello! 

 Well, as this is a devlopment board, I am using, there is no way for me to add a pull up resistor on it. What is strange to me, is that it only occurs, when I add a more complex logic besides my shift register. If i remove this logic, the D19 pin is steady off. Now, I have an additional and even more dramatic problem with the serial interface on my board. I added some logic to use the serial Interface as UART to communicate with a PC. All works fine in the simulation, and on the board, as long as I don't assign the TXD pin in my design. I repeat, because this is very strange to me: I have a configuration running on my board, which works, as far as I can say, without any problems. Then, I assign the pin (U21) as TXD pin (because the documentation of my board says it is connected there) WITHOUT changing any of the VHDL files. After that, my board allways boots again and again and again. Booting means, that the user configuration is reloaded over and over again. In between the reloads, it sends correct data over the UART, but I don't know, what makes the board do that crazy rebooting . . .   Thanks also for the additional information about the shift-register issue and the Signal Tap! Unfortunatly, my primary goal is to solve this rebooting problem . . .   Maik

[Altera_Forum]

Hello again! 

 For those, who are interested: I solved the problem with the continuous rebooting.  The case was, that my design is apparently so complex, that the voltage source of my board gets overloaded. The effect with the rebooting occurs, when I brought the UART IC to working with the assignment of pin U21. That must have been the last straw for the power supply. I have a power supply monitor IC on my board which forces the board to reboot, when the voltages become incorrect. As I need the UART at all costs, I decided to reduce the depth of my shift register, which solved the problem. Now, my board works stable, and as good, as the simulation predicted.  The only issue still left is now this cursed 7-segment dot on D19 . . . Anyway, this seems to have no bearing on my design . . .  Greets Maik

[Altera_Forum]

Can't you change the unused pins to Input with Weak Pull-Up or Bus Hold? That way you don't have to tie an external resistor. Of course, the light will always be on with a pull-up, but at least you'll know why. 

 How fast is your shift-register toggling? What kind of data is going thru it? Is it going into a RAM or registers? From your previous post, you had one with a ton of registers through most of the device. If they're all toggling at a fast rate(i.e. a fast clock and constantly changing data), you'll use a lot of power. Having it go into RAM should significantly reduce that since you're only reading/writing a single RAM and incrementing counters. Although the power supply on the demo boards should be fine for almost all designs, if you really get everything toggling at high-rates, I could definitely see that happening. Glad you're making progress though.

[Altera_Forum]

Hi Rysc! 

 My Shift Register is toggling at 25MHz. (The Master clock on my board is 50MHz). It is now implemented in RAM again. I only tried to implement it into logic-elements, after endian wrote something about it. If I do so, my whole FPGA is nearly a single shift register. That does not work for me, because I need some logic besides the shift register. So finally, I advised the synthesis tool to put it into RAM again. The signals I shift through it are 11 bit wide data. And the depth of the shift register is now 630. So one can say it is a 630x11 bit shift register. Before, it was a 850x11 bit shift register. In the future I will need again the bigger one, but for now, it works as it is. About the data, one has to know that it is not every bit of the shift register 'filled' with a high value at a time. Normally, I have 4-5 11 bit words filled with data. In between them, the shift register elements are all empty. I would have never thought, that it does consume that much power. . .   Besides the FPGA, my board has to drive the UART IC+line and an ADC evaluation kit at 25MHz. Maybe alltogether is to much for the power supply, although I am a little bit disappointed about the fact, that it can't handle that . . .   Greets and thanks for your support! Maik

[Altera_Forum]

That doesn't sound right that it's hitting the power supply. I figured if you whole FPGA was toggling at, say >150MHz with truly random data(i.e. 50% toggle rate) you could be using too much power. Once you're in memory, it sounds like a pretty normal design. Are all the IO assigned and correct? (I know that's a loaded question). I'm just guessing something else may be using a lot of power, like IO contention. Not really sure though.

[Altera_Forum]

All the above advise sounds reasonable. 

 I have found that for pre built "reference boads" it is wise to make sure that all pins that have external components connected to them ALWAYS have those pins fully assigned in the assignment editor. You need to add "extra" code to the design to properly drive outputs to pins that expect something (like your LED "." element). You need to also "catch" inputs and do something with them, anything will do.  This way, every external pin will not be flapping in the wind. (OK, inputs can be ignored if the device driving them has something like a CE (chip enable) that can be driven to tell the external device to stay quiet).  I hope this helps. Avatar

[Altera_Forum]

I think, that all IOs I use are assigned right, and there should be no conflicts with other board components, because I use the so called prototyping connectors of the board for the ADC connection. The UART interface and the seven-segment display, too, do not share their resources with other componets. 

 Hmm, it sounds like a lot of additional work, if I have to assign every pin which is connected to an external component. The board is very complex, with SRAM, SDRAM, Eth Phy, 2 UARTS. That would be a lot of logic, I have to spend on these pins.   Is there no way, to turn unused pins completly off?

[Altera_Forum]

Since you are asking me for specifics. 

 I would set the tool for Un-used pins as inputs with Tri-state pull up.  I would look at each IC that is attached to the FPGA.  If it has the ability to present noise on the inputs, I would see what Output pin will place that chip in turned off mode (none chip select). I would then drive that output pin to the appropriate high or low level to achieve that goal.  Passive input pins from passive external logic will be covered by the above un-used pins settings.  That is what you should do in my 30 years of experence (humble opinion).  I hope this helps. Avatar

[Altera_Forum]

--- Quote Start ---  I would set the tool for Un-used pins as inputs with Tri-state pull up.  --- Quote End ---   I allready did this, but this   --- Quote Start ---  I would see what Output pin will place that chip in turned off mode (none chip select).   --- Quote End ---   is a great idea. I will try this tomorrow, and see if it will work!  Thanks! Maik

[Altera_Forum]

Remove the clock (x-tal) and you can see the difference between dynamic + static and static power consumption. Make sure the clock is realy gone by gnd-ing the input otherwise it may pickup noise instead. Datasheets tells you the static power consumption. Maybe that can give you a hint.

[Altera_Forum]

Hi larsen! 

 Thanks for your participation to this thread!  I think I identified the evildoer. It seems to be the LAN91C111 on my board. When I run my own configuration, he becomes hot as hell. When I reload the NIOS configuration with which the board was delivered (and which I use every time, I reconfigure the FPGA with my configuration), the LAN91C111 becomes hot, too, but not quite as hot, as with my configuration (I wonder how he even survived this all the time . . . )  Now, I have a problem: I looked for a pin on the LAN91C111 that says "turn me off" or something like that. But there isn't one. Instead I have to write some bits into some configuration registers I would like to be able to access, but I do not understand the datasheet of this fellow, at all (http://www.smsc.com/main/datasheets/91c111.pdf (http://www.smsc.com/main/datasheets/91c111.pdf)).  Is there anybody out there, who can give me some advise, how to write a simple disable entity for this chip?  Greets, Maik

[Altera_Forum]

Why don' t You import the Pin Assigment from a sample design for the development board You are using and modify only the Pin assignments specific to Your design. I have been working with a CYCLONE Development Board sample designs which also shows how to place the LAN Controller in a quiescent state. 

When using development board to host my custom design, I found always usesful to open an existing sample design delete their logic and implement my logic; this clears all the board interfacing issues (inlcuding FPGA configuration issues) and allows me to focus on the actual design that I am trying to prototype.