Hi Glenn,
At the moment, the dialog box just sets the timing constraints. As you've
discovered it doesn't exert any control over the DCM settings. I think it
would be possible to add this feature to the toolflow, but for the time
being I think you're best off bringing in the clock externally
Hi John,
The BEE2 user clock input circuit is actually LVPECL, which is probably
why you've been encountering problems driving it using CMOS levels from
the IBOB. Matt Dexter from UCB Radio Astronomy Lab has also designed a
board to properly make the interface. It's been used pretty reliably on
Hi Jan,
The 4 GPIO header banks have a selectable output voltage. Is your IBOB
jumpered for 2.5V output on J14?
Thanks,
Henry
Jan Wagner wrote:
Hi again,
I'm trying to program a frequency synthesizer board that has a 4-wire
(uWire) interface. LVCMOS25, not differential. The logic-high level
Hi John,
Is this the complete log, or is it missing a snippet? It looks like it's
skipping the platgen portion of the backend and jumping directly to xflow.
Can you try to open the project in EDK and running it manually rather than
through Matlab? That might shed some more light on the matter.
Hi Glenn,
The ADC interface core has an embedded DCM.
Regarding your other question about accessing the DCM lock signal, it's not
exposed anywhere in the Simulink flow, but they are available from the MHS.
It has been suggested that we should provide the lock signal as an output
from the XSG
Hi all,
The interchip busses on the BEE2 should be used with caution. The lines are
wave-pipelined, and are routed in bundles that are not consistent throughout
the board, or even within the same bus. You may have to play with different
sending and capture phases on the different lines to get
Like Glenn has said, different routing within the FPGA can cause a
significant increase in the time needed to PAR. The IOBs for the
interchip links are pretty distributed through the chip, so changing
the target can make it harder to route. You can check the PAR logs
(system.log or implementation
Hi Alan,
Sorry for taking a while to respond. In the future I highly recommend that
you email all questions to cas...@lists.berkeley.edu. This will not only
help you access a wider pool of resources, but also helps everybody else in
case they run into the same problem down the line.
I don't
version or write in the directory?
John
On Mon, Aug 18, 2008 at 4:48 PM, Henry Chen
hche...@ssl.berkeley.eduwrote:
Hi Glenn,
It looks like a lot of cores were deprecated in the intervening
tool
revisions.
If you want, it looks like you can manually bring in pcores from
EDK7.1
by
going
to EDK
Hi Homin,
Green blocks and pink blocks cannot be used together. There are conflicting
mask scripts.
Thanks,
Henry
Homin Jiang wrote:
Hello:
This should go to the bug report category.
I am modifying Peter's 400MHz 1024 channels design which i downloaded
from the website. There are 2 green
Hi Glenn,
Here it is.
--Henry
G Jones wrote:
Hello,
Does anyone have drawings of the aluminum plates that iBOB and iADCs
come mounted on that fit in 6U crates handy?
Thanks,
Glenn
digibee_plate.pdf
Description: Adobe PDF document
Hi Fatih,
The toolset is generally installed using ISE Foundation, which should come
with CoreGen. I'm not sure that System Generator will be compatible with
Webpack.
In any case, the WebPack will not support the Virtex-II Pro -50s and -70s
that are currently on CASPER hardware.
Thanks,
Henry
Hi Glenn,
I'm actually in the process of doing this partway for the biplex
unscramblers. For large FFTs, the arbitrary reorders consume an
insanely huge number of resources trying to get the mapping ROM.
Since the biplex unscramble reorders use a known and easily-described
reorder, I was just
* surprised that ROMs no
longer do this optimization. This may be worth calling Xilinx about.
It may be that there is some flag that is disabling this reduction.
Logic optimization is kind of the whole point of ROMs...
On Thu, Sep 25, 2008 at 6:09 PM, Henry Chen hche...@ssl.berkeley.edu wrote:
Hi
Hi Glenn,
The gen_prog_files script/.bat will do that for you.
--Henry
G Jones wrote:
Hello,
I often do the run init_bram thing on my designs after changing the
powerPC software. Is there an existing, easy way to get the
implementation/download.bit file to be moved to the bit_files
Hi John,
Do you have the coefficients in slices rather than BRAMs? That might
be contributing to the high address fanout. Can you send the MDL file
so everybody can take a look at it?
Thanks,
Henry
John Ford wrote:
Hi John,
I've definitely run into the same issue, but haven't had a chance to
SysGen directly, but then you have to do the EDK pcore
wrappers and EDK project manually.
-Henry
wan.ch...@csiro.au wrote:
Hi Henry:
Why we have to use bee_xps to generate the bitstream instead useing sysgen?
Wan
-Original Message-
From: Henry Chen [mailto:hche...@ssl.berkeley.edu
Hi Wanxiang,
If the sync you're setting is the simulation input to the ADC block,
then it's treated as the reset to your sync generator, not the sync
itself. In this case, when you set it to 1 you're just always holding
down the reset to your counter, so you're actually never generating
your
not see anything wrong with them. But
output still is period pulse instead of single pulse spectrum.
Thanks
Wan
-Original Message-
From: Henry Chen [mailto:hche...@ssl.berkeley.edu]
Sent: Thursday, 6 November 2008 5:06 PM
To: Cheng, Wan (ATNF, Marsfield)
Cc: martens.and...@gmail.com
Hi Wanxiang,
No such master UCF file exists for any of the boards. All the pinout
information is embedded in the BEE2_hw_routes.mat table of the toolflow.
The information in this table is read by toolflow functions to extract
the pinout information at compile-time based on which yellow blocks
Hi Alan,
Does iMPACT just give you the big red Programming Failed banner? Are
there any useful status messages in the transcript window?
Thanks,
Henry
Alan Hinton wrote:
Hi all,
I have the Roach board up and running with the roach_bsp.bin code,
things appear to be good. Now I want to start
Hi Wanxian,
The nightly snapshots haven't been updating properly due to some
server configuration changes last month. If you need this code
right away, please download directly from the SVN repository.
Thanks,
Henry
wan.ch...@csiro.au wrote:
Hi David:
Thanks for your answer. But I am afraid
Some of you may have noticed that as of late there as been
more spam than usual coming through on this list. We are
aware of this, and we'll try to tighten down the list setup
to close up some of these holes.
I apologize for any inconvenience.
Thanks,
Henry
Hi Glen,
As far as I can remember, the bus address of the 10GbE blocks are
dynamically allocated. In either case, you should be able to figure
it out by going into XPS_iBOB_base/ppc405_1/include/xparameters.h,
which is the end-all, be-all index of address for anything connected
to the PowerPC.
Hi Wan,
The ADC control pins are part of the ADC controller pcore, rather
than the ADC interface pcore. The controller and its constraints
are conditionally written into the project files during preprocessing.
There should be a small block in the UCF file somewhere before all
of the other ADC
The GPIO yellow blocks should have an option to do DDR I/O, which
will allow you to send out a clock at the IBOB's native rate. You
just have to give it both edges of data in parallel (i.e., for a
clock, you give it a 2-bit unsigned of either '01' binary or '10'
binary).
That said, given the
Hi Aaron,
This sounds like it might be one of those annoying Sysgen Core Cache
conflicts.
Can you try setting your SGCORECACHE environment variable to some temp
directory where you know you have read/write permissions?
Thanks,
Henry
Aaron Parsons wrote:
Maybe I'm flummoxed because I'm a
Hi John,
This is a known issue with the CASPER SVN (and actually all
repositories for Linux kernel source). There are several files
with the same name but with different cases, which Linux will
happily handle but Windows will not. This really screws with
the netfilter_ipv4 directory on a Windows
Hi Randy,
This is partially written up at:
http://casper.berkeley.edu/wiki/Dram
But I'll mention a few highlights.
The bursting nature of the DRAM means that each transaction
covers 288 bits of data, handled at 2 chunks of 144 bits going
into the controller (72 bits in 4 clock edges
Hi Wan,
This means that the definitions of the classes used for the
yellow blocks have been updated and something is out of sync
in Matlab. All you need to do is to run the command
clear classes at the Matlab command prompt and that will
allow things to reset.
This is among the least helpful
Hi all,
Based on a previous thread, I gather that the expected max bandwidth
out of an IBOB using LWIP is ~5-7Mbit/s. Has anybody ever tried
streaming data *into* an IBOB over LWIP? If so, are the numbers
about the same?
Thanks,
Henry
Hi C-H,
You need to be very careful with I/O elements in the toolflow. In
general, only yellow blocks can be used for I/O, as the toolflow
acts on them to generate the EDK project files to connect everything
up.
Without seeing exact error logs, I would guess that your black box
inserts the
work.
About Pcore, do you have any tutorial?
Regards,
C-H Cheng
- Original Message - From: Henry Chen hche...@ssl.berkeley.edu
To: casper@lists.berkeley.edu
Cc: C-H Cheng chch...@asiaa.sinica.edu.tw
Sent: Wednesday, October 28, 2009 3:50 PM
Subject: Re: [casper] ISERDES
That's also my bad... I'll try to get those DRC's implemented
sometime soon...
-Henry
Jason Manley wrote:
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
Hi John, Billy,
For what it's worth, the power distribution design on the BEE2 has
never been stellar. I haven't seen problems specifically with XAUI,
but during the massive orgy of BEE2 production and testing, it was
found that User FPGAs 2 and 3 tended to have higher DRAM error rates.
These 2
Hi Jonathan,
There's probably some peculiarity to Simulink that necessitated
that kind of weirdness. Since the bulk of the components inside
the ADC yellow block are just a simulation model, those delay
values were probably found empirically.
Thanks,
Henry
Jonathan Landon wrote:
Inside the adc
Topics:
1. Delays in ADC block have unexpected values (Jonathan Landon)
2. Re: Delays in ADC block have unexpected values (Henry Chen)
3. Re: Delays in ADC block have unexpected values (Aaron Parsons)
4. Re: Delays in ADC block have unexpected values (David MacMahon
Hi Steve,
The presence of the assert blocks in the library means that the
block hasn't been updated for use with 10.1, and thus has no
ROACH support. In any case, that block really is only meant for
the SiBeam DAC board using the Atmel DAC; it won't be a quick
shoehorning to get it to work with
Hi Dave,
Those are some nice savings! Do you have a feel for whether there
are any performance impacts, for better or worse, or should it be
about neutral?
Thanks,
Henry
On 4/19/2010 8:26 AM, David George wrote:
Hi Aaron.
Nice work! Are there any tantalizing details you might be able to
Hi Andrew,
Assuming you have the standard chassis from Digicom, you likely have
an iStarUSA D-107 chassis. It is actually an odd size at 1.3U; a
ROACH won't fit in a 1U because of the height of the CX4 assembly
(as you've observed).
http://www.istarusa.com/rackmount_chassis/dstorm/1u/d-107.aspx
wrote:
Henry Chen wrote:
Has anybody discovered the magic command to disable the warnings for
In instantiating linked block *: ... Block block doses not have a
a parameter '---' that's crept in since the partial migration to 11.x?
I get this warning per block that gets accessed. I just tried
connects up). If I could only connect it to the %$#)~! pins
I'd be done!
Rick
Henry Chen wrote:
Hi Rick,
That's actually a pretty good question. A not-so-good answer is that
you'd make a yellow block when existing yellow blocks don't provide
all of the functionality you need ;)
Basically
Hi Steve,
Can you check that the whole dac_mkid_interface_v1_01 tree got
properly copied over to C:\roachModels\dac_out\XPS_ROACH_base\pcores?
Thanks,
Henry
On 5/18/2010 12:31 PM, Steve Maher wrote:
Hi,
FYI, upgrading the block description in the Simulink Library Browser
required adding
with the new dac_mkid pcore?
Thanks,
Henry
On 5/18/2010 1:29 PM, Steve Maher wrote:
On Tue, May 18, 2010 at 4:13 PM, Henry Chen hche...@ssl.berkeley.edu
mailto:hche...@ssl.berkeley.edu wrote:
Hi Steve,
Can you check that the whole dac_mkid_interface_v1_01 tree got
properly
generation failed, EDK compilation probably also
failed.
Steve
On Tue, May 18, 2010 at 4:44 PM, Henry Chen hche...@ssl.berkeley.edu
mailto:hche...@ssl.berkeley.edu wrote:
Hi Steve,
If you delete the C:\roachModels\dac_out\XPS_ROACH_base\ directory
rerun just the Copy
Hi John,
If I remember correctly, it should have been possible, but alas is not.
The ability is actually built into the Platform Flash PROM chip, and
the selection jumpers are on the board (one of the set of 3x2 headers
by the PROM). Unfortunately, the 32Mb PROM isn't capable of storing
more
Hey Suraj,
It goes device_name device_type start_address(hex) size(hex, in bytes)
-Henry
On 5/26/2010 11:27 AM, Suraj Gowda wrote:
Hello casperites,
Does anyone know the format for lines in XPS_ROACH_base/core_info.tab?
All I see is 3 numbers:
iadc_controller 321
the load_system(... lines) to disable most of the superfluous warnings
warning off Simulink:SL_LoadMdlParameterizedLink
warning off Simulink:SL_OutputNotConnected
warning off Simulink:SL_LoadMdlLoadError
Hope this makes things more pleasant
Regards
Andrew
On 5 May 2010 02:44, Henry Chen hche
to the FPGA is wise.
Matt Dexter
On Wed, 14 Jul 2010, Henry Chen wrote:
Hi Jayanth,
This might be a problem with the input levels. If you use usr_clk
on the IBOB, it's expecting LVCMOS signals (0-2.5V). Do you have
a non-CW signal generator?
In general, any clock for the IBOB has a range of 24MHz
Hi Kaushal,
You're right; the bee_xps flow will currently not work with
multiple tokens. The way the flow is architected assumed a
monolithic, single-clock Simulink design.
Thanks,
Henry
On 7/16/2010 4:48 AM, Kaushal Dipak Buch wrote:
Hi Jack,
The following is what I tried for implementing a
the version you're running (when you telnet in you
get a greet message) and an exact usage scenario that breaks it if it is
some corner-case?
Jason
On 26 Aug 2010, at 12:43, Henry Chen wrote:
Hey Jason,
I've noticed that in the newer shipping versions of the tcpborphserver
the error
writes, that is true. But it shouldn't
return write ok when it didn't work.
Jason
On 26 Aug 2010, at 14:08, Henry Chen wrote:
I'm running
#version poco-0.1
#build-state poco-0.2804
This popped up when my (Matlab) scripts weren't parsing input right
and it wound up trying to write data
Hi Jack,
The GPIOs on the ROACH are spread across different I/O banks, so
they are all at different voltages. To make them all a uniform 3.3V,
they go through unidirectional level translators; the gpiox_oe_n
signals control the drive directions of these translators.
Cheers,
Henry
On 8/27/2010
Hi Ramesh,
Is there a setting in ckermit to turn off flow control?
Thanks,
Henry
On 9/8/2010 1:41 PM, Ramesh Karuppusamy wrote:
Hi Mark, hi Sean:
Thank you very much for the quick response. Yes, a null-modem cable
solved the issue partly. I see the messages from the roach unit in my
Hi Melissa,
I've been playing around a bit with the new -signfix version of
tcpborphserver. The patch works for me if I do
/etc/init.d/tcpborphserver stop
then replace tcpborphserver2 in /usr/local/sbin and reboot. Then
the new version of the server comes up properly at boot. Did you
have
Hi Dave,
We've just encountered an interesting issue here where the toolflow's
bus addresser gives overlapping addresses as it spans two bridges. What
seems to be happening is that there are a fairly large number of BRAMs
in the design, and so by the time a new opb2opb bridge is inserted, the
Hi Dan,
More specifically, here are some guidelines for using Z-DOKs
http://casper.berkeley.edu/wiki/CASPER_Z-DOK_Compatibility
Thanks,
Henry
On 2/22/2011 9:55 PM, Francois Kapp wrote:
A follow up question. From the data sheet I've found concerning the
6367555-1, it is not clear
Hi Tom,
Any one of the IBOB's header GPIOs should be able monitor it. You
will probably need to put in a series resistor to protect the
LVCMOS inputs pad from the TTL signal:
http://www.xilinx.com/support/answers/10835.htm
Thanks,
Henry
On 2/23/2011 12:12 PM, Tom Kuiper wrote:
We have a box
Hi David,
Okay, cool; that seems to jive with the behavior I'm seeing.
Is the CASPER svn still the primary repository for the ROACH
testing gateware?
Thanks,
Henry
On 4/19/2011 10:40 AM, David George wrote:
Hey Henry.
I'm sending this from my phone, so apologies for the brevity. I
suspect
Hi Ian,
I just gave it a quick try and didn't get the same error. Which
version of the libraries are you using?
Thanks,
Henry
On 6/9/2011 2:40 PM, O'Dwyer, Ian J (382G) wrote:
Hi All
I am getting the following error from the gpio yellow block when
attempting to compile a simple design to
Hi Rich,
The ROACH-Is use XC5VSX95T-1FF1136C or XC5VLX110T-1FF1136C. Avnet
shows the SX95s at $2917.33 each, and the LX110s at $1945.33 each.
The ROACH-IIs, I gather, will use XC6VSX475T-1FFG1759C, which don't
appear to be off-the-shelf available from Avnet. But their engineering
samples are
Hi Louis,
This error means that you're trying to assign a bit position beyond
that supported by the particular IO group. In this case, it's because
the ROACH only has 4 user-accessible LEDs, while the IBOB has 8. So
if you just take out the slices that are giving you trouble, it should
be okay.
iBOB board?
On Mon, Aug 8, 2011 at 8:36 PM, Henry Chen hche...@ssl.berkeley.edu
mailto:hche...@ssl.berkeley.edu wrote:
Hi Louis,
This error means that you're trying to assign a bit position beyond
that supported by the particular IO group. In this case, it's because
the ROACH only
Hi David,
That did the trick. Thanks for the help!
Cheers,
Henry
On 8/12/2011 1:19 AM, David George wrote:
Hey Henry
As it turns out, I forgot to compile in the roach mmc stuff. I have
just checked in a new kernel into casper_svn:
Hi Yifan,
This sounds like the missing mmc drivers that was fixed in the
latest kernel release. You can update your kernel to the newest
one found here:
https://casper.berkeley.edu/wiki/LatestVersions
using the instructions here:
https://casper.berkeley.edu/wiki/ROACH_kernel_uboot_update
I
Hi Rurik, Glenn,
I think the roach_infrastructure block does something similar to generate
arb_clk, after calculating
the appropriate multiply and divide factors in Matlab. roach_infrastructure
(and maybe also the
quad ADC block) also has a portion that uses Verilog generate statements to
choose
Hi Jay,
Unfortunately, the secret sauce of the Shared BRAM yellow block is
that it uses the dual-port BRAM under the hood; one port goes to
the FPGA fabric, and the other goes to the processor bus.
The single-port bram block under the mask is just there to provide
a simulation model, and
67 matches
Mail list logo
