By adding the files I sent this morning, the DAC_mkid & ADC_mkid yellow block will be able to work with ROACH (no more missing file).
Ran > The yellowblocks for the TI DAC part is in xps_library/DACs. I added > (but didn't write) the blocks to the main CASPER SVN maybe 2 weeks > ago, but did not do any testing as I don't have access to either > board. Both blocks are bare bones and contain no simulation > interfaces, but they are ROACH compatible. > > Ran, do you know which files are (still) missing? > > -Suraj > > On Mar 26, 2010, at 8:59 AM, rd...@caltech.edu wrote: > >> Hi Steve, >> >> we have been using DAC_MKID (also ADC_MKID) for a while, the chip is >> TI >> DAC5681. >> there are 2 chips (2 analog output) on the DAC board, each analog >> output >> is controlled by 2 digital input(16 bits, Signed). and full range of >> digital input to the DAC, will give analog output 0.9Vpp. >> >> I found there are missing files in in the library svn to support these >> blocks. >> I attached those files here, you need to copy and paste those file >> into the >> >> /mlib_devel_10_1/xps_lib/XPS_ROACH_base/pcores/ >> >> >> It will be nice if someone can update it on the website. >> >> >> Thanks, >> Ran >> >> >>>>> 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 <jasonman...@gmail.com >>>>> > >> 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 >>>>>>>> <jasonman...@gmail.com> 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 >>>>>>>>> <jasonman...@gmail.com> 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 < >>>>>> mwag...@eecs.berkeley.edu >>>>>>>>>>> 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 >>>>>>>>>> <stephen.f.ma...@nasa.gov> wrote: >>>>>>>>>> Hi Jason, >>>>>>>>>> >>>>>>>>>> Thanks for the reply. >>>>>>>>>> >>>>>>>>>> On Sun, Mar 14, 2010 at 12:10 PM, Jason Manley >>>>>>>>>> <jasonman...@gmail.com> 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> >>>>>>> >>> >>> >>> >>> >> >> >> <mkid_dac_adc_block.zip> > >
