This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LMK03328: Register values for the INPUT and OUTPUT specifications

Part Number: LMK03328
Other Parts Discussed in Thread: CODELOADER

Hi,

We are using 2 nos of LMK03328RHST in our design. We already have the assembled PCB. We are using Code Loader Ver 4.20.2 and trying to get proper register values using the Software tool.It is taking more time to understand each options and get appropriate register values, However the team is stydying it in detail. But for initial testing of FPGA we quickly need to generate Clock and start with the testing in parallel.
Hence we need your support in getting proper register values, so that we will use it in the design and start with Testing. Simultaniously we will compare the register values against the one generated by us using the tool and try to understand them.This will avoid your dependancy in future if we need to change anything.

I have attached the schematics of LMK03328RHST section.Few of the notes on schematics are metiiond below for better understanding

1. Input :
Crystal Input 25MHz to Secondary Input pin (PCB footprints are given for an LVDS oscillator to Primary Input, but not mounted). No AC caps given for both the inputs on board.

2. Output :
200 MHz LVDS on all the 8 Outputs (AC coupling is given on board). These clocks serve clock in pins of High speed Transceiver sections of Xilinx FPGA to run 10Gig Interfaces.

3. Few GPIOs are connexted to FPGA 1.8V IO pins (GPIO0,2,3,5) and rest are PU/PD using resistorss.

4. PDN pin is connected to 1.8V IO pin of FPGA

Please ignore other oscillators visible in the attached schematics tthey are not related to LMK03328 design. Ans also please keep the schematics confidential.

