problem with cyclone POR

[Altera_Forum]

Hi! 

I'm using Cyclone I fpga. During reset my IO pins are not stable...their vibrating between '0' to tristate.. Is this normal? if so, I need a solution to keep my IO pins on tristate. can I control them somehow while the program is being read from the epcs? maybe with reset? 10x a lot! Asaf

[Altera_Forum]

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

[Altera_Forum]

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!

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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?

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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?

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

If you do not have enough logic to probe with SignalTap, then build a modelsim simulation. Its possible that the default Modelsim simulation that Quartus will create will be sufficient for you. In SOPC Builder check the box that creates the simulation files, and then click generate to regenerate the SOPC system and the simulation files. For an SOPC system called sopc_system.sopc, the simulation folder will be called sopc_system_sim/. Inside that folder is a setup_sim.do file. Start Modelsim, cd to that directory, then type 'do setup_sim.do' at the Modelsim command line. Read the text instructions that you see, eg., type 's' to synthesize the design files. I think there is another command to add default signals to the wave editor, alternatively type 'add wave *' to add the top-level files. Then type 'run 10 us' to run the simulation for 10 us.  

 Look at the reset signal and your top-level I/Os that you are having trouble with.  If none of this makes sense, then you need to do some more reading. There is an application note regarding debugging NIOS systems using Modelsim.  http://www.altera.com/literature/an/an351.pdf  Cheers, Dave