I "fixed" the 'dac' block by breaking the link with the library and
removing 4 'assert' blocks sitting between converters and gateways.
Then my compatibility question was partially answered I guess when I
got an inconsistent hardware error saying 'dac' only supports iBOB.
Should I be heading down the line of doing my own dac controlling on the
ROACH?
Steve
On Fri, Mar 26, 2010 at 11:04 AM, Steve Maher <[email protected]
<mailto:[email protected]>> wrote:
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]
<mailto:[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] <mailto:[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] <mailto:[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 <http://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] <mailto:[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]
<mailto:[email protected]>> wrote:
>> > > Hi Jason,
>> > >
>> > > Thanks for the reply.
>> > >
>> > > On Sun, Mar 14, 2010 at 12:10 PM, Jason Manley
>> > > <[email protected] <mailto:[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>
>
