Re: [casper] Unable to Load Firmware Image onto SKARAB

[Adam Isaacson]

Hi Mark,

Thanks for this.

In terms of the BSP images, it should not be necessary to use
"fpga.convert_hex_to_bin()". I use the bin file and hex file that is
generated from Vivado. These versions are stored in the repo link I sent
you. You can use either one. In otherwords, this is all you need to do in
casperfpga.

import casperfpga
fpga = casperfpga.SkarabFpga('169.254.128.213')
fpga.virtex_flash_reconfig('frm123701u1r1_mez3_golden_ska_sa.bin/*.hex',0x0)
[NB: either hex or bin is fine]
fpga.virtex_flash_reconfig('frm123701u1r1_mez3_ska_sa.bin/*.hex',0x300)
[NB:
either hex or bin is fine]

If you got validation errors when configuring the flash then that means the
image is not valid. Therefore, the golden image and multi-boot image was
not valid and hence, the likelihood is the board would not configure
properly and hence, the 1GbE link will not come up.

It is unlikely, that
fpga.upload_to_ram_and_program('frm123701u1r1_mez3_golden_ska_sa.bin')
would cause the board to hang as this programs the SDRAM on the board and
not the flash. It is volatile memory, so when you power down/up then the
board will attempt to boot from the multi-boot flash image. If
unsuccessful, then it boots from the flash golden image. My feeling is that
the fpga.convert_hex_to_bin corrupted the BSP image, as you encountered a
validation error. I believe that function is mostly used for the toolflow
image. I will get Amish to run through the steps you ran through and see if
we can recreate the issue.

Please can you let me know what git version of casperfpga you are using?

Thanks for the feedback.

Kind regards,

Adam


On Thu, Jun 15, 2017 at 10:37 PM, Peryer, Mark A. <
mark.per...@cfa.harvard.edu> wrote:

> Hi Adam,
>
> I will go through what I did to get the Skarab into this state.
>
> import casperfpga
> fpga = casperfpga.SkarabFpga('169.254.128.213')
> fpga.convert_hex_to_bin('frm123701u1r1_mez3_golden_ska_sa.hex',True);
> fpga.convert_hex_to_bin('frm123701u1r1_mez3_ska_sa.hex',True);
> fpga.virtex_flash_reconfig('frm123701u1r1_mez3_golden_ska_sa.bin',0x0)
> fpga.virtex_flash_reconfig('frm123701u1r1_mez3_ska_sa.bin',0x300)
>
> It was at this point that both of the image uploads were returning
> validation errors. I thought that I was potentially not using the correct
> functions, so I used the following command and that is when I believe I
> lost communication with the Skarab over 1GigE.
>
> fpga.upload_to_ram_and_program('frm123701u1r1_mez3_golden_ska_sa.bin')
>
> These firmware images were taken from the Google Drive. At the time I did
> not realize that the most up-to-date images are on the github repo.
>
> Hopefully this will give some insight as to how this issue arose.
>
> Thanks,
>
> Mark Peryer
>
>
>
> On Thu, Jun 15, 2017 at 2:36 PM, Adam Isaacson 
> wrote:
>
>> Hi Jonathan,
>>
>> Thanks for the feedback on the documents and your kind words. These
>> documents will be added to a repo and linked to the wiki by the end of next
>> week. I will send an email out when this is ready.
>>
>> I agree with Clifford. I am still not sure what caused the board to be
>> bricked and I think it would be useful if Mark could give us a step by step
>> approach of how this happened, so that we can take measures to prevent this
>> in future - these things do happen and it is all part of the learning
>> experience, in my judgement. In terms of clarity,  the obsolete documents I
>> was referring to involved using ported versions of the Peralex software to
>> configure the flash. We are not using this anymore since all the
>> functionality has been built into casperfpga.
>>
>> Good luck with getting the board running again.
>>
>> Kind regards,
>>
>> Adam
>>
>>
>>
>> On Thu, Jun 15, 2017 at 5:40 PM, Jonathan Weintroub <
>> jweintr...@cfa.harvard.edu> wrote:
>>
>>> 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 

Re: [casper] Unable to Load Firmware Image onto SKARAB

[Peryer, Mark A.]

