You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When building the bitstream for R5 (using make bin/mega65r5.bit) I notice in Vivado's synthesis log:
CRITICAL WARNING: [Common 17-165] Too many positional options when parsing 'eth_clock', please type 'create_clock -help' for usage info. [/home/mike/git/MEGA65/mega65-core/src/vhdl/mega65r5.xdc:544]
WARNING: [Vivado 12-627] No clocks matched 'eth_rx_clock'. [/home/mike/git/MEGA65/mega65-core/src/vhdl/mega65r5.xdc:545]
The reason seems to be the use of an incorrect character for the dash/hyphen in the constraint file.
The line in the constraint file is
Note the subtle change of the glyph used for the dash/hyphen!
When trying this change, I see the critical warning goes away as expected. However, instead I get a large number of timing violations. The biggest timing violation is a Clock Domain Crossing from eth_rx_clock to clock200, where the slack is -9 ns.
I suggest reviewing the various clocks used in the system, and the associated constraints. The clock summary from Vivado shows the following table:
This shows that the clock eth_rx_clock is independent from all the other clocks. However, that I think is wrong. The clock eth_rx_clock is connected to the top level port eth_clock, which is an output, i.e. generated by the FPGA. It therefore seems more reasonable that eth_rx_clock should be constrained using a create_generated_clock command.
The text was updated successfully, but these errors were encountered:
When building the bitstream for R5 (using
make bin/mega65r5.bit
) I notice in Vivado's synthesis log:The reason seems to be the use of an incorrect character for the dash/hyphen in the constraint file.
The line in the constraint file is
However, it should instead be:
Note the subtle change of the glyph used for the dash/hyphen!
When trying this change, I see the critical warning goes away as expected. However, instead I get a large number of timing violations. The biggest timing violation is a Clock Domain Crossing from
eth_rx_clock
toclock200
, where the slack is -9 ns.I suggest reviewing the various clocks used in the system, and the associated constraints. The clock summary from Vivado shows the following table:
This shows that the clock
eth_rx_clock
is independent from all the other clocks. However, that I think is wrong. The clocketh_rx_clock
is connected to the top level porteth_clock
, which is an output, i.e. generated by the FPGA. It therefore seems more reasonable thateth_rx_clock
should be constrained using acreate_generated_clock
command.The text was updated successfully, but these errors were encountered: