Re: [casper] How to use the qdr_transpose and qdr_ct blocks?
Hi Chenwei et al. Commit 082b13caee in the casper-astro-soak-test branch now allows calibration of QDRs even when the fabric is writing to the whole QDR memory space. It does this my allowing the software interface to disable simulink writes whilst calibration is taking place. To use this functionality, you'll need to use both the updated pcore and calibration software in this commit. Cheers, Jack On Tue, 9 Jun 2015 at 10:00 Chenwei Cai wrote: > Hi Jack, > > Yes, it works now! I have obtained the .bof file from the new compilation. > Thanks so much for your suggestions and help. I will try to calibrate qdr > with the script you provided in my next step. > > Best Regards > Chenwei CAI > > Email: caichenwei1...@pku.edu.cn > > > On Tue, Jun 9, 2015 at 4:24 AM, Jack Hickish > wrote: > >> Hi Chenwei, >> >> I had a look at your model - the error will go away if you select the >> "enable CPU interface" option in your qdr yellow blocks. Regardless of your >> error, enabling the cpu interface is necessary because it is used for >> calibrating the qdr on roach2 (this was not the case on roach1) using the >> script in the mlib_devel repo. >> Note that currently calibrating the qdr requires software writes to occur >> in the top half of the memory without being interfered with by the fabric >> (aka simulink) qdr interface. QDR calibration will fail if you attempt to >> calibrate whilst the fabric is writing to the top half of the qdr memory >> space, so when using more than 20 bits of the address line, you'll need a >> way to halt the simulink interface during calibration. >> Tomorrow I'll try and modify the qdr controller so that it can override >> the simulink interface during calibration, since currently this is an >> unnecessary user hassle. >> >> Cheers, >> Jack >> >> On 8 June 2015 at 10:38, Chenwei Cai wrote: >> >>> Hi Jack, >>> >>> I have encountered the same problem with Xilinx 14.7. See the log, >>> >>> ERROR:PhysDesignRules:1763 - Issue with pin connections and/or >>> configuration on >>> >>> >>> block:>>>>:. For DELAY_SRC IO or O programming the >>> ODATAIN >>>input pins of IODELAYE1 must be connected. >>> ERROR:Bitgen:25 - DRC detected 1 errors and 63 warnings. Please see the >>>previously displayed individual error or warning messages for more >>> details. >>> === >>> Flow run time summary: (01:08:07 seconds total) >>> System update00:00:00 >>> Design Rules Check...00:00:00 >>> Xilinx System Generator..00:52:02 >>> Base system copy.00:00:00 >>> IP creation..00:00:00 >>> EDK files creation...00:00:05 >>> IP elaboration...00:00:00 >>> Software creation00:00:00 >>> EDK/ISE backend..00:15:58 >>> === >>> >>> Maybe I truly need your help on this. And here is my model, >>> https://www.dropbox.com/s/oiawxtux7syt0jv/fft_corner_turner_v4_nuevo.slx?dl=0 >>> . There is one self-defined block, filt_sample, within the model, which can >>> be obtained an added through this url, >>> https://www.dropbox.com/sh/qckqor5hw8if0rv/AAB_SGyCoBsgDHk-8YfpPKlma?dl=0 >>> . >>> >>> Thanks for your help! >>> >>> On Sat, Jun 6, 2015 at 3:43 AM, Jack Hickish >>> wrote: >>> no rush - let me know how the compile goes! cheers jack On 5 June 2015 at 23:24, Chenwei Cai wrote: > Sure Jack, but I have to send that to you on Monday, because that is > not in my personal computer. I have installed Xilinx 14.7 on that computer > and the model is being compiled now. > > > El sábado, 6 de junio de 2015, Jack Hickish > escribió: > >> in fact, can you send me your design and i'll check it works on 14.7. >> Some of the warnings you have are a bit concerning but i think they might >> just be related to some bit slicing you're doing in your model. >> >> Thanks, >> Jack >> >> On 5 June 2015 at 13:06, Jack Hickish wrote: >> >>> Hi Chenwei, >>> >>> I'll fix the verilog anyway to get rid of that erro, but I think >>> you'll find that if you use 14.7 the error will go away. In any case, >>> 14.7 >>> is the last version of ISE that Xilinx will release, so it's the one >>> we're >>> going to target in our libraries - it might be a good idea to upgrade >>> your >>> toolflow for this reason alone. >>> >>> Cheers, >>> Jack >>> >>> On Fri, 5 Jun 2015 at 12:57 Chenwei Cai >>> wrote: >>> Hi Jack, I am using Xilinx 14.5. On Fri, Jun 5, 2015 at 4:55 PM, Jack Hickish >>> > wrote: > Hi Chenwei, > > What version of the Xilinx tools are you using? > I think this is easy to fix, but I'm surprised I didn't see this > error when I compiled my test models. >
Re: [casper] How to use the qdr_transpose and qdr_ct blocks?
Hi Jack, Yes, it works now! I have obtained the .bof file from the new compilation. Thanks so much for your suggestions and help. I will try to calibrate qdr with the script you provided in my next step. Best Regards Chenwei CAI Email: caichenwei1...@pku.edu.cn On Tue, Jun 9, 2015 at 4:24 AM, Jack Hickish wrote: > Hi Chenwei, > > I had a look at your model - the error will go away if you select the > "enable CPU interface" option in your qdr yellow blocks. Regardless of your > error, enabling the cpu interface is necessary because it is used for > calibrating the qdr on roach2 (this was not the case on roach1) using the > script in the mlib_devel repo. > Note that currently calibrating the qdr requires software writes to occur > in the top half of the memory without being interfered with by the fabric > (aka simulink) qdr interface. QDR calibration will fail if you attempt to > calibrate whilst the fabric is writing to the top half of the qdr memory > space, so when using more than 20 bits of the address line, you'll need a > way to halt the simulink interface during calibration. > Tomorrow I'll try and modify the qdr controller so that it can override > the simulink interface during calibration, since currently this is an > unnecessary user hassle. > > Cheers, > Jack > > On 8 June 2015 at 10:38, Chenwei Cai wrote: > >> Hi Jack, >> >> I have encountered the same problem with Xilinx 14.7. See the log, >> >> ERROR:PhysDesignRules:1763 - Issue with pin connections and/or >> configuration on >> >> >> block:>>>:. For DELAY_SRC IO or O programming the >> ODATAIN >>input pins of IODELAYE1 must be connected. >> ERROR:Bitgen:25 - DRC detected 1 errors and 63 warnings. Please see the >>previously displayed individual error or warning messages for more >> details. >> === >> Flow run time summary: (01:08:07 seconds total) >> System update00:00:00 >> Design Rules Check...00:00:00 >> Xilinx System Generator..00:52:02 >> Base system copy.00:00:00 >> IP creation..00:00:00 >> EDK files creation...00:00:05 >> IP elaboration...00:00:00 >> Software creation00:00:00 >> EDK/ISE backend..00:15:58 >> === >> >> Maybe I truly need your help on this. And here is my model, >> https://www.dropbox.com/s/oiawxtux7syt0jv/fft_corner_turner_v4_nuevo.slx?dl=0 >> . There is one self-defined block, filt_sample, within the model, which can >> be obtained an added through this url, >> https://www.dropbox.com/sh/qckqor5hw8if0rv/AAB_SGyCoBsgDHk-8YfpPKlma?dl=0 >> . >> >> Thanks for your help! >> >> On Sat, Jun 6, 2015 at 3:43 AM, Jack Hickish >> wrote: >> >>> no rush - let me know how the compile goes! >>> >>> cheers >>> jack >>> >>> On 5 June 2015 at 23:24, Chenwei Cai wrote: >>> Sure Jack, but I have to send that to you on Monday, because that is not in my personal computer. I have installed Xilinx 14.7 on that computer and the model is being compiled now. El sábado, 6 de junio de 2015, Jack Hickish escribió: > in fact, can you send me your design and i'll check it works on 14.7. > Some of the warnings you have are a bit concerning but i think they might > just be related to some bit slicing you're doing in your model. > > Thanks, > Jack > > On 5 June 2015 at 13:06, Jack Hickish wrote: > >> Hi Chenwei, >> >> I'll fix the verilog anyway to get rid of that erro, but I think >> you'll find that if you use 14.7 the error will go away. In any case, >> 14.7 >> is the last version of ISE that Xilinx will release, so it's the one >> we're >> going to target in our libraries - it might be a good idea to upgrade >> your >> toolflow for this reason alone. >> >> Cheers, >> Jack >> >> On Fri, 5 Jun 2015 at 12:57 Chenwei Cai >> wrote: >> >>> Hi Jack, >>> >>> I am using Xilinx 14.5. >>> >>> On Fri, Jun 5, 2015 at 4:55 PM, Jack Hickish >>> wrote: >>> Hi Chenwei, What version of the Xilinx tools are you using? I think this is easy to fix, but I'm surprised I didn't see this error when I compiled my test models. Cheers, Jack On Fri, 5 Jun 2015 at 12:02 Chenwei Cai wrote: > Thanks Jack, > > The qdr_transpose seems to work appropriately now. And I am now > using the qdr_transpose block to construct my model which will be > executed > with ROACH II, as you can check out in the following url: > https://www.dropbox.com/s/1wcz0lhmjgcuwua/Screenshot%20from%202015-06-05%2015%3A35%3A44.png?dl=0. > The library I am using is the one Jack merged last week ( > http://www.m
Re: [casper] How to use the qdr_transpose and qdr_ct blocks?
Hi Chenwei, I had a look at your model - the error will go away if you select the "enable CPU interface" option in your qdr yellow blocks. Regardless of your error, enabling the cpu interface is necessary because it is used for calibrating the qdr on roach2 (this was not the case on roach1) using the script in the mlib_devel repo. Note that currently calibrating the qdr requires software writes to occur in the top half of the memory without being interfered with by the fabric (aka simulink) qdr interface. QDR calibration will fail if you attempt to calibrate whilst the fabric is writing to the top half of the qdr memory space, so when using more than 20 bits of the address line, you'll need a way to halt the simulink interface during calibration. Tomorrow I'll try and modify the qdr controller so that it can override the simulink interface during calibration, since currently this is an unnecessary user hassle. Cheers, Jack On 8 June 2015 at 10:38, Chenwei Cai wrote: > Hi Jack, > > I have encountered the same problem with Xilinx 14.7. See the log, > > ERROR:PhysDesignRules:1763 - Issue with pin connections and/or > configuration on > > block:>>:. For DELAY_SRC IO or O programming the ODATAIN >input pins of IODELAYE1 must be connected. > ERROR:Bitgen:25 - DRC detected 1 errors and 63 warnings. Please see the >previously displayed individual error or warning messages for more > details. > === > Flow run time summary: (01:08:07 seconds total) > System update00:00:00 > Design Rules Check...00:00:00 > Xilinx System Generator..00:52:02 > Base system copy.00:00:00 > IP creation..00:00:00 > EDK files creation...00:00:05 > IP elaboration...00:00:00 > Software creation00:00:00 > EDK/ISE backend..00:15:58 > === > > Maybe I truly need your help on this. And here is my model, > https://www.dropbox.com/s/oiawxtux7syt0jv/fft_corner_turner_v4_nuevo.slx?dl=0 > . There is one self-defined block, filt_sample, within the model, which can > be obtained an added through this url, > https://www.dropbox.com/sh/qckqor5hw8if0rv/AAB_SGyCoBsgDHk-8YfpPKlma?dl=0 > . > > Thanks for your help! > > On Sat, Jun 6, 2015 at 3:43 AM, Jack Hickish > wrote: > >> no rush - let me know how the compile goes! >> >> cheers >> jack >> >> On 5 June 2015 at 23:24, Chenwei Cai wrote: >> >>> Sure Jack, but I have to send that to you on Monday, because that is not >>> in my personal computer. I have installed Xilinx 14.7 on that computer and >>> the model is being compiled now. >>> >>> >>> El sábado, 6 de junio de 2015, Jack Hickish >>> escribió: >>> in fact, can you send me your design and i'll check it works on 14.7. Some of the warnings you have are a bit concerning but i think they might just be related to some bit slicing you're doing in your model. Thanks, Jack On 5 June 2015 at 13:06, Jack Hickish wrote: > Hi Chenwei, > > I'll fix the verilog anyway to get rid of that erro, but I think > you'll find that if you use 14.7 the error will go away. In any case, 14.7 > is the last version of ISE that Xilinx will release, so it's the one we're > going to target in our libraries - it might be a good idea to upgrade your > toolflow for this reason alone. > > Cheers, > Jack > > On Fri, 5 Jun 2015 at 12:57 Chenwei Cai > wrote: > >> Hi Jack, >> >> I am using Xilinx 14.5. >> >> On Fri, Jun 5, 2015 at 4:55 PM, Jack Hickish >> wrote: >> >>> Hi Chenwei, >>> >>> What version of the Xilinx tools are you using? >>> I think this is easy to fix, but I'm surprised I didn't see this >>> error when I compiled my test models. >>> >>> Cheers, >>> Jack >>> >>> On Fri, 5 Jun 2015 at 12:02 Chenwei Cai >>> wrote: >>> Thanks Jack, The qdr_transpose seems to work appropriately now. And I am now using the qdr_transpose block to construct my model which will be executed with ROACH II, as you can check out in the following url: https://www.dropbox.com/s/1wcz0lhmjgcuwua/Screenshot%20from%202015-06-05%2015%3A35%3A44.png?dl=0. The library I am using is the one Jack merged last week ( http://www.mail-archive.com/casper@lists.berkeley.edu/msg05947.html ). The compile goes smoothly, only to find an error at the last of compile. See the log below, which records the last part of compile. Running DRC. WARNING:PhysDesignRules:367 - The signal >>>g/fifo_din_buf1<81>> is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367
Re: [casper] How to use the qdr_transpose and qdr_ct blocks?
Hi Chenwei, I'll fix the verilog anyway to get rid of that erro, but I think you'll find that if you use 14.7 the error will go away. In any case, 14.7 is the last version of ISE that Xilinx will release, so it's the one we're going to target in our libraries - it might be a good idea to upgrade your toolflow for this reason alone. Cheers, Jack On Fri, 5 Jun 2015 at 12:57 Chenwei Cai wrote: > Hi Jack, > > I am using Xilinx 14.5. > > On Fri, Jun 5, 2015 at 4:55 PM, Jack Hickish > wrote: > >> Hi Chenwei, >> >> What version of the Xilinx tools are you using? >> I think this is easy to fix, but I'm surprised I didn't see this error >> when I compiled my test models. >> >> Cheers, >> Jack >> >> On Fri, 5 Jun 2015 at 12:02 Chenwei Cai wrote: >> >>> Thanks Jack, >>> >>> The qdr_transpose seems to work appropriately now. And I am now using >>> the qdr_transpose block to construct my model which will be executed with >>> ROACH II, as you can check out in the following url: >>> https://www.dropbox.com/s/1wcz0lhmjgcuwua/Screenshot%20from%202015-06-05%2015%3A35%3A44.png?dl=0. >>> The library I am using is the one Jack merged last week ( >>> http://www.mail-archive.com/casper@lists.berkeley.edu/msg05947.html). >>> >>> The compile goes smoothly, only to find an error at the last of compile. >>> See the log below, which records the last part of compile. >>> >>> Running DRC. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/fifo_din_buf1<81>> is incomplete. The signal does not drive any >>> load pins >>>in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/fifo_din_buf1<83>> is incomplete. The signal does not drive any >>> load pins >>>in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/fifo_din_buf1<113>> is incomplete. The signal does not drive any >>> load pins >>>in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/fifo_din_buf1<61>> is incomplete. The signal does not drive any >>> load pins >>>in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/fifo_din_buf1<63>> is incomplete. The signal does not drive any >>> load pins >>>in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/fifo_din_buf1<17>> is incomplete. The signal does not drive any >>> load pins >>>in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/fifo_din_buf1<31>> is incomplete. The signal does not drive any >>> load pins >>>in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM11_RAMA_D1_DPO> is >>> incomplete. The >>>signal does not drive any load pins in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM11_RAMB_D1_DPO> is >>> incomplete. The >>>signal does not drive any load pins in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM11_RAMD_D1_O> is incomplete. >>> The >>>signal does not drive any load pins in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM3_RAMC_D1_DPO> is >>> incomplete. The >>>signal does not drive any load pins in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM3_RAMD_D1_O> is incomplete. >>> The >>>signal does not drive any load pins in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM14_RAMB_D1_DPO> is >>> incomplete. The >>>signal does not drive any load pins in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM14_RAMC_D1_DPO> is >>> incomplete. The >>>signal does not drive any load pins in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM14_RAMD_D1_O> is incomplete. >>> The >>>signal does not drive any load pins in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM19_RAMC_D1_DPO> is >>> incomplete. The >>>signal does not drive any load pins in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM19_RAMD_D1_O> is incomplete. >>> The >>>signal does not drive any load pins in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM6_RAMA_D1_DPO> is >>> incomplete. The >>>signal does not drive any load pins in the design. >>> WARNING:PhysDesignRules:367 - The signal >>> >>> >>> >>g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM6_RAMD_D1_O> is incomplete. >>> The >>>signal does not drive any load pins in the design. >>> WARNING:PhysDesignRules:36
Re: [casper] How to use the qdr_transpose and qdr_ct blocks?
Hi Jack, I am using Xilinx 14.5. On Fri, Jun 5, 2015 at 4:55 PM, Jack Hickish wrote: > Hi Chenwei, > > What version of the Xilinx tools are you using? > I think this is easy to fix, but I'm surprised I didn't see this error > when I compiled my test models. > > Cheers, > Jack > > On Fri, 5 Jun 2015 at 12:02 Chenwei Cai wrote: > >> Thanks Jack, >> >> The qdr_transpose seems to work appropriately now. And I am now using the >> qdr_transpose block to construct my model which will be executed with ROACH >> II, as you can check out in the following url: >> https://www.dropbox.com/s/1wcz0lhmjgcuwua/Screenshot%20from%202015-06-05%2015%3A35%3A44.png?dl=0. >> The library I am using is the one Jack merged last week ( >> http://www.mail-archive.com/casper@lists.berkeley.edu/msg05947.html). >> >> The compile goes smoothly, only to find an error at the last of compile. >> See the log below, which records the last part of compile. >> >> Running DRC. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/fifo_din_buf1<81>> is incomplete. The signal does not drive any load >> pins >>in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/fifo_din_buf1<83>> is incomplete. The signal does not drive any load >> pins >>in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/fifo_din_buf1<113>> is incomplete. The signal does not drive any >> load pins >>in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/fifo_din_buf1<61>> is incomplete. The signal does not drive any load >> pins >>in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/fifo_din_buf1<63>> is incomplete. The signal does not drive any load >> pins >>in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/fifo_din_buf1<17>> is incomplete. The signal does not drive any load >> pins >>in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/fifo_din_buf1<31>> is incomplete. The signal does not drive any load >> pins >>in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM11_RAMA_D1_DPO> is >> incomplete. The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM11_RAMB_D1_DPO> is >> incomplete. The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM11_RAMD_D1_O> is incomplete. >> The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM3_RAMC_D1_DPO> is incomplete. >> The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM3_RAMD_D1_O> is incomplete. >> The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM14_RAMB_D1_DPO> is >> incomplete. The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM14_RAMC_D1_DPO> is >> incomplete. The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM14_RAMD_D1_O> is incomplete. >> The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM19_RAMC_D1_DPO> is >> incomplete. The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM19_RAMD_D1_O> is incomplete. >> The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM6_RAMA_D1_DPO> is incomplete. >> The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM6_RAMD_D1_O> is incomplete. >> The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM18_RAMD_D1_O> is incomplete. >> The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM12_RAMD_D1_O> is incomplete. >> The >>signal does not drive any load pins in the design. >> WARNING:PhysDesignRules:367 - The signal >> >> >> >g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM17_RAMD_D1_O> is incomplete. >> The >>signal does not drive any load pins in the design. >> WARNING:PhysDes
Re: [casper] How to use the qdr_transpose and qdr_ct blocks?
Hi Chenwei, What version of the Xilinx tools are you using? I think this is easy to fix, but I'm surprised I didn't see this error when I compiled my test models. Cheers, Jack On Fri, 5 Jun 2015 at 12:02 Chenwei Cai wrote: > Thanks Jack, > > The qdr_transpose seems to work appropriately now. And I am now using the > qdr_transpose block to construct my model which will be executed with ROACH > II, as you can check out in the following url: > https://www.dropbox.com/s/1wcz0lhmjgcuwua/Screenshot%20from%202015-06-05%2015%3A35%3A44.png?dl=0. > The library I am using is the one Jack merged last week ( > http://www.mail-archive.com/casper@lists.berkeley.edu/msg05947.html). > > The compile goes smoothly, only to find an error at the last of compile. > See the log below, which records the last part of compile. > > Running DRC. > WARNING:PhysDesignRules:367 - The signal > > g/fifo_din_buf1<81>> is incomplete. The signal does not drive any load > pins >in the design. > WARNING:PhysDesignRules:367 - The signal > > g/fifo_din_buf1<83>> is incomplete. The signal does not drive any load > pins >in the design. > WARNING:PhysDesignRules:367 - The signal > > g/fifo_din_buf1<113>> is incomplete. The signal does not drive any load > pins >in the design. > WARNING:PhysDesignRules:367 - The signal > > g/fifo_din_buf1<61>> is incomplete. The signal does not drive any load > pins >in the design. > WARNING:PhysDesignRules:367 - The signal > > g/fifo_din_buf1<63>> is incomplete. The signal does not drive any load > pins >in the design. > WARNING:PhysDesignRules:367 - The signal > > g/fifo_din_buf1<17>> is incomplete. The signal does not drive any load > pins >in the design. > WARNING:PhysDesignRules:367 - The signal > > g/fifo_din_buf1<31>> is incomplete. The signal does not drive any load > pins >in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM11_RAMA_D1_DPO> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM11_RAMB_D1_DPO> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM11_RAMD_D1_O> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM3_RAMC_D1_DPO> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM3_RAMD_D1_O> is incomplete. The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM14_RAMB_D1_DPO> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM14_RAMC_D1_DPO> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM14_RAMD_D1_O> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM19_RAMC_D1_DPO> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM19_RAMD_D1_O> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM6_RAMA_D1_DPO> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM6_RAMD_D1_O> is incomplete. The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM18_RAMD_D1_O> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM12_RAMD_D1_O> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM17_RAMD_D1_O> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM13_RAMD_D1_O> is incomplete. > The >signal does not drive any load pins in the design. > WARNING:PhysDesignRules:367 - The signal > > g/FIFO/BU2/U0/grf.rf/mem/gdm.dm/Mram_RAM7_RAMD_D1_O> is incomplete. The >signal does not drive any load pins in the design.
Re: [casper] How to use the qdr_transpose and qdr_ct blocks?
Thanks Jack, The qdr_transpose seems to work appropriately now. And I am now using the qdr_transpose block to construct my model which will be executed with ROACH II, as you can check out in the following url: https://www.dropbox.com/s/1wcz0lhmjgcuwua/Screenshot%20from%202015-06-05%2015%3A35%3A44.png?dl=0. The library I am using is the one Jack merged last week ( http://www.mail-archive.com/casper@lists.berkeley.edu/msg05947.html). The compile goes smoothly, only to find an error at the last of compile. See the log below, which records the last part of compile. Running DRC. WARNING:PhysDesignRules:367 - The signal > is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal > is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal > is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal > is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal > is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal > is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal > is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:367 - The signal is incomplete. The signal does not drive any load pins in the design. WARNING:PhysDesignRules:1441 - Issue with pin connections and/or configuration on block:>:. The IFFTYPE is DDR and the Q2 output pin of IFF is not used. WARNING:PhysDesignRules:1441 - Issue with pin connections and/or configuration on block:>:. The IFFTYPE is DDR and the Q2 output pin of IFF is not used. WARNING:PhysDesignRules:1441 - Issue with pin connections and/or configuration on block:>:. The IFFTYPE is DDR and the Q2 output pin of IFF is not used. WARNING:PhysDesignRules:1441 - Issue with pin connections and/or configuration on block:>:. The IFFTYPE is DDR and the Q2 output pin of IFF is not used. WARNING:PhysDesignRules:1441 - Issue with pin connections and/or configuration on block:>:. The IFFTYPE is DDR and the Q2 output pin of IFF is not used. WARNING:PhysDesignRules:1441 - Issue with pin connections and/or configuration on block:>:. The IFFTYPE is DDR and the Q2 output pin of IFF is not used. WARNING:PhysDesignRules:1441 - Issue with pin connections and/or configuration on block:>:. The IFFTYPE is DDR and the Q2 output pin of IFF is not used. WARNING:PhysDesignRules:1441 - Issue with pin connections and/or configuration on block:>:. The IFFTYPE is DD
Re: [casper] How to use the qdr_transpose and qdr_ct blocks?
Hi Chenwei,
A couple of general comments --
1. strictly speaking you should have xilinx "gateway out" blocks between
the slice blocks and the scope, since the scope needs simulink (not xilinx)
data types as input. Having said that, it'll probably work the way you have
the design set up, it might issue warnings though.
2. Block sizes of 2^2 probably work, but I'd recommend testing with
something a little bigger in case there are some special cases which stop
the small block size from behaving as expected.
Now to explain (hopefully!) your results --
The qdr transpose is really a reorder, that is, no rearrangement of the
bits within the 36- bit words you're writing will ever take place. Thus, if
the bottom 18 bits going in are always 2, the bottom bits of the output
will also always be 2.
It is a transpose in the sense that as each word comes in, it is written
row by row in to a matrix with in_block_size columns, and out_block_size
rows. It is then reordered such that it is read out column by column.
Some hastily written python code showing how the output is related to the
input (which may or may not be helpful):
import pylab
in_block_size = 2**3
out_block_size = 2**4
n_cycles = 4 #cycles to plot
in_vec = range(in_block_size) * out_block_size * n_cycles
out_vec = [0 for i in range(len(in_vec))]
print 'in', in_vec
for i in range(n_cycles):
offset = i*in_block_size*out_block_size
for col in range(in_block_size):
for row in range(out_block_size):
out_vec[offset + row + col*out_block_size] = in_vec[offset + col +
row*in_block_size]
print 'out:', out_vec
pylab.subplot(2,1,1)
pylab.title('in')
pylab.plot(in_vec)
pylab.subplot(2,1,2)
pylab.title('out')
pylab.plot(out_vec)
pylab.show()
I'm not sure I can entirely explain the output you get. (Ignoring the '2'
in your LSBs, the block input is [0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2, ...]
For an input and output block size of 4, [i think] the output should be:
[0, 4, 0, 4, 1, 5, 1, 5, 2, 6, 2, 6, 3, 7, 3, 7, ].
It doesn't seem to be quite that so I would suggest that either blocks that
small don't work or (perhaps more likely) something is up with your
sync-ing. If you look inside the block, you'll see a reorder, with text
saying 'order=3' or something like that (it is dependent on the qdr
transpose parameters you've chosen. Note, if you change the 'double buffer'
parameter of that block to 1, it will always have an order of 2, which can
be useful). Your sync period needs to be a multiple of both the matrix size
(in your case, 4*4 = 16 cycles) and also the number of reorder orders. Eg,
a multiple of 16*3 = 48 cycles. (see
https://casper.berkeley.edu/memos/sync_memo_v1.pdf for more info on sync
pulses and their pitfalls). I would suggest, for testing, that you input
only a single sync into the block, at least until you are familiar with
it's working.
Cheers, (and hope that helps!)
Jack
On Fri, 24 Apr 2015 at 15:19 Chenwei Cai wrote:
> Thanks Jack and Dan.
>
> Regarding the qdr_transpose block, I am still confused. I have set up some
> simple models to figure out how this block works, but they just lead me to
> a greater confusion.
>
> One of the models is like this:
> https://www.dropbox.com/s/dwhukesqqhdgllf/Screenshot%20from%202015-04-24%2018%3A26%3A33.png?dl=0
> .
> The parameters of the counter are
> https://www.dropbox.com/s/hboym3amfbrcom9/Screenshot%20from%202015-04-24%2018%3A26%3A51.png?dl=0
> .
> And the parameters of the qdr_transpose block are
> https://www.dropbox.com/s/o9ke9wpur5bucwt/Screenshot%20from%202015-04-24%2018%3A27%3A20.png?dl=0
> .
>
> What I expect to do is to transpose the matrix like this
> https://www.dropbox.com/s/cogwtc3sk0cnuem/Screenshot%20from%202015-04-24%2019%3A09%3A27.png?dl=0.
> I have no idea whether the model is doing the same thing as I expect it to
> finish, since the execution of the simulation results in this
> https://www.dropbox.com/s/c28ya7koy5nyisi/Screenshot%20from%202015-04-24%2018%3A21%3A52.png?dl=0
> in
> the scope, which seems quite chaotic and intractable.
>
> I hope you can give me some more details on how to use the qdr_transpose
> block. Thanks!
>
>
>
>
> On Thu, Mar 26, 2015 at 4:38 PM, Chenwei Cai
> wrote:
>
>> Dear CASPER,
>>
>> My name is Chenwei Cai, and I am constructing the Mega-Channel
>> Spectrometer with ROACH II. To achieve that, two corner turners are
>> required before we implement FFTs, which means I may use qdr_transpose or
>> qdr_ct blocks. Since I cannot find any explanations on these blocks
>> anywhere, could you provide me some details about the functions of these
>> two blocks and what kind of data do those ports receive/export?
>>
>> Look forward to hearing from you!
>>
>> --
>> Best Regards
>> Chenwei CAI
>>
>> Mobile: +86-152-0147-9411
>> Email: caichenwei1...@pku.edu.cn
>>
>>
>
>
> --
> Best Regards
> Chenwei CAI
>
> Mobile: +86-152-0147-9411
> Email: caichenwei1...@pku.edu.cn
>
>
Re: [casper] How to use the qdr_transpose and qdr_ct blocks?
Thanks Jack and Dan. Regarding the qdr_transpose block, I am still confused. I have set up some simple models to figure out how this block works, but they just lead me to a greater confusion. One of the models is like this: https://www.dropbox.com/s/dwhukesqqhdgllf/Screenshot%20from%202015-04-24%2018%3A26%3A33.png?dl=0 . The parameters of the counter are https://www.dropbox.com/s/hboym3amfbrcom9/Screenshot%20from%202015-04-24%2018%3A26%3A51.png?dl=0 . And the parameters of the qdr_transpose block are https://www.dropbox.com/s/o9ke9wpur5bucwt/Screenshot%20from%202015-04-24%2018%3A27%3A20.png?dl=0 . What I expect to do is to transpose the matrix like this https://www.dropbox.com/s/cogwtc3sk0cnuem/Screenshot%20from%202015-04-24%2019%3A09%3A27.png?dl=0. I have no idea whether the model is doing the same thing as I expect it to finish, since the execution of the simulation results in this https://www.dropbox.com/s/c28ya7koy5nyisi/Screenshot%20from%202015-04-24%2018%3A21%3A52.png?dl=0 in the scope, which seems quite chaotic and intractable. I hope you can give me some more details on how to use the qdr_transpose block. Thanks! On Thu, Mar 26, 2015 at 4:38 PM, Chenwei Cai wrote: > Dear CASPER, > > My name is Chenwei Cai, and I am constructing the Mega-Channel > Spectrometer with ROACH II. To achieve that, two corner turners are > required before we implement FFTs, which means I may use qdr_transpose or > qdr_ct blocks. Since I cannot find any explanations on these blocks > anywhere, could you provide me some details about the functions of these > two blocks and what kind of data do those ports receive/export? > > Look forward to hearing from you! > > -- > Best Regards > Chenwei CAI > > Mobile: +86-152-0147-9411 > Email: caichenwei1...@pku.edu.cn > > -- Best Regards Chenwei CAI Mobile: +86-152-0147-9411 Email: caichenwei1...@pku.edu.cn
Re: [casper] How to use the qdr_transpose and qdr_ct blocks?
hi chenwei, i don't know of anyone who has developed a megachannel spectrometer for roach2, so i hope you can share your design with the casper community. here are three designs that you might find useful: 1) south africa develeped a mega channel spectrometer for roach1 : perhaps you can adapt their design ? 2) we developed a 128 million channel spectrometer for the bee2. info at https://casper.berkeley.edu/wiki/SETI_Spectrometer this 128 million channel spectrometer uses 3 steps a) course channelization (PFB) b) corner turn c) fine channelization on each course channel (FFT) 3) the old serendip3 and serendip4 spectrometers implemented a large FFT by implementing small FFT's on rows and columns, after putting the time domain vector into a 2D matrix, and applying these six signal processing steps: a) permute (either bit reverse or transpose) b) FFT each row c) permute (either bit reverse or transpose) d) apply complex twiddle factors to each element in matrix e) FFT each row f) permute (either bit reverse or transpose) best wishes, dan On Thu, Mar 26, 2015 at 12:38 PM, Chenwei Cai wrote: > Dear CASPER, > > My name is Chenwei Cai, and I am constructing the Mega-Channel > Spectrometer with ROACH II. To achieve that, two corner turners are > required before we implement FFTs, which means I may use qdr_transpose or > qdr_ct blocks. Since I cannot find any explanations on these blocks > anywhere, could you provide me some details about the functions of these > two blocks and what kind of data do those ports receive/export? > > Look forward to hearing from you! > > -- > Best Regards > Chenwei CAI > > Mobile: +86-152-0147-9411 > Email: caichenwei1...@pku.edu.cn > >
Re: [casper] How to use the qdr_transpose and qdr_ct blocks?
Hi Chenwei, I'm not sure about the qdr corner turn block, but the qdr transpose is fairly simple. It has two parameters, "input block size", and "output block size". The first is the number of channels in the fft input stream, the second is the number of spectra you want to buffer and transpose. I.e. the number of consecutive samples of each channel you want the block to output. For the million channel spectrometer, I expect you'd want something like: 2**11 point (real) fft (2**10 channels output) -> Qdr transpose, input size = output size = 10. -> 2**10 point complex fft. On roach 2, the inputs and outputs of the qdr transpose data streams are 72 bits wide. As with the other Casper blocks, there's also the usual boolean sync pulse which should be input the clock before the first sample in a transpose is input, and will be output the clock before this sample arrives on the data output port. Hope that helps, Jack On Thu, 26 Mar 2015 7:38 pm Chenwei Cai wrote: > Dear CASPER, > > My name is Chenwei Cai, and I am constructing the Mega-Channel > Spectrometer with ROACH II. To achieve that, two corner turners are > required before we implement FFTs, which means I may use qdr_transpose or > qdr_ct blocks. Since I cannot find any explanations on these blocks > anywhere, could you provide me some details about the functions of these > two blocks and what kind of data do those ports receive/export? > > Look forward to hearing from you! > > -- > Best Regards > Chenwei CAI > > Mobile: +86-152-0147-9411 > Email: caichenwei1...@pku.edu.cn > >
