Topic: PLL not locked, but clock outputs seem OK  (Read 13327 times)

bruceyu January 16, 2014, 07:33 AM

  • Member
  • *
  • Posts: 10
Hi,

 PLL is not locked on my FMC150 board, neither the PLL status bit in the register nor the pin.

 I am using the firmware extracted from the BSP package. The PLL is not locked. But the CLK-to-FPGA clock is measuring 245MHz. It looks like the DAC clock is around 491MHz by scoping on R70/R71 resistor’s pad. And ADC clock is around 166MHz by checking CLK_AB on FPGA. I think they are the expected numbers.

  I have got the following readings from internal registers of CDCE device:
 
  •                            0x683C025 0 (Hex)                 
  • [1]                           0x6800027 1 (Hex)                 
     [2]                           0x8382000 2 (Hex)                 
     [3]                           0x6800000 3 (Hex)                 
     [4]                           0xE980000 4 (Hex)                 
     [5]                           0x6800000 5 (Hex)                 
     [6]                           0x6800000 6 (Hex)                 
     [7]                           0x8340000 7 (Hex)                 
     [8]                           0x6800009 8 (Hex)                 
     [9]                           0x680500C 9 (Hex)                 
     [10]                         0x08FC270 A (Hex)                 
     [11]                         0x8000040 B (Hex)
     [12]                         0x60009B0 C (Hex)
     Status4 INDET_AUX It indicates that a clock is present at AUX-input (Y9) , when set to 1 RAM(Read Only)
     Status5 INDET_VCXO It indicates that a clock is present at VCXO-input , when set to 1 RAM(Read Only)
     Status6 PLL_LOCK It indicates that the PLL is locked when set to 1 RAM(Read Only)
     
     Then I calculated the dividers using the equation…
     
     Fvcxo/Fref = P*N/(R*M)
     
     Here with Fvcxo =  491.52MHz, Fref = 100MHz, P = 8, N = (575+1), R = 1, M = (624 + 1), both sides are not equal. N should be (3839+1) to make them equal. So I changed the initial coefficients for the firmware to configure the FMC150 board on reset. And then the register value at 0xA is  0x3BFC270A. But the PLL is still not locked.
     
     Can anyone explain this?
     
     Thanks
  • « Last Edit: January 16, 2014, 10:47 AM by bruceyu »

