How are timing assignments set?

[Altera_Forum]

I have a signal which is very slow to change to the new value each clock cycle. Can I solve this problem with timing assignments? If so, how? 

 I have a case statement similar to the one below:  always @* case (b)  0 : c <= d0;  1 : c <= d1;  2 : c <= d2;  3 : c <= d3; endcase  b is the output of a register that changes immediately on the rising edge of the clock like it should. But c doesn't start changing until nearly an entire clock cycle after b changes. When it does start to change, it takes about half a clock cycle to settle to its new value. Although they are not all stable at the same time, d0 is stable well before b becomes 0, d1 is stable well before b becomes 1, et cetera.  I think that there might be some way to get c to update immediately upon d changing using timing assignments, but I don't know how to do this.   Can I solve this problem with timing assignments and if so, how do I implement a timing assignment? I have never implemented a timing assignment before and cannot find any documentation that explains how to do it.  Also, could I use timing assignments to solve the c-is-slow-to-settle-to-d problem?  I am using Quartus II 5.0 and the clock frequency is 80 MHz.

[Altera_Forum]

What you're seeing is the combinatory propagation delay from "b" to "c", through the logic that implements it. 

 There's no way to make it instantaneous; but sometimes, it can be made faster. You can try to set the synthesis and fitter options set to "speed", instead of area or balanced.  You can also try to use a more modern version of Quartus and use TimeQuestl, instead of the Classic Timing Analyzer.  And of course, you can try to figure out why the combinatory path is so long and see if there's a shorter way.

[Altera_Forum]

How I imagine the synthesizer would implement this is with a multiplexer. Therefore, the combinational logic should be very simple. So, I don't understand why it takes so long to settle. I can't think of any other logic that would be faster. 

 What's stranger to me, however, is the amount of time it takes for c to even begin to change from dn to dn+1. It's about 10 ns which means that the signal b must be taking a route of about 3 metres. 3 metres in a chip that is about a square inch in size! Unless for some reason the signal does not travel at the speed of light.  This last problem could be solved by somehow forcing the fitter to choose a shorter route. I had guessed that this is what timing assignments did. But are you saying that timing assignments cannot be used to solve my problem? Your sole suggestion seems like something that would simply tell the fitter to make all routes shorter rather than singling out a single problematic path.

[Altera_Forum]

--- Quote Start ---  How I imagine the synthesizer would implement this is with a multiplexer. Therefore, the combinational logic should be very simple. So, I don't understand why it takes so long to settle. I can't think of any other logic that would be faster.  --- Quote End ---   This is what I'd say as well. Are b, and d* registers?    --- Quote Start ---  What's stranger to me, however, is the amount of time it takes for c to even begin to change from dn to dn+1. It's about 10 ns which means that the signal b must be taking a route of about 3 metres. 3 metres in a chip that is about a square inch in size! Unless for some reason the signal does not travel at the speed of light.  --- Quote End ---    The electrical field travels at speed of light. Though the speed of light in sillicon dioxide is slower than in vacuum. But that's a minor issue.  The big issue is that the transistors take time to change state. That is the main contributor to the propagation delay. Since you're using a very old Quartus, I assume you're also dealing with a very old FPGA/CPLD. A 10 ns delay even for such simple logic does not look too surprising.    --- Quote Start ---  This last problem could be solved by somehow forcing the fitter to choose a shorter route. I had guessed that this is what timing assignments did. But are you saying that timing assignments cannot be used to solve my problem? Your sole suggestion seems like something that would simply tell the fitter to make all routes shorter rather than singling out a single problematic path.  --- Quote End ---    Your thinking is correct. Quartus does have timing driven synthesis and fitting: you specify timing constraints and the software tries to optimize the design as much as needed until your constraints are met. And this is the default approach nowadays.  But with such an old version as 5.0.. IIRC it doesn't work so well. That's why I suggested a more modern Quartus and TimeQuest.

[Altera_Forum]

--- Quote Start ---  Are b, and d* registers?  --- Quote End ---    b is a register. d is not.    --- Quote Start ---  Quartus does have timing driven synthesis and fitting: you specify timing constraints and the software tries to optimize the design as much as needed until your constraints are met.  --- Quote End ---    So, how would I specify a timing constraint that would force c to change to d within, let's say, 5 ns of b changing?