Re: [casper] Tut3 trouble - Error due to multiple causes

[Mark Wagner]

Hi Daniel,

This error occurs when the Simulink design is updated.  It's possible the
library you've loaded has blocks that are different than those used to
create the original design.  If you start a simulation (Simulation -->
Start), the error dialog box should pop up with more detailed information
about the offending block or connection.  If the issue is a block, try
deleting it and replacing it with one from your library.

Mark


2011/2/15 Daniel Esteban Herrera Peña 

> Hi everyone,
>
> I could get a 800MHz clock source to test the spectrometer in tut3 (using
> the pre-compiled file you provided) with successful results including
> changing the input frequency to 1GHz, now I want to change the adc input
> clock to 2GHz (I see that I must change to interleave mode), but first I
> tried to synthesize the r_spec_2048_r105 without making any change and I
> receive this error:
>
> Detected Linux OS
> #
> ##  System Update  ##
> #
> Error using ==> gen_xps_files at 199
> Error due to multiple causes.
>
> If I knew just one cause I will be happy trying to resolve it, but I have
> no clue at all. I saw in the forums some issue regarding the adc block, I
> tried to follow those steps (re-adding adc block, disabling link) but the
> problem persist. Does anyone knows how to inspect more deeply the error I'm
> having?.
>
> Thanks.
>
> Daniel H.
>
>

[casper] Tut3 trouble - Error due to multiple causes

[Daniel Esteban Herrera Peña]

Hi everyone,

I could get a 800MHz clock source to test the spectrometer in tut3 
(using the pre-compiled file you provided) with successful results 
including changing the input frequency to 1GHz, now I want to change the 
adc input clock to 2GHz (I see that I must change to interleave mode), 
but first I tried to synthesize the r_spec_2048_r105 without making any 
change and I receive this error:


Detected Linux OS
#
##  System Update  ##
#
Error using ==> gen_xps_files at 199
Error due to multiple causes.

If I knew just one cause I will be happy trying to resolve it, but I 
have no clue at all. I saw in the forums some issue regarding the adc 
block, I tried to follow those steps (re-adding adc block, disabling 
link) but the problem persist. Does anyone knows how to inspect more 
deeply the error I'm having?.


Thanks.

Daniel H.

Re: [casper] casper Digest, Vol 39, Issue 10

[Wesley New]

Hi Chao-Te

As for your 2nd point. I have updated the tut2.py script to fix the
programming issue.

Turns out when there is no boffile specified in the arguments, it passed an
empty string to the progdev function.'

An "svn update" should solve this issue now.

Regards

Wesley

On Tue, Feb 15, 2011 at 9:28 AM, Chao-Te Li wrote:

> Hi everyone,
>
> I have been running the tutorials again. as for tut2,
> I found out some interesting things as follows -
>
> 1. I can run every command in tut2.py thru ipython except
> fpga.tap_start('tap0',rx_core_name,mac_base+dest_ip,dest_ip,fabric_port)
> and
>
> fpga.tap_start('tap3',tx_core_name,mac_base+source_ip,source_ip,fabric_port)
>
> I need to remove 'tap0' and 'tap3' for the commands to work. am I using
> an old version of tgtap? but I have updated the file system as described at
> http://www.mail-archive.com/casper@lists.berkeley.edu/msg01370.html
>
> 2. when running the python script (tut2.py), I can't get the device
> programmed. so I comment the command and program the device using katcp.
> and I need to modified the tap-start commands as well.
>
> 3. I found out I can't run tut2 consecutively, the 2nd time I always get
> something like TX overflow and TX almost full. is there a way to get around
> this problem? like clear the tx buffer? at the moment, I need to kill the
> process and re-program the device.
>
> does anyone have idea about these problems?
> Thanks a lot,
>
> Chao-Te
>
>
> --
> Open WebMail Project (http://openwebmail.org)
>
>
> -- Original Message ---
> From: casper-requ...@lists.berkeley.edu
> To: casper@lists.berkeley.edu
> Sent: Sun, 13 Feb 2011 12:55:44 -0800
> Subject: casper Digest, Vol 39, Issue 10
>
> > Send casper mailing list submissions to
> >   casper@lists.berkeley.edu
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >
> https://calmail.berkeley.edu/manage/list/listinfo/casper@lists.berkeley.edu
> >
> > or, via email, send a message with subject or body 'help' to
> >   casper-requ...@lists.berkeley.edu
> >
> > You can reach the person managing the list at
> >   casper-ow...@lists.berkeley.edu
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of casper digest..."
> >
> > Today's Topics:
> >
> >1. 550MSa/sec 12-bit ADC test design (Peter McMahon)
> >
> > --
> >
> > Message: 1
> > Date: Sat, 12 Feb 2011 04:51:31 -0800
> > From: "Peter McMahon" 
> > Subject: [casper] 550MSa/sec 12-bit ADC test design
> > To: 
> > Message-ID: <144101cbcab3$95977940$c0c66bc0$@za.net>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Hi everyone,
> >
> > Sorry to bother everyone again. I'm trying to get a 550MSa/sec 12-
> > bit ADC board to work with my ROACH. The data I'm getting out
> > doesn't make sense, so I'm in the process of figuring out which of
> > my board, design, data interpretation and/or wiring is faulty.
> >
> > To eliminate the possibility that my problems are caused by my
> > having done something really stupid in my design, I'd like to try
> > out a "known good" design. Does anyone have a test design for the 12-
> > bit ADC available that I could use? (I have an LX110 FPGA, so I'd
> > probably need to recompile it, rather than just use the existing
> > "binary".)
> >
> > Thanks,
> >
> > Peter
> >
> > -- next part --
> > An HTML attachment scrubbed and removed.
> > HTML attachments are only available in MIME digests.
> >
> > End of casper Digest, Vol 39, Issue 10
> > **
> --- End of Original Message ---
>
>
>