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.
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 am new to fpga and i need to understand one thing.
In mcu, the code must be specific to hardware i cannot use raspberry pi code on arduino. However since the fpga chip looks at the verilog or vhdl code and creates the circuit we have designed, Can the same vhdl or verilog code be used on different fpga boards(by only editing the clockspeed or pin names accordingly) if there is enough gate source?
I have basys2 board and there are more tutorials on different boards if same code and logic would work then i will not buy another board and learn on basys2 by using different board sources.
Yes both of them will work well. If it is plain code(without any library as in VHDL) it will work.
Sorry for such a general question. I have experience in Verilog but new to FPGA and Quartus II. I use Quartus II to try to compile a design and to see how much logic the design uses. I followed the quick tutorial of Quartus II by Altera. http://www.altera.com/literature/manual/mnl_qts_quick_start.pdf
However, after the step of analysis and synthesis, I noticed there is no logic utilization at all. Only the two Input pins of top module could be seen.
The top module of my design is
RiSC(clk,reset)
Naturally, after compilation, there is still nothing but two pins.
Have you ever met this problem? Could you give me some hint? The design contains hundreds of lines of verilog codes so there should be logic utilization.
Thanks!
Unused outputs will be optimized out. You're going to have to route out some outputs otherwise the synthesizer will nuke all of the logic.
I am working on a PXI system from National Instruments. It has an FPGA card that I have connected externally to a sensor.
I would like to know how to perform a "cycle accurate" simulation that includes a custom external stimulus that emulates the sensor.
There is a lot of example for simulating the labView -> FPGA -> labView interfaces, but nothing for LabView -> FPGA -> external hardware.
If it hasn't been a NI FPGA system, I would have written an HDL test bench for that, but within the NI FPGA framework, I can't figure out where to put my test bench.
In fact there is a place to put an HDL test bench, but as I said, the only available interface to test is the one between the labView code and the FPGA, and not between the FPGA and the external FPGA pins.
Thanks
This is a right pain (IMHO).
Last time I used Labview FPGA (admittedly a couple of years ago) it had no clue about cycle accurate simulation.
I had to build ordinary labview "testbenches" around each Sub VI - the Sub VI goes in a loop within the testbench VI.
Then link all the subvis together within single-cycle-timed-loops at the top-level. That top level is then not simulate-able, you just have to build it and see :( As you probably agree - this is very alien to the usual FPGA flow.
Simulating right up to the pins (and then the hardware outside also) is just not possible (as far as I know, yet) - it is promised at some point...
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.