I run no-os project on zc706+9009, why the jesd stay at CGS mode, it just been Data mode once in a while, may one time of 100 times try.
Even if it's recommended, the external reference clock is not mandatory for receiving/transmitting some data. That is the reference for the AD9528's PLL1. PLL1 provides reference input clock cleanup…
What version of HDL / No-OS are you using ?
2019-r1，if I must provide a sysref clk to 9009 externally?
As you may notice, the JESD link status is DATA. I checked the status several times and it remains the same.
Well, Does the no-os_2019r1 is not the same as no-OS master branch?
I do what you say but the tx_jesd state is stiil stay in CGS
Are you using this version of the project? github.com/.../adrv9009
How did you build your project? Did you use these guides?https://github.com/analogdevicesinc/no-OS/wiki/Building-no-OS-on-Linuxhttps://github.com/analogdevicesinc/no-OS/wiki/Building-no-OS-on-Windows
Yes I do follow these
Do you notice that the log warning of talise enable multichipsync failed
and tal_frame/deframe status
there are did not occur on your screen shot? why that happened?
It get error when make the no-os-master, does no-os-2019_r1 make the tx_jesd link failed which stay in CGS
I failed again with runing no-os-master on hdl_2019_r1. The tx_jesd is still stuck in CGS
additionally, I did not give external refclk to 9009
Even if it's recommended, the external reference clock is not mandatory for receiving/transmitting some data. That is the reference for the AD9528's PLL1. PLL1 provides reference input clock cleanup with external VCXO. However, in this project, PLL2 should normally lock even without PLL1 being locked.
When trying to build the no-OS, you get an error. Are you sure you are actually using the clean master branch? @amiclaus didn't see any issues.
hi, how to check the FPGA jesd settings with the jesd of 9009,from talise_config.c it can see that the framerA and framerB lanes are all 2 (2*M/F) (F=2*M/numberOfLanes), and how to caculate the lanes number of deframer?
and another confusion is in tx_jesd IP cores the num lanes is 4(does this parameter is wrong?) rx_jesd IP cores the num lanes is 2 the same as talise_config.c
You can check the ADRV9009 Transceiver evaluation tool for valid configuration of the JESD204 links.
Our default configuration and all profiles use 4 lanes for TX, 2 lanes for RX and 2 lanes for observation. Given that the number of channels for RX and TX and maximum rate is the same, this accounts for the fact that the bandwidth for TX is double than RX. In case of the observation, in order to get maximum bandwidth, a single observation channel can be enabled.
AdrianC said:all profiles use 4 lanes for TX, 2 lanes for RX and 2 lanes for observation
how to caculate lanes number in profile.
AdrianC said:the ADRV9009 Transceiver evaluation tool
this means TES?and IIO? If not, any links provided?
I would not calculate the number of lanes, I would consider them fixed at 4 TX, 2 RX and 2 ORX. Is there a reason you want to change them ?
xlh said:this means TES?and IIO? If not, any links provided?
AdrianC said:I would not calculate the number of lanes, I would consider them fixed at 4 TX, 2 RX and 2 ORX. Is there a reason you want to change them ?
I did not change it, I mean how to check these parameters in talise_config.c
And when I use TES, it can work normally.
Now my question still stay in why the tx_jesd stuck in CGS. I want to confirm if the jesd settings in software is the same as what in hardware.