I'm using Verilog with the Altera Cyclone II / Nios II) development kit. I'm not yet very experienced with FPGAs. My present design creates text to be superimposed on a TV picture or on a raster created by the FPGA.
At this stage of the design, I read character codes and shapes from the dev kit flash memory (which was initialised by another application). There are no input signals except that I use one of the dev kit push-buttons to select an NTSC or PAL raster. That signal is registered to minimise problems with metastability.
There are two output signals: composite sync and two-level (black/white) video, which I combine in a resistor network and feed to a TV monitor.
In development, I had bizarre behaviour where a minor change to one part of the design changed the behaviour of completely unconnected parts. Simulation did not show these changes. The result was corrupted text (incorrect characters selected and/or corrupted shapes). Another symptom was that one or more of the dev kit LEDs would light and in one case the brightness depended on the state of the push-button. My design does not drive the LEDs and I have configured Quartus to set unused pins as "tri-state with weak pull-up". (On this development kit, the LEDs are driven by a low output).
At first, I assumed it must be my fault, but I checked that my design is fully synchronous. Quartus reports that it should work up to about
150MHz and I'm using only the on-board 50MHz clock. The only aspect of the design unknown to Quartus was the behaviour of the external flash memory (which I read, but do not write). But the flash address is registered to prevent glitches and I don't clock the data until about twice the access time has elapsed.The corruption on-screen is quite repeatable. I ran my fingers along the pins of the flash device to see if the altered timing made any change to the display. It does not.
The results were completely confusing so (since the final design will not use flash memory) I gave up after a couple of days. I removed all my diagnostic signals and the design started to work perfectly !!
I've seen a similar problem today and I now suspect that it is caused when there are output signals at the top level of the design which are not assigned to pins. (This is an easy way to make them appear in the simulation report). As I start assigning the diagnostic top-level signals to unused pins, the problems go away.
Am I missing something here? Am I making a fundamental mistake or is there a Quartus option "Connect Unassigned Top-level Signals to Random Device Pins Without Asking Me" or "Poke Unassigned Top-level Signals into some Lower-level Module" ?
Mike