(57)【特許請求の範囲】
【請求項１】
送信デバイスと受信デバイスとの間でバスを介してデータを転送する方法において、
（１）  前記バス上でデータをドライブするために前記送信デバイスをターンオンするステップと、
（２）  前記受信デバイスが前記データを受信する前に、前記送信デバイスをターンオフするステップと、
（３）  前記受信デバイスにおいて、前記データを受信するステップと
を有することを特徴とする方法。
【請求項２】
送信デバイスと受信デバイスとの間でバスを介してデータを転送する方法において、
（１）  少なくとも第１のフェーズおよび第２のフェーズを含むクロックサイクルを有するクロックで、前記バスをクロックするステップと、
（２）  前記バス上でデータをドライブするために、前記送信デバイスをターンオンするステップと、
（３）  前記受信デバイスが前記データを受信する前に、前記送信デバイスをターンオフするステップと
を有することを特徴とする方法。
【請求項３】
前記（３）のステップは、
（３．１）  前記受信デバイスが前記データをラッチする前に、前記送信デバイスをターンオフするステップを含む
ことを特徴とする請求項２記載の方法。
【請求項４】
前記（２）のステップは、前記クロックサイクルの前記第１のフェーズへの遷移に応じて、前記送信デバイスをターンオンするステップを含み、
前記（３）のステップは、前記クロックサイクルの前記第２のフェーズへの遷移に応じて、前記送信デバイスをターンオフするステップを含む
ことを特徴とする請求項３記載の方法。
【請求項５】
前記（２）のステップは、前記送信デバイスに関連するドライバをイネーブルするステップを含み、
前記（３）のステップは、前記送信デバイスに関連する前記ドライバをディスエイブルするステップを含む
ことを特徴とする請求項３記載の方法。
【請求項６】
クロックサイクル間に、ナルピリオドが設けられない
ことを特徴とする請求項５記載の方法。
【請求項７】
異なる送信デバイスにより送信されるデータ間にナルピリオドが設けられない
ことを特徴とする請求項５記載の方法。
【請求項８】
バスキーパーが使用されない
ことを特徴とする請求項３記載の方法。
【請求項９】
前記クロックサイクルは、前記ドライバのイネーブル化から前記バス上での有効なデータのドライブまでの期間および前記データが前記バス上を進んで前記受信デバイスにより受信される期間の和よりも短くない期間を有する
ことを特徴とする請求項３記載の方法。
【請求項１０】
前記バスは、複数の送信デバイスのうちのいずれかによりドライブされ、前記データは、複数の受信デバイスのうちのいずれかにより受信され、前記クロックサイクルは、ドライバがイネーブル化から前記バス上での有効なデータのドライブまでの最大の可能性あるピリオドとデータが送信デバイスから進み前記バスを介して受信デバイスにより受信される最大の可能性のあるピリオドとの和よりも短くない期間を有する
ことを特徴とする請求項３記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、電子回路のためのデータバスに係り、特に、システムオンチップ（system-on-a-chip,ＳｏＣ）集積回路のためのデータバスに関する。
【０００２】
【従来の技術】
メモリ、マイクロプロセッサ、マイクロコントローラ、デジタルシグナルプロセッサ（ＤＳＰ）のような複数のデータ処理デバイス、および周辺デバイスにより共有される単一のデータパスを提供するためにバス（例えば、アドレスバスおよびデータバス）を使用することは、勿論よく知られてる。バスは、多くの場合、印刷基板上に形成され、複数のデバイス、例えば印刷基板上に取り付けられた集積回路を相互接続する。バスは、周辺デバイスがバスに結合されることを可能にするために、パーソナルコンピュータのバックプレーンのようなコネクタに突き出ることがある。
【０００３】
最近、集積回路製造者は、伝統的に、１つのＰＣＢ上に取り付けられた異なるチップ上に具現化されかつＰＣＢ上を走る１つまたは２つ以上のバスにより相互接続された、例えばメモリ、マイクロコントローラ、ＤＳＰおよびマイクロプロセッサのようなタイプの複数のデバイスコアを含む単一チップを作り始めた。そのようなチップは、一般に、システムオンチップ即ちＳｏＣと呼ばれる。
【０００４】
ＳｏＣ内のコアデバイスは、互いに通信しなければならない。したがって、ＳｏＣは、しばしば、チップ上の複数のコアデバイスを相互接続するデータパスを提供するために、バスを含む。しかし、ＳｏＣ上のバスは、チップ上の導体トレースを含み、印刷基板バスよりも遙かに短くかつ雑音に左右されない傾向にある。１つまたは２つ以上のバスを含む典型的なＳｏＣは、いくつかの周辺デバイスおよび／またはいくつかのメモリブロック（ＳＲＡＭ，ＤＲＡＭ，ＰＲＯＭおよびＲＯＭ）に接続するプロセッサまたはマルチプロセッサを含むＳｏＣであり得る。
【０００５】
フローティングノイズは、複数のドライバにより交互にドライブされ得るバスビットライン(bus bit line)のようなノードに一般に関連する問題であり、ノードアクティブにドライブするドライバがない場合に生じ得る。ノードがアクティブにドライブされない場合、ノードは、バスをドライブすることができるドライバの非導通のｎおよびｐトランジスタおよびバスに結合された受信デバイスのゲート入力のみを介して電源および接地に接続されている。受信機入力ゲート上の電圧は、受信機のｎおよびｐトランジスタを同時に導通させることになるクリティカルレベル、Ｖcritへドリフトする可能性がある。これは、電力を浪費する原因となりかつデバイスを破壊する可能性さえある受信デバイスを通る電源と接地との間の低インピーダンスパスを形成する。
【０００６】
ＣＭＯＳ技術において、フローティングノードの問題は、通常、３つの問題、即ち（１）設計の手抜かり、（２）デコーディングの単純化、および（３）バスターンアラウンド時間（例えば、ナルサイクル（null cycles)）のうちの１つまたは２つ以上のために存在する。設計の手抜かりは、ドライバ選択信号が、信号値の１つまたは２つ以上の組合せに対するデフォルトドライバを選択するようにデコードされない場合に起こる可能性がある。そのような手抜かりは、単純なミステイクである可能性があり、または以前に存在した設計が新しい用途のために修正され、新しい設計においてもはや必要とされないバスドライバが回路から取り除かれる場合に起こり得る。
【０００７】
フローティングノード状態は、バスドライバを選択する信号が意図的にデコードされない場合に起こり得る。これは、バスドライバを選択する多数の信号があり、デコードロジックが、１つまたは２つ以上のデフォルト選択をデコードしないように単純化された場合に起こり得る。
【０００８】
フローティングノード状態の別の原因は、バスコンテンションを防止するためにしばしば設計に含まれるバスターンアラウンド時間仕様である。具体的には、複数のドライバが単一のノード（例えば、バスビットライン）をドライブできる場合、２つのデバイスが同時にバスをドライブすることを防止するために、バスアクセスプロトコルに注意が払われなければならない。
【０００９】
１つのドライバは、次のドライバがターンオンする前に完全にターンオフされなければならない。これは、１つのドライバがバスを論理ローレベルにドライブするように試みており、別のドライバがそれを論理ハイレベルにドライブするように試みている場合、電源と接地との間に非常に低いインピーダンスパスが形成され、デバイスを破壊する可能性があるからである。バスコンテンションは、１つのバスドライバがターンオフし、別のバスドライバが同時にターンオンする時点において、起こる可能性がある。
【００１０】
具体的には、これは、ドライバをターンオフまたはターンオンするためにいくらかの有限の時間ピリオドを必要とする。異なるドライバをターンオンしかつターンオフする遅れの差およびドライバを選択する制御信号のスキューの差は、１つのドライバが、次のドライバがスイッチオンされる同じクロックフェーズにおいてスイッチオフされる場合に、バスコンテンションが起きないことを保証することを極端に困難にする。したがって、クロックの同じフェーズにおいて複数のドライバをターンオンしかつターンオフすることは、過渡的バスコンテンションを生じさせる可能性がある。
【００１１】
バスターンアラウンド時間、即ちナルサイクルは、それによりドライバ間バスコンテンションが防止されるスキームである。これは、全てのドライバがターンオフされている場合のバスアクセスプロトコルにおける割り当てられた時間のピリオド、即ち１つのドライバのスイッチオフと次のドライバのスイッチオンとの間の時間に関係する。したがって、バスプロトコルは、一般に、１つのバス上の複数のドライバのスイッチング間のナルサイクルを含む。ナルサイクル（即ち、バスターンアラウンド時間）は、最もフローティングノードの原因である可能性がある。
【００１２】
ナルサイクルの挿入は、バスコンテンションの問題を除去するが、これは、フローティングノードの問題およびそれに固有な前述した問題を生じる。
【００１３】
したがって、伝統的なバスおよびＳｏＣバスの両方において、バスキーパー（即ち、バスホルダ）が、しばしば設計に含められる。バスキーパーは、ノード（例えば、バス小部分(a bit of a bus））がフローティングすることを防止するフィードバック回路である。バスキーパーの目的は、バス小部分が常に、有効な論理レベルにドライブされ、特に、ライン上の直前のドライブされた論理レベルに保持されることを保証することである。
【００１４】
従来のバスキーパーのフィードバック回路中のバスドライバは、本質的に、最も最近以前にバス上に存在していた同じデータでバスをドライブするが、以前にそのバスをドライブしたデータ処理デバイスのドライバよりも弱い信号強度でドライブする。したがって、以前にドライブされた論理レベルは、ナルサイクルの間維持されるが、次のデータ処理デバイスがナルサイクルの終わりにおいてバスをドライブすることを開始した場合、その強いドライバは、バスキーパーの弱いドライバを容易にうち負かす。
【００１５】
これらの従来のバスキーパーは、いくつかの大きな欠点を有する。第１に、これらは本質的にバスドライバであるので、２つの強いドライバ間のコンテンションほど悪くないが、いくらかのバスコンテンションを生じる。それにも関わらず、コンテンションは、過剰な電力消費およびバス上での遅いデータ変化を生じる。また、従来のバスキーパー設計は、典型的には、回路設計間で容易に移り変わることができなかった。これは、従来のバスキーパーが、特別に設計されたトランジスタと共に設計されなければならず、特定の回路のデータ処理デバイスの強いドライバのトランジスタに対する正確なバランスを提供するように調節されなければならなかった。
【００１６】
また、ナルサイクルの仕様は、バスを遅くする。特に、ナルサイクルの間、バス上で新しいデータはドライブされることができない。ナルサイクルは、バス帯域幅の３０％−４０％になり得る。
【００１７】
この技術分野において知られた別の解決法は、複数のバスを一緒に使用することを避けて、その代わりにマルチプレクサを使用することである。
【００１８】
【発明が解決しようとする課題】
しかし、マルチプレクサは、データパス中にゲート遅れをもたらし、マルチプレクサの仕様に伴う多くのデータパスを形成するために必要とされる実質的に多数のワイヤのために、実質的に回路面積を増大させる。
【００１９】
【課題を解決するための手段】
本発明は、ナルサイクルおよびバスキーパーの必要性を除去するために、バス固有の電荷蓄積特性、および特にＣＭＯＳ技術において製造されるものを利用する。特に、バスノードは、典型的には、以前にアサートされた論理レベルを短い時間保持するように、それに関連づけられた少量のキャパシタンスを有する。システムオンチップ集積回路において、バススピードは、印刷基板を走る従来のバスよりも遙かに速くなる可能性がある。したがって、ＳｏＣ上のバスについてのデータレートは、バス固有の電荷蓄積特性を完全に利用することができるように、極めて高速であり得る。
【００２０】
本発明によれば、データは、１クロックサイクルの第１の半分（即ち、フェーズ）について、特定のコアデバイスのバスドライバによりバス上でドライブされる。ドライバは、データが受信デバイスにおいてラッチされる前に、クロックサイクルの中間クロックエッヂにおいてターンオフされる。バス固有の電荷蓄積特性は、クロックレートの第２の半分（即ちフェーズ）について有効なそのデータ値を保持する。受信装置は、バスクロックサイクルの第２のフェーズの間、即ち、ドライバがターンオフされた後、データをラッチする。
【００２１】
アクティブなバスキーパーまたはナルサイクルが存在しないので、バスキーパーおよびナルサイクルの使用に固有な不利益が、除去される。バスノード固有の電荷蓄積特性および現在の技術（特に、システムオンチップ）で可能な高いバススピードを利用することにより、バスは、クリティカルな電圧へフロートする時間を有しない。本発明によれば、バス帯域幅は、ナルサイクルの除去のために、劇的に増大され得る。
【００２２】
【発明の実施の形態】
本発明によれば、バスターンアラウンド時間、即ち、１つのバスドライバのターンオフと次のバスドライバのターンオンとの間に必要とされる時間は、ドライバ遷移間のナルサイクルを除去することにより、大幅に低減される。
【００２３】
本発明は、システムオンチップ集積回路上のバスと共に使用することに限定されないが、ＳｏＣ固有の非常に短いバスに対して容易に達成可能な所定のタイミング制約を受ける。そのようなタイミング制約は、ＰＣＢ上に走る従来のバスにより満たすことが可能ではあるが、遙かに困難である。
【００２４】
図１Ａおよび１Ｂは、それぞれ、従来のバスタイミングプロトコルを示す回路図およびタイミング図である。バスクロック１１０は、クロックサイクルの前縁（leading edge）を定義するフォーリングエッジを有する２フェーズクロックである。第１のデバイスコアに関連づけられたドライバ１０２は、バス１０６をドライブできる。同様に、第２のデバイスコアに関連づけられたドライバ１０８も、バスをドライブできる。
【００２５】
ドライバ１０２は、バス上のデータをクロックサイクル２についてドライブし、ドライバ１０８は、クロックサイクル３においてバスのドライビングを開始すると仮定する。ライン１２２に示されているように、ドライバ１０２についてのドライバイネーブル信号は、クロックサイクル２の第１の半分、即ち、Ｔ１からＴ３までについてアサートされる。回路遅れにより、ドライバ１０２によりバス上でドライブされるデータは、時刻Ｔ１において瞬時的に有効でないが、バスデータタイムライン１２０に示されているように、イネーブルされた後短い遅れで、時刻Ｔ２において有効になる。
【００２６】
ドライバ１０２イネーブル信号、ライン１１２は、時刻Ｔ３において非アサートになり、これは、クロックサイクルの中間の立ち上がりエッヂである。したがって、有効なデータは、タイムライン１２０に示されているように、時刻Ｔ２から時刻Ｔ３まで、バスドライバ１０２においてアクティブにドライブされる。ドライバイネーブル化に関して、ドライバ１０２は、タイムライン１１４および１２０の両方において分かるように、バスを完全に非アサート化するために、いくらかの有限な量の時間（Ｔ３からＴ４）を取る。
【００２７】
強制されたナル期間Ｔn は、クロックサイクルの第２の半分全体について、バスコンテンションを防止するために提供される。次のドライバは、この期間、即ち時刻Ｔ３から時刻Ｔ５までの間、バスにおいてデータをアサートすることはできない。そして、次のクロックサイクルのリーディングエッヂにおいて（時刻Ｔ５）、ドライバ１０８は、タイムライン１１６に示されているようにイネーブルされる。
【００２８】
ドライバ１０２に関して、タイムライン１１８および１２０に示されているように、ドライバ１０８のデータ出力が時刻Ｔ６において有効になる前にイネーブル信号がアサートされた後、小さな遅れ期間がある。遅れ期間Ｔa は、第２のドライバ１０８が、イネーブルされた後バスを有効な論理レベルにアサートするために必要とされる時間である。バス伝播遅れＴsuの後、データは受信デバイスに到達する。Ｔsuは、受信回路のセットアップ時間と呼ばれ、データが送信デバイスから受信デバイスへバスを介して伝わるためのバス伝播遅れ期間である。
【００２９】
図１Ｂから分かるように、図１Ａおよび１Ｂに示された従来のバスタイミングプロトコルの要求条件は、ドライバがターンオフされる前、即ち、クロックサイクルの第２の半分が時刻Ｔ７において始まる前に、データがあて先デバイスにおいて受信されることである。そして、Ｔa＋Ｔsu は、クロックサイクルの半分、例えばＴ７−Ｔ５よりも長くないはずである。図１Ｂは、時刻Ｔ７におけるクロックサイクルの第１のフェーズの終了まで、Ｔa＋Ｔsu が続くことを示す。しかし、上述したように、この図は、Ｔa＋Ｔsu の最大に許容される期間を示すが、より短い期間であってもよい。
【００３０】
したがって、図１Ａおよび１Ｂにより示された従来の回路において、クロックサイクルの第２の半分は、ドライバをスイッチングするためのナルサイクルであり、データは、クロックサイクルの第１の半分の間に、あて先デバイスに到達しなければならない。このタイミング要求条件が、ドライバがスイッチングしているときのみに存在する必要性により指図されるとしても、実際問題として、タイミング要求条件が、スイッチングデバイスに対して満たされなければならない場合、タイミング要求条件は全ての時点において満たされることになる。
【００３１】
したがって、Ｔa＋Ｔsu は、クロックサイクルの第２の半分が実際にナルサイクルとして使用され、またはいかなる特定のサイクルに対して実際に使用されないかどうかに関わらず、全ての時点において、クロックサイクルの半分に等しいかまたはこれより小さくなければならない。
【００３２】
クロックサイクルの第２の半分、例えば、Ｔ５からＴ７までは、バス上でデータがアクティブにドライブされ得ないナルピリオドである。しかし、前述したように、バスキーパーは、フローティングノードを防止するために、クロックサイクルの第１の半分の間にドライブされた同じ論理レベルにバスを保持するために使用される可能性がある。
【００３３】
本発明は、バス上でドライブされる論理レベルが、バス固有のキャパシタンスによりドライバがターンオフされた後短い期間についてバス上で有効なままとなるという事実を利用する。本発明は、データがバスを介して進み、かつあて先回路においてラッチされる遅れ期間、即ちＴsuが、この特性を完全に利用するために十分に短い場合に特に適用可能である。
【００３４】
本発明は、バス固有のキャパシタンスを利用することにより、スピードを実質的に増大させ（即ち、バスデータサイクル時間を減少させ）、送信デバイスのドライバがターンオフした後データを受信デバイスがラッチするが、データは依然としてバスキャパシタンスのために有効であることを可能にする。
【００３５】
この構成は、２つの大きな効果を有し、それは、バスクロックレート、したがってバスデータ転送レートが大幅に増大することを可能にし、実際、従来技術よりも２ないし４倍となる。第１に、ドライバのターンオンとデータのあて先デバイスへの到達との間の遅れ期間が、クロックサイクルの半分に等しいかまたはこれより小さいことをもはや必要としない。
【００３６】
本発明によれば、ドライバのターンオンとあて先デバイスにおけるデータのラッチとの間の遅れ期間は、単に、クロックサイクル全体と等しいかまたはこれより小さくなければならない。第２に、バスをドライブする異なるドライバ間のナルピリオドの必要がない。具体的には、データが受信される前にドライバをディスエイブルすることにより、新しいデータは、以前のデータが受信された直後に、バスにおいてドライブされ得る。
【００３７】
図２Ａおよび２Ｂは、本発明によるバス動作を示すそれぞれ回路およびタイミング図である。バスクロック２２０は、立ち上がりエッヂがクロックサイクルのリーディングエッヂである２フェーズクロックである。第１のデバイスコアに関連づけられたドライバ２０２は、バス２０６をドライブすることができる。同様に、第２のデバイスコアに関連づけられたドライバ２０８も、バスをドライブすることができる。
【００３８】
ドライバ２０２が、少なくともクロックサイクル２についてバス上のデータをドライブし、ドライバ１０８が、クロックサイクル３においてバスのドライビングを開始することを仮定する。ドライバのターンオフと受信デバイスのデータのラッチングとの間の期間は、ドライバがバスのドライビングをストップした後バス上のデータが無効になることが可能な最短時間（以下、最短データ衰退期間）よりも短くなければならない。
【００３９】
したがって、図２Ｂのタイミング図に示されているように、本発明によれば、ドライバ２０８は、バスクロックのリーディングエッヂにおいて、例えば、時刻Ｔ１において、イネーブルされる（ライン２２８）。短い遅れ期間の後、時刻Ｔ２において、バス上のデータは有効になる（ライン２２８および２３０を参照のこと）。クロックサイクルの中間エッヂにおいて、例えば時刻Ｔ３において、ドライバはディスエイブルされ、かつドライバはターンオフし始める。
【００４０】
短い遅れ期間の後、時刻Ｔ４において、ドライバは完全にオフし、もはやバス上のデータをドライブしない（ライン２２８および２３０を参照のこと）。しかし、ドライバが完全にオフしたとしても、データはクロックの第２のフェーズ中のいくらかの期間有効なままとなり、好ましくは、時刻Ｔ５における次のクロックサイクルのリーディングエッヂまで、クロックサイクルの第２のフェーズ全体を通して有効のままとなる。
【００４１】
そして、クロックの第１のフェーズの期間は、図１Ａおよび１Ｂに示された従来のバスプロトコルにおけるよりも遙かに短くなり得る。ドライバがイネーブルされた後データが有効になる期間Ｔ３は、クロックの第１のフェーズの期間、即ちＴ３−Ｔ１と同じかこれよりも短くなければならない。そして、受信デバイスは、クロックサイクルの終わりまで、データをラッチしなければならない。換言すれば、Ｔa＋Ｔsu は、クロックサイクル全体（即ち、Ｔ５−Ｔ１）と同じかまたはこれより短くなければならない。一方、従来技術においては、Ｔa＋Ｔsu はクロックサイクルの半分よりも短くなければならなかった。したがって、クロックスピードは、従来技術に比べて２倍になり得る。
【００４２】
したがって、本発明は、バスが極端に短く、データサイクルが相応に速い可能性のあるシステムオンチップ集積回路に特に適している。また、ＣＭＯＳ集積回路は、全てのドライバがオフしている場合のそれらの固有の高インピーダンス状態のために、特に適している。不可能ではないが、本発明のタイミング制約を、ＰＣＢ上のチップ間をバスが走らなければならない従来の複数チップ回路において満たすことは困難である。
【００４３】
複数チップ回路は、典型的にはバスデータサイクル時間をバス固有の電荷蓄積特性を利用するために十分に短く保つことを困難にする出力遅れおよび負荷インピーダンスパラメータを有する。複数チップ回路についての出力遅れは、通常、入力バッファ遅れ、出力バッファ遅れ、およびボード(board)レベルクロックスキューを含む。本発明を利用するほど十分に論理レベルがバスキャパシタンスにより保持され得ることを保証するために、基板が十分小さい漏れ電流およびその環境との十分に低い容量性および誘導性の結合を維持することは、通常可能ではない。
【００４４】
２フェーズバスクロックデータサイクルおよび５０％バスクロックデューティサイクルを仮定して本発明の１つまたは２つ以上の特定の実施形態を説明したが、これらのいずれも本発明の必要条件ではない。本発明によれば、（１）バスクロックは少なくとも２つのフェーズを有しなければならず、（２）サイクルの最後のフェーズが開始する前にデータがバス上で利用可能でなければならず、（３）データが受信デバイスにおいてラッチされるクロックフェーズの前に、バスドライバがディスエイブルされなければならない。
【００４５】
多くのシステムオンチップ集積回路について、バスデータが最後のクロックフェーズの終わりの前に有効になることを期待することは合理的である。一般に、ＳｏＣのためのマクロブロックは、出力遅れが様々な他のマクロブロックとうまく働くように再利用可能に設計される。
【００４６】
上述したパラメータは、本発明の特定の実施形態を説明するが、本発明は、より概念的に、（１）バスドライバは、受信デバイスがデータをラッチする前にディスエイブルされる、（２）ドライバがディスエイブルされる時点からデータが受信される時点までの期間は、固有のバスキャパシタンスが以前にドライブされた有効な論理レベルを維持する期間よりも短い、（３）以前のデータが受信デバイスによりラッチされるまで新しいデータはバス上でドライブされないことを必要とすると考えられ得る。
【００４７】
ここに示されたタイミングの説明において、従来技術の回路との関係で、上述したタイミングパラメータは、所定の回路についての最大の可能性のある対応する期間であることは、当業者に明らかである。
【００４８】
また、クロックフェーズは、等しい期間（例えば、５０％デューティサイクル）である必要はない。実際、本発明の好ましい実施形態において、各フェーズは、必要なタイムパラメータを満足しつつ、可能な限り短い。例えば、２フェーズクロックを仮定して、第１のフェーズは、Ｔa と同じくらい短くてもよく、第１のフェーズと第２のフェーズとの和は、Ｔa＋Ｔsu′と同じくらい短くてもよい。
【００４９】
本発明は、所定のクロックスピードに対して最大のバス帯域幅を提供し、または代替的に、遙かに短いバスサイクル、即ちより速いクロックおよびデータレートを提供する。これは、ナルサイクルで時間を浪費しないからである。例えば、データは、上述した従来技術によるバス回路に比べて、クロックピリオドに対して２倍の時間利用可能になり得る。ナルサイクルを除去し、かつ受信デバイスがクロックの最後のフェーズの間にデータをラッチすることを可能にすることにより、バスデータ転送レートは、２のべき乗だけ増大され得る。本発明は、複数のバスドライバ間またはバスドライバとバスキーパー間のバスコンテンションを防止し、スイッチングトランジェントを増大させることなしにナルサイクルを除去する。
【００５０】
バスキーパーは、一般に本発明で不必要であるが、本発明は、その利点を損なうことなしに、バスキーパーとの関連で使用され得る。特に有用な特定のバスキーパー回路の１つは、この出願と同じ出願人に譲渡された同日出願に係る"Clock Gated Bus Keeper" という名称の米国特許出願に開示されたバスキーパー回路である。
【００５１】
【発明の効果】
以上説明したように、本発明によれば、ナルサイクルの除去により、バス帯域幅を増大可能な送信デバイスと受信デバイスとの間でバスを介してデータを転送する方法を提供することができる。
【図面の簡単な説明】
【図１】従来技術によるバスアーキテクチャの回路およびタイミングを示す図。
【図２】本発明によるバスアーキテクチャの回路および動作タイミングを示す図。
【符号の説明】
１０２，１０８，２０２，２０８  ドライバ
１０６，２０６  バスデータ
１１２，２２２  ドライバ１イネーブル
１１４，２２４  ドライバ１
１１６，２２６  ドライバ２イネーブル
１１８，２２８  ドライバ２
１２０，２３０  バスデータ
【図１】
0003721074.tif 000002
【図２】
0003721074.tif 000003