• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Is there anyone here that can help me reduce propagation delays in my vhdl code?

cirthix

Diamond Member
I need to increase clockspeed of my project by at least 50%.

Using an ecp2m speed grade 5, I have a limit of about 100mhz for my code. I need to hit 150mhz, preferably around 170mhz. There is one value that is slowing the system down, everything else works at or above 172mhz in a worst-case situation (speed grade 5, minimum operating voltage, 105 degrees C).

It's too much code to post. If you can lend a hand, send me a PM. Thanks!
 

General guideline: Use the affected signal as far OUTSIDE of the logic hierarchy as possible.
For instance, given this equation:
G = A xor B xor C xor D xor E xor F

Suppose that signal A is late-arriving, and G is timing critical. In which case, put A on the outermost xor block, like this:
G = A xor (B xor C xor D xor E xor F)

Obviously this is a pretty simple example. The point is to try to reduce the amount of logic that your late-arriving signals have to traverse.
 
Originally posted by: cirthix
I need to increase clockspeed of my project by at least 50%.

Using an ecp2m speed grade 5, I have a limit of about 100mhz for my code. I need to hit 150mhz, preferably around 170mhz. There is one value that is slowing the system down, everything else works at or above 172mhz in a worst-case situation (speed grade 5, minimum operating voltage, 105 degrees C).

It's too much code to post. If you can lend a hand, send me a PM. Thanks!

Try optimizing for speed, manually laying out the blocks, and use as much dedicated global clock sources as you can for your system clock.
 
Paradoxically, you might also try optimizing for area. If your critical path is because of a long net, it might help.
 
I'm new to this, so I may be interpreting this incorrectly. The signal that is slow is only used after many (could be up to 4000 clocks, no less than 400 clocks) clocks, so does it even matter that the maximum clockspeed of this signal is low?
 
Originally posted by: cirthix
I'm new to this, so I may be interpreting this incorrectly. The signal that is slow is only used after many (could be up to 4000 clocks, no less than 400 clocks) clocks, so does it even matter that the maximum clockspeed of this signal is low?

Yes, it matters to the tool. Perhaps not to the design itself, but the tool has know way to know when this signal has semantic meaning and when it doesn't. All the tool sees is a long chain of logic without flip-flops in between. This is what is commonly called a 'false timing path', or just a 'false path'.

The tricky thing about false paths is they're not always functionally false paths. Sometimes they really do rely on having unity cycle time. So you should work to break this infrequently-used signal into a pipeline of sub-signals instead.

To apply this technique to the earlier xor example, compute:
B xor C, D xor E, in cycle 0
B xor C xor F, D xor E xor A, in cycle 1
A xor B xor C xor D xor E xor F, in cycle 2

Thusly, the logic in each stage of the pipeline is reduced, (hopefully) increasing the potential clock frequency of this set of nets.
 
Back
Top