01-08-2014 11:44 AM
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;
state <= s_not_locked;
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
state <= s_adjust_phase;-- Phase adjust is needed
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;
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
state <= s_check_for_adjust_done; -- Stay here
01-08-2014 02:07 PM
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.
01-08-2014 02:14 PM
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?
01-08-2014 02:34 PM
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.
01-15-2014 03:20 PM