arnaudNL January 16, 2014, 09:52 AM (#1)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Dear Sir,


The firmware will not be operational before you actually run the software application, as per 4FM Getting Started Guide; The software configures the chip set in a way it can be used.


Best Regards,
Arnaud

bruceyu January 16, 2014, 09:59 AM (#2)

  • Member
  • *
  • Posts: 10
Thank you for your reply. But it seems the firmware does send it out an initialisation sequence at power-up reset...
Can you also point out where I can get the "Getting Started Guide"?

arnaudNL January 16, 2014, 10:13 AM (#3)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Dear Sir,


Yes correct, there is a portion of "ROM Init" preparing the chips so they can be controlled, communication buses and a few things like that. The clock configuration is done by the software but it does not configure the chips in a ready state; There are hundreds of settings to do before you get samples in and out and some of them require fine tuning application specifics. This is where the software comes handy, changing an ADC setting does not cost 45 minutes of firmware recompilation time.


The getting started guide was shipped along with the .exe and can also be found there : C:\Program Files (x86)\4dsp\4FM Core Development Kit\Documentation\4FM_Get_Started_Guide_WinXP.pdf


The software source code can also be found there C:\Program Files (x86)\4dsp\FMC Board Support Package\Refs\Software or C:\Program Files (x86)\4dsp\4FM Core Development Kit\Plug-Ins, depending if you installed a PCI or Ethernet reference design. This will become handy, bringing up the whole chip set without a reference is ambitious, as you have seen!


Best Regards,
Arnaud

bruceyu January 16, 2014, 11:00 AM (#4)

  • Member
  • *
  • Posts: 10
Hi Arnaud,

Thank you for your reply. But probably we are not talking about the same thing.

The firmware I used is from "C:\Program Files (x86)\4dsp\Common\Firmware\Extracted\098_sp605_fmc150\star_lib\sip_fmc150\vhdl". I have taken this frimware with "fmc150_if.vhd" as the top-level, and integrated it into my FPGA project. My project communicates with "fmc150_if.vhd" using the Command Interface.

This firmware has an initialisation process which configures four those components on the board in turn via the SPI interface. This initialisation sequence does configure the clock management - CDCE72010, as one of those four. This is confirmed by the register readings which are the initial coefficients in "C:\Program Files (x86)\4dsp\Common\Firmware\Extracted\098_sp605_fmc150\star_lib\sip_fmc150\vhdl\v6\xilinx\cdce72010_init.coe". Am I wrong?

So with all settings configured, (confirmed by the register readings), the PLL should be locked. Isn't that right?

The text format in my first post should be fine now...the font was too way small.

Thanks,

Bruce

bruceyu January 16, 2014, 11:03 AM (#5)

  • Member
  • *
  • Posts: 10
BTW: I dont have the directory "4FM Core Development Kit" under "C:\Program Files (x86)\4dsp\"...?

arnaudNL January 16, 2014, 12:23 PM (#6)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Dear Bruce,


We are talking about the same thing, surely; I am saying the software has to run in order the firmware is operational. There is a ROM init indeed, this is what you confirmed but it does not bring the chip set up completely.


The software application has to run in order to get the chip set up. Internal/External clock, configuration of the CDCE chip to provide the right clocking for both DAC/ADC, etc.. There are also some sequence involved. All these register read/write are done from the software through the firmware. The software also places a waveform in the DAC's local memory, start the play back and acquire sample. Having a loopback cable between ADC/DAC allows you to acquire what is played by the DAC, well in other words, a complete reference.


For your last point, this is quite interesting. So you only have Common, FMC Board Support Package and FMC Analyzer? Do you have any shortcut to an application in the start menu or maybe you have not installed the kit at the default path? When did you download your BSP? Do you see FMC15x application under FMC Board Support Package\Refs\Software?


Best Regards,
Arnaud



bruceyu January 16, 2014, 12:45 PM (#7)

  • Member
  • *
  • Posts: 10
Hi Arnaud,

We are getting there... I forgot to say that I am not using any of those popular boards. The mother board to the FMC150 is built by us and there is no either PCI or Eth interface on it. But via the Command Interface on "fmc150_if.vhd", my system/software could access all the registers.

So after the ROM init is configured by firmware after power-on reset, what extra configurations or setup sequence should be done,  to bring the chip set up completely?

By the way, using my software, I have managed to place a sine waveform in the DAC's memory, and when playing back, a sine waveform was also seen on a scope at the DAC output. So this bit is not a problem.

Thanks,

Bruce

bruceyu January 23, 2014, 08:29 AM (#8)

  • Member
  • *
  • Posts: 10
Anyone can help with the PLL issue - not locked?

thanks,


arnaudNL January 23, 2014, 11:40 AM (#9)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Hello Bruce,


I tried to run the reference design and I do get PLL lock, maybe try that to see if your hw is functional or not.


Otherwise there must be a settings mismatch between our reference design and your design. PLL not locked indicate issue in the clock configuration generally.


Best Regards,
Arnaud

bruceyu January 23, 2014, 11:51 AM (#10)

  • Member
  • *
  • Posts: 10
Hi

Thank you very much for the run,

The COE file I used "cdce72010_init.coe" has the following contents:

;******************************************************************
;** CECE72010 Initialization                                     **
;******************************************************************
;
; This .COE file specifies initialization values for a block
; memory of depth=16, and width=32.
; Values are specified in hexadecimal format:
; 28 MSB = data, 4 LSB = address.
;
; Loading from ROM stops when address 0xC has been processed.
; therefore this register must be the last entry in this file.
;
memory_initialization_radix=16;
memory_initialization_vector=
683C0250,
68000271,
83820002,
68000003,
E9800004,
68000005,
68000006,
83400007,
68000098,
680500C9,
08FC270A,
0000040B,
0000180C;

Using this configuration, PLL was not locked.

Based on my calculation shown in my first post, I changed the initial coefficient at 0xA is 0x3BFC270A. The PLL is still not locked.

I could read back all the configurations as you can see in my first post.
So what could possibly have gone wrong?

Thanks,

Bruce

arnaudNL January 23, 2014, 12:23 PM (#11)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Hello,


Then the configuration is not correct. Have you dumped the CDCE registers after the software ran. I believe I already indicated that the default firmware load is not sufficient?


Attached is the source file in charge of configuring this chip, this is how we bring the chip up and get a lock on our design, so please try to extract your values from there.


Have you actually ran our reference design? If not please do that, and check for your lock at the reference frequency, then try to only play around CDCE settings for the other frequency (in the software), once this is good you have your values.


Don't hesitate to report back if you have any troubles running the reference design or getting a lock on the reference design.


Best Regards,
Arnaud

bruceyu January 23, 2014, 02:27 PM (#12)

  • Member
  • *
  • Posts: 10
Hi Arnaud,

yes. the dumped CDCE registers were given in my first post.

I can't see the source file you mentioned. Could you please send it by email?

I am not sure what you meant with "run our reference design"...If you were referring to the software supplied by 4DSP, then I haven't and I can't. It is because your software has no way to communicate with the mother Board we designed (there is no pci or eth interface on it).

Thanks,

Bruce


arnaudNL January 24, 2014, 05:23 AM (#13)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Bruce,


Our customers always first get familiar with the reference on boards from Xilinx and then move forward on their own boards, it makes sense. Typically FMC150 reference design is available for so many chip FPGA boards, saying that you simply cannot use the reference because it is not compatible with your hardware is not very constructive. If you are really sure about that you need to expect you will not get much support around that. Integrating our products on your own hardware is not covered by technical support, you can decide to purchase an engineering support contract from us, contact sales@4dsp.com to discuss that further.


I think I repeated that 5 times already: The reference design is a software AND a firmware, both need to be used in conjunction and you actually keep not listening about that. You are still sure that by loading the firmware you should get a lock. I finish to believe you don't need support; you know everything already..


Avnet has another reference design, they provide it to their customers and supporting it. It is a very simple one source file design which seems more suited to your needs ( no ethernet link required ).. As you have purchased the board from Avnet, 4DSP does not need to provide you with any technical support; Avnet is supporting their own customers. Have you at least looked at the material provided with your Avnet kit?


Best Regards,
Arnaud

bruceyu January 24, 2014, 08:09 AM (#14)

  • Member
  • *
  • Posts: 10
Hi Arnaud,

I got a lock... :D . I compared my configurations with the settings in the cpp file you sent, and found out that my calculations was wrong. N should be (383+1). The value at 0xA should be 0x05FC270A. And after setting the lock-detect window to 15ns, I had the PLL locked.

I appreciate for the help.

Thanks,

Bruce