luke
/
prjxray
mirror of https://github.com/openXC7/prjxray.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

timfuz: update readme 

Signed-off-by: John McMaster <johndmcmaster@gmail.com>
This commit is contained in:
John McMaster 2019-01-10 16:00:57 +01:00
parent dff1402dfa
commit 9fdd4fab86
1 changed files with 26 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
fuzzers/007-timing/README.md
View File

@ -174,24 +174,32 @@ At a high level, the above learnings gave this process:
- Group delays map onto the group pivot variable, typically setting other elements to 0 (if the processed set is not the one used to create the pivots they may be non-zero) - Group delays map onto the group pivot variable, typically setting other elements to 0 (if the processed set is not the one used to create the pivots they may be non-zero)
## TODO ## TODO, suggestions
Milestone 1 (MVP) Includes
* DONE * Consider removing rref
* Provide any process corner with at least some of the fabric - Intended to understand what can't be solved, maybe not useful in production
* Need more coverage
Milestone 2 - Consider instrumenting all fuzzers to output data to feed into timing anlayzer
* Provide all four fabric corners - Justification: we need a lot of weird cases, we have code that does that in the other fuzzers
* Simple makefile based flow * Tune performance parameters
* Cleanup/separate fabric input targets - Can we improve quality of results?
- Do we have a good enough quality checker? (solve_qor.py)
Milestone 3 - Compare our vs Xilinx output on random designs
* Create site delay model - Does the solve take too long? What could speed it up?
* Investigate min corner
Final - Tends to solve towards 0, making this not useful
* Investigate ZERO - Low priority: most designs just close timing with setup time
* Investigate virtual switchboxes * Investigate characterizing full RC timing model
* Compare our vs Xilinx output on random designs * Can we split pivot delays among elements instead of entirely into pivot?
* Consider breaking out timing analyzer into its own project / library so it can be re-used on other projects
* Review "--massage". Does this help?
* Review computed site delays vs published Xilinx numbers (DC and AC Switching Characteristics)
* Fabric delay models are RC, but are the site delay models RC as well or maybe just linear?
* Can we create antenna nets to get simpler solves?
* Can we get tcl timing analyzer to analyze a partial route?
- Option says you should be able to do this
- I could not actually get it to work
### Improve test cases ### Improve test cases
@ -206,7 +214,7 @@ At a minimum these should be moved to their own directory.
Background: there are a number of speed models with the name ZERO in them. Background: there are a number of speed models with the name ZERO in them.
These generally seem to be zero delay, although needs more investigation. These generally seem to be zero delay, although needs more investigation.
Example: see virtual switchbox item below Example: see pseudo pip item below
The timing models will probably significantly improve if these are removed. The timing models will probably significantly improve if these are removed.
In the past I was removing them, but decided to keep them in for now in the spirit of being more conservative. In the past I was removing them, but decided to keep them in for now in the spirit of being more conservative.