Fantastic little device! Relating to the post, I also happened to brick one erasing the Foboot bootloader by writing the flash beyond the limit (there was a bug regarding writing to addresses beyond max at the time, but then I was pushing the limit by abusing dfu-utils :) https://x.com/sylefeb/status/1391898565061001225 ). I tried to use the programming pads but at the time was lacking the skills and it ended in disaster (ripped pads...).
This is a fascinating topic, especially when considering how this was achieved back in the days. We now take it for granted, but this was not a simple feature to have in your game in 199x ( x<6 ;) ).
Lookup tables are great to produce impressive graphics effects under strict
compute limits. I use them in many FPGA projects. On FPGA there is a balance
between limited memory (often BRAM) and limited compute, but they can be used to
great effect:
Tunnel effect (exactly as user bemmu described below):
Sine tables are also very typical, for animating things on screen or plain
trigonometry, for instance my small fixed integer raytracer uses a sine table
to animate the spheres (and the cos is easy to get from the sin, especially if
the table has a power of two size ;) ):
Very, very impressive works, both MRISC32 and FuryGPU (which I just learned about, love the idea of a FPGA-retro-GPU that could go in a modern computer!). It's hard to overstate the amount of passion, care and technical expertise that go into such projects.
I'm the author of 'q5k' (Quake viewer in 5K LUTs) and so I wanted to say Hi to my fellow Quake-on-FPGA enthusiasts. Thanks for the mention, and looking forward to the next steps of your projects!
PS: Q5k is of course much, much slower (runs on a small $10 ice40 up5k FPGA), and only a viewer. The renderer is custom using fixed-point only. Unlikely I'll be ever able to run the full game at any decent speed, but I'm surely going to try :) For anyone interested, here's the repo of q5k and doomchip-onice: https://github.com/sylefeb/tinygpus
Thanks a bunch for the link! I love how you fit a quake renderer onto such a small device (having a demo scene size coding history, I enjoy the challenge of a constrained target and I'd like to do something similar with the MRISC32 ISA some time - e.g. an "MRISC32-A0").
Something missing from those discussions is perception of legal risk around the licenses.
If you fail to comply with any FOSS license, the enforcement mechanism is the same: since you didn't uphold the terms of the license, you have NO license and thus can be penalized for copyright infringement.
However, FOSS license violations rarely result in the most draconian copyright infringement penalties. Generally, what FOSS authors want is adherence to the license going forward, rather than to sue you for money and maximize damages.
In the case of permissive licenses, coming into compliance just means adding credit somewhere. Nobody finds that painful. So infringement suits basically don't happen — infringeers just add credits in new releases, the past is forgotten, end of story.
In the case of copyleft, coming into compliance typically requires more work: most infringers remove the copyleft dependency and either replace it with something else or write new code. Theoretically the infringer could also release previously proprietary source code under the copyleft license but AFAIK in practice nobody chooses this option. Because copyleft compliance is more work, copyleft enforcement is a bigger deal, and copyleft authors sometimes go to court.
The consequence is that copyleft licenses are perceived as entailing greater legal risk, especially GPL and AGPL.
This copyleft-vs.-permissive bifurcation isn't perfect because e.g. the Eclipse License is a copyleft license but is perceived as low risk. Really the perception of risk around a licnse has to do with the community around the license and its traditions. GPL and AGPL, among all FOSS licenses, are perhaps the most likely to result in enforcement actions.
So... by choosing AGPL, you associate your project with a comparatively litigious FOSS community, even if the enforcement mechanism being leveraged isn't any different from what's available to permissive license communities. And so, users who wish to minimize what they perceive as increased legal risk may stay away from your project.
Yes, exactly! Silice is only a thin abstraction layer over Verilog with a few syntax conveniences (fsms, pipelines, BRAMs, groups, interfaces, please see README ).
You can design in Silice in a way similar to Verilog ( with more comfort -- well I hope :) ) and choose to use some of its more advanced helpers such as building FSMs with explicit control flow constructs (while/break/subroutines).
Silice only does a few optimizations/transformations and they are very predictable (most rules are already documented), so you can still reason about your design directly in terms of flip-flops, states, multiplexers, etc. In this way it is much simpler compared to what I understand an HLS to be (these are capable of remarkable optimizations). I am trying to strike a balance between comfort of design and remaining very close to the hardware.
Silice generates Verilog, and I have to say it is not pretty -- I am not expecting anyone to directly edit the output. However Silice easily interops with Verilog: one can directly reuse existing modules and access vendor specific primitives -- also Silice generated Verilog could be easily integrated in Verilog projects, but I yet have to make this easier.
As I said in another thread (https://news.ycombinator.com/item?id=27575174) the spirit in which I am developing Silice is "I hope you'll find it useful" ; there are many options out there and I think it is great to have various tools for various problems and various styles.
I've looked before at these high-level things generating Verilog and I don't see what they bring that's so much better than what I can do with well-established VHDL. VHDL is rather verbose but that's nothing a bit of preprocessing/templating can't fix. Does slice offer something more here? I've looked at the readme but nothng jumps out. And I'm not even talking about vhdl-2019, which looks awesome (I can't wait to use in 2039 when it becomes supported in my tools)!
I looked over the Silice readme yesterday, and as a seasoned HDL engineer, I didn't see anything for me but I could see it's merit as a learning tool.
On HLS in general, I was a skeptic too until I read this paper. [1] I am still more a verilog and verilog-mode [2] kinda guy but I can definitely see the benefits. For me, it's hard to look at figures 5,6,7 & 8 and not be impressed. I've actually started using Chisel [3] because of that paper.
That said, it's not all unicorns and rainbows. Unfortunately dealing with back end CAD is kinda an issue because they use verilog as an intermediate language and one basically ends up with the C++ name mangling issue. Chisel is not so bad about it, but it's not great either.
Hi (author) - for me Silice brings comfort while designing, simplicity of reuse (groups+interfaces making it easy to assemble components), a syntax that is more to my taste (obviously ;) ) and ease of prototyping with the 'control-flow' FSM style and pipeline constructs. Plus the Lua pre-processor that I enjoy using. All this while staying close to Verilog and being able to inter-operate easily.
I also try to build an environment around Silice so that one can easily get started and enjoy testing things, experimenting with relatively advanced projects that are also (for several) explained in details. (The build system relies upon many great projects: yosys, nextpnr, edalize, openfpgaloader, verilator, icarus, etc.)
But this is a very subjective thing ; I absolutely understand that others may not like it or feel it is not necessary, being already expert at other tools. Also, I would never argue that one should use Silice instead of X. Take a look at the repo, checkout a few projects (I recommend 'vga_demo', 'terrain', 'ice-v', 'pipeline_sort' and, for pushing beyond reasonable, 'doomchip'). If you see something you might like, perhaps try making a simple design, see if that is a good tool for you.
> how do you generate recursive designs in vhdl? e.g. reduction trees?
>> preprocessing/templating
> so your tool (vhdl/verilog) requires using another tool (perl/tcl/python) to be productive and you think that's not a failing of the (first) tool?
In my opinion yes it does, and yes that is a failing. But what I was saying is, that alone is not worth the large cost of moving to something new. I was asking if Slice could offer anything more to justify that large cost.
I understand mapping a recursive algorithm to hardware, and VHDL can definitely do that [1]. (even if it is generally a bad idea) But what is a recursive hardware design? It sounds really interesting.
actually this is exactly what i was talking about i.e. (as far as i understand it) this is essentially a reduction tree. i called it a recursive hardware design because it synthesizes to indeed i was unaware that you recursively call functions in vhdl. thanks!
Really nice tool to code FPGA, and hopefully by introducing more powerful tools will encourage and enable more people to utilize FPGA in their products and solutions design.
Just wondering if you are also planning to support FIRRTL in addition to Verilog? It is an intermediate representation for later versions of Chisel and previous discussions on HN [1].
In your Silice descriptions, you did mention about utilizing Lua, can you explain its relationship with Silice?
Hi (author) - Thanks! I would like to support FIRRTL very much, I have looked into it a bit in the past and that all looks feasible. It is a rather big feature though, so it will take some time.
Lua is used as a pre-processor language. This is quite powerful, for instance to automatically generate code, read data into BRAMs (for init), for example RISCV compiled code or DooM wad data (!!). This is used in most projects, see for instance 'pipeline_sort', 'ice-v' or 'doomchip' (a bit extreme there). All lines starting with $$ are pre-processor code, and inserts such as $N$ concatenate the Lua generated N in the Silice code. You can for instance write a for loop with Lua that will duplicate Silice code to e.g. generate a sorting network.
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.
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, ...
Doom has had an immediate huge impact in its time ; even before the source code got released the game had a hacker-friendly wibe to it. For instance DEU (the first editor I used) was released in 1994 (https://doom.fandom.com/wiki/Doom_Editing_Utilities). The 'unofficial specs', still invaluable today if you want to hack Doom, were released in 1994: http://www.gamers.org/dhs/helpdocs/dmsp1666.html
Magazines would bundle floppies (and then CDs) full of levels, with new textures and recorded games. Total conversions were made. Tools appeared to directly manipulate the executable and achieve various effects. As far as I remember no other game before had clustered such a large and active community around it? (which is not to say that no other great and amazing games existed before, so many gems lie in the past!)
And then there was the networked play. I spent an afternoon with a friend soldering a cable to play 'null-modem', and we got it working around ~6pm. At 5am the next day we were still playing, me on a luxurious 486 DX2-66, my friend in a tiny window on a 386 DX-33Mhz, both with red eyes. This was an experience like quite no other at the time.
The gameplay was simplistic but huge fun. The immersion was intense. The tech was stellar. But I am obviously biased by nostalgia ;)
I was in college at UCSD when the 14-Mb shareware DOOM was released. I finally found it (after frantic searching) on a public FTP server somewhere in Australia. I started the download, then went to dinner. After eating, I came back to both the completed file and a salty email from the Aussie sysadmin admonishing me for saturating their connection. The next few days (and my GPA for that quarter) were a bit of a blur. Good times. :D
True - I only (partially) re-implemented the render loop, and this is far from the complete game. A game is always much more that its core technical components.
Adding a keyboard/joystick input is high on my todo. In terms of moving around this really should be just a question of wiring it to the board: the renderer takes a generic x,y,z + angle viewpoint as did the original engine. However, this also means checking for collisions with the BSP scene which is fun to implement (a nice trick in a BSP is to shift the line equations and check with a point as opposed to checking with a disc of some radius).
Side note: I instrumented chocolate-doom (fantastic port) to output the path shown in the video. Initially I was loading a demo lump, but I realized that these are only the inputs and could not easily reproduce the exact way the game answers them (for example, progressive acceleration and of course collisions).
Next up on my list are correct blinking lights, working doors/lifts and sprites (things + enemies). But I also want to optimize it, and to release the language I used to make this. So quite a huge todo; we'll see how it goes. In any case all of that will be made available so everyone can join the fun!
Happy to - but in full this will be better explained on release on the github README, with code examples.
Also, I am no language expert, and not an FPGA expert either (I have been learning for ~ 1 year). I shape this for my own use, hopping it will be useful for others, but I wouldn't pretend nor expect to be achieving something particularly new or interesting at large. Nevertheless, I am using it to build increasingly more complex hardware, the doom-chip being the most advanced so far. Every time the language is extended and fine tuned, so it is rooted in practice.
=> The following is an excerpt from the being-written documentation introduction:
My goal is to make it possible to write algorithms for FPGAs in the same way we write them for processors: defining sequences of operations, subroutines that can be called, and using control flow statements such as while/break. At the same time, the language remains low level. Everything an algorithm does is precisely timed, you can fully exploit the parallelism and niceties of FPGA architectures, clock domains are exposed.
My approach is reminiscent of high performance programming in the late 90s (in the demo scene in particular): the then considered high-level C language was commonly interfaced with time-critical ASM routines. This enabled a best-of-both-worlds situation, with C being used for the overall program flow and ASM used only on carefully optimized hardware dependent routines.
The language aims to do the same, providing a thin programmer friendly layer on top of Verilog, while allowing to call low level Verilog modules whenever needed. It favors and exposes parallelism, so as to fully utilize the FPGA architecture.
The main design principles are:
- Prioritize combinational over sequential execution. Parallelism comes first!
- Clearly defined rules regarding clock cycle consumption.
- Explicit clock domains and reset signals.
- Inter-operates easily with Verilog, allowing to import and reuse existing modules.
- Familiar C-like syntax (but this is not C! different constructs for parallelism, pipelining, etc.).
- Powerful LUA-based pre-processor.
Thanks, looking forward to reading more. I am a hardware guy, but I see using higher-level languages to generate HDL as being a very powerful approach.
Fantastic little device! Relating to the post, I also happened to brick one erasing the Foboot bootloader by writing the flash beyond the limit (there was a bug regarding writing to addresses beyond max at the time, but then I was pushing the limit by abusing dfu-utils :) https://x.com/sylefeb/status/1391898565061001225 ). I tried to use the programming pads but at the time was lacking the skills and it ended in disaster (ripped pads...).
The code repo for the overall project is here: https://github.com/sylefeb/tinygpus