Re: [casper] Roach2 i2c read/write failures
This problem is likely the FTDI not being configured to tristate the IIC pins on reset, hence they are likely driven. This may be weakly enough that IIC open drain might work, or possibly some are configured to tristate and other aren't, or the config is random - just a thought.
Re: [casper] Roach2 QDR
A small chip-in - QDR doesn't work below 120 MHz:
http://www.cypress.com/?id=4&rID=31542
Regards
On 10 March 2015 at 22:17, Matt Strader wrote:
> Hi Jack,
>
> Thanks for your reply. I think I understand better what's going on. I was
> thinking in terms of 64-bit words that get written or read each cycle, but
> looking in qdr_cal(), I should probably think of two 32-bit words read or
> written each cycle. Then, perhaps I shouldn't be too surprised if the order
> of the two words read out doesn't match my intuition.
>
> Initially, I was compiling at 100 MHz, but the qdr_cal always failed. Then
> I tried 200 and 250 MHz, and the qdr_cal succeeds.
>
> My tests go like this. For the 200 MHz design,
> I call qdr_cal, and it returns True.
>
> Then I write this sequence of 64-bit values via the CPU:
> [0, 1, 2, 3, 4, 5, ..., , 1048574, 1048575]
>
> I read back the sequence from the CPU, and it agrees.
> [0, 1, 2, 3, 4, 5, ..., , 1048574, 1048575]
>
> I read it in fabric and get
> [1048575<<32, 0<<32, 1<<32, 2<<32, 3<<32, 4<<32, ..., 1048574<<32, ]
>
>
> Then I try the other direction, by writing a sequence of 64-bit values in
> fabric:
> [0,1,2,3,4,5, ... , 1048574, 1048575]
>
> I read back the sequence in fabric and it agrees:
> [0,1,2,3,4,5, ... , 1048574, 1048575]
>
> I read it via the CPU:
> nBytesPerSample=8
> struct.unpack('>{}Q'.format(nSamples),
> roach.read('qdr0_memory',nSamples*nBytesPerSample))
> and get:
> [1<<32, 2<<32, 3<<32, 4<<32, 5<<32, ..., 1048575<<32, 0<<32]
>
> So reading and writing only by the CPU is consistent, and reading and
> writing only in fabric is consistent, but when I do one by the CPU and the
> other in fabric, the two 32 bit words get swapped, and the sequence is
> offset by one value. I actually see the same offset in a Roach1 version of
> the design as well. It all seems consistent, not intermittent.
>
> Thanks,
> Matt
>
>
>
> On Mon, Mar 9, 2015 at 10:42 AM, Jack Hickish wrote:
>>
>> Hi Matt,
>>
>> The qdr_cal routine calibrates the relationship of clock and data signals
>> in the link between the FPGA and QDR signals. Basically it writes test
>> patterns and reads them back looking for glitches. It then changes the delay
>> of IODELAY blocks so that data read from the QDR is captured reliably.
>> If this calibration script runs successfully, I'm surprised you still see
>> glitches with 32 bits of data swapped between read and write (both from
>> PPC). This would (surely?) count as a glitch and cause the calibration
>> routine to fail(?). Do you only see strange behaviour when you read from the
>> FPGA fabric, or do straight write/reads from the CPU also misbehave? Is the
>> behaviour the same on every read / write (i.e., not intermittent)?
>>
>> My experience with the QDR is that at high clock speeds (not sure how
>> high, but I see this at 312 MHz) the read latency of the QDR interface isn't
>> 10 clock cycles as it should be even with the minimum IODELAY configuration,
>> and there are no reliable qdr_cal solutions. I solved this problem for my
>> design by removing half a clock cycle latency from the interface, at which
>> point the QDR would calibrate ok. What speed are you running your design at?
>> To me, misordered 32-bit chunks of data sounds indicative of a latency
>> problem in the qdr_cal solution, since the interface is 32 bit DDR, so half
>> a clock cycle mangles 32-bit chunks of data.
>>
>> Good luck!
>>
>> Jack
>>
>>
>>
>> On Fri, 6 Mar 2015 at 23:54 Matt Strader
>> wrote:
>>>
>>> Hi all,
>>>
>>> I'm trying to use QDR on Roach2. I have a test design where I write to
>>> QDR either in firmware or with katcp, then read it out in the firmware and
>>> check the results with snapshot blocks. It mostly works, but with some
>>> interesting quirks.
>>>
>>> I know that katcp can only write 64 bits of the 72 bit QDR word, so I
>>> changed the bitbasher blocks in qdr_mask.m to move the inaccessible bits out
>>> of the way to the most significant bits. Now everything seems to work well,
>>> except that in some builds (seems to depend on clock rate?), the first 32
>>> bits (of the 64 bits I'm writing in a cycle) get swapped with the last 32
>>> bits sometime between writing the word and reading it back. And there is a
>>> sometimes a difference in whether I am writing in firmware or by katcp to
>>> whether this swap happens.
>>>
>>> Also, when I write with katcp starting at address zero, I find that when
>>> reading out, the write started at what seems to be address 1. Is the
>>> latency of QDR set to 10 cycles?
>>>
>>> I can live with all this, as long as it is repeatable for a given design,
>>> but I thought I'd ask if anyone knows what is causing these quirks.
>>>
>>> Also, I understand that we should run a software calibration for qdr,
>>> which seems to be qdr_cal() in qdr.py in the ska-sa:casperfpga repo. So, I
>>> run this first, which seems to work for my latest compiles, but I haven't
>>> noticed a difference in the results. What exactly
Re: [casper] packet capture
Use a NIC that can do dpdk: http://dpdk.org/doc/nics then look on the web for dpdk packet capture utils. David On 30 June 2016 at 10:30, Andrew Siemion wrote: > Hi Louis, > > We found this paper quite useful: > > http://www.ieee-hpec.org/2014/CD/index_htm_files/FinalPapers/95.pdf > > Cheers, > > Andrew > > On Jun 30, 2016, at 6:58 AM, Louis P. Dartez > wrote: > > Hi all, > Can anyone guide me on what tools are being used for packet capture > purposes right now? I’ve been working on a baseband recorder using a ROACH1 > using the 10GbE lines but I can’t seem to avoid losing packets when writing > data to memory or disk. I wrote a threaded packet sniffer in C with a > pretty tight loop that write directly to memory in Ubuntu Linux. I’m > wondering if there are any optimizations that I could be missing out. > > > Any advice would be greatly appreciated, Thanks in advance! > LD > > Louis P. Dartez > > Ph.D. Candidate > > STARGATE > > Center for Advanced Radio Astronomy > > University of Texas Rio Grande Valley > > (956) 372-5812 > > > >
Re: [casper] NIC tuning and IRQ binding : Regarding
> I think modern Linux network drivers use a "polling" approach rather than > an interrupt driven approach, so I've found IRQ affinity to be less > important than it used to be. This can be observed as relatively low > interrupt counts in /proc/interrupts. The main things that I've found > beneficial are: > IRQ affinity is what links the RX queue to a core, without setting it up you don't get nice RSS. If you want packets to spread to cores you 100% need it. Cheers, David -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CA%2BLg%2BWHR96gfyxXQwQiFiXwAbFS5YBeZKX662w_axNERUzuPAg%40mail.gmail.com.
[casper] A new 10Ge Controller (ten_Gbe_v2)
Greetings all. I've just finished a revamped 10Ge (v2) controller for Virtex-5 devices, which has been integrated into the mlib_10_1 build (ROACH target only). The old 10Ge controller ran into timing trouble at roughly 200 MHz on RX and 260 MHz on TX, also it used a ton of BRAMS (13). These two show-stopper issues warranted a rewrite of the core. The new core has the following features: * Application interface tested at 333MHz (RX+TX) * Reduced Block-RAM utilization: Typical utilization 7, without CPU interface 3, worst-case 9 (if application clock < 156.25) * Receive CRC using Virtex-5 CRC hard-macros * Written entirely in Verilog with a fairly comprehensive simulation test-harness targeted for the Icarus Verilog simulator - Note: with this core the maximum TX frame size is 8k The application interface has changed a little. Documentation will be up on the wiki soon at http://casper.berkeley.edu/wiki/Ten_GbE_v2 The software interface remains the same. The core is still very green and equires a bit more testing. It would be great if some CASPER folk with ROACHs would get their hands dirty. Cheers, David -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
[casper] Resolved: bug report -- opb_adccontroller_v1_00_a -- user_logic.vhd
Hello Homin. This error was fixed in SVN a few days ago, try updating your MLIB revision. Sorry about the hassle, the ROACH target code is usable but in development. Its great that you are building roach designs. Feel free to try out other yellow blocks for testing and if there are issues please report them - we want to squish as many bugs as possible! Regards, David btw the code should have read - attribute iob: string; attribute iob of adc0_ddrb_reg : signal is "true"; --ensure IOB packing to ensure minimum skew attribute iob of adc1_ddrb_reg : signal is "true"; ------- -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] the recapture bits are lost in ADC interface
Hi Wan. Firstly I'm assuming you are targeting ROACH... It would probably be best to look at the synthesis/map logs before looking at the output NCD. The synthesis logs tend to be very telling when it comes to floating outputs etc. Generally speaking when things are optimized away it is an indication that the outputs are not being used, so I would check your simulink design and make absolutely sure you are actually using those signals. I can confirm that the code from SVN works, attached is a .mdl file for a design which outputs ADC data to 10Ge. Note the design will not work without support software to configure the ADC (currently there is no simple way of configuring the ADCs) Regards, David George -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za Hi: I am working with 10.1 library. For the following code in the adc_interface.vhd ADC_DATA_DDR: for i in adc_dataeveni'range generate adc_dataeveni_ddr: ddr_input port map ( clk => adc_clk, d => adc_dataeveni(i), qrise => adc_datai_ddr(i + 24), qfall => adc_datai_ddr(i + 8) ); adc_dataoddi_ddr: ddr_input port map ( clk => adc_clk, d => adc_dataoddi(i), qrise => adc_datai_ddr(i + 16), qfall => adc_datai_ddr(i + 0) ); adc_dataevenq_ddr: ddr_input port map ( clk => adc_clk, d => adc_dataevenq(i), qrise => adc_dataq_ddr(i + 24), qfall => adc_dataq_ddr(i + 8) ); adc_dataoddq_ddr: ddr_input port map ( clk => adc_clk, d => adc_dataoddq(i), qrise => adc_dataq_ddr(i + 16), qfall => adc_dataq_ddr(i + 0) ); end generate; I only could find bit 15 and 31 are generated in the post map NCD file. I guess all others bits are optimized out. I could not understand why. I could not solve this problem for a week. Anybody has seen this case? Thanks Wan rawdata_machine.tar.gz Description: application/gzip
[casper] 10.1 dev: ROACH ADC and 10GE Auto-configuration
Hi All. The 10Ge and ADC blocks on ROACH now require no control software for basic configuration. The ADCs will 'automatically' set themselves into interleaved or normal mode, while the 10Ge will preconfigure its registers to the settings specified in the yellow block. This will allow the possibility of zero-config designs. Regards, David George (note: the 10ge pre-configuration is also implemented on iBOB) -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
[casper] ROACH BORPH/MSSGE toolflow update
Hi All. As of today, ROACH builds now generate working BORPH (.bof) files. BORPH is up and running on ROACHs here at KAT, thanks to Hayden and Brandon Hamilton. Here is the shell output reading and writing to shared registers: r...@roach:/tmp# ./test_basic.bof & [1] 22 r...@roach:/tmp# cd /proc/22/hw/ r...@roach:/proc/22/hw# echo "0" >> ioreg_mode r...@roach:/proc/22/hw# cd ioreg r...@roach:/proc/22/hw/ioreg# ls sh_bram sh_fifo_in2 sh_fifo_out2 sys_board_idsys_rev sh_fifo_in sh_fifo_out sh_reg_in sys_irq_controller sys_rev_rcs sh_fifo_in1 sh_fifo_out1 sh_reg_outsys_monitor sys_scratchpad r...@roach:/proc/22/hw/ioreg# echo "1234" >> sh_reg_in r...@roach:/proc/22/hw/ioreg# cat sh_reg_out 04D2 r...@roach:/proc/22/hw/ioreg# Cheers, David -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
[casper] DRAM on ROACH
Hi Wan. We use the Xilinx Memory Interface Generator (MIG) 2.3 through COREGEN to generate our controller. The generated code is in the CASPER svn at: mlib_devel_10_1/xps_lib/XPS_ROACH_base/pcores/dram_controller_v1_00_a/hdl/verilog Regards, -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
[casper] KAT XAUI
Hi All. I've written (and tested) a replacement module for the Xilinx XAUI core called xaui_kat. It is currently being used in the ROACH build on MLIB_10_1. This means that if you are targeting ROACH you don't need to register/buy any cores from Xilinx. It is also nice to have an open source alternative which we can peak and poke. If anyone is interested, the code is here: http://casper.berkeley.edu/svn/trunk/mlib_devel_10_1/xps_lib/XPS_ROACH_base/pcores/xaui_phy_v1_00_a/hdl/verilog/ There is no real reason that this core couldn't be used in the other base projects (other than the fact it may be a tad green). Please feel free to test it! Cheers, David -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] Keeping DRAM from showing up in BORPH
Hi Glenn. You can save some brams with a relatively simple change in the async_ddr2 pcore. If you replace the existing bram fifos (512 deep) with distributed memory (16 deep) you save a number of brams (7, I think). There is also a substantial timing improvement. With ROACH in 10.1 this option is configurable through a yellow block checkbox and a pcore parameter. I've had a quick look at the 7.1 BEE2 DRAM CPU interface (the sniffer, as it is called), and that module seems to use only distributed ram and a little logic. I could be wrong though. Also it looks as though the "share with PPC" checkbox doesn't do anything on 7.1 and was recently removed. This option works on ROACH 10.1 though. Cheers, David I have a design which uses all four DIMMs on a BEE2 User FPGA. I have no need to access the DIMMs from BORPH or the PowerPC, and it seems like the interfaces to do so take up a fair amount of resources. Is there any (not too painful) way to remove those interfaces to free up the resources? Thanks, Glenn -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] problem of ADC 1.1 card with Roach
Hi Wan 1. I could not find the three control wires in the FPGA UCF file. You are quite correct, there was an error recently introduced into the ROACH base ucf, which should now be fixed (r1985). 2. After I add the three control wires into UCF file, I could not see the clock output from FPGA. I'm not sure what you mean here, please give more precise and detailed info of what you have and are doing. Do you have the ADC plugged into the ROACH with the sampling rate at four times the fabric rate? Do you have a led flasher application with an LED attached to counter? The ADC clock should always come through, provided there is a external clock plugged into the adc board, regardless of adc configuration status. If you are really stuck try modifying the EDK project to hook a counter directly onto the adc0_clk and attaching an led to the counter MSB. Anybody had used the ADC card with Roach? I been using the iADCs with ROACHs for about 7 months. Good luck. Cheers, David -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] problem of ADC 1.1 card with Roach
Hi Wan. > I find ADC chip is not set into a right mode because only 2 of 4 diff pairs > give me right data. So I find the 3 wire control pins are not allocated in > the UCF file. I modify the UCF file according to the schematic. Compare your pin constraints to those in the casper subversion repository, specifically the ucf file at: mlib_devel_10_1/xps_lib/XPS_ROACH_base/data/system.ucf. Perhaps it would be a good idea to rebuild your design using an up-to-date casper toolflow. I'm not quite sure what you mean by "2 of the 4 diff pairs". Are you seeing what looks like sensible data on two of the four byte lanes from a single ADC channel? > But I find I still could not get right data and I could not find right clock > from the 3 wire control clock. I don't follow. Are you probing the three wire interface on the ADC and are not seeing a clock or data? > I setup the FPGA clock coming from ADC card. So I think my fabric clock > should be 1/2 or 1/4 sample rate clock depending on the configuration of ADC > chip. Now I provide a 400MHz sample rate clock to the ADC card. You should expect the FPGA clock rate to be 1/4 (100MHz) with a configured iADC, 1/2 indicates that the iADC has not been configured correctly. > I have not made sense that what the counter you mentioned is? What's the > function? I suggest you set up an led-flasher in your simulink design so you can see that the clock is alive. > Any idea about my problem? I think, basically, the problem is the ADC chip > is not configured correctly. I agree. As before I suggest you rebuild your design with an up-to-date svn. I will build a basic adc design to test the toolflow and see if I have these problems. (I'm off sick so it won't be today, perhaps tomorrow) Regards, David -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
Re: [casper] maximum 10 GbE packet size
Hi All. On 10GbEv2 it is 8192, plus UDP and IP headers etc. But there would be no space for your application headers. This is correct, 8k is the V2 limit. There are a few problems with the current implementation, firstly it would be far more useful to support 8k data payload + some control/status info, which, I gather, is what you would like to do. Also the core will start telling you the fifo is always tell you that it is almost full for every packet, which makes backing off impossible. For these reasons I would like to add a 32 entries distributed ram augmentation fifo, to extend the capacity by 32 entries (32*8 bytes) without requiring an extra bram. Apologies for the lousy documentation, I have a knack at writing vague documents. I will have a go at getting this done tomorrow, I'll post when it looks ready. On the old Xilinx core, I seem to recall success with packet sizes up to 1100x64b. But this was a long time ago. So this might work for you, but YMMV. The old core can do 16k (less a few) packets, hence the high bram utilization. Cheers, David -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] maximum 10 GbE packet size
A note to all those who are interested in or are using the 10Ge V2 core, it now supports frame sizes of 8704 bytes, and will resolve the issues discussed earlier in this thread. These changes apply from CASPER SVN revision 2019. Cheers, David
Re: [casper] The max frequency of DD2 DRAM of ROACH
Hi Wan. The DRAM on ROACH is working and is relatively stable. I have used it in a few basic designs, but I wouldn't say it has been exhaustively tested. However, I would say it is ready for public consumption. From the yellow block you should select either 150, 200, 266, 300 or 333 MHz. Only these options are valid, other values will default to 266 MHz. 266 MHz is a safe options that seems to compile happily, I have run into timing problems with 300 MHz before and 333 MHz is ambitious to say the least. Cheers -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
[casper] A useful tool for making timing
Hi All. This might help 10.1 users with timing problems who are trying to tweak map and par settings. I've recently come across a tool which will run your fpga implementation several times with different map and par settings. You can run several builds simultaneously, useful if you have a multi-core processor with a lot of memory. This tool is only available on Linux. You use it like this: smartxplorer -l "hosts" -ra -part xc5vsx95t-ff1136-1 system.ngd hosts is a file which contains a list of hostnames (which can be multiple of the same host, which may include localhost). A report is attached which shows the best results for one of my designs. Hopefully we can find a sweet-spot and integrate it into the toolflow. Cheers, David -- FPGA SmartXplorer (tm) Version 10.1.03 -- Strategy : MapRunTime -- Run index : run1 Map options : -ol std -w Par options : -ol std Status : Done Achieved Timing Score : 482693 Current Best (Lowest) Timing Score : 482693 Current Best Strategy : MapRunTime -- -- Strategy : MapTimingExtraEffort1 -- Run index : run3 Map options : -ol high -xe n -w -t 3 Par options : -ol high -t 3 Status : Done Achieved Timing Score : 0 Current Best (Lowest) Timing Score : 0 Current Best Strategy : MapTimingExtraEffort1 -- -- Strategy : MapGlobalOpt -- Run index : run2 Map options : -ol high -xe n -global_opt on -retiming on Par options : -ol high Status : Done Achieved Timing Score : 2968 Current Best (Lowest) Timing Score : 0 Current Best Strategy : MapTimingExtraEffort1 -- -- Strategy : MapPhysSynth -- Run index : run4 Map options : -ol high -xe n -register_duplication -logic_opt on -w -t 9 Par options : -ol high -xe n -t 9 Status : Done Achieved Timing Score : 0 Current Best (Lowest) Timing Score : 0 Current Best Strategy : MapTimingExtraEffort1 -- -- Strategy : MapTimingExtraEffort2 -- Run index : run5 Map options : -ol high -xe n -w -t 8 Par options : -ol high -t 8 Status : Done Achieved Timing Score : 0 Current Best (Lowest) Timing Score : 0 Current Best Strategy : MapTimingExtraEffort1 -- -- Strategy : MapUseIOReg -- Run index : run7 Map options : -ol high -xe n -pr b Par options : -ol high Status : Done Achieved Timing Score : 12317 Current Best (Lowest) Timing Score : 0 Current Best Strategy : MapTimingExtraEffort1 -- -- Strategy : MapTimingExtraEffort3 -- Run index : run6 Map options : -ol high -xe n -w -t 7 Par options : -ol high -xe n -t 7 Status : Done Achieved Timing Score : 19455 Current Best (Lowest) Timing Score : 0 Current Best Strategy : MapTimingExtraEffort1 ---
Re: [casper] How to read and write ADC register
Hi Wan. It seems like you need to work out how the CASPER build works. A good thing to do would be to look at exactly how the iadc works. Look closely at the pcore, system.mhs and xps_library/*/* files. Find any mention of the 'adc' or 'xps_adc' in all the xps_library files and compare it to what you have for your custom adc design. The unix command 'grep' is useful for grovelling through files. Once you have seen how it has been done for the iadc, you should be able to understand/copy the mechanics for your own adc. Also have a look at the yellow block guide: http://casper.berkeley.edu/wiki/How_to_make_a_%22yellow%22_block Regards, David -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] SPI driver
Hi Homin. >> I am looking for a device driver for SPI which as a spare on the ROACH board. Did anyone try it in the ROACH/Linux environment ? I'm pretty sure no-one has used the SPI on ROACH yet, although I could be wrong. You might be the first... You probably have two options, first you could use the spare built-in PPC SPI/IIC port, which can be accessed using the SPI header (refdes: P4). I've poked around uBoot and there appears to be no support in the our svn version (and the denx git repository), which is an indicator that same will apply to the kernel. So there might be quite a bit of work getting the PPC SPI to work in both u-boot and linux. However, getting this to work may be beneficial to anyone else who wants to use SPI in the future. The second option, which I recommend, is to write an HDL SPI controller module for the V5 which you can lump together with your adc_controller. Have a look at the source below which controls the iADC: http://casper.berkeley.edu/svn/trunk/mlib_devel_10_1/xps_lib/XPS_ROACH_base/pcores/opb_adccontroller_v1_00_a/ http://casper.berkeley.edu/svn/trunk/mlib_devel_10_1/xps_lib/XPS_ROACH_base/pcores/adc_interface_v1_01_a/ With this you can configure your adc via borph, or uboot (using the mw and md commands), when your FPGA is programmed. Regards, David George -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] Virtex 5 Power Consumption Measurements
Hi Jonathan. The page at: http://casper.berkeley.edu/wiki/ROACH_Architecture says that the Actel-based Monitor/Management Subsystem "monitors the voltage and current draw of key power supplies on the board using on-chip ADCs".On the other hand the page at: http://casper.berkeley.edu/wiki/Roach_monitor_and_management_subsystem shows only OVP, UVP, and OTP thresholds. I've had another look at the actel current monitoring and it looks like it is broken (which is why it hasn't been added to the latter table). I've been meaning to fix this... If not: does anyone have any suggestions as to how to make such measurements? Or proxies? We are certainly capable of making a jig to insert a current meter on the ATX lines, though it is not clear whether such a measurement would be specific to the FPGA. If there is a way to interrupt the paths from the DC-DC converters, we might cautiously consider doing that too, though it's not preferred. There are current sense resistors on all the major supplies - you could measure the voltage drops there and calculate the power. Or you could use a power meter on the ATX and look at the delta after you program the FPGA, which is what we did here. Hope this helps. Regards -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] ADC initiate software
Hi Homin. The ROACH iADC is 'automatically' set up in gateware, have a look at the casper svn at: mlib_devel_10_1/xps_lib/XPS_ROACH_base/pcores/opb_adccontroller_v1_00_a At the time this was done BORPH wasn't quite ready and a software-free configuration mechanism was required. Currently the configuration could be performed using borph/tcpborphserver client. I don't think a borph iadc driver exists, but it would be a good thing to have. Regards, David
Re: [casper] Virtex 5 Power Consumption Measurements
Hello again. I have spent the day investigating the roach monitor current monitoring and now have some answers. I think you are saying that power supply current measurement capability has in principle been designed into ROACH, however for some reason this functionality is not yet working properly. You use the work "broken". Current monitoring has been designed into Roach hardware and is implemented on the roach monitor. As it turns out, it is working (with a few limitations) but I wouldn't consider it working well enough use for serious measurements. The current monitoring accuracy is limited by the sense resistor values. From observation the voltage drops across these resistors ranges from 0.5 to 20 mV. The Actel Fusion datasheet only provides accuracy information for inputs of greater than 50 mV. This raises a bit of a red flag as we have no guarantee on the accuracy on current roach builds. The resistor values could be increased to achieve this drop. However, on the supplies which draw high currents (1v0 1v5 1v8 2v5, ie the interesting ones) this isn't feasible due to the power that will be dissipated. Things might not be all that bad. It seems (at least for the single channel that I tested today) that the performance is fairly linear through the full range of voltages across the sense resistors. However, there is a fixed offset error. This fixed offset is fairly large when compared to the expected measurement. This was the main reason that I considered the current monitoring 'broken'. Although, perhaps, it could still be considered so given the Actel Fusion FPGA limitations. Right. So if you would like to use the current monitoring functionality on the roach, first read the current values with the board powered-off and use those to calibrate the fixed-offset for further measurements. As regards the current sense resistor idea: are you suggesting measuring voltages across resistors manually? I.e. is this independent of the Actel current measurements, or does the Actel sense those voltages? The Actel won't get the accuracy required to pick up the voltage difference across the two channels. For current monitoring the Fusion has an amplifier (which is the most likely cause of the fixed offset problems) We did consider measuring differential power with FPGA suspended and running. It is probably a workable idea, I would worry little about secondary causes of dissipation fudging the numbers, e.g. FPGA running causes heating causes fan to run faster. You could well be right. As I see it the major unknown is the efficiency of the power supplies which would be included in the overall power measurement. I think all those with Roach interests would be interested in your results, so best of luck! Regards, David George
Re: [casper] ADC initiate software
Hi Homin. I have read the VHDL code as you specified in last email. But i still can't find there is parallel to 3-wire serial mechanism in that file. That's because it is sneakily written in verilog; There are two parts to the opb_adc_controller. The first is the OPB interface, which has always existed, where you can configure the ADC via software. The second part is a verilog module, opb_adccontroller_v1_00_a/hdl/verilog/adc_config_mux.v This module includes a state machine to configure the ADC in standard or interleaved mode. When auto-config is enabled the three-wire interface is grabbed by the adc_config_mux rather than the obp controller. The auto-config function can be enable or disabled by software. Regards, David
[casper] Updated Linux Kernel
Hey Griffin. I have been using netboot on a few roach boards with pretty good success(3 of 4 working), but I have one roach which hangs at "roach_mmc: ROACH MMC driver" . I tried a few different version of uboot but with the same hang up. Is there something I am missing, is there any documentation on the mmc driver for the roach? Thanks. I suspect the kernel you are using doesn't check for the CPLD revision being compatible. This feature is implemented on the kernel at casper_svn:trunk/roach/sw/binaries/linux/uImage-rmon-20090904. This build includes lots of new features. These include: * power_management (shutdown -h turns off the roach, shutdown -r performs a hardware reset, pushing the power button will trigger a userspace shutdown) * sensors (with the right /etc/sensors3.conf (look in casper_svn:roach/sw/lm-sensors/) you can use the standard "sensors" command) * RTC (hwclock commands should now work) Just a brief warning, these features are all pretty bleeding edge. Try casper_svn:trunk/roach/sw/binaries/linux/uImage-vanilla-20090904 if you run into trouble. This build has no Roach MMC or Roach Monitor support. If you want MMC to work you will need to reprogram your CPLD with the latest binary using a Xilinx programmer. The latest binary sits at: casper_svn: roach/gw/binaries/roach_cpld/roach_cpld_8_0_1588.jed I hope this solves your problem. The MMC documentation is a tad thin. (Read non-existant:p) Cheers. -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
[casper] Roach MMC/SD support
Hello Casperites. Here is a quick howto to get MMC/SD cards working on ROACHs. First thing to do is program the CPLD with the latest roach_cpld design. You'll find this at: http://casper.berkeley.edu/svn/trunk/roach/gw/binaries/roach_cpld/roach_cpld_8_0_1588.jed Then use the latest Roach kernel at: http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/uImage-rmon-20090904 You can insert the card before booting or at any stage when the kernel running. The insertion detection is a little iffy, a bug in the driver. Sometimes when you plug the card in then out quickly it misses an event. Mostly it is fine though. You should see a message from the mmc-block driver that a card has been detected, like: mmc0: new high speed SD card at address b368 mmcblk0: mmc0:b368 SD993792KiB mmcblk0: p1 If you don't have an mmc device device file (like /dev/mmcblock1) file you can create one as following: mknod /dev/mmcblock1 b 179 1 Just make sure you are mounted write-enabled on you root fs. You can now mount it and do stuff like: roach:~# mount /dev/mmcblock1 /mnt/mmc/ roach:~# dd if=/dev/zero bs=4096 count=4096 conv=fdatasync > /mnt/mmc/test_data 4096+0 records in 4096+0 records out 16777216 bytes (17 MB) copied, 8.81871 seconds, 1.9 MB/s roach:~# dd if=/dev/mmcblock of=/dev/null count=40960 bs=4096 40960+0 records in 40960+0 records out 167772160 bytes (168 MB) copied, 37.4179 seconds, 4.5 MB/s The performance figures you above seem to be about the max, 1.9 MB/s write and 4.5 MB/s read. Note that the CPU usage is 100% during access (no DMA, lots of polling) so expect reduced performance during access. This is a bit of a pain, but hey - its not bad for a CPLD design. You can also 'run mmcboot' from uboot (if you are up to date) which will try to boot linux off an attached mmc/sd card. Just remember to install the latest kernel in uboot and install your etch filesystem on an ext2 formatted partition mmc/sd card. (note: you must use the first primary partition). Cheers. -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] Booting problem
Hello there. > > I set usbboot following this webpage: > http://casper.berkeley.edu/wiki/Roach_getting_started The wiki instructions you followed were slightly wrong. Setting initboot to usb boot makes it impossible to stop the u-boot boot process, which is useful if you want to change kernel etc. Luckily you should be able to clear the u-boot environment from linux as follows: dd if=/dev/zero bs=1024 count=256 | tr "\000" "\377" > /dev/mtdblock4 After you reboot you should be able to setup u-boot as set-out in the roach getting started guide: http://casper.berkeley.edu/wiki/Roach_getting_started Cheers. -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] ROACH file copy failure
Hey Laura. I screwed up the build with a check-in I made a week or so ago (now fixed). This is probably what caused your compile error. Synthesis failed; ngc file was not created; copy failed. If this was the case you would have seen a synthesis error earlier on. Cheers, David I'm trying to compile a design for ROACH and am getting an error when NGCBUILD runs. The design is David George's 1 million channel spectrometer. *** Running NGCBUILD ... ERROR:MDT - IPNAME:xaui_phy_0_wrapper INSTANCE:xaui_phy_0 - F:\Users\Laura\seti_roach\rmspec\XPS_ROACH_base\system.mhs line 957 - failed to move F:\Users\Laura\seti_roach\rmspec\XPS_ROACH_base\implementation\xaui_phy_0_wra pper.ngc to F:\Users\Laura\seti_roach\rmspec\XPS_ROACH_base\implementation\xaui_phy_0_wra pper\xaui_phy_0_wrapper.ngc ERROR:MDT - IPNAME:rmspec_tgec_wrapper INSTANCE:rmspec_tgec - F:\Users\Laura\seti_roach\rmspec\XPS_ROACH_base\system.mhs line 968 - failed to move F:\Users\Laura\seti_roach\rmspec\XPS_ROACH_base\implementation\rmspec_tgec_wr apper.ngc to F:\Users\Laura\seti_roach\rmspec\XPS_ROACH_base\implementation\rmspec_tgec_wr apper\rmspec_tgec_wrapper.ngc ERROR:MDT - IPNAME:xaui_phy_2_wrapper INSTANCE:xaui_phy_2 - F:\Users\Laura\seti_roach\rmspec\XPS_ROACH_base\system.mhs line 1011 - failed to move F:\Users\Laura\seti_roach\rmspec\XPS_ROACH_base\implementation\xaui_phy_2_wra pper.ngc to F:\Users\Laura\seti_roach\rmspec\XPS_ROACH_base\implementation\xaui_phy_2_wra pper\xaui_phy_2_wrapper.ngc IPNAME:rmspec_xsg_core_config_wrapper INSTANCE:rmspec_xsg_core_config - F:\Users\Laura\seti_roach\rmspec\XPS_ROACH_base\system.mhs line 251 - Running NGCBUILD *** The file that it's trying to copy is not in the XPS_ROACH_base\implementation folder. Any ideas? Laura -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] PowerPC U-Boot Configuration
Hi. > Hello > I had erased/corrupted the flash memory during updating and I used OCD > commander to program PPC's uboot over USBWiggler. Of course I had the > macro(program.mac), too. > I follow the web page: > http://casper.berkeley.edu/wiki/ROACH_Bringup#PowerPC_U-Boot_Configuration > > When I execute the OCD commander with macro, OCD commander show me a > lot of messages and the last line is "word 0x71000ffc = 0x4bfff004". > Then, OCD commander stop working It looks like you have the correct macro - you would typically get that macro from the roach production files at: http://casper.berkeley.edu/svn/trunk/roach/production/test_software/roach_testing/macraigor_macros/loadram_rinit_auto.mac The final command that the macro runs is 'exit', which closes OCD commander. So OCD commander closing unexpected is a feature not a bug! Once OCD commander quits you should start seeing activity on the serial port. Wait a while (more than 10s I think) until a character starts repeating (it looks like an S in hyperterminal). When this happens you are ready to transfer. Use XMODEM (not YMODEM) to xfer the u-boot.bin file. You'll find the latest file in: http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/uboot/ You should have uboot running after the xmodem transfer completes. Cheers. -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] PowerPC U-Boot Configuration
Hello again... > I try the mac file > http://casper.berkeley.edu/svn/trunk/roach/production/test_software/roach_testing/macraigor_macros/loadram_rinit_auto.mac > > it works. > But the ROACH can't complete the whole uboot process. > The screen only shows the message as follows: > --- > > U-Boot 2008.10-svn2226 (Aug 7 2009 - 16:06:44) > > CPU: AMCC PowerPC 440EPx Rev. A at 660 MHz (PLB=165, OPB=82, EBC=82 MHz) > No Security/Kasumi support > Bootstrap Option H - Boot ROM Location I2C (Addr 0x52) > 32 kB I-Cache 32 kB D-Cache > Board: Roach > I2C: ready > DTT: 1 is 30 C > DRAM: (spd v1.2) 1 GB > --- > > What's happened? Good question! I don't really have an answer. What I can say is that the next text output should be "FLASH: 64 MB". So I'm guessing something went wrong with your flash somehow. This could be a red-herring though. I would try the following before getting my hands really dirty: * Changing the boot configuration to CONFIG C by toggling CONFIG DIP 1 and then power cycling * Updating the CPLD, via Xilinx JTAG, with the newest design (you can find it at casper_svn:roach/gw/binaries/roach_cpld/ * Try reinstalling uboot using the macG tool If these fail I would then try dumping the External Processor Bus memory using the maccraigor tool. * First try dumping some memory at the CPLD Base to check that the EPB is working You should get something like this... > halt > word 1c000 20 C000: 007F0200 3100 0501 0501 C010: 01FF 0300 D00D0800 06340100 C020: 007F0200 3100 0501 0501 C030: 01FF 0300 D00D0800 06340100 C040: 007F0200 3100 0501 05010 * Next try dumping the flash contents to check that flash is working You should get something like this... >word 1fffa 20 FFFA: 27051956 552D426F 6F742032 3030382E FFFA0010: 31302D73 766E3232 32362028 41756720 FFFA0020: 20372032 30303920 2D203136 3A30363A FFFA0030: 34342900 FFFA0040: Next I would try loading uboot with the debug signatures enabled (see attached). If this fails I would use the debugger, or just lots of uboot debug messages, to find out where exactly the code got stuck. Please keep me posted on your progress. Good Luck, David
Re: [casper] 10 GbE Xilinx core
Hi Laura. Currently you require the free xilinx xaui phy core (you can download it off the web). The opensource xaui is slightly broken in svn and is disabled (I'll try to fix it this week). Cheers, David Hallo, Quick question... Does the new 10 GbE block for ROACH require any Xilinx licensed cores? And if so, which one? Thanks, Laura -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] PowerPC U-Boot Configuration
Great news! It might have been caused by the updated uboot. It would be interesting to see if the old uboot works with the old dimm(it would be great if you could check this). I did notice that you were using a dual-rank 1GB dimm, while we are using single rank 512MB dimms here. Glad you came right. Cheers, David > Dear David > > You are right. > I change another DDRII ram, it works!!! > Before this ROACH was broken, this DDRII is OK... > After all, thanks for your help very much. > > Regards A-Hsin > > - Original Message - From: "David George" > > To: "C-H Cheng" > Sent: Thursday, September 17, 2009 6:12 PM > Subject: Re: [casper] PowerPC U-Boot Configuration > > >> It fails before flash initialization, so it is likely a ddr2 problem. >> Try another ddr2 dimm, registered is fine, any size and any speed. >> I'll try to see what could go wrong... >>> Hi David >>> >>> After trying the debug.bin file, I get some message:(also I config to >>> CONFIG C in SW3) >>> - >>> >>> >>> U-Boot 2008.10-svn2009 (Jun 23 2009 - 15:08:44) >>> >>> CPU: AMCC PowerPC 440EPx Rev. A at 528 MHz (PLB=132, OPB=66, EBC=66 >>> MHz) >>> No Security/Kasumi support >>> Bootstrap Option C - Boot ROM Location EBC (16 bits) >>> 32 kB I-Cache 32 kB D-Cache >>> Board: Roach >>> I2C: ready >>> DTT: 1 is 27 C >>> DRAM: (spd v1.2) 1 GB >>> ok705ffe44 >>> >>> >>> U-Boot 2008.10-svn2322 (Sep 17 2009 - 11:08:33) >>> >>> CPU: AMCC PowerPC 440EPx Rev. A at 528 MHz (PLB=132, OPB=66, EBC=66 >>> MHz) >>> No Security/Kasumi support >>> Bootstrap Option C - Boot ROM Location EBC (16 bits) >>> 32 kB I-Cache 32 kB D-Cache >>> Board: Roach >>> I2C: ready >>> DTT: 1 is 28 C >>> DRAM: dram: about to probe chip 0x50 >>> (spd v1.2) dram: raw >>> 80 08 08 0e 0a 61 40 00 05 30 45 00 82 08 00 00 >>> 0c 04 38 01 02 00 03 3d 50 50 60 3c 1e 3c 2d 80 >>> 20 27 10 17 3c 1e 1e 00 00 3c 69 80 18 22 00 00 >>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 72 >>> dram: ddr2 memory >>> dram: bus speed 13202Hz >>> dram: refresh rate 7812500ps >>> dram: 0x2 = 0x >>> dram: controller caps 0x020c0e00 >>> dram: 0x0 = 0x190a >>> dram: 0x1 = 0x0100 >>> dram: burst length caps=0xc, chosen=4 >>> dram: latency choices 0x38 >>> dram: can do cl=5 >>> dram minclock: 45...@13202hz -> 0 >>> dram: can do cl=4 >>> dram minclock: 50...@13202hz -> 0 >>> dram: can do cl=3 >>> dram minclock: 60...@13202hz -> 0 >>> dram: selected cas=3, X-2 >>> dram: 0x3 = 0x02030602 >>> dram trc: 6000...@13202hz -> 7 >>> dram trrd: 750...@13202hz -> 0 >>> dram trtp: 750...@13202hz -> 0 >>> dram: 0x4 = 0x08010100 >>> dram trp: 1500...@13202hz -> 1 >>> dram tras: 4500...@13202hz -> 5 >>> dram: 0x5 = 0x02020206 >>> dram twtr: 750...@13202hz -> 0 >>> dram trfc: 10500...@13202hz -> 13 >>> dram: 0x6 = 0x0101c80e >>> dram: 0x7 = 0x000d0101 >>> dram: 0x8 = 0x02c80001 >>> dram: 0x9 = 0x00011d5f >>> dram: 2 ranks >>> dram: 0xa = 0x0300 >>> dram: each rank 512Mb >>> dram txsnr: 11500...@13202hz -> 15 >>> dram: 0xb = 0x0010c800 >>> dram: tckmax is 8000ps, arb tcke set to 3 >>> dram: 0xc = 0x0003 >>> dram: memory is probably unbuffered >>> dram: 0xe = 0x >>> dram: 0x11 = 0x1900 >>> dram: 0x12 = 0x19191919 >>> dram: 0x13 = 0x19191919 >>> dram: 0x14 = 0x0b0b0b0b >>> dram: 0x15 = 0x0b0b0b0b >>> dram: 0x16 = 0x00267f0b >>> dram: 0x17 = 0x >>> dram: 0x18 = 0x01010002 >>> dram tref: 781250...@13202hz -> 1031 >>> dram: 0x1a = 0x5b260408 >>> dram: 0x1b = 0x0800682b >>> dram: 0x1c = 0x >>> dram: 0x1f = 0x >>> dram: got 14 row addresses, limit 14 >>> dram: 0x2a = 0x0006 >>> dram: have 4 banks >>> dram: got 10 column addresses, limit 12 >>> dram twr: 1500...@13202hz -> 1 >>> dram: 0x2b = 0x020a0200 >>> dram trcd: 1500...@13202hz -> 1 >>> dram: 0x2c = 0x0002 >>> dram: making memory go >>> dram: 0x2
Re: [casper] More Versatile 10Ge Block(s)?
Hey Randy. Are there any modified 10Ge blocks available which support transmitting other than 64 bits per clock cycle (or 64 bits per two clock cycles at higher clock rates) in order to accommodate widely ranging FPGA clock frequencies while still maintaining approximately 10Gbps? Any XAUI-based 10Ge implementation is fixed to four byte lanes (32 bits) at 312.5 MHz. Further, the Xilinx implementation limits you to 64-bit at 156.25 MHz. So fundamentally you have a 64 bit interface. For convenience the Casper 10Ge blocks stuck with 64 bit on the user interface. It would be conceivable to change the user bit width to any multiple or factor of 64 and use multiplexors internally to make the 64 bit for the 10ge interface. However, this function can be more easily and flexibly done in the application interface using the the application 'data valid' signal. Regards -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] Using "ten_GbE_v2" above 120MHz...
Hi Randy. > In the block documentation regarding use of the "ten_GbE_v2" block, > there's no mention > of the requirement to clock data into the TX fifo on every other clock > cycle when running > much above 120MHz. I assume that this requirement, which was explained > in the block > documentation for the original "ten_GbE" block, applies to v2 as well. > Is this correct? There are two ways you can prevent TX overflows with the ten_Gbe_v2 block. The first is rate matching which involved clocking in data at a certain rate, for instance every other cycle, so that the data rate in just less than 10Gbps. This is what is described in the old 10Ge doc. A note on this; 10Ge is pretty efficient with large packet - so I wouldn't worry about rate matching until 145-150 MHz (156.25 is exactly 10Gbps). Though it is better to be safe than sorry. The second way of preventing overflows, which allows 100% utilization, involves using the flow control signals. Basically keep clocking in data until the "tx almost full" flag goes high after which back-off transmitting until the flag is cleared. When this flag goes high you have 4 free slots in the TX FIFO (I think it is actually more, but rather be safe). This means you have some time to back-off your tx state machine and don't need to cause undue timing hazards. Rate matching is sometimes the easiest, but won't get you maximum performance. Cheers, David George -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
[casper] Using mlib_devel_10_1 with Matlab 2008b & ISE 11.3 on 64-bit Linux
Hello All. I am pleased to report that the mlib_devel_10_1 libraries now work with ISE 11.3 on Linux! This is a very early announcement - I have been using the tools on Linux for two days now. However, I have successfully compiled a moderately complicated design. This design, a 1M channel ROACH Spectrometer, contains the following: * 12-Tap PFB_Fir_Real * 11k 4-input FFT_Wideband_Real * A QDR Corner Turn * a 1k Biplex real FFT * A QDR Vector accumulator * a DRAM buffer * a BRAM VACC * 2x10GE_v2 In short, this tests quite a few of the CASPER blocks. Here are a few of the advantages to using Linux and XSG 11.3: * 64-bit means the end of running out of memory for compiles (no /3GB windows nonsense) * Multiple users can run the tools on a server with very little slow-down (a product of being able use more memory) * I have noticed a major speed-up when updating/redrawing blocks (around a factor of 4) * I have also noticed a speed-up in map/par compile times (This may have been specific to my design) * Most importantly you would no longer need to run Windows! It is important to note that the 11.3 tools do not support Virtex-II pro boards ie iBOBs and BEE2s. The only other catch (so far) is the new draconian licensing for both Matlab 2008b and ISE 11.3. I have started a wiki page which contains information on installing and running system generator on Linux: http://casper.berkeley.edu/wiki/Linux_xps Cheers, David -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
[casper] A revision control library block for your application model file
Hello all. I've made a basic revision control block that tries to provide revision information for an application model file via a few shared registers. It exports the following things to the processor: * A 32-bit major revision number (set as a mask parameter) * A 32-bit minor revision number (set as a mask parameter) * A 31-bit revision control number (typically would be an svn revision extracted through a system call) * A single bit indicating that the current build is dirty. Currently the only clients supported are tortoiseSVN and unix 'svn'. You just need to add tortoiseSVN to your path in your startup batch (.bat) file. I adding this to mine: set RCS_BIN="C:\Program Files\TortoiseSVN\bin" set PATH=%RCS_BIN%;%PATH% I will try to add something equivalent for the mlib libraries. Hopefully this will help people keep track of their versions. Cheers. -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] Slow HD write speed
Hi Kjetil. So, we have a ROACH system that we have set up to boot via usbboot into a full debian etch filesystem. The problem is that we get extremely low write speeds to the disk. In the order of a couple of Mbit/s. The problem might be that your root filesystem is mounted with the 'sync' flag. Edit your /etc/rcSimple file (Init runs this script first); if you have something like: mount -o remount,rw,sync,noatime / change it to something like: mount -o remount,rw,noatime / This was my mistake - I though it would be a good idea for SD/MMC card access to be synchronous. Turns out it wasn't really. Perhaps a filesystem update is on the cards. The other problem is the AMCC PPC440EPX USB seems to misbehave quite badly. I have been fiddling around for a day or so, trying to work out why one of our flash sticks doesn't work reliably. Firstly, there is a known issue for the PPC440EPX USB that can lead to screw-ups when both OHCI and EHCI Linux drivers are loaded. https://kerneltrap.org/mailarchive/linux-usb/2008/11/2/3900114 There are fixes (hacks) in the upstream kernel, but we are running off the old "ppc" tree and updating to the new "powerpc" is not an insignificant task (It will probably happen this year though). I think this leads to USB devices falling over to OHCI (full-speed) even when they are EHCI(high-speed) compatible. This leads to data-rates of 1-2 MB per second. This could also be your problem. Now in theory, if you compile a kernel with just EHCI (high-speed mode) your USB devices should work at high speeds (9+ MB per second). However, I have seen very weird behaviour on one specific flash drive here with just EHCI compiled in. When I first insert the device the usb driver spews out errors. Then if I put in another device, which happens to work, and reinsert the old flakey flash drive it works fine from then on. This makes me think there is some software/setup problem. The same flakey device always works in OHCI mode when EHCI hasn't been compiled into the kernel. In summary - USB on ROACH has some known problems which will hopefully improve when we update to the new mainline kernel. If you are having reliability trouble try compiling a kernel without EHCI. If you want maximum performance try compiling without OHCI. Also make sure that your root filesystem isn't mounted 'sync'. Regards, David -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] The Roach GPIO error in casper library
Hi Wan When I use ROACH:GPIO in casper library, I was told "undefined routing table for hardware system: ROACH(gpioA)". This error indicates that the bus you have selected (gpioA) hasn't been populated in the BEE2_hw_routes.mat routing table. The routing table contains the mapping between the various GPIO busses, e.g zdok/leds, and theirs associated pin locations (ucf pin constraints). I recommend that you load the file into matlab and fiddle around with it, you'll get the idea. As of the 14th of August 2009 the single-ended IO on ROACH has been integrated into the casper toolflow. After updating your svn you should see gpioa, gpioa_oe_n, gpio_b and gpio_b_oe_n in the GPIO block. If you don't, try reverting to the library gpio block. These should provide you with access to the ROACH single-ended GPIO. You should note that you need to control the direction buses of the GPIO using the gpioa_oe_n and gpiob_oe_n output enables signals. So setting gpioa_oe_n to '0' (active low) will set the whole gpioa bus to outputs and '1' to inputs. Regards, David -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] ROACH clocks and chassis setup
Hey Griffin. Also, when hooking a ROACH up in a chassis where does the power switch and LED cables go? Could someone send me a picture or schematic of this perhaps? Thanks. On the clocks: arb_clk is a configurable-frequency, internal clock derived from the system clock using DCMs aux_clk0 and aux_clk1 correspond to the two clock inputs near the ZDOKs (J13 and J14) (not sure which is which) Also, when hooking a ROACH up in a chassis where does the power switch and LED cables go? Could someone send me a picture or schematic of this perhaps? Thanks. The cables hook onto the J7 connector in the corner. You just need to follow the silkscreen labels. The only gotcha is that you need to connect the power switch to CHS_SW not PWR. Hopefully this stuff will be documented properly. Some day. Cheers, David -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] I2C driver
Hi Mellisa. Have you already developed an I2C driver for the ROACH board? I've added the iic master controller I wrote for our katadc to the casper svn at: http://casper.berkeley.edu/svn/trunk/mlib_devel_10_1/xps_lib/pcores/kat_iic_controller_v1_00_a/ It is a very simple interface, designed to handle high latency (tcpborphserver). There is some documentation at: http://casper.berkeley.edu/svn/trunk/mlib_devel_10_1/xps_lib/pcores/kat_iic_controller_v1_00_a/doc/ Currently it is in no way integrated into the toolflow. Cheers, David -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] Xilinx MAXDELAY constraint compiler bug
Hey Suraj. I've been working on Verilog code that requires the application of a MAXDELAY constraint to an 8 bit data bus output from a register explicitly forced into the Input/Output Buffer. When I apply the constraint to the whole bus, PAR results show that the Xilinx tools attempt to apply a MAXDELAY of 0 ns to bit 6 ONLY, while properly applying the MAXDELAY = 2 ns to the other bits. This result is the same over each of the 16 busses to which I have applied this constraint. A workaround I am using right now is to apply the constraint to each individual bit, but this prevents me from parameterizing the module how I would like to. Does anybody know either (1) how I can use some equivalent of a Verilog generate to make sure that the constraint gets applied to each bit of an arbitrary width bus, or (2) why the constraint gets misinterpreted? This is an interesting problem that I have run into and, up until now, never found a solution to. However, today I cracked it. Consider this verilog code snippet: wire [3:0] leddies_reg; wire [3:0] leddies_int; genvar gen_i; generate for (gen_i = 0; gen_i < 4; gen_i = gen_i + 1) begin: max_delay_gen (* MAXDELAY = "8 ns" *) wire int0 = leddies_reg[gen_i]; assign leddies_int[gen_i] = int0; end endgenerate This will attach the MAXDELAY constraint by attaching the constraint to the intermediate int0 wire, and using that wire to connect the target(leddies_reg) to the intermediate(leddies_int) one by one. It ain't pretty but it works. Also I'm damn sure that there is some kind of xilinx bug with attaching constraints to buses. In my opinion: wire [7:0] mybus //synthesis attribute MAXDELAY of mybus is 2 ns or (* MAXDELAY = "2 ns") wire [7:0] mybus; should both work. But they don't. For some reason, as you have experienced, some net get the constraint and some get 0ns. I'm almost 100% that this is a xilinx bug. Hopefully this helps. Cheers, David -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
[casper] MSSGE 11.3 weirdness: Undefined variable "com" or class
Hi All.
It appears that if sysgen crashes enough it seems to unload itself for
some reason.
If you see this error:
??? Undefined variable "com" or class
"com.xilinx.sysgen.XFixJavaLoader.setClassLoader"
Try running
xlAddSysgen(getenv('XILINX_DSP'))
Cheers,
David
--
David George
Digital Design Engineer
Karoo Array Telescope
Tel: +27 21 531-7282
Fax: +27 21 531-9761
Email: david.geo...@ska.ac.za
Web: www.ska.ac.za
Re: [casper] Reference to non-existent field 'clock_loc'
Hi All. Quite magically my installation started exhibiting this problem as this thread opened up. I have been fiddling around with this and have nailed down the problem (In my case) to one statement in xps_xsg_conf_mask.m: xlsetparam(xsg_blk,... 'directory', ['./',clear_name(get_param(gcb,'parent')),'/sysgen'],... 'sysclk_period', num2str(1000/clk_rate),... 'compilation', 'NGC Netlist',... 'ngc_config',ngc_config,... 'synthesis_language', 'VHDL'); Changing this to: xlsetparam(xsg_blk, 'directory', ['./',clear_name(get_param(gcb,'parent')),'/sysgen']); xlsetparam(xsg_blk, 'sysclk_period', num2str(1000/clk_rate)); xlsetparam(xsg_blk, 'compilation', 'NGC Netlist'); xlsetparam(xsg_blk, 'ngc_config',ngc_config); xlsetparam(xsg_blk, 'synthesis_language', 'VHDL'); Fixes the problem for me but causes the Xilinx block to take a quite a bit longer to update. I would be interested if this solves it for anyone else. Cheers, David -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] interrupt the booting process
Hi Zhiwei. If the bootcmd and bootdelay have been set up properly you should be able to press the anykey while the "Hit any key to stop autoboot: 10-9-8-7-etc" message appears. I suspect you may have set the wrong environment variable or perhaps the environment became corrupt. It should be possible to clear the environment from linux though. Uboot will use the default, compile time, values. So hopefully following these steps will fix your problem: * boot linux * cat /dev/zero > /dev/mtdblock4 * reboot Be careful which partition you zap because it is possible to clobber uboot. I would first check that it is the environment variables by running "cat /dev/mtdblock4 | hd |head". Ensure that you never change the initboot and preboot commands. Cheers, David > Mark, > > I tried removing the usb stick, and it ended up with the error: > > Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(2,0) > Rebooting in 180 seconds.. > > I tried several times, it cannot even get to the busybox. > > Zhiwei > > > On Wed, Jan 20, 2010 at 3:37 PM, Mark Wagner > mailto:mwag...@eecs.berkeley.edu>> wrote: > > Hi Zhiwei, I'm not sure if this will help, but have you tried > removing the usb stick? > > Mark > > On Wed, Jan 20, 2010 at 11:45 AM, Zhiwei Liu <mailto:zhiwei@gmail.com>> wrote: > > Jason, > > I was trying to update the uboot for my roach board following > the instruction from: > http://casper.berkeley.edu/wiki/ROACH_kernel_uboot_update > But I cannot interrupt the booting process, it always boots > from the USB stick. (I save the bootcmd environment to run > usbboot) > I tried every key to stop the booting process(ctrl-c, ctrld-d, > ctrl-z, space, etc.), no one works. > Is there any way I can interrupt the booting process, so I can > type the uboot command, following the update procedure. > Or is there any way I can clear the uboot environment without > booting into the uboot. > > -- > Zhiwei Liu > > > > > > -- > Zhiwei Liu -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
Re: [casper] filesystem update
Hey Mark. I would check my /dev/ entries. Remember they cannot be extracted by non-root, they might have gone missing. Cheers, David I updated my usb stick to the filesystem: http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/filesystem/filesystem_etch_2009-11-30.tar.bz when I 'run usbboot' I get to: sd 1:0:0:0: [sda] 15794175 512-byte hardware sectors (8087 MB) sd 1:0:0:0: [sda] Write Protect is off sd 1:0:0:0: [sda] Assuming drive cache: write through sd 1:0:0:0: [sda] 15794175 512-byte hardware sectors (8087 MB) sd 1:0:0:0: [sda] Write Protect is off sd 1:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 1:0:0:0: [sda] Attached SCSI removable disk EXT2-fs warning (device sda1): ext2_fill_super: mounting ext3 filesystem as ext2 VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 136k init Warning: unable to open an initial console. warning: `ntpd' uses 32-bit capabilities (legacy support in use) and then the boot process freezes. I've repartitioned and rebuilt the filesystem as ext3 and then simply copied (cp -rp) over the files as i've done on other working usb sticks. Any suggestions? Thanks, Mark -- David George Digital Design Engineer Karoo Array Telescope Tel: +27 21 531-7282 Fax: +27 21 531-9761 Email: david.geo...@ska.ac.za Web: www.ska.ac.za
[casper] roach II design review docs
To all those who will be listening in on the ROACH II review today here are some documents that might come in handy: The ROACH II wiki page: http://casper.berkeley.edu/wiki/ROACH2 <http://casper.berkeley.edu/wiki/ROACH2>The ROACH II block diagram: http://casper.berkeley.edu/svn/roach2/doc/blockdiagram/roach2_block_diagram0.4.pdf ROACH II Design Review presentation: http://casper.berkeley.edu/svn/roach2/doc/review/ROACH%20II%20Review.pdf Cheers, David -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
[casper] Roach II schematics
Hi all. To those who may be interested, you can grab a prelim version of the schematics here: http://casper.berkeley.edu/svn/roach2/elec/roach2/schematic/roach2_0_0.pdf -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
Re: [casper] IOB conflict between ADCs and GPIO banks
Hey Billy. On 17 March 2010 20:03, Billy Mallard wrote: > Hi all, > > I'm trying to add some GPIO outputs to a ROACH design that uses two > ADCs, but ISE seems to be having trouble simultaneously routing IOBs > for the ADCs and the GPIO banks. Has anyone encountered this? > > I'm using 7 out of 8 pins on a single bank, all as outputs, and i've > tried each bank (A and B) independently. The ADCs are the new 3GSps > NatSemi ones. > > Billy > > The GPIO ports had the incorrect IO voltages assigned to them and ISE was complaining about mixed voltage levels on a single bank. This is now fixed in SVN. Cheers, David -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
[casper] Optimized software registers
Greetings All. I've done some optimization on the ROACH software registers and it has turned out to be pretty fruitful. The powerpc to simulink register utilization has been reduced from 99 to 26 slices (3.8x less). The simulink to powerpc register utilization has been reduced from 72 to 25 slices (2.9x less). This should help out with utilization if you use a lot of software registers (eg the packetized correlator). These changes apply from svn revision 2945. Cheers, David -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
Re: [casper] Optimized software registers
Hi Aaron. Nice work! Are there any tantalizing details you might be able to > pass along as to what changes made the difference? I always like the > lessons-learned section... > Sure, there were two things optimized: The first was an unnecessary OPB to IPIF bridge. This was an artefact from using the EDK GUI to create OPB modules. Rather than using this mechanism, I wrote the module with a direct OPB connection (which is simpler and easier to follow in my opinion) The other optimization was to trim the extras that were accessible from software (these included locks and status bits). I'm not sure that these features were ever used and are definitely not required for BORPH. I think that the registers are now as simple as they could be. Cheers, David > > On Mon, Apr 19, 2010 at 7:34 AM, David George > wrote: > > Greetings All. > > I've done some optimization on the ROACH software registers and it has > > turned out to be pretty fruitful. > > The powerpc to simulink register utilization has been reduced from 99 to > 26 > > slices (3.8x less). > > The simulink to powerpc register utilization has been reduced from 72 to > 25 > > slices (2.9x less). > > This should help out with utilization if you use a lot of software > registers > > (eg the packetized correlator). > > These changes apply from svn revision 2945. > > Cheers, > > David > > -- > > David George > > Karoo Array Telescope > > Tel: +27 21 531-7282 > > Email: david.geo...@ska.ac.za > > > > > > -- > Aaron Parsons > > 510-406-4322 (cell) > Campbell Hall 523, UCB > -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
Re: [casper] Optimized software registers
Hey Henry. I think they will be little difference in practice. Perhaps a cycle less latency, but that is hard to say as I'm not really sure what was going on in the OPB-IPIF bridge. In principle the OPB-IPIF bridge might support bursting(for DMA) a little better. But I'm pretty sure DMA isn't used on software registers or anywhere else for that matter (certainly not on ROACH). The difference should only be in utilization. I've had a close look at the extra features in the old software registers and they are entirely superfluous. These could be removed on iBOB on BEE2 base package for a little extra saving there. Cheers, David On 21 April 2010 22:12, Henry Chen wrote: > 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 >>pass along as to what changes made the difference? I always like the >>lessons-learned section... >> >> >> Sure, there were two things optimized: >> >> The first was an unnecessary OPB to IPIF bridge. This was an artefact from >> using the EDK GUI to create OPB modules. Rather than using this mechanism, I >> wrote the module with a direct OPB connection (which is simpler and easier >> to follow in my opinion) >> The other optimization was to trim the extras that were accessible from >> software (these included locks and status bits). I'm not sure that these >> features were ever used and are definitely not required for BORPH. I think >> that the registers are now as simple as they could be. >> >> Cheers, >> David >> >> >> >>On Mon, Apr 19, 2010 at 7:34 AM, David George >>mailto:david.geo...@ska.ac.za>> wrote: >> > Greetings All. >> > I've done some optimization on the ROACH software registers and >>it has >> > turned out to be pretty fruitful. >> > The powerpc to simulink register utilization has been reduced >>from 99 to 26 >> > slices (3.8x less). >> > The simulink to powerpc register utilization has been reduced >>from 72 to 25 >> > slices (2.9x less). >> > This should help out with utilization if you use a lot of >>software registers >> > (eg the packetized correlator). >> > These changes apply from svn revision 2945. >> > Cheers, >> > David >> > -- >> > David George >> > Karoo Array Telescope >> > Tel: +27 21 531-7282 >> > Email: david.geo...@ska.ac.za <mailto:david.geo...@ska.ac.za> >> >> > >> >> >> >>-- >>Aaron Parsons >> >>510-406-4322 (cell) >>Campbell Hall 523, UCB >> >> >> >> >> -- >> David George >> Karoo Array Telescope >> Tel: +27 21 531-7282 >> Email: david.geo...@ska.ac.za <mailto:david.geo...@ska.ac.za> >> > -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
Re: [casper] ROACH File I/O Bottleneck
Hi All. Just a few comments on bus performance. The processor bus is 16 bits at 66 MHz (or 83), so the theoretical maximum is 133 MB/s. There are 3 cycles bus overhead per transaction (for registering etc in FPGA) and an extra two or so for for accessing the register/bram. So that is roughly a bus efficiency of 1/5, so that puts the max at around 27MB/s. Incidentally, this could be improved to close to 100% by implementing a bursting/DMA scheme (this would affect BRAM access only). This will require a little work and would use the other FPGA/PPC chip select. Beyond this there are perhaps one or two cycles overhead for CPU access. So from borph you should be getting around 20 MB/s. Currently, the processor manages to program the FPGA, transferring 5MB, in around 100ms (50MB/s). Although this isn't quite a fair comparison, it gives an idea as to what speeds should be expected when accessing brams. Cheers, David
Re: [casper] GPU Spectrometer
Hi John. > > > I know folks are working on a hybrid spectrometer using roach/ibob and > GPU's. I am in need of a 1M channel, 2 pol, 400 MHz spectrometer. Anyone > offer up their design as a possibility? I think GUPPI maybe could do it, > but I wonder if anyone else has gotten anything going. Or could you build > such beast with just a roach or 2? > > > > A while ago I made a 1M channel, single pol, 500 MHz spectrometer on a single ROACH. The project folder is here: http://casper.berkeley.edu/svn/trunk/projects/roach_mspec/ Have a look at the block diagram, which should give an idea of the design: http://casper.berkeley.edu/svn/trunk/projects/roach_mspec/doc/roach_mspec.pdf The FPGA utilization was as follows: 90% of slices, 21% DSP, 35% BRAM There was also lot of room for optimisation. For example, the qdr vector accumulator + DRAM buffer could have been replaced just a DRAM vector accumulator. Also lots of slices could be freed up by using DSPs. The other bonus is you would clock your FPGA 50 Mhz slower. I think you could comfortably do dual-pol with 2 ROACHs. Cheers, David -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
Re: [casper] ROACH bootstrap configuration info
Hi David and Jason. I created a mantis issue for getting access to those parameters: http://casper.berkeley.edu/mantis/view.php?id=30 You will need kernel support for those features - a little bit of work but it shouldn't be too hard. The all zeros bug already had a tracker: http://casper.berkeley.edu/mantis/view.php?id=3 It is a pretty serious problem and I'll try to find time in the next few weeks to zap it. The FPGA should be able to handle the 83 MHz bus. The real headache is that it did at some point. Cheers, David -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
Re: [casper] ROACH bootstrap configuration info
Hi David. > 1) The UFC version > 2) The STP version You can grep the kernel log (dmesg), look for Roach Montior > 3) The CPLD version Currently this is not accessible, could easily be reported by mmc driver in kernel log > 4) The bootstrap configuration used by the AMCC (maybe accessible via > /dev/mem?) This is currently not accessible, but could probably reported in the kernel log. You should be able to get the uboot revision from the mtd device file, exactly how I'm not sure. Grepping might help. The real trick would be to make these bit easily accessible from userspace, rather than parsing the kernel logs. I would think sysfs entries would be ideal, but this would require real work. Cheers, David -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
Re: [casper] .bof generation problems
Hi Suraj. If the V6 programming failed, you should see a message in dmesg saying about the done pin not going high. Also make sure you haven't compiled for the LX110T if you have an SX95T board, or vise virsa. Regards, David On 27 July 2010 21:44, Suraj Gowda wrote: > Hi Dave, > > The file permissions are > -rwxr-xr-x 1 43845 300 4469095 Jul 26 2010 1.bof > -rwxr-xr-x 1 43845 300 4469090 Jul 22 2010 2.bof > > Also, the MD5 checksum of the .bof running on the roach matches the > original. > > Thanks, > -Suraj > > On Tue, 27 Jul 2010 10:57:59 -0700, David MacMahon > wrote: >> On Jul 27, 2010, at 10:33 , Suraj Gowda wrote: >> >>> When I try to run the .bof from the ROACH command line, it returns >>> with >>> "Input/Output Error". The ROACH is NFS mounted and I put the bof >>> in the >>> filesystem via scp. >> >> Sounds like a corrupted/incomplete bof file. What are its >> permissions on the ROACH (i.e "ls -l 1.bof")? Does it have the same >> checksum on the ROACH as it does where you created it? >> >>> One strange thing I've noticed is that sometines mkbof creates a >>> file that >>> is executable and sometimes it doesn't and I have to manually set >>> it as >>> executable. Is this a sign that maybe it's quitting early? >> >> I don't know, but I agree that it sounds fishy. >> >> Dave > > -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
[casper] Sporadic ROACH Power-up issue
Hi all. If your new ROACH boards have been exhibiting strange and random power-up behaviour you should be able to solve the problem. The Actel Fusion device is most probably not receiving an adequately long power-on reset pulse. Changing capacitor C33 from 0.01uF to 0.22uF (or 0.1uF) increases the pulse width and makes the part behave as it should. You can test whether this is indeed the issue affecting your ROACH by pushing the chassis reset button. If the behaviour returns to normal, then you should change the cap. Regards, David -- David George Karoo Array Telescope Tel: +27 21 531-7282 Email: david.geo...@ska.ac.za
Re: [casper] ROACH bootstrap configuration info (fix for read back all '0's)
Hi Dave and casper. > We've been experiencing some flakey behavior on some ROACH boards. The > symptom was that data written to a software register after programming a bof > file would sometimes not read back properly (we got all 0's). I know this is a fairly old issue but one that turns out to crop up even in bootstrap option C (ie at bus speeds of 66MHz). I'll summarize the symptom again: Sometimes when you program the FPGA the configuration seems not to 'take; all you get are '0's on reads. It turns out to be a really weird problem. Basically the configuration works fine, the CRC checks out, the FPGA makes it through its internal boot sequence, BUT (and it is a big but) it 'forgets' to enable the IOs. So basically your FPGA is configured ok, but all the IOs are in tri-state. Why this happens, I do not know. However, you can check to see that is has happened by doing a jtag FPGA status read using the impact tools. What you'll see in the log is this: status of GTS_CFG_B : 0 This indicates that the IOs are stuck in tri-state. This is the only difference between a configuration that works and one that returns all zeros. There is a work-around, which involves telling the FPGA to enable the IOs earlier in the boot sequence. You do this by modifying the following line in XPS_ROACH_base/etc/bitgen.ut: -g GTS_cycle:5 to -g GTS_cycle:2 This fix seems to work for us. The reason why the original setting occasionally doesn't work is a mystery to me. The other interesting thing is that it has only crept in recently ie in newer boards. This makes me think that it could be a silicon issue. That is just speculation. I will be pushing this change up to the casper kat repo some time. (when I can get git to work) Kind regards, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
Re: [casper] How to disable the 'bee_xps' timing check?
Hi Guy. > > To disable the PAR timing check: > > 1> Disable the "Treat timing closure failure as error" option from the > Project Options dialog in XPS. > > OR > > > 2> Type following at the XPS prompt: > XPS% xset enable_par_timing_error 0 Your design has not made timing. You can generate your bitstream if you disable the "Treat timing closure failure as error" option (you can do this by modifying the edk project file, system.xmp). This is REALLY, REALLY NOT recommended. Your design will, in all likelihood, not work as expected at the desired clock frequency. What you need to do is look at your timing report and identify the blocks in your simulink design which are causing problems. (you will find the timing report in XPS_ROACH_base/implementation/system.twr) It is somewhat of a dark art interpreting the .twr file, which I wont cover here. Once you have identified the problem block you need to adjusting the latency for the primitives that are causing the timing problem. Good luck. Kind regards, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
[casper] ppc440epx debugging breakthrough
Hi All. I have been doing some work on reverse engineering the jtag/ocd interface on the ppc440epx (which is a closed protocol). Turns out I've had a bit of luck. It is now possible to 'debrick' a ROACH board, ie load up a bootloader, without any proprietary tools or programmers. The programmer I have used is an Amontec JTAGKey Tiny (which has an FTDI ft2232 chip on it). The JTAG operation are performance using urjtag, a nice GPL'ed tool which supports a number of jtag programmers. I have put all the details up on: http://casper.berkeley.edu/wiki/ROACH_Debricking The solution, as it sits, is rather incomplete, ugly, and less than ideal. However, it does seem to work. Here is a link describing the secret COP interface. http://www.mail-archive.com/linuxppc-embed...@ozlabs.org/msg30394.html I am pretty excited about this! Hopefully IBM and Freescale don't hunt me down... Cheers, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
Re: [casper] OPB address overlap on ROACH
Hi Henry.
That was definitely an oversight on my part.
> The way I'm reading gen_xps_mod_mhs for the powerpc440_ext is that each
> bridge's address space essentially has static allocation using
The bridges are currently designed to fit on 0x8 intervals after the
0x100 simulink peripheral starting point. The reason for not making
the position completely arbitrary may have been to save a few resources in the
address decoding: ie (8 >= x < 8f) is slightly cheaper than
(81230 >= x < 8ff). I say may because I cant really remember.
I reckon the easiest solution here would be to double the opb2opb
bridge interval
size. Have a look at gen_xps_mod_mhs.m, line 40. Change it to:
opb_bridge_size = hex2dec('0010');
This should be fine until you have 16 OPB bridges, which puts the
limit on the number of
yellow blocks to 512. The limit is imposed so you dont overlap the qdr
(which sits at 0x200)
Hopefully this solution works and doesn't affect your sensibilities;)
Cheers,
David
--
David George
Karoo Array Telescope
Tel: +27 11 442-2434
Email: david.geo...@ska.ac.za
Re: [casper] PAR could not meet all timing constraints.
Hi Daniel > I tried to clock at 100MHz system clock and 400Mz for ADC, now I changed > to 200/800 respectively and it compiled! Why adc_clk_buf has issues with > lower frequency? Where I can find it in my design? It looks like your timing error was inside the iADC yellow block, which corresponds to a pcore in your EDK project. I suspect you have run into a minimum timing constraint on a DCM which is configured for high speed clocks. The minimum input clock frequency for DCMs on Virtex-5 is 120 MHz. So this timing error isn't one that adding latency can fix. If you want to run at less than 120 MHz, you need change two parameters (vhdl generics) in xps_lib/XPS_ROACH_base/pcores/adc_interface_v1_01_a/hdl/vhdl/adc_interface.vhd. Both DFS_FREQUENCY_MODE and DLL_FREQUENCY_MODE should be equal to "LOW" (as opposed to "HIGH") This represents a bug in the toolflow (or I suppose a missing feature) as this could very comfortably be done automatically. I'll file a bug report on this and it will probably be fixed soon. Hopefully I'm correct in understanding the problem and have helped ease your mind about it too. Cheers, David George
Re: [casper] ROACH qdr latency question
Hi Yuta. > I have a question about the qdr block. According to the documentation > (http://casper.berkeley.edu/wiki/Qdr), there is supposed to be 9 cycles of > latency between the rd_en signal and valid data at data_out. > However, I am noticing that it is actually 10 cycles (i.e. if rd_en is high > at cycle 0, the data is available at cycle 10). That doc was written a while ago and has slipped out of sync with the current state of the code. The latency is 10. Regards, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
Re: [casper] RMSPEC Project
Hi Andrea.
> 1. Who is the designer?
I believe I might be to blame for all your headaches.
> 2. Has this project been never updated with the current libraries?
No. That design was done just about a year and a half ago and hasn't
been touched since.
I think the best thing to do would be to redraw the whole design using
all new library blocks. (which I believe you have done)
> I have modified a string in the plot_scripts regarding the GNUPLOT
> configuation ("set style data lines" instead of "set data style lines",
> it's a minor changes maybe due to a new gnuplot version...).
> The script which get data at the first stage (pfb output) is working well,
> but the FULL one is not working.
Okay this is something at least!
> I was afraid about the "datapath clock rate" field in the DRAM properties,
> set to 200, so I have tried to compile the project using 266, but also
> this attempt failed.
200 or 266 should be fine. Oh and apologies for the documentation!
> I realized that my ROACH did not have a RAM memory on the FPGA DIMM slot,
> therefore I have added a CRUCIAL 1GB 240-PIN 128MX72 DDR2 PC2-4200
> CT12872AA53E.18FD, the same memory model used in the PPC DIMM slot. But
> the result is the same, even if trying again with the original bof-file.
I reckon the first thing to do would be to make sure your dram is
working. The easiest way to do this is to read the dram_controller
register. Read the second 32-bit word in the register. If this value
is not 0x1 your dram is not working. Once you are sure the dram is
working we can put our heads together about debugging the design.
> 3. Has somebody never tried to use this project on its ROACH board?
I got this thing working a long time ago.
> I think that something is missing or just not well updated.
Could be. It seems as though it may be a DRAM issue though.
> Hope some of you can help me...it will be my pleasure to make available to
> this community the updated and working version.
That is a good point. I never had the time to put polish on the
design, but I would be happy to help you bring it back to life.
Cheers,
David
--
David George
Karoo Array Telescope
Tel: +27 11 442-2434
Email: david.geo...@ska.ac.za
Re: [casper] RMSPEC Project
Hi Andrea. > Looking at that register in fact I got all zeroes. I you get all zeros this means the dram controller hasn't managed to finish its initialization routine which indicates that something is wrong. Before you try to debug that design you need to make 100% sure that your DIMM is working. > The RAM device I'm sure > is in good healt because is the one I use as PPC DIMM RAM in another ROACH > board. There are only a limited number of DDR2 DIMMs supported in the FPGA slot (The PPC slot supports all I believe). I'm not actually sure what the supported dimms are. (I'm 'CCing Wesley New who may know) ** Wesley Andrea's DIMM is a CRUCIAL 1GB 240-PIN 128MX72 DDR2 PC2-4200 CT12872AA53E.18FD **. So the situation may be that your Crucial DIMM is not supported by the DRAM controller. There may also be some other problem. > I'm tryng to debug all control signals into the BUF block, I recognize is > not easy but very well designed. I wouldn't be so sure that it is well designed... So as I mentioned earlier, before debugging the design further make sure that you can get the dram to work at all. Create a simple .mdl file with the dram, tie all the inputs to 0's and enable the cpu interface. You should then be able to access the memory from the dram_memory register. Hopefully we can help you sort out this problem. Cheers, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
Re: [casper] RMSPEC Project
Hi Andrea. Glad you got it working. > I think there are still something to manage because the output plot seems > to be just a part of 1 Million Channels and I got many 'udp > over/underflow' warning messages but for today I'm very happy. If you are running linux it help to increase the size of the UDP buffer with this command (as root): sysctl -w net.core.rmem_max=8388608 (This was indicated in the comment at the top of the plot scripts) I apologize to you for the state of those plot tools, they were knocked together and have no polish whatsoever. > Many thanks for the help, > I will let you know of the progress in this project and I will post it on > the Casper repository. No problem. Cheers, David
[casper] ROACH 2: it exists
Hi All. As you may know a new CASPER board is in the pipeline called ROACH 2. The design is centred around a Xilinx Virtex-6 SX475T FPGA. It should be, roughly, a 4-times improvement in terms of overall performance over ROACH 1. Well, the board arrived from assembly just under a week ago and I have been working at trying to get it to do stuff (other than emit smoke). The board now boots into uboot, we can JTAG in an FPGA bitstream and the PowerPC can successfully "talk" to the FPGA. The FTDI USB to JTAG + serial works like a charm (which is lucky because neither the Xilinx and Macraigor programmer play along with the JTAG chain). So hopefully progress will be good over the coming weeks so we can start making lots of these board soon;) The wiki page is hopelessly out of date, but includes some more information about ROACH 2: http://casper.berkeley.edu/wiki/ROACH2 I have also uploaded a video of the board in action for your enjoyment. You can view the video directly here: http://casper.berkeley.edu/wiki/images/d/d1/Roach2_knight_rider.mpg Expect more updates on the casper lists and the wiki soon. All the best, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
Re: [casper] Roach QSH-DP connector pin number and roach ucf pinout name
Hi Guy. > I'm planning to send data from an external board to the roach by using the > QSH interface. Where can I find the QSH pin number with the roach fpga > pinout connection name(or ucf) especially with differential signal name > details. The mapping between signals and FPGA pins is stored in xps_library/BEE2_hw_routes.mat file. The schematics should also help: http://casper.berkeley.edu/hardware/roach_v1_02_sch.pdf You should be able to access the QSH bits though a simulink GPIO block. Though you may need to create a yellow block if the interface is complicated. Cheers, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
[casper] ROACH 2 Wiki page updated
Hi All. I have updated some of the info on the ROACH 2 wiki page: http://casper.berkeley.edu/wiki/ROACH2 More importantly I have added some pics too. Cheers, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
Re: [casper] katADC, ISE/SysGen10.1 compatible?
Hi Luis.
> I created new netlists and verilog files of {fab,cpu}_op_fifo and rx_fifo,
> using FIFO Generator v4.3 and selecting the options according to the original
> XCO files.
As you have worked out, the FIFO netlists were generated using ISE 11
tools, making them incompatible with 10.1. Regenerating them as you
did was the right way to go. There shouldn't be any reason that you
cant use the KATADC with 10.1.
>
>
> The only thing that I did not copy exactly is the reset_type option of the
> rx_fifo in v5.3: reset_type=Synchronous_Reset. I am getting this error from
> xst:
>
This shouldn't make any difference. Synchronous resets are probably best anyway.
>
> I programmed a Roach board, but I am not sure if this trick worked?
>
> --
> In [41]: fpga.progdev('katadc_alone_2011_Mar_25_1844.bof')
> Out[41]: 'ok'
>
> In [36]: corr.katadc.get_ambient_temp(fpga,0)
> Out[36]: 0.0
>
> In [37]: corr.katadc.eeprom_details_get(fpga,0)
> Out[37]:
> {'adc_ic_id': 0,
> 'pcb_rev': 0,
> 'reserved': (0, 0, 0, 0),
> 'rf_fe_id': 0,
> 'serial_number': 0}
> --
>
This is definitely not working. I suspect you are getting all zero's
on reads. I'm not really sure why this is happening.
Firstly I would check that PPC comms are okay by reading and writing
to the sys_scratchpad register. I would then dump the
kat_iic_controller register and look for any non-zero values. If you
don't see anything this most likely means something is wrong with the
generated EDK project. Exactly, what would be hard to say. You could
post your generated XPS_ROACH_base/system.mhs and coreinfo.tab files
which may give some clues.
I think Jason might have some code which manipulates the
kat_iic_controller register directly. This might provide a little more
insight than the corr routines.
Hopefully we can work this one out quickly.
Cheers,
David
Re: [casper] katADC, ISE/SysGen10.1 compatible?
Hey Jason (and CASPER) > FWIW, it looks like ROACH2 will start using 12.x tools so it might be a good > idea not to fall too far behind the development versions. ROACH-2 will start out using the 11 toolflow. A whole lot of work is required to get things moved over to the 12 and 13 tools. We will need some scheme of migrating from OPB to PLB. That said, we'll get there eventually. Cheers, David
Re: [casper] tut2 10gbe not configuring
Hi Andrew. *sigh* > > > > It creates a tap interface, which is of dubious value. (Does anyone > know which packets received on 10gbe are passed along to the tap > interface? It better not be a lot of them, because there's no way > that the PPC could keep up at full speed.) > The 10Ge controller has two interfaces. The primary of which is a high-speed UDP interface to the fabric (or FPGA) interface. The only traffic that goes to this interface is the UDP traffic directed to the local port as defined by user. It is clear that this UDP interface isn't all that is needed. Some things, for example like ARP, ICMP and TCP (for potential control packets) and impracticable to implement on an FPGA (ignoring the possibility of a soft core CPU, which would be a waste of resources considering we have a dedicated processor). To do these things we have a secondary interface (the CPU interface) which is essentially a basic MAC controller presented to the PPC. All traffic that is intended for the board not including that high speed UDP stuff goes through this interface. The TAP interface is, in my opinion, a very neat way of handling TCP/ICMP/ARP etc. This lets the kernel do all the hard work. The alternative is to have a userspace daemon which emulates a network stack (or some subset of one). I would call the former an elegant solution and not at all dubious. Regards, David
Re: [casper] U-boot, DTT: 1 FAILED INIT
Hi Luis. This looks distinctly as if a AD7414-1 has been populated instead of the AD7414-0. I see you have a device that has i2c address 0x4D which is what would happen if the -0 and -1 were swapped. You can query the device manually by running the following from uboot: i2c md 4d 0 1 What you should get back is the temperature in hex. We should just find our what happened here. That said, this isn't a major issue. Regards, David
[casper] ROACH-2 prototypes working well
Hi All. ROACH-2 development and testing has gone well over the last two months. At this point we have tested the two prototype boards and are happy that everything works. While there were a number of minor issues, we were able to get everything functioning with a few blue wires and a steady hand. The only item untested is the DRAM, for which I blame Xilinx's trigger happy memory interface group. Work will now start on fixing the various issues. Have a look at the wiki page for all the latest details and pics: http://casper.berkeley.edu/wiki/ROACH2 There is a particularly nice image of the board with two CX4 mezzanine cards attached (and working!): http://casper.berkeley.edu/wiki/Image:Roach2_rev0_2xcx4mezz.jpg For those who are particularly interested, we are planning to have a telecon next week Wednesday to discuss the hardware fixes, changes and the way forward. This will happen at the regular ROACH telecon time. I'll post these details a little later. Kind regards, David -- David George Karoo Array Telescope Tel: +27 11 442-2434
Re: [casper] 10 gbe mysteriously disabled?
Hi Jon. I would check the 10Ge link status register. It sits at an offset of 0x24 in the 10Ge register. It should be equal to 0x7e or 0x7c. If it equals one of these values the controller and link are working fine. Has this same bitstream worked on the same board before? I have on rare occasions I have seen compiles that produced 10ge bitstreams that would work on some boards and not others. If this is the case I would try recompiling. Have other people seen this issue? It is a little unlikely that there is a hardware failure, but you can run the Built-in tests from u-boot to ease your mind. Have a look at the FPGA Configuration and Testing section. http://casper.berkeley.edu/wiki/ROACH_Bringup#FPGA_Configuration_and_Testing Kind regards, David
Re: [casper] Roach 1: QDR to reference designator mapping
Hey Henry. I'm sending this from my phone, so apologies for the brevity. I suspect the test bitstream is old. I don't have the version numbers at hand now. I'll mail tomorrow. The NEC and ISSI qdrs exposed a bug in the controller that caused cal to fail. The dll reset was screwy. This was fixed just over a year ago. The mlib_devel stuff is up to date. Cheers, David
Re: [casper] Roach CPLD Revision
Hi Matt. > The CASPER Wiki has the latest verions of the Roach1 Xilinx CPLD as : > http://casper.berkeley.edu/svn/trunk/roach/gw/binaries/roach_cpld/roach_cpld_8_0_1588.jed This is fine as the default. The last change made corresponds with the change to the "8" major revision number. > Bur I've come across a couple of Roach1s that have a different/newer? > version. > I don't have exact # infront of me but I think it might be 1590. It seems silly, but the only difference between the files is the Subversion revision number which is extracted at compile time and stored in the design. This is an artifact created when source other than the CPLD stuff changes in the repository. Cheers, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
Re: [casper] Possible 10gbe bug
Hi Jon. > This is a known problem and I don't believe anybody's working on a fix. There > is a slight complication in that the core uses multiple clock domains so > there is potential for race conditions during reset at clock boundaries if > this is not handled properly. David George (10GbE core author) can probably > comment further. Jason is correct here. The business of multi clock-domain resets is a pain. Reset signals have to be registered multiple times and have an unknown propagation and deassertion time. In principle the most correct way to do this would be to have a "reset_done" reply signal back to the user. Another way of doing this is to define a safe back-off period, for example waiting 16 cycles. Another way of doing it is to not use the reset at all (which is my personal favourite). > FWIW, you only have to mask the "valid" line because EOF is ignored unless > the valid line is asserted. I am also using this workaround in the packetised > correlator. This is a pretty good work-around. It doesn't cost anything extra in the controller as would a reset-done or hardware enforced back-off. This particular reset situation could be made better by using a synchronous FIFO reset. Currently the issued reset only affects the data fifos on assertion and other logic throughout. So you accumulate junk in the fifos until you de-assert the reset. A fix is simple, but I don't really have time to test it. The issue of what happens when you clear the reset is a little more complicated and may require a back-off period. This same issue affects the DRAM (and possibly others). I think the moral of the story is that it is worth being paranoid when issuing resets. Hope this sheds some light on the situation. Regards, David
Re: [casper] PlanAhead and broken borph executables
Hey Billy. > By "broken", i mean: i can program the fpga, but all the registers read > out zero; if i write a register, it continues to read back zero. I would just check that you aren't running into the "read-back all zero's" issue. Refer to this email: http://www.mail-archive.com/casper@lists.berkeley.edu/msg01938.html A quick summary of the problem: sometimes the FPGA would program fine, but all the IOs would be kept in tri-state and register reads would be all 0's. This was resolved. Check that you have "-g GTS_cycle:2" as a bitgen argument. It is set in XPS_ROACH_base/etc/bitgen.ut It may also help to use Xilinx's Impact tool to read the V5 status. You should see the option in the debug menu. What you are looking out for is GTS_CFG_B : 0 If you see this cleared your IOs are stuck in tristate. It may help if you attached the debug message into an email. This is the only thing I can think of. It sounds like a configuration related issue. Cheers, David
Re: [casper] casper.berkeley.edu hacked
Hi Mark. > Namely, the website, wiki, git, and svn. I'm having trouble doing an svn checkin. (I am checking in a kernel change: https://casper.berkeley.edu/svn/trunk/roach/sw/linux) I'm getting this error: svn: Can't create directory '/srv/svn/db/transactions/3427-1.txn': Permission denied Also mantis appears to be broken. Cheers, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
Re: [casper] Roach questions
Hi Mandana. I can answer a couple of your questions. > 1) How do I estimate the FPGA clock frequency from the sys_clkcounter value? Simply take two readings, calculate the difference between last and first (taking care of 32-bit overflows) and divide by the time taken. > 3) I have two iADC board and I feed the clock using a splitter. The FPGA > clock is naturally driven from iADC0. Do I need to worry about phase > mismatch or delay between iADC1 clock and FPGA clock? Any advice? You don't have to worry about the phase difference. All ADC inputs go through an asynchronous FIFO with the associated clock on the input and the application clock on the output. Regards, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
Re: [casper] Sample design for ROACH DRAM and CPU
Hi Peter. > Thanks very much. I think I was seeing 512 MB of DRAM, so this single- vs > dual-rank DIMM story seems to explain what is happening. I would just check which part you have installed. That DDR2 memory module wikipage has some really great info. From it I gather the situation is as follows: There were 3 types of dimms shipped: * Kingston KVR800D2D8P5/1G - 1GB, Dual rank, 14 row address bits, 10 column address bits, 2 bank address bits * Corsair CM72DD1024AR-667/S - 1GB, Single rank, 14 row address bits, 10 column address bits, 3 bank address bits * Viking Modular VR5ER287218FBWS1 - 1GB, Single rank, 14 row address bits, 10 column address bits, 3 bank address bits Just some clarification on the address bits, when addressing the dram memory the bits are used as follows: Bank[1:0], Row[13:0], Column[9:2]. The two LSBs of the Column address are not useful to us because they only affected the order of the data within a burst, so we leave them fixed at 0 for memory access. You will notice that this only gives us 512MB, 24 address bits with an effective word size of 256. As Laura pointed out, if you have the Kingston part expect to only be able to use 512MB. If you have the others you should be able to use the full 1GB with a little fiddling. I just checked the dram controller and I see that only 2 bank address bits are being used by default. In principle this could be set this to 3 to provide full access to the 1GB. My only concern about changing this in git would be the effect on the Kingston memory (which my gut feeling says shouldn't be a problem, but my gut is frequently unreliable). Perhaps you could try changing the bank address to 3 for your board to see if it makes a difference. Just edit: mlib_devel: xps_lib/XPS_ROACH_base/pcores/dram_controller_v1_00_a/hdl/verilog/dram_controller.v and change the BANK_WIDTH parameter to 3. Before the changes get checked in, it just must be checked that this doesn't break Kingston support. As for larger, single rank DIMMs, they would definitely require changes that would break compatibility with the others DIMMs. They seem to add an extra column address bits, which would lead to dead spots if the memory on the supported DIMMs. Hopefully this clears things up a bit and I haven't been talking rubbish! Cheers, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
[casper] Updated linux kernel for ROACH
Hi All. Shanly Rajan and myself have been doing some BORPH kernel work and have uncovered and fixed a bug which was causing failed programs to not be reported. You can find the latest version here: https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/uImage-20110520-progfailfix I have also updated the latest version wiki page: https://casper.berkeley.edu/wiki/Latest_version Cheers, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
Re: [casper] Low level design on a Roach board
Hi Aziz. > I want to use a Roach board (one with virtex5 FPGA) to test some VHDL > designs and I’m not using Simulink, matlab, XPS . To do so I need to know You could start with this project: https://casper.berkeley.edu/svn/trunk/roach/gw/roach_bsp/ It is a verilog project we use to test the ROACH boards. It has a make-based build. You will need standard GNU tools, iverilog and Xilinx ISE installed. This is best compiled under Linux, but can be compiled in windows with cygwin. This project doesn't have that much polish to it. It may be better to use the XPS (EDK) project as your starting point. casper git: xps_lib/XPS/ROACH_base You should be able to use the EDK gui to create your design. > how to create a BORPH compatible interface between the FPGA and the PowerPC. As for a borph compatible file. Your compile should produce a .bin file which you use combine with a core_info.tab file with the mkbof utility. There should be plenty of coreinfo.tab files around to work out the format. Refer to the MSGGE build scripts for how to run mkbof: casper git: xps_library/ > What I’m looking for is information regarding the connection between the > FPGA and the PPC such as pins, communications protocol …and how to manually The PPC datasheet has tons of info on that interface (refer to the external bus controller section): http://myapm.apm.com/MyAMCC/retrieveDocument/PowerPC/440EPx/PPC440EPx_440GRx_UM2018.pdf Also, the EDK and ISE projects mentioned earlier have HDL code which uses this interface. > Any low level technical document describing the architecture of the ROACH > and its OS would be very appreciated. I would also appreciate any example. The best (and only existing) low-level documentation is in the existing code. The schematics are available on the wiki, which should help out. Regards, David
Re: [casper] Low level design on a Roach board
Hi Aziz. > Now I just need to find how to program the FPGA. One option to create a BOF > file using mkbof, I tried that but I got an error. I think its because I do > not have a valid core_info.tab file. I just used the one from ROACH_BASE. This is how you make a bof file: (From xps_library/gen_xps_files.m) ./mkbof -o implementation/system.bof', ' -s core_info.tab -t 3 implementation/system.bin > Can you explain how to manually make a core_info.tab file? If I just need to > modify the existing one can you explain what should I modify and how? To understand the coreinfo.tab format here is an excerpt from mlib_devel_dbelab00/xps_lib/XPS_ROACH_base/core_info.tab sys_board_id304 sys_rev 344 sys_rev_rcs 384 sys_scratchpad 3c4 sys_clkcounter 3 104 The first string is the register name (ie what appears in the /proc borph entry). The second is the mode, I think 3 is RW. The 3rd is the memory offset within the FPGA and the fourth is the register size. > If I succeed in making a BOF file I still need to know what to have on the > FPGA side in order to talk to the powerpc the way it is supposed to be in > BORPH. Is this explained somewhere? It happens the other way around, the PPC communicates with the FPGA. You would tend to write a wishbone bus module which memory maps resources from the FPGA. If you google this you will find lots of examples and a spec. > The other possible option is to write a C code to configure the FPGA > directly from the bitstream file and choose my own communication protocol > between the PPC and the FPGA (which would be an ideal solution for me). Sure you could do this, I would think it would be lots more work. > Does BORPH provide an API for that? No, you would be implementing an alternative to BORPH. Regards, David
Re: [casper] mmcboot with updated kernel
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: https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/uImage-20110812-mmcomitfix Would you mind testing. If it works I'll update the latest version wiki page. Cheers, David -- David George Karoo Array Telescope Tel: +27 11 442-2434 Email: david.geo...@ska.ac.za
Re: [casper] ROACH clocks and chassis setup
Hi Matt. > What is the CHS_LED1 signal ? > This is the red LED below the green/power LED on the front of > the iStar 1.3U chassis. > In the recent past we've started to see a couple of systems > where this LED turns on for some reason. > > The schematics show it connects to the D1 pin of the Actel part at U60. That red led indicates a few things. If it flashes it represents a system health related emergency shutdown. If it is solid, which I believe is your case, it means that the monitoring subsystem has an interrupt that is waiting to be serviced by the PPC. This interrupt can be set for the following things (in order of likelihood): a power-button event, an internal monitor bus error and a software defined system health threshold violation. What I suspect is happening is those boards have the Linux kernel which I put up a few months ago which doesn't include the MMC and roach_monitor drivers. This is causing the triggered IRQs to remain unserviced and the LED stays high. Its almost certain that the power button was the trigger. Try updating your boards with the kernel I put up a couple of days ago: https://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/uImage-20110812-mmcomitfix Sorry to cause headaches. Henry has tested this kernel so I'll update the wiki recommended versions. Cheers, David
Re: [casper] Accessing SMA clock inputs and DCM?
Hi Suraj/Jon. > 0) Sacrifice a goat to the EDK gods so that they will allow you to complete > in a reasonable amount of time. > > Hah. To get EDK to work you may need to go bigger. Perhaps a few cattle or a first-born. hehe. It's not that bad, just copy the way another block does it. Monkey see monkey do works well for EDK. Cheers, David
Re: [casper] I2C and SPI on roach {I,II}
Hi John. > We have a need for an I2C *or* an SPI port on ROACH 1 and 2. There are > actual headers on R1 that say "SPI" and "IIC". Are these attached to the > PPC? Is there any driver support for them? These do attach to the PowerPC. There are two separate ports on R1, labelled IIC and SPI. The IIC port is used for a bunch of things including DRAM SPD. Putting something bad on this port might prevent the PPC from booting, but will require no configuration. The second labelled SPI is spare and can be set up to use SPI or IIC. I'm pretty sure there is kernel support for both I2C and SPI for the PPC. I'm not sure that SPI is compiled in, but I2C will definitely be there. Your devices will most easily be made available to userspace via the i2c-dev driver. I'm not sure about the equivalent for SPI. You may need to do a little configuration in u-boot to support SPI and perhaps the spare IIC. (I have never used SPI on the PPC) I would say IIC would be far easier. > On R2, these ports are not obviously present. I suppose the GPIO pins > connected to the PPC could be used for this. Again, any plans for > supporting IIC or SPI on R2? R2 takes the same PPC pins out, but to a single header (P7) labelled PPC IIC. The spare IIC pins are labelled SCL, SDA and PDO (SPI). The "in use" I2C pins and quietly labelled C (SCL) and D(SDA). Cheers, David
Re: [casper] I2C and SPI on roach {I,II}
> What voltage levels are on the IIC bus on R and R2? They are both 3v3. > Thanks, David. My pleasure.
Re: [casper] Roach clocking question
Hi Rick > the FPGA. I gather that the software registers are resynch'ed to the fabric > clock; is there a way to defeat this resynching, or some other option for > switching clocks? It'd be trivial in Verilog, but I don't see how to do it > in Simulink. As you said, all the Simulink signals are synch'ed to the application clock. This is necessary to abstract away the clock to the simulink user. While it may be possible by some black magic to get a signal in on a different clock domain I would probably say that it isn't a good idea. What you could do is have an edge detect of the simulink signal inside your yellowblock on the adc clock domain and sample that result to the system clock domain (sys_clk) which then drives the DCM/ADC reset for a fixed period. That way you should be guaranteed that the ADC reset will not kill the clock permanently. What most other ADCs do is instantiate an OPB pcore/module which does the resetting. A good example of this is the opb_katadccontroller, you could just copy that and strip out what you dont need. You will also need to modify the base system.mhs and system.ucf. This approach is particularly useful if you need to do some other tweaking like DCM alignment or ADC configuration. Regards, David
Re: [casper] Roach IIc
Hi Patrick. > The team at the Green Bank NRAO has opted to use IIc on the ROACH board > (ROACH1 for the short term, but ROACH2 in the future). Does anyone have > experience with IIc on ROACH, primarily from the software side? First up; are you using IIC driven from the PPC or the FPGA? If you plan on using the PPC, the easiest way to go about it initially would be to use the i2c commands in u-boot which are very user friendly: i2c probe #list all the device on the iic bus i2c md# read a register on a given device i2c mw# write a register on a given device Uboot will be very useful initially for debug/testing but you will need kernel support for the final app. You have two options here. Either write/use a kernel driver to export the IIC function to userspace e.g. a GPIO device or hw sensor exported to sysfs or use the i2c-dev driver to access the raw IIC device from userspace. I would probably go for i2c-dev. Have a look the kernel doc below: http://www.mjmwired.net/kernel/Documentation/i2c/dev-interface If you plan on using the FPGA to drive the IIC you should look at the kat_iic_controller that gets pulled with katadc designs. I believe there is already some supporting python infrastructure in the corr package. Cheers, David
Re: [casper] Roach I Board Power Requirements
Hi Joseph. I guess I could comment on the power management side. > * Since we have two Roach Boards in close proximity, could we power them > both from one larger ATX supply? I think it is possible to gang two roaches on one supply. Just remember whatever scenario you choose, the roach will expect the ATX supply to be there a short while after being powered-on (by chassis button or remotely via Actel Fusion). If not, the fusion will register a FAULT condition, will retry four or five times to power-up and will eventually give up. A ROACH wont mind having the supplies always-on (ie with the ATX supply enable bypassed). If you go this way, I would consider the minimum load requirements, as the load resistors are only enabled when the board is considered by the Actel to be in the powered-up state. Hopefully this helps. Cheers, David
Re: [casper] UDP problem
Hi Rick > I have a design which uses the TenGbE core (version 1) and sends out 8kB > packets. It works fine and we achieve 6Gb/s throughput which is > plenty. Recently i made a change to send a short packet with some timer > data following all of the big packets. This short packet contains just > 16 bytes. For some reason, it doesn't show up at the host. I have test > points on the tx_valid and tx_eof control lines, and I can see that they > are being asserted properly. But the packet just doesn't show up. I > don't believe there is any minimum data size for a UDP packet, but I > wonder if anybody has any ideas about this. Could it be getting > swallowed up by the NIC in the (windows) host? The Ethernet payload minimum is 46 bytes - so if you add IPv4+UDP+16B payload you get 20 + 8 + 16 = 44B, with a frame this size you are likely to see network hardware classify it as a runt frame and it will get discarded. I wouldn't be surprised if that is happening. In an ideal world the FPGA would have the nous to insert an extra 2B in the payload to make ethernet happy, but FPGAs are better off dumb. (It takes up less logic that way) It could also be an issue in the 10Ge controller that it rejects small frame intelligently or by accident. I cant quite remember. I would suggest adding an extra 8B to the payload. If that doesn't work it would disproves my first theory. Whatever you find the minimum to be, it might be a nice idea to tweak the wiki doc accordingly. (I would bet the same applies to the 10Gev2 core) Cheers, David
Re: [casper] ROACH 2 GPIO
Hi Nimish. > Is there any documentation for ROACH 2 specific GPIO interface? If not, can > someone throw light on how to configure the GPIO yellow block for ROACH 2. I guess there is no documentation on R2 interfaces at the moment. Something equivalent to: https://casper.berkeley.edu/wiki/ROACH_FPGA_Interfaces would be nice. R2's GPIO consists of 16 standard IOs out from the FPGA at a 1.5 IO voltage. There are no bidirectional buffers as there were with R1. Each IO can be input/output/tristate/pullup/pulldown - whatever the FPGA supports. They should be freely assignable. > Also, do pin numbers in the yellow block match the physical layout? They should, file a bug if they aren't. Cheers, David
Re: [casper] Shared BRAM yellow block
Hi Glen. We've also been experimenting with adding TIG (timing ignore) statements to > the timing constraint file so that things like shared registers are not > constrained to meet timing, since it shouldn't make much difference. This > is not yet commonly done though. > > I would be very nervous about disabling timing checks in general. Metastability will bite you in weird and unexpected ways. For example you may have a control word stored in a BRAM (or software register) that may present itself as an unintended/intermediate/oscillating value for an indefinite period of time (although often with a small probability). It is standard practice to register multiple times and have an arbiter when asynchronous logic is involved. I would venture to guess that the overhead of fixing the timing error would be less than this additional logic. So I guess I'm saying: fix the timing error and don't disable the timing checks. Remember the R2 chip is massive, four times the area. It makes sense that more register stages are needed in and out of peripherals that worked for R1. I guess it is easy to say from someone not doing the work ;) Good luck. Cheers, David
Re: [casper] Bidirectional IO?
Hi All. The solution here is a new type of gpio pcore which has three gateway ports: gpio_o, gpio_i and gpio_oe. Currently there are two gpio pcores; one for in and one for out. David
Re: [casper] Fault LED
Hi all - all these sensors can have their fault outputs masked in software; either using linux drivers or in uboot. The faults also go away when you read the sensor values (if I remember correctly); uboot has a sensor command which should do this. Either have a look at the uboot code or lmsensors for linux. David On 28 May 2013 20:41, Rich Lacasse wrote: > Hi Adam, > > With respect to the LED, I found that the alarm was caused by the external > fans being disconnected. I was able to probe R74 through R77 to narrow it > down to fans. I am operating with the board externally cooled, not in a > chassis, so the chassis fans are not connected. Interestingly enough, when > I connected to tborphserver3 interface and queried the individual sensors > as you recommended, it reported 0's for three of the fans and* the fault > went away*! Does that make any sense? > > Thanks for the help, > Rich > > On 5/28/2013 1:42 PM, casper-requ...@lists.berkeley.edu wrote: > > Fault LED > >
