Hi Wang This error occurs when you have a data bus and are trying to use part of it that does not exist. This means that a Slice block is expecting a wider data bus than your design is giving it. For the FFT it may be that the shift input does not have the correct width, or possibly your data bus. (The signal going into shift must have a bit for every FFT stage e.g for a 2^10 point FFT, there must be at least 10 bits).
If you go to 'Edit'->'Signals and Ports' and turn on the 'Port Data Types' option, you will be able to see what width your data buses are. Regards Andrew On Fri, Feb 13, 2015 at 1:29 AM, Wang Jinqing <jqw...@shao.ac.cn> wrote: > Hello, > > I have tried to the complex FFT core . During the simulation,the system > generator give out the error as below: > Slice endpoints must lie between the LSB and MSB > Error occurred during "Rate and Type Error Checking". Maybe the input now > is not correct,because I have connect the real_pfb's output to the complex > FFT directory.Can it work well? But I don't kown how to fix. > > I have set the FFT's parameters as the fft_setting.jpg appendix. > > Best Regards. > > Oliver Wang > > > -----原始邮件----- > > 发件人: casper-requ...@lists.berkeley.edu > > 发送时间: 2015年2月13日 星期五 > > 收件人: casper@lists.berkeley.edu > > 抄送: > > 主题: casper Digest, Vol 87, Issue 8 > > > > Send casper mailing list submissions to > > casper@lists.berkeley.edu > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://calmail.berkeley.edu/manage/list/listinfo/casper@lists.berkeley.edu > > > > or, via email, send a message with subject or body 'help' to > > casper-requ...@lists.berkeley.edu > > > > You can reach the person managing the list at > > casper-ow...@lists.berkeley.edu > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of casper digest..." > > > > > > Today's Topics: > > > > 1. VHDL black-boxing (lack of existing documentation) (James Smith) > > 2. Error with mmcm (Nishanth Shivashankaran) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Thu, 12 Feb 2015 11:34:39 +0200 > > From: James Smith <jsm...@ska.ac.za> > > Subject: [casper] VHDL black-boxing (lack of existing documentation) > > To: casper@lists.berkeley.edu > > Message-ID: > > <CAG67D36=abxtvfgo4x82e9yp6_yfzkppjewoszqukvsrtph...@mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Hello all, > > > > > I've been trying to move away from such big heavy models, my ultimate goal > > > being to have VHDL black boxes instead of precompiled ones made from Xilinx > > or Casper DSP blocks. > > > > Jack Hickish's HDL Black Box Tutorial ( > > https://casper.berkeley.edu/wiki/Tutorial_HDL_Black_Box) demonstrates a > > > very simple example of this, but I wanted something which could be a little > > > bit more dynamic, e.g. in terms of bit-widths for a given input. I started > > with a simple D-flip-flop block, which would automatically size itself > > according to what was put in at the input. Eventually I got it right. > > > > This is my VHDL code (important points noted with #### - these aren't > > obvious from the above tutorial): > > > ################################################################################# > > library IEEE; > > use IEEE.std_logic_1164.all; > > > > entity d_flip_flop_nbit is > > generic (n_bits: positive); ##### > > port (D : in std_logic_vector(n_bits - 1 downto 0); #### > > clk, ce: in std_logic; > > Q : out std_logic_vector(n_bits - 1 downto 0)); #### > > end d_flip_flop_nbit; > > > > architecture behav of d_flip_flop_nbit is > > begin > > > > dffn: process (clk) > > begin > > if (rising_edge(clk)) then > > Q <= D; > > end if; > > end process dffn; > > > > end behav; > > > ################################################################################# > > > > This is the accompanying config M-file: > > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > function d_flip_flop_nbit_config(this_block) > > this_block.setTopLevelLanguage('VHDL'); > > this_block.setEntityName('d_flip_flop_nbit'); > > this_block.addSimulinkInport('D'); > > this_block.addSimulinkOutport('Q'); > > > > % ----------------------------- > > if (this_block.inputTypesKnown) > > > > > this_block.addGeneric('n_bits','positive',num2str(this_block.port('D').width)); > > %%%%% > > > > %Sysgen user guide specifies these lines of code but Matlab doesn't > > like them. Apparently > > %the functions referred don't actually exist. What I have below is a > > bit of a hack but it worked. > > % q_port = this_block.port('Q'); > > % q_port.setWidth = this_block.port('D').width; > > % q_port.setBinPt(0); > > % q_port.makeUnsigned(); > > > > q_port = this_block.port('Q'); > > q_port_string = > > strcat('Ufix_',num2str(this_block.port('D').width),'_0'); %%%%% > > q_port.setType(q_port_string); > > > > end % if(inputTypesKnown) > > % ----------------------------- > > > > % ----------------------------- > > if (this_block.inputRatesKnown) > > setup_as_single_rate(this_block,'clk','ce') > > end % if(inputRatesKnown) > > % ----------------------------- > > > > uniqueInputRates = unique(this_block.getInputRates); > > > > this_block.addFile('d_flip_flop_nbit.vhd'); > > > > return; > > % ------------------------------------------------------------ > > > > function setup_as_single_rate(block,clkname,cename) > > inputRates = block.inputRates; > > uniqueInputRates = unique(inputRates); > > if (length(uniqueInputRates)==1 & uniqueInputRates(1)==Inf) > > block.addError('The inputs to this block cannot all be constant.'); > > return; > > end > > if (uniqueInputRates(end) == Inf) > > hasConstantInput = true; > > uniqueInputRates = uniqueInputRates(1:end-1); > > end > > if (length(uniqueInputRates) ~= 1) > > > block.addError('The inputs to this block must run at a single rate.'); > > return; > > end > > theInputRate = uniqueInputRates(1); > > for i = 1:block.numSimulinkOutports > > block.outport(i).setRate(theInputRate); > > end > > block.addClkCEPair(clkname,cename,theInputRate); > > return; > > % ------------------------------------------------------------ > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > > > I searched fairly extensively through the archive, and I saw no > > documentation of this. The Xilinx documentation helped a bit, but > > discrepancies between it and what Matlab would actually accept caused me > > many headaches. In the end I found the workaround above which seemed to > > work, but I'll admit I don't like it very much. > > > > > Is anyone else working in this sort of an environment? Is there any reason > > that VHDL / Verilog seems to have been abandoned in favour of the > > Simulink-based block approach? Would anyone find it helpful if the > > tutorials were expanded a bit with this kind of information? > > > > Regards, > > James > > -------------- next part -------------- > > An HTML attachment scrubbed and removed. > > HTML attachments are only available in MIME digests. > > > > ------------------------------ > > > > Message: 2 > > Date: Thu, 12 Feb 2015 11:41:40 -0700 > > From: Nishanth Shivashankaran <nshiv...@asu.edu> > > Subject: [casper] Error with mmcm > > To: Casper Lists <casper@lists.berkeley.edu> > > Message-ID: > > <cabrsghjwxdwdv+pbp9ga3x4+fw0espbvg1nw7qmz6zky0gs...@mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Hi All, > > > > I am trying to create a yellow block for the roach2 with the MUSIC > > adc/dac, I replaced the DCM with the MMCM. I compiled the DAC and ADC > > > portion separately. The DAC portion seems to work without any errors and I > > was able to put out tones and i visually saw it on the spectrum analyzer > > > but the ADC portion is giving me some compilation error with the same clock > > > frequency. I am using the same set of multipliers and dividers as the DAC. > > > the error message says the ngdbuild is changing multipliers and dividers. I > > am wondering if anyone can help me with this problem. > > > > ERROR:LIT:667 - Block 'MMCM_ADV symbol > > > > > "physical_group_tut3_r2_adcdac_512_adc_mkid/tut3_r2_adcdac_512_adc_mkid/dcm_c > > lk/tut3_r2_adcdac_512_adc_mkid/tut3_r2_adcdac_512_adc_mkid/MMCM_adc"' > > has its > > target frequency, FVCO, out of range. Valid FVCO range for speed grade > > "-1" > > is 600MHz - 1200MHz. The computed FCVO is a function of the input > > frequency > > > CLKIN1_PERIOD, the division factor DIVCLK_DIVIDE, and the CLKFBOUT_MULT_F > > attribute (FVCO = 1000*CLKFBOUT_MULT_F/(CLKIN1_PERIOD*DIVCLK_DIVIDE)). > > The > > CLKIN_PERIOD attribute may have been set by ngdbuild based on the user > > specified PERIOD constraint. The current calculated FVCO is 512.032770 > > MHz. > > Reference the V6 architecture Users Guide or search the Xilinx Answer > > Records > > database for the error code. > > Errors found during logical drc. > > > > thanks > > Nishanth Shivashankaran > > -------------- next part -------------- > > An HTML attachment scrubbed and removed. > > HTML attachments are only available in MIME digests. > > > > End of casper Digest, Vol 87, Issue 8 > > ************************************* > > > >
