Hi all,
Right now I'm developing a board using virtex-II FPGA, and want to 
implement a function
using the DCM to offer variable(dynamic) phase shifting. I use Xilinx 
ISE 8.2i, and ModelSim
SE for development. As I setup the IP cores for DCM, everything looks 
fine in the PRP simulation,
except that the PSDONE signal never goes high, which means everytime I 
trigger the PSEN signal
to high (for exactly one period, as said in the User Guide),  the DCM 
just doesn't take any action.
I just wonder what is other things that I still need to do. If anybody 
who can address my problem,
Thanks!~

>Hi all,
>Right now I'm developing a board using virtex-II FPGA, and want to 
>implement a function
>using the DCM to offer variable(dynamic) phase shifting. I use Xilinx 
>ISE 8.2i, and ModelSim
>SE for development. As I setup the IP cores for DCM, everything looks 
>fine in the PRP simulation,
>except that the PSDONE signal never goes high, which means everytime I 
>trigger the PSEN signal
>to high (for exactly one period, as said in the User Guide),  the DCM 
>just doesn't take any action.
>I just wonder what is other things that I still need to do. If anybody 
>who can address my problem,
>Thanks!~
>
>

I have the same problem using my spartan3.  Have you solve your problemyet?

thanks

"cutemonster"
<c...@hotmail.com> wrote in message 
news:QqqdnTYyipGfU-_b...@giganews.com...
> >Hi all,
>>Right now I'm developing a board using virtex-II FPGA, and want to
>>implement a function
>>using the DCM to offer variable(dynamic) phase shifting. I use Xilinx
>>ISE 8.2i, and ModelSim
>>SE for development. As I setup the IP cores for DCM, everything looks
>>fine in the PRP simulation,
>>except that the PSDONE signal never goes high, which means everytime I
>>trigger the PSEN signal
>>to high (for exactly one period, as said in the User Guide),  the DCM
>>just doesn't take any action.
>>I just wonder what is other things that I still need to do. If anybody
>>who can address my problem,
>>Thanks!~
>>
>>
>
> I have the same problem using my spartan3.  Have you solve your problem
> yet?
>
> thanks

Something I saw in my own design: the state machine I was using to control 
the DCM in my Spartan-3E issued a PSEN before the DCM was ready.  Since the 
state machine was waiting for a PSEN that would never come, my initial 
reaction was that I never received the PSDONE.

By adding an explicit timeout for the PSDONE to reissue a PSEN as a 
workaround in my initial code, I was able to issue a first PSEN as seen by 
the DCM.

Only with this timeout in place did I find that sometimes - making 10s of 
thousands of adjustments - the time from PSEN to PSDONE would exceed even 
the 5x timeout period I had designed for on very rare occasions.

If you design a state machine to deal with a timeout, I'd suggest disabling 
the timeout after the first PSDONE is detected.  If you're getting an error 
because you find yourself waiting too long, wait longer.  If you're in this 
latter camp, it might be helpful to record a histogram of how many clock 
cycles it takes between PSEN and PSDONE.  For your specific input jitter 
environment, you may get results that deviate from the published maximums.

- John_H 

>"cutemonster"
<c...@hotmail.com> wrote in message 
>news:QqqdnTYyipGfU-_b...@giganews.com...
>> >Hi all,
>>>Right now I'm developing a board using virtex-II FPGA, and want to
>>>implement a function
>>>using the DCM to offer variable(dynamic) phase shifting. I use Xilinx
>>>ISE 8.2i, and ModelSim
>>>SE for development. As I setup the IP cores for DCM, everything looks
>>>fine in the PRP simulation,
>>>except that the PSDONE signal never goes high, which means everytime I
>>>trigger the PSEN signal
>>>to high (for exactly one period, as said in the User Guide),  the DCM
>>>just doesn't take any action.
>>>I just wonder what is other things that I still need to do. If anybody
>>>who can address my problem,
>>>Thanks!~
>>>
>>>
>>
>> I have the same problem using my spartan3.  Have you solve yourproblem
>> yet?
>>
>> thanks
>
>Something I saw in my own design: the state machine I was using tocontrol 
>the DCM in my Spartan-3E issued a PSEN before the DCM was ready.  Sincethe 
>state machine was waiting for a PSEN that would never come, my initial 
>reaction was that I never received the PSDONE.
>
>By adding an explicit timeout for the PSDONE to reissue a PSEN as a 
>workaround in my initial code, I was able to issue a first PSEN as seenby 
>the DCM.
>
>Only with this timeout in place did I find that sometimes - making 10s of
>thousands of adjustments - the time from PSEN to PSDONE would exceed even
>the 5x timeout period I had designed for on very rare occasions.
>
>If you design a state machine to deal with a timeout, I'd suggestdisabling 
>the timeout after the first PSDONE is detected.  If you're getting anerror 
>because you find yourself waiting too long, wait longer.  If you're inthis 
>latter camp, it might be helpful to record a histogram of how many clock
>cycles it takes between PSEN and PSDONE.  For your specific input jitter
>environment, you may get results that deviate from the publishedmaximums.
>
>- John_H 
>
>
>

I checked lock pin and it's locked.  So, it should be ready for phasealignment.  I don't know why I still couldn't get it to work.  How do youdo with your reset sequence?  If possible, can I take a look at your codeto see what I missed?

thanks a lot,