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.
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 used a ATmega649 before but then switched to ATmega649V.
Does it matter which MCU version given to the compiler, ATmega649, ATmega649V or ATmega649P?
I understand it as the architecture is exactly the same it is only some powersaving that is somehow achieved without changing the architecture that is the difference?
Using avr-gcc.
well, you can use an "almost" compatible architecture with no harm, though you have to triple check the datasheet that there's no difference in the way registers are setup otherwise your program won't work, or worst will work until a feature is failing. It is usually a source of frustration when you've forgotten you've been using a close enough, but not exactly the architecture you're targetting.
I don't know well enough the Atmega649X, and I won't thoroughly read the lengthy datasheets to find those differences. So if you decide to do it, be careful, and don't forget about that!
usually the additional letters signalize differences in max speed, supply voltage ratings or power consumptions. the core itself is compatible. so if numbers match, it is no difference from the compilers point of view.
however the flash tool may recognize them as different parts and require correct settings.
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.
I'm working on a VHDL project for a Xilinx FPGA, and found myself at a cross road.
I need for example to add two signals (C=A+B), and found that Xilinx has Tool that can generate a component which will do the job.
But this could also be implemented in standard VHDL: C <= A + B
If I use standard VHDL the code should be portable, but does this has lower throughput?
I mean, does the special components use DSP functions inside the FPGA ect., that makes them faster, or can the Synthesizer normally handle this?
Any time you can infer something do so.
Performance is very rarely impacted, especially in the case of simple things like adders and multipliers. Even RAM blocks are easy to infer for many purposes - I only tend to instantiate vendor components if I need a very specific vendor-block behaviour.
The DSP blocks will be used well if you write VHDL code for adders and multipliers of the appropriate widths (or smaller) with pipelining that matches what is available inside the block. If you want to be more advanced and use (for example) Xilinx's DSP block's opcode input then you will have to instantiate a block.
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.