Hi Adam,

I will go through what I did to get the Skarab into this state.

import casperfpga
fpga = casperfpga.SkarabFpga('169.254.128.213')
fpga.convert_hex_to_bin('frm123701u1r1_mez3_golden_ska_sa.hex',True);
fpga.convert_hex_to_bin('frm123701u1r1_mez3_ska_sa.hex',True);
fpga.virtex_flash_reconfig('frm123701u1r1_mez3_golden_ska_sa.bin',0x0)
fpga.virtex_flash_reconfig('frm123701u1r1_mez3_ska_sa.bin',0x300)

It was at this point that both of the image uploads were returning
validation errors. I thought that I was potentially not using the correct
functions, so I used the following command and that is when I believe I
lost communication with the Skarab over 1GigE.

fpga.upload_to_ram_and_program('frm123701u1r1_mez3_golden_ska_sa.bin')

These firmware images were taken from the Google Drive. At the time I did
not realize that the most up-to-date images are on the github repo.

Hopefully this will give some insight as to how this issue arose.

Thanks,

Mark Peryer



On Thu, Jun 15, 2017 at 2:36 PM, Adam Isaacson  wrote:

> Hi Jonathan,
>
> Thanks for the feedback on the documents and your kind words. These
> documents will be added to a repo and linked to the wiki by the end of next
> week. I will send an email out when this is ready.
>
> I agree with Clifford. I am still not sure what caused the board to be
> bricked and I think it would be useful if Mark could give us a step by step
> approach of how this happened, so that we can take measures to prevent this
> in future - these things do happen and it is all part of the learning
> experience, in my judgement. In terms of clarity,  the obsolete documents I
> was referring to involved using ported versions of the Peralex software to
> configure the flash. We are not using this anymore since all the
> functionality has been built into casperfpga.
>
> Good luck with getting the board running again.
>
> Kind regards,
>
> Adam
>
>
>
> On Thu, Jun 15, 2017 at 5:40 PM, Jonathan Weintroub <
> jweintr...@cfa.harvard.edu> wrote:
>
>> 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 
>> 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, 

Re: [casper] Unable to Load Firmware Image onto SKARAB

[Adam Isaacson]

Hi Jonathan,

Thanks for the feedback on the documents and your kind words. These
documents will be added to a repo and linked to the wiki by the end of next
week. I will send an email out when this is ready.

I agree with Clifford. I am still not sure what caused the board to be
bricked and I think it would be useful if Mark could give us a step by step
approach of how this happened, so that we can take measures to prevent this
in future - these things do happen and it is all part of the learning
experience, in my judgement. In terms of clarity,  the obsolete documents I
was referring to involved using ported versions of the Peralex software to
configure the flash. We are not using this anymore since all the
functionality has been built into casperfpga.

Good luck with getting the board running again.

Kind regards,

Adam


On Thu, Jun 15, 2017 at 5:40 PM, Jonathan Weintroub <
jweintr...@cfa.harvard.edu> wrote:

> 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 
> 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 

Re: [casper] Unable to Load Firmware Image onto SKARAB

[Jonathan Weintroub]

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  
> 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 

Re: [casper] Unable to Load Firmware Image onto SKARAB

[Clifford van Dyk]

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 

Re: [casper] Unable to Load Firmware Image onto SKARAB

[Jonathan Weintroub]

Thanks very much for the quick response, Adam, and the detailed procedures, 
much appreciated.  I found two JTAG pods, one the Xilinx branded one, and a 
more compact version by Diligent, and a couple of cable sets.  An attempt at 
reprogramming will be made today and we will let you know.  Best regards, 
Jonathan

