>> The 'dac' yellow block _does include a gateway internally. I believe >> the >> error is referring to the input data lines, but I haven't figured it out >> yet. But I may be barking up the wrong tree because I'm trying to >> control >> the DAC2x1000-16 (TI DAC5681) DAC - included with our ROACH - but the >> (mask) >> description for block 'dac' is "Interface to SiBeam single Atmel >> TS86101G2B >> DAC board". Will this work with the DAC2x1000-16? >> >> I found the 'dac_mkid' block but am struggling trying to find input >> descriptions, etc. There's no author info in the code in >> xps_library/@xps_dac_mkid/*. Is hunting down the authors via SVN >> checkins >> appropriate - or perhaps I just keep bugging the mailing list? =}
If the atmel 86101G2B chip isn't the same as the TI DAC5681 chip, then it's doubtful. mkid sounds like kinetic inductance detector stuff. Maybe a clue there as to the originator of the code. John > > If you already did what Jason suggested, another thing is that you have to > have some clocked circuit in there as well. Maybe just a simple counter > driving an LED or something that won't get optimized out. > > John > >> >> Steve >> >> >> >> On Thu, Mar 25, 2010 at 5:38 PM, Jason Manley <[email protected]> >> wrote: >> >>> The "sim_out" ports on yellow blocks should include this gateway >>> internally, so this gateway block should not be necessary. >>> >>> Your rate errors are probably caused by the fact that you haven't set >>> an explicit sampling rate for the constants. Simulink tries to >>> propagate these sample rates to other blocks down the chain. Since the >>> constants have no inputs, they have nothing from which to infer the >>> sample rate. Just set it to be a sampled constant with a period of "1" >>> on all the constants blocks. >>> >>> Jason >>> >>> >>> >>> On 25 Mar 2010, at 14:24, Nevada Sanchez wrote: >>> >>> > Whenever you connect an FPGA block (something that becomes >>> > synthesized in hardware) to a simulink block (like a scope) you need >>> > to use the Gateway In/Out blocks in the Xilinx blockset. Try >>> > dropping a Gateway Out in between the DAC and the scope. >>> > >>> > -Nevada >>> > >>> > On Mar 25, 2010, at 17:20 PM, Steve Maher wrote: >>> > >>> >> After some major install/downgrade/upgrade gyrations I was able to >>> >> run the basic roach tutorial - yes! - thanks for the help. >>> >> >>> >> However, my first solo model produced two errors from different >>> >> "sources" (console vs. dialog). See highlights in attached image. >>> >> >>> >> Since this is the first time I've ever written any FGPAish type >>> >> thingy (I'm usually coding Java), I've certainly done something >>> >> stupid. But my usual debugging skills are diminished when >>> >> presented with two different errors. Are they just two separate >>> >> errors? Which one should I address first? Any great location to >>> >> explain the errors in more detail? >>> >> >>> >> Thanks for any advice, >>> >> Steve >>> >> >>> >> p.s., the converters are outputting 9_8, which I believe is what is >>> >> needed by dac inputs >>> >> >>> >> On Mon, Mar 15, 2010 at 12:38 PM, Jason Manley >>> >> <[email protected]> wrote: >>> >> Actually, the most stable flow right now (at least I've found) is >>> >> Windows XP 32-bit with 10.1.3.1386 and Matlab R2007b. This is what I >>> >> would recommend. >>> >> >>> >> I'm still investigating the 11.x flow on Linux. It's not ready for >>> >> prime-time yet: I sometimes have Matlab disappearing on me, compiles >>> >> that sometimes take significantly longer (22hrs), ridiculous memory >>> >> usage (over 16GB) etc etc. >>> >> >>> >> Jason >>> >> >>> >> On 15 Mar 2010, at 09:29, Steve Maher wrote: >>> >> >>> >> > >>> >> > >>> >> > On Mon, Mar 15, 2010 at 11:55 AM, Jason Manley >>> >> > <[email protected]> wrote: >>> >> > Wow, you're having a really tough time with the toolflow setup! We >>> >> > normally insist that you use the recommended versions >>> >> > >>> >> > Actually, we're trying to get a quick proof of concept, so what >>> are >>> >> > the recommended versions? >>> >> > >>> >> > FYI, this >>> >> > http://casper.berkeley.edu/wiki/Xilinx_ISE_11.4_Setup >>> >> > uses XIlinx 11.4 and I've have had a tough time finding at >>> >> > xilinx.com. Latest download is 11.1 and then upgrade is to 11.5. >>> >> > >>> >> > I guess I should back down to 10.1, per the following >>> >> > http://casper.berkeley.edu/wiki/MSSGE_Toolflow_Setup >>> >> > >>> >> > I'm guessing you would recommend Linux over Windows, right? >>> >> > >>> >> > Thanks, >>> >> > Steve >>> >> > >>> >> > >>> >> > to avoid these >>> >> > troubles, but let's continue down the debuggin' path and see >>> >> where it >>> >> > leads... >>> >> > >>> >> > First, a little explanation: The "gcs" block stands for "Get >>> >> Current >>> >> > System" and is there so that if by accident you started bee_xps >>> >> while >>> >> > having some subsystem in the foreground (and hence bee_xps thought >>> >> > that's what you were trying to compile) that you could correct it >>> >> by >>> >> > selecting the top level window (the one with the SysGen icon) and >>> >> > press this button. The text window to the left shows the design >>> >> you're >>> >> > trying to compile. It should show your top-level model name and >>> >> there >>> >> > should be no spaces or slashes and it should not start with a >>> >> capital >>> >> > letter. As far as I can tell from your logs, this is set correctly >>> >> > already. So you would not have seen any change when pressing the >>> >> gcs >>> >> > button. >>> >> > >>> >> > It seems you have a problem with sampled values. Everything >>> >> within the >>> >> > sysgen domain should have a sample period set to "1". Any source >>> >> > blocks need to have this set explicitly, but subsequent blocks can >>> >> > infer the sample period from their input signals. However, this in >>> >> > itself should not cause an error, so I'll ignore it for now. >>> >> > >>> >> > Since your modified bee_xps.m has different line numberings, I >>> >> can't >>> >> > make out where it's failed. Line 337 is near to a callback to >>> >> copy the >>> >> > basesystem. If it's breaking here, then probably either >>> >> > 1) xcopy (on windows; linux uses copy command with >>> different >>> >> > arguments) is not there or not functional (try typing xcopy on the >>> >> > command prompt) or, >>> >> > 2) your environment variables are not setup correctly to >>> >> > point to the >>> >> > base systems. We usually do this in a batch file that's used to >>> >> start >>> >> > matlab (appended below). Specifically, you will need the following >>> >> > Windows environment variables set: >>> >> > MLIB_ROOT pointing to the directory where the >>> >> > bee_library, and >>> >> > xps_library directories are located. (eg MLIB_ROOT=c:\casper_svn >>> >> > \mlib_devel_10_1) >>> >> > BEE2_XPS_LIB_PATH pointing to the xps_lib >>> >> directory >>> >> > (eg >>> >> > BEE2_XPS_LIB_PATH=%MLIB_ROOT%\xps_lib) >>> >> > Jason >>> >> > >>> >> > start_matlab.bat: >>> >> > >>> >> > set MATLAB=C:\Programs\MATLAB2007b >>> >> > set XILINX=C:\Xilinx\ISE10.1\ISE >>> >> > set XILINX_EDK=C:\Xilinx\EDK10.1\EDK >>> >> > set MLIB_ROOT=C:\casper_svn\mlib_devel_10_1 >>> >> > set BEE2_XPS_LIB_PATH=%MLIB_ROOT%\xps_lib >>> >> > set RCS_BIN="C:\Program Files\TortoiseSVN\bin" >>> >> > set PATH=%RCS_BIN%;%PATH% >>> >> > >>> >> > set PATH=%XILINX%\bin\nt;%XILINX_EDK%\bin\nt;%PATH%; >>> >> > >>> >> > %MATLAB%\bin\win32\matlab.exe >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > On 15 Mar 2010, at 06:56, Steve Maher wrote: >>> >> > >>> >> > > Hi, >>> >> > > >>> >> > > Further, but still failure. >>> >> > > >>> >> > > On Sun, Mar 14, 2010 at 6:14 PM, Mark Wagner < >>> [email protected] >>> >> > > > wrote: >>> >> > > Hi Steve, >>> >> > > >>> >> > > Try opening up the System Generator block and entering in 'd7' >>> in >>> >> > > the 'clock pin location' field. >>> >> > > >>> >> > > Okay, did it. >>> >> > > >>> >> > > I also changed Slice "Specify range as" from Upper to Lower, to >>> >> be >>> >> > > the same as the tutorial >>> >> > > >>> >> > > Then, make sure the highest level in your model file is >>> selected >>> >> > > and open bee_xps, >>> >> > > >>> >> > > I'm new to the terminology, but I believe I only have one level >>> >> in >>> >> > > my model, no? And for John Ford's comments, I also tried >>> >> > > 'selecting' System Generator block before running (which is a >>> >> little >>> >> > > askew of his comments, but the best I could do). >>> >> > > >>> >> > > click 'gcb' and make sure it still corresponds to your model >>> file >>> >> > > name, not a subsystem. >>> >> > > >>> >> > > I have only "gcs" on my BEE XPS 1.1. When I click it nothing >>> >> > happens. >>> >> > > >>> >> > > Then try running bee xps. >>> >> > > >>> >> > > >>> >> > > I get three warnings (which don't look fatal) and then failure >>> >> > > (output below). Looks like the error occurs in >>> >> xlGenerateButton but >>> >> > > I don't know where that code is. >>> >> > > >>> >> > > Also, are you using 'Use explicit sample period' of 1 in your >>> >> slice >>> >> > > block? If not, this might explain the error you're getting >>> >> with the >>> >> > > Slice and Counter. >>> >> > > >>> >> > > >>> >> > > This was already set correctly in the Counter block. >>> >> > > >>> >> > > Steve >>> >> > > >>> >> > > >>> >> > > Mark >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > Detected Unknown Unix-like OS >>> >> > > ############################# >>> >> > > ## System Update ## >>> >> > > ############################# >>> >> > > SFM DEBUG sys value: testborph >>> >> > > Warning: The model 'testborph' does not have continuous states, >>> >> > > hence Simulink is using the solver >>> >> > > 'VariableStepDiscrete' instead of solver 'ode45'. You can >>> disable >>> >> > > this diagnostic by explicitly >>> >> > > specifying a discrete solver in the solver tab of the >>> >> Configuration >>> >> > > Parameters dialog, or by setting >>> >> > > the 'Automatic solver parameter selection' diagnostic to 'none' >>> >> in >>> >> > > the Diagnostics tab of the >>> >> > > Configuration Parameters dialog >>> >> > > > In gen_xps_files at 208 >>> >> > > In bee_xps>run_Callback at 152 >>> >> > > In bee_xps at 84 >>> >> > > Warning: Inconsistent sample times. Sample time ([0, 1]) of >>> >> signal >>> >> > > driving input port 1 of >>> >> > > 'testborph/cnt_en/testborph_cnt_en_user_data_out' differs from >>> >> the >>> >> > > expected sample time ([1, 0]) at >>> >> > > this input port. >>> >> > > > In gen_xps_files at 208 >>> >> > > In bee_xps>run_Callback at 152 >>> >> > > In bee_xps at 84 >>> >> > > Warning: Using a default value of 0.2 for maximum step size. >>> The >>> >> > > simulation step size will be equal >>> >> > > to or less than this value. You can disable this diagnostic by >>> >> > > setting 'Automatic solver parameter >>> >> > > selection' diagnostic to 'none' in the Diagnostics page of the >>> >> > > configuration parameters dialog >>> >> > > > In gen_xps_files at 208 >>> >> > > In bee_xps>run_Callback at 152 >>> >> > > In bee_xps at 84 >>> >> > > ############################# >>> >> > > ## Block objects creation ## >>> >> > > ############################# >>> >> > > ###################### >>> >> > > ## Checking objects ## >>> >> > > ###################### >>> >> > > Running system generator ... >>> >> > > Error using ==> gen_xps_files at 337 >>> >> > > XSG generation failed: >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > On Sun, Mar 14, 2010 at 3:02 PM, Steve Maher >>> >> > > <[email protected]> wrote: >>> >> > > Hi Jason, >>> >> > > >>> >> > > Thanks for the reply. >>> >> > > >>> >> > > On Sun, Mar 14, 2010 at 12:10 PM, Jason Manley >>> >> > > <[email protected]> wrote: >>> >> > > Hi Steve >>> >> > > >>> >> > > Are you preloading the libraries? >>> >> > > >>> >> > > I am now =) >>> >> > > >>> >> > > I get a zillion warnings in the console (mostly about >>> >> parameterized >>> >> > > links) but I can now run XSG/XPS ... thanks. >>> >> > > >>> >> > > >>> >> > > >>> >> > > However, XSG fails when building the following tutorial (my >>> >> version >>> >> > > attached) >>> >> > > >>> >> > > http://casper.berkeley.edu/wiki/Roach_Tutorial >>> >> > > >>> >> > > I've included testborph_sysgen_error.log below, but the main >>> >> error >>> >> > > seems to be the following: >>> >> > > >>> >> > > All Xilinx Blocks must be contained in a level of hierarchy >>> >> with a >>> >> > > System Generator Token >>> >> > > >>> >> > > Obviously I do have a System Generator Token. Googling for the >>> >> > > error produced >>> >> > > http://www.xilinx.com/support/answers/24845.htm, but it's not >>> >> > > applicable. >>> >> > > >>> >> > > >>> >> > > Hmmm... >>> >> > > >>> >> > > Steve >>> >> > > >>> >> > > p.s. If I try running XPS a second time, Matlab/Simulink >>> crashes. >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > --------------------------------- Version Log >>> >> > > ---------------------------------- >>> >> > > Version Path >>> >> > > System Generator 11.5.2275 C:/Xilinx/11.1/ >>> >> DSP_Tools/nt/ >>> >> > > sysgen >>> >> > > AccelDSP 11.5.2275 C:/Xilinx/11.1/ >>> >> DSP_Tools/nt/ >>> >> > > AccelDSP >>> >> > > Matlab 7.9.0.529 (R2009b) C:/Program Files/MATLAB/ >>> >> > R2009b >>> >> > > ISE 11.4.i C:/Xilinx/11.1/ISE >>> >> > > >>> >> > >>> >> >>> -------------------------------------------------------------------------------- >>> >> > > Summary of Errors: >>> >> > > Error 0001: All Xilinx Blocks must be contained in a level of >>> >> > > hierarc... >>> >> > > Block: Unspecified >>> >> > > Error 0002: A summary of Sysgen errors has been written to C:/ >>> >> > > roachmo... >>> >> > > Block: >>> >> > > Error 0003: A summary of Sysgen errors has been written to C:/ >>> >> > > roachmo... >>> >> > > Block: >>> >> > > Error 0004: A summary of Sysgen errors has been written to C:/ >>> >> > > roachmo... >>> >> > > Block: 'testborph/Counter' >>> >> > > Error 0005: A summary of Sysgen errors has been written to C:/ >>> >> > > roachmo... >>> >> > > Block: 'testborph/Slice' >>> >> > > >>> >> > >>> >> >>> -------------------------------------------------------------------------------- >>> >> > > >>> >> > > Error 0001: >>> >> > > >>> >> > > Reported by: >>> >> > > Unspecified >>> >> > > >>> >> > > Details: >>> >> > > All Xilinx Blocks must be contained in a level of hierarchy >>> >> with a >>> >> > > System Generator Token >>> >> > > >>> >> > >>> >> >>> -------------------------------------------------------------------------------- >>> >> > > >>> >> > > Error 0001: >>> >> > > >>> >> > > Reported by: >>> >> > > >>> >> > > Details: >>> >> > > A summary of Sysgen errors has been written to C:/roachmodels/ >>> >> > > testborph_sysgen_error.log >>> >> > > >>> >> > >>> >> >>> -------------------------------------------------------------------------------- >>> >> > > >>> >> > > Error 0001: >>> >> > > >>> >> > > Reported by: >>> >> > > >>> >> > > Details: >>> >> > > A summary of Sysgen errors has been written to C:/roachmodels/ >>> >> > > testborph_sysgen_error.log >>> >> > > >>> >> > >>> >> >>> -------------------------------------------------------------------------------- >>> >> > > >>> >> > > Error 0001: >>> >> > > >>> >> > > Reported by: >>> >> > > 'testborph/Counter' >>> >> > > >>> >> > > Details: >>> >> > > A summary of Sysgen errors has been written to C:/roachmodels/ >>> >> > > testborph_sysgen_error.log >>> >> > > >>> >> > >>> >> >>> -------------------------------------------------------------------------------- >>> >> > > >>> >> > > Error 0001: >>> >> > > >>> >> > > Reported by: >>> >> > > 'testborph/Slice' >>> >> > > >>> >> > > Details: >>> >> > > A summary of Sysgen errors has been written to C:/roachmodels/ >>> >> > > testborph_sysgen_error.log >>> >> > > >>> >> > >>> >> >>> -------------------------------------------------------------------------------- >>> >> > > >>> >> > > >>> >> > > >>> >> > >>> >> > >>> >> >>> >> >>> >> <dacError.png> >>> > >>> >>> >>> >>> >> > > > >
