From 90d9d9b928aeed78e7dff9de6c0de8dea36cf668 Mon Sep 17 00:00:00 2001 From: lkcl Date: Fri, 22 Nov 2019 19:16:25 +0000 Subject: [PATCH] --- nlnet_2019_coriolis2/questions.mdwn | 65 ++++++++++++++++++++++++++++- 1 file changed, 64 insertions(+), 1 deletion(-) diff --git a/nlnet_2019_coriolis2/questions.mdwn b/nlnet_2019_coriolis2/questions.mdwn index c49b4ded8..c7b006012 100644 --- a/nlnet_2019_coriolis2/questions.mdwn +++ b/nlnet_2019_coriolis2/questions.mdwn @@ -1,4 +1,67 @@ # Questions -TODO +Dear Jean-Paul and Luke, + +you applied to the 2019-10 open call from NLnet. We have some questions +regarding your project The Libre-RISCV SoC, Coriolis2 ASIC Layout +Collaboration. + +Can you provide a breakdown of the amount requested? We understand there +are a number of different tasks you will undertake, but we need to +understand the cost composition of the proposal. + +Are Coriolis2 python bindings ready for the upcoming switch to Python3, +as python2 availability is decreasing? The same actually holds for Qt4, +do you plan to upgrade this - or would you be open to others doing that? + +nmigen is a tool produced by others, how will this work? Will additional +cost be needed to upstream this effort? Would it not make more sense for +that project to be funded directly? + +# Answer (1) + +> you applied to the 2019-10 open call from NLnet. We have some questions +> regarding your project The Libre-RISCV SoC, Coriolis2 ASIC Layout +> Collaboration. +> +> Can you provide a breakdown of the amount requested? We understand there +> are a number of different tasks you will undertake, but we need to +> understand the cost composition of the proposal. + + I will let that point to Luke... + +> Are Coriolis2 python bindings ready for the upcoming switch to Python3, +> as python2 availability is decreasing? The same actually holds for Qt4, +> do you plan to upgrade this - or would you be open to others doing that? + + * For Qt 5, the port is already done and working. It was needed to + build for Debian 9 / Ubuntu 18.04 LTS. + + * For Python 3, the move has not been done (yet), but I sure feel a + rising pressure to do it. + + Long answer is that my "reference build system" is Scientific Linux 7 + (a free clone of RHEL 7) which allows me to both run my tool and the + commercial ones as well (Cadence/Mentor/Synospys) and keep me close to + the OSes used in the industry. And this system still uses Python 2.7 + as it's primary (RedHat makes very stable systems, but the downside + is that they uses old versions of tools). So, of course I'm aware + that I will need to switch to Python 3 at some point, but it doesn't + feel urgent. + I'm perfectly happy with other people doing the port, I'm just not + very proud about the way the Python bindings are done. As I want to + perform very specific operations, I did develop a bunch of C macros + to do the job. They work well and do exactly what I want and there is + even a tutorial on how to use them, but they are a bit clumsy and + not that easy to understand. + Portability across systems is a dependency nightmare, so I try + to keep to most commonly shared ones. + +> nmigen is a tool produced by others, how will this work? Will additional +> cost be needed to upstream this effort? Would it not make more sense for +> that project to be funded directly? + + To muddle the point even more (this is an info I wanted to pass on + Luke), we are also investigating on nmigen in the LIP6, with the same + goal of interfacing with Coriolis. -- 2.30.2