In verilog and VHDL RTL commands to tools can be given as pragma directives as pseudo comments. I want to avoid using any of these pragma directives in my real comments, so what I'd like to have is a comprehensive list of pragma directive triggers. Ones I know about are:
-- pragma
// synthesis
-- synopsys
You can find a comprehensive list here:
http://www.sigasi.com/content/list-known-vhdl-metacomment-pragmas
As long as you don't have a comment starting with the trigger, i.e., -- <trigger> ..., you should be safe.
For example, when using Altera Quartus, avoid comments such as
-- altera code below,
while
-- The following is for altera.
would be fine.
You can probably find several lists like this, but I doubt any of them are complete. (The one zennehoy posted is missing -- psl, among others.) Even if there is a complete list somewhere you never know what pragmas vendors will add in the future, thus you can never be sure.
If you want your code to be as portable as possible you should probably avoid starting comments with common vendor/tool names like zennehoy suggests (such as synopsys, altera, xilinx, lattice, modelsim, etc.) Other than that I'd say you just have to take your chances.
Related
I have generated dump output files using command -fdump-tree-all and -fdump-rtl-all and I got a lot of dump files. I have read that the codes in GIMPLE are in pseudo-C syntax and RTL dump files are too low level to be understood. Is there any ways to understand GIMPLE and RTL dump files? Any software that can convert it to C code or something useful? Any tutorial to learn to understand it? Thanks
the best way to do it (for me) is to dump some examples and understand by yourself the emitted code. It's not difficult, there are some change from the original code (like cycles are transformed in if with goto), there are a lot of passes in gcc and my advice is to dump what you need. In my case i use frequently the commands:
-fdump-tree-lower
-fdump-tree-cfg
-fdump-tree-ssa
-fdump-tree-optimized (it's the last pass before going into rtl passes)
rtl is almost incompressible and it's needed a great understanding over that dialect
Is there a way/workaround to use statements in a UCF file conditionally, or, can UCF files be included into other UCF files conditionally?
The problem I'm facing is that I have a top module with a set of generics which conditionally instantiate or remove certain submodules from the top module via generate statements.
However, most of these submodules have timing constraints defined in the projects UCF file.
Somewhere during map or par the build process is aborted stating that an instance the UCF file is refering to does not exist (which is correct since the instance was never created due to the choice of generics in the top module).
Whats the best possible way to achieve some sort of "conditional constraint", which can avoid this problem? (beside the obvious preprocessor/script which fingers around in my UCF file)
PS: I'm using the Xilinx ISE 14.4 / Vivado 2012.4 command line tools.
This question has been asked several times:
http://forums.xilinx.com/t5/Design-Entry/include-and-ifdef-for-ucf-files/td-p/77822
http://forums.xilinx.com/t5/Design-Entry/Conditional-inclusion-of-ucf-files/td-p/195684
Short answer is no, not possible unfortunately.
Your best bet is to create 2 separate UCF files and either create a script to point to one or the other or to manually replace it each time you turn on/off your generic switch.
IF you are using Vivado, then you should know that UCF files are no longer supported under the Vivado synthesis. Unless you have to use XST, then you no longer limited to use the out dated UCF file format for your constraints.
Vivado is using XDC constraints, which are a sub set ot TCL, which means you can write a code with conditions to handle your constraints in any way you desire.
You can take a look at the UG 903 from Xilinx for moredetails on how to use the constraints in the latest version of their tools:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2012_2/ug903-vivado-using-constraints.pdf
Another potential solution would be to use Xilinx synthesis attributes.
This can be done to constrain timing of nets, just like the UCF can.
The difference is, attributes can be done inline in VHDL, near the signal declaration.
It's clunky, though.
The right solution likely depends on how many constraints you have.
I upvoted FarhadA's answer, but I wanted to emphasize the point that XDC files are TCL scripts and so they can include conditionals and for loops. So much better than UCF files.
Another advantage of the constraint processing in Vivado is that if it encounters a constraint that does not match the design, it issues a Critical Warning and continues.
Is there any way of telling ISE to synthesize my VHDL/Verilog code into combinational circuits consisting only of look-up tables? I would like to avoid multiplexers, multipliers, and the like in the tech schematic... and wouldn't mind having an unoptimized (with many components than is optimal) version because of this preference.
Thanks SOCommunity!
There is a way to do that. Look at the XST user guide for switches that control the use of the primitives you want to avoid:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_2/xst_v6s6.pdf
or:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_2/xst.pdf
depending on your target architecture.
For example, to avoid DSP blocks use:
-use_dsp48 no
To avoid automatic packing into BRAMs use:
-auto_bram_packing no
This switch can also be useful:
-slice_utilization_ratio
as will others.
I have a convenient way to look at the available switches, along with some explanation of what they do, on my site:
https://www.boldport.com/flow/#new/options
(click 'Edit', and then 'More options...')
I hope this helps.
In Xilinx you can use the Language templates for this purpose. Select the device you are using and check the available type of LUT's and other components. You can individually instantiate these LUT in your design.
You may have to switch off the "optimization during synthesis" option in XST properties to make this work correctly.
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_1/ise_p_lt_using_language_templates.htm
In order to ease the visual reading of simulation waves, I would like to assign some signals to "XXXX", but only at simulation time, and thus I want the logical synthesis tool (ISE in my case) to skip those instructions.
Two questions from here:
Is there an equivalent technique of a #ifdef SIMULATION_TIME, like in C ?
Would an assignment to "XXXX" have any influence on the logical synthesis (reset to 0 ? warnings ? nothing ?). If it has no impact at all, then my question is answered. If not, I still need to assign to "XXXX"...
Thanks.
(1) You're looking for
--pragma synthesis_off
-- your simulation-only code
--pragma synthesis_on
(2) You might get some warnings from ISE, especially when these signals drive logic. Just make sure, that the signals have a defined value before you use them. This method should work then, as well.
If you find yourself wanting to use ifdef for arbitrary code selection then you can use the VHDL keywords if generate.
label: if SOME_OPTION = SOME_VALUE generate
some VHDL here
end generate;
This is handy if you need to optionally include some code, however the synthesis on/off is more widely used if the selection is between simulation and synthesis.
One other trick to go with George's answer - if you want a boolean for in_synthesis say:
constant in_simulation : boolean := false
--pragma synthesis_off
or true
--pragma synthesis_on
;
constant in_synthesis : boolean := not in_simulation;
As others have mentioned, there is typically a way to turn off synthesis that is tool dependent (check the ISE docs).
When I need something more sophisticated, I perform pre-processing. Typically, I use makefiles and various *nix flavored text processing tools (sed, awk, perl, &c). This can be as simple or as complex as desired. What started as a way to uncomment different blocks of code for simulation vs. synthesis now extracts register documentation and auto-generates C header files for the SW team.
If you don't want to "roll you own", you can apply one of the many pre-existing implementations (C pre-processer, m4 macro language, &c) to your build process.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm with a mechanical engineering background but I'm interested to learn good software engineering practice with Ada. I have a few queries.
Q1. If I understand correctly then someone can just write a package specification (ads) file, compile it and then compile the main program which is using the package. Later on, when one knows what to include in the package body then the latter can be written and compiled. Afterwards, the main program can now be run. I've tried this and I would like to confirm that this is good practice.
Q2. My second question is about stubs (sub-units) and the use of SEPARATE. Say I have a main program as follows:
WITH Ada.Float_Text_IO;
WITH Ada.Text_IO;
WITH Ada.Integer_Text_IO;
PROCEDURE TEST2 IS
A,B : FLOAT;
N : INTEGER;
PROCEDURE INPUT(A,B: OUT FLOAT; N: OUT INTEGER) IS SEPARATE;
BEGIN -- main program
INPUT(A,B,N);
Ada.Float_Text_IO.Put(Item => A);
Ada.Text_IO.New_line;
Ada.Integer_Text_IO.Put(Item => N);
END TEST2;
Then I have the procedure INPUT in a separate file:
separate(TEST2)
PROCEDURE INPUT(A,B: OUT FLOAT; N: OUT INTEGER) IS
BEGIN
Ada.Float_Text_IO.Get(Item => A);
Ada.Text_IO.New_line;
Ada.Float_Text_IO.Get(Item => B);
Ada.Text_IO.New_line;
Ada.Integer_Text_IO.Get(Item => N);
END INPUT;
My questions:
a) AdaGIDE suggests me to save the the INPUT procedure file as input.adb. But then on compiling the main program test2, I get the warning:
warning: subunit "TEST2.INPUT" in file "test2-input.adb" not found
cannot generate code for file test2.adb (missing subunits)
To AdaGIDE, this is more of an error as the above warnings come before the message:
Compiling...
Done--error detected
So I renamed the input.adb file to test2-input.adb as was suggested to me by AdaGIDE on compiling. Now on compiling the main file, I don't have any warnings. My question now is if it's ok to write
PROCEDURE INPUT(A,B: OUT FLOAT; N: OUT INTEGER) IS
as I did in the sub-unit file test2-input.adb or is it better to write a more descriptive term like
PROCEDURE TEST2-INPUT(A,B: OUT FLOAT; N: OUT INTEGER) IS
to emphasize that procedure input has a parent procedure test2 ? This thought follows from AdaGIDE hinting me about test2-input.adb as I mentioned above.
b) My next question:
If I understand well the compilation order, then I should compile the main file test2.adb first and then the stub test2-input.adb . On compiling the stub I get the error message:
cannot generate code for file test2-input.adb (subunit)
Done--error detected
However, I can now do the binding and linking for test2.adb and run the program .
I would like to know if I did wrong by trying to compile the stub test2-input.adb or should it not be compiled?
Q3. What is the use of having subunits? Is it just to break a large program into smaller parts? I know an error arises if one doesn't put any statements between BEGIN and END in the subunit. So this means that one always has to put a statement there. And if one wants to write the statements later, one can always put a NULL statement between between BEGIN and END in the subunit and comes back to the latter at a later time. Is this how software engineering is done in practice?
Thanks a lot...
Q1: That is excellent practice.
And by treating the package specification as a specification, you can provide it to other developers so that they will know how to interface to your code.
Q2: I believe that AdaGIDE actually uses the GNAT compiler for all compilation, so it's actually GNAT that is in charge of the acceptable filenames. (This can be configured, but unless you have a very compelling reason to do so, it is far simpler to simply go with GNAT/AdaGIDE's file naming conventions.) More pertinent to your question, though, there's no strong reason to include the parent unit as part of the separate unit's name. But see the answer to Q3...
Q3: Subunits were introduced with the first version of Ada--Ada 83--in part to help modularize code, and allow for deferred development and compilation. However, Ada software development practice has pretty much abandoned the use of subunits, all the procedure/function/task/etc bodies are simply all maintained in the body of the package. They are still used in some areas, like if a platform-specific version of subprogram may be needed, but for the most part they're rarely used. It leaves fewer files to keep track of, and keeps the implementation code of a package all together. So I strongly recommend you simply ignore the subunit capabilities and place all your implementation code in package bodies.
It's pretty normal to split a problem up into component parts (packages), each supporting a different aspect. If you've learnt Ada, it'd be normal to write the specs of the packages first, argue (perhaps with yourself) why that's the right design, and then implement them. And this would be normal, I think, in any language that supports specs and bodies - for example, C.
Personally I would do check compilations as I went, just to make sure I'm not doing anything stupid.
As for separates - one (not very good) reason is to reduce clutter, to stop the unit getting too long. Another reason (for a code generator I wrote) was so that the code generator didn't need to worry about preserving developers' hand-written code in the UML model; all code bodies were separates. A third might be for environment-dependent implementation (eg, Windows vs Unix), where you'd let the compiler see a different version of the separate body for each environment (people normally use library packages for this, though).
Compilers have their own rules about file names, and what order things can be compiled in. When GNAT sees
procedure Foo is
procedure Bar is separate;
it expects to find Foo's body in a file named foo.adb and Bar's body in foo-bar.adb (you can, I believe, tell it different - gnatmake's package Naming - but it's probably not worth the trouble). It's best to go with the flow here;
separate (Foo)
procedure Bar is
is clear enough.
You can compile foo-bar.adb, and that will do a full analysis and catch almost all errors in the code; but GNAT can't generate code for this on its own. Instead, when you compile foo.adb it includes all the separate bodies in the one generated object file. It certainly isn't wrong to do this.
With GNAT, there's no need to worry about compilation order, you can compile in any order you like. But it's best to use gnatmake and let the computer take the strain!
You can indeed work the way you describe, except of course your program won't link until all of the package bodies have some kind of implementation. For that reason, I think it is more normal to write a dummy package body with all procedures implemented as:
begin
null;
end;
And all functions implemented as something like:
begin
return The_Return_Type'first; --'
end;
As for separates...I don't like them. For me I'd much rather be able to follow the rule that all the code for a package is in its package body. Separates are marginally acceptable if for some reason the routine is huge, but in that case a better solution is almost always to refactor your code. So any time I see one, it is a big red flag.
As for the file name thing, this is a gnat issue, not an Ada issue. Gnat took the unusual position for a compiler that the name of the contents of a file dictate what the file itself must be named. There are probably other compilers in the world that do that, but I've yet to find one in 30 years of coding.