problem with cyclone POR

--- Quote Start ---

I need a solution to keep my IO pins on tristate.

--- Quote End ---

The pin DEV_OE can be used to tri-state all pins. See p331

http://www.altera.com/literature/hb/cyc/cyc_c5v1.pdf

Cheers,

Dave

thank you so much!

do you beleive this is the reason for the unstability I/O pins on the reset?

how should I connect it so when the cyclone resets all pins will go tristate and only when the altera has done initialize all pins will go like programmed?

10x again!

--- Quote Start ---

The pin DEV_OE can be used to tri-state all pins.

--- Quote End ---

It's an optional pin function, that takes effect after entering user mode. It's ignored before and during configuration read.

--- Quote Start ---

During reset my IO pins are not stable...their vibrating between '0' to tristate..

--- Quote End ---

The report doesn't seem to describe a regular behaviour. According to the device manual, all I/O pins will act as inputs with weak pull-up for unconfigured device. They change to the configured behaviour when user mode is entered. There's no room for "vibrating between '0' to tristate" before CONFIG_DONE or more exactly INIT_DONE is asserted. You may want to check the state of this pins (INIT_DONE is optional only) when observing the unwanted behaviour.

My first assumption would be, that the unwanted behaviour is actually observed in user mode due to incorrect logic program. Can you tell, what's the type of affected pins in your logic?

--- Quote Start ---

It's an optional pin function, that takes effect after entering user mode. It's ignored before and during configuration read.

--- Quote End ---

Hey Frank, thanks for the correction. I was going to recommend he use the IO_PULLUP# option that is present on the Stratix devices to enable the weak pull-ups during configuration, however, the Cyclone device does not have that pin. I incorrectly assumed that DEV_OE performed a similar function (with respect to tri-stating during configuration). However, you're right, the device pins are tri-stated during configuration anyway, so the DEV_OE pin function is not required until after configuration.

Cheers,

Dave

the current pin is an output from my NIOS processor.

I dont think I can make logic errors when sellecting an IO pin in a processor :)

Do you have any suggestions?

Hi mackrants,

--- Quote Start ---

the current pin is an output from my NIOS processor.

I dont think I can make logic errors when sellecting an IO pin in a processor :)

Do you have any suggestions?

--- Quote End ---

Can you describe the problem a little better please. For example, is the output a signal from a PIO component on the Avalon bus or is it a direct processor pin (which one)? Or some other signal? What are you trying to control with the I/O, have you enabled a weak pull-up on the signal?

What are you using to look at the signal to determine that it is going between 0 and tri-state? Have you used SignalTap II to capture a trace of the signal?

Cheers,

Dave

--- Quote Start ---

During reset my IO pins are not stable...their vibrating between '0' to tristate..

--- Quote End ---

Are the pins that are 'unstable' clocked, and how is the reset signal generated, and then conditioned? For example, an external reset signal should be 'clean', no glitches, and should be synchronized to the clock domain in which it is used using a cascaded DFF (there are recommendations on the Altera web site). This results in asynchronous reset assertion and synchronous deassertion.

Cheers,

Dave

Hi Dave and thanks again!

I'm Using an Peripherial output of NIOS PROCESSOR, I'v looked at the signal with an agillent scope. I can see the glitches you were talked about.

about the reset, I didn't quite understand... my reset is a hardwere reset, I cant control it from Quartus...so what you meant is to put an actuall DFF between the reset circuit to the altera's reset input, and synchronize it to the clock?

and also... I dont have enought logic elements to map the signals to Signal Tap.

and how can I enable a weak pull-up resistor to the output?

I think, the relation between configuration phase and reset behaviour in the original post is misleading. It's rather a pure reset problem, that's completely located in the NIOS software or possibly FPGA code.

Achieving a clean synchronous reset deassertion is an important point, but I guess, it's implemented for the NIOS core anyway.

Using SignalTap to trace the problem woud be next step, if no obvious reason can bedetected. There's a SignalTap option to use a reset trigger for data aquisition.

Hi,

can it mabye be related to the NIOS PROCESSOR reset?

can I configure the outputs of the processor to tristate during reset? or it can be only '1' or '0'?

10x asaf