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.

LMX2594: TICS Pro not updating as expected for LMX2594 when importing hex register values

Part Number: LMX2594

I have a bunch of LMX2594 config files from a Xilinx eval board project.  When I import these into TIC Pro I often don't get the correct output frequencies generated.  I don't have an eval board connected to my system - I'm just running TICS Pro standalone to generate and verify these configurations. 

I've attached a couple of the files I've been testing with.  Both expect a 400MHz input clock and they should generate 4GHg and 1024MHz outputs.  When I switch from one file to the other I can see the N divider value changing more than once while the Import Hex Registers is running - for the 1024 file I can see it load with 333 (which is correct) and then change to 166, for the 4000 file I see it initially loaded with 400 but then change to 800.  It looks like TICS is trying to calculate some of these values on the fly - can I stop it from doing that?

I tried disabling the Options->Autoupdate but that didn't help.  

Is TICS Pro supposed to simulate the chip in some sense?  When I check RESET under User Controls I'm not seeing the registers change to their POR values.

I'm using TICS Pro 1.7.2.0.  

R0	0x000002
R0	0x000000
R112	0x700000
R111	0x6f0000
R110	0x6e0000
R109	0x6d0000
R108	0x6c0000
R107	0x6b0000
R106	0x6a0000
R105	0x690021
R104	0x680000
R103	0x670000
R102	0x663f80
R101	0x650011
R100	0x640000
R99	0x630000
R98	0x620200
R97	0x610888
R96	0x600000
R95	0x5f0000
R94	0x5e0000
R93	0x5d0000
R92	0x5c0000
R91	0x5b0000
R90	0x5a0000
R89	0x590000
R88	0x580000
R87	0x570000
R86	0x560000
R85	0x55d300
R84	0x540001
R83	0x530000
R82	0x521e00
R81	0x510000
R80	0x506666
R79	0x4f0026
R78	0x4e0003
R77	0x4d0000
R76	0x4c000c
R75	0x4b08c0
R74	0x4a0000
R73	0x49003f
R72	0x480001
R71	0x470081
R70	0x46c350
R69	0x450000
R68	0x4403e8
R67	0x430000
R66	0x4201f4
R65	0x410000
R64	0x401388
R63	0x3f0000
R62	0x3e0322
R61	0x3d00a8
R60	0x3c0000
R59	0x3b0001
R58	0x3a8001
R57	0x390020
R56	0x380000
R55	0x370000
R54	0x360000
R53	0x350000
R52	0x340820
R51	0x330080
R50	0x320000
R49	0x314180
R48	0x300300
R47	0x2f0300
R46	0x2e07fc
R45	0x2dc0df
R44	0x2c1f22
R43	0x2b0001
R42	0x2a0000
R41	0x290000
R40	0x280000
R39	0x270003
R38	0x260000
R37	0x250204
R36	0x24014d
R35	0x230004
R34	0x220000
R33	0x211e21
R32	0x200393
R31	0x1f43ec
R30	0x1e318c
R29	0x1d318c
R28	0x1c0488
R27	0x1b0002
R26	0x1a0db0
R25	0x190624
R24	0x18071a
R23	0x17007c
R22	0x160001
R21	0x150401
R20	0x14e048
R19	0x1327b7
R18	0x120064
R17	0x11012c
R16	0x100080
R15	0x0f064f
R14	0x0e1e40
R13	0x0d4000
R12	0x0c5001
R11	0x0b00a8
R10	0x0a10d8
R9	0x090604
R8	0x082000
R7	0x0740b2
R6	0x06c802
R5	0x0500c8
R4	0x040a43
R3	0x030642
R2	0x020500
R1	0x01080b
R0	0x00259c
R0	0x00259c
R112	0x700000
R111	0x6f0000
R110	0x6e0000
R109	0x6d0000
R108	0x6c0000
R107	0x6b0000
R106	0x6a0000
R105	0x690021
R104	0x680000
R103	0x670000
R102	0x663f80
R101	0x650011
R100	0x640000
R99	0x630000
R98	0x620200
R97	0x610888
R96	0x600000
R95	0x5f0000
R94	0x5e0000
R93	0x5d0000
R92	0x5c0000
R91	0x5b0000
R90	0x5a0000
R89	0x590000
R88	0x580000
R87	0x570000
R86	0x560000
R85	0x55d300
R84	0x540001
R83	0x530000
R82	0x521e00
R81	0x510000
R80	0x506666
R79	0x4f0026
R78	0x4e010d
R77	0x4d0000
R76	0x4c000c
R75	0x4b0800
R74	0x4a0000
R73	0x49003f
R72	0x480001
R71	0x470081
R70	0x46c350
R69	0x450000
R68	0x4403e8
R67	0x430000
R66	0x4201f4
R65	0x410000
R64	0x401388
R63	0x3f0000
R62	0x3e0322
R61	0x3d00a8
R60	0x3c0000
R59	0x3b0001
R58	0x3a8001
R57	0x390020
R56	0x380000
R55	0x370000
R54	0x360000
R53	0x350000
R52	0x340820
R51	0x330080
R50	0x320000
R49	0x314180
R48	0x300300
R47	0x2f0300
R46	0x2e07fc
R45	0x2dc0df
R44	0x2c1fa0
R43	0x2b0000
R42	0x2a0000
R41	0x290000
R40	0x280000
R39	0x270001
R38	0x260000
R37	0x250104
R36	0x240190
R35	0x230004
R34	0x220000
R33	0x211e21
R32	0x200393
R31	0x1f43ec
R30	0x1e318c
R29	0x1d318c
R28	0x1c0488
R27	0x1b0002
R26	0x1a0db0
R25	0x190624
R24	0x18071a
R23	0x17007c
R22	0x160001
R21	0x150401
R20	0x14d048
R19	0x1327b7
R18	0x120064
R17	0x11014e
R16	0x100080
R15	0x0f064f
R14	0x0e1e40
R13	0x0d4000
R12	0x0c5002
R11	0x0b00a8
R10	0x0a10d8
R9	0x090604
R8	0x082000
R7	0x0740b2
R6	0x06c802
R5	0x0500c8
R4	0x040c43
R3	0x030642
R2	0x020500
R1	0x010809
R0	0x00241c
R0	0x000000
R0	0x000000
R0	0x000000

  • Hi Jay,

    I think this is related to how TICS Pro calculates the included divide settings, or more specifically, how it does not when using hex register import. We make a distinction between fields that are pure calculation (included divide for example) and fields that are register-backed; exporting the hex registers alone can make it challenging for TICS Pro to properly determine what some of these pure calculation fields should be. I find that importing the configuration, toggling the VCO_PHASE_SYNC, and then reimporting the configuration produces the correct behavior. This is a bug and I am going to look into it for update in the next release of TICS Pro.

    Toggling the reset does not modify the TICS Pro virtual register map, because this could easily become a nuisance when trying to design configurations. The state of the TICS Pro registers is a best-guess at the state of the device registers, based on which registers were most recently written or read back.

    Regards,

  • Thanks Derek.  It would be nice if there were a mode that allowed the hex register values to be loaded while suppressing any calculations. 

    I'll try the VCO_PHASE_SYNC trick and see if that helps.

    - Jay