(57)【要約】集積回路は、不揮発性メモリと結合される中央処理ユニットを伴う、マスタ処理コアと、マスタ処理コアから独立して動作し、揮発性プログラムメモリと結合される中央処理ユニットを有する、スレーブ処理コアとを有し、マスタ中央処理ユニットは、プログラム命令をスレーブ処理コアの不揮発性メモリの中に転送するように構成され、プログラム命令の転送は、マスタ処理コアの中央処理ユニット内で専用命令を実行することによって行われる。【特許請求の範囲】
【請求項１】
集積回路であって、
不揮発性メモリと結合される中央処理ユニットを有する、マスタ処理コアと、
前記マスタ処理コアから独立して動作し、揮発性プログラムメモリと結合される中央処理ユニットを有する、スレーブ処理コアと、
を備え、
マスタ中央処理ユニットは、プログラム命令を前記スレーブ処理コアの不揮発性メモリの中に転送するように構成され、
前記プログラム命令の転送は、前記マスタ処理コアの中央処理ユニット内で専用命令を実行することによって行われる、
集積回路。
【請求項２】
前記専用命令は、ソースアドレスを定義する第１のオペランドと、宛先アドレスを定義する第２のオペランドとを有し、前記宛先アドレスは、前記命令の実行後、自動インクリメントされる、請求項１に記載の集積回路。
【請求項３】
前記専用命令は、情報ワードをバッファの中に転送させ、前記情報は、前記バッファから前記揮発性プログラムメモリの中に書き込まれる、請求項１または請求項２に記載の集積回路。
【請求項４】
前記命令は、前記不揮発性メモリに前記情報を出力させ、それに応じて、前記情報は、前記バッファによって捕捉される、前記請求項のいずれか１項に記載の集積回路。
【請求項５】
前記情報は、２４ビットワードである、請求項３に記載の集積回路。
【請求項６】
前記集積回路は、複数のスレーブ処理コアを備え、前記専用命令は、標的スレーブ処理ユニットを定義する第３のオペランドを有する、前記請求項のいずれか１項に記載の集積回路。
【請求項７】
前記第１のオペランド内に記憶されるソースアドレスは、随意に、前記命令の実行後、自動インクリメントされることができる、請求項２−６のいずれか１項に記載の集積回路。
【請求項８】
前記ソースアドレスは、前記マスタ処理コアと関連付けられた周辺デバイスの特殊機能レジスタである、請求項２−７のいずれか１項に記載の集積回路。
【請求項９】
前記周辺デバイスは、シリアル通信周辺機器である、請求項８に記載の集積回路。
【請求項１０】
前記周辺デバイスは、パラレル入力ポートである、請求項８に記載の集積回路。
【請求項１１】
前記マスタ処理コアは、前記不揮発性プログラムメモリ内に記憶される情報を検証するさらなる命令を実行するようにさらに動作可能である、前記請求項のいずれか１項に記載の集積回路。
【請求項１２】
前記さらなる命令は、第１の情報を前記バッファの中に転送させ、前記バッファのコンテンツは、揮発性メモリ内に記憶される第２の情報と比較される、請求項１１に記載の集積回路。
【請求項１３】
前記さらなる命令は、前記不揮発性メモリに適用されて前記第１の情報を出力する第１のアドレスと、揮発性メモリに適用されて前記第２の情報を出力する第２のアドレスとを備える、請求項１１または請求項１２に記載の集積回路。
【請求項１４】
前記さらなる命令はさらに、前記第１および第２の情報と関連付けられたエラー補正コード（ＥＣＣ）を検証する、請求項１１−１３のいずれか１項に記載の集積回路。
【請求項１５】
前記不揮発性メモリと関連付けられたＥＣＣは、前記不揮発性メモリから読み取られることができ、前記ソースと関連付けられたＥＣＣは、別個に生成される、請求項１４に記載の集積回路。
【請求項１６】
第１の処理コアの不揮発性メモリは、保護スキームによって定義されたコード保護を備え、スレーブ処理ユニットの揮発性プログラムメモリは、前記保護スキームの設定に依存するコード保護を有する、前記請求項のいずれか１項に記載の集積回路。
【請求項１７】
前記保護スキームは、前記不揮発性メモリの複数のセグメントを定義し、各セグメントは、前記保護スキーム内に保護設定を有する、請求項１６に記載の集積回路。
【請求項１８】
前記不揮発性メモリのための各保護設定は、読取動作のための設定と、プログラムまたは消去動作のための設定とを有する、請求項１７に記載の集積回路。
【請求項１９】
前記保護スキームは、所定の数のセキュリティレベルを提供し、各セキュリティレベルは、セグメント毎に保護設定を定義する、請求項１６−１８のいずれか１項に記載の集積回路。
【請求項２０】
前記揮発性プログラムメモリのためのコード保護は、前記不揮発性メモリのセグメントのうちの１つのためのコード保護と同一である、請求項１７−１９のいずれか１項に記載の集積回路。
【請求項２１】
レジスタが、前記不揮発性メモリのどのセグメントが揮発性メモリのためのコード保護設定を提供するように選択されるかを記憶する、請求項１７−２０のいずれか１項に記載の集積回路。
【請求項２２】
前記不揮発性メモリの読取動作のための設定は、揮発性メモリの読取および書込動作に適用される、請求項１８−２１のいずれか１項に記載の集積回路。
【請求項２３】
セグメントが保護されるとき、保護設定に応じて、１つのセグメントから実行される命令は、異なるセグメント上で動作し得ない、請求項１７−２２のいずれか１項に記載の集積回路。
【請求項２４】
セグメントが保護されるとき、保護設定に応じて、１つのセグメントから実行される読取命令は、異なるセグメントの所定のエリア上のみで動作し得る、請求項１７−２３のいずれか１項に記載の集積回路。
【請求項２５】
前記所定のエリアは、インタラプトベクトルを記憶する、請求項２４に記載の集積回路。
【請求項２６】
前記不揮発性メモリは、ブートセグメントと、一般セグメントとを備える、請求項１７−２５のいずれか１項に記載の集積回路。
【請求項２７】
前記不揮発性メモリはさらに、試験セグメントを備える、請求項１７−２６のいずれか１項に記載の集積回路。
【請求項２８】
不揮発性メモリと結合される第１の中央処理ユニットを有する、第１の処理コアと、前記第１の処理コアから独立して動作し、揮発性プログラムメモリと結合される第２の中央処理ユニットを有する、第２の処理コアとを備える、マルチコア集積回路処理デバイス内の処理コアのためのファームウェアを提供するための方法であって、
データをスレーブ処理コアの不揮発性メモリの中に書き込ませる、前記第１の中央処理ユニット内の専用命令を実行するステップ
を含む、方法。
【請求項２９】
前記専用命令は、ソースアドレスを定義する第１のオペランドと、宛先アドレスを定義する第２のオペランドとを有し、前記宛先アドレスは、前記命令の実行後、自動インクリメントされる、請求項２８に記載の方法。
【請求項３０】
前記専用命令の実行に応じて、情報ワードは、前記不揮発性メモリからバッファの中に転送され、前記情報は、前記バッファから前記揮発性プログラムメモリの中に書き込まれる、請求項２８または請求項２９に記載の方法。
【請求項３０】
前記専用命令をループ内で繰り返すステップをさらに含む、請求項２８−３０のいずれか１項に記載の方法。
【請求項３１】
前記集積回路は、複数のスレーブ処理コアを備え、前記専用命令は、標的スレーブ処理ユニットを定義する第３のオペランドを有する、請求項２８−３０のいずれか１項に記載の方法。
【請求項３２】
前記第１のオペランド内に記憶されるソースアドレスは、随意に、前記命令の実行後、自動インクリメントされることができる、請求項２９−３１のいずれか１項に記載の方法。
【請求項３３】
前記マスタ処理コアによって、前記不揮発性プログラムメモリ内に記憶される情報を検証するさらなる命令を実行するステップをさらに含む、請求項２８−３２のいずれか１項に記載の方法。
【請求項３４】
前記さらなる命令は、第１の情報を前記バッファの中に転送させ、前記バッファのコンテンツは、揮発性メモリ内に記憶される第２の情報と比較される、請求項３３に記載の方法。
【請求項３５】
前記さらなる命令は、前記不揮発性メモリに適用されて前記第１の情報を出力する第１のアドレスと、揮発性メモリに適用されて前記第２の情報を出力する第２のアドレスとを備える、請求項３３または３４に記載の方法。
【請求項３６】
前記さらなる命令はさらに、前記第１および第２の情報と関連付けられたエラー補正コード（ＥＣＣ）を検証する、請求項３３−３５のいずれか１項に記載の方法。
【請求項３７】
前記不揮発性メモリと関連付けられたＥＣＣは、前記不揮発性メモリから読み取られることができ、前記ソースと関連付けられたＥＣＣは、別個に生成される、請求項３６に記載の方法。
【請求項３８】
前記第１の処理コアの不揮発性メモリは、保護スキームによって定義されたコード保護を備え、スレーブ処理ユニットの揮発性プログラムメモリは、前記保護スキームの設定に依存するコード保護を有する、請求項２８−３７のいずれか１項に記載の方法。
【請求項３９】
前記保護スキームは、前記不揮発性メモリの複数のセグメントを定義し、各セグメントは、前記保護スキーム内に保護設定を有する、請求項３８に記載の方法。
【請求項４０】
前記不揮発性メモリのための各保護設定は、読取動作のための設定と、プログラムまたは消去動作のための設定とを有する、請求項３８または請求項３９に記載の方法。
【請求項４１】
前記保護スキームは、所定の数のセキュリティレベルを提供し、各セキュリティレベルは、セグメント毎に保護設定を定義する、請求項３９または請求項４０に記載の方法。
【請求項４２】
前記揮発性プログラムメモリのためのコード保護は、前記不揮発性メモリのセグメントのうちの１つのためのコード保護と同一である、請求項３９−４１のいずれか１項に記載の方法。
【請求項４３】
レジスタが、前記不揮発性メモリのどのセグメントが揮発性メモリのためのコード保護設定を提供するように選択されるかを記憶する、請求項４２に記載の方法。
【請求項４４】
前記不揮発性メモリの読取動作のための設定は、揮発性メモリの読取および書込動作に適用される、請求項４０−４３のいずれか１項に記載の方法。
【請求項４５】
セグメントが保護されるとき、保護設定に応じて、１つのセグメントから実行される命令は、異なるセグメント上で動作し得ない、請求項３９−４４のいずれか１項に記載の方法。
【請求項４６】
セグメントが保護されるとき、保護設定に応じて、１つのセグメントから実行される読取命令は、異なるセグメントの所定のエリア上のみで動作し得る、請求項３９−４５のいずれか１項に記載の方法。
【請求項４７】
前記所定のエリアは、インタラプトベクトルを記憶する、請求項４６に記載の方法。
【請求項４８】
前記不揮発性メモリは、ブートセグメントと、一般セグメントとを備える、請求項２８−４７のいずれか１項に記載の方法。
【請求項４９】
前記不揮発性メモリはさらに、試験セグメントを備える、請求項２８−４８のいずれか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連特許出願）
本願は、２０１５年４月３０日に出願された共有に係る米国仮特許出願第６２／１５４，９２７号に対する優先権を主張するものであり、該米国仮特許出願は、あらゆる目的のために参照により本明細書中に援用される。
【０００２】
（技術分野）
本開示は、中央処理ユニット（ＣＰＵ）に関し、特に、デジタル信号処理ユニット（ＤＳＰ）を伴うマイクロコントローラに関する。本開示はさらに、マルチプロセッサ集積回路デバイスに関し、特に、複数のプロセッサを伴うマイクロコントローラに関する。
【背景技術】
【０００３】
（背景）
内蔵システムは、概して、中央処理ユニット（ＣＰＣ）と、メモリと、複数の周辺デバイスとを備え、単一チップシステムまたは単一チップマイクロコントローラを形成する。多くの高度なシステムは、１つを上回るＣＰＵを備える。ＣＰＵはさらに、本願の譲受人によって製造されたｄｓＰＩＣコア等のデジタル信号処理能力を有するように拡張されてもよい。図１は、そのような処理コアのブロック図を示す。図から分かるように、本コアは、Ｘ  Ｄａｔａ  ＲＡＭおよび別個のＹ  Ｄａｔａ  ＲＡＭ等の典型的デジタル信号処理能力と、ＲＡＭの両方が並行してアクセスされ得るようにＲＡＭおよびレジスタファイルと結合されるＤＳＰエンジンとを有する。本処理コアの他の典型的要素も、示される。加えて、本従来のＤＳＰ拡張マイクロコントローラは、図１の下に、システムバスを通してコアと結合されるある周辺デバイスを示す。図２は、レジスタファイルおよびＤＳＰエンジンのアキュムレータのワーキングレジスタならびに他の典型的ＤＳＰレジスタ等のコアのレジスタを示す。図３は、図１のブロック図のＤＳＰエンジンのより詳細なブロック図を示す。処理コアは、図１−３に示されるように、デジタル信号処理能力を備える、単一処理コアである。これは、コアのうちの１つとしてマルチコアデバイス内で使用されることができる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特に、例えば、そのコアのうちの少なくとも１つ内に信号処理能力を備えるデュアルコアマイクロコントローラ等のマルチコアデバイス内で使用されるとき、そのような処理コアのための改良された命令セットの必要性がある。
【０００５】
マルチプロセッサコアマイクロコントローラは、完全に分離されたコアを用いて設計されてもよく、各コアは、異なるシステムクロック上で動作してもよい。したがって、２つまたはそれを上回るコア間で通信する能力を提供するために、具体的通信インターフェースが、必要である。特に、マルチプロセッサデバイス上のプロセッサメモリ間でコード保護されたデータを移動させるための手段が、必要とされる。ソリューションは、完全に構成可能であるが、シリコン使用に関して効率的である必要があった。
【０００６】
マルチプロセッサマイクロコントローラのマスタ−スレーブ構成では、プログラムがスレーブの中にロードされた後もコード保護が維持されながら、デュアルコアスレーブプロセッサプログラムロード／検証方法論のためのサポートが必要とされる。
【課題を解決するための手段】
【０００７】
ある実施形態によると、集積回路は、不揮発性メモリと結合される中央処理ユニットを有する、マスタ処理コアと、マスタ処理コアから独立して動作し、揮発性プログラムメモリと結合される中央処理ユニットを有する、スレーブ処理コアとを備えてもよく、マスタ中央処理ユニットは、プログラム命令をスレーブ処理コアの不揮発性メモリの中に転送するように構成され、該プログラム命令の転送は、マスタ処理コアの中央処理ユニット内で専用命令を実行することによって行われる。
【０００８】
さらなる実施形態によると、専用命令は、ソースアドレスを定義する第１のオペランドと、宛先アドレスを定義する第２のオペランドとを有し、宛先アドレスは、命令の実行後、自動インクリメントされる。さらなる実施形態によると、専用命令は、情報ワードをバッファの中に転送させ、情報は、バッファから揮発性プログラムメモリの中に書き込まれる。さらなる実施形態によると、命令は、不揮発性メモリに該情報を出力させ、それに応じて、該情報は、該バッファによって捕捉される。さらなる実施形態によると、情報は、２４ビットワードである。さらなる実施形態によると、集積回路は、複数のスレーブ処理コアを備え、専用命令は、標的スレーブ処理ユニットを定義する第３のオペランドを有する。さらなる実施形態によると、第１のオペランド内に記憶されるソースアドレスは、随意に、命令の実行後、自動インクリメントされることができる。さらなる実施形態によると、ソースアドレスは、マスタ処理コアと関連付けられた周辺デバイスの特殊機能レジスタである。さらなる実施形態によると、周辺デバイスは、シリアル通信周辺機器である。さらなる実施形態によると、周辺デバイスは、パラレル入力ポートである。さらなる実施形態によると、マスタ処理コアは、不揮発性プログラムメモリ内に記憶される情報を検証するさらなる命令を実行するようにさらに動作可能である。さらなる実施形態によると、さらなる命令は、第１の情報をバッファの中に転送させ、バッファのコンテンツは、揮発性メモリ内に記憶される第２の情報と比較される。さらなる実施形態によると、さらなる命令は、不揮発性メモリに適用され、第１の情報を出力する、第１のアドレスと、揮発性メモリに適用され、第２の情報を出力する、第２のアドレスとを備える。さらなる実施形態によると、さらなる命令はさらに、第１および第２の情報と関連付けられたエラー補正コード（ＥＣＣ）を検証する。さらなる実施形態によると、不揮発性メモリと関連付けられたＥＣＣは、不揮発性メモリから読み取られることができ、ソースと関連付けられたＥＣＣは、別個に生成される。さらなる実施形態によると、第１の処理コアの不揮発性メモリは、保護スキームによって定義されたコード保護を備え、スレーブ処理ユニットの揮発性プログラムメモリは、保護スキームの設定に依存するコード保護を有する。さらなる実施形態によると、保護スキームは、不揮発性メモリの複数のセグメントを定義し、各セグメントは、保護スキーム内に保護設定を有する。さらなる実施形態によると、不揮発性メモリのための各保護設定は、読取動作のための設定と、プログラムまたは消去動作のための設定とを有する。さらなる実施形態によると、保護スキームは、所定の数のセキュリティレベルを提供し、各セキュリティレベルは、セグメント毎に保護設定を定義する。さらなる実施形態によると、揮発性プログラムメモリのためのコード保護は、不揮発性メモリのセグメントのうちの１つのためのコード保護と同一である。さらなる実施形態によると、レジスタが、不揮発性メモリのどのセグメントが揮発性メモリのためのコード保護設定を提供するように選択されるかを記憶する。さらなる実施形態によると、不揮発性メモリの読取動作のための設定は、揮発性メモリの読取および書込動作に適用される。さらなる実施形態によると、セグメントが保護されるとき、保護設定に応じて、１つのセグメントから実行される命令は、異なるセグメント上で動作し得ない。さらなる実施形態によると、セグメントが保護されるとき、保護設定に応じて、１つのセグメントから実行される読取命令は、異なるセグメントの所定のエリア上のみで動作し得る。さらなる実施形態によると、所定のエリアは、インタラプトベクトルを記憶する。さらなる実施形態によると、不揮発性メモリは、ブートセグメントと、一般セグメントとを備える。さらなる実施形態によると、不揮発性メモリはさらに、試験セグメントを備える。
【０００９】
別の実施形態によると、不揮発性メモリと結合される第１の中央処理ユニットを有する、第１の処理コアと、第１の処理コアから独立して動作し、揮発性プログラムメモリと結合される第２の中央処理ユニットを有する、第２の処理コアとを備える、マルチコア集積回路処理デバイス内の処理コアのためのファームウェアを提供するための方法は、データをスレーブ処理コアの不揮発性メモリの中に書き込ませる、第１の中央処理ユニット内の専用命令を実行するステップを含んでもよい。
【００１０】
本方法のさらなる実施形態によると、専用命令は、ソースアドレスを定義する第１のオペランドと、宛先アドレスを定義する第２のオペランドとを有し、宛先アドレスは、命令の実行後、自動インクリメントされる。本方法のさらなる実施形態によると、専用命令の実行に応じて、情報ワードは、不揮発性メモリからバッファの中に転送され、情報は、バッファから揮発性プログラムメモリの中に書き込まれる。本方法のさらなる実施形態によると、方法はさらに、該専用命令をループ内で繰り返すステップを含んでもよい。本方法のさらなる実施形態によると、集積回路は、複数のスレーブ処理コアを備え、専用命令は、標的スレーブ処理ユニットを定義する第３のオペランドを有する。本方法のさらなる実施形態によると、第１のオペランド内に記憶されるソースアドレスは、随意に、命令の実行後、自動インクリメントされることができる。本方法のさらなる実施形態によると、方法はさらに、マスタ処理コアによって、不揮発性プログラムメモリ内に記憶される情報を検証するさらなる命令を実行するステップを含んでもよい。本方法のさらなる実施形態によると、さらなる命令は、第１の情報をバッファの中に転送させ、バッファのコンテンツは、揮発性メモリ内に記憶される第２の情報と比較される。本方法のさらなる実施形態によると、さらなる命令は、不揮発性メモリに適用され、第１の情報を出力する、第１のアドレスと、揮発性メモリに適用され、第２の情報を出力する、第２のアドレスとを備える。本方法のさらなる実施形態によると、さらなる命令はさらに、第１および第２の情報と関連付けられたエラー補正コード（ＥＣＣ）を検証する。本方法のさらなる実施形態によると、不揮発性メモリと関連付けられたＥＣＣは、不揮発性メモリから読み取られることができ、ソースと関連付けられたＥＣＣは、別個に生成される。本方法のさらなる実施形態によると、第１の処理コアの不揮発性メモリは、保護スキームによって定義されたコード保護を備え、スレーブ処理ユニットの揮発性プログラムメモリは、保護スキームの設定に依存するコード保護を有する。本方法のさらなる実施形態によると、保護スキームは、不揮発性メモリの複数のセグメントを定義し、各セグメントは、保護スキーム内に保護設定を有する。本方法のさらなる実施形態によると、不揮発性メモリのための各保護設定は、読取動作のための設定と、プログラムまたは消去動作のための設定とを有する。本方法のさらなる実施形態によると、保護スキームは、所定の数のセキュリティレベルを提供し、各セキュリティレベルは、セグメント毎に保護設定を定義する。本方法のさらなる実施形態によると、揮発性プログラムメモリのためのコード保護は、不揮発性メモリのセグメントのうちの１つのためのコード保護と同一である。本方法のさらなる実施形態によると、レジスタが、不揮発性メモリのどのセグメントが揮発性メモリのためのコード保護設定を提供するように選択されるかを記憶する。本方法のさらなる実施形態によると、不揮発性メモリの読取動作のための設定は、揮発性メモリの読取および書込動作に適用される。本方法のさらなる実施形態によると、セグメントが保護されるとき、保護設定に応じて、１つのセグメントから実行される命令は、異なるセグメント上で動作し得ない。本方法のさらなる実施形態によると、セグメントが保護されるとき、保護設定に応じて、１つのセグメントから実行される読取命令は、異なるセグメントの所定のエリア上のみで動作し得る。本方法のさらなる実施形態によると、所定のエリアは、インタラプトベクトルを記憶する。本方法のさらなる実施形態によると、不揮発性メモリは、ブートセグメントと、一般セグメントとを備える。本方法のさらなる実施形態によると、不揮発性メモリはさらに、試験セグメントを備える。
【図面の簡単な説明】
【００１１】
【図１】図１は、デジタル信号能力を有する単一ＣＰＵを伴う、マイクロコントローラのブロック図を示す。
【図１Ａ】図１は、デジタル信号能力を有する単一ＣＰＵを伴う、マイクロコントローラのブロック図を示す。
【図１Ｂ】図１は、デジタル信号能力を有する単一ＣＰＵを伴う、マイクロコントローラのブロック図を示す。
【図２】図２は、図１による、ＣＰＵの種々のレジスタを示す。
【図３】図３は、図１による、ＣＰＵのＤＳＰエンジンの具体的部分を示す。
【図４】図４は、ある実施形態による、デュアルコアマイクロコントローラを示す。
【図５】図５は、種々の実施形態による、デュアルまたはマルチコアマイクロコントローラを示す。
【図６】図６は、いくつかの実施形態による、プログラムＲＡＭがアクセスされ得る方法の詳細を示す。
【図７】図７は、フラッシュメモリのセグメント化を示す。
【図８】図８−１１は、種々のセキュリティレベルを伴うテーブルを示す。
【図９】図８−１１は、種々のセキュリティレベルを伴うテーブルを示す。
【図１０】図８−１１は、種々のセキュリティレベルを伴うテーブルを示す。
【図１１】図８−１１は、種々のセキュリティレベルを伴うテーブルを示す。
【図１１Ａ】図８−１１は、種々のセキュリティレベルを伴うテーブルを示す。
【図１１Ｂ】図８−１１は、種々のセキュリティレベルを伴うテーブルを示す。
【図１１Ｃ】図８−１１は、種々のセキュリティレベルを伴うテーブルを示す。
【発明を実施するための形態】
【００１２】
図４および５に示されるように、デュアルまたはマルチコア処理デバイス４００は、マスタ中央処理ユニット（ＣＰＵ）４１２を伴う、マスタマイクロコントローラ４１０と、それぞれがスレーブ中央処理ユニット４２２を有する、１つまたはそれを上回るスレーブユニット４２０とを有するように設計されることができ、各スレーブ中央処理ユニット４２２のコア設計は、概して、マスタＣＰＵ４１２のコア設計と同じまたはそれに類似してもよい。しかしながら、他の実施形態によると、スレーブＣＰＵ４２２は、マスタＣＰＵ４１２と異なってもよい。マスタマイクロコントローラは、図４に示されるように、その独自のセットの周辺デバイスを有する。スレーブユニット４２０は、その独自のセットの周辺デバイスを有してもよく、またはそうではなくてもよく、したがって、それ自体でマイクロコントローラを形成する。したがって、各マスタおよびスレーブデバイスは、より多いまたはより少ない完全に独立した処理デバイスを形成し、専用バスまたは通信インターフェース４３０と通信してもよい。図４および５は、マスタマイクロコントローラ４１０と、単一スレーブマイクロコントローラ４２０とを伴う、そのような設計を示す。通信インターフェース４３０は、２つのコア４１０、４２０間の通信を可能にするように提供される。各プロセッサ４１２、４２２は、示されるように、Ｈａｒｖａｒｄアーキテクチャ内に設計されてもよい。しかしながら、種々の実施形態による原理は、ｖｏｎ  Ｎｅｕｍａｎｎアーキテクチャに容易に変換され得る。マスタユニットは、例えば、プログラムメモリとして使用されるフラッシュメモリ４１６と、データメモリとして使用されるランダムアクセスメモリ４１４とを備え、それぞれ、マスタコア４１２と結合される。
【００１３】
図４および５に示されるように、スレーブユニット４２０はフラッシュメモリを伴わずに設計されることができる。代わりに、専用プログラムランダムアクセスメモリ４２６が、提供される。本メモリが揮発性であるという事実に起因して、種々の実施形態によると、マスタ４１０を通してロードされるであろう。本設計選択肢は、フラッシュ技術によって提供されるボトルネックが回避されるという利点を有する。フラッシュメモリは、概して、ＲＡＭより低速である。故に、読取遅延がなく、スレーブは、より速い実行速度で動作されることができ、これは、例えば、ＳＭＰＳアプリケーション等のある高速アプリケーションにとって非常に有益であり得る。前述のように、１つを上回るスレーブユニット４２０が、種々の実施形態によると、実装されてもよい。両コアが同じである場合、マスタコア４１２は、スレーブユニット４２２内に実装されないか、またはスレーブユニット内では機能しないかのいずれかであり得る、付加的命令を含むように設計されることができる。これらの付加的命令は、フラッシュメモリ４１６からまたは外部ソースからスレーブデバイス４２０のＰＲＡＭ４２６へのデータの転送を可能にする。例えば、ある実施形態によると、複数のコアは、単一チップデバイス内に実装されてもよく、各コアは、割り当てられた構成レジスタを有してもよく、そのようなレジスタのビットのうちの１つは、個別のユニットがマスタであるかまたはスレーブであるかを定義してもよい。論理は、コアのうちの１つのみがマスタとして設定されることを可能にするように存在してもよい。いったん本ビットが設定されると、付加的命令は、実行されることが可能にされ得る。他のユニット（スレーブ）では、これらの命令は、実行され得ない、例えば、それらは、不正オペコードとして解釈され得る。
【００１４】
マスタユニット４１０によってＰＲＡＭ４２６にアクセスするための制御論理は、図４に示されるように、バッファ／コンパレータユニット４１８とともに、マスタユニット内に位置することができる。代替として、類似ユニットは、ＰＲＡＭラッパユニット４２８とともに、図５に示されるように、スレーブユニット４２０内に配列されてもよい。いずれかのユニットが、マスタユニット４１０またはスレーブユニット４２０のいずれかに排他的にＰＲＡＭのアクセスを付与するように設計される。他の実施形態は、論理のある部分をマスタコア内に、他の部分をスレーブコア内に設置する、または論理を両ユニットの外側に配列してもよい。同様に、通信インターフェース４３０は、いずれかのユニットの内側にあるかまたは完全に両ユニットの外側にあってもよい。ＰＲＡＭアクセスユニット４１８または４２８のための付加的制御が、図５に点線を用いて示されるように、通信インターフェース４３０によって提供されてもよい。図５はまた、点線を用いて、付加的スレーブユニット４４０および４５０を示す。全ユニットは、各スレーブユニット内のバスおよび関連付けられたラッパユニット４２８を通して接続してもよい。実施形態は、したがって、デュアルコア実装に限定されない。当業者は、他の実装も可能性として考えられることを認識するであろう。
【００１５】
図６は、スレーブ側における例示的インターフェースのブロック図を示す。本例示的実施形態では、マスタスレーブインターフェースは、通信インターフェース４３０を形成する。２つのマルチプレクサ４２８ａ、４２８ｂは、それぞれ、プログラムＲＡＭ４２６のデータおよびアドレスバスへのアクセスを付与する。付加的アクセス論理４２８ｃは、マスタユニット４１０、スレーブコア４２２、およびＰＲＡＭ４２６に接続されるように示される。本実施形態では、通信インターフェース４３０は、マルチプレクサを制御し、マスタユニット４１０へのアクセスを与える一方、スレーブプロセッサは、リセット状態に保持される。いったんＰＲＡＭ４２６がスレーブファームウェアをロードされると、マルチプレクサ４２８ａ、４２８ｂは、スレーブユニット４２０へのアクセスを戻すように制御され、ＣＰＵ４２２は、リセットから解放されるであろう。アクセス制御およびデータ検証論理４２８ｃは、読取および書込を分散させ、マスタユニット４１０またはスレーブユニット４２０のいずれかから生じ得る、信号をイネーブルにし得る。インターフェースは、図６に示されるように、マスタユニット４１０とＰＲＡＭ４２６との間の書込専用パスを提供してもよい。そのような実装では、アクセス制御およびデータ検証論理４２８ｃは、書き込まれたデータの検証を行うように構成されてもよい。例えば、一実施形態によると、アクセス制御およびデータ検証論理は、マスタユニット４１０と結合されると、２つの異なるモードで動作してもよい。第１のモードでは、スレーブファームウェアをＰＲＡＭ４２６の中に書き込むための論理信号を提供し、データバイトは、任意の好適な様式で、例えば、ＰＲＡＭ４２６の中に連続的に書き込まれる。第２のモードでは、ユニット４２８ｃは、検証機能を提供してもよい。伝送されるデータを書き込む代わりに、ユニット４２８ｃは、マスタユニット４１０によって提供されるデータとＰＲＡＭ４２６のコンテンツを比較し、正しくプログラムされていることを検証する。ＰＲＡＭに関するマスタ／スレーブインターフェースの他の実施形態も、可能性として考えられる。
【００１６】
したがって、種々の実施形態によると、マルチコアデバイス、特に、デュアルコアマイクロコントローラのためのスレーブプロセッサロード／検証方法論が、提供されることができる。これは、コア内でＤＳＰエンジンを使用する、特に、厳密制御ループアプリケーション（例えば、ＳＭＰＳアプリケーション）に関して、従来のマルチコアデバイスと比較して改良された効率および性能を提供する。しかしながら、処理コアは、ＤＳＰエンジンを含むように設計される必要はない。種々の実施形態による原理は、従来のＣＰＵのみを含む処理コアにも適用される。さらに、関連付けられたＣコンパイラの効率および性能は、そのような改良された命令セットによって改良されるであろう。
【００１７】
種々の実施形態によると、新しいデュアル（マルチ）コアアーキテクチャは、スレーブコアプログラムＲＡＭ（ＰＲＡＭ）をロードおよび検証するための専用ＣＰＵ命令を含む。性能要件が増加するにつれて、特に、ＤＳＰベースのアプリケーションに関して、ＣＰＵスループット、特に、ＤＳＰエンジンスループットを改良する必要性が、明白となる。例えば、速度の増加の必要性が存在する。一実施形態によると、デュアルコアデバイスは、そのプログラムメモリとしてフラッシュメモリを使用するマスタユニット４１０のために１００ＭＨｚ（例えば、０．７５ＭＩＰ／ＭＨｚにおいて）を標的とし、そのプログラムメモリとしてＰＲＡＭを使用するスレーブユニット４２０のために１２０ＭＨｚ（例えば、０．９ＭＩＰ／ＭＨｚにおいて）を標的とする。前述のように、スレーブユニット４２０内のプログラムメモリ４２６のためのＰＲＡＭ選択肢は、本ユニットが、より効率的かつより高速で起動することを可能にする。さらに、いくつかの実施形態によると、ＤＳＰのためのハードウェアコンテキストスイッチングに関する待ち時間もまた、低減される必要があり得る。最後に、他の実施形態によると、ＩＳＡ改良が、ＤＳＰアルゴリズム効率を改良するために必要とされ得る。コンパイラ効率における利得は、いくつかの実施形態によると、ビットフィールド命令およびより柔軟なレジスタ利用を伴うより高速の分割器を用いて達成され得る。
【００１８】
これらの改良のうちのいくつかは、既存の設計への最小限の変更を伴って、新しい命令および能力を追加することによって達成され得る。他の改良は、同一反復非回復型アルゴリズムを使用して、除算演算を加速することによって達成され得る。以下の改良は、独立して実装されることができる。したがって、種々の実施形態は、これらの改良の全部またはサブセットを使用してもよい。
【００１９】
要するに、ＣＰＵ改良は、スレーブコアプログラムＲＡＭ（ＰＲＡＭ）のロードおよび検証；ＤＳＰアキュムレータ、ステータス、およびＤＳＰエンジン構成を含むように拡張されたハードウェアコンテキストスイッチ；データ限界（境界チェック）命令；アキュムレータ３２ビットデータロード／記憶命令；およびＤＳＰ正規化命令のＤＳＰ改良の一部または全部を提供する、デュアルコアサポート命令を備え得る。達成され得るコンパイラ効率利得は、ビットフィールド命令および除算命令改良である。
【００２０】
種々の実施形態によると、ＤＳＰ機能性を伴うデュアルコアマイクロコントローラは、スレーブプログラム初期化を促進するために追加されるＰＲＡＭロード（ＬＤＳＬＶ）および検証（ＶＦＳＬＶ）命令を伴うスレーブコアを備えてもよい。これらの命令は、従来のプログラム空間可視性（ＰＳＶ）アドレス指定またはＴＢＬＷＴｘ命令の使用と比較して、ＰＲＡＭのメモリマップ画像からのデータの移動のより高速の代替となるように設計される。命令は、ＣＰＵが、前述のように、マスタ（ＣＰＵ＿ＩＳ＿ＭＡＳＴＥＲ＝１）としてインスタンス化されるときのみイネーブルにされる。ディスエーブルにされると、それらは、不正オペコードと見なされるであろう。
【００２１】
ＰＲＡＭをロード／検証するための一意の命令を使用する別の利点は、ＰＲＡＭをマスタアドレス空間の中に再マップする必要なく、既存のＰＳＶ  ＣＰＵ命令フローを保つ（単に、スレーブに、通過アドレスおよびデータをスヌープさせる）ことによって、設計および検証を単純化することである。一実施形態によると、既存のＭＯＶ命令は、スレーブＰＲＡＭ捕捉機能をイネーブルにするための制御フラグを用いて拡張され得る。しかしながら、ＰＲＡＭが初期化された方法に関してユーザに対するより明確なレベルを追加することを可能にする（かつこれらのオペコードがそもそも不注意に実行されるであろう可能性が低いという理由からわずかなセキュリティを提供する）ので、一意の命令（ＭＯＶオペコードに類似するが、また、ＰＲＡＭをマスタクロックドメインにスイッチし、それをロードするように伝えるためのスレーブへの信号をアサートしたもの）を作成することがより有益である。
【００２２】
ＬＤＳＬＶ命令は、いくつかの実施形態によると、命令ワード（Ｉ−ｗｏｒｄ）全体をＰＳ（フラッシュ）からＰＳ（Ｓａｖｅ  ＰＲＡＭ）に２サイクル以内に移動することができるという理由から、他のデータ移動命令と異なる。各読取は、２４ビットワードをフラッシュからフェッチし、次いで、標的スレーブＰＲＡＭへのそのワードの書込をもたらすであろう。従来のｄｓＰＩＣ／ＰＩＣ２４  ＣＰＵアーキテクチャは、１６ビットより大きいデータ値をフラッシュから移動する手段を有しておらず、したがって、データは、マスタＣＰＵを通して移動されないが、スレーブによって捕捉される（フラッシュデータバス上で利用可能であるとき）。したがって、これらの新しい命令は、それらを実行しているプロセッサの自然データ幅より広いデータを（単一エンティティとして）移動可能であるという点において一意である。
【００２３】
スレーブは、捕捉されたデータを使用して、それを規定されたＰＲＡＭアドレスに書き込む（ＬＤＳＬＶ）か、またはそれを規定されたＰＲＡＭアドレスのコンテンツと比較する（ＶＦＳＬＶ）かのいずれかを行うであろう。ＬＤＳＬＶＮＦＳＬＶ命令は、同じ方式で動作するが、ＶＦＳＬＶは、信号ｃｐｕ＿ｓｌａｖｅ＿ｐｒａｍ＿ｖｅｒｉｆｙ＿ｅｎをアサートし、マスタフラッシュから読み取られるデータがＰＲＡＭコンテンツに対して比較されるべきであることを示す（ＰＲＡＭの中にロードされる代わりに）。
【００２４】
これらの命令は、マスタデバイス４１０のフラッシュメモリ４１６を含む、所定のソースからのデータをプログラムＲＡＭ（ＰＲＡＭ）４２６の中に転送することを可能にし得る。この目的を達成するために、マスタデバイス４１０は、データを転送し、転送されるデータを検証するための専用命令を提供してもよい。例えば、以下である。
【００２５】
−標的アドレスとともに捕捉される、マスタフラッシュ画像４１６からのデータワードを、スレーブＰＲＡＭラッパまたはバッファ４１８／４２８の中に移動する、ロードスレーブ命令ＬＤＳＬＶ。そのような命令は、例えば、ポストインクリメント機能性を伴う、または伴わない、間接ソースアドレスと、ポストインクリメント機能性を伴う、間接宛先アドレスと、複数のスレーブのうちのどれが宛先であるかを定義するであろう、リテラルとを定義するであろう。しかしながら、デュアルコア（単一スレーブ）実装では、リテラルはまた、省略され得る。ポストインクリメント機能性をソース上に有するオプションは、ＬＤＳＬＶ／ＶＦＳＬＶが、実行後、後続ＬＤＳＬＶ／ＶＦＳＬＶ反復に備えて、次のソースアドレスに自動的にインクリメントすることを可能にする。これは、特に、ＲＥＰＥＡＴループ内から実行するときに有用である。ポストインクリメントオプションを使用しないとき、同一命令は、同じデータのブロックを宛先ＰＲＡＭ４２６内に書き込むために使用され得る（ブロックフィルとしても知られる）。代替として、ソースアドレスは、マスタ周辺デバイス、例えば、フラッシュコントローラプログラミングデータレジスタのｎビット、例えば、２４ビット特殊機能レジスタにポイントし得る。他の実施形態によると、ソースは、潜在的に、パラレル入力ポート、シリアル受信バッファ等でもあり得る。いくつかの実施形態は、プログラムアドレス空間の中にマップされる、ｎビットレジスタ、例えば、２４ビットレジスタのみが、使用可能であり得る。したがって、外部データを２４ビット特殊機能レジスタにダイレクトすることによって、スレーブデバイス４２０のＰＲＡＭ４２６の中に間接的に書き込まれ得る。しかしながら、ポストインクリメント機能は、プログラムデータをマスタフラッシュメモリ４１６からスレーブＰＲＡＭ４２６の中に転送するための主要機能であり得る。一実施形態では、マスタフラッシュ４１６およびスレーブＰＲＡＭ４２６は、同じように編成されてもよく、各データワード読取は、適切な論理４２８によって、直接、ＰＲＡＭ４２６の中に転送され得る。しかしながら、いくつかの実施形態では、ＰＲＡＭ４２６は、フラッシュメモリ４１６と異なる方式で編成されてもよい。例えば、フラッシュメモリ４１６は、２４ビットワード内に編成され得る一方、ＰＲＡＭ４２６は、４８ビットワード内に編成され得る。そのような実装では、バッファ４１８／４２８は、フラッシュメモリ４１６からの第１の読取を記憶し、記憶されたデータを後続読取とともにＰＲＡＭ４２６の中に書き込むように提供されてもよい。いくつかの実施形態によると、ここでの限界は、ソースフラッシュデータの幅であり得ず、実際には、ＬＤＳＬＶ／ＶＦＳＬＶ動作は、単一ｎビット値、例えば、２４ビット値上でのみ稼働し得る。したがって、ソースフラッシュが４８ビット幅であっても、２４ビット値のみが、そのような実施形態では、そもそも移動され得る。他の実施形態は、そのような値に制限され得ない。他の転送機構も、種々のメモリのための具体的設計選択肢に従って適用され得る。さらに、エラー補正コード（ＥＣＣ）が、フラッシュメモリ４１６およびＰＲＡＭ４２６内に実装されてもよい。エラー補正に関して、フラッシュおよびＰＲＡＭが両方とも、ＥＣＣと同一ワード幅である場合でも、ある実施形態によると、ＥＣＣパリティデータは、コピーされない。むしろ、常時、それをロードすると、ＰＲＡＭラッパ内で再生成される。いくつかの実施形態によると、これは、既存の２４ビットデータパスのみをコア内で利用し得る、既存のＰＳＶモデルを再使用する限界に起因し得る。再び、他の実施形態は、そのような制限に直面し得ない。
【００２６】
−例えば、２４ビットデータワードをマスタフラッシュ画像から読み取り、データをＰＲＡＭ４２６のコンテンツと比較する、検証スレーブ命令ＶＦＳＬＶ。したがって、コンパレータが、フラッシュメモリおよびＰＲＡＭ内に記憶されるデータの実際の比較を行うために提供されてもよい。フラッシュメモリは、ＥＣＣ機能性に関して設計され得、本付加的情報は、いくつかの実施形態によると、読取可能ではないが、ＲＡＭからのＥＣＣデータは、読取可能であってもよい。比較機構、例えば、バッファおよび関連付けられたコンパレータは、ＥＣＣデータを読み取られたフラッシュメモリデータから生成するための論理を装備してもよい。したがって、本命令は、完全検証のために、マスタデータに関するＥＣＣパリティを再計算し、記憶されたＰＲＡＭ  ＥＣＣと比較してもよく、また、いくつかの実施形態によると、比較不良の場合、（「スティッキー」）検証エラーを（ＭＳＩマクロ内に）フラグしてもよい。
【００２７】
−ＬＤＳＬＶ／ＶＦＳＬＶ命令は、ＲＥＰＥＡＴループ内で実行されるように設計されてもよく、いくつかの実施形態では、既存のデータパイプラインを使用して、（最大）３サイクル（アクセス時間）フラッシュから１ワード／サイクルへの転送を加速してもよい。第１の実行は、データパイプラインをプライミングし、データ整合をハンドルするために、１を上回るサイクル、例えば、５サイクルを要求し得る。しかしながら、任意の後続転送は、単一サイクル内で行われ得る。最後の命令またはラップアップは、例えば、データパイプラインを展開するために、３サイクルを要求し得る。ＰＲＡＭの中に転送されるべきプログラムのサイズに応じて、反復ループ内の単一サイクル転送が、転送を有意に加速させる。他の実施形態は、概して、各命令を単一サイクル内で実行し得る。
【００２８】
−いくつかの実施形態によると、スレーブデュアルパネルモードで動作するとき、ＬＤＳＬＶ／ＶＦＳＬＶ命令は、スレーブがディスエーブルにされると、アクティブＰＲＡＭへのアクセスのみを有し得、ＬＤＳＬＶ／ＶＦＳＬＶ命令は、常時、非アクティブＰＲＡＭへのアクセスを有し得る。デュアルパネルモードは、いくつかのデバイスに適用され、ＰＲＡＭを２つの別個のブロックに分裂させる。本モードでは、ＰＲＡＭ制御は、「非アクティブ」パネルがマスタによって（再）ロードされている間（おそらく、デバイス更新の間にフラッシュの中に再プログラムされた新しいＰＲＡＭ画像を伴う）、スレーブが、「アクティブ」パネルから実行を継続し得るように構成されるようになる。いったん完了すると、マスタは、パネルをスイッチし得ることをスレーブに信号伝達する（専用命令、例えば、ＢＯＯＴＳＷＰ命令を使用して、オンザフライで）。これは、非常に特殊な「ライブ更新」スキームであって、いくつかの実施形態において実装され得、ソフトウェア更新がデバイスの中に再フラッシュされている間、スレーブが、実行（例えば、ＳＭＰＳの内側の制御ループ）を保つことを可能にするように設計される。これらのループを数１００ＫＨｚまたはそれを上回って起動するアプリケーションは、フルデバイスリセットと関連付けられたダウンタイム（数ミリ秒）を所望せず、したがって、リセットを伴わずに、新しいＰＲＡＭコードをロードし、次いで、それに瞬時にスワップすることを可能にすることを所望する。ＢＯＯＴＳＷＰが行うべきことは、文字通り、単に、ＰＲＡＭパネルをスイッチすることのみであるため、そのような実施形態のためのファームウェアは、スマートハンドオーバを要求し得る。デバイスが通常通りリセットすると（将来のある時点で）、新しいＰＲＡＭコードは、通常通り「アクティブ」パネルの中にロードされるであろう。
コード実施例：
実施例１：ＬＤＳＬＶ：フラッシュからのＰＲＡＭロード
【化１】
2018514868.tif 000002
【００２９】
実施例１に示されるコード断片は、ＬＤＳＬＶ命令がスレーブ＃０のＰＲＡＭをロードするためにアプリケーション初期化の間に使用され得る方法を実証する。
実施例２：ＶＦＳＬＶ：フラッシュからのＰＲＡＭ検証
【化２】
2018514868.tif 000003
【００３０】
実施例２に示されるコード断片は、ＶＦＳＬＶ命令がスレーブ＃０のＰＲＡＭコンテンツを検証するためにアプリケーション初期化の間に使用され得る方法を実証する。
実施例３：ＬＤＳＬＶ：フラッシュからのＰＲＡＭブロックフィル
【化３】
2018514868.tif 000004
【００３１】
実施例３に示されるコード断片は、ＬＤＳＬＶ命令がスレーブ＃０のＰＲＡＭをブロックフィル（すなわち、定数値を伴うロード）するために使用され得る方法を実証する。この場合、定数は、ＬＤＳＬＶのためのレジスタ間接アドレスを使用して、フラッシュから供給される（ポストインクリメントなし）。
実施例４：ＬＤＳＬＶ：ＮＶＭＤＡＴＡＬからのＰＲＡＭロード
【化４−１】
2018514868.tif 000005
【化４−２】
2018514868.tif 000006
【００３２】
代替として、ブロックフィルオペコード値は、ＮＶＭコントローラ２４ビットＮＶＭＤＡＴＡＬレジスタから供給される変数であってもよい。ＮＶＭＤＡＴＡＬレジスタは、ＰＳ内に位置し、ＮＶＭコントローラがフラッシュプログラム／消去のためにイネーブルにされない（すなわち、ＮＶＭＣＯＮ．ＷＲＥＮ＝０）と、２４ビットｒ／ｗレジスタとなる。レジスタは、フラッシュプログラム／消去がイネーブルになる（すなわち、ＮＶＭＣＯＮ．ＷＲＥＮ＝１）ときは常時、書込専用である。任意の命令オペコードが、ＮＶＭＤＡＴＡＬの中にロードされ、続いて、ＰＲＡＭの中にロードされてもよい。ＶＦＳＬＶ命令は、ＬＤＳＬＶ動作の成功を確認するための同一様式で使用されてもよい。本アプローチはまた、デバイスから外部供給されるデータとともに、ＰＲＡＭの全部または一部をロードするために使用され、実施例４に示されるように、それを最初にマスタフラッシュメモリの中にプログラムする必要性を除去し得る。
【００３３】
いくつかの実施形態によると、付加的命令が、ＤＳＰエンジンとともにＣＰＵ内に実装されてもよい。そのような付加的命令は、必ずしも、前述のロード／検証命令の実装を要求しない。さらに、それらは、マルチコア設計を要求せず、また、ＣＰＵおよび統合されたＤＳＰエンジンを備える、単一コアデバイス内にも実装され得る。
【００３４】
したがって、いくつかの実施形態によると、第１のタイプの命令は、１６ビットデータ境界チェックであってもよく、限界機能性は、強制データ限界（ＦＬＩＭ／ＦＬＩＭ．ｖ）命令を追加し、１６ビットデータ境界チェックおよび限界動作を加速させ得る。そのような命令は、標的符号付き値と個別のＷレジスタ内に保持される上限および下限を比較する。標的値が上限を上回る、または下限未満である場合、限界超過レジスタが、標的符号付き値とともにロードされる。したがって、飽和関数が、ユーザ選択可能上限および下限を用いて定義されることができる。そのような命令は、以下の２つのバージョンで実装されることができる。
【００３５】
ＦＬＩＭ：前述の機能をＣＰＵのワーキングレジスタおよびステータスビットのセットのいずれかに行い、結果を示す。
ＦＬＩＭ．ｖ：ステータスビットを設定し、結果を示す；限界を超過した符号付き値をＷｎの中に保存し、これは、アンチワインドアップアルゴリズムに有用であり得る。したがって、本命令は、ＦＬＩＭと同一機能を行うが、また、以下の実施例５のコード断片に示されるように、オーバーシュート（またはアンダーシュート）値を指定されるレジスタ内に記憶する。
実施例５：
【化５】
2018514868.tif 000007
【００３６】
第２の付加的命令は、ＤＳＰアキュムレータベースの境界チェックおよび限界動作を加速するために追加される、アキュムレータ最大および最小命令（ＭＡＸＡＢ／ＭＩＮＡＢ）である：これらの命令は、標的アキュムレータ内の符号付き値と、他のアキュムレータ内に保持される上限（ＭＡＸＡＢ）または下限（ＭＩＮＡＢ）を比較する。限界アキュムレータ値が、上限（ＭＡＸＡＢ）を上回る、または下限（ＭＩＮＡＢ）未満である場合、限界アキュムレータは、標的アキュムレータの中にコピーされる。再び、これらの命令は、以下の２つの実装で実装され得る。
【００３７】
ＭＡＸＡＢ／ＭＩＮＡＢ：前述のような機能を行い、ステータスビットを設定し、結果を示す。
ＭＡＸＡＢ．ｖ／ＭＩＮＡＢ．ｖ：前述と同一機能を行い、ステータスビットを設定し、結果を示す。さらに、これらの命令は、ＦＬＩＭ．ｖ命令同様に、限界を超過した符号付き値をＷｎまたはメモリ（アンチワインドアップアルゴリズムのために有用）の中に保存するが、４０ビットアキュムレータ値を用いて動作する。
実施例６：
【化６】
2018514868.tif 000008
【００３８】
両タイプの命令が実行されると、それらは、続いて、前述の断片に示されるように、実行されるように設計され得る。これらの命令は、自動的に、個別のフラグを設定し、最大または最小限界に到達したことを示す。一実施形態によると、最小限界命令は、限界に到達しない場合、無動作命令のように機能するように設計され得、それによって、ステータスレジスタのフラグに影響を及ぼさない。したがって、前述に示されるように、分岐命令は、１回のみ、実行される必要がある。最大限界命令がフラグをトリガする場合、最小限界命令は、無動作命令のように実行するであろうため、リセットしないであろう。以下の分岐命令は、正しく実行するであろう。本機能性は、ＭＡＸＡＢ（．ｖ）命令がＭＩＮＡＢ（．ｖ）命令の前に実行されることのみを要求し得る。
【００３９】
さらなる命令が、実装されることができるが、これもまた、デュアルまたはマルチコア設計を要求しない。いくつかの実施形態によると、３２ビットロード／記憶アキュムレータ命令（ＬＡＣ．ｄ／ＳＡＣ．ｄ）が、中間結果の移動を加速するために追加されることができ、分解能が失われ得ない。既存のロード／記憶アキュムレータ（ＬＡＣ／ＳＡＣ）命令は、１６ビットデータを移動させるが、１．３１アキュムレータデータを移動させるための直接手段は、従来のｄｓＰＩＣコア内には存在しない。種々の実施形態によると、３２ビットデータを移動させるように拡張される命令は、以下を含み得る。
ＬＡＣ．ｄ：３２ビット値をメモリからアキュムレータＡまたはＢの中に読み取り、随意に、シフトし、次いで、符号拡張する
ＳＡＣ．ｄ：随意に、アキュムレータＡまたはＢのＬＳ３２ビットをメモリの中にシフトし、次いで、記憶する
【００４０】
いくつかの実施形態によると、これらは、単一命令ワードとして実装されることができ、２サイクル以内に実行され得る。
【００４１】
他の実施形態によると、アキュムレータ正規化（ＮＯＲＭ）命令が、既存の正規化シーケンスを加速する（ＦＢＣＬ命令を使用して）ために追加されることができる。既存のＣＰＵ  ＩＳＡは、Ｆｉｎｄ  Ｆｉｒｓｔ  Ｂｉｔ  Ｃｌｅａｒ  Ｌｅｆｔ（ＦＢＣＬ）を含む、複数の命令の使用を通して、アキュムレータデータ正規化をサポートする。
【００４２】
６命令、５サイクル動作（最大１６ビットシフト専用）。
【００４３】
いくつかの実施形態は、１命令ワードのみを使用して、１サイクル内で実行する、ＮＯＲＭ命令を実装してもよい。命令は、自動的に、最大１６ビットによって両方向に標的アキュムレータを正規化する。これは、１６ビットを上回る正規化に対してカスケードされてもよい。
各反復からの指数が、次いで、追加されることができる。
これは、３命令、３サイクル動作をもたらす。
【００４４】
しかしながら、ＮＯＲＭ命令の他の実装は、単一反復内でアキュムレータ全体を正規化可能であり得る。
【００４５】
いくつかの実施形態によると、ビットフィールド命令（ＢＦＩＮＳ／ＢＦＥＸＴ）が、コンパイラ効率を改良するために追加される。コンパイルされたコードは、頻繁に、標的ワード内で複数のビットを挿入または抽出する必要がある。ビットフィールドオフセットおよび幅は、常に、定数値である。
ＢＦＩＮＳ：ビットフィールドをＣＰＵ  Ｗ−レジスタまたはリテラル値から標的ワードの中に書き込む
ＢＦＥＸＴ：ビットフィールドを標的ワードから読み出し、それをＣＰＵ  Ｗ−レジスタの中にロードする
【００４６】
全ビットフィールド命令は、２ワード、２サイクル動作である：ビットフィールドを用いない場合、動作全体が完了するために、約７ワード、７サイクルを要求する。ビットフィールドを用いる場合、動作全体が完了するために、約４ワード、４サイクルを要求する。
【００４７】
いくつかの実施形態によると、除算改良は、インタラプト可能な非回復型除算命令一式（従来のｄｓＰＩＣと同様に）を提供する。実行時間は、ここでは、全除算命令に対して７サイクル（Ｐ３３Ｅ：１９サイクル）（ＲＥＰＥＡＴ命令のための１サイクルを含む）であって、オリジナル除算ＲＥＰＥＡＴカウントを使用する既存のアプリケーションコードと完全にバックワード互換性がある。
【００４８】
さらに、いくつかの実施形態によると、代替除算命令セットが、コンパイラレジスタ配分効率を改良するために提供されることができる。既存の（３２／１６ビット）除算命令は、被除数Ｗｍ＋１：Ｗｍ、除数Ｗｎ、および余り：商Ｗ１：Ｗ０である。
【００４９】
代替除算命令セットでは、被除数Ｗｍ＋１：Ｗｍ、除数Ｗｎ、および余り：商Ｗｍ＋１：Ｗｍであって、Ｗ１：Ｗ０は、保存される。
【００５０】
要するに、以下の付加的命令が、特に、ＣＰＵおよびＤＳＰエンジンを備えるｄｓＰＩＣコアのために提供されることができる。第１の命令ＬＤＳＬＶおよびＶＦＳＬＶのみが、マルチコアデバイスのために具体的に設計され、全ての他の命令は、任意の組み合わせにおいて随意に実装されてもよい。
ＬＤＳＬＶ、ＶＦＳＬＶ：ロードおよび検証スレーブＰＲＡＭ
ＦＬＩＭ｛．ｖ｝：符号付き１６ビットデータ値境界チェックおよび限界
ＭＡＸＡＢ｛．ｖ｝、ＭＩＮＡＢ｛．ｖ｝：アキュムレータ１．３１データ値境界チェックおよび限界
ＬＡＣ．ｄ、ＳＡＣ．ｄ：アキュムレータ３２ビットロードおよび記憶
ＮＯＲＭ：アキュムレータ正規化
ＢＦＩＮ、ＢＦＥＸＴ：ビットフィールド挿入および抽出
ＤＩＶｘ２：Ｗ１：Ｗ０を保存する、代替除算命令セット
【００５１】
図７に示されるようなさらなる実施形態によると、デュアル（マルチ）コアプロセッサのためのコード保護スキームが、提供されてもよい。本保護スキームは、特に、デュアルコアマイクロコントローラ内のスレーブプロセッサに有益である。他の実施形態によると、本概念はまた、単一コアプロセッサまたはマイクロコントローラに適用されてもよい。図７は、例示的コード保護スキーム７００を示す。フラッシュメモリは、いくつかのセグメントに分裂されてもよく、それぞれ、他へのアクセスに関するその独自のルールを伴う。例えば、デバイスまたはヒューズ機構のプログラミングの間のみ構成され得る、構成レジスタが、アクセス保護スキームを設定するために提供されてもよい。図７は、フラッシュがユーザフラッシュおよび試験フラッシュパーティションに分割されることを示す。しかしながら、他の実施形態は、単一パーティションのみまたはさらに多くのパーティションを提供してもよい。ユーザフラッシュパーティションは、ブートセグメントおよび一般セグメントにセグメント化される。さらに、インタラプトベクトルテーブルＩＶＴおよびＡＩＶＴのためのより小さいセグメントが、提供されてもよく、これは、現在の設定保護レベルに応じて、ブートセグメントの中に含まれてもよい、または別個の保護を有してもよい。図７は、異なる場所におけるインタラプトベクトルテーブルＩＶＴおよび代替インタラプトベクトルテーブルＡＩＶＴを示す。しかしながら、他の実施形態は、これらの２つのテーブルを、ブートセグメントＢＳの前または任意の他の好適な場所に位置し得る、１つのセグメントＶＳに統合してもよい。最後に、例えば、統合された回路内プログラム機能によって、デバイスがプログラムされるときのみ書き込まれ得る、種々のデバイス構成レジスタを備える、構成セグメントが、提供されてもよい。セグメントの配列は、個別の実装に従って、異なってもよい。保護スキームは、種々の異なる設定を可能にし、各セグメントは、異なるように保護されてもよい。特に、１つのセグメントから別のセグメントへのアクセスは、具体的設定に従って、制限されてもよい。さらに、セグメントへのベクトル化は、セキュリティ設定に従って制限されてもよい。
【００５２】
いくつかの実施形態に従って実装される場合、試験アドレス空間は、フラッシュのいくつかの特殊セクタを含有し、全て、例えば、２４ビットプログラム空間であり得る、プログラム空間の上位（最高アドレス）半分内にある。そのような実施形態における構成セグメント（典型的には、単一セクタまたはそれ未満）は、ユーザフラッシュアドレス空間（２４ビットプログラム空間の下位半分）内に常駐する。
【００５３】
−１つの試験セクタは、工場使用のために留保され（すなわち、非公開試験モードにおいてのみ書込可能であって、そうでなければ、常時、保護される）、デバイスＩＤ情報、デバイス較正データのための「ヒューズ」値等を含有する。本セクタはまた、典型的には、顧客のみ書き込み得る（消去不能）、「顧客ＯＴＰ」データのための単一データ列を含有する。
【００５４】
−前述のようなデュアルブート（デュアルパネル）デバイスでは、別の試験セクタが、ブート（動作）モードヒューズ値のために留保される。本セクタは、ユーザがデバイス全体を消去（チップ消去）しない限り、保護される。
【００５５】
−１つまたはそれを上回る試験セクタが、デバイス試験の間の使用のため、続いて、開発ツールによって、Ｄｅｂｕｇ  Ｅｘｅｃを保持するために留保される。これらのセクタは、公開試験モード（デバッグモード等）において書込可能である。
【００５６】
−構成セクタは、ユーザオプションを選択するための全ユーザプログラマブル「ヒューズ」を含有する。これは、選択されたコード保護レベルに基づいて、（ユーザ定義された）書込許可を有する。
【００５７】
全「ヒューズ」データは、自動的に、デバイスリセットシーケンスの一部として、フラッシュコントローラによって読み取られ、特殊デバイス構成レジスタの中にロードされる。
【００５８】
前述のように、各セグメントは、その独自のアクセスルールを有し、別のセグメントからの読取／書込アクセス（以降、「外部」アクセスと指定される）を防止し得る。さらに、セグメントへのベクトル化は、特に、高セキュリティ設定では、制限され得る。テーブルは、行われる動作のタイプに応じて、セグメント毎に設定を定義してもよく、異なる動作は、図１０により詳細に示されるように、異なるセキュリティ設定を有してもよい。セキュリティは、読取および書込／消去保護に別個に分裂されることができ、例えば、書込保護ビットは、書込保護を別個に設定するために使用されてもよい。実装は、種々の実施形態に従って変動してもよい。図８は、ブートセグメントのための３つの異なるレベルの保護を伴う実施形態を示す。図１０は、一般セグメントのための３つの異なるレベルの保護を伴う実施形態を示す。類似テーブルが、他のセグメントのために使用されてもよい。各保護レベルは、セグメントの外側からの異なるセグメントへの読取アクセスのための別個の保護を提供する。加えて、各レベルは、書込保護が設定されるかどうかを設定してもよい。ブートセグメントのための図８に示される実施形態および一般セグメントのための図１０では、第１のレベルは、読取保護を提供せず、概して、全アクセスされるセグメントに適用される。書込保護が本モードでアクティブである場合、それは全セグメントに適用され、次いで、個別のセグメントの「外側」からプログラムされることまたは消去されることができない。
【００５９】
第２のレベルは、標準的レベルとして示される。図８は、ブートセグメントのための保護を示す。本設定では、ブートセグメントは、「外側」から読み取られる、または書き込まれることができず、書込保護設定に応じて、ブートセグメント内で実行されるアクションからも書き込まれ得ない。図１０は、一般セグメントのための設定を示す。ここでは、ブートセグメントならびに一般セグメントは、一般セグメント内で読取動作を行うことができる。一般セグメントへの書込は、書込保護ビットが設定されていない場合のみ可能にされる。試験セグメント内からのいかなる動作も、一般セグメントへの読取または書込アクセスを可能にしないであろう。
【００６０】
第３のレベルは、高保護レベルとして示される。本設定では、ブートセグメントのために、標準的設定保護に加え、ブートセグメントへのベクトル化も、制限され得る。したがって、本付加的保護は、ベクトルテーブルのいかなる修正も防止し得る。しかしながら、ブートセグメントのために、保護は、標準的設定と同じであってもよい。
【００６１】
図１０は、一般セグメントのための高セキュリティ設定を示し、外側からのいかなるアクセスも、禁止される。言い換えると、一般セグメントは、一般セグメント内からのみアクセスされることができる。一般セグメントＧＳ内からの書込アクセスさえ、個別の保護ビットを設定することによって禁止され得る。
【００６２】
図１１は、別の実施形態による、アプリケーションモードにおけるセキュリティ動作に関するより詳細なテーブルを伴う実施形態をより詳細に示す。動作は、最左列下に列挙され、ＧＳ、ＢＳ、ＣＳ、およびＶＳへの対応する影響は、対応する行に示される。種々の動作が、定義される。第１のライン（セグメント内へのＰＣロールオーバー）は、別のセグメントへのプログラムカウンタロールオーバーに関する。第２のライン（セグメントへのＰＦＣ）は、ジャンプまたは分岐命令の実行等の任意のタイプのプログラムフロー変更および種々のセグメントへのその影響に関する。次のライン（ＩＶＴまたはＡＩＶＴからのベクトル）は、具体的セグメントへのベクトル化に関する。次のライン（テーブル読取／ＰＳＶ）は、セグメントへのＰＳＶまたはテーブル読取命令アクセスに関する。次のライン（ページ消去）は、個別のセグメントに影響を及ぼすであろう、ページ消去機能に関する。次のライン（行プログラム）は、メモリ行のプログラミングに関する。他のアクションは、以下の行に示される。したがって、異なる保護設定が、異なるタイプのアクションに適用されてもよい。読取および書込動作等のあるアクションは、１つのセグメント内で行われ得るが、他のセグメントにも影響を及ぼし得る。種々の実施形態による保護スキームは、これらのアクションを選択的に保護することを可能にする。インタラプトによって生じるもの等のいくつかのアクションは、それ自体、具体的セグメントから生じ得ず、したがって、図１１におけるテーブルは、それらが実行されるセグメント間で区別されない。図１１におけるテーブルは、アクションが、個別のテーブルセル内に「ＯＫ」を示すことによって許可されるか、または「Ｎｏ」または「０」のいずれかを示すことによって禁止されるかを示し、後者は、動作が「０」読取をもたらすであろうことを示す。図１１に関するいくつかの実施例は、以下である。
【００６３】
−セグメントＧＳからのＴＢＬＲＤ／ＰＳＶの実行は、ＣＰＵがセグメントＧＳセキュリティレベルに関係なく、セグメントＧＳからのデータを閲覧することを可能にするであろうが、そのセキュリティが「該当せず」に設定される場合のみ、ＣＰＵがセグメントＢＳからのデータを閲覧することを可能にするであろう。セグメントＣＳは、常時、セグメントＶＳのように読取可能である。
【００６４】
−セグメントＧＳを標的とするセグメントＢＳ内でのコード実行を使用したページ消去の試みは、セグメントＧＳ書込保護がイネーブルにされる、および／またはセグメントＧＳセキュリティが「高」である場合、失敗するであろう。以下に議論されるように、セグメントＣＳは、「高度」と呼ばれる、付加的セキュリティレベルを有することに留意されたい。
【００６５】
図１１に示されるように、種々の異なるアクションが、異なる設定に従って保護されることができ、読取および書込アクションは、別個に保護されてもよい。しかしながら、他の実装は、読取と書込を区別しなくてもよい。加えて、図１１は、構成セグメントＣＳのために、付加的セキュリティレベルが実装され得、別個の中間保護レベルを可能にし得ることを示す。
【００６６】
いくつかの実施形態によると、スレーブＰＲＡＭ４２６は、例えば、前述のように、ヒューズ回路または構成レジスタによって、ブートセグメント（ＢＳ）または一般セグメント（ＧＳ）アドレス空間のいずれかに配分されてもよい。別の実施形態によると、スレーブＰＲＡＭは、マスタセグメントＧＳセキュリティのみ継承することができる。
【００６７】
したがって、スレーブＰＲＡＭ４２６は、フラッシュメモリ４１６の対応するマスタフラッシュセグメントに割り当てられるセキュリティレベルをとるであろう。ＬＤＳＬＶ／ＶＦＳＬＶ命令実行は、ここでは、実行される個別のフラッシュ実行セグメントおよび割り当てられる個別のＰＲＡＭセグメントに敏感であるように実装される。したがって、関連付けられたコード保護セキュリティレベルは、そのような命令が実行されるときに適用される。ＬＤＳＬＶ／ＶＦＳＬＶは、したがって、ＰＲＡＭ内では、読取機能と見なされる。プログラムまたはページ消去機能およびその関連付けられたセキュリティルールのみが、フラッシュメモリに適用される。したがって、フラッシュメモリ４１６のＢＳ／ＧＳ読取のためにすでに定義されたルールもまた、以下のように、ＰＲＡＭ内で読取または書込を行うＬＤＳＬＶ／ＶＦＳＬＶ命令を使用するとき、スレーブＰＲＡＭアクセスに適用されるであろう。
ＬＤＳＬＶ／ＶＦＳＬＶは、マスタのＢＳ内から実行され、スレーブＰＲＡＭが、以下に割り当てられる場合、機能するであろう。
（１）ＢＳ（セグメントセキュリティレベルと無関係）
（２）ＧＳ（かつＧＳが「高」セキュリティレベルではない）
ＬＤＳＬＶ／ＶＦＳＬＶは、マスタのＧＳ内から実行され、スレーブＰＲＡＭが、以下に割り当てられる場合、機能するであろう。
（１）ＧＳ（セグメントセキュリティレベルと無関係）
（２）ＢＳ（かつＢＳが「該当せず」セキュリティレベルである）
【００６８】
前述の条件が満たされない場合、ＬＤＳＬＶ／ＶＦＳＬＶ実行は、影響を受けないであろう。また、他の実施形態によると、他の条件も、適用されてもよい。前述の条件は、単なる実施例にすぎない。フラッシュアクセスコード保護ルール（ソースデータ読取のため）が満たされるであろうと仮定される。
【００６９】
図９は、図８に示されるものに類似するブートセグメントのための高度コード保護スキームを示す。再び、類似テーブルが、他のセグメントのために使用されてもよい。ＰＲＡＭ４２６がマスタフラッシュメモリ４１６のブートセグメントに割り当てられる場合、したがって、マスタＢＳを任意のセキュリティレベル（すなわち、「該当せず」以外のレベル）に設定することによって、セグメントＧＳ内の信頼されないコードから保護され得る。逆に言えば、ＰＲＡＭがマスタのセグメントＧＳに割り当てられる場合、また、マスタＧＳを「高」セキュリティに設定することによって、ＢＳ内の信頼されないコードから保護され得る。
【図１】
2018514868.tif 000009
【図１Ａ】
2018514868.tif 000010
【図１Ｂ】
2018514868.tif 000011
【図２】
2018514868.tif 000012
【図３】
2018514868.tif 000013
【図４】
2018514868.tif 000014
【図５】
2018514868.tif 000015
【図６】
2018514868.tif 000016
【図７】
2018514868.tif 000017
【図８】
2018514868.tif 000018
【図９】
2018514868.tif 000019
【図１０】
2018514868.tif 000020
【図１１】
2018514868.tif 000021
【図１１Ａ】
2018514868.tif 000022
【図１１Ｂ】
2018514868.tif 000023
【図１１Ｃ】
2018514868.tif 000024
【国際調査報告】
2018514868.tif 000025
2018514868.tif 000026
2018514868.tif 000027
2018514868.tif 000028