Table of Contents for Programming Languages: a survey


"The problem is that Verilog was originally designed as a language to describe simulations, so it has constructs to describe arbitrary interactions between events. When X transitions from 0 to 1, do Y. Great! Sounds easy enough. But then someone had the bright idea of using Verilog to represent hardware. The vast majority of statements you could write down don’t translate into any meaningful hardware. Your synthesis tool, which translates from Verilog to hardware will helpfully pattern match to the closest available thing, or produce nothing, if you write down something untranslatable. If you’re lucky, you might get some warnings. ... How is it possible that a reasonable description of something in Verilog turns into something completely wrong in hardware? You can think of hardware as some state, with pure functions connecting the state elements. This makes it natural to think about modeling hardware in a functional programming language. Another natural way to think about it would be with OO. Classes describe how the hardware works. Instances of the class are actual hardware that will get put onto the chip. Yet another natural way to describe things would be declaratively, where you write down constraints the hardware must obey, and the synthesis tool outputs something that meets those constraints.

Verilog does none of these things. To write Verilog that will produce correct hardware, you have to first picture the hardware you want to produce. Then, you have to figure out how to describe that in this weird C-like simulation language. That will then get synthesized into something like what you were imaging in the first step.

As a software engineer, how would you feel if 99% of valid Java code ended up being translated to something that produced random results, even though tests pass on the untranslated Java code? And, by the way, to run tests on the translated Java code you have to go through a multi-day long compilation process, after which your tests will run 200 million times slower than code runs in production. " -- [1]


Verilog tutorials

Bluespec SystemVerilog (BSV)




Verilog vs VHDL vs ...

"VHDL is used primarily in Europe (and in some academic classes in the US), while Verilog is used by the vast majority of businesses in the US, and most of the top schools for VLSI. I know that the vast majority of chip designers I know (which are 90% US based) much prefer Verilog. As for Intel and ARM, both are primarily Verilog shops, but I know ARM provides both Verilog and VHDL models for the licensed components. " -- [2]

"...The latest version of the IEEE standard version of Verilog is Verilog 2005, but there are also offshoots, such as SystemVerilog?. While most things distributed for interoperability and targeted for general understanding are written in Verilog, most actual designers use SystemVerilog?, which was eventually made into its own IEEE standard. SystemVerilog? adds a lot of object oriented features, and is a pretty clean addition to Verilog." -- [3]

"You usually see VHDL in .eu and some defense contractors, and Verilog everywhere else. VHDL feels similar to Ada, and Verilog is more similar to C." -- [4]


There have been a number of attempts to do better than jamming an ad hoc scripting language into Verilog, but they’ve all fizzled out. As a functional language that’s easy to add syntax to, Haskell is a natural choice for Verilog code generation; it spawned ForSyDe?, Hydra, Lava, HHDL, and bluespec. But adoption of ForSyDe?, Hydra, Lava, and HHDL is pretty much zero, not because of deficiencies in the language, but because it’s politically difficult to get people to use a Haskell based language. Bluespec has done better, but they’ve done it by making their language look C-like, scrapping the original Haskell syntax and introducing Bluespec SystemVerilog? and Bluespec SystemC?. The aversion to Haskell is so severe that when we discussed a hardware style at my new gig, one person suggested banning any Haskell based solution, even though bluespec has been used to good effect in a couple projects within the company. ... Chisel is interesting. Like bluespec, it simulates much more quickly than Verilog, and unsynthesizable representations are syntax errors. It’s not as high level, but it’s the only hardware description language with a modern type system that I’ve been able to discuss with hardware folks without people objecting that Haskell is a bad idea.

Commercial vendors are mostly moving in the other direction because C-like languages make people feel all warm and fuzzy. A number of them are pushing high-level hardware synthesis from SystemC?, or even straight C or C++. " -- [5]

More at:

HLLs that compile to hardware languages or similar; also possibly other hardware langs



Scala (Spatial):




Scheme as a Verilog preprocessor:



" CGRAs consist of an array of a large number of function units (FUs) interconnected by a mesh style network. Register files are distributed throughout the CGRAs to hold temporary values and are accessible only by a subset of FUs. The FUs can execute common word-level operations, including addition, subtraction, and multiplication. In contrast to FPGAs, CGRAs have short reconfiguration times, low delay characteristics, and low power consumption as they are constructed from standard cell implementations. Thus, gate-level reconfigurability is sacrificed, but the result is a large increase in hardware efficiency.

A good compiler is essential for exploiting the abundance of computing resources available on a CGRA. However, sparse connectivity and distributed register files present difficult challenges to the scheduling phase of a compiler. "

" Need for faster and power-efficient processors has paved the way for many-core processors along with considerable research in accelerators. Acceleration through popular Graphics Processing Units (GPUs) is over a broad range of the parallel applications but majorly limited to parallel loops and loops with high trip counts. Field programmable gate arrays (FPGAs) on the other hand, are reconfigurable and general-purpose but are marred by low power efficiency due to their fine-grain management.

Coarse-Grained Reconfigurable Arrays (CGRAs) are promising accelerators, capable of accelerating even non-parallel loops and loops with lower trip-counts. They are programmable yet, power-efficient accelerators. CGRA is an array of Processing Elements (PE) connected through a 2-D network; each PE contains an ALU-like Functional Unit (FU) and a Register File (RF). FUs are capable of executing arithmetic, logical or compare operations. The configuration memory issues context to each PE specifying the operation, every cycle. Data/address bus are shared either by PEs in the same column or by PEs in the same row. CGRA can achieve higher power efficiency due to simpler hardware and intelligent software techniques. "






york lava stuff: