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.

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