I figured out a missing piece of my ADALM-PLUTO puzzle. I was getting placing errors about IO which couldn't be placed in an empty assembly. It turned out that the zynq_ps instantiation was using some generics that didn't work for the device, specifically: - C_PACKAGE_NAME - C_DQ_WIDTH - C_DQS_WIDTH - C_DM_WIDTH I added the following generics to the zynq_ps entity: - DQ_WIDTH : positive := 32 - PACKAGE_NAME : string := "clg484" I then made the following changes to the instantiation: C_DQ_WIDTH => DQ_WIDTH, C_DQS_WIDTH => DQ_WIDTH/8, C_DM_WIDTH => DQ_WIDTH/8, C_PACKAGE_NAME => PACKAGE_NAME I don't know if this is the best way to do it, but it seemed to work for me to allow for the old stuff to still work while giving me the ability to over ride it. Best practice might be to make the PACKAGE_NAME into an enumerated type since a string is too generic especially with no checking. So, to the real question, what is the preferred method for contributing some of these changes back to the community? And, are there issues seen with what I did here? Does it follow your best practices or should things be modified? Thanks, Brian

I made the same modifications, and will be included in OpenCPI release 1.7 or sooner. We're still in the process of transitioning the project from GitHub to GitLab. When the GitLab project is released to the public with OpenCPI 1.6 it will include a new contributing guide which layouts the steps necessary to push changes back to the community. Looks like your running into the same problems I had to run through. Can you elaborate a little more on your setup? In a previous email you mentioned you created an RCC platform based on Xilinx 2017.4. Did you updated the stock firmware and have that running on Pluto? Are you still utilizing the USB device functionality orr are you using it in standalone mode? Aaron On Thu, Jan 9, 2020 at 9:08 AM Brian Padalino <bpadalino@gmail.com> wrote: > I figured out a missing piece of my ADALM-PLUTO puzzle. I was getting > placing errors about IO which couldn't be placed in an empty assembly. It > turned out that the zynq_ps instantiation was using some generics that > didn't work for the device, specifically: > > - C_PACKAGE_NAME > - C_DQ_WIDTH > - C_DQS_WIDTH > - C_DM_WIDTH > > I added the following generics to the zynq_ps entity: > > - DQ_WIDTH : positive := 32 > - PACKAGE_NAME : string := "clg484" > > I then made the following changes to the instantiation: > > C_DQ_WIDTH => DQ_WIDTH, > C_DQS_WIDTH => DQ_WIDTH/8, > C_DM_WIDTH => DQ_WIDTH/8, > C_PACKAGE_NAME => PACKAGE_NAME > > I don't know if this is the best way to do it, but it seemed to work for me > to allow for the old stuff to still work while giving me the ability to > over ride it. Best practice might be to make the PACKAGE_NAME into an > enumerated type since a string is too generic especially with no checking. > > So, to the real question, what is the preferred method for contributing > some of these changes back to the community? And, are there issues seen > with what I did here? Does it follow your best practices or should things > be modified? > > Thanks, > Brian >

On Thu, Jan 9, 2020 at 11:30 AM Aaron Olivarez <aaron@olivarez.info> wrote: > I made the same modifications, and will be included in OpenCPI release 1.7 > or sooner. We're still in the process of transitioning the project from > GitHub to GitLab. When the GitLab project is released to the public with > OpenCPI 1.6 it will include a new contributing guide which layouts the > steps necessary to push changes back to the community. > Awesome! > > Looks like your running into the same problems I had to run through. Can > you elaborate a little more on your setup? In a previous email you > mentioned you created an RCC platform based on Xilinx 2017.4. Did you > updated the stock firmware and have that running on Pluto? Are you still > utilizing the USB device functionality orr are you using it in standalone > mode? > I'm only looking to run it standalone. I saw the failure of the fsk_filerw to target the 7010, so I just excluded it from the list to build for now. Is there a good internal loopback test to run for OpenCPI that tests AXI DMA and make sure everything is all plumbed together well? A simple PL loopback might work well for me? Maybe putting in the TX-only part of the FSK modem might be the next step? I'm open to suggestions. My initial plan was just to insmod the kernel module built against the pluto-fw linux kernel, copy over the appropriate libraries and run a simple application. Is that not a great idea? Guidance is very much appreciated. Thanks, Brian

I used the testbias application to test initial AXI DMA plumbing within

Yup, that will work. The issue you might run into is the lack of space

On Thu, Jan 9, 2020 at 10:38 AM Brian Padalino <bpadalino@gmail.com> wrote: > On Thu, Jan 9, 2020 at 11:30 AM Aaron Olivarez <aaron@olivarez.info> > wrote: > >> I made the same modifications, and will be included in OpenCPI release >> 1.7 or sooner. We're still in the process of transitioning the project from >> GitHub to GitLab. When the GitLab project is released to the public with >> OpenCPI 1.6 it will include a new contributing guide which layouts the >> steps necessary to push changes back to the community. >> > > Awesome! > > >> >> Looks like your running into the same problems I had to run through. Can >> you elaborate a little more on your setup? In a previous email you >> mentioned you created an RCC platform based on Xilinx 2017.4. Did you >> updated the stock firmware and have that running on Pluto? Are you still >> utilizing the USB device functionality orr are you using it in standalone >> mode? >> > > I'm only looking to run it standalone. I saw the failure of the > fsk_filerw to target the 7010, so I just excluded it from the list to > build for now. Is there a good internal loopback test to run for OpenCPI > that tests AXI DMA and make sure everything is all plumbed together well? > A simple PL loopback might work well for me? Maybe putting in the TX-only > part of the FSK modem might be the next step? I'm open to suggestions. > I used the testbias application to test initial AXI DMA plumbing within OpenCPI. > My initial plan was just to insmod the kernel module built against the > pluto-fw linux kernel, copy over the appropriate libraries and run a simple > application. Is that not a great idea? > > Yup, that will work. The issue you might run into is the lack of space on the file system; but you can get around easily. I've done it with a flash drive or enabling NFS kernel support. There is also an OpenCPI remote (ssh) option that we will be using upon release. On your RCC platform be sure your tool dir is using? I'm using /gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin I ran into issues when running apps because they were being cross compiled using the older xilinx compiler: /gnu/arm/lin/bin You might already gone past this but I also had to update the -mfloat-abi=softfp to -mfloat-abi=hard > Guidance is very much appreciated. > > Thanks, > Brian >

