New Contributor
ContributorHi Htork,
At first remember to initialize register, seems Quartus has done for you setting them to 0.
Leaving register in an unknown state can be dangerous, when powered up state machine, counters logic can stuck in some unknown unwanted state.
About question:
always @ ( posedge (clk)) // destination register
q <= d2 & 1'b1;
endmodule
is optimized so AND removed from design, if this port added to infer delay design fail.
Question 1:
Clock come from external pin and routed through clock lanes or not. This has some fixed propagation times you can find on data sheet. The two signals are phase shifted by this fixed time.
Question 2:
Q from external pin is delayed of some amount of time related to output buffer from Q of register.
Internal signals are delayed by combinatorial propagation times and register propagation.
First register propagate 1 from input on rising edge.
Second one receive this signal delayed by register propagation time added to combinatorial propagation.
Register output change some time after active clock edge.
Combinatorial logic start propagate when one of input change asyncrounos from clock.
These delay on your image appear as they where few nS wide compared to 10nS clock, on a so simple design on Cyclon10 seems too large.
New ContributorI agree that the delay from latch edge of clock to data on register q-pin seems long.
However, since I'm new to this I have nothing to compare with, What should I expect?
What can I do to reduce the delay?
Included image is of the setup slack analysis for the path between register d1 - d2.
It seems that it is the arrival of the latch edge of the clock which is the main reason for the long delay.
The clock is connected to a clock pin on the FPGA.
The other inputs and outputs are connected to nearby pins.
