[Suzaku:02074] Re: EDK9.2→11.5移行に失敗

Nobuaki Sugishima email@hidden
2011年 2月 24日 (木) 18:34:49 JST


遅くなりましたが、Xilinx社代理店のサポートを受け解決しましたので報告します。

----- Original Message ----- 
From: "mio" <email@hidden>
To: <email@hidden>
Sent: Wednesday, January 05, 2011 10:34 AM
Subject: [Suzaku:02061] Re: EDK9.2→11.5移行に失敗


> あけましておめでとうございます。
> 中島です。
>
>> sz410です。
>>
>> EDK9.2から11.5への移行に失敗しました:
>> Base System Builderにはよらず、sz410-20100617をModifyする方法で進めました。 
>> 
>>
>> 経過:
>>
>> 1.プロジェクト起動段階
>> WARNING:EDK:1582 - IPNAME:dcr_v29 INSTANCE:dcr - prj_11\xps_proj.mhs line
>> 328 - deprecated core for architecture 'virtex4fx'!
>> WARNING:EDK:1582 - IPNAME:dcr_v29 INSTANCE:dcr -
>> prj_11\_xps_tempmhsfilename.mhs line 319 - deprecated core for 
>> architecture
>> 'virtex4fx'!
>> のwarningがでます。
>> dcr_v29には PARAMETER HW_VER = 1.00.aではなく1.00.bがあるようなのでmhs
>> ファイルを書き換えたのですが、プロジェクトが起動しなくなってしまったので
>> 元へ戻しました。
>> warningなので無視することにしました。
>>
> 11.5に1.00.bありました??
> 1.00.bに変更して起動しなくなる要素はみあたらない感じですが、
> 起動しなくなるなら、バージョンアップする必要はないと思います。
>

このWarningは無視して差し支えないそうです。



>> 2.bram_vec、xps_bram_if_cntlrを追加
>> PARAMETER C_BASEADDR = 0xFFFF0000
>> PARAMETER C_HIGHADDR = 0xFFFF3FFF
>> の定義を追加してBitstreamが生成できました。
>>
>>
>> 3.mycoreを追加
>> prj_11\pcores\xps_mycore_v1_00_a\hdl\vhdlに9.2で実績のあるmycoreを追加
>> data\のxps\proj.ucfをこれも実績のある同名ファイルで上書きの上Compile
>> その結果:
>> ERROR:Map:237 - The design is too large to fit the device. Please check 
>> the
>> Design Summary section to see which resource requirement for your design
>> exceeds the resources available in the device. Note that the number of
>> slices
>> reported may not be reflected accurately as their packing might not have
>> been
>> completed.
>>
> mhsファイルのmpmc_sz410の記述のところに以下を追記してみてください。
>
> PARAMETER C_PI0_RD_FIFO_TYPE = SRL
> PARAMETER C_PI0_WR_FIFO_TYPE = SRL
>
>> 私のやや特殊事情ですが16KBのCasheをFPGAに確保しています。殆ど
>> Slice数の増加なしに設定することができました。9.2では動作も問題な
>> いようです。
>> これがこのErrorを生んだ原因らしいです。EDKのバージョンにより通ら
>> なくなる理由をXilinxの代理店に問い合わせたのですが、bramの単位消費量
>> が違うのでそれを考慮してDesignするようにとのことでした。
>> やむなく容量を半分に落として、このErrorを回避しました。
>>


代理店によればバージョンアップによりBRAMの単位メモリーサイズが大きくなることはあり得るとのことでしたが、ご教示いただいた方法で解決しました。ありがとうございます。
多少腑に落ちないのはBRAMの問題なのにmpmc_sz410に処置を追加して解決した点です。 

評価は不十分ながら動作はしています。


>> 4.constraint error
>> 次に
>> ERROR:Pack:1653 - At least one timing constraint is impossible to meet
>> because
>> component delays alone exceed the constraint. A timing constraint summary
>> below shows the failing constraints (preceded with an Asterisk (*)).
>> Please
>> use the Timing Analyzer (GUI) or TRCE (command line) with the Mapped NCD
>> and
>> PCF files to identify which constraints and paths are failing because of
>> the
>> component delays alone. If the failing path(s) is mapped to Xilinx
>> components
>> as expected, consider relaxing the constraint. If it is not mapped to
>> components as expected, re-evaluate your HDL and how synthesis is
>> optimizing
>> the path. To allow the tools to bypass this error, set the environment
>> variable XIL_TIMING_ALLOW_IMPOSSIBLE to 1.
>> がでます。
>> そこで環境変数SETにXIL_TIMING_ALLOW_IMPOSSIBLE=1を追加しました。これは
>> constraint error
>> の判定を緩和するオプションのようです。
>> しかし効果はありません。
> 一応以下に情報はあるようですが、
> http://japan.xilinx.com/support/answers/31145.htm
> XIL_TIMING_ALLOW_IMPOSSIBLE=1
> を追加したらいいですよ、と書いてありますね・・・。
>
>> ----------------------------------------------------------------------------------------------------------
>>
>> Constraint | Check | Worst Case |
>> Best Case | Timing | Timing
>> | | Slack |
>> Achievable | Errors | Score
>> ----------------------------------------------------------------------------------------------------------
>>
>> * TS_dcm_ddr_clk_dcm_ddr_clk_CLK0_BUF = PER | SETUP | 1.080ns|
>> 3.554ns| 0| 0
>> IOD TIMEGRP "dcm_ddr_clk_dcm_ddr_clk_CLK0 | HOLD | -0.456ns|
>> | 511| 39707
>> _BUF" TS_dcm_ddr_fx_dcm_ddr_fx_CLKFX_BUF | | |
>> | |
>> HIGH 50% | | |
>> | |
>> ----------------------------------------------------------------------------------------------------------
>> *のついたスレッショルドオーバーの個所が4個あります。
>> なお、2項の段階でも1つありました。しかしこの場合はCompilerはとおしてく
>> れたようです。
>>
>> mycoreのどの個所がこのエラーを引き起こしたのか要素を削除する方法で分析に
>> かかったのですが、prj.vhd、user_logic.vhd、mycore.vhdのどこでおきたのか
>> 特定できませんでした。
>> TS_dcm_ddr_clk_dcm_ddr_clk_CLK0_BUFに関するエラーというメッセージを見て
>> いるとある特定の記述がこの結果をもたらしているのではないような感じがしま
>> す。
>> dcm_module自身あるいは他の欠陥がこのようなメッセージを引き出しているの
>> か、私には判断できません。
>>
> mycoreというのは、どのように作成したip coreでしょうか?
> あまり関係なさそうですが、もし、
> XPSに付属しているCreate and Import Peripheral Wizardで
> 作成したのならば、11.5で一回作りなおしたほうがいいかもしれません。
>
>
>> なにか気がつかれた点があればお教えください。
>>
>

原因はucfファイルにありました。
V9.2では冒頭を:
Net SYS_CLK_IN TNM_NET = SYS_CLK_IN;
TIMESPEC TS_SYS_CLK_IN = PERIOD SYS_CLK_IN 10000 ps;

#NET "ppc_reset_bus_Chip_Reset_Req" TPTHRU = "RST_GRP";
#NET "ppc_reset_bus_Core_Reset_Req" TPTHRU = "RST_GRP";
#NET "ppc_reset_bus_System_Reset_Req" TPTHRU = "RST_GRP";
#TIMESPEC "TS_RST1" = FROM CPUS THRU RST_GRP TO FFS  TIG;
#NET sys_bus_reset TIG;

# SYSTEM I/O

Net SYS_CLK_IN       LOC = Y6 | IOSTANDARD = LVCMOS33;
Net SYS_RST_IN       LOC = U3 | IOSTANDARD = LVCMOS33 | TIG;
Net FPGA_RESET_EN    LOC = U2 | IOSTANDARD = LVCMOS33;
Net BOOT_JP          LOC = W4 | IOSTANDARD = LVCMOS33;
Net nLED             LOC = T4 | IOSTANDARD = LVCMOS33;
Net CNSL_RX          LOC = Y4 | IOSTANDARD = LVCMOS33;

としていました。これをコメントアウトを消し、nLEDの誤りを修正、追加:

Net SYS_CLK_IN TNM_NET = SYS_CLK_IN;
TIMESPEC TS_SYS_CLK_IN = PERIOD SYS_CLK_IN 10000 ps;

⇒NET "ppc_reset_bus_Chip_Reset_Req" TPTHRU = "RST_GRP";
⇒NET "ppc_reset_bus_Core_Reset_Req" TPTHRU = "RST_GRP";
⇒NET "ppc_reset_bus_System_Reset_Req" TPTHRU = "RST_GRP";
TIMESPEC "TS_RST1" = FROM CPUS THRU RST_GRP TO FFS  TIG;

NET sys_bus_reset TIG;
INST "ocm_temac_cntlr/ocm_temac_cntlr/v4_emac_top/v4_emac" LOC = 
"EMAC_X0Y0";
INST "ppc405_system/ppc405_system/PPC405_ADV_i/PPC405_ADV_i" LOC = 
"PPC405_ADV_X0Y0";

# SYSTEM I/O

Net SYS_CLK_IN       LOC = Y6 | IOSTANDARD = LVCMOS33;
Net SYS_RST_IN       LOC = U3 | IOSTANDARD = LVCMOS33 | TIG;
Net FPGA_RESET_EN    LOC = U2 | IOSTANDARD = LVCMOS33;
Net BOOT_JP          LOC = W4 | IOSTANDARD = LVCMOS33;
⇒Net nLED<0>          LOC = T4 | IOSTANDARD = LVCMOS33;
Net CNSL_RX          LOC = Y4 | IOSTANDARD = LVCMOS33;

これでCompileエラーは解消しました。V9.2からの移行時ucfファイルをコピーという粗作業によりエラーが持ち込まれたようです。
9.2の時代、ucfファイルをこのように設定していた経緯は今となっては不明です。 

Compileおよび動作に関しては問題ありませんでした。

以上


> _______________________________________________
> suzaku mailing list
> email@hidden
> http://lists.atmark-techno.com/cgi-bin/mailman/listinfo/suzaku
> 




suzaku メーリングリストの案内