--- Quote Start ---
kaz and ak6dn:
Thank you so much for your help; this is much appreciated!
1. To resolve the timing issues, I had to create an instance of the multiplier using the megawizard IP. The inputs were both 64 bit, and the output was 128 bits. The IP was set to have a pipeline of 4 clock cycles.
2. The multicycle path constraint works well to remove some timing issues. The description given by ak6dn is good and I've learned much from this.
Apparently the recommended HDL coding style (page 12-4,
https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/hb/qts/qts_qii5v1.pdf) for an inferred multiplier does not work well in all situations (particularly for a high clock frequency) and cannot be easily extended beyond 2 clock cycles.
So once again, thank you. The timing issue is resolved.
By the way, the regs within the unsigned_mult64 module should be unsigned rather than signed.
--- Quote End ---
Glad it is sorted out. Yes inference lacks certain internal features and most old style designers do not like inference unlike new comers who want portable code (so called).
Regarding multicycle you need care to define your case. If output stream is delayed relative to input stream but data rate is as clock rate then multicycle does not apply even if your output stream is delayed terribly. if input rate and hence output rate is a regular fraction of clock rate then yes but even then you need to control phase of sampling clock such as by using clk enable.
Honored Contributor
