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

NC353_TESTING/README.md

+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

README.md

@@ -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
 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
-NC353 camera (so others will be able to modify their camera code with the current version of Xilinx tools),
-but we are not there yet - ***this project is valid for simulation only!***
+Project is modified to work with the current (and the last!) version of Xilinx ISE - 14.7,
+not tested enough, but the generated bitstream proved to be operational on just one camera. It is not yet safe
+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".
-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_10_1_03_files** directory contains files from the original design that relied on ancient ISE 10.1.03.
 
-```
-run  -use_new_parser no -ifn  x353.prj  -ofn x353.ngc  -top x353  -p xc3s1200eft256  -uc x353.xcf  -opt_mode speed  -opt_level 1 
-```
+**ISE_14_7_results** includes log and results from the current tools
  
-and ISE noticed that:
+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.
 
-```
-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.