Hello Clifford, Thank you very much for the detailed response, and it is good to know Peralex is overlooking the correspondence. I confess to being a little frustrated at the end of the day yesterday, so may have been a bit grumpy. Adam bore the brunt, and I really do appreciate his patient, good tempered, and helpful response.
Today starts afresh: —I get you on your philosophy regarding end users never removing the lids. This JTAG effort will actually be the second time this is done, in an offline correspondence Amish suggested removing the 40 GigE NICs which it was thought might magically convince the 1GigE to come back to life (it didn’t). I think the unit bricked when Mark followed a procedure to reflash the firmware in the original set of docs Adam sent, which in a phone support con they said had become obsolete. Mark/Adam/Amish/André can fill in the blanks. —regarding the user experience I was probably (or certainly) over the top in requesting a kit of expensive cables, F/O adapters etc. Though it is a nice feeling opening one of those Xilinx eval kits with all the goodies. It is just something to consider. Certainly the quick start guide, perhaps on paper, is important. André had certain opinions on this, and I guess they reduce to “if you were selling to a non-CASPER industry user, it would be more important to show the support coming from Peralex”. Actually, in the US, it would be useful for Cyntony to develop some support capacity. This is just feedback, worth what you paid for it. We’re getting along ok, and I hope even better than that in a day. Have a great holiday all. Cheers, Jonathan > On Jun 15, 2017, at 11:12 AM, Clifford van Dyk <cliffordvan...@gmail.com> > wrote: > > Hi Jonathan (and Adam/Wesley/Mark) > > Firstly, I want to assure you that Peralex is monitoring the Casper group > mails, and we will step in where we feel it necessary. Right now, it > looks like you are getting excellent support from SKA-SA. > > Secondly, our aim with Skarab is that end users never pop the lids off the > units (except possibly when changing the hardware configuration) or have to > scrutinise schematics (unless they are adding/designing new modules etc). For > this to hold, it should not be easy to "brick" the unit. We are therefore > very keen to understand exactly what went wrong here (I think there are still > some outstanding questions from SKA-SA in this regard), and figure out how to > prevent it from happening again. Peralex provided SKA-SA with all the back > doors to the lowest level programming of the Skarab, but I don't think the > average user should be exposed to these back doors in the platform management > APIs/tools (or at least not without some big warning flags/overrides being > set). Unfortunately your platform shipped with the stock Peralex bootloaders, > that are now not 100% compatible with the 'casperfpga' toolchain, so SKA-SA > needed to ask you to reconfigure the bootloaders to the SKA-SA modified > version of the bootloader binaries that is compatible with the 'casperfpga' > tools. In future, all units that are likely to use the 'casperfpga' toolchain > will ship with SKA-SA bootloaders so there is out the box compatibility. > > As Wesley and Adam said, the intention is that the flash (and backup flash) > images are bootloaders, that should never be reprogrammed/overwritten with > application code (behaving much like the BIOS in a PC). This is in strong > contrast to how most FPGA platforms work, where end users are used to > programming their application into FPGA configuration flashes. While it is > certainly possible to put end user images in boot flash, this defeats much of > the rapid on-the-fly reconfiguration of the platform. The SDRAM-based > reconfiguration should be the only option that an end user ever needs (unless > non-volatility of end user application is important). The end user > application image should also contain sufficient support (BSP framework) to > support further reconfiguration. If the end user SDRAM image is corrupted > and/or is incorrectly set up to support further reconfiguration, then a power > cycle will cause the unit to fall back to the bootloader image (boot the > flash), and wait for new application code to be uploaded. > > Finally, thanks to Jonathan Weintroub for the feedback regarding the user > experience, and suggestions around the "package". Please keep this coming! At > the very least I think we need a "Quick Start" guide that ships in every box > and should maybe include non-commercially available interface adapters that > may be required etc. I'm not sure whether it is worth creating a separate > Developers Edition accessories pack that is optionally available but > recommended for first time users - some of the 40 GbE interface cables etc. > are expensive enough that I don't think users would want to be paying for > them with every Skarab unit (if they weren't useful in final deployment), > maybe only the first development units. I'll propose something and bounce it > off our early adopters. An explainer on how to build a cluster (with a list > of known/tested compatible hardware/cabling/etc) may also be worthwhile. > > Please also be aware that tomorrow is a South African public holiday, so > support from this side may be limited. Good luck with your platform recovery! > > Kind regards, > Clifford > > On 6/15/2017 12:45 AM, Jonathan Weintroub wrote: >> Hi Adam, >> >> Ok thanks. I found a Xilinx Platform USB pod in anticipation of this need >> before leaving the office. I still need to locate the fly lead cables. For >> this reason alone this needs to wait till tomorrow. It's also very late for >> you so I feel badly keeping you up. >> >> The package of documents your group assembled and passed on to us is very >> detailed and impressive, and we really appreciate it! >> >> We were discussing today that somehow the most basic procedures need to be >> more tightly packaged and perhaps the board should ship with a set of the >> most needed accessories--a few loop back cables perhaps, maybe even a JTAG >> tickler or similar, maybe a F/O module or twi, and a large clear photo of >> the unit showing what connector and part is where, etc. Just to make it >> absolutely clear to the new user, especially if not a CASPER insider.This >> especially if it is hoped to market the SKARAB to industry etc >> internationally and more widely. >> >> The package supplied with the typical Xilinx evaluation board is a great >> model, though probably more than can be managed practically speaking. >> >> You mentioned in your response the schematics. Have full schematics of >> SKARAB been released? I must have missed them in the package please confirm. >> >> Thanks again. >> >> Jonathan >> >> On Wed, Jun 14, 2017 at 6:26 PM Adam Isaacson <aisaac...@ska.ac.za >> <mailto:aisaac...@ska.ac.za>> wrote: >> Hi Jonathan and Mark, >> >> >> Yes, JTAG is the way. Okay, I have done this before. This is what needs to >> be done and I am going via memory here - will confirm when I am in the >> office tomorrow: >> >> 1) Remove the SKARAB lid >> 2) This is TBC, but you will need to short the jumper on P9 (schematic page >> 42), which will add the Virtex 7 and reconfig device to the JTAG chain. I >> know I need to do this when I run the Vivado ILA. >> 3) The JTAG connector is ref des JP3, which is a 20 pin header. You will >> need to use the Xilinx USB Platform Programmer Cable to connect to the 20 >> pin header using the fly leads that come with the Xilinx USB Platform >> Programmer Cable. NB: Remember to install the USB drivers as specified in >> the Vivado install How To. >> 4) Open Vivado and open the Hardware Manager. First, auto connect and make >> sure the FPGA can be detected. Then add the flash device. I used the >> "mt28gu01gaax1e-bps-x16" device together with the *.MCS files stored in the >> repo. You just need to configure the multi-boot image to gain access to the >> board via the 1GbE interface again. Set the RS pins to [25:24]. You may need >> the *.prm files, which are available in >> https://drive.google.com/drive/folders/0B2dCFqGD5y-8eHlSVlFrUVdPOVE?usp=sharing >> >> <https://drive.google.com/drive/folders/0B2dCFqGD5y-8eHlSVlFrUVdPOVE?usp=sharing>. >> If you do then let me know and I will add them to the repo. >> 5) Configure the flash, verify and then power off the board and see if the >> 1GbE comes up. >> >> If you are still struggling then I will generate a proper How To document >> tomorrow with graphics etc. I will probably do that anyway. >> >> Good luck! >> >> >> >> On Wed, Jun 14, 2017 at 11:44 PM, Jonathan Weintroub >> <jweintr...@cfa.harvard.edu <mailto:jweintr...@cfa.harvard.edu>> wrote: >> Hi Wes and other SKARAB experts, >> >> To my understanding our SKARAB is now "bricked" and no longer responds on >> Ethernet at all. We now need a way to bring it back to life from a straight >> off the factory floor state. We surmise this involves JTAG and while there >> is a tantalizing mention of this protocol in the docs Adam supplied, there >> are no details. >> >> We may need Peralex expert support here. We are time constrained on this >> project and need to get rolling. >> >> Please advise, thanks! >> >> Jonathan Weintroub >> SAO >> >> >> On Wed, Jun 14, 2017 at 5:11 PM Wesley New <wes...@ska.ac.za >> <mailto:wes...@ska.ac.za>> wrote: >> Hi Mark, >> >> Firstly, welcome to the CASPER community. >> >> The SKARAB has multiple images stored in Flash. These are meant only used >> for the initial FPGA image at start up and a fall back image. This is a >> Xilinx standard method of configuration. You should be using the >> upload_to_ram_and_program function. This function uploads the your compiled >> fpg file to the SDRAM and then triggers the Virtex to program itself from >> the SDRAM. You will probably have overwritten the boot >> images. :( >> import casperfpga >> >> SKARAB_IP = '10.99.45.170' >> SKARAB_FPG = 'skarab.fpg' >> >> # skarab programming >> skarab = casperfpga.CasperFpga(SKARAB_IP) >> skarab.upload_to_ram_and_program(SKARAB_FPG) >> >> Does the board come back after waiting some time? >> >> >> >> >> Wesley New >> South African SKA Project >> +2721 506 7300 <tel:+27%2021%20506%207300> >> www.ska.ac.za <http://www.ska.ac.za/> >> >> >> >> On Wed, Jun 14, 2017 at 7:16 PM, Peryer, Mark A. >> <mark.per...@cfa.harvard.edu <mailto:mark.per...@cfa.harvard.edu>> wrote: >> Hello, >> >> After trying to reconfigure the flash memory on the Virtex7 FPGA with a new >> image, I am no longer able to connect to the SKARAB through casperfpga using >> the 1GigE port. When I enter the command fpga = >> casperfpga.SkarabFpga('169.254.128.213'), the following is >> output. >> >> DEBUG:casperfpga.casperfpga:169.254.128.213 <http://169.254.128.213/>: now a >> CasperFpga >> DEBUG:casperfpga.skarab_fpga:Retransmit attempts: 0 >> DEBUG:casperfpga.skarab_fpga:Waiting for response. >> DEBUG:casperfpga.skarab_fpga:No packet received: will retransmit >> DEBUG:casperfpga.skarab_fpga:Retransmit attempts: 1 >> DEBUG:casperfpga.skarab_fpga:Waiting for response. >> DEBUG:casperfpga.skarab_fpga:No packet received: will retransmit >> DEBUG:casperfpga.skarab_fpga:Retransmit attempts: 2 >> DEBUG:casperfpga.skarab_fpga:Waiting for response. >> DEBUG:casperfpga.skarab_fpga:No packet received: will retransmit >> ERROR:casperfpga.skarab_fpga:Socket timeout. Response packet not received. >> >> My thinking is that the firmware image loaded into the flash is corrupt and >> now the 1GigE port is disabled. Are these any other possible ways to load a >> firmware image into flash without using the 1GigE port, such as the USB port >> or JTAG header? If so, what would be the required procedure to do so? >> >> Thanks, >> >> Mark Peryer >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu <mailto: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 >> <mailto:casper+unsubscr...@lists.berkeley.edu>. >> To post to this group, send email to casper@lists.berkeley.edu >> <mailto:casper@lists.berkeley.edu>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu <mailto: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 >> <mailto:casper+unsubscr...@lists.berkeley.edu>. >> To post to this group, send email to casper@lists.berkeley.edu >> <mailto:casper@lists.berkeley.edu>. >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu <mailto: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 >> <mailto:casper+unsubscr...@lists.berkeley.edu>. >> To post to this group, send email to casper@lists.berkeley.edu >> <mailto:casper@lists.berkeley.edu>. >> >> >> >> -- >> >> Best Regards / Vriendelike Groete >> >> Adam Isaacson >> FPGA Engineer >> >> >> (+27) 82 563 9602 3rd Floor, The Park, >> Park Road, >> (+27) 21 506 7300 Pinelands >> (+27) 21 506 7375 7405 >> www.ska.ac.za <> South Africa >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu" <mailto: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 >> <mailto:casper+unsubscr...@lists.berkeley.edu>. >> To post to this group, send email to casper@lists.berkeley.edu >> <mailto:casper@lists.berkeley.edu>. > -- 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 post to this group, send email to casper@lists.berkeley.edu.
