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>
