From c207f796a80cc4c8d1ddab669ff089ca697cb185 Mon Sep 17 00:00:00 2001 From: lkcl Date: Wed, 11 Mar 2020 03:22:15 +0000 Subject: [PATCH] --- why_a_libresoc.mdwn | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/why_a_libresoc.mdwn b/why_a_libresoc.mdwn index bdbf564b0..29cdb0c61 100644 --- a/why_a_libresoc.mdwn +++ b/why_a_libresoc.mdwn @@ -4,7 +4,9 @@ Its quite hard to guarantee that performant processors (think pipelined, out-of- There are entire [dissertations](http://www.kroening.com/diss/diss-kroe.pdf) dedicated to the subject matter of merely functionally verifying a pipeline (this doesn’t even consider out of order execution). -Given the fact that performant bug-free processors no longer exist [1][2], how can you trust your processor [3]? The next best thing is to have access to a processor’s design files. Not only have access to them, you must have the freedom to study, improve them, run the test suites and be able to improve those too. Not only that, you and everyone who has a stake in the success needs to be entirely free from NDAs and other restrictions which prevent and prohibit communication. +Given the fact that performant bug-free processors no longer exist [1][2], how can you trust your processor [3]? The next best thing is to have access to a processor’s design files. Not only have access to them, you must have the freedom to study, improve them, run the test suites and be able to improve those too. + +Not only that, you and everyone who has a stake in the success needs to be entirely free from NDAs and other restrictions which prevent and prohibit communication. An example: although you yourself might not have the technical capability to review our SoC, you can always find a third party to pay wjo can. However if the source code was under NDA, do you think that would be practical to consider? *Collaboration, not competition*. -- 2.30.2