> On Jun 15, 2017, at 7:28 AM, Adam Isaacson  wrote:
> 
> Hi Jonathan and Mark,
> 
> I have written a How To for configuring the flash via the JTAG 
> (https://docs.google.com/a/ska.ac.za/document/d/1TeVELJ1jEQLzk-qqzWhXODd_HEalTkDJhXq4Q1Y_qgU/edit?usp=sharing
>  
> )
> 
> I have also updated the https://github.com/ska-sa/skarab_bsp_images 
>  (master branch) repo with the 
> *.prm files required. I went through this process this morning and 
> successfully configured the flash.
> 
> Let me know if you have any issues.
> 
> @ Mark: Please only use the flash configuration for the BSP images. If you 
> have an image generated from the toolflow then please use the casperfpga 
> "upload_to_ram_and_program" function. 
> 
> Kind regards,
> 
> Adam
> 
> On Thu, Jun 15, 2017 at 1:02 AM, Adam Isaacson  > wrote:
> Hi Jonathan and Mark,
> 
> Thanks for the feedback. The documentation is a work in progress, so feedback 
> is important.
> 
> I will certainly add a How To on configuring the SKARAB via the JTAG and we 
> are/will be working on a user manual for casperfpga.
> 
> The schematics are part of the "Peralex Documentation" link I sent to you 
> earlier today. Check the link, it is there.
> 
> Here are the relevant ones explained (for general CASPER community use):
> 
> 1) How to install Vivado on Ubuntu 14.04LTS 
> (https://drive.google.com/drive/folders/0B2dCFqGD5y-8YTNGT0wzZTFXU1E?usp=sharing
>  
> ).
>  I am currently using Vivado 2016.2 and I suggest using the same. The How To 
> document explains how to install: 2014.3.1, 2015.4 and 2016.2. NB: Rule of 
> thumb I follow, if you are working with Vivado 2016 then use the 
> corresponding year for the Matlab version i.e. R2016a or R2016b. If you don't 
> then there will be issues with compatibility regarding the system generator 
> tools. It is a step by step how to, so should be detailed enough to install.
> 
> 2) How to install Matlab on Ubuntu 14.04LTS 
> (https://drive.google.com/drive/folders/0B2dCFqGD5y-8anluUTg1ZjZxbWc?usp=sharing
>  
> ).
>  I am currently using Matlab R2016b and I suggest using the same. The How To 
> document explains how to install: Matlab R2012b, R2015b and R2016b. I have 
> only ever used R2015b and R2016b with the JASPER toolflow - R2012b has been 
> used with the old CASPER toolflow and with Xilinx ISE 14.7. This How To may 
> help Arash with the issue regarding the LIBSTDC files.
> 
> 3) How to use the new JASPER toolflow using Matlab/Python or just from Python 
> (https://docs.google.com/document/d/131VGftG8QoCVqnm5unFcj0pplnPoI17urIgvb-qymu4/edit?usp=sharing
>  
> ).
>  This document will explain how to run the commands in order to generate a 
> fpg file either using matlab with python or just directly from python. It 
> explains the arguments for the exec_flow command. This is a very useful 
> document and should be read.
> 
> 4) The JASPER toolflow mlib_devel directory explained 
> (https://docs.google.com/document/d/1L0j6vihbT2DsT45SrWc58J2htheJDW4cpQxUw-wlf0E/edit?usp=sharing
>  
> ).
>  This is what Jack Hickish sent to me at the beginning of the year explaining 
> the new mlib_devel directory structure. This is useful for Mark and anyone 
> else who is new to CASPER.
> 
> This will be placed on GitHub before the CASPER 2017 conference.
> 
> I hope this answers your questions.
> 
> Kind regards,
> 
> Adam
> 
>   
> 
> 
> 
> On Thu, Jun 15, 2017 at 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 

Re: [casper] Unable to Load Firmware Image onto SKARAB

[Adam Isaacson]

Hi Jonathan and Mark,

I have written a How To for configuring the flash via the JTAG (
https://docs.google.com/a/ska.ac.za/document/d/1TeVELJ1jEQLzk-qqzWhXODd_HEalTkDJhXq4Q1Y_qgU/edit?usp=sharing
)

I have also updated the https://github.com/ska-sa/skarab_bsp_images (master
branch) repo with the *.prm files required. I went through this process
this morning and successfully configured the flash.

Let me know if you have any issues.

@ Mark: Please only use the flash configuration for the BSP images. If you
have an image generated from the toolflow then please use the casperfpga
"upload_to_ram_and_program" function.

Kind regards,

Adam

On Thu, Jun 15, 2017 at 1:02 AM, Adam Isaacson  wrote:

