On 01 Apr 2008, at 13:43, John Ford wrote:
Hi,
On Fri, 15 Feb 2008, John Ford wrote:
Is there any ppc software already written for the ibob to set the
properties of the 10gbe block? The default software load just has a
tengbeinfo command, but nothing to set anything.
Yes, see:
This is odd... I recall that when we were playing with the pocket
spectrometers and pocket correlators, there was next-to-nothing below
10MHz. I never looked at a waveform view and just assumed that this
was because of poor low frequency response. It should be ok to sample
at 32msps - I've
I have never seen this before, and I am using all the user LEDs and
DIMM1 and DIMM2 in the correlator design.
On 10 Jul 2008, at 00:15, G Jones wrote:
Hello,
I am trying to route a design using DRAM and BEE2_usr:led GPIO and I
ran into the following PAR error:
ERROR:Place:17 - The placement
Hi guys
I fixed a bug in the EXEC command on the udp framework server for the
BEE2s today. The changed code and a compiled executable have been
checked-in to SVN.
Jason
Hi Oren
No, we currently don't have a multicast feature. If you do implement
it, I will certainly make use of it!
Regards,
Jason
On 15 Sep 2008, at 21:47, Oren Milgrome wrote:
Hi, I am trying to set up 10GBE multicasting with CASPER hardware and
would like to check if this feature is in
Create more coefficient generators and sprinkle them around inside the
PFB?
Sorry, I don't have Simulink with me, so can't offer more concrete
advice. But if the problem is with the fanout, why not create seperate
sources with smaller fanouts?
Jason
On 06 Nov 2008, at 15:46, John Ford
Yeah, and I eventually forfeited the FIFOs and used shared BRAMs
instead! Marc and myself have been chatting about this and I think the
behaviour of the shared FIFOs might change a little on ROACH to make
it more intuitive and easier to use.
Jason
On 19 Jan 2009, at 23:42, Andrew Siemion
Henry and/or Dave can correct me if I'm wrong, but my understanding
was that if you checked the use lightweight MAC box in the 10GbE
core, then it would instantiate the Berkeley core rather than the
Xilinx one. In this case you shouldn't need the Xilinx 10GbE core.
The underlying Berkeley
The KAT guys were complaining of a similar behaviour, but I can't say
I've ever experienced this myself and have been unable to reproduce
it. Is your problem repeatable?
Have you enabled the Load FPGA option in Impact?
Also check the MODE jumper settings on your IBOB. It shouldn't affect
If you're having issues with the parallel cable in Linux, the USB JTAG
cable DLC9G Platform Cable USB works fine in Linux.
Impact should not return success unless the transfer really was
successful. Apparently there's a CRC that is performed to confirm this.
Jason
On 28 Jan 2009, at
At this week's ROACH telecon it was reported that BORPH was not
working on ROACH. Thanks to Brandon Hamilton's efforts this morning,
BORPH on ROACH is back up and running.
We have a different kernel and root filesystem and are now able to
execute bof files on ROACH. Backups are being made
going on.
On Mon, Feb 2, 2009 at 4:47 AM, Jason Manley
jasonman...@gmail.com 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
Good news: I have successfully tested an IBOB sending data to a ROACH
over XAUI. The IBOB was using the Xilinx XAUI controller and the ROACH
was using Dave's opensource KATXAUI controller. It worked first-time
as expected.
It looks like we're another step closer towards PAPER's Australia
On 08 Apr 2009, at 09:44, David MacMahon wrote:
Hi, Andrew and Griffin,
Looks great overall! Here are a few suggestions (you asked for
them!)...
Clock selection and frequency specification have been a perennial
source of confusion on the ibobs. If the ADC is sampling at 800 MHz
and
to you before tomorrow.
Jason
On 25 May 2009, at 02:16, wan.ch...@csiro.au wan.ch...@csiro.au
wrote:
Hi Jason:
Any idea?
Thanks
Wan
-Original Message-
From: Cheng, Wan (ATNF, Marsfield)
Sent: Friday, 22 May 2009 4:48 PM
To: 'Jason Manley'
Cc: casper@lists.berkeley.edu
Subject: RE
: Jason Manley [mailto:jason_man...@hotmail.com]
Sent: Monday, 25 May 2009 4:35 PM
To: Cheng, Wan (ATNF, Marsfield)
Cc: casper@lists.berkeley.edu
Subject: Re: [casper] Roach issue: Stale NFS file handle error is
reported
We're looking into this. I think we might change things to be a little
less
For those of you with ROACH boards, here is a little utility for
querying the onboard Actel Fusion housekeeping/monitoring chip.
It's simply a python script that lets you view and control some of the
housekeeping functions over the network (through the Xport). If you've
never used the
([getenv('MLIB_ROOT'), '\gavrt_library\gavrt_library.mdl']);
Jason Manley
Digital Engineer
SKA-SA, KAT Pinelands office
Unit 12, Lonsdale Building
Lonsdale Road
Pinelands
7405
South Africa
Cell: +27 82 662 7726
Work: +27 21 531 7282
Fax: + 27 21 531 9761
On 10 Jun 2009, at 10:42, Mitchell
Hi CASPERites
As mentioned by Andrew a few days ago, KATCP is the preferred control
interface to ROACH. While the KATCP syntax and grammar is very well
defined, no official documentation currently exists describing the
ROACH-specific implementation of it. I have started a wiki page here:
Yeah, I'm guessing something didn't work right when you did the SVN
checkout. Try checking out a fresh copy to a local filesystem.
My checkout from this morning is fine.
Jason
On 19 Jun 2009, at 13:35, John Ford wrote:
Could you check your permissions of the original base system files
(ie
On 10GbEv2 it is 8192, plus UDP and IP headers etc. But there would be
no space for your application headers.
When we specc'd it originally, the thought here was that 8192b is the
closest power-of-2 for BRAM sizing to that same 9216b limit for most
NICs. If we wanted to get to 9000, we'd
Hi Robert
You are correct, the 10GbEv2 core is preferred for ROACH. It is faster
and has a smaller footprint.
Just yesterday I finished integrating Marc Welz's 10GbE driver and
updated tcpborphserver. This hides all the ARP/MAC address
configuration complexity, so you don't need to worry
There are 3 partitions on the BEE2 card:
FAT with the sysace file
EXT2 partition with the root filesystem
SWAP partition
You can create these partitions and then just copy the files across
from one to the other (make sure to copy everything including the /
dev/ nodes)
Jason
On 09 Jul
I took over development of the packetised correlator control package
~2 years ago. These later versions can be found on CASPER SVN, here: http://casper.berkeley.edu/svn/trunk/projects/packetized_correlator/
Aaron's original version is on this page, I think:
I compiled an 8192 channel FFT the other day no problems. But I have
not yet tried it on actual hardware.
Jason
On 27 Jul 2009, at 08:41, Jason Zheng wrote:
Last time I tried this on 10.1 with a 2^20 FFT design, the Matlab
froze for a long time and I ended up closing the program.
On Mon,
I suggest you try the 10.1. I no longer use the 7.1 libraries and
they're not under active development like the 10.1 libraries. There
have been numerous fixes to the 10.1 FFT to fix these and other
problems. There are still timing problems with 10.1, but the FFT is
working AFAIK.
My
Hi CASPERites
For those of you wanting to get started using 10GbE on ROACH, I have
written a demo application along with instructions on how to use it
here: http://casper.berkeley.edu/wiki/ROACH_10GbE_tutorial
In doing so, I discovered a bug in tcpborphserver which only allows
for a
Hi Suraj
Yes, I have had similar experiences. You have to close any open
connections yourself, else the (separate) thread with the open port
stays open, hanging the exit procedure. myroachobject.stop() does
this. Take a look at some of my scripts in the corr package to see an
example.
Thanks Simon
I have updated CORR's katcp wrapper to do this by default now.
Jason
On 05 Aug 2009, at 14:10, Simon Cross wrote:
Hi Jason and Suraj
On Wed, 2009-08-05 at 13:55 +0200, Jason Manley wrote:
Yes, I have had similar experiences. You have to close any open
connections yourself
KAT is targeting -27dBm.
I think PAPER is running even lower. We originally tried tried higher
levels, but the RFI environment at Green Bank forced us to drop the
level further because the inputs were regularly clipping.
Jason
On 18 Aug 2009, at 23:54, Matt Dexter wrote:
Hi Jonathan,
I
Hi John
I don't think anyone within CASPER core has actually tried the dual-
port cards. Fujitsu suggested that these were a bit of a waste,
because most computers are unable to swallow data from two 10GbE ports.
Jason
On 21 Aug 2009, at 19:42, John Ford wrote:
Hi all.
Anyone tried this
Placing snap blocks on separate ibobs will not be a definitive test,
but would certainly be helpful. You would have to trigger them from
the external 1PPS, which is not guaranteed to be perfectly aligned
across boards after the first arm-trigger-sync operation (you may
jitter by one or two
periods). Also, is
the jitter expected to vary on such short timescales?
I'll take a look at Billy's designs now.
Also, on clocking: how are your boards clocked? The
downstream=faster approach?
~R
2009/8/28 Jason Manley jasonman...@gmail.com
I have successfully been able to do what you want
Hi Wei-Chung
Yes, the shipping versions of tcpborphserver do not allow multiple
versions of tgtap at the same time and are the cause of the errors you
describe (as outlined on the wiki page).
I recommend you install a new version from here:
, at 03:22, Wei-Chung Hsieh wrote:
Hi Jason,
Thank you very much for your information.
I will try again.
Thanks and Regards,
Wei-Chung
- Original Message - From: Jason Manley jasonman...@gmail.com
To: Wei-Chung Hsieh wchs...@asiaa.sinica.edu.tw
Cc: casper@lists.berkeley.edu
Sent: Tuesday
Um, no, this is probably a different problem. You are getting these
errors while using SSH/SCP, right? The hardware problem with faulty
PHY manifests as one or more of the PHY LEDs flashing on/off (there
are three red ones next to the PHY chip). If your link is stable, then
I believe the
As mentioned in the Getting Started with ROACH wiki page, http://casper.berkeley.edu/wiki/Roach_getting_started#How_do_I_talk_to_my_ROACH_over_the_network.3F
use roach_monitor.py from a remote machine connected to the Xport.
Find it here:
link.
Now, back to the problem; We have a locally attached harddrive that
we are writing our data to over USB. Occasionally we want to connect
and download these. That's why I am using ssh. I can't really use
KATCP for this, can I?
Thanks again,
Kjetil
Jason Manley wrote:
Um
I was having similarly strange problems until I upgraded all the
Xilinx tools to the latest service packs. They've all disappeared now.
Jason
On 03 Nov 2009, at 20:32, John Ford wrote:
Hi all. This is exactly the error I have, and I am attempting to
fix it
now. Note that I have XP, not
never happen. Please provide details.
Jason
-Original Message-
From: Jason Manley [mailto:jasonman...@gmail.com]
Sent: Tuesday, 3 November 2009 5:40 PM
To: Wormnes, Kjetil (ATNF, Marsfield); Marc Welz; David George
Cc: Cheng, Wan (ATNF, Marsfield); casper@lists.berkeley.edu
Subject: Re
to the network since the operating system is over NFS
than the ROACH board itself.
Jason Manley wrote:
Marc Welz or David George built that kernel. They are the best
people to ask about this. I've cc'd them, though I'm not sure
either would have the config file from that release. It might
, and then, looking at the call stack
it no longer appears to crash inside EMAC access functions.
The download speeds seem quite variable; but this is probably more
likely due to the network since the operating system is over NFS
than the ROACH board itself.
Jason Manley wrote:
Marc Welz
If you already have a bitstream, simply plug a JTAG programmer into P2
(labelled Xilinx JTAG), and use IMPACT.
But if I read your email correctly, you haven't configured clocks or
anything so I'm not sure what the point of this exercise is. I agree
with Suraj, easiest would be to start
Hi Kjetil.
We have occasionally observed a similar problem here. Uboot tries to
learn the required memory timing when booting. Sometimes it fails.
It seems to be due to aggressive bus timing and poor signal integrity.
Switching to registered DIMMs (like the one the FPGA uses) solves that
The biggest difference between working /3GB option and not working is
the memory card and its driver. It depends how much system memory it's
mapping. With the /3GB option, you're only leaving 1GB for kernel
address space and everything else. We've had to fit PCI-E graphics
cards to our
Ha! I have the same desktop computer! I bought a little Nvidia Geforce
9500 PCI-E card and now have no problems with the /3GB option.
Jason
On 18 Nov 2009, at 08:54, Homin Jiang wrote:
My Windows desktop is Dell OptiPlex 755, Intel Q35 Express chipset
onboard graphics.
regards
Jason
Matt and I have had problems with BEE2 - switch with short cables. The
lanes lose sync, and then take a fixed time to resync. Data is lost
during this process, hence the losses are higher at higher datarates.
With lower rates, it is able to buffer the data and resume without
significant
I don't think the NIC-switch cable length makes much difference. I've
used everything from 0.5m to 5m and they all worked fine. These ports
have some form of auto-equalisation which seems to work very well.
Jason
On 25 Nov 2009, at 15:59, John Ford wrote:
Matt and I have had problems with
Hi CASPERites with ROACH boards...
Firmware and Software:
==
You might consider applying the following updates. These versions are
considered stable and are currently in use by KAT. In order of
priority:
* Update your base-system Simulink SVN repository:
There
Nicely done!
I am wanting to write a paper on a combined NxN correlator and
beamformer imaging instrument. This amounts to the existing packetised
correlator with added beamformers, which you basically get for free.
It makes use of existing 10GbE links' free bandwidth and each
additional
I haven't tried QuADC on ROACH, but I have noticed on the ibob, that
there is no check to see that there's no pin overlap between both
ADCs. You can set 'em both to ZDOK 0 and will start compile before
falling-over with cryptic (read: unrelated) error messages.
Jason
On 11 Dec 2009, at
to compile for ROACH.
Jason Manley
Digital Engineer
SKA-SA, KAT Pinelands office
Unit 12, Lonsdale Building
Lonsdale Road
Pinelands
7405
South Africa
Cell: +27 82 662 7726
Work: +27 21 531 7282
Fax: + 27 21 531 9761
reference designs (Jason Manley)
--
Message: 1
Date: Mon, 21 Dec 2009 09:13:15 +0200
From: Jason Manley jasonman...@gmail.com
Subject: [casper] roach reference designs
To: casper@lists.berkeley.edu, casper-correla
Good catch, thanks Glenn. I'm not sure how I missed this myself, since
I'm actually using bram delays. Feel free to make any changes.
I'm out of the office 'till Monday and so will take a closer look next
week.
Jason
On 30 Dec 2009, at 18:56, G Jones wrote:
Hello,
The auto_tap_init.m
...
cheers
homin jiang
Jason Manley wrote:
I have just checked-in the latest versions. F engine is at revision
306 (stable) for ibobs and X engine is up to rev 322g (debug
compile) for roach.
There are two major outstanding issues before the system is
deployable:
1) Loss of packets from F
We (KAT) use:
* Round +-even in FFT and PFB.
* Bitwidth at 18bits. Multipliers are 18x25 in V5, not 25x25.
* Using lower bitwidths for lookup table in PFB does not have a
major impact on performance (eg, PAPER is using 8 bit lookups).
* There is support for different coeff
I think the key error is that you weren't escaping your new commands.
But I suggest you start from scratch. Erase any changes you may have
made and return to defaults (this will restore your apparent missing
'partitions' variable, which automounts the onboard flash memory):
* run
behavior of USB booting ought to
be re-examined in that context.
USB drives with write protect switches are reasonably common and
could provide the same functionality.
Thanks to all the list for the help.
Tom
On Thu, Jan 14, 2010 at 9:28 PM, Jason Manley jason_man...@hotmail.com
wrote
Nope, 10GbE packets are exactly like normal ethernet packets, they
just come faster. Wireshark normally uses the interface in promiscuous
mode, which means you'll get the packets no matter where they're
destined. You've definitely got IP addresses and ports setup properly?
Then this sounds
Tom, I think you mean the kernel is jiffy:
http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/uImage-jiffy-20091110
The recommended Uboot version is still http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/uboot/uboot-clkfix-20091113.bin
Although there is a later version in SVN
Yes, I can confirm that reset problem on the old core. Had it in the
packetised correlator too. Don't reset it was my solution too. I
suppose the rule of thumb is don't reset anything unless you need to.
There was some funny business in the RX fifo as well, if memory
serves. After an
The CASPER webserver had to be shutdown due to an airconditioning
failure. We're working on the problem now and hope to have it running
again soon. All CASPER web services are affected, including the wiki
and svn.
Jason
by CPLD or uBoot not being the
latest versions?
-Griffin
On Dec 1, 2009, at 7:33 AM, Jason Manley wrote:
Hi CASPERites with ROACH boards...
Firmware and Software:
==
You might consider applying the following updates. These versions
are considered stable
For those interested in future CASPER correlator developments, and the
next generation hardware that will enable these large correlators, I
have posted an updated ROACH2 block diagram at http://casper.berkeley.edu/wiki/ROACH2
. The most prominent change over the original specs (from the 2009
the documentation said it would.
Thanks,
Steve
On Thu, Mar 4, 2010 at 5:26 PM, Jason Manley jasonman...@gmail.com
wrote:
Recommend you switch to a full linux root filesystem based on Debian
Etch, available here:
http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/filesystem
You might want to take a look at http://casper.berkeley.edu/wiki/MSSGE_Toolflow
and also http://casper.berkeley.edu/wiki/MSSGE_Toolflow_Setup
If you do not have any of the Xilinx blocks in your simulink library,
then installation of System Generator probably didn't complete. Once
you've
the latest Xilinx (11.5)
doesn't like the latest Matlab (2010a) so I had to downgrade Matlab
to 2009b.
Thanks,
Steve
On Wed, Mar 10, 2010 at 12:35 PM, Jason Manley jason_man...@hotmail.com
wrote:
You might want to take a look at http://casper.berkeley.edu/wiki/MSSGE_Toolflow
and also http
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
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
It's true that you can generally compile larger designs on Linux, but
I don't believe the end-to-end stability is (yet) as good as windows.
There is a difference between memory-mapping capability and program
stability.
ISE/EDK is generally much faster under Linux (and I regularly move my
Wow! nice find! Thanks Billy!
Jason
On 16 Mar 2010, at 18:23, Billy Mallard wrote:
Hi all,
I just discovered a way to disable the unhelpful warning messages that
Simulink spews whenever you load the CASPER library. Add this line to
your startup.m:
warning off
The v2 10GbE block has a bug and is currently hard-coded to use the
Xilinx cores.
AFAIK, the open-source XAUI core has also been disabled and checking
the box has no effect.
Jason
On 21 Mar 2010, at 10:37, Sean wrote:
Hi Mark and Andrew,
Thanks for the help so far.
I haven't seen
FWIW, tgtap does all the IP, MAC and ARP stuff for you. It will
continue searching for ip addresses and update the arp cache as new
devices appear on the network, so you don't have to worry about it
once started.
fpga.tap_start(my10gbe_core,mac_addr,ip_addr,port)
where my10gbe_core is the
~0dBm full scale input. Burn-out ~4dBm.
Jason
On 24 Mar 2010, at 12:34, dana whitlow wrote:
Hello,
Can someone please tell me the following:
FS input drive referred to the RF input connector, at perhaps
about 500 MHz
Burnout threshold, same location and similar frequency.
Thanks
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
Here are the latest firmware and software revisions for your ROACH
boards...
* Linux Kernel:
http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/uImage-jiffy-20091110
*) Timing (jiffy) changes.
* tcpborphserver (KATCP server on ROACH):
It seems there is a limit to the length of the 10GbE core name (ie
simulink name) of ~8 characters, which you might be exceeding (Terry
discovered this yesterday). I keep short names (4 chars) and hadn't
noticed this.
To help debug, try'n ssh into the roach board and do a ps aux to see
I have confirmed that the tutorial works as expected, so I can only
assume that you're running outdated software somewhere.
However, I have updated tut2 to use newwer functions in katcp_wrapper
and the updated tgtap function call below:
PLEASE NOTE:
The function call to tgtap has changed
There is a new KATCP server for ROACH available at http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/tcpborphserver/tcpborphserver2-2010-04-02-tgtap
to support the use of 10GbE cores with longer names. This bug would
have reared its ugly head if you tried to start multiple instances of
What is wrong with it? I'm using the simple_bram_vacc in a few
designs without trouble, and have just successfully simulated it. I've
never used Glenn's so can't comment on that one.
Jason
On 07 Apr 2010, at 10:19, Suraj Gowda wrote:
Xilinx style fix: Use Glenn's vector accumulator from
suraj is planning on hardening the yellow block cores
so that their routing/timing is locked down, independent
of what else is running in the fpga.
Please don't make this the default behaviour. On designs that are
nearly fully packed (99%), you need to be able to twiddle every part
of the
Werthimer wrote:
hi jason,
perhaps we can have different yellow block cores,
one hardened for people that need high speed input,
one not hardened,
or better yet - a parameter that selects whether the
routing is hardened or not?
dan
On 4/22/2010 10:32 PM, Jason Manley wrote:
suraj
ROACH bus runs at 66MHz (or 83MHz if you overclock it to boot config
H). I agree that the 3.5MB/s is miserable performance considering what
it should be capable of achieving. I suspect these bottlenecks are
mostly BORPH related. I also recall an extended bus handshake being
mentioned for
for the CPU?
On Wed, Apr 28, 2010 at 10:44 PM, Jason Manley
jasonman...@gmail.com wrote:
ROACH bus runs at 66MHz (or 83MHz if you overclock it to boot
config H). I
agree that the 3.5MB/s is miserable performance considering what it
should
be capable of achieving. I suspect these bottlenecks
Here is a copy of an response from Mike Memmott (from Fujitsu), along
with a spreadsheet of some of the cards they've tested. It's an
excerpt from an email conversation we had about 10GbE NICs. Note that
this is pretty old now (Oct 2008), but might still be of value.
I use the Chelsio
need to decide
between windows versus RHEL. I read the following thread dated mid-March:
http://www.mail-archive.com/casper@lists.berkeley.edu/msg01328.html
Has this recommendation changed since?
Thanks,
Mandana
Jason Manley wrote:
I too find RHEL a very frustrating OS to use on a day
Thanks for the effort Mark and Dave, I think this will be a great step
forward.
I agree that we should leave the deprecated stuff in SVN and just let
it die a natural death. If someone wants it for an old project, at
least they'll still be able to find it where they expected it to be.
I can comment on the clock speeds reporting incorrectly: this is
because your uboot is outdated. You'll also notice that your system
clock (in Linux/BORPH) is not ticking at the correct rate.
WRT 10GbE: You can confirm that your 10GbE cores are configured
correctly by using the
Wow! Thanks Dave, this looks awesome. The new web interface is
fantastic, including checkin times, log messages and auto-tar! I like!
Jason
On 16 Jun 2010, at 22:35, David MacMahon wrote:
The migration of trunk/mlib_devel_10_1 (and trunk/caltech/lib10.1)
from Subversion to Git is complete.
If I did not write any matlab scripts and only use the
casper library standard green block, I would not be affect. Is this
right?
And could you clarify in which case user can overwrite the casper
library 'i' with their own?
Thanks
Wan
-Original Message-
From: Jason Manley
or it is a single FFT
output.
Thanks
Wan
-Original Message-
From: Jason Manley [mailto:jasonman...@gmail.com]
Sent: Thursday, 17 June 2010 7:31 PM
To: Cheng, Wan (CASS, Marsfield)
Cc: casper@lists.berkeley.edu
Subject: Re: Green FFT fixed
No, the FFT redraw scripts used i and j
There are three bugs we know of in the FFT.
The first one (the biggest one) involves the twiddle coefficients and
matlab's understanding of i and j as sqrt(-1) for complex numbers.
This one's been fixed and should be checked-in. See earlier emails for
details.
The second bug is a little
AFAIK, the toolflow doesn't currently support multi-clock domains from
within the Simulink environment. Simulink hides this from you by
trying to run everything at the fastest rate and then using enable
lines to blank the lower speed logic components.
Perhaps you should consider
Yeah, this has been discussed last year already. It's also been
mentioned multiple times in the latest firmware versions email
threads. (eg http://www.mail-archive.com/casper@lists.berkeley.edu/msg01370.html
)
It sounds like this might be an old board... are you running the
latest CPLD
/products/memory.htm
).
Regards
Andrew
On 16 March 2010 14:01, Steve Maher stephen.f.ma...@nasa.gov wrote:
On Mon, Mar 15, 2010 at 12:38 PM, Jason Manley
jasonman...@gmail.comwrote:
Actually, the most stable flow right now (at least I've found) is
Windows XP 32-bit with 10.1.3.1386 and Matlab
This is terrible news. Heartfelt condolences from the digital team in
South Africa. We will all miss his energetic spirit and passion for
radio astronomy. His pragmatic approach was admired by us all and we
feel a real sense of loss.
Please convey our sympathies to Susan and family.
Jason
This is telling you that the FPGA isn't programmed. Unfortunately you
can't go'n program the FPGA behind tcpborphserver's back because it
keeps state (including register listings etc). You need to use
myfpga.progdev('mybof.bof'), for example.
Jason
On 26 Jul 2010, at 22:39,
There is a web interface where you can configure the IP address (just go to
192.168.4.20 in your browser) or otherwise there are telnet interfaces on ports
, 1 and 10001. One of them is a text based config, I forget which (just
try 'em all).
Jason
On 31 Aug 2010, at 7:45 PM, Soriano,
Try adder latency 1, multiplier latency 2, bram latency 3. Be sure to optimise
to use DSP48 multipliers and tick any boxes asking to pull adders into DSP48s.
This should allow adders following multipliers to use a single DSP48 slice,
with registered input and output (making for a shorter signal
I'll just raise a flag of caution that if you're not rounding in your PFB,
there may be some artifacts in your output. Some ppl don't care about this
though.
Jason
On 10 Sep 2010, at 13:01, Danny Price wrote:
Thanks everyone, I've managed to get a modified tutorial 3 to compile (with
Jack
1 - 100 of 285 matches
Mail list logo
