aboutsummaryrefslogtreecommitdiffstats
path: root/content.org
diff options
context:
space:
mode:
authorYann Herklotz <git@yannherklotz.com>2021-09-17 14:02:18 +0100
committerYann Herklotz <git@yannherklotz.com>2021-09-17 14:04:59 +0100
commit5267842354c708b8817d8ef24516f36aabda5a89 (patch)
tree7e1a8b359bab4cd4bc17e4dd51c277cf62b7de25 /content.org
parentb4b42c6a8ef60a9d7779f74d12ba4126eede372b (diff)
downloadyannherklotz.com-5267842354c708b8817d8ef24516f36aabda5a89.tar.gz
yannherklotz.com-5267842354c708b8817d8ef24516f36aabda5a89.zip
Fix links in content.org
Diffstat (limited to 'content.org')
-rw-r--r--content.org43
1 files changed, 20 insertions, 23 deletions
diff --git a/content.org b/content.org
index b688b0c..e62b0b8 100644
--- a/content.org
+++ b/content.org
@@ -658,7 +658,7 @@ hardware using FPGAs.
The workshop also included two poster sessions, and all the attendees presented the current projects
that were being worked. These were also quite varied and included projects from various universities
and also covered topics from optical circuits and storage to custom hardware and FPGAs. I presented
-our work on {{{link([[/blog/2019-06-19-verismith.html][Verismith]],[[#verismith][Verismith]])}}}, our Verilog synthesis tool fuzzer.
+our work on {{{link([[/2019/06/verismith/][Verismith]],[[#verismith][Verismith]])}}}, our Verilog synthesis tool fuzzer.
I would like to thank Shane Fleming for inviting us to the workshop, and also thank all the
organisers of the workshop.
@@ -849,15 +849,12 @@ that were found can be seen in the [[https://github.com/ymherklotz/verismith/tre
:END:
The following resources provide more context about Verismith:
-- [[/docs/fpga2020/verismith_paper.pdf][Verismith FPGA '20 paper]]
-- [[/docs/fpga2020/verismith_thesis.pdf][Verismith thesis]]
-- [[/docs/fpga2020/verismith_slides.pdf][Verismith slides]]: Presented
- to the Circuits and Systems group at Imperial College on the
- 01/07/2019 and at FPGA '20 on 25/02/2020.
-- [[/docs/msrphd2019/verismith_poster.pdf][Verismith poster]]: Presented
- at the
- [[https://www.microsoft.com/en-us/research/event/phd-workshop-on-next-generation-cloud-infrastructure/][Microsoft
- Research PhD Workshop]] on 25/11/2019.
+- {{{link([[/docs/fpga2020/verismith_paper.pdf][Verismith FPGA '20 paper]],[[./static/docs/fpga2020/verismith_paper.pdf][Verismith FPGA '20 paper]])}}}
+- {{{link([[/docs/fpga2020/verismith_thesis.pdf][Verismith thesis]],[[./static/docs/fpga2020/verismith_thesis.pdf][Verismith thesis]])}}}
+- {{{link([[/docs/fpga2020/verismith_slides.pdf][Verismith slides]],[[./static/docs/fpga2020/verismith_slides.pdf][Verismith slides]])}}}: Presented to the Circuits and Systems group at
+ Imperial College on the 01/07/2019 and at FPGA '20 on 25/02/2020.
+- {{{link([[/docs/msrphd2019/verismith_poster.pdf][Verismith poster]],[[./static/docs/msrphd2019/verismith_poster.pdf][Verismith poster]])}}}: Presented at the [[https://www.microsoft.com/en-us/research/event/phd-workshop-on-next-generation-cloud-infrastructure/][Microsoft Research PhD Workshop]] on
+ 25/11/2019.
** Realistic Graphics :graphics:
:PROPERTIES:
@@ -884,25 +881,25 @@ every point on the sphere is used to get it's colour. As a simplification, the s
be a perfect mirror, so that one reflection vector is enough to get the right colour.
#+caption: *Figure 1*: Urban latitude and longitude map.
-[[/images/realistic-graphics/urbanEM_latlong.jpg]]
+{{{link([[/images/realistic-graphics/urbanEM_latlong.jpg]],[[./static/images/realistic-graphics/urbanEM_latlong.jpg]])}}}
The latitude longitude map was created by taking a photo of a mirror ball and mapping the spherical
coordinates to a rectangle.
#+caption: *Figure 2*: Normals calculated on a sphere.
-[[/images/realistic-graphics/normal.jpg]]
+{{{link([[/images/realistic-graphics/normal.jpg]],[[./static/images/realistic-graphics/normal.jpg]])}}}
The first step is to calculate the normals at every pixel using the position and size of the
sphere. These can be visualised by setting the RGB to the XYZ of the normal at the pixel.
#+caption: *Figure 3*: Reflection vectors calculated on a sphere.
-[[/images/realistic-graphics/reflect.jpg]]
+{{{link([[/images/realistic-graphics/reflect.jpg]],[[./static/images/realistic-graphics/reflect.jpg]])}}}
The reflection vector can then be calculated and visualised in the same way, by using the following
formula: $r = 2 (n \cdot v) n - v$.
#+caption: *Figure 4*: Final image after indexing into the latitude longitude map using reflection vectors.
-[[/images/realistic-graphics/final.jpg]]
+{{{link([[/images/realistic-graphics/final.jpg]],[[./static/images/realistic-graphics/final.jpg]])}}}
The reflection vector can be converted to spherical coordinates, which can in turn be used to index
into the lat-long map. The colour at the indexed pixel is then set to the position that has that
@@ -919,18 +916,18 @@ iterations, the lights are placed in the centroid of each region. Below is an e
splits, meaning there are 2^6 = 64 partitions.
#+caption: *Figure 5*: Latitude longitude map of the Grace cathedral.
-[[/images/realistic-graphics/grace_latlong.jpg]]
+{{{link([[/images/realistic-graphics/grace_latlong.jpg]],[[./static/images/realistic-graphics/grace_latlong.jpg]])}}}
The average colour of each region is assigned to each light source that was created in each region.
#+caption: *Figure 6*: After running the median cut algorithm for 6 iterations.
-[[/images/realistic-graphics/median_cut6.jpg]]
+{{{link([[/images/realistic-graphics/median_cut6.jpg]],[[./static/images/realistic-graphics/median_cut6.jpg]])}}}
Finally, these discrete lights can be used to light diffuse objects efficiently, by only having to
sample a few lights.
#+caption: *Figure 7*: The radiance at each individual sample.
-[[/images/realistic-graphics/median_cut_radiance6.jpg]]
+{{{link([[/images/realistic-graphics/median_cut_radiance6.jpg]],[[./static/images/realistic-graphics/median_cut_radiance6.jpg]])}}}
** Jekyll to create a portfolio website :web:
:PROPERTIES:
@@ -1326,7 +1323,7 @@ files on the fly and runs them. The image above shows a possible basic setup for
in this case is the Mips I processor.
#+caption: Mips processor layout.
-[[/images/mips_processor_pipeline.jpg]]
+{{{link([[/images/mips_processor_pipeline.jpg]],[[./static/images/mips_processor_pipeline.jpg]])}}}
A processor also has to be able to store information to be able to execute these
instructions. Normally, processors have a small number of registers that are suited for this
@@ -1376,7 +1373,7 @@ normally done to transform a higher level language such as C, into a lower level
assembly.
#+caption: Compiler Workflow
-[[/assets/img/compiler_flow.svg]]
+{{{link([[/assets/img/compiler_flow.svg]],[[./static/assets/img/compiler_flow.svg]])}}}
**** Project
:PROPERTIES:
@@ -1459,7 +1456,7 @@ The three main parts of the project were
The custom music sheet is a grid which represents different notes that are to be played.
#+caption: Custom music sheet as a grid.
-[[/images/A4Grid.jpg]]
+{{{link([[/images/A4Grid.jpg]],[[./static/images/A4Grid.jpg]])}}}
The notes are encoded in binary in each column using 5 bits which allows for 32 different
pitches. The grid supports 32 different notes that are played sequentially.
@@ -1470,16 +1467,16 @@ histogram of intensities vertically and horizontally. Below is an example of thi
twinkle twinkle little star as an example.
#+caption: Horizontal histogram.
-[[/images/cut_hist_horiz.jpg]]
+{{{link([[/images/cut_hist_horiz.jpg]],[[./static/images/cut_hist_horiz.jpg]])}}}
#+caption: Vertical histogram.
-[[/images/cut_hist_vert.jpg]]
+{{{link([[/images/cut_hist_vert.jpg]],[[./static/images/cut_hist_vert.jpg]])}}}
The maximum was then used to as a threshold value to determine the individual notes and where the
stave lines and notes were located.
#+caption: Notes detected and turned grey
-[[/images/pitch_detect.jpg]]
+{{{link([[/images/pitch_detect.jpg]],[[./static/images/pitch_detect.jpg]])}}}
The grid can then be generated by encoding the pitch of the note as a 5 bit binary number and
drawing the grid.