Regards,
VijethaLMK03328.pdf

  • Hello Vijetha,
    Thanks for reaching out to us. We will review your schematics and provide you feedback by Tuesday due to Easter Holidays. I would suggest you to load the default state in the TICSpro as a starting point and then change the configuration as needed for your application.
    By the way, this is a public forum. For sharing confidential information with TI, please use clock_support@list.ti.com.
    Thanks for having patience.
    Best regards
    Puneet
  • I attached the codeloader file as well as the exported register data.

    The schematic looks okay.

    Make sure GPIO0 is driven high to enable the outputs; otherwise, driving GPIO0 low will hold the output dividers in SYNC state with the output clocks muted.

    To program, you can write all registers and toggle the RESETN_SW bit (1 -> 0) to reset the device with the your settings.

    Alan

    LMK03328_iWave_25M-ref_200M-lvds.mac

    LMK03328_iWave_25M-ref_200M-lvds-hex-reg-export.txt
    R0	0x0010
    R1	0x010B
    R2	0x023B
    R3	0x0300
    R4	0x0482
    R5	0x050E
    R6	0x0646
    R7	0x078A
    R8	0x0802
    R9	0x0900
    R10	0x0AA8
    R11	0x0B00
    R12	0x0CDF
    R13	0x0D00
    R14	0x0E00
    R15	0x0F00
    R16	0x1000
    R17	0x1100
    R18	0x1200
    R19	0x1300
    R20	0x14FF
    R21	0x15FF
    R22	0x16FF
    R23	0x1703
    R24	0x1800
    R25	0x19F5
    R26	0x1A00
    R27	0x1B20
    R28	0x1C00
    R29	0x1D03
    R30	0x1E40
    R31	0x1F20
    R32	0x2020
    R33	0x210B
    R34	0x2220
    R35	0x2320
    R36	0x240B
    R37	0x2510
    R38	0x260B
    R39	0x2710
    R40	0x280B
    R41	0x2910
    R42	0x2A0B
    R43	0x2B10
    R44	0x2C0B
    R45	0x2D0A
    R46	0x2E00
    R47	0x2F00
    R48	0x3000
    R49	0x3100
    R50	0x3295
    R51	0x3303
    R52	0x3400
    R53	0x3500
    R54	0x3600
    R55	0x3700
    R56	0x3802
    R57	0x3918
    R58	0x3A00
    R59	0x3B60
    R60	0x3C00
    R61	0x3D00
    R62	0x3E00
    R63	0x3F3D
    R64	0x4009
    R65	0x4100
    R66	0x420C
    R67	0x4308
    R68	0x4401
    R69	0x4504
    R70	0x4607
    R71	0x4713
    R72	0x4818
    R73	0x4900
    R74	0x4A64
    R75	0x4B00
    R76	0x4C00
    R77	0x4D00
    R78	0x4E3D
    R79	0x4F09
    R80	0x5000
    R81	0x510C
    R82	0x5208
    R83	0x5301
    R84	0x5404
    R85	0x5507
    R86	0x5600
    R87	0x5700
    R88	0x5800
    R89	0x59E3
    R90	0x5A01
    R91	0x5B32
    R92	0x5C01
    R93	0x5D59
    R94	0x5E01
    R95	0x5FAC
    R96	0x6001
    R97	0x61EE
    R98	0x6202
    R99	0x632E
    R100	0x6402
    R101	0x65A4
    R102	0x6603
    R103	0x670A
    R104	0x6800
    R105	0x6900
    R106	0x6A05
    R107	0x6B00
    R108	0x6C08
    R109	0x6D0F
    R110	0x6E1F
    R111	0x6F00
    R112	0x7000
    R113	0x7100
    R114	0x7200
    R115	0x730D
    R116	0x7419
    R117	0x7500
    R118	0x7607
    R119	0x770A
    R120	0x7800
    R121	0x7900
    R122	0x7A08
    R123	0x7B0F
    R124	0x7C1F
    R125	0x7D00
    R126	0x7E00
    R127	0x7F00
    R128	0x8000
    R129	0x810D
    R130	0x8219
    R131	0x8300
    R132	0x8407
    R133	0x8505
    R134	0x8600
    R135	0x871F
    R136	0x8824
    R137	0x8910
    R138	0x8A1F
    R139	0x8B00
    R140	0x8C00
    R141	0x8D0E
    R142	0x8EFF
    R143	0x8F00
    R144	0x9000
    R145	0x9100
    R169	0xA940
    R172	0xAC24
    R173	0xAD00
    

  • Hi Alan,

    This is a multiple board chasis design. We are using over 12 LMK03328 Modules used for various different Frequency Synthesis.
    Some of the outputs are fixed but some of them do change as the design matures.
    I feel we cannot ask you the codeloader file repeatedly as our requirement changes. Hence we need to freeze a meathod to get the correct codeloader file without much of effort.
    I tried to understand the Codeloader software and it doesn't seems to be pretty straight forward, hence is there a easy way to do the settings and generate the codeloader output.

    Also we are programming the Clock Generator EEPROM through I2C.

    I have summarised the procedure with the below pseudocode to program the Clock Generator Modules, please review the same

    1. PDN 0-->1
    2. Block Register Read/Write as per the Codeloader values.
    3. SRAM Write
    R145[3:0] = 0x0; // Set to page 0
    R137[6] = 1'b1; // Register to SRAM transfer
    4. EEPROM Write
    R144[7:0] = 0xEA; // Protection
    R137[0] = 1'b1; // SRAM to EEPROM transfer
    Read R136; // Make sure EEPROM programming cycles has incremented
    R 144 = 0x00;
    Read R137[5] // if set to 0 indicates EEPROM programming successsful
    5. RESETN_SW = 1'b0;

    Query :

    1. Some of the Registers has 'RESERVED' bits, Is this taken care in the Codeloader file or should we mask each of the registers while writing to it - in which case can you share the Mask values for the registers if available.
    eg: Reg 12 has Bit5 set RESERVED, but code loader sets the value 0 to this register bit(0xDF). Should the software ignore and write 0xDF directly to that register or read the old value then mask that bit and rewrite to it.
    I have received a list of registers which are either Read only and RESERVED through another link, which will be ignored directly. No write to them - Is this Correct.

    2. Should RESETN_SW (1->0)is done after EEPROM Write or after SRAM Write, anyway it does not reset the configuration controller. Also after setting this bit to 0, should it be reverted back to 1 (0->1) to make it to out-of-reset, if so what should be the minimum pulse width of the same.

    Regards,

    Vijetha

  • Attached List of registers which are either Read only and RESERVED.

  • PS :

    1. GPIO0 is connected to FPGA (1.8V bank) and also Pulled down to GND using 4.99K OHM.
    Now if I have to make it high can I connect it to 1.8V? If it must be connected to VDD_DIG(3.3V) then i have to isolate it from FPGA. Which is correct :
    Option 1 : Connect GPIO0 to FPGA (1.8V IO pin) + Give pull up to 1.8V (VCCO voltage)
    Option 2 : Isolate GPIO0 from FPGA and pull up GPIO0 to VDD_DIG (3.3V)

    If we see table 8.2 in page 14 of Datasheet, the electrical characteristics says VIH min is 1.2 V, hence connecting GPIO0 to 1.8V will still cosidered as Logic High.

    2. We have used 7M25072001 Crystal on secondary inputs as recommended by datasheet of LMK03328. Hoping it is a precise crystal with +/-30ppm stability.
    By going through the Crystal Input interface we deduce the following

    "If reducing frequency error of the crystal is of utmost importance, a crystal with low pullability should be used. If
    frequency margining or frequency spiking is desired, a crystal with high pullability should be used"


    We are not interested in any frequency margining options, What should be the GPIO 4 & 5 connected to?, does the register values you have attached in the earlier post
    will match the same options.

  • Vijetha,
    Please give me a couple days to review this.
    Thanks,
    Alan
  • Hi Alan,

    Any updates on above list of queries?

    Regards,

    Vijetha

  • 1. The programming sequence looks OK.

    Registers at R135 and above are read-only, reserved, or memory control registers, so they can be excluded when you execute Step 2 (Block Register Write per CodeLoader values).  Registers R0 to R11 are read-only and can be skipped or masked.

    For Step 2, you can write the register data exported from Codeloader from R12 to R134 (inclusive), and apply the following write mask:

    • Reserved bits in Writable registers should not be modified (apply read-modify-write method)
    • Apply write mask (0xFF = do not modify) to read-only registers (R13, R16, R18)
    • Apply write mask (0xFF = do not modify) to reserved registers (R26,R48, R87, R106 to R116, R121 to R131)

    2. RESETN_SW bit can be cleared (1->0) at the end (Step 5) as you have it.  You can set RESETN_SW (0->1) in a subsequent register write.  I2C interface is slow enough that you do not need to worry about minimum time for RESETN_SW.

    Regards,
    Alan

  • 1. Yes, VIH min is 1.2 V so GPIO's are 1.8-V compatible. Either Option #1 or #2 is fine.
    2. Tie GPIO4 to high through 10k, and Tie GPIO5 to GND through 10k. Use short trace lengths from XTAL pins to SECREF pins to minimize stray cap.

    Alan
  • Hi,

    The Hardware changes in GPIO are made as below :

    GPIO0 : 10K PULL DOWN to GND

    GPIO1 : 10K PULL DOWN to GND

    GPIO2 and GPIO3 : PULL UP to 1.8V through 10K

    GPIO4 : PULL UP to 1.8V through 10K

    GPIO5 : 10K PULL DOWN to GND

    And we will check further and get back with the result and observations.

    Regards,

    Vijetha

  • Hi Alan,

    We are able to configure the Register Block of the Clock Generator and synthesize the new output clocks.
    But writing to EEPROM is not successful.
    The Clock Generator outputs are synthesized as Default EEPROM Contents as in Table 13. after Restart.

    Please check the comments in line.

    1. PDN 0-->1

    2. Block Register Read/Write as per the Codeloader values.
    -- We are able to write to these register set and the output clock gets synthesized as per the new values.

    3. SRAM Write
    R145[3:0] = 0x0; // Set to page 0
    R137[6] = 1'b1; // Register to SRAM transfer

    4. EEPROM Write
    R144[7:0] = 0xEA; // EEPROM Protection
    R137[0] = 1'b1; // SRAM to EEPROM transfer
    Read R136; // Make sure EEPROM programming cycles has incremented
    R 144 = 0x00; // EEPROM Protection
    Read R137[5] // if set to 0 indicates EEPROM programming successful

    -- R136 has the value 0x01 indicating EEPROM was configured once. But it remains unchanged even when EEPROM is written multiple times. Someone in forum had pointed out that it gets incremented after reset. But the register remains unchanged even after Power Cycle.
    -- Read R137[5] is set 1 indicating the EEPROM write is not successful.

    5. RESETN_SW = 1'b0;

    Query:

    1. Do all LMK03328 parts support EEPROM programming.
    2. Is there any Timing to be maintained in the above sequence. I have maintained 1ms delay between any 2 register writes and about 1 Sec after EEPROM write (data sheet mentions 230 ms).
    3. How to proceed further to write to EEPROM.

    Regards,

    Vijetha

  • Hi Alan,

    We are able to configure the Register Block of the Clock Generator and synthesize the new output clocks.
    But writing to EEPROM is not successful.
    The Clock Generator outputs are synthesized as Default EEPROM Contents as in Table 13. after Restart.
    Please check the comments in line.

    1. PDN 0-->1

    2. Block Register Read/Write as per the Codeloader values.
    -- We are able to write to these register set and the output clock gets synthesized as per the new values.

    3. SRAM Write
    R145[3:0] = 0x0; // Set to page 0
    R137[6] = 1'b1; // Register to SRAM transfer

    4. EEPROM Write
    R144[7:0] = 0xEA; // EEPROM Protection
    R137[0] = 1'b1; // SRAM to EEPROM transfer
    Read R136; // Make sure EEPROM programming cycles has incremented
    R 144 = 0x00; // EEPROM Protection
    Read R137[5] // if set to 0 indicates EEPROM programming successful

    -- R136 has the value 0x01 indicating EEPROM was configured once. But it remains unchanged even when EEPROM is written multiple times. Someone in forum had pointed out that it gets incremented after reset. But the register remains unchanged even after Power Cycle.
    -- Read R137[5] is set 1 indicating the EEPROM write is not successful.

    5. RESETN_SW = 1'b0;

    Query:

    1. Do all LMK03328 parts support EEPROM programming.
    2. Is there any Timing to be maintained in the above sequence. I have maintained 1ms delay between any 2 register writes and about 1 Sec after EEPROM write (data sheet mentions 230 ms).
    3. How to proceed further to write to EEPROM.
  • Yes, all LMK03328 parts support EEPROM programming.

    Here are some suggested modifications (in red) for your programming sequence:

    1. PDN 0-->1

    2. Block Register Read/Write as per the Codeloader values.
    -- We are able to write to these register set and the output clock gets synthesized as per the new values.
    -- Make sure R12[2] = 1'b1 (Always enable internal digital system clock)


    3. SRAM Write 
    R145[3:0] = 0x0; // Set to page 0
    R137[7:0] = 0x50; // Register to SRAM transfer, automatic CRC
    Read R137; // Make sure R137 reads 0x10 (bit 6 is self-cleared) to confirm SRAM transfer is complete before proceeding


    4. EEPROM Write
    R144[7:0] = 0xEA; // EEPROM Protection
    R137[7:0] = 0x11; // SRAM to EEPROM transfer, automatic CRC
    Wait at least 300 ms.
    Read R137; // Make sure R137 reads 0x10 (bit 1 is self-cleared, bit 5 is cleared) to confirm EEPROM program is completed successfully.
    R144 = 0x00; // EEPROM Protection

    5. NVM Commit -- Execute this step only after successful EEPROM programming (i.e. R137 reads 0x10 in Step 4)
    R137[7:0] = 0x18; // Transfers NVM contents to registers (intention of this is to refresh the NVMCNT value in R136)
    Read R136; // Make sure EEPROM program count has incremented (this register is only updated by NVM commit, power-cycling, or toggling PDN pin, but NOT by soft-reset).

    6. RESETN_SW = 1'b0; (Soft-reset is not required if PLLs are already locked, but can be done to re-initiate a VCO calibration if PLLs are not locked).

    Hopefully this works for you.

    Regards,
    Alan

  • Hi Alan,

    Myself Chethan working on FPGA programming sequence with Vijetha.
    Please find the below observations inline

    1. PDN 0-->1

    2. Block Register Read/Write as per the Codeloader values.
    -- We are able to write to these register set and the output clock gets synthesized as per the new values.
    -- Make sure R12[2] = 1'b1 (Always enable internal digital system clock)

    AS EXPECTED - WE ARE WRITING CORRECTLY

    3. SRAM Write 
    R145[3:0] = 0x0; // Set to page 0
    R137[7:0] = 0x50; // Register to SRAM transfer, automatic CRC
    Read R137; // Make sure R137 reads 0x10 (bit 6 is self-cleared) to confirm SRAM transfer is complete before proceeding

    AS EXPECTED R 137 READS 0X10 -- SRAM TRANSFER IS SUCCESSFUL

    4. EEPROM Write
    R144[7:0] = 0xEA; // EEPROM Protection
    R137[7:0] = 0x11; // SRAM to EEPROM transfer, automatic CRC
    Wait at least 300 ms.
    Read R137; // Make sure R137 reads 0x10 (bit 1 is self-cleared, bit 5 is cleared) to confirm EEPROM program is completed successfully.

    ERROR: R137 READS 0X11 - REGISTER IS READ AFTER 60 SECONDS IN DEBUG MODE. STILL THE ZEROTH BIT IS SET. THAT SAYS EEPROM PROGRAMMING IS A FAILURE.
    NOTE: I CONSIDER IN YOUR ABOVE COMMENT YOU MEANT BIT 0 & 4 INSTEAD OF BIT 1 & 5.

    R144 = 0x00; // EEPROM Protection

    5. NVM Commit -- Execute this step only after successful EEPROM programming (i.e. R137 reads 0x10 in Step 4)
    R137[7:0] = 0x18; // Transfers NVM contents to registers (intention of this is to refresh the NVMCNT value in R136)
    Read R136; // Make sure EEPROM program count has incremented (this register is only updated by NVM commit, power-cycling, or toggling PDN pin, but NOT by soft-reset).

    6. RESETN_SW = 1'b0; (Soft-reset is not required if PLLs are already locked, but can be done to re-initiate a VCO calibration if PLLs are not locked).

    Regards,
    Chethan
  • Hi Alan,

    This is chethan replying working on FPGA programming sequence with Vijetha.
    Please find the below observations


    1. PDN 0-->1

    2. Block Register Read/Write as per the Codeloader values.
    -- We are able to write to these register set and the output clock gets synthesized as per the new values.
    -- Make sure R12[2] = 1'b1 (Always enable internal digital system clock)
    AS EXPECTED - WE ARE WRITING CORRECTLY

    3. SRAM Write 
    R145[3:0] = 0x0; // Set to page 0
    R137[7:0] = 0x50; // Register to SRAM transfer, automatic CRC
    Read R137; // Make sure R137 reads 0x10 (bit 6 is self-cleared) to confirm SRAM transfer is complete before proceeding
    AS EXPECTED R 137 READS 0X10 -- SRAM TRANSFER IS SUCCESSFUL

    4. EEPROM Write
    R144[7:0] = 0xEA; // EEPROM Protection
    R137[7:0] = 0x11; // SRAM to EEPROM transfer, automatic CRC
    Wait at least 300 ms.
    Read R137; // Make sure R137 reads 0x10 (bit 1 is self-cleared, bit 5 is cleared) to confirm EEPROM program is completed successfully.
    ERROR: R137 READS 0X11 - READ AFTER 60 SECONDS IN DEBUG MODE. STILL THE 0TH BIT IS SET. THAT SAYS EEPROM PROGRAMMING IS A FAILURE.
    NOTE: I HOPE IN YOUR ABOVE COMMENT YOU MEANT BIT 0 & 4 INSTEAD OF BIT 1 & 5.

    R144 = 0x00; // EEPROM Protection

    5. NVM Commit -- Execute this step only after successful EEPROM programming (i.e. R137 reads 0x10 in Step 4)
    R137[7:0] = 0x18; // Transfers NVM contents to registers (intention of this is to refresh the NVMCNT value in R136)
    Read R136; // Make sure EEPROM program count has incremented (this register is only updated by NVM commit, power-cycling, or toggling PDN pin, but NOT by soft-reset).

    6. RESETN_SW = 1'b0; (Soft-reset is not required if PLLs are already locked, but can be done to re-initiate a VCO calibration if PLLs are not locked).

    Regards,
    Chethan
  • Hi Alan,

    Please find the below observations


    1. PDN 0-->1

    2. Block Register Read/Write as per the Codeloader values.
    -- We are able to write to these register set and the output clock gets synthesized as per the new values.
    -- Make sure R12[2] = 1'b1 (Always enable internal digital system clock)
    AS EXPECTED - WE ARE WRITING CORRECTLY

    3. SRAM Write 
    R145[3:0] = 0x0; // Set to page 0
    R137[7:0] = 0x50; // Register to SRAM transfer, automatic CRC
    Read R137; // Make sure R137 reads 0x10 (bit 6 is self-cleared) to confirm SRAM transfer is complete before proceeding
    AS EXPECTED R 137 READS 0X10 -- SRAM TRANSFER IS SUCCESSFUL

    4. EEPROM Write
    R144[7:0] = 0xEA; // EEPROM Protection
    R137[7:0] = 0x11; // SRAM to EEPROM transfer, automatic CRC
    Wait at least 300 ms.
    Read R137; // Make sure R137 reads 0x10 (bit 1 is self-cleared, bit 5 is cleared) to confirm EEPROM program is completed successfully.

    ERROR: R137 READS 0X11 - READ AFTER 60 SECONDS IN DEBUG MODE. STILL THE 0TH BIT IS SET. THAT SAYS EEPROM PROGRAMMING IS A FAILURE.
    NOTE: I HOPE IN YOUR ABOVE COMMENT YOU MEANT BIT 0 & 4 INSTEAD OF BIT 1 & 5.

    R144 = 0x00; // EEPROM Protection

    5. NVM Commit -- Execute this step only after successful EEPROM programming (i.e. R137 reads 0x10 in Step 4)
    R137[7:0] = 0x18; // Transfers NVM contents to registers (intention of this is to refresh the NVMCNT value in R136)
    Read R136; // Make sure EEPROM program count has incremented (this register is only updated by NVM commit, power-cycling, or toggling PDN pin, but NOT by soft-reset).

    6. RESETN_SW = 1'b0; (Soft-reset is not required if PLLs are already locked, but can be done to re-initiate a VCO calibration if PLLs are not locked).

    Regards,
    Chethan

  • Hi Alan,

    Thank you for helping us root cause the issue. I will add the solution for the readers.

    Bug was in Step 4 - EEPROM Write
    As these transactions are atomic, there should not be any transactions in between 2 writes in step-4, but as we were following Read-Modify-Write to register 137, which was adding an additional read cycle between below 2 write cycles to R144 and R137.

    R144[7:0] = 0xEA; // EEPROM Protection
    R137[7:0] = 0x11; // SRAM to EEPROM transfer, automatic CRC

    Regards,
    Chethan