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? =} 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> > > > > > >
