Commit 33becf20 authored by Andrey Filippov's avatar Andrey Filippov

Added files and instructions to test bitstream files in Elphel NC353 camera

parent 851608a0
Testing new generated bitstream images in Elphel NC353 cameras
==============================================================
CAUTION: Replacing /etc/x353.bit bit file with the experimental one can make the camera
hang, at it it will repeat each time you reboot the camera as the /etc/init.d/fpga
script will attempt to use the same file again.
Here is the modified version of this script - you may use ftp client to replace the original 'fpga' script:
$ ftp 192.168.0.9
Connected to 192.168.0.9.
220 Elphel (R) Model 353 Camera release 8.2.16 (May 16 2015) ready.
Name (192.168.0.9:user): root
331 User name okay, need password.
Password: <pass>
230 User logged in, proceed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /etc/init.d
250 Command successful.
ftp> put fpga
local: fpga remote: fpga
200 Command okay.
150 Opening data connection.
226 Transfer complete.
16251 bytes sent in 0.00 secs (453431.9 kB/s)
ftp> exit
221 Goodbye.
This is the modified part of the script:
FPGA_ONE_TIME_IMAGE="/etc/x353_experimental.bit"
FPGA_TMP_IMAGE="/var/tmp/x353_experimental.bit"
if [ -f $FPGA_ONE_TIME_IMAGE ] ; then
echo "Moving $FPGA_ONE_TIME_IMAGE to /var/tmp"
mv $FPGA_ONE_TIME_IMAGE /var/tmp
sync
FPGA_IMAGE=$FPGA_TMP_IMAGE
fi
echo "For testing unsafe experimental bitsteam images:"
echo "Name this file as $FPGA_ONE_TIME_IMAGE - it will be 'deleted before used'"
echo "so next boot will use the original (safe) bitstream file"
So regardless of success or failure of the testing of the experimental bitstream file
it will be used only until the next reboot/power cycle.
To test the new bitstream file you need to rename it to x353_experimental.bit and ftp to
camera /etc directory (supposing you started from the local directory with the
x353_experimental.bit file:
$ ftp 192.168.0.9
Connected to 192.168.0.9.
220 Elphel (R) Model 353 Camera release 8.2.16 (May 16 2015) ready.
Name (192.168.0.9:user): root
331 User name okay, need password.
Password: <pass>
230 User logged in, proceed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> put x353_experimental.bit
local: x353_experimental.bit remote: x353_experimental.bit
200 Command okay.
150 Opening data connection.
226 Transfer complete.
480220 bytes sent in 1.45 secs (324.2 kB/s)
ftp> exit
221 Goodbye.
A sample bitstream file is in the ISE_14_7_results directory, with the default project settings
the new generated bitstream files will be in the ise_results subdirectory.
It is a good idea to telnet to the camera and issue a 'sync' command (equivalent to the
"safely remove" for the flash cards). Or just open [http://<your_camera_ip>/phpshell.php?command=sync]
in the browser.
Good hacking!
Elphel team
\ No newline at end of file
This diff is collapsed.
...@@ -8,71 +8,20 @@ This repository is created as a reference for simulation of image acquisition, p ...@@ -8,71 +8,20 @@ This repository is created as a reference for simulation of image acquisition, p
in the new NC393 camera that includes functionality of the previous one, so the same input image (on one of in the new NC393 camera that includes functionality of the previous one, so the same input image (on one of
the 4 channels) should generate the same intermediate and final compressed files on both cameras. the 4 channels) should generate the same intermediate and final compressed files on both cameras.
We will also try to make it possible to generate functional bitstream files compatible with the existing Project is modified to work with the current (and the last!) version of Xilinx ISE - 14.7,
NC353 camera (so others will be able to modify their camera code with the current version of Xilinx tools), not tested enough, but the generated bitstream proved to be operational on just one camera. It is not yet safe
but we are not there yet - ***this project is valid for simulation only!*** to replace the x353.bit camera unless you have experience in reflashing "bricked" camera as described in
[http://wiki.elphel.com/index.php?title=Netboot_firmware_upgrade] as it is easy to accidentally make a camera
non-bootable.
Here is what makes it difficult: **NC353_TESTING** sub-directory contains description how to make such testing reasonably safe, together with
the 'fpga' init script (automatically executed at boot time) that should be replaced in the camera file system.
1. Xilinx abandoned support for the older devices in the current software called "Vivado". **ISE_10_1_03_files** directory contains files from the original design that relied on ancient ISE 10.1.03.
2. Last verion of the ISE (it is ISE 14.7) can not use the older code "as is"
3. We were able to modify the Verilog code to be parsed by the current XST, but it does not
recognize some statements in the *.xcf constraints file (I had to rename original *.ucf to *.xcf).
4. Attempt to try old parser (suggested by XST itself as the new parser is not the default for
the Spartan 3e):
```
WARNING:Xst:3152 - You have chosen to run a version of XST which is not the default
solution for the specified device family. You are free to use it in order to take
advantage of its enhanced HDL parsing/elaboration capabilities. However,
please be aware that you may be impacted by language support differences.
This version may also result in circuit performance and device utilization
differences for your particular design. You can always revert back to the
default XST solution by setting the "use_new_parser" option to value "no"
on the XST command line or in the XST process properties panel.
```
also failed. After I added recommended options:
``` **ISE_14_7_results** includes log and results from the current tools
run -use_new_parser no -ifn x353.prj -ofn x353.ngc -top x353 -p xc3s1200eft256 -uc x353.xcf -opt_mode speed -opt_level 1
``` You may follow instructions in the README.md for the [VDT plugin](https://github.com/Elphel/vdt-plugin) ,
just use this (x353) project instead of the eddr3 mentioned in the documentation. And you will need to use
Xilinx ISE (not Xilinx Vivado) for this Spartan3e FPGA.
and ISE noticed that:
```
WARNING:Xst:1583 - You are using an internal switch '-use_new_parser'.
```
It still repeated the same WARNING:Xst:3152 (see above) disregarding its own suggestion.
So we will need to find a way how to replace lines in the *xst file that cause errors in XST:
```
204 TIMEGRP "CPU_ADDR" = pads("A<*>");
205 TIMEGRP "CPU_ADDRCE" = "CPU_ADDR" pads("CE*");
206 TIMEGRP "CPU_DATA" = pads("D<*>");
207 TIMEGRP "WE" = pads("WE");
208 TIMEGRP "OE" = pads("OE");
209 TIMEGRP "DACK_PAD"= pads("DACK*");
209 TIMEGRP "DREQ_PAD"= pads("DREQ*");
210 TIMEGRP "ALLPADS"= pads("*");
```
```
ERROR:Xst:1888 - Processing TIMEGRP CPU_ADDR: User group 'pads("A<*>")' defined from
other user group pattern not supported.
```
Even Google does not know what to do about this Xilinx XST feature:
> No results found for "ERROR:Xst:1888".
>
> Results for ERROR:Xst:1888 (without quotes):
>
> ...
So we'try to find other ways to re-formulate old timing constraints preserving the same meaning and try
again to run tools. Until then I'll have to mention again ***this project is valid for simulation only!***
Update: Not yet tested with the real hardware, but the project was modified to work with ISE 14.7 (physical
constraints were changed to parameters from the old style synthesis attributes, and the tools genereted a
bitfile and even original timing constraints (after changing to uppercase) were met.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment