Skip to content

Barry / rf-depot

Go to a project
Toggle navigation
Toggle navigation pinning
bc83a1ad by root
Options

initial commit

0 parents
Expand all
Inline Side-by-side
Showing 1000 changed files with 839 additions and 0 deletions

Too many changes to show.
Plain diff Email patch

To preserve performance only 1000 of 1000+ files are displayed.

1 #
2 # Commondefs for Project BB
3 #
4 # Makefiles which include this should first define BBDEPTH
5 # to be the relative path from their parent directory.
6
7 # Use $(MAKE) $(MAKEARGS) instead of $(MAKEF) so that make -n works
8 # This gets around the fact that $(MAKE) works and $(MAKEF) does not.
9 # MAKEARGS is based directly on $(MAKEF) in commondefs.
10
11 MAKEARGS = VCFLAGS="$(VCFLAGS)" VFFLAGS="$(VFFLAGS)" \
12 VPFLAGS="$(VPFLAGS)" VMKDEPFLAGS="$(VMKDEPFLAGS)"
13
14 # sum of all source files;
15
16 SOURCES = $(HFILES) $(ASFILES) $(CFILES) $(SHFILES)
17
18 # sum off all object files depending on SOURCES;
19
20 OBJECTS = $(ASFILES:.s=.o) $(CFILES:.c=.o)
21
22 # make sure 'default' does not hit these rules
23
24 defaultrule: default
25
26 # C compiler options and definitions;
27
28 GCDEFS =
29 LCFLAGS = $(LCDEFS) $(LCINCS) $(LCOPTS)
30 GCFLAGS = $(GCDEFS) $(GCINCS) $(GCOPTS)
31
32 # VCS definitions;
33 # VCS_HOME is the path to the vcs tool root;
34 # VCS_NAME is the name of the executable;
35 # VCS is the path to the executable;
36 # allow user to overwrite all of them;
37
38 VCS_HOME ?= /ecad/vcs
39 VCS_NAME ?= vcs
40 VCS_LIB ?= $(VCS_HOME)/intel_i686_linux_2.2/lib
41 VCS ?= $(VCS_HOME)/bin/$(VCS_NAME)
42
43 # sum up all the vcs options;
44
45 VCSOPTS = $(GVCSOPTS) $(LVCSOPTS) $(VVCSOPTS)
46 VCSINCL = $(VCS_HOME)/include
47
48 # VIRSIM definitions;
49
50 VIRSIMHOME = $(VCS_HOME)/virsimdir
51 VCD2VPD = $(VCS_HOME)/virsimdir/bin/vcd2vpd
52
53 # other tool definitions;
54
55 SHELL = /bin/sh
56 RM = /bin/rm
57
58 # log definitions;
59
60 LOG_RESULT = \
61 @echo -n "!!! $(*:T) of" `basename \`pwd\``": "; \
62 grep "number of errors" $*.out
63
64 LOG_ERROR = $(LOG_RESULT)
65
1 #
2 # Commonrules for Project BB
3 #
4 # Makefiles which include this should first define BBDEPTH
5 # to be the relative path from their parent directory.
6
7 # Inference rules
8
9 .SUFFIXES : .v .sym .tab .mem .rdp .Z .ss .edf .vsyn
10
11 .v.sym:
12 $(RMVCOM) < $*.v | $(ECSGEN)
13 echo "TEXT 0 0 Left 2 $(*:T)" >> $(*:T).asy
14 $(ASYIN) $(*:T).asy
15
16 .c.tab:
17 $(HOST_CC) $*.c $(CFLAGS) -o $* $(LDFLAGS)
18 $* > $*.tab
19
20 .tab.mem:
21 $(TAB2VMEM) -o $*.mem -s 100 $*.tab > /dev/null
22
23 .mem.out:
24 simv +mem=$*.mem > $*.out
25 $(LOG_RESULT);
26
27 .c.rdp:
28 $(HOST_CC) $*.c $(CFLAGS) -o $* $(LDFLAGS)
29 $* > $*.rdp
30
31 .Z.out:
32 uncompress -c $*.Z > $*
33
1 /BBdefs/1.5/Tue Sep 17 20:37:17 2002//
2 /BBrules/1.1/Wed Mar 27 22:48:02 2002//
3 D/doc////
4 D/ecad////
5 D/hw////
6 D/java////
7 D/lib////
8 D/sw////
9 D/verification////
1 /root/leakn64/depot/
1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2 <html>
3 <head>
4 <title>BB SYSTEM - Design Principles &amp; Assumption</title>
5 </head>
6 <body bgcolor="#ffffff">
7
8 <h1>
9 <center>BB System - Design Principles &amp; Assumption</center>
10 </h1>
11
12 <h2>I. Design Principles</h2>
13
14 <ol>
15
16 <li><a href="http://intwww.routefree.com/rf/doc/bbdepot/bbdepot_arch.html">BB Depot - Design Principles</a>
17 </li>
18
19 <li><a href="http://intwww.routefree.com/rf/doc/bbservers/bbserver_arch.html#Design%20Goals">BB Server -
20 Design Principles</a>
21 </li>
22
23 </ol>
24
25 <h2>II. Assumptions</h2>
26
27 <ol>
28
29 <li>Customer must be able to purchase a BB Player &amp; Content at the
30 same time. Packaging should be such that this is possible without opening
31 the entire box at the retailer.</li>
32
33 <li>No refunds are permitted for an eTicket Purchase, after the eTicket
34 has been downloaded. The customer must have a specific step where he
35 will confirm the eTicket Purchase, thereby redeeming the eTicket.</li>
36
37 <li>BB Cards will be initialized in the factory.</li>
38
39 <li>BB Depot will be able to detect if a BB Card is not initialized and
40 prompt the Retailer to go through with the BB Card Repair process.</li>
41
42 </ol>
43
44 </body>
45 </html>
No preview for this file type
1 /filelist.xml/1.1/Mon Apr 8 18:29:27 2002//
2 /image001.gif/1.1/Mon Apr 8 18:29:27 2002/-kb/
3 /image002.gif/1.1/Mon Apr 8 18:29:27 2002/-kb/
4 D
1 rf/doc/BB_Game_System_Architecture_Overview_files
1 <xml xmlns:o="urn:schemas-microsoft-com:office:office">
2 <o:MainFile HRef="../BB_Game_System_Architecture_Overview.htm"/>
3 <o:File HRef="image001.gif"/>
4 <o:File HRef="image002.gif"/>
5 <o:File HRef="filelist.xml"/>
6 </xml>
...\ No newline at end of file ...\ No newline at end of file
1 /filelist.xml/1.1/Mon Apr 8 17:47:01 2002//
2 /image001.gif/1.1/Mon Apr 8 17:47:01 2002/-kb/
3 /image002.gif/1.1/Mon Apr 8 17:47:01 2002/-kb/
4 /image003.gif/1.1/Mon Apr 8 17:47:01 2002/-kb/
5 D
1 rf/doc/BB_Game_System_SW_Architecture_Overview_files
1 <xml xmlns:o="urn:schemas-microsoft-com:office:office">
2 <o:MainFile HRef="../BB_Game_System_SW_Architecture_Overview.htm"/>
3 <o:File HRef="image001.gif"/>
4 <o:File HRef="image002.gif"/>
5 <o:File HRef="image003.gif"/>
6 <o:File HRef="filelist.xml"/>
7 </xml>
...\ No newline at end of file ...\ No newline at end of file
1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2 <html>
3 <head>
4
5 <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
6 <title>BB Player High-level characteristics</title>
7 </head>
8 <body>
9
10 <h1>BB Player High Level Information</h1>
11 This document is intended as a summary of the main characteristics/targets
12 for the BB SoC and system. For details refer to the <a href="http://therouter.routefree.com/bb/rf/doc/hw/index.html">
13 hardware documentation</a>
14 <a href="http://therouter.routefree.com/bb/rf/doc/hw/index.html">.<br>
15 </a>
16 <br>
17
18 <h3>BB SoC Area Estimate (NEC 0.25u process, UC2)</h3>
19 <br>
20
21 <table cellpadding="2" cellspacing="2" border="1" width="100%">
22 <tbody>
23 <tr>
24 <td valign="Top"><b>Item</b><br>
25 </td>
26 <td valign="Top"><b>Area (mm^2)</b><br>
27 </td>
28 </tr>
29 <tr>
30 <td valign="Top">BCP (Includes, SI, PI, AI, VI, RSP, RDP, USB, RI,
31 MI), without SRAMs (with SRAMS, without the PAD Ring it is 72.38 mm^2, so
32 this is a conservative number)<br>
33 </td>
34 <td valign="Top">40<br>
35 </td>
36 </tr>
37 <tr>
38 <td valign="Top">R4300 Core CPU, includes 8 kbyte dcache and 16 kbyte
39 icache<br>
40 </td>
41 <td valign="Top">20<br>
42 </td>
43 </tr>
44 <tr>
45 <td valign="Top">Internal single ported secure SRAM, 32 Kbyte, 64
46 bits x 4096 words<br>
47 </td>
48 <td valign="Top">4<br>
49 </td>
50 </tr>
51 <tr>
52 <td valign="Top">Internal SRAM, IMEM, DMEM, TMEM, dual ported, 4kbytes,
53 64 bits x 512 words x 3<br>
54 </td>
55 <td valign="Top">3<br>
56 </td>
57 </tr>
58 <tr>
59 <td valign="Top">Internal SRAM: there is another block of memory in
60 the layout, could be VI line or Memspan<br>
61 </td>
62 <td valign="Top">1<br>
63 </td>
64 </tr>
65 <tr>
66 <td valign="Top">Internal Flash (64 Kbyte)<br>
67 </td>
68 <td valign="Top">4<br>
69 </td>
70 </tr>
71 <tr>
72 <td valign="Top"><b>Sub-total</b><br>
73 </td>
74 <td valign="Top">72 (= 8.5 * 8.5)<br>
75 </td>
76 </tr>
77 <tr>
78 <td valign="Top">Pad ring, 0.5 mm on all sides<br>
79 </td>
80 <td valign="Top">9 * 9<br>
81 </td>
82 </tr>
83 <tr>
84 <td valign="Top"><b>Total</b><br>
85 </td>
86 <td valign="Top">81<br>
87 </td>
88 </tr>
89
90 </tbody>
91 </table>
92 <br>
93 <br>
94
95 <h3>BB SoC Power Estimate</h3>
96 Power estimates are derived from known (at least roughtly) RCP estimates
97 and scaling for voltage and frequency. Since power is dominated by switching,
98 it is linear in frequency and proportional to the square of the voltage.<br>
99 <br>
100 Original RCP: 62.5 MHz core, 250 MHz RDRAM, 0.35u process, 3.3 Volts. Power
101 consumption: 3 Watts<br>
102 BCP: 93.75 MHz core, 187.5 MHz DDR, 0.25u process, 2.5 Volts. Estimated
103 power consumption:&nbsp; 2.6 Watts<br>
104 R4300 CPU core: power consumption, from NEC estimates of 0.25u core: 1 Watt
105 at 100 MHz<br>
106 R4300 CPU core: 140.625, estimated, 1.4 Watts<br>
107 <br>
108 Total BB SoC (assuming we run CPU at 140.625 MHz): 4 Watts<br>
109 <br>
110 We can probably subtract something from these since it includes RDRAM, which
111 used a lot of power.<br>
112
113 <h3>BB System Power Estimate</h3>
114 Add DDR power consumption (Doug?)<br>
115 Others are minor.<br>
116
117 <h3>BB Player System COGS</h3>
118 <br>
119
120 <table cellpadding="2" cellspacing="2" border="1" width="100%">
121 <tbody>
122 <tr>
123 <td valign="Top"><b>Item/Description</b><b><br>
124 </b></td>
125 <td valign="Top"><b>Supplier(s)</b><b><br>
126 </b></td>
127 <td valign="Top"><b>Cost</b><br>
128 </td>
129 </tr>
130 <tr>
131 <td valign="Top">BB SoC, 0.25u, 100 mm squared, 208 pin PQFP (4 watts
132 possible?)<br>
133 </td>
134 <td valign="Top">NEC<br>
135 </td>
136 <td valign="Top">$6.00<br>
137 </td>
138 </tr>
139 <tr>
140 <td valign="Top">BB Memory module, includes 1x8MB Nand flash on board,
141 1 multi-color LED for status, 2 expansion slots for additional card (these
142 are smart-media like, but with mechanical changes so they are not directly
143 compatible with existing smart-media)<br>
144 </td>
145 <td valign="Top">For Nand flash, Toshiba, Samsung, etc<br>
146 </td>
147 <td valign="Top">$10.00<br>
148 </td>
149 </tr>
150 <tr>
151 <td valign="Top">16 MByte (128 mbit) x 32 DDR<br>
152 </td>
153 <td valign="Top"><br>
154 </td>
155 <td valign="Top">$5.00<br>
156 </td>
157 </tr>
158 <tr>
159 <td valign="Top">Integrated A/V DAC, as used on N64. <br>
160 </td>
161 <td valign="Top">Ricoh<br>
162 </td>
163 <td valign="Top">$1.60<br>
164 </td>
165 </tr>
166 <tr>
167 <td valign="Top">Audio Amplifier<br>
168 </td>
169 <td valign="Top"><br>
170 </td>
171 <td valign="Top">$0.60<br>
172 </td>
173 </tr>
174 <tr>
175 <td valign="Top">Clock generators/crystals. Current plan is to have
176 separate clocks for System and Video, since this allows a form of random number
177 generation on chip. All other internal clocks will be synthesized from the
178 system clock. <br>
179 </td>
180 <td valign="Top"><br>
181 </td>
182 <td valign="Top">$1.00<br>
183 </td>
184 </tr>
185 <tr>
186 <td valign="Top">Regulators/On-board switcher. Two voltages: 3.3,
187 2.5 volt for BB SoC. 5 V is required for USB (double check power requirements).<br>
188 </td>
189 <td valign="Top"><br>
190 </td>
191 <td valign="Top">$3.00<br>
192 </td>
193 </tr>
194 <tr>
195 <td valign="Top">Passive/Active components: caps, zeners for USB,
196 pull-ups, etc<br>
197 </td>
198 <td valign="Top"><br>
199 </td>
200 <td valign="Top"><br>
201 </td>
202 </tr>
203 <tr>
204 <td valign="Top">Plastic Case and Buttons<br>
205 </td>
206 <td valign="Top">Foxcon?<br>
207 </td>
208 <td valign="Top">$2.00<br>
209 </td>
210 </tr>
211 <tr>
212 <td valign="Top">PCB, 4 layer<br>
213 </td>
214 <td valign="Top">Foxcon?<br>
215 </td>
216 <td valign="Top">$2.00<br>
217 </td>
218 </tr>
219 <tr>
220 <td valign="Top">Power supply, 5V wall plug, 1-2A<br>
221 </td>
222 <td valign="Top"><br>
223 </td>
224 <td valign="Top">$2.00<br>
225 </td>
226 </tr>
227 <tr>
228 <td valign="Top">Basic Cable: 1 composite video, 2 audio, power and
229 ground (5 total), 10 ft long<br>
230 </td>
231 <td valign="Top"><br>
232 </td>
233 <td valign="Top">$1.00<br>
234 </td>
235 </tr>
236 <tr>
237 <td valign="Top">Transformation cost (assume ~2% of total parts cost)<br>
238 </td>
239 <td valign="Top"><br>
240 </td>
241 <td valign="Top">$0.80<br>
242 </td>
243 </tr>
244 <tr>
245 <td valign="Top">Total cost<br>
246 </td>
247 <td valign="Top"><br>
248 </td>
249 <td valign="Top">$34.00<br>
250 </td>
251 </tr>
252
253 </tbody>
254 </table>
255 <br>
256
257 </body>
258 </html>
1 rf/doc/BB_Servers/BBCenterERD_files
1 D/BBCenterERD_files////
2 D/bbserver_interfaces////
3 D/data_defs////
4 D/transaction////
1 /root/leakn64/depot/
1 rf/doc/BB_Servers/bbserver_interfaces
1 rf/doc/BB_Servers/data_defs
1 rf/doc/BB_Servers/transaction/BBDEPOT-ConentSync_files
1 D/BBDEPOT-ConentSync_files////
2 D/XS-ContentSync////
3 D/XS-DownloadContent////
4 D/XS-DownloadContent-BBCard////
5 D/XS-PublishContent////
6 D/XS-RegionalReleaseOfContent_files////
7 D/XS-RevokeContent////
8 D/XS-StartContentDistribution////
9 D/XS-SuspendContent////
10 D/overlayed////
1 rf/doc/BB_Servers/transaction
1 rf/doc/BB_Servers/transaction/XS-ContentSync
1 rf/doc/BB_Servers/transaction/XS-DownloadContent-BBCard
1 rf/doc/BB_Servers/transaction/XS-DownloadContent
1 rf/doc/BB_Servers/transaction/XS-PublishContent
1 rf/doc/BB_Servers/transaction/XS-RegionalReleaseOfContent_files
1 rf/doc/BB_Servers/transaction/XS-RevokeContent
1 rf/doc/BB_Servers/transaction/XS-StartContentDistribution
1 rf/doc/BB_Servers/transaction/XS-SuspendContent
1 rf/doc/BB_Servers/transaction/overlayed
1 /BB-System-Principles.html/1.3/Mon Mar 10 22:31:29 2003//
2 /BB_Game_System_Architecture_Overview.doc/1.4/Mon Apr 8 17:47:01 2002/-kb/
3 /BB_Game_System_Architecture_Overview.htm/1.1/Mon Apr 8 18:29:27 2002//
4 /BB_Game_System_SW_Architecture_Overview.doc/1.2/Tue Apr 9 02:58:02 2002/-kb/
5 /BB_Game_System_SW_Architecture_Overview.htm/1.2/Tue Apr 9 02:58:02 2002//
6 /BB_Player_High_Level_characteristics.html/1.2/Mon Jun 17 21:45:04 2002//
7 /NEC_Project_Requirements.html/1.1/Fri Jul 5 21:40:21 2002//
8 /bb_game_state.html/1.5/Sat Mar 15 00:45:12 2003//
9 /hwimpact.html/1.9/Mon Nov 18 06:41:21 2002//
10 /index.html/1.106/Mon Nov 15 01:44:55 2004//
11 /n64software.html/1.3/Mon Mar 17 19:18:45 2003//
12 D/BB_Game_System_Architecture_Overview_files////
13 D/BB_Game_System_SW_Architecture_Overview_files////
14 D/BB_Servers////
15 D/IP_Cores////
16 D/Security_Overview////
17 D/bb_depot////
18 D/bb_player_sw////
19 D/bb_player_system////
20 D/browser////
21 D/dv////
22 D/ffs////
23 D/game_dev////
24 D/hw////
25 D/manufacturing////
26 D/presentations////
27 D/schedule////
28 D/security////
1 /root/leakn64/depot/
1 /arc_usb1.html/1.1/Mon Aug 5 22:59:32 2002//
2 /index.html/1.1/Mon Aug 5 22:59:32 2002//
3 /usb_latency_issues.html/1.1/Mon Aug 5 22:59:32 2002//
4 D
1 /root/leakn64/depot/
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
2 <HTML>
3 <HEAD>
4 <TITLE></TITLE>
5 <META NAME="GENERATOR" CONTENT="StarOffice/5.1 (Linux)">
6 <META NAME="AUTHOR" CONTENT="bill saperstein">
7 <META NAME="CREATED" CONTENT="20020731;14470600">
8 <META NAME="CHANGEDBY" CONTENT="bill saperstein">
9 <META NAME="CHANGED" CONTENT="20020731;15213000">
10 <STYLE>
11 <!--
12 @page { size: 8.5in 10.96in; margin-left: 1.25in; margin-right: 1.25in; margin-top: 1in; margin-bottom: 1in }
13 -->
14 </STYLE>
15 </HEAD>
16 <BODY>
17 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><FONT FACE="courier, monospace">This
18 document attempts to describe the protocol flow for the ARC USB 1.1
19 core. Included in the document are the flow diagrams for each of the
20 usb transactions, control, bulk data_in, bulk data_out, iso data_in
21 and iso data_out. The interrupt transaction looks like the bulk
22 transaction except for the different PID.</FONT></P>
23 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
24 </P>
25 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><FONT FACE="courier, monospace">There
26 are several constraints on latency required by the ARC design. They
27 are listed below:</FONT></P>
28 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
29 </P>
30 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><FONT FACE="courier, monospace">1)The
31 most critical latency requirement for the core is the receipt of the
32 BDT descriptor (via a DMA read access from memory) in NO MORE than
33 580ns. If the core does not receive the BDT in this time frame, it
34 NAK's the bulk or control transaction or bit stuffs the iso
35 transaction. It then awaits for the next token and gets in an
36 infinite loop with the host. Without control of the BDT, the core is
37 unable to communicate with the software regarding the type/endpoint
38 of the transaction requested.</FONT></P>
39 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
40 </P>
41 <P ALIGN=JUSTIFY STYLE="margin-left: 0.5in; margin-bottom: 0in"><FONT FACE="courier, monospace">The
42 current bb_chip does not guarantee the 580ns latency for retrieval of
43 the BDT by the core. In order to solve this problem, it is proposed
44 that a copy of the BDT's be placed close to the ARC core so that a
45 memory access will not be necessary. We are only expecting to support
46 four(4) endpoints in the bb_chip. This requires 64 bytes of storage
47 for the local BDT's.</FONT></P>
48 <P ALIGN=JUSTIFY STYLE="margin-left: 0.5in; margin-bottom: 0in"><BR>
49 </P>
50 <P ALIGN=JUSTIFY STYLE="margin-left: 0.5in; margin-bottom: 0in"><FONT FACE="courier, monospace">The
51 local BDT's will be placed outside of the BVCI interface of the core,
52 between the BIU and the C/D bus.</FONT></P>
53 <P ALIGN=JUSTIFY STYLE="margin-left: 0.5in; margin-bottom: 0in"><FONT FACE="courier, monospace">When
54 the core accesses the BDT memory address, it will access this local
55 register file instead of starting a C/D DMA access. Similarly, from
56 the processor side, these registers will be memory mapped to the USB
57 region on the C/D bus.</FONT></P>
58 <P ALIGN=JUSTIFY STYLE="margin-left: 0.5in; margin-bottom: 0in"><BR>
59 </P>
60 <P ALIGN=JUSTIFY STYLE="margin-left: 0.5in; margin-bottom: 0in"><FONT FACE="courier, monospace">The
61 use of local BDT's will eliminate the latency issue encountered when
62 the core tries to retrieve the descriptors from memory.</FONT></P>
63 <P ALIGN=JUSTIFY STYLE="margin-left: 0.5in; margin-bottom: 0in"><BR>
64 </P>
65 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><FONT FACE="courier, monospace">2)Another
66 latency requirement is for DMA writes. The core uses a 16 byte fifo
67 divided into two 8 byte ping-pong fifos. All DMA writes from the core
68 are performed as 4 byte writes to memory. Thus, while one fifo is
69 being filled, the other must be able to be emptied. To fill the 8
70 byte fifo from usb requires 64bits X 80ns = 5usec. The current
71 latency of getting onto the C/D bus is 1 usec; so this constraint
72 should NOT be a problem for the bb_chip design.</FONT></P>
73 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
74 </P>
75 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><FONT FACE="courier, monospace">3)For
76 DMA reads from memory, the core needs to return data to the USB bus
77 within 580ns + 740ns = 1.3usec. Using the local BDT's to retrieve the
78 descriptor, the entire 1.3usec is the latency required to get the
79 data from memory. Again, since the latency of the C/D bus is (worst
80 case 1 usec.), this constraint should NOT be a problem for the
81 bb_chip design.</FONT></P>
82 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
83 </P>
84 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><FONT FACE="courier, monospace">The
85 following diagrams show the protocol flow for the different
86 transactions using the ARC core.</FONT></P>
87 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
88 </P>
89 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><IMG SRC="sv6106101.gif" NAME="Object1" ALIGN=LEFT WIDTH=831 HEIGHT=609 BORDER=0><BR CLEAR=LEFT><BR>
90 </P>
91 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><FONT FACE="arial, sans-serif">Control
92 Transfer</FONT></P>
93 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
94 </P>
95 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><IMG SRC="sv6106102.gif" NAME="Object2" ALIGN=LEFT WIDTH=847 HEIGHT=621 BORDER=0><BR CLEAR=LEFT><BR>
96 </P>
97 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><FONT FACE="arial, sans-serif">Bulk
98 Data_IN</FONT></P>
99 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
100 </P>
101 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><IMG SRC="sv6106103.gif" NAME="Object3" ALIGN=LEFT WIDTH=863 HEIGHT=632 BORDER=0><BR CLEAR=LEFT><BR>
102 </P>
103 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><FONT FACE="arial, sans-serif">Bulk
104 Data_Out</FONT></P>
105 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
106 </P>
107 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><IMG SRC="sv6106104.gif" NAME="Object4" ALIGN=LEFT WIDTH=879 HEIGHT=644 BORDER=0><BR CLEAR=LEFT><BR>
108 </P>
109 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><FONT FACE="arial, sans-serif">ISO
110 Data_IN</FONT></P>
111 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
112 </P>
113 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><IMG SRC="sv6106105.gif" NAME="Object5" ALIGN=LEFT WIDTH=895 HEIGHT=656 BORDER=0><BR CLEAR=LEFT><BR>
114 </P>
115 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
116 </P>
117 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><FONT FACE="arial, sans-serif">ISO
118 Data_Out</FONT></P>
119 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
120 </P>
121 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
122 </P>
123 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
124 </P>
125 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
126 </P>
127 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
128 </P>
129 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
130 </P>
131 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
132 </P>
133 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
134 </P>
135 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
136 </P>
137 <P ALIGN=JUSTIFY STYLE="margin-bottom: 0in"><BR>
138 </P>
139 </BODY>
140 </HTML>
...\ No newline at end of file ...\ No newline at end of file
1 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
2 <html>
3 <head>
4 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
5 <meta name="GENERATOR" content="Mozilla/4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) [Netscape]">
6 <title>BB Chip IP Cores</title>
7 </head>
8 <body bgcolor="#FFFFFF" lang="EN-US">
9
10 <h1>
11 BB Chip IP Cores Main Page</h1>
12
13 <h3>
14 USB Core </h3>
15 <a href="arc_usb1.html">ARC USB Core Flow</a>
16 <br><a href="usb_latency_issues.html"> Interrupt Latency with USB Cores</a>
17 <h3>
18 Video Encoder</h3>
19 <h3>
20 AES Core</h3>
21 <h3>
22 </body>
23 </html>
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
2 <HTML>
3 <HEAD>
4 <TITLE></TITLE>
5 <META NAME="GENERATOR" CONTENT="StarOffice/5.1 (Linux)">
6 <META NAME="CREATED" CONTENT="20020805;11531500">
7 <META NAME="CHANGEDBY" CONTENT="bill saperstein">
8 <META NAME="CHANGED" CONTENT="20020805;11582900">
9 </HEAD>
10 <BODY>
11 <P><BR><BR>
12 </P>
13 <P><FONT FACE="courier, monospace">I wanted to summarize the meeting
14 last Friday(8/2) where we discussed in greater details the
15 &quot;shortcomings&quot; of the InSilicon and ARC USB cores. In
16 addition, we discussed the &quot;environments&quot; in which the USB
17 would be utilized in the player. </FONT>
18 </P>
19 <P><FONT FACE="courier, monospace">First, Andy re-visited the
20 interrupt latency issue and with Doug's help, we calculated the
21 latency to enter and exit a standard interrupt handler. The
22 calculation showed that there is around 9.7usec overhead to get
23 into/out <BR>of the handler (operating at 62.5MHz). In addition, the
24 period between interrupts when transferring 64bytes over usb is
25 around 47 usec. </FONT>
26 </P>
27 <P><FONT FACE="courier, monospace">For the InSilicon solution, the
28 buffer is loaded during the interrupt routine. This takes around
29 2.5usec additional to load the buffer (causing a total of 12.2usec in
30 the handler). To solve this problem, would require additional <BR>64byte
31 buffers (additional endpoints) to allow the host driver to rotate
32 thru the endpoints and the firmware on the player could load several
33 buffers during one interrupt routine. The additional buffers&nbsp; is
34 basically a real estate <BR>issue. </FONT>
35 </P>
36 <P><FONT FACE="courier, monospace">For the ARC solution, the same
37 problem with interrupt latency occurs, although the 2.5usec additonal
38 latency is not present since the ARC core dma's the data into the
39 buffer w/o processor intervention. The solution of multiple
40 <BR>endpoints can also be used with the ARC core to solve the latency
41 problem. However, the ARC core does NOT require addition buffers
42 since the core dma's all the data into the latency buffer. </FONT>
43 </P>
44 <P><FONT FACE="courier, monospace">The previous discussion pertains
45 to the usb core in device mode. When the core is in host mode, there
46 appears to be NO way to overcome the interrupt latency issue. This is
47 mainly due to the fact that the processor always has to <BR>initiate
48 the token for each host transaction. There appears to be no way to
49 line up these tokens to let the core fire off several transactions in
50 a row. </FONT>
51 </P>
52 <P><FONT FACE="courier, monospace">Now, to see how these latency
53 issues affect the operation of the player during normal applications,
54 we can outline the normal operating environments for the player when
55 utilizing usb: </FONT>
56 </P>
57 <P><FONT FACE="courier, monospace"><U>Device Mode</U> (bulk transfers
58 only) <BR>&nbsp;&nbsp; connection to depot <BR>&nbsp;&nbsp;&nbsp;
59 connection to PC </FONT>
60 </P>
61 <P><FONT FACE="courier, monospace">&nbsp;&nbsp;&nbsp; Both of these
62 connections will be transferring large amounts of data. Bandwidth
63 over usb important. The processor will only be running the browser
64 during these device mode connections. This situation is similar to
65 the one described above for large transfers in device mode. In the
66 case of InSilicon, we will see a 20-25% utilization of the CPU to
67 perform such transfers from the depot. We wouldn't want to add more
68 64byte buffers to the core it possible. In the case of ARC, we would
69 use the additional endpoints to allow the depot to rotate through the
70 endpoints and reduce CPU involvement. </FONT>
71 </P>
72 <P><FONT FACE="courier, monospace">&nbsp;&nbsp;&nbsp; Since the CPU
73 is not being heavily utilized during these two device mode
74 connections, it appears OK to use either core without a detrimental
75 affect. </FONT>
76 </P>
77 <P><FONT FACE="courier, monospace"><U>Host Mode</U> (the player CPU
78 may be heavily utilized in host mode connection, ie. playing a game)
79 <BR>&nbsp;&nbsp;&nbsp; modem - ISO transfer <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
80 For ISO transfers, the latency issue to can be reduced greatly by
81 allowing the packet size to increase to 1KB </FONT>
82 </P>
83 <P><FONT FACE="courier, monospace">&nbsp;&nbsp;&nbsp; e-net - bulk
84 transfer <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Both cores
85 suffer from interrupt latency every 64 bytes of transfer </FONT>
86 </P>
87 <P><FONT FACE="courier, monospace">&nbsp;&nbsp;&nbsp; printer - bulk
88 transfer <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Both cores
89 suffer from interrupt latency every 64 bytes of transfer </FONT>
90 </P>
91 <P><FONT FACE="courier, monospace">&nbsp;&nbsp;&nbsp; camera, card
92 reader - bulk transfer <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
93 Both cores suffer from interrupt latency every 64 bytes of transfer </FONT>
94 </P>
95 <P><FONT FACE="courier, monospace">&nbsp;&nbsp;&nbsp; keyboard,
96 joystick - bulk transfer <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
97 Transfers are small and infrequent to not present a problem </FONT>
98 </P>
99 <P><FONT FACE="courier, monospace">There is one more item that should
100 be discussed regarding&nbsp; the USB cores. That being ease of
101 integration and verification. The InSilicon design is strickly a
102 slave device on BVCI. It should be very straightforward to
103 incorporate this core into the bb_chip. A good place to attach this
104 core would be to the MI peripheral bus (similar to a ROM). This core
105 requires minimum glue logic to possibly translate control signals
106 from one synchronous bus to another. </FONT>
107 </P>
108 <P><FONT FACE="courier, monospace">For the ARC core, it is required
109 to add the local descriptor block to avoid the 580nsec requirement to
110 read the BDT's. In addition, there will be a bus translation unit
111 requied between BVCI and C/D bus. This bus translation unit will need
112 to operate as both a master and slave. It will probably be somewhat
113 more complicated than a slave-only interface. </FONT>
114 </P>
115 <P><FONT FACE="courier, monospace">Finally, there is the issue of
116 verification. For the ARC core, it is required to translate the DLL
117 code into our I/OSim environment to test basic usb transactions in
118 the &quot;system&quot; environment. This effort is required to do
119 standalone testing of the BVCI/ C-D interface block. For the
120 InSilicon case, the complete test environment is in Verilog with
121 possibly some PLI code for the transaction <BR>generators. It appears
122 that the translation of&nbsp; the BVCI host/slave tasks to the uP bus
123 should be straightforward. <BR>&nbsp;</FONT></P>
124 </BODY>
125 </HTML>
...\ No newline at end of file ...\ No newline at end of file
1 /secmod1.gif/1.1/Wed Mar 27 22:27:09 2002/-kb/
2 /secmod2.gif/1.1/Wed Mar 27 22:27:09 2002/-kb/
3 /secmod3.gif/1.1/Wed Mar 27 22:27:09 2002/-kb/
4 /secmod4.gif/1.1/Wed Mar 27 22:27:09 2002/-kb/
5 /secmod5.gif/1.1/Wed Mar 27 22:27:09 2002/-kb/
6 /secmodel.html/1.1/Wed Mar 27 22:27:09 2002//
7 D
1 rf/doc/Security_Overview
1 /root/leakn64/depot/
1 D/remote_mgmt_files////
1 /root/leakn64/depot/
1 /Fig2.vsd/1.1/Fri Sep 20 23:34:07 2002/-kb/
2 /fig1.vsd/1.1/Thu Sep 19 18:37:03 2002/-kb/
3 /image001.gif/1.1/Fri Sep 20 23:34:07 2002/-kb/
4 /image002.gif/1.2/Fri Sep 20 23:34:07 2002/-kb/
5 /image003.gif/1.1/Fri Sep 20 23:34:07 2002/-kb/
6 D
1 rf/doc/bb_depot/remote_mgmt_files
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
This diff could not be displayed because it is too large.
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
This diff could not be displayed because it is too large.
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
This diff could not be displayed because it is too large.
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
This diff could not be displayed because it is too large.
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
This diff is collapsed. Click to expand it.
This diff is collapsed. Click to expand it.
No preview for this file type
No preview for this file type
This diff could not be displayed because it is too large.
This diff could not be displayed because it is too large.
This diff could not be displayed because it is too large.
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type
No preview for this file type