Bizarre behaviour by Quartus?

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

MikeShepherd564@btinternet.com wrote:

> 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" ?

Quartus does reserve the right to drive "unused"
pins with random internal nodes, which I find
a baffling default.

However I have never seen this happen when
unused pins are assigned to tristate.
I would open case with Altera.

            -- Mike Treseler

Any port in the tio-level-design will become a pin, regardless if it is 
assigned to a location or not. If no location is specified, Quartus will 
choose one for you. I think this behavior cannot be changed (maybe you could 
try "virtual" pins).

Thomas

www.entner-electronics.com

<MikeShepherd564@btinternet.com> schrieb im Newsbeitrag 
news:6o2a32dsbr4vlt9bar7vh7lek3j0v3qfn0@4ax.com...
> 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 

>Quartus does reserve the right to drive "unused"
>pins with random internal nodes, which I find
>a baffling default.
>
>However I have never seen this happen when
>unused pins are assigned to tristate.
>I would open case with Altera.
>
>            -- Mike Treseler

Thanks for that, Mike.  I'll maybe raise it with them when I have more
confidence that I know what I'm doing with Quartus.  For now, at least
I can just make sure not to have unused signals at the top level.

Mike

On Thu, 06 Apr 2006 14:22:34 +0100, MikeShepherd564@btinternet.com
wrote:

>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" 

This is not an option but the default. Top level pins are device pins
and when they are unassigned Altera tools select the "best" location
for them. After all they have to go to some where. Sometimes this is
useful at the very start of the project where you really don't care
where the pins get assigned. You should just assign them to some safe
locations if you don't want this to happen.

rOn Thu, 06 Apr 2006 06:57:00 -0700, "Mike Treseler"
<mike_treseler@comcast.net> wrote:

>MikeShepherd564@btinternet.com wrote:
>
>> 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" ?
>
>Quartus does reserve the right to drive "unused"
>pins with random internal nodes.

Do you have a reference for this ?

mk wrote:

> Do you have a reference for this ?

My only reference is a vivid memory
of a sore experience. But since I made
a big deal out of it, I fired up Quartus 5.1 to check.
The default for unused pins is now
/As output driving GND/
which could still be a rude surprise
when powering up an new prototype.

The old default setting is still available:
/As output driving an unspecified signal/
Don't know what this could be good for.
Routing maybe.

A safer default would be
/As input tri-stated/

         -- Mike Treseler

On Thu, 06 Apr 2006 13:47:05 -0700, Mike Treseler
<mike_treseler@comcast.net> wrote:

>A safer default would be
>/As input tri-stated/

Only with a weak pull-down. I don't want to think about what hundreds
of tri-stated floating inputs would do (ala when you try a small
design on an off-the-shelf board)

>>...... is there a Quartus option "Connect Unassigned Top-level Signals to Random Device Pins Without Asking Me" 

>This is not an option but the default. Top level pins are device pins
>and when they are unassigned Altera tools select the "best" location
>for them. After all they have to go to some where. Sometimes this is
>useful at the very start of the project where you really don't care
>where the pins get assigned. You should just assign them to some safe
>locations if you don't want this to happen.

Why do they "have to go somewhere"?  Surely they could go nowhere?

If Quartus does assign an output itself, I'd at least like a warning.
After all, it's easy to forget to assign at least one signal.  It
could be in conflict with another device.  In my case, it looks like
it was in conflict enough to cause a malfunction.  Instead, there's
just an "info" message (lost among all the other green messages).

If Quartus does assign a pin, where do I see which pin it allocated? I
don't see anything in the pin assignments.  What's the use of
allocating a pin ("best" or otherwise) if it doesn't tell me where it
is?

Mike

Mike Treseler wrote:

> mk wrote:
> 
>> Do you have a reference for this ?
> 
> 
> My only reference is a vivid memory
> of a sore experience. But since I made
> a big deal out of it, I fired up Quartus 5.1 to check.
> The default for unused pins is now
> /As output driving GND/
> which could still be a rude surprise
> when powering up an new prototype.

yes, and you _think_ you are being carefull by
bringing up a design a little at a time.... :(

Why would they do this, do they not have
a low-cost safe pin default ?

-jg