I designed a circuit using RTL SystemC library. This circuit works fine and I can simulate it properly. Now I want to deploy it into an FPGA and I'm looking for a way to convert my SystemC code into VHDL or Verilog in order to use it in Xilinx ISE.
Is there a way to do that ? Or do O have to do all the programming again but this time, in VHDL ?
Probably yes, you have to clone the existing design in VHDL - certainly, if you must use ISE. But it might be worth looking at Vivado first.
However, assuming your simulator understands VHDL as well as SystemC, this will be straightforward because you can drop the VHDL into the existing testbenches and verify its correct function, thereby reusing at least half of your proglamming so far.
And presumably you can use the SystemC version as an accurate specification; translating this into VHDL should be quite a straightforward process.
Related
What FPGA vendor boards are supported (well) by Chisel? Are most FPGAs on the market generically supported? Or do we need to be careful about some details when buying? If so, what should we pay attention to?
I really need a hardware suite that minimizes the gap and hassles between the simulation and the actual synthesis layer. Thanks!
Chisel produces a synthesizable subset of Verilog 2001 that is supported by all FPGAs and FPGA tool vendors.
By example, you can write Chisel code for an inverter and use this to generate Verilog:
import chisel3._
import chisel3.stage.ChiselStage
class Inverter extends RawModule {
val in = IO(Input(Bool()))
val out = IO(Output(Bool()))
out := !in
}
(new ChiselStage).emitVerilog(new Inverter)
The produced Verilog is shown here:
module Inverter(
input in,
output out
);
assign out = ~in; // #[main.scala 10:10]
endmodule
This Verilog file can then be used in any FPGA toolchain (open or closed source) that supports Verilog. You would need to write the associated collateral that the toolchain wants (implementation constraints file, etc.). Functional verification can be done a lot of ways, e.g., writing Verilog/SystemVerilog testbenches for the generated Verilog, using cocotb for Python-based testbenches, or using one of the Chisel testing libraries (which actually run tests on the Verilog) like ChiselTest. ChiselTest actually uses Verilator as one of its possible backends meaning that the tests you write in ChiselTest will run on a Verilator-compiled binary. This is a concrete example of tight coupling between generated Verilog and a tool that only ingests Verilog.
Note: this views FPGA vendor tools as "Verilog to bitstream compilers" and not as "integrated development environments". By this view, FPGA vendor tools support any of the HDLs of a similar type including, but not limited to: Clash, nmigen, and SpinalHDL. For IDE-support, a Java IDE is going to be better for doing actual Chisel development, e.g., Emacs with Scala metals or IntelliJ Idea.
Chisel is not supported natively by any vendor tool that I know. The FPGA could be programed by open source compilers which could support natively chisel (I didn't find any, but that doesn't there is none).
Now it would still work well for FPGA design, the compiler will generate verilog that all the FPGA vendor tool supports.
In that case, as you can see you are far from minimizing the gap between the simu and synthesis! But using chisel over low-level RTL language offers advantages that might overcome those differences in a lot of cases.
Since you are asking this question I am guessing that you don't have a lot of experience in FPGA. I would advice, to pick the same board as an open source project that uses chisel. This approach is true for any language you end-up picking (chisel or not), pick an open source of that language and take the same platform.
from the doc: https://www.chisel-lang.org/
" Chisel adds hardware construction primitives to the Scala programming language, providing designers with the power of a modern programming language to write complex, parameterizable circuit generators that produce synthesizable Verilog."
major FPGA vendor tools:
Xilinx's vivado => check page 7, supports: VHDL, verilog, system verilog
Intel's quartus => page 54, supports: VHDL, verilog, system verilog
Mentors's questa => supports VHDL, Verilog, SystemVerilog, PSL, SystemC
open source compiler/ simulator:
Verilator supports: verilog, system verilog
yosys supports: Verilog-2005
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 have Xilinx background and now I happened to write some code on Altera devices. I have a question about generating post-synthesis models (also post-fit). On Xilinx I had netget which was able to generate verilog or vhdl post-synthesis model of my design which I was able to use freely for example in iverilog compiler. I quartus ii i have found quartus_eda tool but I am not able to perform what I wanted, I can generate *.vo files which looks fine but I am not able to find libraries to cover elements used there. I am using --tool=modelsim. Where I should look after them ?
See ModelSim-Altera Precompiled Libraries for pre-compiles libraries for Altera devices in ModelSim simulation.
The Preparing for EDA Simulation may also be helpful.
However, you may re-consider doing post-synthesis/fit simulation, since functional simulation at RTL level combined with Static Timing Analysis (STA) maybe an alternative approach. If the intention is to verify timing with post-fit simulation, then note that Altera apparently is abandoning this support for this, since timing information in Standard Delay Format Output File (.sdo) files is not generated for post-fit simulation information for e.g. Cyclone V devices.
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.
I have pex_pkg.vhd and I want to use this library to make floating point adder but altera max+plus II give me an error can't open "PEX_lib" how to include this library in max+plus ?
I'd stay away from Max plus II if I were you, it's v. old - its VHDL support was always spotty, and IIRC using libraries other than work wasn't possible.
Altera's tool is Quartus now - I'm sure that can handle multiple libraries.
You should check out David Bishop's VHDL Floating Point Library. This is by the same author who wrote the VHDL floating point libraries that are build into VHDL 2008, but these are usable with older and more common VHDL tools. They are fully tested and synthesizable. The only potential downside is that because they are implemented via functions, they can only describe the common case of either pipelined or combinational data paths. (If you want, for instance, a smaller multi-cycle digit-serial design, you have to resort to a different library.)
Are you sure you wish that? Most floating point libraries aren't synthesizable.