Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
X
x353
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Commits
Open sidebar
Elphel
x353
Commits
d0085ebb
Commit
d0085ebb
authored
Jul 26, 2015
by
Andrey Filippov
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
added description of the project
parent
ffb8037f
Changes
3
Expand all
Hide whitespace changes
Inline
Side-by-side
Showing
3 changed files
with
494 additions
and
1 deletion
+494
-1
.project
.project
+6
-1
README.md
README.md
+59
-0
x353.xcf
x353.xcf
+429
-0
No files found.
.project
View file @
d0085ebb
...
...
@@ -17,7 +17,12 @@
<link>
<name>
ise_logs/ISExst.log
</name>
<type>
1
</type>
<location>
/home/andrey/git/x353/ise_logs/ISExst-20150726001950045.log
</location>
<location>
/home/andrey/git/x353/ise_logs/ISExst-20150726141146079.log
</location>
</link>
<link>
<name>
ise_state/x353-synth.tgz
</name>
<type>
1
</type>
<location>
/home/andrey/git/x353/ise_state/x353-synth-20150726135708468.tgz
</location>
</link>
</linkedResources>
</projectDescription>
README.md
0 → 100644
View file @
d0085ebb
x393
=====
FPGA code for Elphel NC353 camera, updated to work with
[
VDT plugin
](
https://github.com/Elphel/vdt-plugin
)
This repository is created as a reference for simulation of image acquisition, processing and compression
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!**
*
Here is what makes it difficult:
1.
Xilinx abandoned support of 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:
```
run -use_new_parser no -ifn x353.prj -ofn x353.ngc -top x353 -p xc3s1200eft256 -uc x353.xcf -opt_mode speed -opt_level 1
```
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".
So we'try to find other ways to re-formulate old timing constraints preserving the same meaning and try
again to run tools.
x353.xcf
0 → 100644
View file @
d0085ebb
This diff is collapsed.
Click to expand it.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment