Project cleanup
- Remove unusused files of wr core
- Eliminate 2 latches from data_engine
- Delete the svn repo: https://www.ohwr.org/project/fmc-tdc/tree/master
From: Rene Bakker [Rene.Bakker@incaacomputers.com]
Sent: 07 November 2014 10:42
To: Evangelia Gousiou
Cc: Bert Gooijer; Erik Van Der Bij; Adriaan Rijllart; Bart Sijbrandij
Subject: RE: White Rabbit TDC
>> Hello Rene,
>> Thank you very much for all the remarks.
What is btw the difference between the https://www.ohwr.org/project/fmc-tdc/tree/master accessible with SVN, which I was using before, and https://www.ohwr.org/project/fmc-tdc-1ns-5cha-gw/tree/master which is accessible with Git? If the SVN is replaced bij the Git, I think the SVN should be removed.
>> The https://www.ohwr.org/project/fmc-tdc/tree/master should actually
be deleted; it was the initial repository for all the project (including
gateware and hardware etc). Then we split the project in sub-projects
(hardware, gaterare, testing) and each sub-project has its own git
repository now.
So please, for the gateware use the git
https://www.ohwr.org/project/fmc-tdc-1ns-5cha-gw/tree/master
During the processing of the with_wrabbit project I noticed some
parsing errors:
ERROR:HDLCompiler:870 -
"/home/incaa/Work/fmc-tdc/hdl/ip_cores/wishbone/wb_lm32/src/lm32_cpu.v"
Line 155: Macro <CFG_EBA_RESET> is not defined.
ERROR:HDLCompiler:806 -
"/home/incaa/Work/fmc-tdc/hdl/ip_cores/wishbone/wb_lm32/src/lm32_cpu.v"
Line 155: Syntax error near ";".
ERROR:HDLCompiler:870 -
"/home/incaa/Work/fmc-tdc/hdl/ip_cores/wishbone/wb_lm32/src/lm32_instruction_unit.v"
Line 147: Macro <CFG_EBA_RESET> is not defined.
ERROR:HDLCompiler:806 -
"/home/incaa/Work/fmc-tdc/hdl/ip_cores/wishbone/wb_lm32/src/lm32_instruction_unit.v"
Line 147: Syntax error near ";".
ERROR:HDLCompiler:281 -
"/home/incaa/Work/fmc-tdc/hdl/ip_cores/wishbone/wb_lm32/src/lm32_top.v"
Line 29: Cannot open include file "system_conf.v".
ERROR:ProjectMgmt - 5 error(s) found while parsing design hierarchy.
Although the design can be fully placed and routed without errors, could
this have any influence on the actual functionality?
>> None of these files is actually needed in the project. On a later release I will remove those files from the project. I have actually added an issue
The design rule check of the Xilinx tools also showed some
warnings/suggestions, of which I do not know if they will have any
influence on the functionality of the tdc core.
For both the no_wrabbit and with_wrabbit project the following was
reported:
WARNING:PhysDesignRules:372 - Gated clock. Clock
net
cmp_tdc_mezz/cmp_tdc_core/data_engine_block/engine_st[3]_PWR_227_o_Mux_41_o
is sourced by a combinatorial pin. This is not good design practice. Use
the
CE pin to control the loading of data into the flip-flop.
This is probably due to the latches which are generated by XST for
time_c_en and time_c_rst within data_engine.
WARNING:Xst:737 - Found 1-bit latch for signal <time_c_en>. Latches may
be generated from incomplete case or if statements. We do not recommend
the use of latches in FPGA/CPLD designs, as they may lead to timing
problems.
WARNING:Xst:737 - Found 1-bit latch for signal <time_c_rst>. Latches may
be generated from incomplete case or if statements. We do not recommend
the use of latches in FPGA/CPLD designs, as they may lead to timing
problems.
I noticed that within process data_engine_fsm_comb these two signals
are not assigned within every state.
>> Hmm..on a later release I will also eliminate those latches.
And for the with_wrabbit project it also reported:
WARNING:PhysDesignRules:2212 - Async clocking for BRAM
(comp
U_WR_CORE/WRPC/U_Endpoint/U_Wrapped_Endpoint/U_Rx_Path/gen_with_packet_filter
.U_packet_filter/U_microcode_ram/gen_dual_clk.U_RAM_DC/Mram_ram)
port(s) with
READ_FIRST mode has certain restrictions. Make sure that there is no
address
collision. A read/write on one port and a write operation from the other
port
at the same address is not allowed. RAMB16BWER, when both ports are 18
bits
wide or smaller, A13-6 including A4 cannot be same. When any one port is
36
bits wide, A13-7 including A5 cannot be the same. Violating this
restriction
may result in the incorrect operation of the BRAM.
I do not know if this could be an issue.
>> It is not an issue; this packet filter is written/programmed only once on boot time, then it's only read.