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
Related to allowing global variables to be top level inputs or outputs #123
Allow special clock enable and reset signals marked this way too maybe?
Otherwise, work around like in the graphics repo work - simply using a MAIN top level input port ex. pixel(uint1_t clock) that renders a pixel_clock input wire and marking it with the CLK_MHZ pragma as a clock doesnt work for all tools:
During internal runs of the tool all inputs have registers so timing paths are all sync. In this case the input clock is registered using itself as a clock and weird things happen...
At least apparently for some tools like Quartus, which, similar to #137, seem unable to use get_nets for the internal net name that isn't registered as the source of the clock for create_clock in the timing constraints. The internal clock net is also connected as an output port. Quartus can apply a clock to this output port with get_ports - but the clock constraint does not reach the interior of the design - internal registers,etc that are using the internal 'copy' of the clock wire are all still unconstrained/not reached by the output port create clock constraint.
Vivado however is able to define a proper internal clock net usingcreate_clock with get_nets on the intended top level clock signal (and seems to ignore preceding funny clock input register business).
The text was updated successfully, but these errors were encountered:
JulianKemmerer
changed the title
Allowing global variables to be marked defined as top level clock inputs
Allowing global variables to be marked as top level clock inputs
Oct 27, 2022
Related to allowing global variables to be top level inputs or outputs #123
Allow special clock enable and reset signals marked this way too maybe?
Otherwise, work around like in the graphics repo work - simply using a
MAIN
top level input port ex.pixel(uint1_t clock)
that renders apixel_clock
input wire and marking it with the CLK_MHZ pragma as a clock doesnt work for all tools:During internal runs of the tool all inputs have registers so timing paths are all sync. In this case the input clock is registered using itself as a clock and weird things happen...
At least apparently for some tools like Quartus, which, similar to #137, seem unable to use
get_nets
for the internal net name that isn't registered as the source of the clock forcreate_clock
in the timing constraints. The internal clock net is also connected as an output port. Quartus can apply a clock to this output port withget_ports
- but the clock constraint does not reach the interior of the design - internal registers,etc that are using the internal 'copy' of the clock wire are all still unconstrained/not reached by the output port create clock constraint.Vivado however is able to define a proper internal clock net using
create_clock
withget_nets
on the intended top level clock signal (and seems to ignore preceding funny clock input register business).The text was updated successfully, but these errors were encountered: