I was a bit nervous about the synthsizability of certain VHDL features, so I thought it might be a good idea to see what is written in the standard (IEEE 1076.6 "IEEE Standard for VHDL Register Transfer Level (RTL) Synthesis").
To my astonishment, I found that there is no current standard: the 1999 version has been superseded by the 2004 version; the 2004 version has the status "withdrawn":
https://standards.ieee.org/standard/1076_6-2004.html
I find it hard to believe that there is no need for a standard subset, so
I hope someone can explain why the appears to be no current standard.
First DASC made them joint standards with IEC. When this happened, the numbers changed - which made them hard to find.
Some time later, both the VHDL and Verilog standards were retired by DASC (Design Automation Standards Comittee) because no one stepped forward to maintain them. Since I do not generally attend DASC meetings, I missed that this happened.
I worked on the VHDL RTL standard. It lacks reward when you put forward coding styles and attributes and vendors such as Xilinx and Altera do not implement them.
It can be revived. It is worth reviving if you can get the tool vendors (Xilinx, Altera, Synopsys, Mentor, and Cadence) participating and implementing the standard.
However, without them participating and committing to implement new features, then the effort by a user led committee would not be worth the time.
If you think of just the statemachine and ROM/RAM attributes, we really need some consistency out of industry - the current state is embarrassing.
Related
I have some question about Chisel conversion. I know it's theoretical but it would be nice if someone give his opinion.
1) I want to ask why Chisel does not focus on VHDL / SystemVerilog conversion. Although both Verilog and VHDL are same, in some countries especially Europe prefer VHDL.
2) Similarly, C++ model is used for simulation models. Why Not SystemC for this purpose?
I was reading some notes and find out FIRRTL is the middleman for converting CHISEL-->FIRRTL--> Verilog and CHISEL---> FIRRTL--> C++ model.
Is it a nice idea to use the (Low)FIRRTL specs to Convert the VHDL and SystemC models.?
The short answer is that supporting VHDL and SystemC backends simply hasn't been a priority for the developers.
There are a few reasons why it hasn't been a priority:
People rarely ask for it. This is the first time I've seen this come up
since this issue on the Chisel 2 repo back in 2014.
Lack of developer time. We have quite a backlog of features already so additional backends simply haven't been a priority. While I think the implementation effort of adding a VHDL and/or SystemC backend isn't too bad, they would also present an additional maintenance and verification overhead. All this being said, Chisel3 and FIRRTL are open-source projects so we welcome contributors who want to help us with particular features!
Unclear benefits. VHDL (at least) is interoperable with Verilog so it's unclear why a VHDL backend is needed. As far as tooling, my understanding is that Verilog seems to have equivalent or better support than VHDL. For readability/debug-ability concerns, the generated code is not really intended for reading anyway; rather, most users use waveforms and only use the emitted code for the source-locators pointing back to the Scala source. I'm less familiar with SystemC so there might be some nice benefits of emitting it that I'm unaware of!
I'm most certainly unaware many benefits so please let me know what I'm missing!
One other bit that might help future readers: as jkoenig mentioned, the purpose of Chisel isn't to generate HDL code for humans to use. The purpose is to create a new language for designing hardware.
Verilog just happens to be a language that is spoken by lots of hardware tools, so generating Verilog is an easy way to make Chisel interoperable with the current ecosystem of CAD tools. Otherwise you would have to write your own synthesis and place-and-route tools if you actually wanted to implement Chisel designs on real hardware. In this respect, Verilog or VHDL is a moot argument. Either one would work, and as long as one works, the other is not really necessary.
I thought of building a synthesis tool which is based on dedicated hardware in order to accelerate the developing of an RTL.
Are there any HW based platforms that synthesis RTL ?
Can one approximatly estimate how fast is it in compare to Synopsis tool
The idea is to make kind of bootstrapping of vhdl/verilog/netlist synthesizer, a platform that makes a big state machine implemented in HW that sensitizing all the RTL (Writing a compiler in its own language shows the close idea for SW world).
As always, when the question presupposes "do it in hardware", the answer always has to be "show which bottlenecks the hardware will fix and how ". Until you understand the problem well enough to answer that question in more than a handwaving fashion, its all guesswork.
As another has noted - if it were sensible (financially), there's a big enough market of frustrated engineers waiting for synthesis to complete that it would already be there.
If it's just for a fun project, then sure, have at it :)
Here's a recent thesis about the topic, and the author has written a book as well. Given the cost of hardware development this probably isn't practical today.
That's a very interesting idea, and to answer your first question I'm fairly sure there are no existing products like this commercially available.
You should know that synthesis tools are extremely complex, however. Creating what you want is going to be a lot of work, I would say that even a feasibility study (which, among other questions, should answer your second question) would be enough for a master's thesis.
Like Martin said there are tons of frustrated engineers out there with designs that take hours to synthesize (I'm one of them!). Still both Altera's and Xilinx' synthesis tools utilize the six-core processor in my computer very badly, especially if I don't do any design partitioning. This leads me to believe that parallelizing the synthesis process isn't easy, although I tend to overestimate engineers at big companies.
I believe at university I wrote a program for an FPGA which was in a language derived from C. I am aware about languages such as VHDL and verilog. However, what I dont understand is the amount of choice a programmer has regarding which to use? Is it dependent on the FPGA? I am going to be using a Xilinx FPGA.
I am confused because the C-variant language was, unsurprisingly, similar to C- however I know things like VHDL are nothing like C. Therefore if I have a choice I would prefer to programme an FPGA using a C-variant language. The Xilinx website had a million documents and it wasn't overly clear.
It was probably Verilog that you used. It's rather C-like in a lot of it's constructs. I wouldn't say it's "like C", but some syntax is similar.
VHDL is based on ADA, so yes, it's rather different.
There are some small FPGA specific languages around, but VHDL and Verilog are the big two. I think most others have died now.
Remember that writing hardware and writing software are two rather different things. You can't really describe hardware constructs in a language like C (*). The language needs to have special features to allow you to describe exactly what you want. The code needs to be structured in a way that will make the hardware efficient. Don't fool yourself into thinking that you can take a piece of software and magically run it on an FPGA just by changing the language/compiler. (This is targeted more at your follow up question to Marty).
Trying to use C to write a circuit description, is like trying to program a computer in English. You could do it, but it's really the wrong language for the job.
(*) Yes, I know there's SystemC (a C++ class library that is meant to make code synthesisable), but I've yet to see anyone get good results from it, and certainly not on FPGAs. Even then the code has to be structured in a similar way as for an HDL.
Clearly HDL are still preferable when programming FPGA (Xilinx, Altera etc : all accept VHDL or Verilog).
However, things are changing (slowly) : there are now excellent so-called behavioral synthesizers that allow you to code in C and generate hardware, expressed for you in VHDL or Verilog at the register-transfer level. They are sometimes refered as HLS : high-level synthesis.
The problem is that they are quite expensive.
Synfony from Synopsys
Cynthesizer from Forte Design Systems
CatapultC from Calypto (was from Mentor)
ImpulseC
At the academic level :
Gaut from Labsticc lab (France)
spark
legup
Hercules
...
Basically, these tools work by extracting a dependency graph from the C program : nodes represents computations and edges represent variables : that is all what you do when you program, in either C or other programming language. Using this internal representation, the compiler can do hardware-relevant transformations like : register allocation (mapping variables to register, or keeping them combinatorial i.e on wires), operations scheduling (deciding if operation execute in same clock cycle) etc, and finally generate HDL automatically.
Hope this helps
JCLL
Usually FPGA vendors will have toolchains that support both Verilog and VHDL - it's up to you to choose which language you'd like. It's generally just these two languages that are supported.
For more C-like languages, a long-shot option is to use the synthesisable subset of SystemC. This is C++ with circuit-friendly stuff added. I'm not sure if the FGPA tools support this though.
For programming FPGAS, is it possible to write my own place & route routines? [The point is not that mine would be better; the point is whether I have the freedom to do so] -- or does the place & route stage output into undocumented bitfiles, essengially forcing me to use proprietary tools?
Thanks!
There's been some discussion of this on comp.arch.fpga in the past. The conclusion is generally that unless you want to attract intense legal action from the FPGA companies then you probably don't want to do something like this. bitfile formats are closely guarded secrets of the FPGA companies and you would likely have to understand the file format in order to do what you want to do. That implies that you would need to reverse engineer the format and that (if you made your tool public in any way) would get you a lawsuit in short order.
I will add that there probably are intermediate files and that you likely wouldn't read or write the bitfile itself to do what you want to do, but those intermediate files tend to be undocumented as well. Read the EULA for your FPGA synthesis tool (ISE from Xilinx, for example) - any kind of reverse engineering is strictly forbidden. It seems that the only way we'll ever have open source alternatives in this space is for an open source FPGA architecture to emerge.
I agree with annccodeal, but to amplify a little bit, on Xilinx, there may be a few ways to do this. The XDL file format allows (or used to allow) explicit placement and routing. In addition, it should be possible to script the FPGA Editor to implement custom routing.
As regards placement, there is a rich infrastructure to constrain technology mapping of logic to primitives and to control placement of those primitives. For example LUT_MAP constraints can control technology mapping and LOC and RLOC constraints can determine placement. In practice, these allow the experienced designer great control over how a design is implemented without requiring them to duplicate man-centuries of software development to generate a bitstream directly.
You may also find interesting the current state of the art FPGA CAD research software such VPR. In my opinion these are challenged to keep up with vendor's own tools that must cope with modern heterogeneous FPGAs with splittable 6-LUTs, DSP blocks, etc.
Happy hacking.
I have looked on the web and the discussions/examples appear to be for traditional software development. Since Verilog and VHDL (used for chip design, e.g. FPGAs and ASICs) are similar to software development C and C++ it would appear to make sense. However they have some differences being fundamentally parallel and requiring hardware to fully tests.
What experiences, good and bad, have you had? Any links you can suggest on this specific application?
Edits/clarifications:
10/28/09: I'm particularly asking about TDD. I'm familiar with doing test benches, including self-checking ones. I'm also aware that SystemVerilog has some particular features for test benches.
10/28/09: The questions implied include 1) writing a test for any functionality, never using waveforms for simulation and 2) writing test/testbenches first.
11/29/09: In Empirical Studies Show Test Driven Development Improves Quality they report for (software) TDD "The pre-release defect density of the four products, measured as defects per thousand lines of code, decreased between 40% and 90% relative to the projects that did not use TDD. The teams' management reported subjectively a 15–35% increase in initial development time for the teams using TDD, though the teams agreed that this was offset by reduced maintenance costs." The reduced bugs reduces risk for tape-out, at the expense of moderate schedule impact. This also has some data.
11/29/09: I'm mainly doing control and datapath code, not DSP code. For DSP, the typical solution involves a Matlab bit-accurate simulation.
03/02/10: The advantage of TDD is you make sure the test fails first. I suppose this could be done with assertions too.
I write code for FPGAs, not ASICS... but TDD is my still my preferred approach. I like to have a full suite of tests for all the functional code I write, and I try (not always successfully) to write testcode first. Staring at waveforms always happens at some point when you're debugging, but it's not a good way of validating your code (IMHO).
Given the difficulty of performing proper tests in the real hardware (stimulating corner cases is particularly hard) and the fact that a VHDL-compile takes seconds (vs a "to hardware" compile that takes many minutes (or even hours)), I don't see how anyone can operate any other way!
I also build assertions into the RTL as I write it to catch things I know shouldn't ever happen. Apparantly this is seen as a bit "weird", as there's a perception that verification engineers write assertions and RTL designers don't. But mostly I'm my own verification engineer, so maybe that's why!
I use VUnit for test driven development with VHDL.
VUnit is a Python library that invokes the VHDL compiler and simulator and reads the results of the simulation. It also provides several nice VHDL libraries that makes it a lot easier to write better test benches, such as a communication library, logging library and a checking library.
There are many possibilities since it is invoked from Python. It is possible to both generate test data, as well as check the output data from the test in Python. I saw this example the other day where they used Octave - a Matlab copy - for plotting test results.
VUnit seems very active and I have several times been able to actually ask questions directly to the developers and gotten help quite quickly.
A downside is that it is harder to debug compilation errors since there are so many function/procedure variations with the same name in the libraries. Also, some stuff is done behind the scene by preprocessing the code, which means that some errors might show up in unexpected places.
I don't know a lot about hardware/chip design, but I am deeply into TDD, so I can at least discuss suitability of the process with you.
The question I'd call most pertinent is: How quickly can your tests give you feedback on a design? Related to that: How quickly can you add new tests? And how well do your tools support refactoring (changing structure without changing behavior) of your design?
The TDD process depends a great deal on the "softness" of software - good automated unit tests run in seconds (minutes at the outside), and guide short bursts of focused construction and refactoring. Do your tools support this kind of workflow - rapidly cycling between writing and running tests and building the system under test in short iterations?
The SystemVerilog extensions to the IEEE Verilog Standard include
a variety of constructs which facilitate creating thorough test suites
for verifying complex digital logic designs. SystemVerilog is one of
the Hardware Verification Languages (HVL) which is used to verify ASIC chip
designs via simulation (as opposed to emulation or using FPGA's).
Significant benefits over a traditional Hardware Design Language (Verilog) are:
constrained randomization
assertions
automatic collection of functional and assertion coverage data
The key is to have access to simulation software which supports
this recent (2005) standard. Not all simulators fully support
the more advanced features.
In addition to the IEEE standard, there is an open-source SystemVerilog library
of verification components available from VMM Central (http://www.vmmcentral.com). It provides a reasonable framework for creating a test environment.
SystemVerilog is not the only HVL,and VMM is not the only library.
But, I would recommend both, if you have access to the appropriate
tools. I have found this to be an effective methodology in finding design
bugs before becoming silicon.
With regard to refactoring tools for hardware languages, I'd like to point you to our tool Sigasi HDT. Sigasi provides an IDE with built-in VHDL analyzer and VHDL refactorings.
Philippe Faes, Sigasi
ANVIL– ANother Verilog Interaction Layer talks about this some. I haven't tried it.
I never actively tried TDD on an RTL design, but I had my thoughts on this.
What I think would be interesting is to try out this approach in connection with assertions. You would basically first write down in form of assertions what you assume/expect from your module, write your RTL and later you can verify these assertions using formal tools and/or simulation. In contrast to "normal" testcases (where you probably would need to write directed ones) you should have much better coverage and the assertions/assumptions may be of use later (e.g. on system level) as well.
However I wouldn't fully rely on assertions, this can become very hairy.
Maybe you can express your thoughts on this as well, as you are asking for it I guess you carry some ideas in your head?
What is TDD for you? Do you mean having all your code exercised by automatic tests at all times, or do you go further to mean that tests are written before the code and no new code is written unless tests fail?
Whichever approach you prefer, HDL code testing isn't very different from software testing. It has its pluses (much better coverage and depth of testing) and minuses (difficult to set up and cumbersome relatively to software).
I've had very good experience with employing Python and generic HDL transactors for implementing comprehensive and automatic tests for synthesizable HDL modules. The idea is somewhat similar to what Janick Bergeron presents in his books, but instead of SystemVerilog, Python is used to (1) generate VHDL code from test scenarios written in Python and (2) verification of results written by the monitoring transactors that accept waveforms from the design during simulation.
There's much more to be written about this technique, but I'm not sure what you want to focus on.