> Hi Jonathan and Mark,
>
> Thanks for the feedback. The documentation is a work in progress, so
> feedback is important.
>
> I will certainly add a How To on configuring the SKARAB via the JTAG and
> we are/will be working on a user manual for casperfpga.
>
> The schematics are part of the "Peralex Documentation" link I sent to you
> earlier today. Check the link, it is there.
>
> Here are the relevant ones explained (for general CASPER community use):
>
> 1) How to install Vivado on Ubuntu 14.04LTS (https://drive.google.com/driv
> e/folders/0B2dCFqGD5y-8YTNGT0wzZTFXU1E?usp=sharing). I am currently using
> Vivado 2016.2 and I suggest using the same. The How To document explains
> how to install: 2014.3.1, 2015.4 and 2016.2. NB: Rule of thumb I follow, if
> you are working with Vivado 2016 then use the corresponding year for the
> Matlab version i.e. R2016a or R2016b. If you don't then there will be
> issues with compatibility regarding the system generator tools. It is a
> step by step how to, so should be detailed enough to install.
>
> 2) How to install Matlab on Ubuntu 14.04LTS (https://drive.google.com/driv
> e/folders/0B2dCFqGD5y-8anluUTg1ZjZxbWc?usp=sharing). I am currently using
> Matlab R2016b and I suggest using the same. The How To document explains
> how to install: Matlab R2012b, R2015b and R2016b. I have only ever used
> R2015b and R2016b with the JASPER toolflow - R2012b has been used with the
> old CASPER toolflow and with Xilinx ISE 14.7. This How To may help Arash
> with the issue regarding the LIBSTDC files.
>
> 3) How to use the new JASPER toolflow using Matlab/Python or just from
> Python (https://docs.google.com/document/d/131VGftG8QoCVqnm5unFcj0p
> plnPoI17urIgvb-qymu4/edit?usp=sharing). This document will explain how to
> run the commands in order to generate a fpg file either using matlab with
> python or just directly from python. It explains the arguments for the
> exec_flow command. This is a very useful document and should be read.
>
> 4) The JASPER toolflow mlib_devel directory explained (
> https://docs.google.com/document/d/1L0j6vihbT2DsT45SrWc58J2
> htheJDW4cpQxUw-wlf0E/edit?usp=sharing). This is what Jack Hickish sent to
> me at the beginning of the year explaining the new mlib_devel directory
> structure. This is useful for Mark and anyone else who is new to CASPER.
>
> This will be placed on GitHub before the CASPER 2017 conference.
>
> I hope this answers your questions.
>
> Kind regards,
>
> Adam
>
>
>
>
>
> On Thu, Jun 15, 2017 at 12:45 AM, Jonathan Weintroub <
> jweintr...@cfa.harvard.edu> 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 
>> 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 

Re: [casper] Unable to Load Firmware Image onto SKARAB

[Adam Isaacson]

Hi Jonathan and Mark,

Thanks for the feedback. The documentation is a work in progress, so
feedback is important.

I will certainly add a How To on configuring the SKARAB via the JTAG and we
are/will be working on a user manual for casperfpga.

The schematics are part of the "Peralex Documentation" link I sent to you
earlier today. Check the link, it is there.

Here are the relevant ones explained (for general CASPER community use):

1) How to install Vivado on Ubuntu 14.04LTS (https://drive.google.com/
drive/folders/0B2dCFqGD5y-8YTNGT0wzZTFXU1E?usp=sharing). I am currently
using Vivado 2016.2 and I suggest using the same. The How To document
explains how to install: 2014.3.1, 2015.4 and 2016.2. NB: Rule of thumb I
follow, if you are working with Vivado 2016 then use the corresponding year
for the Matlab version i.e. R2016a or R2016b. If you don't then there will
be issues with compatibility regarding the system generator tools. It is a
step by step how to, so should be detailed enough to install.

2) How to install Matlab on Ubuntu 14.04LTS (https://drive.google.com/
drive/folders/0B2dCFqGD5y-8anluUTg1ZjZxbWc?usp=sharing). I am currently
using Matlab R2016b and I suggest using the same. The How To document
explains how to install: Matlab R2012b, R2015b and R2016b. I have only ever
used R2015b and R2016b with the JASPER toolflow - R2012b has been used with
the old CASPER toolflow and with Xilinx ISE 14.7. This How To may help
Arash with the issue regarding the LIBSTDC files.

