index.xml


1
2
3
4
5
6
7
8

<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Vericert</title><link>https://vericert.ymhg.org/</link><description>Recent content on Vericert</description><generator>Hugo -- gohugo.io</generator><language>en-uk</language><copyright>© 2020-2021 Yann Herklotz</copyright><atom:link href="https://vericert.ymhg.org/index.xml" rel="self" type="application/rss+xml"/><item><title>Building Vericert</title><link>https://vericert.ymhg.org/docs/building/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://vericert.ymhg.org/docs/building/</guid><description>To build Vericert, the provided Makefile can be used. External dependencies are needed to build the project, which can be pulled in automatically with nix using the provided default.nix and shell.nix files.
The project is written in Coq, a theorem prover, which is extracted to OCaml so that it can then be compiled and executed. The dependencies of this project are the following:
Coq: theorem prover that is used to also program the HLS tool.</description></item><item><title>Coq Style Guide</title><link>https://vericert.ymhg.org/docs/coq-style-guide/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://vericert.ymhg.org/docs/coq-style-guide/</guid><description>This style guide was taken from Silveroak, it outlines code style for Coq code in this repository. There are certainly other valid strategies and opinions on Coq code style; this is laid out purely in the name of consistency. For a visual example of the style, see the example at the bottom of this file.
Code organization # Legal banner # Files should begin with a copyright/license banner, as shown in the example above.</description></item><item><title>Future Work</title><link>https://vericert.ymhg.org/future/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://vericert.ymhg.org/future/</guid><description>This section contains future work that should be added to Vericert to make it into a better high-level synthesis tool.
The next interesting optimisations that should be looked at are the following:
globals, type support, memory partitioning, and loop pipelining. Globals # Globals are an important feature to add, as have to be handled carefully in HLS, because they have to be placed into memory, and are often used in HLS designs.</description></item><item><title>Unreleased Features</title><link>https://vericert.ymhg.org/docs/unreleased/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://vericert.ymhg.org/docs/unreleased/</guid><description>The following are unreleased features in Vericert that are currently being worked on and have not been completely proven correct yet. Currently this includes features such as:
scheduling, operation chaining, if-conversion, and functions. This page gives some preliminary information on how the features are implemented and how the proofs for the features are being done. Once these features are properly implemented, they will be added to the proper documentation.</description></item><item><title>Using Vericert</title><link>https://vericert.ymhg.org/docs/using-vericert/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://vericert.ymhg.org/docs/using-vericert/</guid><description>Vericert can be used to translate a subset of C into Verilog. As a simple example, consider the following C file (main.c):
void matrix_multiply(int first[2][2], int second[2][2], int multiply[2][2]) { int sum = 0; for (int c = 0; c &amp;lt; 2; c++) { for (int d = 0; d &amp;lt; 2; d++) { for (int k = 0; k &amp;lt; 2; k++) { sum = sum + first[c][k]*second[k][d]; } multiply[c][d] = sum; sum = 0; } } } int main() { int f[2][2] = {{1, 2}, {3, 4}}; int s[2][2] = {{5, 6}, {7, 8}}; int m[2][2] = {{0, 0}, {0, 0}}; matrix_multiply(f, s, m); return m[1][1]; } It can be compiled using the following command, assuming that vericert is somewhere on the path.</description></item></channel></rss>