cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Explorer
Explorer
4,852 Views
Registered: ‎10-19-2012

Spartan 6 PLL doesn't lock on Post-Synthesis Simulation

Jump to solution

Hi, I have a design that runs perfectly on Behavioral Simulation, but it is showing very weird behavior in hardware. So, I'm trying to do a Post-Translate simulation.

 

Everything from the Behavioral simulation is the same (testbench and all) as in the Post-Translate simulation. But, in the Post Transalte Simulation the PLL never locks, so my design never starts running. I'm instantiating a PLL_BASE primitive with internal feedback (and I know for a fact that it locks in hardware because I see some output out of my design).

 

I'm running the simulation with Modelsim SE 10.1, also tried ISIM and the results were the same. By viewing the signals from the PLL the only thing I noticed is that CLKIN2 remains at an UNKNOWN value while CLKIN1 receives correctly the input clock. The PLL_BASE instance doesn't let me assign CLKIN2 (only input is CLKIN).

 

Any Ideas ?

0 Kudos
Reply
1 Solution

Accepted Solutions
Explorer
Explorer
6,260 Views
Registered: ‎10-19-2012

OK. For anyone having this problem this is how I solved it.

 

I instantiated PLL_ADV instead of PLL_BASE and connected the signals pertinent to the design (for information on how to instantiate PLL_ADV see (Virtex-5 Libraries Guide for HDL Designs). Everything else I left OPEN if it was OUTPUT or driven to GND if it was INPUT. Voila, the PLL locked.

View solution in original post

0 Kudos
Reply
4 Replies
Scholar
Scholar
4,845 Views
Registered: ‎02-27-2008

Locking PLL,

 

DLL, and DCM in simulation may be fussy (not work) because simulating the feedback may be a problem.

 

I suspect that it will work in practice, but I would check the feedback in the simulation.

 

Anything remaining at an unknown value is very very bad, so you should discover the source of the unknown.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Reply
Explorer
Explorer
4,841 Views
Registered: ‎10-19-2012

I see. I'm working with VHDL sources, it seems that the only way to accomplish what you say would be to instantiate PLL_ADV and connect everything, correct ? Because XST  or Translate seems to be turning my PLL_BASE into PLL_ADV with CLKIN2 left to an unkown value.

 

Also, this is a little unrelated, but I have seen warning in BitGen that my DCMs (elsewhere in my project) have the PSEN pin connected to some node that is not GROUND (but I have it connected to '0' in the VHDL source) even though I'm not using 'VARIABLE' Phase shift generic (yes, my intention is NOT to use variable phase shift).

 

I'm using ISE 14.1

0 Kudos
Reply
Scholar
Scholar
4,831 Views
Registered: ‎02-27-2008

i,

 

GND may be connected to in any number of ways.  I would not worry about that (I trust the tools to tie it to logic zero, however derived).

 

I am more concerned about a clock not being connected to anything.  But that is not the pin of a clock to the PLL.

 

There is only one hardware element, and that is the full and complete PLL/DCM.  So, what you ask for (base) is always implemented as the complete element (advanced).

 

CLKIN1 and 2 are internal nodes, so I am not sure why this is an issue....Only one of them is selected, and I would hope it is the right one.

 

So, it doesn't matter if it is unknown, as it should also be unused.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Reply
Explorer
Explorer
6,261 Views
Registered: ‎10-19-2012

OK. For anyone having this problem this is how I solved it.

 

I instantiated PLL_ADV instead of PLL_BASE and connected the signals pertinent to the design (for information on how to instantiate PLL_ADV see (Virtex-5 Libraries Guide for HDL Designs). Everything else I left OPEN if it was OUTPUT or driven to GND if it was INPUT. Voila, the PLL locked.

View solution in original post

0 Kudos
Reply