3) How to use the new JASPER toolflow using Matlab/Python or just from
Python (https://docs.google.com/document/d/131VGftG8QoCVqnm5unFcj0pplnPoI
17urIgvb-qymu4/edit?usp=sharing). This document will explain how to run the
commands in order to generate a fpg file either using matlab with python or
just directly from python. It explains the arguments for the exec_flow
command. This is a very useful document and should be read.

4) The JASPER toolflow mlib_devel directory explained (
https://docs.google.com/document/d/1L0j6vihbT2DsT45SrWc58J2htheJD
W4cpQxUw-wlf0E/edit?usp=sharing). This is what Jack Hickish sent to me at
the beginning of the year explaining the new mlib_devel directory
structure. This is useful for Mark and anyone else who is new to CASPER.

This will be placed on GitHub before the CASPER 2017 conference.

I hope this answers your questions.

Kind regards,

Adam





On Thu, Jun 15, 2017 at 12:45 AM, Jonathan Weintroub <
jweintr...@cfa.harvard.edu> 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  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 

Re: [casper] Unable to Load Firmware Image onto SKARAB

[Jonathan Weintroub]

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  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.
> 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> 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  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 <+27%2021%20506%207300>
>>> www.ska.ac.za
>>>
>>>
>>>
>>> On Wed, Jun 14, 2017 at 7:16 PM, Peryer, Mark A. <
>>> 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.

 

Re: [casper] Unable to Load Firmware Image onto SKARAB

[Adam Isaacson]

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.
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> 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  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 <+27%2021%20506%207300>
>> www.ska.ac.za
>>
>>
>>
>> On Wed, Jun 14, 2017 at 7:16 PM, Peryer, Mark A. <
>> 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: 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" 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.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> 

Re: [casper] Unable to Load Firmware Image onto SKARAB

[Jonathan Weintroub]

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  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
> www.ska.ac.za
>
>
>
> On Wed, Jun 14, 2017 at 7:16 PM, Peryer, Mark A. <
> 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: 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" 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.
>>
>
> --
> 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.
>

-- 
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.

Re: [casper] Unable to Load Firmware Image onto SKARAB

[Adam Isaacson]

Hi Mark,

I assume you were loading the latest BSP images to your SKARAB? Further to
what Wesley said,  please can you also indicate the following:

1) Did you reprogramme both the multiboot and golden flash images?
2) Did you use the *.hex or *.bin file that was in the repo?
3) Is it possible that you configured the multiboot image at address 0x0
and the golden image at address 0x300 instead of the multiboot image at
0x300 and the golden image at 0x0?
4) I am assuming you powered down the board after configuration?
5) Can you explain in step format how you went about configuring the flash?

Okay, so it seems the image in the flash is corrupt. Yes, it is possible to
configure the flash on your board via the JTAG and using the *.mcs files
and the Vivado hardware manager. This will involve removing the SKARAB lid
to access the connector, but let us first see if your board comes back and
what steps resulted in this issue.

Kind regards,

Adam





On Wed, Jun 14, 2017 at 11:11 PM, Wesley New  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 <+27%2021%20506%207300>
> www.ska.ac.za
>
>
>
> On Wed, Jun 14, 2017 at 7:16 PM, Peryer, Mark A. <
> 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: 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" 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.
>>
>
> --
> 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.
>



-- 
[image: SKA_banner]

Best Regards / Vriendelike Groete

*Adam Isaacson*
FPGA Engineer

[image: SKA_banner][image: SKA_banner]
[image: SKA_banner]   (+27) 82 563 9602 [image: SKA_banner]   3rd Floor,
The Park, Park Road,
[image: SKA_banner]   (+27) 21 506 7300 Pinelands
[image: SKA_banner]   (+27) 21 506 7375 7405
[image: SKA_banner]   www.ska.ac.za South Africa

-- 
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.

Re: [casper] Unable to Load Firmware Image onto SKARAB

[Wesley New]

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
www.ska.ac.za



On Wed, Jun 14, 2017 at 7:16 PM, Peryer, Mark A. <
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: 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" 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.
>

-- 
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.