Far too little information in the question, but...
if that 19ns path is a pure combinational critical path, then yes the clock period must be greater than 19ns.
Another way of looking at it : an overall circuit latency of 19ns and a clock period of 7 ns implies 2 pipeline registers in that 19ns path. (delay between 2 and 3 clock cycles).
Note there are pitfalls synthesising pipelined circuits... here's one, which is my best guess given the scant information...
Clock constraints only cover paths between source registers and destination registers. It looks as if - in your example - the longest path between one register and another is 7 ns, allowing that as your clock period.
It does NOT cover paths from:
- an input port to a register
- a register to an output port
- an input directly to an output bypassing all registers.
These CAN be addressed by a more complex set of constraints, but if you are working on a module internal to the FPGA (part of a hierarchical design or a reusable component) there's a simpler way:
create a wrapper entity to instantiate the block under test. In the wrapper, register every input to the block, and every output from it - and clock these registers from the same clock as your pipeline.
This way, every I/O path into or out of the block is covered by the clock constraint and you will likely find your 19ns path is either
- optimised better to meet the fast clock constraint
- reported as a timing violation because it can't meet that clock constraint
- imposes a lower clock frequency at which this long path will meet timings
or possibly some combination of the above.
Now it is up to you to re-pipeline until you meet your goals.
There is a related problem for actual I/O pins to the FPGA device. These have their own delays, which can be mitigated with registers in the IOBs themselves. (Then you find relatively long routing delays from the more remote pins to the actual logic : in extreme cases you may need an additional pipeline stage to hide that delay from your pipelined logic).
Re: Edited question:
I don't know where your A and B registers are in the design, or how you manage to make a multiplier as slow as 19 ns, or why you aren't using an FPGA with DSP blocks purpose built for this task (and 10-20x faster). But if A,B and P are internal to your MAC and clocked off the same clock, yes you should see a clock period that covers the multiply.
How do you know the mult is really 19 ns? Have you examined the slowest path covered by the 7ns clock? Does that path actually run through the multiplier?
Is it possible you measured 19ns from IOB through mult to IOB in isolation (with no registers)? (There are synthesis options to allow testing blocks in isolation, without inserting IOBs.)
In that case it may be that eliminating the IOBs (and their delays!) and inserting the mult between A,B and P registers allowed a more optimal synthesis and placement, and actually meets a more reasonable 7 ns. But that again is speculation.
You'll have to learn to read the timing reports. and track the longest path from source register to destination register through the combinational logic in between.