OpenCores
URL https://opencores.org/ocsvn/s6soc/s6soc/trunk

Subversion Repositories s6soc

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /
    from Rev 40 to Rev 41
    ↔ Reverse comparison
  •

Rev 40 → Rev 41

/s6soc/trunk/doc/spec.pdf Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream
/s6soc/trunk/doc/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
/s6soc/trunk/doc/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
/s6soc/trunk/doc/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
/s6soc/trunk/doc/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}

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.