-  Create RCC workers to handle initialization and configuration of

-  Created rx_app to receive complex samples - I generated a tone using

-  FSK APP
   - filerw
            - got this to work by reducing several properties in the

 I used the testbias application to test initial AXI DMA plumbing

Yup, that will work. The issue you might run into is the lack of space

On your RCC platform be sure your tool dir is using?  I'm using

You might already gone past this but I also had to update the

These are the steps I took to incorporate AD9361 as well as a progress report of my version of the PLUTO port, hope this helps. Most of the code was ported from https://github.com/opencpi/av.bsp.e310 since E310 also utilizes the CMOS interface. - Create RCC workers to handle initialization and configuration of AD9361 hdl/devices/pluto_rx.rcc and hdl/devices/pluto_tx.rcc - equivalent to hdl/cards/e3xx_rx.rcc and hdl/cards/e3xx_tx.rcc - Create pluto_tx_test and pluto_rx_test applications for those workers. Tests SPI configuration to AD9361 - Create ad9361_adc_test application - Receive and verify PRBS sequence generated from AD9361 at different sampling rates - requires assembly - ad9361_1r1t_test_adc_asm - mod to this assembly was to reduce the FIFO from 8192 to 1024 due to lack of distributed ram resources on 7010 - Create ad9361_dac_test - PRBS sequence generated in fabric sent to DAC , AD9361 is placed in digital loopback and PRBS sequence is received on ADC channel. - requires assembly - ad9361_1r1t_test_asm - mod similar to previous 8192 to 1024 due to lack of distributed ram on 7010 - could only compare 512 samples on receive side due to smaller FIFO At this point I was able to confirm that I can configure, send, and receive data to and from AD9361, now for the RF side. - Created rx_app to receive complex samples - I generated a tone using a signal generate and plotted received signal - requires dc_offset_iq_imbalance_mixer_cic_dec_timestamper assembly no mods necessary - FSK APP - filerw - got this to work by reducing several properties in the filerw assembly, definitely not ideal - reducing the number of taps of FIR - 8 taps - reducing the number of iterations on cordics - 5 stages on each - tx - 7010 only has 80 dsp's I had to reduce mfsk2_zp16_fir_real_phase_to_amp_cordic_cic_int assembly to a 60 taps SSE FIR - rx - 7010 only has 80 dsp's I had to reduce dc_offset_iq_imbalance_mixer_cic_dec_rp_cordic_fir_real assembly to 60 taps SSE FIR - txrx (WIP) - unlike the filerw going to RF the FIR filter is critical in creating the correct accumulations for the phase_to_amp cordic. - Currently working on a component based on Xilinx FIR IP core that uses shared DSP resources to get past 80 dsp slice limitation Aaron On Thu, Jan 9, 2020 at 11:08 AM Aaron Olivarez <aaron@olivarez.info> wrote: > > On Thu, Jan 9, 2020 at 10:38 AM Brian Padalino <bpadalino@gmail.com> > wrote: > >> On Thu, Jan 9, 2020 at 11:30 AM Aaron Olivarez <aaron@olivarez.info> >> wrote: >> >>> I made the same modifications, and will be included in OpenCPI release >>> 1.7 or sooner. We're still in the process of transitioning the project from >>> GitHub to GitLab. When the GitLab project is released to the public with >>> OpenCPI 1.6 it will include a new contributing guide which layouts the >>> steps necessary to push changes back to the community. >>> >> >> Awesome! >> >> >>> >>> Looks like your running into the same problems I had to run through. Can >>> you elaborate a little more on your setup? In a previous email you >>> mentioned you created an RCC platform based on Xilinx 2017.4. Did you >>> updated the stock firmware and have that running on Pluto? Are you still >>> utilizing the USB device functionality orr are you using it in standalone >>> mode? >>> >> >> I'm only looking to run it standalone. I saw the failure of the >> fsk_filerw to target the 7010, so I just excluded it from the list to >> build for now. Is there a good internal loopback test to run for OpenCPI >> that tests AXI DMA and make sure everything is all plumbed together well? >> A simple PL loopback might work well for me? Maybe putting in the TX-only >> part of the FSK modem might be the next step? I'm open to suggestions. >> > > I used the testbias application to test initial AXI DMA plumbing > within OpenCPI. > > >> My initial plan was just to insmod the kernel module built against the >> pluto-fw linux kernel, copy over the appropriate libraries and run a simple >> application. Is that not a great idea? >> >> Yup, that will work. The issue you might run into is the lack of space > on the file system; but you can get around easily. I've done it with a > flash drive or enabling NFS kernel support. There is also an OpenCPI remote > (ssh) option that we will be using upon release. > > On your RCC platform be sure your tool dir is using? I'm using > /gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin > I ran into issues when running apps because they were being cross > compiled using the older xilinx compiler: /gnu/arm/lin/bin > > You might already gone past this but I also had to update the > -mfloat-abi=softfp to -mfloat-abi=hard > > >> Guidance is very much appreciated. >> >> Thanks, >> Brian >> >