diff options
Diffstat (limited to 'content/zettel/1f2.md')
| -rw-r--r-- | content/zettel/1f2.md | 29 |
1 files changed, 29 insertions, 0 deletions
diff --git a/content/zettel/1f2.md b/content/zettel/1f2.md new file mode 100644 index 0000000..a0cef03 --- /dev/null +++ b/content/zettel/1f2.md @@ -0,0 +1,29 @@ ++++ +title = "Input language specification" +author = "Yann Herklotz" +tags = [] +categories = [] +backlinks = ["1f3a", "1f1"] +forwardlinks = ["1f3", "1f2a"] +zettelid = "1f2" ++++ + +The first reason a HLS tool might be seen as unreliable is because when +coming from C, the behaviour of the input is often unspecified. This +means that it can be defined by the compiler, resulting in different +behaviour in different compilers. HLS tools take great advantage of +this, to allow for hardware specific optimisations. In addition to that, +HLS tools will define various different subsets of the language that +will get compiled correctly. One example of this is that if a pointer is +used multiple times it may not be valid anymore: + +> using pointers which are updated multiple times is not recommended. +> HLS would optimize the redundant assignments. Please look at this +> section in UG902. +> +> Using pointers which are accessed multiple times can introduce +> unexpected behavior after synthesis. In the following example pointer +> d~i~ is read four times and pointer d~o~ is written to twice: the +> pointers perform multiple accesses. — nithink, Xilinx forum[^1] + +[^1]: <https://forums.xilinx.com/t5/High-Level-Synthesis-HLS/Pointer-synthesis-in-Vivado-HLS-v20-1/m-p/1117009> |