UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Adventurer
Adventurer
12,262 Views
Registered: ‎02-08-2013

DCM Phase Overflow Status Bit Issues

I have 2 issues related to dynamically adjusting the DCM phase shift. Everything else about the DCM is working fine.

 

1. There seems to be some conflicting information regarding the overflow status bit. I have seen in a troubleshooting guide that if the overflow bit is set the DCM should be reset. I have also seen in the users guide that the overflow bit remains set until the phase adjust is reduced below the limit either by self temperature compensation adjustment or by manual adjustment (at least that's how I read it, pg72).

 

What I'm seeing in simulation is once the phase is incremented to where the overflow bit is set, decrementing the phase will not cause the bit to be cleared and the actual phase also does not decrement once that bit is set. It appears the overflow bit is locking out phase changes, which makes sense on one hand.

 

But on the board the overflow bit is set once the limit is reached and clears with one decrement and I can further reduce the actual phase back to 0 just fine.

 

2. I'm using the DCM in DIRECT mode for debugging reasons. On the board when I increment the phase I can only reach 128 before the overflow bit limits the incrementing code. Why can't I reach 1023? Doesn't direct mode remove any intelligence from the phase control circuitry and allow for a 0-1023 range regardless of temperature and other variables?  But then in simulation I can only reach 638 before the overflow bit is set, not sure what up with that.

  

I need some guidance on the proper use of the phase overflow bit.

 

Generics from inst:

      CLKDV_DIVIDE => 2.0, -- Divide by: 1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5,6.0,6.5
      -- 7.0,7.5,8.0,9.0,10.0,11.0,12.0,13.0,14.0,15.0 or 16.0
      CLKFX_DIVIDE => 1, -- Can be any integer from 1 to 32
      CLKFX_MULTIPLY => 2, -- Can be any integer from 2 to 32
      CLKIN_DIVIDE_BY_2 => FALSE, -- TRUE/FALSE to enable CLKIN divide by two feature
      --CLKIN_PERIOD => 2.857143, -- Specify period of input clock in ns from 1.25 to 1000.00
      CLKOUT_PHASE_SHIFT => "DIRECT", -- Specify phase shift mode of NONE, FIXED,
      -- VARIABLE_POSITIVE, VARIABLE_CENTER or DIRECT
      CLK_FEEDBACK => "1X", -- Specify clock feedback of NONE or 1X
      DCM_PERFORMANCE_MODE => "MAX_SPEED", -- Can be MAX_SPEED or MAX_RANGE
      DCM_AUTOCALIBRATION => TRUE, --
      DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS", -- SOURCE_SYNCHRONOUS, SYSTEM_SYNCHRONOUS or
      -- an integer from 0 to 15
      DFS_FREQUENCY_MODE => HIGH, -- HIGH or LOW frequency mode for frequency synthesis
      DLL_FREQUENCY_MODE => HIGH, -- LOW, HIGH, or HIGH_SER frequency mode for DLL
      DUTY_CYCLE_CORRECTION => TRUE, -- Duty cycle correction, TRUE or FALSE
      FACTORY_JF => X"F0F0", -- FACTORY JF Values Suggested to be set to X"F0F0"
      PHASE_SHIFT => 0, -- Amount of fixed phase shift from -255 to 1023
      SIM_DEVICE => "VIRTEX5", -- Set target device, "VIRTEX4" or "VIRTEX5"
      STARTUP_WAIT => FALSE

 

 

Snipit of phase control code:

 

            when s_not_locked =>
               -- Wait for DCM lock
               if (dcm_locked = '1') then
                  state <= s_check_phase;
               else
                  state <= s_not_locked;
               end if;
           
            when s_check_phase =>
               -- DCM is locked now see if it needs phase adjusting
               if (dcm_phase(9 downto 0) = cpu_phase(9 downto 0))  then
                  -- No phase adjust is needed
                  state <= s_check_phase; --  Stay here
               else
                  state <= s_adjust_phase;-- Phase adjust is needed
               end if;
           
            when s_adjust_phase =>
               if (dcm_phase(9 downto 0) > cpu_phase(9 downto 0)) then -- Decrement DCM phase
                  o_psincdec <= '0';
                  o_psen     <= '1';
                  dcm_phase <= dcm_phase - 1;
               elsif phase_ovrflw = '0' then-- Increment DCM phase if not at limit
                  o_psincdec <= '1';
                  o_psen     <= '1';
                  dcm_phase <= dcm_phase + 1;
               end if;
               state <= s_check_for_adjust_done;--
           
            when s_check_for_adjust_done =>
               -- Wait for previous phase adjustment to be completed or if CPU has

               -- changed the phase setting (prevents lockup if done pulse if missed)
               if (psdone = '1' or cpu_phase_setting_change = '1') then
                  state <= s_check_phase; -- Adjust again if necessary
               else
                  state <= s_check_for_adjust_done; --  Stay here
               end if;

 

Thanks.

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
0 Kudos
5 Replies
Scholar austin
Scholar
12,252 Views
Registered: ‎02-27-2008

Re: DCM Phase Overflow Status Bit Issues

What we say, vs. what it does....

 

I would assume that it works as described.  Why?  Because all DCM's on all device families are not identical.  By assumming that only what is specified works, we do not hsave to document every separate DCM foer each family.

 

For this design, with this part, it will work as that silicon is working, for now, and all future parts.  Unless there isa change notice.  In which case, it changes.

 

Changes to production products are not something we do, unless it is absolutely required (and then we notify users).   Given this is an older product, no changes are in the queue, none are planned, and none are ever likely.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Adventurer
Adventurer
12,249 Views
Registered: ‎02-08-2013

Re: DCM Phase Overflow Status Bit Issues

For got to mention this is a Virtex 5 part.
Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
0 Kudos
Adventurer
Adventurer
12,247 Views
Registered: ‎02-08-2013

Re: DCM Phase Overflow Status Bit Issues

I'm having trouble extracting any sense out of your reply. Are you saying Xilinx washes there hands of DCM issues and I'm to use trial and error to determine operation?

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA
0 Kudos
Scholar austin
Scholar
12,243 Views
Registered: ‎02-27-2008

Re: DCM Phase Overflow Status Bit Issues

Ray,

 

I am saying that the documentation is the ruling element.

 

If the product behavior provides functionality beyond what is stated, that is something that Xilinx cannot (will not) guarantee.

 

So, the document states that the overflow, or underflow is set when it occurs.


As to what happens after, that is specified as a 'sticky bit' (stays set).  Evidently, in your testing, it can be reset by appropriately incrementing, or decrementing.  Congratulations.  You now have something you can trust to do exactly as it is, under exactly the same conditions.  If you are going to depend on that behavior, Xilinx doesn't warranty it -- we only guarantee what it said in the documentation.

 

So if it doesn't clear the flag, when you expect it to, do not complain to us.

 

For example, if the flag is set, and you do not know if you should increment or decrement (because the flag is both overflow and underflow), how can you guaranatee the flag will clear?  You do not know which action to take.  So you try to increment, and it does not clear.  Bingo!  It has just failed to do what you expected.  It also performed exactly as specified.  No more, no less.

 

 

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Adventurer
Adventurer
12,208 Views
Registered: ‎02-08-2013

Re: DCM Phase Overflow Status Bit Issues

Austin, Thanks for your input. I have decided to open a case since after working on this for 2 weeks it really appears to not be working as documented.

Regards, Ray Haynes, Ostendo Technologies, Inc. Carlsbad, CA