It's great how open source FPGA design tools are light years ahead of the closed source behemoths from the FPGA manufacturers. (Chisel being another example)
Me too. I was particularly hopeful that they would explain why they decided to not go with systemC as it seems to solve a similar problem but I couldn't find anything.
Hi, Silice author here. I cannot provide a detailed answer as I am not familiar enough with SystemC. I started Silice as a "quality of life" (in the video game sense) thin layer above Verilog, hoping to obtain something that would be more enjoyable to write with. I'd like this to be true both for getting started with FPGA, but also when describing advanced designs with efficiency concerns in mind (LUT count, max perf, hardware specificity such as DSP blocks, etc.).
In many ways Silice is very simple. Just a thin abstraction layer with helpful syntax helpers (groups, interfaces, pipelines, fsm), automating some checks and performing simple optimizations (e.g. flip-flop pruning). But please see the README for all details.
The spirit in which I am developing Silice is "I hope you'll find it useful" and absolutely not "this will be the definitive HDL". First, I am surely not qualified enough to imagine achieving such a goal, and second I am a big believer in having various tools for various problems and various styles.
So I hope you'll find it useful :) I am taking great care in providing a build system to make it easy to get started both in simulation and real FPGA hardware. This relies on many other great projects: yosys, nextpnr, edalize, openfpgaloader, verilator, icarus, ...
It looks interesting enough, but I see that it's AGPL 3.0 licensed. AFAIK, the perceived toxicity of that license makes it impossible for use in a commercial setting?
Hi, Silice author here. I picked the AGPL 3.0 knowing it is on the strict side of the spectrum, but not thinking it would be 'toxic'?
If you have some pointers on this I'd like to learn more.
In particular, I'd like Silice to be under a GPL style license (so that everyone benefits from improvements), but also to ensure that what is produced with Silice (designs coming in/out of it) is not 'contaminated' by the license.
I think 'toxic' in the case of AGPL means that companies who would like to run privately-modified versions of your AGPL software on their servers for end-users to use (remotely) don't want to share their changes.
If your priority is strictly that you want everyone to benefit from improvements that are made, AGPL isn't toxic.
On the other hand, it might limit what improvements are made in the first place, because companies that don't want to share won't adopt the software and make those improvements.
So the dilemma is one of priorities. If you want widespread adoption by companies, you have to license in such a way that companies can keep private modifications, because that's their priority. (Unless they are an open source company, and I would be surprised if those have a problem with AGPL.)
There is a secondary dilemma where companies worry about where the line is between 'private modification' and 'mere aggregation'. It's understandable that companies who think their crown jewels are the network services they provide, would worry that using AGPL software as part of their services might be found to be so closely related to the AGPL software that it's a derivative of it, making the whole thing is subject to AGPL release terms. Especially if engineering gets a bit sloppy about copying and pasting.
Your assumption that a company’s priority is to not share is a possibility, but it is a worst case one, and one that is IMO less of a concern for a programming language: keeping bug fixes or even new language features to themselves may very well be a net negative. A buggy reference language implementation for external users will turn them off from using it, and make it harder to hire experienced users or benefit from improvements by others.
For such a case, the fear of using AGPL is much more likely one of accidental contamination, such as an employee copying a piece of AGPL licensed code into a completely different, unrelated project.
Google prohibits SW licensed under AGPL not only on their servers, but even on employee laptops.
They fear contamination and forced release of their internal IP, because, compared to regular GPL licenses, the AGPL has some language in it that makes it problematic making those tools available on a network.
This may be an overreaction on their part, but I’m not in a position to argue that case.
The comment on your GitHub issue, that generated Verilog isn’t covered by the license terms, is understandable, but without a real license it’s probably only just that, a comment, and even if it provides legal cover for generated code, it still doesn’t matter because it doesn’t change the blanket ban of AGPL licensed tools.
Google does not have such strong objections against GPL3, which differs from the AGPL3 in just one paragraph.
There's a lot of FUD against AGPL. I suspect that's because companies with deep pockets don't like it -- for reasons that are entirely by design of AGPL and simply s matter of preference.
The only toxicity here is from people who call that "toxic".
For your choice, you need to ask yourself: if your project were to be used as part of a web service by a company which then doesn't share the changes they made to your project, would you be okay with that?
If the answer is "no", then AGPL is the right choice. Otherwise, go with GPL.
In practice, your project doesn't seem the kind of thing where I expect substantial use in a web service. I mean, perhaps there's going to be a Godbolt of HDLs one day? But I guess it's unlikely to come up in a significant way, in which case the whole web service issue just doesn't matter and therefore GPL is the "safer" choice.
I like to learn new stuff by doing personal projects, but since there are so many things to learn, I select those that, one day, might benefit me professionally as well: as a consultant, to help me with perform some task at work more efficiently, etc.
Most new languages that gather some kind of following get their start outside a commercial environment.
If a tool has a license so toxic that many companies
(1) simply rule out their installation on company servers or company laptops out of principle, I move on and select something else to learn.
> the thing you need
The license makes it so that I'll never know whether I need it or not.
A few days ago I tried to build linux kernel for RV32I but had no luck getting it to run in qemu. 64-bit works. asking around basically resulted in everyone telling me that nobody cares about rv32 linux and it is unsupported and unmaintained. so what use is in rv32i?
Not everything has to run Linux. Many applications of small CPUs have no OS at all, while others run under a relatively simple RTOS such as Zephyr or FreeRTOS, both of which work on RV32.
OT: Another project with technical collaborators that have seemingly coalesced around Twitter. How do you even find and become apart of these communities? When I look at Twitter, it's nothing but vitriol.
You have to find and follow people you want to see - and ignore all the "New and Trending" that Twitter tries to shove on you.
I don't use Twitter often, but it seems like the social media of choice for semi-public techy millenials so I follow a bunch of that type. Every time I go on twitter (~monthly) I have a good time seeing all the fun projects that have been happening and all the cross-pollination between different interesting people.
