Internal GPIO connection to any pins of P2 or P13 for ADRV9361-Z7035 BOB Carrier Board

Hi,

The system.v is created by Vivado, and if you are using our flow of building the project (with make command), then that file will be deleted every time the build starts and then will be created again during the build.

Can you take a look at the constraints file of this project? And look at the comments there, you will see that there are pins from P2 and P13 present, so you could trace back the path for these signals gp_in.
Let's say you want to use IO_L08_12_JX3_P. This one is already in the constraints file, here, named gp_in[73].
Then going backwards, it is changing the name of the signal here to gp_in_s[73].
Further, gp_in_s[73] is assigned to gp_in_2 here. This gp_in_2 multibit port is declared here and connected to axi_gpreg/up_gp_in_2 here

This would be one approach, of course, applied to your signals.

There is another approach, but more complicated.

Let me know if this is not what you need and I will explain the other approach.

Best regards,
Iulia

Hi,

Thanks for your fast response. I'll try to build the project while updating the ccbob_bd.tcl as per your recommendation, test data on port P13 and get back to you if the more complicated solution is needed as an alternative.

I've one more question is there away by which I can choose the implementation running strategy used on VIVADO before building the project using ADI make command.

Thanks in advance,

Hatem

Hatem said:

is there away by which I can choose the implementation running strategy used on VIVADO before building the project using ADI make command.

Are you referring to something like this? https://docs.xilinx.com/r/en-US/ug904-vivado-implementation/Customizing-Implementation-Strategies

If so, I think you should do some changes in this procedure accordingly to your customization, if you still want to use the make command flow. Maybe you should do some changes in other procedures, but I am not sure, you would have to check that.

Best regards,
Iulia

I already do so in my customization after doing regular implementation cycle proposed by ADI using make command flow, but I was thinking this could be forced before building the project by editing some .tcl file. 

One last question is there a possibility that I run my digital core inside the AXI_ad9361.v at a lower clock rate than the rx_clk of 250 MHZ or will this affect the whole core rates. As I see this clock is used by many other modules of the tdd, up_axi, adc, dac, fifos, ...  As the timing violation in the implementation of the digital core is due to the limit of 4 ns by 0.35ns WNS.

Thanks in advance,

Hatem

iulia said:

do some changes in this procedure

Apologies but it seems the link to the procedure that I mentioned, didn't get posted. This is the procedure (adi_project_impl): https://github.com/analogdevicesinc/hdl/blob/master/projects/scripts/adi_project_xilinx.tcl#L602

Hatem said:

is there a possibility that I run my digital core inside the AXI_ad9361.v at a lower clock rate than the rx_clk of 250 MHZ or will this affect the whole core rates

There are two options, as far as I can see, depending on what you're doing there with the GPIOs.

If you want to do some data processing, I would suggest you to create an IP and add it like the FIR instance from this diagram is added. This way you will be doing the processing at a lower speed, 61.44MHz, like it is depicted in the diagram.

But if don't do any data processing and you just use the GPIOs like some enable/disable, etc., then I would suggest you to do Clock Domain Crossing.

Best regards,
Iulia

Even though the ADRV9361-z7035 board was working properly before, but now the board refuses to login.  It's plugged into PicoZed SDR BOB Carrier board with the led CFG (Ds7) neither turns on blue as usual and GP100 DS3 of turns into red forever with DS4 glowing a little.

I was following your recommendations to interconnect an internal generated clock at 1 Hz and send it to gp_out_0 port with other pins of the port connected to 0, by writing the command ad_connect gp_out_0 axi_ad9361/clk_dv in ccbob_bd.tcl. However, once booted into the board I got the above behavour and can't access or login into the SOM board again.

I've tried reimaging the SDcard with default settings from the following site 

https://wiki.analog.com/resources/tools-software/linux-software/adi-kuiper_images/release_notes

but still nothing changes, is there a way so, I can reset the board into factory settings, please guide me what to do as soon as possible?

Thanks in advance,

Hatem

Hatem said:

the led CFG (Ds7) neither turns on blue as usual and GP100 DS3 of turns into red

That means you did something wrong in your design and the board is not programmed. 

Hatem said:

your recommendations to interconnect an internal generated clock at 1 Hz and send it to gp_out_0 port

I just suggested that you could use those GPIOs, but it's up to you if you use them properly.

What you connected there, is a 32-bit signal (gp_out_0, see here) with a 122.88MHz clock (the clock for the default configuration).

Hatem said:

but still nothing changes,

You don't have to rewrite the image of the SD card. You just need to put the BOOT.BIN, uImage and devicetree.dtb in the boot partition of the SD card (more info here).

Best regards,
Iulia

Hi,

Thanks for your detailed explanation to every point. The issue was due to copying the new BOOT.bin through ethernet connection while the board is running. So, when I restart the SOM board the overwriting changes the boot file into .error, that results in failure to configure the FPGA board. The issue was solved by turning off the board, removing the SD card, copy the boot into root location and returns the SD card into position, then switch on again.

Thanks for your appreciated support,

Hatem

Thank you for letting me know.

Have a nice day!