06-05-2014 07:50 AM
I have a board with spartan 6 and dd3, microblaze app.
I have an external reset as well, connected to the usual proc_sys_reset.
From an external microcontroller, when I see the DONE pin active, I send a 10mS pulse reset to the FPGA.
The problem is that If I power on my board when it's warmed up (air temp 40c), the microblaze can't often access the DDR, it get stuck.
If I insert a pause of 100mS between DONE active and my reset, then it goes all the times.
I really don't understand why.
Also, when it is blocked trying to access the DDR, If I send a second reset pulse (without reloading the bitstream), it goes well. It also goes well once blocked even if I reload the bitstream and send (even immediately!) the reset pulse.
06-07-2014 07:36 AM
06-05-2014 08:03 AM
These sorts of issues are either incomplete, missing, or wrong timing constraints (check your timing reports, and understand all warnings, and look at all paths not constrained in the reports); or the change in temperature has caused a phase shift (frequency shift) in some components in the system (not just the FPGA) which will require the clock management (DCM in this part) to be reset. Then the status pins on the DCM. The LOCKED signal, the INPUT_CLOCK_STOPPED, etc. Typically, one monitors all the DCM status signals, and if anything is wrong, the DCM is then reset (as well as whatever else requires a reset).
The DCM itself has no problems going from room temperature to hot, but the on board oscillator, or other devices may have bejhavior that the DCM cannot track.
So, in summary, check your timing, and look at the DCM status.
06-05-2014 10:10 AM
06-05-2014 10:24 AM
I do not know....
But it is common to delay reset after DONE goes high (use a shift register to delay a reset signal...).
You may also look at the startup sequence in the bit file generation (bitgen options in ISE). You may move the release of the global signals to be done at a later point, and you may also choose to not start until the DCM is locked, once you know what the problem is (or you can move them around to help you find the problem).
Of course, depending on what is connected on the outside, you may need to wait some time before starting up.
Debugging the system to find out EXACTLY what is happening is highly encouraged. I never went to production with any mystery behaviors, as that almost certainly meant that the product would cause incredible problems with customers.
06-05-2014 10:44 AM
06-05-2014 10:47 AM
You may try the free evaluation
If you are a university student, you may have the license through your school's participation in the Xilinx University program.
06-05-2014 12:36 PM
06-05-2014 01:24 PM
There is no reset. There is the end of configuration, where everything starts running, with the specified initial conditions (which are zero, unless they are specified as a one).
So, all logic starts being clocked, with all DFF starting with zero, unless the verilog or VHDL specified their initial condition as one. Processor, state machine, video filter, it makes no difference. If a design has a reset line (like the MicroBlaze) you can tie it to a pushbutton, or tie it to not assert at all (as it will start properly without it).
Typically, if a reset is desired, one delays it until everything is stable (external oscillators are stable, inputs are all known values, all power supplies are good, whatever is needed).
Often, the configuration is held (delayed) just so a more complex reset is not needed (INIT held until the system is ready to let the configuration proceed).
Look at the configuration users guide for details on holding off configuring (adding delay).
06-05-2014 02:02 PM
06-05-2014 02:18 PM
I have to agree with Austin here: the Spartan-6 configuration guide explains how the FPGA starts up:
If you jump to page 84 you will see the startup sequence and the things you can optionally configure to delay the startup until the clocks are stable. Earlier in the guide it talks about delaying startup by holding the done input low.
If you decide you need a reset you could use EOS as an indication that DONE has gone high, the IO has been enabled and the synchronous logic is ready to change state.
On page 86 you will see the startup waveforms including a signal that is called POR or Power On Reset, but that is before the FPGA is even configured, so it is long gone before you could use it.
06-06-2014 09:34 AM
I verified with the oscilloscope that proc_sys_reset generates resets after loading bitsream, even if my ext_reset is tied to gnd.
I also discovered that when I have the problem, most of times ddr_calib_done remains 0.
I checked constraints etc..., all seems ok.
To summarize, if I issue an ext_reset just pulse immediatley after done pin high I see the problem, whilst If I do it after 100 mS everything is ok.
I'd like to understand why.
That precocius pulse can brutally interrupt what is going on (dcm, calibration....) but once it is released (with all dcm locked), everything should start from the beginning, included microblaze, MPMC and, indirectly, ddr reset and calibration.
I don't think it's a PCB or jitter issue because of the 100ms pause getting things very better.
06-06-2014 09:43 AM
06-07-2014 07:36 AM