guruguru123’s diary

かなり雑な作業日記です。

ゲーテッドクロックからクロックイネーブル付きへの変更練習

以前、ゲーテッドクロックをイネーブル付きのものに置き換えるというようなことを言っていた。そこでゲーテッドクロックをクロックイネーブルに変更していくための練習をした。

まずはゲーテッドクロックになってしまう例を作成。

entity clock_pra is
port(
clk : in std_logic;
D : in std_logic;
Q : out std_logic;
a : in std_logic;
b : in std_logic
);
end clock_pra;

architecture Behavioral of clock_pra is
signal dbuf : std_logic;
signal c : std_logic;

begin
c <= (clk and a and b);
process (clk) begin
if c' event and c = '1' then
dbuf <= D;
end if;
end process;

Q <= dbuf;

end Behavioral;

f:id:guruguru123:20170313153038p:plain

RTL Schematicを見るとクロックがAND回路の出力になっていることがわかる。

次にイネーブルのものを作成。

entity clock_pra is
port(
clk : in std_logic;
d_i : in std_logic;
Q : out std_logic;
a : in std_logic;
b : in std_logic
);
end clock_pra;

architecture Behavioral of clock_pra is
signal dbuf : std_logic;
signal c : std_logic;
signal D : std_logic;

begin
c <= (a and b);

process(c,d_i,dbuf) begin
if c = '1' then
D <= d_i;
else
D <= dbuf;
end if;
end process;

process (clk) begin
if clk' event and clk = '1' then
dbuf <= D;
end if;
end process;

Q <= dbuf;

end Behavioral;

f:id:guruguru123:20170313153508p:plain

こちらはクロックがそのまま用いられており、AND出力がイネーブルとして用いられている。また、以下のようなパターンでも同様な回路が構成される。

architecture Behavioral of clock_pra is
signal dbuf : std_logic;
signal c : std_logic;

begin
c <= (a and b);

process (clk,c) begin
if clk' event and clk = '1' then
if c = '1' then
dbuf <= D;
end if;
end if;
end process;

Q <= dbuf;

end Behavioral;

f:id:guruguru123:20170313153805p:plain

以下参考にしたサイト

https://japan.xilinx.com/support/documentation/sw_manuals_j/xilinx11/sim.pdf

https://japan.xilinx.com/support/answers/51737.html

 

Papilio Pro上にRAMを構成(4)

RS232C通信を用いてきてうまくいかないため、問題点をはっきりさせるために、いったんRS232C通信での出力の確認をやめた。代わりに出力の下位4bitをIOピンから1bitずつ出力して、目視による確認ができるようなものを作っていく。

製作していく中で以下のような問題点が見つかった。
・タイミング制御部のミス
ゲーテッドクロックの除去

内部構成RAMについては、問題なく動作していることが確認できたため、修正すべき点はクロック周りだけである。調べつつ進めていきたい。

Papilio Pro上にRAMを構成(3)

前回までは、読み出しまでが終わったタイミングでRS232C通信を開始していたが、今回は1秒ごとに

RAM制御→RS232C:DATA1→RS232C:DATA→RS232C:DATA1→RS232C:DATA2

でまたRAM制御に戻すようなものに改良してみた。

最初に以下のようにしてみた。

RAM制御→RS232C:DATA1→RAM制御→...

出力がうまく得られなかったのだが、それに加えてRS232Cの出力が、RS232Cへのデータ入力をRAMからの読み出しデータにすると1秒間隔で出てくるので、おかしいことになっていた。試しにRS232Cへのデータ入力を直接入力すると、ちゃんと2秒おきに出力が出てくる。

 

今後はこちらの方式で進めていきたい。

Papilio Pro上にRAMを構成(2)

SDRAMコントローラとなるべく同じような動作をするようにRAMコントローラを作ってみた。動作させたところ、目的の信号が出てはいるのだが動作が不安定であった。その理由がわからないため、テストベンチを作るなどして原因を考えて行きたい。

以下、動作確認時の信号のキャプチャ。

f:id:guruguru123:20170120172751p:plain

Papilio Pro 上にRAMを構成

SDRAMで行き詰っていたところ、ISEのBlock Memory Generatorで内部RAMを作って試してみたらと、アドバイスを頂いたので試してみた。

http://www.hmwr-lsi.co.jp/fpga/fpga_5.htm

こちらのサイトを参考にとりあえず構成をしてみた。

Block Memory Generatorがところどころバージョンアップに伴う変更があり、このサイト通りではなかったものの構成することができた。また、コンポーネントとして組み込むこともできた。

f:id:guruguru123:20161209220727p:plain

f:id:guruguru123:20161209220731p:plain

f:id:guruguru123:20161209220733p:plain

今回構成したのはDual Port RAMだったが、今回用いるのはSingle Port RAMでいいと思う。そこで、次回はSingle Port RAMを構成して動作テストをしていきたい。

SDRAMを用いてのAD9851への書き込み

SDRAMコントローラがとりあえずできたので、以前作ったAD9851ドライブ機構と合わせてみようとした。しかし、以前はVelirog hdlを用いていたため、また、ZPUinoに組み込んでいたため、信号部分等の変更が面倒だった。そこで新しくDDSドライブ部をつくり、組み込んだ。今回は、40bitのデータ生成は考えず(浮動小数点計算をさせるブロックを作っていないため)既存のデータを読み出して書き込むような機能にした。f:id:guruguru123:20161026181347p:plain

周波数設定ワードは32bitだが今回使用するSDRAMは1つのアドレスに16bitまで格納するので、バースト長2で書き込み、読み出しをするようにした。一通り作って出力を確認してみたが正しく動作していない。

考えられる原因はプリチャージ動作の不足かバーストでの動きをきちんと記述できていないかだ。

どこが原因かわからないのでテストベンチを作成した。以下シミュレーション結果。黄色い線までが初期設定、黄色い線より後ろが書き込み、読み出し動作となっている。

これを見る限りでは正しく動作している気がするのだが動いてくれない。

f:id:guruguru123:20161124225728p:plain

f:id:guruguru123:20161124225847p:plain

解決出来次第この記事を更新する。

 

Papilio Pro基板上SDRAMの利用(10)

前回に引き続き、一秒間隔の信号に従ってSDRAMへデータを書き込み、その書き込んだアドレスからデータを読み出す。そのデータをRS232C通信でPC上に表示させ、ここまで終わったら次の立ち上がり信号を待機する。というSDRAMコントローラの製作。f:id:guruguru123:20161020181008p:plain

前回、RS232C部分のエラーを改善したため、今回は各部分を接続して動作させてみた。しかし、SDRAMコントローラの開始、終了とRS232C通信の開始、通信がうまくかみ合っていなかったため、そこの改善からはじめた。無駄にタイミング信号をつけすぎていたため、その辺をまとめて、わかりやすくしたところ正しく動作した。以下は動作させたときのPC表示と入力データ。これを見ると正しく出力を得られていることがわかる。

f:id:guruguru123:20161020181011p:plain

 

しかし、今回は一秒ごとに起動→アクティブ→書き込み→読み出しとしたのでこのままでは高速化は望めない(今回の方式では17clk必要で、0.5μ秒)。これからは、リフレッシュ機能をちゃんと作り、バースト読み出しを2アドレスできるようにする。目標は40bitのデータを1μ秒以下での読み出しだ。

また、データを複数用意して、時間変化に伴ってそれらを書き込むアドレスを変えたときに正しく動作するのかも実験していきたい。