ASTRO lib won't work with the 9.1 tools :-(
7.1 will only work with Matlab R14 :-(
If you want to feed the 1:4 demuxed ADC data directly into the
PFB_FIR, then you need the wideband version. You'll notice in the
Medicina packetised F engine that we're using a DDC up front which
extracts 1/4 of the band (hence only one complex input to the PFB_FIR).
Are you trying to do an FFT on a real-sampled signal (in this case
pick the pfb_wideband_real and set the number of simultaneous inputs
to 2^2 and feed in the four real signals from the ADC), or are you
doing complex sampling on the ADC's Q/I inputs with a 90deg out of
phase clock sampling each input? There are different versions of the
PFB_FIR for each situation.
Jason
On 03 Feb 2009, at 13:07, Jan Wagner wrote:
Thanks for all the tips.
I think the situation is worse. The main problem is I'm trying to
use the astro_library with Xilinx 9.1i + Matlab R2006b.
Apparently I just should not do that. Everything seems to fall
apart, fix one thing and the next part breaks even worse :-/ We
managed to get Xilinx 7.1i (maybe it works with Matlab R2006b... in
my dreams...). Hopefully under 7.1i the design will work out-of-box.
The main underlying issue however, why I want to test the other
designs, is that I don't really understand how the Casper PFB FIR
works.
It is polyphase, yet accepts only one complex 8-bit input sample. I
can't find the polyphase R=4 decimating FIR that would seem natural
for the 1:4 muxed ADC converter. Perhaps have to configure the
Casper PFB for 2 x complex input, feed the 4 I-channel ADC samples
directly in, and then manually sum the 4 outputs?
- Jan
On Mon, 2 Feb 2009, G Jones wrote:
I've come across these problems occasionally as an uncaught
exception in the yellow block initialization scripts, usually
related to something like selecting the wrong platform, or not
having the platforms set up correctly. Unfortunately, I don't have
more details, but if you trace through the execution of the mask
file, you can usually figure out what's going on.
On Mon, Feb 2, 2009 at 4:47 AM, Jason Manley
<[email protected]> wrote:
Hmmm... This looks like a Matlab problem rather than an issue
with the design. Make sure there are no non-terminated lists (eg
[1,2,3,4 without the closing bracket). I don't
see this issue on my side. You're definitely running the
recommended version of Matlab? I've seen a similar error if SP2 is
not installed.
Jason
On 02 Feb 2009, at 12:14, Jan Wagner wrote:
Hi Jason,
On Mon, 2 Feb 2009, Jason Manley wrote:
The IBOB (F engine) component uses the ASTRO library,
but the BEE2 (X engine) part uses the CASPER library. Thus, for for
the model file containing the
DRAM_VACC, you should be compiling it with CASPER library.
Hmm I had to double-check, the i_r303_med_1.mdl that I try to
compile does have the iBob selected as platform under XSG core
config.
But yep I had the paths wrong, Casper was not excluded from
the paths, loaded both at the same time! Ups...!
Thanks, after fixing this, there are no complaints about DRAM
any more. So some progress!
A new issue cropped up, now the i_r303_med_1.mdl doesn't yet
"compile" due to this:
Problem with block: i_r303_med_1/dbuf_ct_sram/sram
Index exceeds matrix dimensions.
Maybe i'll figure it out though...
Thanks!
- Jan
Also, do not load the CASPER and ASTRO libraries at the
same time. There are conflicting function calls with the same name
which do different things.
I have just successfully compiled both the BEE2 and IBOB
medicina designs using the standard 7.1 libraries. You should only
need address_gen_vacc_v2_mask for
the DRAM_VACC's address generation block.
Jason
On 30 Jan 2009, at 20:55, Jan Wagner wrote:
Hi,
i wanted to compile the recent projects from SVN
trunk (because i had some hobby ideas for reusing these), e.g.
medicina correlator
http://casper.berkeley.edu/svn/trunk/projects/medicina_correlator/
but they all fail.
The problem is (afaict) that they use the
deprecated astro library. And the astro library reorder_library.mdl
wants mask
address_gen_dram_mask_temp.m, but the only one
available is address_gen_dram_mask.m, and the names etc used in
this one do not match those in the
.mdl so it breaks -- addr_gen_DRAM ends up with
floating internal connections.
Could someone please upload the
address_gen_dram_mask_temp.m ?
- Jan
