Forum Discussion
Altera_Forum
Honored Contributor
18 years agoIs 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.