Meeting timing in an fpga design can be painful at best. The pain is from the long wait times between "compiles" which by itself isnt so bad. What sucks is that (for myself atleast) you can not do anything else while its running (except rant on a blog!).
In theory you could go on and dick with the code while its running, and start multiple runs with different code/config yet in practice I`ve found multitasking like this usually ends in not knowing what you actually changed after all the compiles have finished.
As
a software guy its pretty hard to imagine wtf im talking about. Timing ?
Routing ? Mapping ? Placing ? wtf ? A more concrete version of a complete logic "compile" looks like
the pic on the the left. This is a carry chain thats 1nsec overbudget, meaning its a = b + c; for a specific bit in an integer. The particular problem here is it takes 1nsec too long because its more than a simple addition and has some other funky stuff that gives the tools problems.
It got me thinking on how do you explain what modern EDA tools do to a software guy?
An answer is; imagine your system memory is no-longer deterministic. This means if you write to address 0x1000[0] = 1; theres no guarantee a read of 0x1000[0] == 1. The only rule to getting deterministic behavior of 0x1000[0] == 1, is if the read & write instructions are close to the memory data location. Meaning the location of the CPU`s instructions in memory, must be close to memory location 0x1000 for deterministic behaviour.
If that does not sound like a raving lunatic`s version of sudoku then you can start to imagine how a compiler would look. First part is generating the correct sequence of opcodes based on the verilog/vhdl input file. After that its an optimization problem of finding the best opcodes / memory location combination to get correct read/write memory behaviour - in a finite amount of time, a NP hard problem.
And finally if you believe all of that, then its easy to make a program that compiles no problem, but is impossible to work - thus the pain of timing closure.
... atleast in some psudo hand wavy sudoku analogy.
It got me thinking on how do you explain what modern EDA tools do to a software guy?
An answer is; imagine your system memory is no-longer deterministic. This means if you write to address 0x1000[0] = 1; theres no guarantee a read of 0x1000[0] == 1. The only rule to getting deterministic behavior of 0x1000[0] == 1, is if the read & write instructions are close to the memory data location. Meaning the location of the CPU`s instructions in memory, must be close to memory location 0x1000 for deterministic behaviour.
If that does not sound like a raving lunatic`s version of sudoku then you can start to imagine how a compiler would look. First part is generating the correct sequence of opcodes based on the verilog/vhdl input file. After that its an optimization problem of finding the best opcodes / memory location combination to get correct read/write memory behaviour - in a finite amount of time, a NP hard problem.
And finally if you believe all of that, then its easy to make a program that compiles no problem, but is impossible to work - thus the pain of timing closure.
... atleast in some psudo hand wavy sudoku analogy.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.