URL
https://opencores.org/ocsvn/s6soc/s6soc/trunk
Subversion Repositories s6soc
Compare Revisions
- This comparison shows the changes necessary to convert path
/s6soc/trunk/doc
- from Rev 40 to Rev 41
- ↔ Reverse comparison
Rev 40 → Rev 41
/spec.pdf
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
/gfx/pmodmap.eps
1,7 → 1,7
%!PS-Adobe-2.0 EPSF-2.0 |
%%Title: /home/dan/work/rnd/opencores/s6soc/trunk/doc/gfx/pmodmap.dia |
%%Creator: Dia v0.97.2 |
%%CreationDate: Fri Apr 29 19:02:02 2016 |
%%CreationDate: Mon May 23 11:43:28 2016 |
%%For: dan |
%%Orientation: Portrait |
%%Magnification: 1.0000 |
/gfx/s6bones.eps
1,7 → 1,7
%!PS-Adobe-2.0 EPSF-2.0 |
%%Title: /home/dan/jericho/work/rnd/opencores/s6soc/trunk/doc/gfx/s6bones.dia |
%%Title: /home/dan/work/rnd/opencores/s6soc/trunk/doc/gfx/s6bones.dia |
%%Creator: Dia v0.97.2 |
%%CreationDate: Sat Apr 23 06:36:46 2016 |
%%CreationDate: Tue May 17 20:32:00 2016 |
%%For: dan |
%%Orientation: Portrait |
%%Magnification: 1.0000 |
2869,7 → 2869,7
end_ol grestore |
0.300000 slw |
[0.200000] 0 sd |
[0.800000] 0 sd |
[1.600000] 0 sd |
1 slj |
0.749020 0.749020 0.749020 srgb |
n 5.500000 58.000000 m 5.500000 66.000000 l 27.500000 66.000000 l 27.500000 58.000000 l f |
8442,11 → 8442,16
11028 1664 12138 3205 conicto |
13248 4747 13248 7456 conicto |
end_ol grestore |
0.400000 slw |
0.600000 slw |
[] 0 sd |
[] 0 sd |
0 slc |
n 94.000000 11.000000 m 98.000000 11.000000 l s |
0.300000 slw |
[0.200000] 0 sd |
[1.600000] 0 sd |
1 slj |
1.000000 1.000000 1.000000 srgb |
0.749020 0.749020 0.749020 srgb |
n 69.500000 8.000000 m 69.500000 14.000000 l 92.500000 14.000000 l 92.500000 8.000000 l f |
n 69.500000 9.500000 m 69.500000 9.500000 1.500000 1.500000 180.000000 270.000000 ellipse f |
n 92.500000 9.500000 m 92.500000 9.500000 1.500000 1.500000 270.000000 360.000000 ellipse f |
8462,7 → 8467,7
n 94.000000 9.500000 m 94.000000 12.500000 l s |
n 69.500000 12.500000 1.500000 1.500000 90.000000 180.000000 ellipse s |
n 92.500000 12.500000 1.500000 1.500000 0.000000 90.000000 ellipse s |
gsave 72.967500 11.674156 translate 0.035278 -0.035278 scale |
gsave 72.967500 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
6783 5241 moveto |
7271 5077 7732 4539 conicto |
8490,7 → 8495,7
5992 9984 4903 9984 conicto |
3008 9984 lineto |
end_ol grestore |
gsave 74.286266 11.674156 translate 0.035278 -0.035278 scale |
gsave 74.286266 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
8640 4520 moveto |
8640 3840 lineto |
8515,7 → 8520,7
2453 6112 2349 4921 conicto |
7232 4928 lineto |
end_ol grestore |
gsave 75.535099 11.674156 translate 0.035278 -0.035278 scale |
gsave 75.535099 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
5234 4224 moveto |
3580 4224 2942 3844 conicto |
8548,7 → 8553,7
6204 8576 7102 7639 conicto |
8000 6702 8000 4798 conicto |
end_ol grestore |
gsave 76.778930 11.674156 translate 0.035278 -0.035278 scale |
gsave 76.778930 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
1472 11648 moveto |
2880 11648 lineto |
8556,7 → 8561,7
1472 0 lineto |
1472 11648 lineto |
end_ol grestore |
gsave 77.343402 11.674156 translate 0.035278 -0.035278 scale |
gsave 77.343402 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
768 4800 moveto |
4800 4800 lineto |
8564,7 → 8569,7
768 3584 lineto |
768 4800 lineto |
end_ol grestore |
gsave 77.887890 11.674156 translate 0.035278 -0.035278 scale |
gsave 77.887890 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
-64 11200 moveto |
9408 11200 lineto |
8576,7 → 8581,7
-64 9920 lineto |
-64 11200 lineto |
end_ol grestore |
gsave 79.064285 11.674156 translate 0.035278 -0.035278 scale |
gsave 79.064285 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
1472 8384 moveto |
2880 8384 lineto |
8589,7 → 8594,7
1472 9920 lineto |
1472 11648 lineto |
end_ol grestore |
gsave 79.628757 11.674156 translate 0.035278 -0.035278 scale |
gsave 79.628757 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
8020 6735 moveto |
8538 7678 9259 8127 conicto |
8620,7 → 8625,7
6430 8576 7071 8104 conicto |
7713 7633 8020 6735 conicto |
end_ol grestore |
gsave 81.606907 11.674156 translate 0.035278 -0.035278 scale |
gsave 81.606907 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
8640 4520 moveto |
8640 3840 lineto |
8645,10 → 8650,10
2453 6112 2349 4921 conicto |
7232 4928 lineto |
end_ol grestore |
gsave 82.855740 11.674156 translate 0.035278 -0.035278 scale |
gsave 82.855740 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
end_ol grestore |
gsave 83.500133 11.674156 translate 0.035278 -0.035278 scale |
gsave 83.500133 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
9856 10304 moveto |
9856 8704 lineto |
8670,7 → 8675,7
7300 11392 8188 11120 conicto |
9077 10848 9856 10304 conicto |
end_ol grestore |
gsave 84.918804 11.674156 translate 0.035278 -0.035278 scale |
gsave 84.918804 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
1472 11648 moveto |
2880 11648 lineto |
8678,7 → 8683,7
1472 0 lineto |
1472 11648 lineto |
end_ol grestore |
gsave 85.483276 11.674156 translate 0.035278 -0.035278 scale |
gsave 85.483276 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
4676 7424 moveto |
3579 7424 2941 6560 conicto |
8699,7 → 8704,7
832 6250 1852 7413 conicto |
2872 8576 4672 8576 conicto |
end_ol grestore |
gsave 86.724610 11.674156 translate 0.035278 -0.035278 scale |
gsave 86.724610 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
7488 8064 moveto |
7488 6784 lineto |
8721,7 → 8726,7
5700 8576 6308 8448 conicto |
6917 8320 7488 8064 conicto |
end_ol grestore |
gsave 87.841060 11.674156 translate 0.035278 -0.035278 scale |
gsave 87.841060 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
1408 11648 moveto |
2816 11648 lineto |
8736,9 → 8741,4
1408 0 lineto |
1408 11648 lineto |
end_ol grestore |
0.600000 slw |
[] 0 sd |
[] 0 sd |
0 slc |
n 94.000000 11.000000 m 98.000000 11.000000 l s |
showpage |
/gfx/altbones.eps
1,11 → 1,11
%!PS-Adobe-2.0 EPSF-2.0 |
%%Title: /home/dan/jericho/work/rnd/opencores/s6soc/trunk/doc/gfx/altbones.dia |
%%Title: /home/dan/work/rnd/opencores/s6soc/trunk/doc/gfx/altbones.dia |
%%Creator: Dia v0.97.2 |
%%CreationDate: Sat Apr 23 06:38:39 2016 |
%%CreationDate: Tue May 17 20:30:09 2016 |
%%For: dan |
%%Orientation: Portrait |
%%Magnification: 1.0000 |
%%BoundingBox: 0 0 648 341 |
%%BoundingBox: 0 0 648 440 |
%%BeginSetup |
%%EndSetup |
%%EndComments |
118,7 → 118,7
/start_ol { gsave 1.1 dpi_x div dup scale} bind def |
/end_ol { closepath fill grestore } bind def |
4.961635 -4.961635 scale |
0.300000 -68.300000 translate |
0.300000 -88.200000 translate |
%%EndProlog |
|
|
4094,11 → 4094,6
[] 0 sd |
0 slc |
n 102.000000 45.000000 m 98.000000 45.000000 l s |
0.600000 slw |
[] 0 sd |
[] 0 sd |
0 slc |
n 120.000000 56.000000 m 120.000000 58.000000 l s |
0.400000 slw |
[] 0 sd |
[] 0 sd |
5447,7 → 5442,7
8156 11392 8438 11328 conicto |
8448 9408 lineto |
end_ol grestore |
gsave 103.061250 10.204729 translate 0.035278 -0.035278 scale |
gsave 103.061250 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
1920 704 moveto |
1920 4096 lineto |
5481,7 → 5476,7
5788 -320 4513 -66 conicto |
3239 187 1920 704 conicto |
end_ol grestore |
gsave 104.914516 10.204729 translate 0.035278 -0.035278 scale |
gsave 104.914516 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
6688 640 moveto |
8089 640 8844 1680 conicto |
5512,10 → 5507,10
5325 14272 4373 12782 conicto |
3422 11292 3392 8201 conicto |
end_ol grestore |
gsave 106.637904 10.204729 translate 0.035278 -0.035278 scale |
gsave 106.637904 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
end_ol grestore |
gsave 107.497097 10.204729 translate 0.035278 -0.035278 scale |
gsave 107.497097 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
15619 0 moveto |
13981 0 lineto |
5540,7 → 5535,7
19524 13824 lineto |
15619 0 lineto |
end_ol grestore |
gsave 110.232037 10.204729 translate 0.035278 -0.035278 scale |
gsave 110.232037 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
2048 13915 moveto |
2048 14369 2378 14704 conicto |
5563,7 → 5558,7
4352 10624 lineto |
4352 1088 lineto |
end_ol grestore |
gsave 111.098721 10.204729 translate 0.035278 -0.035278 scale |
gsave 111.098721 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
1152 576 moveto |
1152 3072 lineto |
5597,7 → 5592,7
4096 -320 3114 -96 conicto |
2133 128 1152 576 conicto |
end_ol grestore |
gsave 112.487420 10.204729 translate 0.035278 -0.035278 scale |
gsave 112.487420 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
832 0 moveto |
832 1088 lineto |
5627,7 → 5622,7
5952 0 lineto |
832 0 lineto |
end_ol grestore |
gsave 114.230784 10.204729 translate 0.035278 -0.035278 scale |
gsave 114.230784 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
2368 1088 moveto |
2368 14464 lineto |
5658,7 → 5653,7
4224 7774 4224 5865 conicto |
4224 4815 lineto |
end_ol grestore |
gsave 115.964161 10.204729 translate 0.035278 -0.035278 scale |
gsave 115.964161 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
6176 640 moveto |
7649 640 8400 1824 conicto |
5679,7 → 5674,7
11328 2765 9919 1222 conicto |
8511 -320 6176 -320 conicto |
end_ol grestore |
gsave 117.592638 10.204729 translate 0.035278 -0.035278 scale |
gsave 117.592638 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
832 0 moveto |
832 1088 lineto |
5709,7 → 5704,7
5952 0 lineto |
832 0 lineto |
end_ol grestore |
gsave 119.336002 10.204729 translate 0.035278 -0.035278 scale |
gsave 119.336002 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
11136 5120 moveto |
3200 5120 lineto |
5734,10 → 5729,10
3360 8071 3200 6208 conicto |
8960 6208 lineto |
end_ol grestore |
gsave 120.937004 10.204729 translate 0.035278 -0.035278 scale |
gsave 120.937004 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
end_ol grestore |
gsave 121.796197 10.204729 translate 0.035278 -0.035278 scale |
gsave 121.796197 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
5056 1088 moveto |
8016 1088 lineto |
5772,7 → 5767,7
10963 0 7996 0 conicto |
1088 0 lineto |
end_ol grestore |
gsave 123.784334 10.204729 translate 0.035278 -0.035278 scale |
gsave 123.784334 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
7296 10624 moveto |
10752 10624 lineto |
5798,7 → 5793,7
7296 9536 lineto |
7296 10624 lineto |
end_ol grestore |
gsave 125.527699 10.204729 translate 0.035278 -0.035278 scale |
gsave 125.527699 10.244167 translate 0.035278 -0.035278 scale |
start_ol |
1152 576 moveto |
1152 3072 lineto |
5832,7 → 5827,7
4096 -320 3114 -96 conicto |
2133 128 1152 576 conicto |
end_ol grestore |
gsave 107.142500 13.591396 translate 0.035278 -0.035278 scale |
gsave 107.142500 13.630833 translate 0.035278 -0.035278 scale |
start_ol |
5056 7616 moveto |
7691 7616 lineto |
5859,7 → 5854,7
7360 0 lineto |
1088 0 lineto |
end_ol grestore |
gsave 108.840910 13.591396 translate 0.035278 -0.035278 scale |
gsave 108.840910 13.630833 translate 0.035278 -0.035278 scale |
start_ol |
11136 5120 moveto |
3200 5120 lineto |
5884,7 → 5879,7
3360 8071 3200 6208 conicto |
8960 6208 lineto |
end_ol grestore |
gsave 110.441912 13.591396 translate 0.035278 -0.035278 scale |
gsave 110.441912 13.630833 translate 0.035278 -0.035278 scale |
start_ol |
9792 10688 moveto |
9792 8000 lineto |
5909,7 → 5904,7
8255 10944 8749 10877 conicto |
9243 10811 9792 10688 conicto |
end_ol grestore |
gsave 111.735700 13.591396 translate 0.035278 -0.035278 scale |
gsave 111.735700 13.630833 translate 0.035278 -0.035278 scale |
start_ol |
2048 13915 moveto |
2048 14369 2378 14704 conicto |
5932,7 → 5927,7
4352 10624 lineto |
4352 1088 lineto |
end_ol grestore |
gsave 112.602384 13.591396 translate 0.035278 -0.035278 scale |
gsave 112.602384 13.630833 translate 0.035278 -0.035278 scale |
start_ol |
4224 5814 moveto |
4224 4764 lineto |
5965,7 → 5960,7
2368 -3200 lineto |
2368 9536 lineto |
end_ol grestore |
gsave 114.335760 13.591396 translate 0.035278 -0.035278 scale |
gsave 114.335760 13.630833 translate 0.035278 -0.035278 scale |
start_ol |
832 0 moveto |
832 1088 lineto |
5995,7 → 5990,7
5952 0 lineto |
832 0 lineto |
end_ol grestore |
gsave 116.079125 13.591396 translate 0.035278 -0.035278 scale |
gsave 116.079125 13.630833 translate 0.035278 -0.035278 scale |
start_ol |
11136 5120 moveto |
3200 5120 lineto |
6020,7 → 6015,7
3360 8071 3200 6208 conicto |
8960 6208 lineto |
end_ol grestore |
gsave 117.680127 13.591396 translate 0.035278 -0.035278 scale |
gsave 117.680127 13.630833 translate 0.035278 -0.035278 scale |
start_ol |
9792 10688 moveto |
9792 8000 lineto |
6045,7 → 6040,7
8255 10944 8749 10877 conicto |
9243 10811 9792 10688 conicto |
end_ol grestore |
gsave 118.973914 13.591396 translate 0.035278 -0.035278 scale |
gsave 118.973914 13.630833 translate 0.035278 -0.035278 scale |
start_ol |
8128 3343 moveto |
8128 5568 lineto |
6081,7 → 6076,7
7680 10944 8832 9842 conicto |
9984 8740 9984 6636 conicto |
end_ol grestore |
gsave 120.587401 13.591396 translate 0.035278 -0.035278 scale |
gsave 120.587401 13.630833 translate 0.035278 -0.035278 scale |
start_ol |
4224 1088 moveto |
5952 1088 lineto |
6095,7 → 6090,7
4224 15552 lineto |
4224 1088 lineto |
end_ol grestore |
gsave 121.454085 13.591396 translate 0.035278 -0.035278 scale |
gsave 121.454085 13.630833 translate 0.035278 -0.035278 scale |
start_ol |
1152 576 moveto |
1152 3072 lineto |
6135,10 → 6130,10
0 slc |
n 98.000000 8.000000 m 98.000000 62.000000 l s |
0.400000 slw |
[] 0 sd |
[] 0 sd |
[0.200000] 0 sd |
[1.600000] 0 sd |
1 slj |
1.000000 1.000000 1.000000 srgb |
0.870588 0.870588 0.870588 srgb |
n 69.500000 8.000000 m 69.500000 14.000000 l 92.500000 14.000000 l 92.500000 8.000000 l f |
n 69.500000 9.500000 m 69.500000 9.500000 1.500000 1.500000 180.000000 270.000000 ellipse f |
n 92.500000 9.500000 m 92.500000 9.500000 1.500000 1.500000 270.000000 360.000000 ellipse f |
6145,7 → 6140,7
n 68.000000 9.500000 m 68.000000 12.500000 l 94.000000 12.500000 l 94.000000 9.500000 l f |
n 69.500000 12.500000 m 69.500000 12.500000 1.500000 1.500000 90.000000 180.000000 ellipse f |
n 92.500000 12.500000 m 92.500000 12.500000 1.500000 1.500000 0.000000 90.000000 ellipse f |
0.000000 0.000000 0.000000 srgb |
0.501961 0.501961 0.501961 srgb |
n 69.500000 8.000000 m 92.500000 8.000000 l s |
n 69.500000 14.000000 m 92.500000 14.000000 l s |
n 69.500000 9.500000 1.500000 1.500000 180.000000 270.000000 ellipse s |
6154,6 → 6149,7
n 94.000000 9.500000 m 94.000000 12.500000 l s |
n 69.500000 12.500000 1.500000 1.500000 90.000000 180.000000 ellipse s |
n 92.500000 12.500000 1.500000 1.500000 0.000000 90.000000 ellipse s |
0.000000 0.000000 0.000000 srgb |
gsave 72.967500 11.703750 translate 0.035278 -0.035278 scale |
start_ol |
6783 5241 moveto |
6433,4 → 6429,318
[] 0 sd |
0 slc |
n 94.000000 11.000000 m 98.000000 11.000000 l s |
0.600000 slw |
[] 0 sd |
[] 0 sd |
0 slc |
n 98.000000 53.000000 m 102.000000 53.000000 l s |
0.400000 slw |
[] 0 sd |
[] 0 sd |
0 slc |
0 slj |
0.400000 slw |
0 slc |
0 slj |
[] 0 sd |
1.000000 1.000000 1.000000 srgb |
n 117.875000 76.500000 m 117.875000 69.500000 l 116.125000 69.500000 l 119.625000 66.000000 l 123.125000 69.500000 l 121.375000 69.500000 l 121.375000 76.500000 l 123.125000 76.500000 l 119.625000 80.000000 l 116.125000 76.500000 l ef |
0.000000 0.000000 0.000000 srgb |
n 117.875000 76.500000 m 117.875000 69.500000 l 116.125000 69.500000 l 119.625000 66.000000 l 123.125000 69.500000 l 121.375000 69.500000 l 121.375000 76.500000 l 123.125000 76.500000 l 119.625000 80.000000 l 116.125000 76.500000 l cp s |
0 slc |
0 slj |
[] 0 sd |
n 117.875000 76.500000 m 117.875000 69.500000 l 116.125000 69.500000 l 119.625000 66.000000 l 123.125000 69.500000 l 121.375000 69.500000 l 121.375000 76.500000 l 123.125000 76.500000 l 119.625000 80.000000 l 116.125000 76.500000 l cp s |
0.400000 slw |
[] 0 sd |
[] 0 sd |
1 slj |
1.000000 1.000000 1.000000 srgb |
n 113.500000 80.000000 m 113.500000 88.000000 l 126.500000 88.000000 l 126.500000 80.000000 l f |
n 113.500000 81.500000 m 113.500000 81.500000 1.500000 1.500000 180.000000 270.000000 ellipse f |
n 126.500000 81.500000 m 126.500000 81.500000 1.500000 1.500000 270.000000 360.000000 ellipse f |
n 112.000000 81.500000 m 112.000000 86.500000 l 128.000000 86.500000 l 128.000000 81.500000 l f |
n 113.500000 86.500000 m 113.500000 86.500000 1.500000 1.500000 90.000000 180.000000 ellipse f |
n 126.500000 86.500000 m 126.500000 86.500000 1.500000 1.500000 0.000000 90.000000 ellipse f |
0.000000 0.000000 0.000000 srgb |
n 113.500000 80.000000 m 126.500000 80.000000 l s |
n 113.500000 88.000000 m 126.500000 88.000000 l s |
n 113.500000 81.500000 1.500000 1.500000 180.000000 270.000000 ellipse s |
n 126.500000 81.500000 1.500000 1.500000 270.000000 360.000000 ellipse s |
n 112.000000 81.500000 m 112.000000 86.500000 l s |
n 128.000000 81.500000 m 128.000000 86.500000 l s |
n 113.500000 86.500000 1.500000 1.500000 90.000000 180.000000 ellipse s |
n 126.500000 86.500000 1.500000 1.500000 0.000000 90.000000 ellipse s |
gsave 116.465000 83.244167 translate 0.035278 -0.035278 scale |
start_ol |
4032 13248 moveto |
4032 1664 lineto |
6467 1664 lineto |
9551 1664 10983 3061 conicto |
12416 4458 12416 7471 conicto |
12416 10464 10983 11856 conicto |
9551 13248 6467 13248 conicto |
4032 13248 lineto |
1984 14912 moveto |
6158 14912 lineto |
10482 14912 12505 13109 conicto |
14528 11306 14528 7471 conicto |
14528 3616 12495 1808 conicto |
10463 0 6158 0 conicto |
1984 0 lineto |
1984 14912 lineto |
end_ol grestore |
gsave 118.550545 83.244167 translate 0.035278 -0.035278 scale |
start_ol |
1984 14912 moveto |
11392 14912 lineto |
11392 13184 lineto |
4032 13184 lineto |
4032 8832 lineto |
11072 8832 lineto |
11072 7104 lineto |
4032 7104 lineto |
4032 1728 lineto |
11584 1728 lineto |
11584 0 lineto |
1984 0 lineto |
1984 14912 lineto |
end_ol grestore |
gsave 120.261440 83.244167 translate 0.035278 -0.035278 scale |
start_ol |
4032 13248 moveto |
4032 7616 lineto |
6578 7616 lineto |
7992 7616 8764 8349 conicto |
9536 9082 9536 10437 conicto |
9536 11782 8764 12515 conicto |
7992 13248 6578 13248 conicto |
4032 13248 lineto |
1984 14912 moveto |
6578 14912 lineto |
9083 14912 10365 13773 conicto |
11648 12634 11648 10437 conicto |
11648 8220 10365 7086 conicto |
9083 5952 6578 5952 conicto |
4032 5952 lineto |
4032 0 lineto |
1984 0 lineto |
1984 14912 lineto |
end_ol grestore |
gsave 121.894911 83.244167 translate 0.035278 -0.035278 scale |
start_ol |
4032 13248 moveto |
4032 7616 lineto |
6578 7616 lineto |
7992 7616 8764 8349 conicto |
9536 9082 9536 10437 conicto |
9536 11782 8764 12515 conicto |
7992 13248 6578 13248 conicto |
4032 13248 lineto |
1984 14912 moveto |
6578 14912 lineto |
9083 14912 10365 13773 conicto |
11648 12634 11648 10437 conicto |
11648 8220 10365 7086 conicto |
9083 5952 6578 5952 conicto |
4032 5952 lineto |
4032 0 lineto |
1984 0 lineto |
1984 14912 lineto |
end_ol grestore |
gsave 113.932500 86.630833 translate 0.035278 -0.035278 scale |
start_ol |
1984 14912 moveto |
4032 14912 lineto |
4032 0 lineto |
1984 0 lineto |
1984 14912 lineto |
end_ol grestore |
gsave 114.731748 86.630833 translate 0.035278 -0.035278 scale |
start_ol |
11264 6769 moveto |
11264 0 lineto |
9408 0 lineto |
9408 6708 lineto |
9408 8287 8787 9071 conicto |
8167 9856 6925 9856 conicto |
5434 9856 4573 8912 conicto |
3712 7968 3712 6338 conicto |
3712 0 lineto |
1856 0 lineto |
1856 11200 lineto |
3712 11200 lineto |
3712 9472 lineto |
4374 10469 5271 10962 conicto |
6169 11456 7343 11456 conicto |
9278 11456 10271 10267 conicto |
11264 9078 11264 6769 conicto |
end_ol grestore |
gsave 116.447637 86.630833 translate 0.035278 -0.035278 scale |
start_ol |
3776 14400 moveto |
3776 11200 lineto |
7552 11200 lineto |
7552 9792 lineto |
3776 9792 lineto |
3776 3693 lineto |
3776 2319 4149 1927 conicto |
4523 1536 5669 1536 conicto |
7552 1536 lineto |
7552 0 lineto |
5669 0 lineto |
3540 0 2730 795 conicto |
1920 1591 1920 3693 conicto |
1920 9792 lineto |
576 9792 lineto |
576 11200 lineto |
1920 11200 lineto |
1920 14400 lineto |
3776 14400 lineto |
end_ol grestore |
gsave 117.509146 86.630833 translate 0.035278 -0.035278 scale |
start_ol |
11520 6040 moveto |
11520 5120 lineto |
3072 5120 lineto |
3192 3213 4213 2214 conicto |
5234 1216 7057 1216 conicto |
8113 1216 9104 1472 conicto |
10096 1728 11072 2240 conicto |
11072 512 lineto |
10085 106 9048 -107 conicto |
8011 -320 6944 -320 conicto |
4273 -320 2712 1242 conicto |
1152 2804 1152 5468 conicto |
1152 8222 2635 9839 conicto |
4119 11456 6636 11456 conicto |
8893 11456 10206 9999 conicto |
11520 8543 11520 6040 conicto |
9664 6592 moveto |
9644 8110 8822 9015 conicto |
8001 9920 6647 9920 conicto |
5114 9920 4192 9045 conicto |
3271 8171 3132 6582 conicto |
9664 6592 lineto |
end_ol grestore |
gsave 119.175086 86.630833 translate 0.035278 -0.035278 scale |
start_ol |
8448 9408 moveto |
8136 9605 7769 9698 conicto |
7402 9792 6960 9792 conicto |
5391 9792 4551 8788 conicto |
3712 7785 3712 5907 conicto |
3712 0 lineto |
1856 0 lineto |
1856 11200 lineto |
3712 11200 lineto |
3712 9472 lineto |
4295 10479 5230 10967 conicto |
6165 11456 7503 11456 conicto |
7694 11456 7925 11424 conicto |
8156 11392 8438 11328 conicto |
8448 9408 lineto |
end_ol grestore |
gsave 120.289040 86.630833 translate 0.035278 -0.035278 scale |
start_ol |
7616 15552 moveto |
7616 14016 lineto |
5843 14016 lineto |
4860 14016 4478 13618 conicto |
4096 13220 4096 12185 conicto |
4096 11200 lineto |
7104 11200 lineto |
7104 9792 lineto |
4096 9792 lineto |
4096 0 lineto |
2240 0 lineto |
2240 9792 lineto |
448 9792 lineto |
448 11200 lineto |
2240 11200 lineto |
2240 11976 lineto |
2240 13844 3108 14698 conicto |
3977 15552 5863 15552 conicto |
7616 15552 lineto |
end_ol grestore |
gsave 121.243144 86.630833 translate 0.035278 -0.035278 scale |
start_ol |
7008 5568 moveto |
4786 5568 3929 5061 conicto |
3072 4555 3072 3332 conicto |
3072 2359 3715 1787 conicto |
4358 1216 5464 1216 conicto |
6988 1216 7910 2294 conicto |
8832 3372 8832 5161 conicto |
8832 5568 lineto |
7008 5568 lineto |
10688 6345 moveto |
10688 0 lineto |
8832 0 lineto |
8832 1664 lineto |
8202 647 7262 163 conicto |
6323 -320 4964 -320 conicto |
3245 -320 2230 645 conicto |
1216 1610 1216 3230 conicto |
1216 5120 2482 6080 conicto |
3749 7040 6261 7040 conicto |
8832 7040 lineto |
8832 7226 lineto |
8832 8512 7999 9216 conicto |
7166 9920 5659 9920 conicto |
4702 9920 3794 9696 conicto |
2886 9472 2048 9024 conicto |
2048 10752 lineto |
3058 11104 4008 11280 conicto |
4958 11456 5858 11456 conicto |
8288 11456 9488 10188 conicto |
10688 8921 10688 6345 conicto |
end_ol grestore |
gsave 122.901594 86.630833 translate 0.035278 -0.035278 scale |
start_ol |
9984 10816 moveto |
9984 9088 lineto |
9205 9504 8421 9712 conicto |
7637 9920 6838 9920 conicto |
5050 9920 4061 8776 conicto |
3072 7633 3072 5568 conicto |
3072 3503 4061 2359 conicto |
5050 1216 6838 1216 conicto |
7637 1216 8421 1424 conicto |
9205 1632 9984 2048 conicto |
9984 320 lineto |
9216 0 8394 -160 conicto |
7572 -320 6645 -320 conicto |
4123 -320 2637 1272 conicto |
1152 2864 1152 5568 conicto |
1152 8312 2652 9884 conicto |
4152 11456 6764 11456 conicto |
7612 11456 8419 11296 conicto |
9226 11136 9984 10816 conicto |
end_ol grestore |
gsave 124.390198 86.630833 translate 0.035278 -0.035278 scale |
start_ol |
11520 6040 moveto |
11520 5120 lineto |
3072 5120 lineto |
3192 3213 4213 2214 conicto |
5234 1216 7057 1216 conicto |
8113 1216 9104 1472 conicto |
10096 1728 11072 2240 conicto |
11072 512 lineto |
10085 106 9048 -107 conicto |
8011 -320 6944 -320 conicto |
4273 -320 2712 1242 conicto |
1152 2804 1152 5468 conicto |
1152 8222 2635 9839 conicto |
4119 11456 6636 11456 conicto |
8893 11456 10206 9999 conicto |
11520 8543 11520 6040 conicto |
9664 6592 moveto |
9644 8110 8822 9015 conicto |
8001 9920 6647 9920 conicto |
5114 9920 4192 9045 conicto |
3271 8171 3132 6582 conicto |
9664 6592 lineto |
end_ol grestore |
showpage |
/src/spec.tex
5,7 → 5,7
\title{Specification} |
\author{Dan Gisselquist, Ph.D.} |
\email{dgisselq (at) opencores.org} |
\revision{Rev.~0.2} |
\revision{Rev.~0.3} |
\begin{document} |
\pagestyle{gqtekspecplain} |
\titlepage |
26,6 → 26,8
with this program. If not, see \texttt{http://www.gnu.org/licenses/} for a copy. |
\end{license} |
\begin{revisionhistory} |
0.3 & 5/23/2016 & Gisselquist & Draft for comment, includes ZipOS and PMod |
pin mapping\\\hline |
0.2 & 5/14/2016 & Gisselquist & Updated Draft, still not complete \\\hline |
0.1 & 4/22/2016 & Gisselquist & First Draft \\\hline |
\end{revisionhistory} |
38,7 → 40,13
The Zip CPU was built with the express purpose of being an area optimized, |
32--bit FPGA soft processor. |
|
The S6~SoC is designed to prove that the ZipCPU has met this goal. |
The S6~SoC is designed to prove that the Zip~CPU has met this goal. |
|
There are two side--effects to this. First, the project proves how capable a |
CMod--S6 is, and second, this project provides demonstration implementations |
of how to interact with a variety of PMod devices: the audio amplifier, |
the serial 2--line LCD display, the USBUART, and the 16--character numeric |
keypad. |
\end{preface} |
|
\chapter{Introduction} |
45,57 → 53,84
\pagenumbering{arabic} |
\setcounter{page}{1} |
|
This project is ongoing. Any and all files, to include this one, are subject |
to change without notice. |
% What is old |
The Zip~CPU is a soft core CPU designed to fit within an FPGA, to use a minimum |
amount of the FPGA's resources, and yet to provide the services of a fully |
capable 32--bit computer. It is based upon a Von~Neumann architecure and so a |
single 32--bit wishbone bus provides it with access to both peripherals and |
memory. |
|
This project comes from my desire to demonstrate the Zip CPU's utility in a |
challenging environment. The CMod~S6 board fits this role nicely. |
% What does the old lack? |
Previous demonstrations of the Zip~CPU have focused on larger FPGAs, such as |
the Spartan--6 LX9 and LX25 and the Artix--7 35T. On these FPGA's, |
the Zip~CPU runs in a pipelined configuration where it is tightly integrated |
with a prefetch/instruction cache. While these demonstrations have shown that |
the Zip~CPU can act as a very simple CPU in these environments, they really |
haven't demonstrated the ability of the Zip~CPU to use only a minimum amount |
of the FPGA's resources. |
|
% What is new |
The CMod~S6 board provides the opportunity for that demonstration rather nicely. |
% What does the new have that the old lacks |
\begin{enumerate} |
\item The Spartan--6 LX4 FPGA is very limited in its resources: |
It only has 2,400 look--up tables (LUTs), and can only support |
a 4,096~Word RAM memory (16 kB). |
\item With only 4kW RAM, the majority of any program will need to be placed into |
and run from flash. (The chip will actually support more, just not |
8k RAM.) |
and run from flash. |
\item While the chip has enough area for the CPU, it doesn't have enough area |
to include the CPU and \ldots write access to the flash, debug access, |
wishbone command access from the UART, pipelined CPU operations, and |
more. Other solutions will need to be found. |
wishbone command access from the UART, pipelined CPU operations, |
a prefetch cache and more. Other solutions will need to be found. |
\end{enumerate} |
|
Of course, if someone just wants the functionality of a small, cheap, CPU, |
this project does not fit that role very well. While the S6 is not very |
expensive, it is still an order of magnitude greater than it's CPU competitors |
in price. This includes such CPU's as the Raspberry Pi Zero, or even the |
TeensyLC. |
expensive at nearly \$70, it is still an order of magnitude greater than it's |
CPU competitors in price. This includes such CPU's as the Raspberry Pi Zero |
(\$5), or even the TeensyLC (\$12). |
|
If, on the other hand, what you want is a small, cheap, CPU that can be embedded |
within an FPGA without using too much of the FPGA's resources, this project |
will demonstrate that utility and possibility. Alternatively, if you wish to |
study how to get a CPU to work in a small, constrained environment, this project |
may be what you are looking for. |
% What performance gain can be expected? |
|
If, on the other hand, what you want is a small, cheap, CPU that can be |
embedded within an FPGA without using too much of the FPGA's resources, this |
project will demonstrate that possibility as well as some utility. |
Alternatively, if you wish to study how to get a CPU to work in a small, |
constrained environment, this project may be what you are looking for. |
|
Finally, because the Zip~CPU and the included ZipOS are as small and simple as |
they are, the code base found here will be simpler to understand than the |
code bases for some of these other projects. For example, the Zip~CPU |
instruction set is very simple. With less than 40 instructions, it is much |
easier to understand and learn than the ARM instruction set. Further, unlike |
the ARM, the entire specification for and description of the Zip~CPU is |
publicly available. Likewise, an operating system such as the ZipOS that has |
less than \hbox{3,000} lines of code will be much easier to understand than any |
Linux operating system--even if it has much less functionality. |
|
\chapter{Architecture} |
Fig.~\ref{fig:architecture} |
\begin{figure}\begin{center} |
\includegraphics[width=5in]{../gfx/s6bones.eps} |
\caption{CMod S6 SoC Architecture: ZipCPU and |
\caption{CMod S6 SoC Architecture: Zip~CPU and |
Peripherals}\label{fig:architecture} |
\end{center}\end{figure} |
shows the basic internal architecture of the S6~SoC. In summary, it consists of a CPU |
shows the basic internal architecture of the S6~SoC. In summary, it consists |
of a CPU |
coupled with a variety of peripherals for the purpose of controlling the |
external peripherals of the S6: flash, LEDs, buttons, and GPIO. External |
devices may also be added on, such as an audio device, an external serial |
port, an external keypad, and an external display. All of these devices |
are then available for the CPU to interact with. |
external peripherals of the S6~SoC: flash, LEDs, buttons, and GPIO. External |
devices may also be added on, and have been added on as part of this project, |
such as an audio device, an external serial port, an external keypad, and an |
external display. All of these devices are then available for the CPU to |
interact with. |
|
If you are familiar with the Zip CPU, you'll notice this architecture provides |
no access to the Zip CPU debug port. There simply wasn't enough room on the |
device. Debugging the ZipCPU will instead need to take place via other means, |
device. Debugging the Zip~CPU will instead need to take place via other means, |
such as dumping all registers and/or memory to the serial port on any reboot. |
|
Further, the ZipCPU has no ability to write to flash memory. For this reason, |
there exists an alternate CMod S6~SoC architecture, as shown in |
Further, the Zip~CPU has no ability to write to flash memory. For this reason, |
there exists an alternate CMod S6~SoC architecture, shown in |
Fig.~\ref{fig:altarchitecture}. |
\begin{figure}\begin{center} |
\includegraphics[width=5in]{../gfx/altbones.eps} |
109,9 → 144,13
The basic approach to loading the board is actually quite simple. Using the |
Digilent ADEPT JTAG configuration program, {\tt djtgcfg}, the alternate |
configuration may be written directly to the device. Once this alternate |
configuration has been loaded, the flash may be examined and programmed. |
This includes programming a primary and alternate configuration into the |
configuration section of the flash. Once complete, the system may then be |
configuration has been loaded, the flash may be examined and programmed using |
the {\tt zipload} utility. This utility uses Digilent's Asynchronous Parallel |
Port interface (DEPP) to communicate with the device, and in particular to |
tell the device what to write to the flash. When writing to the flash, |
the {\tt zipload} utility will program both a primary and an alternate |
FPGA configuration into the configuration section of the flash, as well as |
computer code into the rest of the flash. Once complete, the system may then be |
reloaded with the primary configuration file which will contain an image of |
the CPU. The CPU will then begin following the instructions found in flash |
memory. |
118,6 → 157,11
|
|
\chapter{Software} |
This chapter provides an overview of the software that is available to support |
the S6~SoC. This includes not only the RTL, the Makefiles, and the software |
that will run on the Zip~CPU within the S6~SoC, but also the support software |
necessary for communicating with the S6~SoC in its alternate configuration. |
|
\section{Directory Structure} |
\begin{itemize} |
\item[{\tt trunk/bench}] Contains software for emulating the S6 without the S6 |
126,7 → 170,7
\item[{\tt trunk/bench/cpp}] All of the bench testing software is |
written in C++, so it is found in this directory. Primary |
among these programs is the {\tt zip\_sim} program which will |
simulate the ZipCPU within the S6--Soc. Specifically, it |
simulate the Zip~CPU within the S6~SoC. Specifically, it |
simulates everything at or below the {\tt busmaster.v} level. |
|
Some, although not all, of the peripherals have been simulated |
134,7 → 178,7
Quad--SPI flash, the UART, and the LED's. |
|
\end{itemize} |
\item[{\tt trunk/doc}] All of the documentation for the S6SoC project may be |
\item[{\tt trunk/doc}] All of the documentation for the S6~SoC project may be |
found in this documentation directory. Specifically, I would commend |
your attention to anything with a {\tt .pdf} extension, as these |
are the completed documents. Among these you should find a copy of the |
147,9 → 191,11
kept that were used in building both this document as well as |
the GPL copyright. |
\end{itemize} |
\item[{\tt trunk/rtl}] Verilog files |
\item[{\tt trunk/rtl}] Verilog files. The two top--level files are |
{\tt toplevel.v} for the primary top level module, and |
{\tt alttop.v} for the alternate load. |
\begin{itemize} |
\item[{\tt trunk/rtl/cpu}] Verilog files containing the ZipCPU |
\item[{\tt trunk/rtl/cpu}] Verilog files containing the Zip~CPU |
core and peripherals. The toplevel file here is the |
{\tt zipbones.v} file, although some of the peripherals, such |
as the {\tt ziptimer.v} are referenced independently. |
158,7 → 204,7
for software subdirectories beneath it. |
\begin{itemize} |
\item[{\tt trunk/sw/dev}] This directory holds a variety of |
simple programs for the ZipCPU, such as {\tt helloworld}, |
simple programs for the Zip~CPU, such as {\tt helloworld}, |
{\tt doorbell} and {\tt doorbell2}, as well as software drivers |
for various peripherals, such as the real--time clock simulator, |
and the keypad and display device drivers. |
176,33 → 222,34
\end{itemize} |
\end{itemize} |
|
\section{ZipCPU Tool Chain} |
To build programs for the ZipCPU, you will need the ZipCPU toolchain. You |
can find this as part of the ZipCPU project, available at OpenCores. Building |
the ZipCPU project should result in a set of binaries in the |
\hbox{\tt trunk/sw/install/cross-tools/bin} directory. Make this directory |
a part of your path, and you should be able to build the CMod S6 ZipCPU |
software. Specifically, you will need to use {\tt zip-gcc}, {\tt zip-as} |
{\tt zip-ld}, and {\tt zip-cpp}. Other tools, such as {\tt zip-objdump} and |
{\tt zip-readelf}, may also prove to be very useful when trying to figure out |
what is going on within the SoC. |
\section{Zip CPU Tool Chain} |
To build programs for the Zip~CPU, you will need the Zip~CPU toolchain. You |
can find this as part of the Zip~CPU project, available at OpenCores. Building |
the Zip~CPU project should result in a set of binaries in the |
\hbox{\tt zipcpu/trunk/sw/install/cross-tools/bin} directory. Make this |
directory a part of your path, and you should be able to build the CMod S6 |
Zip~CPU software. Specifically, you will need to use {\tt zip-gcc}, |
{\tt zip-as}, {\tt zip-ld}, and {\tt zip-cpp}. Other tools, such as |
{\tt zip-objdump} and {\tt zip-readelf}, may also prove to be very useful when |
trying to figure out what is going on within the SoC. |
|
\section{Bench Test Software} |
|
Bench testing software currently consists of the {\tt zip\_sim} program found |
within {\tt trunk/bench/cpp}. This program requires Verilator to run, and |
simulates in a cycle accurate fashion, the entire S6SoC from {\tt busmaster.v} |
simulates in a cycle accurate fashion, the entire S6~SoC from {\tt busmaster.v} |
on down. Further, the external Quad--SPI flash memory, UART, and LED's are |
also simulated, although the 2--line display, audio, and keypad are not. |
|
\section{Host Software} |
These include: |
Several software programs have been built to support the S6~SoC from a nearby |
host. These programs include: |
\begin{itemize} |
\item {\tt dumpuart}: My current approach to debugging involves |
dumping the state of the registers and memory to the |
UART upon reboot. The dumpuart command found here is |
designed to make certain that the UART is first set |
up correctly at 9600~Baud, and that second everything |
up correctly at 9600~Baud, and second that everything |
read from the UART is directly sent to both a file and |
to the screen. In this fashion, it is similar to the |
UNIX {\tt tee} program, save for its serial port |
211,23 → 258,44
a device that came factory installed, the |
{\tt readflash} program reads the original installed |
configuration from the flash and dumps it to a file. |
\item {\tt wbregs} |
\item {\tt zipload}: This is the primary program you will need |
to get your software loaded on the CMod. It takes three |
arguments. The first is the name of the primary |
Xilinx configuration file, the second is the name |
of the alternate Xilinx configuration file, and the |
third is the name of the ZipCPU program you wish to |
write to Flash memory. |
|
Each of these arguments is optional. For example, if |
only one configuration file is given, the loader will |
load the primary configuration. If only one ZipCPU |
program is given, the program will be loaded into |
the program memory area and the configuration file areas |
This program is only useful when the alternate configuration is loaded. |
|
\item {\tt wbregs}: This program offers a capability very similar to the |
PEEK and POKE capability Apple user's may remember from before the |
days of Macintosh. {\tt wbregs <address>} will read from the |
Wishbone bus the value at the given address. Likewise |
{\tt wbregs <address> <value>} will write the given value into the |
given address. While both address and value have the semantics of |
numbers acceptable to {\tt strtoul()}, the address can also be a named |
address. Supported names can be found in {\tt regdefs.cpp}, and their |
register mapping in {\tt regdefs.h}. |
|
As examples, {\tt wbregs version}, will return the build date, or |
version of the RTL. {\tt wbregs spio} reads the special purpose |
I/O register, and {\tt wbregs gpio 0xffffffff} will set all output |
GPIO ports high while {\tt wbregs gpio 0xffff0000} will set all |
output GPIO ports to ground. |
|
This program is only useful when the alternate configuration is loaded. |
|
\item {\tt zipload}: This is the primary program you will need to get your |
software loaded on the CMod. It takes three arguments. The first is |
the name of the primary Xilinx configuration file, the second is the |
name of an alternate Xilinx configuration file, and the third is the |
name of the Zip~CPU program you wish to write to Flash memory. |
|
Each of these arguments is optional. For example, if only one |
configuration file is given, the loader will load the primary |
configuration. If only one Zip~CPU program is given, the program will |
be loaded into the program memory area and the configuration file areas |
will be left untouched. |
|
This program is only useful when the alternate configuration is loaded. |
\end{itemize} |
\section{ZipCPU Programs} |
\section{Zip CPU Programs} |
The following are a list of simple, independent, single-task example programs |
that will run on the S6~SoC: |
\begin{itemize} |
\item {\tt helloworld}: The first program any programmer should build, |
``Hello, world!'' This program sends the string, ``Hello, world!'' |
249,35 → 317,38
does not include any menus to configure the device or set time, since |
it doesn't include any keypad functionality. |
\item {\tt kptest}: A test of whether or not they keypad driver works. When |
run, anytime a key is pressed, the key's value (in hex) will be |
sent to the UART. Further, pressing an `F' on the keypad will also |
send a newline over the UART, in case you wish to keep your lines from |
getting too long. |
run, anytime a key is pressed, the key's associated printable character |
will be sent to the UART. Further, pressing an `F' on the keypad will |
also send a newline over the UART, in case you wish to keep your lines |
from getting too long. |
\end{itemize} |
\section{ZipOS} |
This operating system is pre--emptive and multitasking, although with many |
limitations. Those familiar with the internals of the Linux kernel may laugh |
that I call this an Operating System at all: it has no memory management unit, |
no paging, no virtual memory, no file I/O access, no network stack, no ability |
to dynamically add or remove tasks, indeed it hardly has any of the things |
most often associated with an Operating System. It does, however, handle |
interrupts, support multiple pre--emptive tasks in a multitasking, timesharing |
fashion, and it supports some very basic and rudimentary system calls. In a |
similar fashion, it does contain just about all of the functionality necessary |
for a multi--tasking microcontroller built around a do--forever loop. For its |
size, I consider it an impressive achievement. You are welcome to disagree |
with me, however. |
The ZipOS is a brand new operating system, specifically designed to run on the |
ZipCPU. It is both pre--emptive and multitasking, although with many |
limitations. Those familiar with the internals of other operating systems, such |
as Linux, may laugh that I call this an Operating System at all: it has no |
memory management unit, no paging, no virtual memory, no file I/O access, no |
network stack, no ability to dynamically add or remove tasks, indeed it hardly |
has any of the things most often associated with an Operating System. It does, |
however, handle interrupts, support multiple pre--emptive tasks in a |
multitasking, timesharing fashion, and it supports some very basic and |
rudimentary system calls. In a similar fashion, it does contain just about all |
of the functionality necessary for a multi--tasking microcontroller built |
around a do--forever loop. For its size, I consider it an impressive |
achievement. You are welcome to disagree with me, however. |
|
This version of the ZipOS starts in the resetdump.s code, so that upon |
This version of the ZipOS starts in the {\tt resetdump.s} code, so that upon |
any startup the ZipOS will dump register contents, the BusError register, and |
any scope contents to the UART. This can take some time, so you may wish to |
configure what you really wish to send--if anything. If desired, this will |
also dump the entire memory as well. All of this is quite useful in case the |
ZipCPU encounters a bus error or other sort of error that causes it to hang, |
stall, or reboot, as these registers are very carefully not touched prior to |
being sent to the UART output port. |
configure what you really wish to send--if anything. If desired, |
{\tt resetdump} can also be configured to also dump the entire memory as well |
while only using 9~memory locations. All of this is quite useful in case the |
Zip~CPU encounters a bus error or other sort of error that causes it to hang, |
stall, or reboot, as the CPU registers are very carefully not touched prior to |
being sent to the UART output port. This extends to all registers save the |
supervisor PC and CC registers, which would've been reset by a reboot anyway. |
|
{\tt resetdump.s} also calls a rudimentary bootloader, to load the parts of |
{\tt resetdump.s} then calls a rudimentary bootloader, to load the parts of |
the ZipOS that need to run faster into Block RAM. The choice of what parts |
to load into Block RAM is made on a file by file basis, and found within |
the linker script, {\tt cmodram.ld}. |
289,76 → 360,277
|
The user tasks are found (mostly) within {\tt doorbell.c}, also found in the |
ZipOS directory. This file contains two kernel entry points, {\tt kntasks()}, |
which returns the number of tasks the kernel needs to know about, and |
which returns the number of user tasks the kernel needs to know about, and |
{\tt kinit()}, which builds each of the tasks and connects their file |
descriptors to the various devices they will be referencing. |
\subsection{Traps} |
The ZipOS supports a variety of traps, listed here: |
\subsection{System Calls} |
The ZipOS supports a variety of system calls, listed here: |
\begin{itemize} |
\item WAIT: Halts the execution of a process until an event takes place, or |
a timeout has been reached. The events that can take place are a |
\item {\tt int wait(unsigned event\_mask, int timeout)} |
|
Halts the execution of a process until an event matching the |
{\tt event\_mask} takes place, or a {\tt timeout} (in milliseconds) |
has been reached. The events that can take place are a |
bitmask of the various interrupts the CPU supports, together with a |
bitmask of the values found in {\tt swint.h}. |
bitmask of the software interrupt values found in {\tt swint.h}. |
|
The timeout value can either be zero, to return immediately with the |
list of events that have taken place, negative, to wait indefinitely, |
or a positive number of milliseconds in order to wait at least that |
time for the event of interest to take place. |
The {\tt timeout} value can either be zero, to return immediately with |
the list of events that have taken place, negative, to wait |
indefinitely, or a positive number of milliseconds in order to wait at |
least that time for the event of interest to take place. |
|
This also allows a process to sleep for any number of milliseconds. |
Waiting on a zero event mask allows a process to sleep for any number |
of requested milliseconds. |
|
When wait returns, any events returned by the wait have been cleared. |
|
The other thing to be aware of is that events may accumulate before the |
wait system call. They will only be returned and cleared, though, if |
the wait call indicates an interest in those events. |
\item CLEAR: This system call works closely with the wait system call. |
Indeed, it is very similar to a wait system call with a zero timeout. |
It clears any of the requested events which may be pending. If given |
a timeout (in milliseconds), it will start a timer and generate a |
{\tt SWINT\_TIMEOUT} event to be sent to this process when the timer |
completes. |
\item POST: Certain devices, such as the real--time clock and the doorbell |
wait system call. Nothing within the wait system call clears prior |
events. These prior events be returned and cleared, though, if |
the wait call indicates an interest in those events. |
|
Upon return, the a bitmask of events that have taken place will be |
returned to the process. |
|
\item {\tt int clear(unsigned event\_mask, int timeout)} |
|
This system call works closely with the wait system call. Indeed, |
when the timeout given is zero, the two function nearly identically. |
It clears any of the requested events which may be pending, and returns |
a bit mask of the events that were pending and cleared. |
|
However, if the timeout is given (and is positive), then {\tt clear()} |
starts a timer. Once the timer has completed, a timeout event, |
{\tt SWINT\_TIMEOUT}, will be generated and made available to the task |
to wait upon it. |
|
In a similar fashion, if the timeout is negative, then any pending |
timeout is cleared. |
|
\item {\tt void post(unsigned event\_mask)} |
|
Certain devices, such as the real--time clock and the doorbell |
reader, need the ability of being able to post events to any listener |
within the O/S. The POST system call allows them to POST events in |
this manner. |
\item YIELD: This is simply a way of being nice to other processes. This system |
|
Were the ZipOS to be closer to a secure O/S, it might restrict what |
events each process could post. Right now, however, any process can |
post any event--whether it be a hardware or a software generated event. |
|
\item {\tt void yield(void) } |
|
This is simply a way of being nice to other processes. This system |
call takes no arguments and simply asks the scheduler to schedule the |
next process. It does not take this process off of the ready to run |
list, so the next process may be this one. However, since the scheduler |
is a round--robin scheduler, it will only return to this process if |
nothing else is available to run. |
\item READ: This is roughly the same system call as the POSIX read() system |
call. It reads some number of memory addresses (words, not octets), |
to the given file descriptor. If the memory requested is unavailable, |
is a round--robin scheduler, it will only return to this process once |
it has gone through all other available processes checking whether or |
not they are available to be run. |
|
\item {\tt int read(int fid, void *buf, int len)} |
|
This is roughly the same system call as the POSIX read() system |
call. It reads some number of words (not octets) from the file |
descriptor (device) specified by {\tt fid} into the memory address |
range starting at {\tt buf} and {\tt len} words long. If the memory |
requested is unavailable, |
the read will wait until it is available, possibly indefinitely. |
\item WRITE: This is roughly the same system call as the POSIX write() system |
|
Upon return, the {\tt read()} function call returns the number of |
words actually read, or a negative value on error. |
|
As a future feature, a {\tt read()} system call should be able to be |
interrupted by a timeout. This feature has not (yet) been implemented, |
but will likely be implemented via a combination of the {\tt clear()} |
system calls ability to set timeouts together with the {\tt read()} |
functions ability to wait for available data. |
|
\item {\tt int write(int fid, void *buf, int len)} |
|
This is roughly the same system call as the POSIX {\tt write()} system |
call. It writes some number of memory addresses (words, not octets), |
to the given file descriptor. If nothing is reading from the device, |
the write stall the task forever, otherwise it will only stall the task |
until the data is either written to the receiving task, or copied into |
a memory buffer. |
\item TIME: Returns the number of seconds since startup. Eventually, this will |
to the given file descriptor. If there is no reader task or device |
associated with the file descriptor, then the {\tt write()} system |
call will block forever once the internal pipe fills up. Otherwise, |
if something is reading from the file descriptor's pipe, the writing |
task will only stall until the data is either written to the receiving |
task, or copied into a memory buffer. |
|
Upon return, the {\tt write()} system call returns the number of words |
actually written to the system pipe (not necessarily the number that |
have been read), or a negative value on error. |
|
\item {\tt unsigned time(void) } |
|
Returns the number of seconds since startup. Eventually, this will |
return the number of seconds since January 1, 1970, and be identical |
to the UNIX system time() command, but that may not happen on this |
project. |
|
% \item SEMGET |
% \item SEMPUT |
\item MALLOC: Allocates memory from the system/kernel heap. This is a very |
low overhead memory allocator that, while it does allocate memory, |
cannot free it later. It is nearly 100\% efficient since only |
one memory address, the top of the heap, is used to determine what |
memory has been allocated. |
\item FREE: Not currently implemented. |
|
\item {\tt void *malloc(void)} |
|
Allocates memory from the system/kernel heap. This is a very low |
overhead memory allocator that, while it does allocate memory, cannot |
free it later. It is nearly 100\% efficient since only one memory |
address, the top of the heap, is used to determine what memory has |
been allocated. |
|
\item {\tt void free(void *buf)} |
|
This function is a do--nothing stub. |
|
\end{itemize} |
\subsection{Scheduler} |
The ZipCPU currently supports only a round--robin scheduler. Tasks are executed |
The ZipOS currently supports only a round--robin scheduler. Tasks are executed |
in the order they were created, as long as they are available to be executed. |
If no tasks are available to be run, the Scheduler will run the idle task which |
puts the CPU to sleep while waiting for an interrupt. |
|
\chapter{Operation} |
The {\tt doorbell} program has been built to illustrate the operation of both |
the Zip~CPU, the ZipOS, as well as showing off how all of the various |
peripherals work. It was envisioned after my family and I experienced an |
unexpected visitor during the wee hours of the morning. The {\tt doorbell} |
program is designed to couple the doorbell and the exterior lights to a |
single button. Hence, when the doorbell to the house is pressed, the exterior |
light is turned on for a half an hour. This, then, would make it difficult |
for someone to see inside during this time. |
|
This chapter will present an example of how the {\tt doorbell} program works. |
|
To run the {\tt doorbell} program, you will first need to build the various |
RTL and software support programs just to get the {\tt doorbell} program on |
the device: |
\begin{enumerate} |
\item First build the primary and alternate .bit files by building |
with {\tt toplevel.v} and then {\tt alttop.v} as your top--level |
RTL files. I like to place my Xilinx work directoy into |
{\tt trunk/xilinx}, and if you do the same the load scripts that |
are referenced next will work. |
|
Before going on, double check that both configuration .bit files were |
created, that they each fit within the device (there would be errors |
if they did not), and that they met their respective timing |
requirements. |
|
\item Then, load the alternate bit file into the S6~SoC. You will need |
the Digilent tools installed in order to do this. Having done so, |
you may run {\tt make axload} from the {\tt trunk/} directory. |
If you didn't run the Xilinx ISE from within {\tt tunk/xilinx}, |
you may need to find your .bit files and adjust where they load |
from, but this should be fairly straight--forward from the instructions |
within the Makefile. |
\item Build the software found in the host directory. This sotware depends |
upon Digilent's ADEPT toolsuite, so you will need to adjust the |
Makefile so that it references the toolsuite. |
|
{\em Note:} Currently, the host software is serial--number locked to |
my own CMod--S6. Until I fix this and make it more user friendly, |
you'll want to switch your software to reference your own CMod. |
To do this, look for the {\tt "SN:\ldots"} lines within the `*.cpp' |
files. Currently, there is one such line within wbregs, another |
within readflash, and the last within zipload. To find our your own |
device's serial number, type {\tt djtgcfg enum}. It should find one |
(or more) CMod devices connected to your system, and list each of |
their serial numbers. |
|
Once you've done this, you should have a working set of host support |
programs: readflash, wbregs, and zipload. |
|
\item Using {\tt wbregs}, you may now test your configuration. {\tt wbregs} |
works like the peek and poke programs from a generation ago. |
{\tt wbregs <address>} will return the value of the memory (or |
peripheral) found at the {\tt <address>}. Some addresses have names, |
such as {\tt UART}, {\tt SPIO}, {\tt GPIO}, {\tt PIC}, and so forth. |
These names are found in {\tt trunk/sw/host/regdefs.cpp}, and their |
mappings in {\tt trunk/sw/host/regdefs.h}. |
|
As examples, if you type {\tt wbregs version} you should be able |
to read the version (a.k.a. build date) from the currently installed |
.bit file. Likewise if you type {\tt wbregs uart 65}, you should see |
an `A' (i.e. a 65) sent from the S6~SoC over the serial port. |
{\tt wbregs uart} by itself will read a single character from the |
serial port and so on. |
|
You should be able to test all of your peripherals by hand using |
{\tt wbregs}: GPIO, Flash, UART, keypad, buttons, LEDs, Interrupt |
controller, timer, etc.\footnote{The display and audio devices may be |
more difficult since these require multiple interactions over the |
course of a short period of time to work.} This should give you some |
confidence in how these peripherals work, should you need it. You |
may also use this time to verify that your wiring is properly set up. |
|
\item If you wish to make certain you keep track of the original Flash bitfile |
that came with your device, you may read it out using {\tt readflash}. |
This will dump the contents of you flash onto {\tt qspiflash.bin}. |
You may then wish to change the name of this file, lest you overwrite |
it by running {\tt readflash} again later. |
|
\item At this point, it's time to build the programs for the Zip~CPU. To do |
this, you will first need to download the Zip~CPU project. When |
building that project, it will create a directory of programs |
(including its compiler) in |
{\tt zipcpu/trunk/sw/install/cross-tools/bin}. |
Include this directory into your path. |
|
\item Change into {\tt trunk/sw/dev} to build some device testing files. |
{\tt make} by itself should build some of these. |
|
You should now be ready to run some basic tests on the S6~SoC. |
|
\item Let's test the UART first: back out to the main directory {\tt trunk/}, |
and run\break |
{\tt sw/host/zipload sw/dev/helloworld} and then {\tt make xload}. |
Now, examine your UART port. (You do have the PModUSBUART installed |
and connected, right?) You should see ``Hello, world!'' printed |
over and over again once each second. |
|
\item You may try other test files in a similar manner, such as |
{\tt trunk/sw/dev/doorbell} and\break |
{\tt trunk/sw/dev/doorbell2}. The first of these will just play the |
doorbell over and over again, whereas the second one will wait for a |
button press before playing the doorbell sound. |
|
\item Now let's go and build the ZipOS together with it's user files. To do |
this, enter into the {\tt trunk/sw/zipos} directory and type |
{\tt make}. If all goes well, you should now have a program named |
{\tt trunk/sw/zipos/doorbell} which you can load into your S6~SoC as |
well. |
|
\item A final load, and we'll be done. To do this, make {\tt axload} again, |
and this time {\tt sw/host/zipload xilinx/toplevel.bit sw/zipos/doorbell}. |
When you power on your device the next time, or after you |
{\tt make xload}, you'll find the ZipOS running on the Zip~CPU. |
|
\item To test the doorbell, press one of the buttons. You should hear a |
doorbell coming out of the PModAMP2 audio port. |
|
\item You should also be able to read the time on the LCD display. It will be |
the wrong time (the number of seconds since power on \ldots). To set |
the correct time, press `A' on the keypad and then type in the 6--digit |
time: HHMMSS. |
|
If you make a mistake, the `C' key can be used for a backspace. |
|
\item You can also set the time of ``dawn'' by pressing a `B' on the keypad |
and then typing in the time ``dawn'' should be at. The same is |
true for dusk, only you'll need to start that by pressing a `C' on the |
keypad. |
|
\item Now, when the doorbell rings, the LCD will show the time the doorbell |
was pressed. If the time is at night, the ourdoor light (oops, I |
mean LED\#3) will turn on for a half an hour (currently set to |
30~seconds, since I don't have the patience to wait a half hour while |
testing). |
\end{enumerate} |
|
Now that you've made it this far, you can go back and examine what was done |
along the way, and perhaps even modify it for your own personal application. |
|
\chapter{Registers} |
There are several address regions on the S6~SoC, as shown in |
Tbl.~\ref{tbl:memregions}. |
376,13 → 648,20
\end{center}\end{table} |
In general, the address regions that are made up of RAM or flash act like |
memory. The RAM can be read and written, and the flash acts like read only |
memory. |
memory.\footnote{The Flash can be written, but only by an external command |
while in the alternate configuration.} |
|
This isn't quite so true with the other address regions. Accessing the I/O |
region, while it may be read/write, may have side-effects. For example, reading |
from the debugging scope device's data port will read a word from the scope's |
buffer and advance the buffer pointer. |
This isn't quite true with the other address regions. Accessing the I/O |
region, while it will act like a memory, it may also have side-effects. For |
example, reading from the debugging scope device's data port will read a word |
from the scope's buffer and advance the buffer pointer. (More on that later.) |
|
Finally, to keep the address decoder simple, many of these addresses are |
multiply mapped. Hence you may find the I/O peripherals mapped throughout the |
{\tt 0x0100}--{\tt 0x01ff} address region. Other memory addresses are similarly |
overmapped. This overmapping was a resource minimization feature, to get the |
bus to fit within a minimum number of FPGA resources. |
|
\section{Peripheral I/O Control} |
Tbl.~\ref{tbl:ioregs} |
\begin{table}[htbp] |
395,32 → 674,58
SPIO &\scalebox{0.8}{\tt 0x0105} & 32 & R/W & Special Purpose I/O, Keypad, LED Controller \\\hline |
GPIO &\scalebox{0.8}{\tt 0x0106} & 32 & R/W & GPIO Controller \\\hline |
UART &\scalebox{0.8}{\tt 0x0107} & 32 & R/W & UART data\\\hline |
VERSION &\scalebox{0.8}{\tt 0x0108} & 32 & R & Build date\\\hline |
\end{reglist} |
\caption{I/O Peripheral Registers}\label{tbl:ioregs} |
\end{center}\end{table} |
shows the addresses of various I/O peripherals included as part of the SoC. |
We'll walk through each of these peripherals in turn, describing how they work. |
|
\subsection{Interrupt Controller} |
The interrupt controller is identical to the one found with the ZipSystem. |
The layout of the PIC bits is shown in Fig.~\ref{fig:picreg}. |
The programmable interrupt controller (PIC) is identical to the one found with |
the ZipSystem. The layout of the PIC bits is shown in Fig.~\ref{fig:picreg}. |
\begin{figure}\begin{center} |
\begin{bytefield}[endianness=big]{32} |
\bitheader{0-31} \\ |
\bitbox{1}{E} |
\bitbox{15}{Enabled} |
\bitbox{15}{Enabled Ints} |
\bitbox{1}{A} |
\bitbox{15}{ACTIVE} |
\bitbox{15}{Currently Active Ints} |
\\ |
\end{bytefield} |
\caption{Programmable Interrupt Control (PIC) Register}\label{fig:picreg} |
\end{center}\end{figure} |
This controller supports up to fifteen interrupts, however only twelve are |
defined within the SoC. If any interrupt line is active, the PIC controller |
will have that bit set among it's active set. Once set, the bit and hence the |
defined within the SoC. These are listed in Tbl.~\ref{tbl:hw-ints}. |
\begin{table}[htbp] |
\begin{center}\begin{tabular}{|p{0.9in}|p{0.75in}|p{3.75in}|}\hline |
\rowcolor[gray]{0.85} Name & Bit Mask & Description \\\hline\hline |
INT\_BUTTON & 0x001 & A Button has been pressed. \\\hline |
INT\_BUSERR & 0x002 & A Wishbone bus error has taken place\\\hline |
INT\_SCOPE & 0x004 & The Scope has completed its collection\\\hline |
INT\_RTC & 0x008 & An alarm or timer has taken place (assuming the RTC |
is installed, and includes both alarm or timer)\\\hline |
INT\_TIMA & 0x010 & Timer-A has reached zero\\\hline |
INT\_TIMB & 0x020 & Timer-B has reached zero\\\hline |
INT\_UARTRX & 0x040 & A character has been received via the UART\\\hline |
INT\_UARTTX & 0x080 & The transmit UART is idle, and ready for its next |
character.\\\hline |
INT\_KEYPAD & 0x100 & One of the keypad wires has been pulled low. \\\hline |
INT\_AUDIO & 0x200 & The audio device is ready for its next sample\\\hline |
INT\_GPIO & 0x400 & The GPIO input lines have changed values.\\\hline |
INT\_FLASH & 0x800 & The flash device has finished either its erase or |
write cycle, and is ready for its next command. (Alternate |
config only.)\\\hline |
\end{tabular} |
\caption{Hardware Interrupts}\label{tbl:hw-ints} |
\end{center}\end{table} |
If any interrupt line is active, the PIC controller |
will have that bit set among its active set. Once set, the bit and hence the |
interrupt can only be cleared by writing to the controller. Interrupts can |
also be enabled as well. The enabled bit mask controls which interrupt lines |
are permitted to interrupt the CPU. Hence, just because an interrupt is active |
doesn't mean it will interrupt the CPU--the enabled line must be set as well. |
doesn't mean it will interrupt the CPU--the corresponding bit in the enable |
mask must be set as well. |
Finally, then {\tt A} or {\tt ANY} bit will be high if any interrupts are both |
enabled and active, whereas the {\tt E} or global interrupt enable bit can be |
set to allow the PIC to interrupt the CPU or cleared to disable all interrupts. |
433,9 → 738,9
|
Enabling specific interrupts, via writes to the enable lines, are different. |
To enable a specific interrupt, enable all interrupts and |
set the wire high associated with the specific interrupt you wish to enable. |
Hence writing a {\tt 0x80010000} will enable interrupt line zero, while also |
enabling all previously enabled interrupts. |
set the mask bit associated with the specific interrupt you wish to enable. |
Hence writing a {\tt 0x80010000} will enable interrupt line zero |
({\tt INT\_BUTTON}), while also enabling all previously enabled interrupts. |
To disable a specific interrupt, disable all interrupts and write a one to the |
enable line of the interrupt you wish to disable. In this fashion, writing a |
{\tt 0x00010000} will disable all interrupts and leave interrupt line zero |
450,8 → 755,10
may also globally enable or disable interrupts. |
|
\subsection{Last Bus Error Address} |
The Bus Error peripheral simply records the address of the last bus error. |
This can be useful when debugging. While the peripheral may only be read, |
The Bus Error peripheral simply records the address of the last bus error, |
and sets an interrupt upon receiving a bus error. (The interrupt itself |
is kind of useless ...) The address can be useful when debugging. While the |
peripheral may only be read, |
setting it is really as easy as creating a bus error and trapping the result. |
Another use for this is upon any reboot, it is possible to read the address |
of the last bus error and perhaps learn something of what caused the CPU to |
458,29 → 765,40
restart. |
|
\subsection{ZipTimer} |
The S6 Soc contains two ZipTimers, available for the CPU to use. These are |
The S6~SoC contains two ZipTimers, available for the CPU to use. These are |
countdown timers. Writing any non--zero value to them will cause them to |
immediately start counting down from that value towards zero, and to interrupt |
the CPU when they reach zero. Writing a new value while the timer is running |
will cause that new value to automatically load into the CPU and start counting |
from there. Writing a zero to the timer disables the timer, and causes it to |
stop. |
the CPU upon the transition to zero. Writing a new value while the timer is |
running will cause that new value to automatically load into the timer and |
start counting from there. Writing a zero to the timer disables the timer, and |
causes it to stop. |
|
ZipTimer A can be set to auto reload. When set, the timer will automatically |
ZipTimer A can be set to auto reload by setting the top bit as well as the |
interval. When so set, the timer will automatically |
load it's last set value upon reaching zero and interrupting the CPU. This |
effectively turns it into an interrupt timer if desired. To set this feature, |
write to the timer the number of clock ticks before an interrupt, but also set |
the high order bit. In this fashion, writing a {\tt 0x80013880} will interrupt |
the high order bit. In this fashion, writing a {\tt 0x8001387f} will interrupt |
the CPU every millisecond, starting one millisecond after the write takes place |
(assuming an 80~MHz system clock). |
(assuming an 80~MHz system clock).\footnote{Note that, since the timer spends |
a cycle at zero, setting it for a 80,000 cycle period requires setting the |
timer value to one less than 80,000.} |
|
ZipTimer B has been wired for a different purpose. ZipTimer B does not support |
auto reload, nor will it interrupt the CPU. Instead, ZipTimer B has been wired |
as a watchdog timer. When this timer reaches zero, the CPU will be rebooted. |
One way to use this timer would be in conjunction with the ZipTimer A, and to |
write a number to it upon any entry to the interrupt service routine. If given |
enough time, this would cause the CPU to reboot if for any reason it locked up. |
as a watchdog timer. When this timer transitions to zero, the CPU will be |
rebooted. One way to use this timer would be in conjunction with the ZipTimer |
A, and to write a number to it upon any entry to the interrupt service routine. |
If given enough time, this would cause the CPU to reboot if for any reason it |
locked up. |
|
The ZipOS uses ZipTimer~A for task swapping. By setting the timer for |
1~ms, the ZipOS examines every task for a potential task swap every millisecond. |
Of course, if the various tasks are running from Flash at 52~clocks per |
instruction, this means that as few as 1,538~instructions may be executed |
between timer interrupts, but this can be tuned if necessary for better |
performance. |
|
\subsection{PWM Audio Controller} |
The bit fields of the PWM Audio controller are shown in Fig.~\ref{fig:pwmreg}. |
\begin{figure}\begin{center} |
498,17 → 816,21
\end{center}\end{figure} |
This controller has been designed for easy writing. To send a sample to the |
PWM audio controller, simply write the sample to the controller and clear the |
PWM audio interrupt. When the audio interrupts the CPU again, it is ready |
for the next sample. |
PWM audio interrupt---{\em in that order}. When the audio interrupts the CPU |
again, it is ready for the next sample. Do note, however, that the audio |
interrupt can only be cleared once a new sample has been written to it. |
Attempts to clear it prior to that will have no effect. (This is why the |
order matters.) |
|
The audio sample rate has been fixed at 8~kHz. While changing this rate is |
easy to do within {\tt busmaster.v}, the rate itself takes some work to keep |
up with, so I wouldn't recommend going much (any) faster. |
up with, so I wouldn't recommend going faster. |
|
The audio controller supports two additional functionalities, however. The |
first is that the {\tt E} bit will be set upon any read when or if the audio |
controller is ready for another sample. Equivalently, the audio interrupt |
will be asserted. |
controller is ready for another sample and the Audio interrupt has been |
asserted. By polling this bit, for example, the audio driver can be run without |
using the interrupt functionality. |
|
The second functionality has to do with the two auxiliary control bits present |
in the PModAMP2 audio device. These are the gain and shutdown bits. To set |
556,17 → 878,30
make certain that parts of these registers can be modified atomically. |
Specifically, to change an LED, write the new value as well as a `1' to the |
corresponding LED change enable bit. The same goes for the keypad column |
output, a `1' needs to be written to the change enable bit in order for a |
new value to be accepted. |
output, a `1' needs to be written to the corresponding change enable bit in |
order for a new value to be accepted. |
|
As examples, writing a {\tt 0x0ff} to the {\tt SPIO} register will turn all |
LED's on, {\tt 0x0f0} will turn all LED's off, and {\tt 0x011} and {\tt 0x010} |
will turn LED0 on and then off again respectively. |
|
The keypad is a little bit tricker. To wait for a keypad interrupt, one needs |
to set the column outputs to zero. To do this, write a {\tt 0x0f00} to the |
{\tt SPIO} register. When a user then presses a key, one of the row inputs |
will go low and an interrupt will be asserted. The key must then be debounced, |
and the ZipOS debounces keys for 5~ms. Once debounced, the key may be read. |
To do this, set half of the columns to zero, such as by writing a {\tt 0x0cf00} |
to the {\tt SPIO} register. If one of the row values is still zero, then |
one of the two columns tested corresponded with the key. This can then be |
repeated until the correct column has been determined, at which point the |
row can be read and the key known. |
|
The controller will generate a keypad interrupt whenever any row input is |
zero, and a button interrupt whenever any button value is a one. This also |
means that, once generated, the interrupt must be disabled until the key or |
button is released. |
zero, and a button interrupt whenever any button value is a one. This is a |
level triggered interrupt, not edge triggered. What that means is that, |
once generated, the interrupt will need to be disabled until the key or button |
is released---there will be no interrupt for the release, that part will need |
to be done in software. |
|
\subsection{General Purpose I/O} |
The General Purpose Input and Output (GPIO) control register, shown in |
583,32 → 918,38
the value of the 16--input GPIO pins, whereas the bottom 16--bits indicate |
the value being placed on the 16--output GPIO pins. To change a GPIO pin, |
write the new pin's value to this register, together with setting the |
corresponding pin in the upper 16--bits. For example, to set output pin 0, |
write a {\tt 0x010001} to the GPIO device. To clear output pin 0, write a |
{\tt 0x010000}. This makes it possible to adjust some output pins independent |
of the others. |
corresponding pin in the bit-mask represented by the upper 16--bits. For |
example, to set output pin 0, write a {\tt 0x010001} to the GPIO device. To |
clear output pin 0, write a {\tt 0x010000}. Likewise pin two may be set by |
writing a {\tt 0x020002}, and both pins may be set by writing {\tt 0x030003}, |
etc. This makes it possible to adjust some output pins independent of the |
others. |
|
The GPIO controller, like the keypad or SPIO controller, will also generate |
an interrupt. The GPIO interrupt is generated whenever a GPIO input line |
changes. The interrupt is not selective: if any line changes, a GPIO interrupt |
will be generated. There are no do not care lines. |
will be generated. There are no ``do not care'' lines (although the GPIO |
controller could be easily adjusted to make such ``do-not-care'' lines if |
necessary \ldots). |
|
Of the 16 GPIO inputs and the 16 GPIO outputs, two lines have been taken for |
I2C support. GPIO line zero, for both input and output, is an I2C data line, |
I2C support, and a third has been stolen to make the PMod's fit on the |
board. GPIO line zero, for both input and output, is an I2C data line, |
{\tt io\_sda}, and GPIO line one is an I2C clock line, {\tt io\_scl}. If the |
output of either of these |
lines is set to zero, the GPIO controller will drive the line. Otherwise, |
the line is pulled up with a weak resistor so that other devices may |
pull it low. If either line is low, when the output control bit is high, |
output of either of these lines is set to zero, the GPIO controller will pull |
the line low. Otherwise, the line is pulled up so that other devices may pull |
it low. If either line is low, when the output control bit is high, |
it is an indicator that another device is sending data across these wires. |
Likewise GPIO input line 15 has been fixed to ground in order to support |
placing the keypad next to the S6~SoC. |
|
\subsection{UART Data Register} |
Moving on to the UART \ldots |
although the UART module within the S6~SoC is highly configurable, as built |
Moving on to the UART \ldots although the UART module itself |
within the S6~SoC is highly configurable, as built |
the UART can only handle 9600~Baud, 8--data bits, no parity, and one stop bit. |
Changing this involves changing the constant {\tt uart\_setup} within |
{\tt busmaster.v}. Further, the UART has only a single byte data buffer, so |
reading from the port has a real--time requirement associated with it--the |
reading from the port has a real--time requirement associated with it: the |
data buffer must be emptied before the next value is read. |
Attempts to read from this port will either return an 8--bit data value from |
the port, or if no values are available it will return an {\tt 0x0100} |
616,16 → 957,19
waiting for the interrupt to be ready, second reading from the port itself, |
and then third immediately clearing the interrupt. (The interrupt cannot |
be cleared while data is waiting.) Writing to the UART port is done in a |
similar fashion. First, wait until the UART transmit interrupt is asserted, |
second write to the UART port, and then third clear the interrupt. As with |
the read interrupt, clearing the interrupt prior to writing to the port will |
have no effect. |
similar fashion. First, wait until the UART transmit interrupt is asserted |
(this will likely be most of the time), second write to the UART port, and |
then third clear the interrupt. As with the read interrupt, clearing the |
transmit interrupt prior to writing to the port will have no effect. Likewise, |
clearing the transmit interrupt after the byte has been written will have no |
affect either. |
|
\section{Debugging Scope} |
The debugging scope consists of two registers, a control register and a data |
register. It needs to be internally wired to 32--wires, internal to the S6 |
SoC, that will be of interest later. For further details on how to configure |
and use this scope, please see the {\tt WBSCOPE} project on OpenCores. |
register. It needs to be internally wired to 32--wires, internal to the |
S6~SoC, that will be of interest when debugging. For further details on how |
to configure and use this scope, please see the {\tt WBSCOPE} project on |
OpenCores. |
|
\section{Internal Configuration Access Port} |
The Internal Configuration Access Port (ICAP) provides access to the internal |
633,7 → 977,8
the CPU with the capability to command a different FPGA load. In particular, |
the code in Fig.~\ref{fig:reload} should reconfigure the FPGA from any given |
Quad SPI {\tt address}.\footnote{According to Xilinx's technical support, this |
will only work if the JTAG port is not busy.} |
will only work if the JTAG port is not busy--such as when the USB port is |
disconnected.} |
\begin{figure}\begin{center}\begin{tabbing} |
{\tt warmboot(uint32 address) \{} \\ |
\hbox to 0.25in{}\={\tt uint32\_t *icape6 = (volatile uint32\_t *)0x{\em <ICAPE port address>};}\\ |
651,15 → 996,17
plugged in to the USB JTAG port. It will only work if the CMod has been |
provided with an independent power supply, leaving the USB JTAG unplugged. |
|
For further details, please see either the {\tt WBICAPETWO} project on OpenCores |
as well as Xilinx's ``Spartan-6 FPGA Configuration User Guide''. |
For further details, please see either the {\tt WBICAPETWO} project on |
OpenCores as well as Xilinx's ``Spartan-6 FPGA Configuration User Guide''. |
|
\section{Real--Time Clock} |
|
The Real Time Clock will be included if there is enough area to support it. |
The four registers correspond to a clock, a timer, a stopwatch, and an alarm. |
If space is tight, the timer and stopwatch, or indeed the entire clock, may be |
removed from the design. For further details regarding how to set and use this |
clock, please see the {\tt RTCCLOCK} project on OpenCores. |
(There isn't currently \ldots) |
The four registers of this port correspond to a clock, a timer, a stopwatch, |
and an alarm. If space is tight, the timer and stopwatch, or indeed the entire |
clock, may be removed from the design. For further details regarding how to |
set and use this clock, please see the {\tt RTCCLOCK} project on OpenCores. |
|
There is currently not enough area on the chip to support the Real--Time Clock |
together with all of the other peripherals listed here. You can adjust whether |
667,15 → 1014,18
of {\tt busmaster.v}. For example, it may be possible to get the RTC back by |
disabling the ICAPE2 interface. |
|
In place of the RTC capability, the ZipOS offers a software based RTC capability |
to simulate the clock register of this port. |
|
\section{On-Chip Block RAM} |
|
The block RAM is the fastest memory available to the processor. It is also |
the {\em only} writeable memory available to the processor. Hence all |
non-constant program data {\em must} be placed into block RAM. The ZipCPU |
non-constant program data {\em must} be placed into block RAM. The Zip~CPU |
can also run instructions from the block RAM if extra speed is desired. When |
runnning from block RAM, the ZipCPU will nominally take 8~clocks per |
instruction, for an effective rate of 8~MIPS. Loads or stores to block RAM |
will take one instruction longer. |
runnning from block RAM, the Zip~CPU will nominally take 8~clocks per |
instruction, for an effective rate of 10~MIPS. Loads or stores to block RAM |
will take one clock longer. |
|
\section{Flash Memory} |
The flash memory has been arbitrarily sectioned into three sections, one for |
687,29 → 1037,35
\rowcolor[gray]{0.85} Start & End & & Purpose \\\hline\hline |
\scalebox{0.9}{\tt 0x400000} & \scalebox{0.9}{\tt 0x43ffff} & R & Primary configuration space\\\hline |
\scalebox{0.9}{\tt 0x440000} & \scalebox{0.9}{\tt 0x47ffff} & R & Alternate configuration space\\\hline |
\scalebox{0.9}{\tt 0x480000} & \scalebox{0.9}{\tt 0x7fffff} & R & ZipCPU program memory\\\hline |
\scalebox{0.9}{\tt 0x480000} & \scalebox{0.9}{\tt 0x7fffff} & R & Zip~CPU program memory\\\hline |
\end{tabular} |
\caption{Flash Address Regions}\label{tbl:flash-addresses} |
\end{center}\end{table} |
The host program {\tt zipload} can be used to load a ZipCPU program and |
The host program {\tt zipload} can be used to load a Zip~CPU program and |
configuration files into this address space. To use it, first load the |
alternate configuration into the FPGA. Then pass it, as arguments, the |
primary, and alternate if desired, configuration files followed by the ZipCPU |
program file. Then, when the primary configuration is loaded again, perhaps |
upon power up, the ZipCPU will automatically start running from it's |
primary, and alternate (if desired), configuration files followed by the |
Zip~CPU program file. Then, when the primary configuration is loaded again, |
perhaps upon power up, the Zip~CPU will automatically start running from it's |
{\tt RESET\_ADDRESS}, {\tt 0x480000}. |
|
When running from Flash memory, the ZipCPU will nominally take 52~clocks per |
When running from Flash memory, the Zip~CPU will nominally take 52~clocks per |
instruction, for an effective speed of about 1.5~MIPS. |
|
When using {\tt zipload}, the first bit file argument will load the first |
configuration space, the second bit file argument will load the second |
configuration space, and the third argument will load the Zip~CPU program |
into its space. |
|
\chapter{Clocks} |
|
The S6~SoC is designed to run off of one master clock. This clock is derived |
from the 8~MHz input clock on the board, by multiplying it up to 80~MHz. |
from the 8~MHz input clock on the board, by multiplying it up to 80~MHz. The |
code for doing this can be found in both {\tt toplevel.v} and {\tt alttop.v}. |
|
\chapter{IO Ports} |
\chapter{I/O Ports} |
|
See Table.~\ref{tbl:ioports}. |
Table.~\ref{tbl:ioports} |
\begin{table}[htbp] |
\begin{center} |
\begin{portlist} |
724,8 → 1080,10
o\_pwm\_gain & 1 & Output & Audio output 20~dB gain enable\\\hline |
i\_uart & 1 & Input & UART receive input\\\hline |
o\_uart & 1 & Output & UART transmit output\\\hline |
i\_uart\_cts & 1 & Input & \\\hline |
o\_uart\_rts & 1 & Output & \\\hline |
o\_uart\_cts & 1 & Output & H/W flow control response, true if the internal |
single-byte receive buffer is empty.\\\hline |
i\_uart\_rts & 1 & Input & H/W flow control, true if the PModUSBUART wishes |
to send a byte\\\hline |
i\_kp\_row & 4 & Output & Four wires to activate the four rows of the keypad\\\hline |
o\_kp\_col & 4 & Output & Return four wires, from the keypads columns \\\hline |
i\_gpio & 14 & Output & General purpose logic input lines\\\hline |
735,12 → 1093,45
\end{portlist} |
\caption{List of IO ports}\label{tbl:ioports} |
\end{center}\end{table} |
lists the various I/O ports associated with the S6~SoC. These ports are named |
in roughly the same manner they are used. The four UART pins, |
{\tt i\_uart}, {\tt o\_uart}, {\tt i\_uart\_rts} and {\tt o\_uart\_cts}, |
connect to the PModUSBUART. The three PWM pins, {\tt o\_pwm}, |
{\tt o\_pwm\_gain}, and {\tt o\_pwm\_shutdown\_n}, control the PModAMP2 audio |
device. The eight pins, {\tt i\_kp\_row[3:0]} and {\tt o\_kp\_col[3:0]}, |
control the PModKYPD keypad. The final PMod, PModCLS, is controlled via the |
SPI lines formed from {\tt o\_gpio[4:2]} and {\tt i\_gpio[2]}. This display |
could also be controlled via I2C, {\tt io\_sda} and {\tt io\_scl}, although that |
is not part of the current demonstration software. |
|
\begin{table} |
The assignment of these pins to external output I/O pins is shown in |
Fig.~\ref{fig:physicalio}. |
\begin{figure} |
\begin{center} |
\includegraphics[height=7in]{../gfx/pinout.eps} |
\caption{Physical Locations of Device I/O Ports}\label{tbl:physicalio} |
\end{center}\end{table} |
\caption{Physical Locations of Device I/O Ports}\label{fig:physicalio} |
\end{center}\end{figure} |
Although pin assignment to the actual S6~board has been rather arbitrary, there |
is a touch of method to the madness. In particular, the S6~SoC pin placement |
supports placing the PMods in the configuration shown in |
Fig.~\ref{fig:pmodplaces}. |
\begin{figure} |
\begin{center} |
\includegraphics[height=7in]{../gfx/pmodmap.eps} |
\caption{Suggested mapping of I/O ports to PMod Locations}\label{fig:pmodplaces} |
\end{center}\end{figure} |
From this figure you can see that I have tried to minimize the amount of |
movement necessary to install any particular PMods, while also making the |
greatest use of pins on board. What may not be obvious from this picture |
is that the PMod power and ground lines are all connected to power and ground |
rails separate from the CMod itself. |
|
As with any piece of open source firmware, these pin assignments are fairly |
arbitrary and easy to adjust by making changes to the {\tt cmod.ucf} and |
{\tt cmodtop.ucf} files. The main difference between those two files being |
the DEPP interface supported by alternate configuration, which uses |
{\tt cmod.ucf}. |
|
% Appendices |
% Index |
\end{document} |