Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorStrange effect with Stratix FPGA
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 Maik16 Replies
Altera_ForumHello 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
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
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
@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
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
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).
