I am using Yosys to synthesize an AES core to gate level Verilog with mapping to cells from a Liberty file.
Is there a way to report the mapping of registers and memory instances from the RTL to the gate level instances/pins/nets?
This is my version:
Yosys 0.8+ 510 (git sha1 1217e47e, clang 10.0.1 -fPIC -Os)
You should see more names preserved using write_verilog -norename. In some cases, Yosys will also add a (* src = "..." *) attribute tracking the original source location.
Related
I was having trouble with the linker for the embedded arm gcc compiler, and I found a tutorial somewhere online saying that I could fix my linker errors in arm-none-eabi-gcc by including the argument -specs=nosys.specs, which worked for me, and it was able to compile my code.
My chip is an ATSAM7SE256 microcontroller, which to my understanding is an arm7tdmi processor using the armv4t and thumb instruction sets, and I've been compiling my code using:
arm-none-eabi-gcc -march=armv4t -mtune=arm7tdmi -specs=nosys.specs -o <exe_name>.elf <input_files>
And the code compiles with no issue, but I have no idea if it's doing what I think it's doing.
What is the significance of a spec file? What other values can you set with -specs=, and in what situations would you want to? Is nosys.specs the value I want for a completely embedded arm microcontroller?
It is documented at: https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Overall-Options.html#Overall-Options
It is a file containing switches to override standard defaults for various build components such as the compiler, assembler and linker. For example it can be used to replace the default C library.
I have never seen it used; typically bare-metal embedded system builds explicitly specify --nostdlib then explicitly link the required library. It could be used for environment specific build environments to link other default code such as an RTOS I guess. Personally I'd rather make all that explicit on the command line that hiding it in a file somewhere.
Essentially it applies the switches specified in the file as if they were defaults, so can be used to define defaults for specific build and execution environments.
The format of the specs file is documented at https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Spec-Files.html#Spec-Files
Without seeing both the linker errors and the content of the nosys.specs file in this case it is difficult to say how or why it solved your linker problem. The alternative solution of course would be to apply whatever switches are in the specs file directly.
I use clang, gcc (and also their arm version).
is there somewhere a documentation, where i can see which values the following 2 arguments take:
set(CMAKE_SYSTEM_NAME <value>)
set(CMAKE_SYSTEM_PROCESSOR <value>)
i cannot find any doc, where cmake lists every possible input.
i just see that you have to assign a value to those, but what options do i have?
like system name: Linux is one, how about Windows?
And then what about processors, arm, x86, x86_64 (amd64)...
would be cool if someone knows a good source of documentation.
thanks
From the CMake wiki about cross compiling:
Once the system and the compiler are determined by CMake, it loads the
corresponding files in the following order:
Platform/${CMAKE_SYSTEM_NAME}.cmake (optional, but issues a stern
warning)
Platform/${CMAKE_SYSTEM_NAME}-<compiler>.cmake
(optional)
Platform/${CMAKE_SYSTEM_NAME}-<compiler>-${CMAKE_SYSTEM_PROCESSOR}.cmake
(optional)
So, for find out all possible values for variable CMAKE_SYSTEM_NAME you could check filenames under Modules/Platform and extract the first part of every filename.
As for CMAKE_SYSTEM_PROCESSOR variable, its only purpose is to include the latter file (of 3 components in the filename). From the same wiki:
This variable is not used very much except for one purpose,
it is used to load a CMAKE_SYSTEM_NAME-compiler-CMAKE_SYSTEM_PROCESSOR.cmake file,
which can be used to modify settings like compiler flags etc. for the target.
You probably only have to set this one if you are using a cross compiler
where every target hardware needs special build settings.
I would like to write verilog that can be synthesized either using yosys (preferable) or the Lattice Radiant tool chain using Synplify (needed for encrypted IP from Lattice for example).
Most of the hard cells like the PLL have different names between the two tools.
Is there a verilog library that allows one to choose either synthesis tool with a single 'define for example?
Unfortunately not, the open source iCE40 flow was developed before Radiant existed; so used the original iCEcube primitive library (which is still the only option for devices pre-UltraPlus). For reference this is documented at http://www.latticesemi.com/~/media/LatticeSemi/Documents/TechnicalBriefs/SBTICETechnologyLibrary201608.pdf - imo it is Lattice who are at fault for failing to provide backwards compatibility with their own library...
We are experiencing bad code generation for a source file using IBM XL C/C++ at -O3 on PowerPC platforms. Its surfaces as a hang and it appears a particular loop is not broken.
The problem only surfaces under XL C/C++. Our testing regime indicates the source file is clean of undefined behavior, memory errors and other errata. We also don't receive strict/nostrict warnings from the compiler for the source file.
We want to compile the source file at -O2 instead of -O3. We want to add instrumentation, like a pragma, to the source file so it can be guarded appropriately for the compiler. The instrumentation allows others to wire-in other build systems like Cmake and Autotools and things will "just work" for them. (The necessary information is available in the source and not our makefile).
The IBM manual for the compiler is located at IBM XL C/C++ for AIX, V13.1, but damn if I can find the option.
What is the IBM XL C/C++ equivalent to #pragma GCC optimize? How do we instrument the source code to tell XL C/C++ to use -O2 instead of -O3?
An IBM XL C/C++ for AIX V13.1 option that you could use to compile that one source file at -O2 is #pragma options optimize=2. Info about it can be found online here or in the PDF here. If you want to override -O3 that has already been specified on the command line, and control it at a function level, you may use #pragma option_override(<your function name>, "opt(level, 2)"). Info about it can be found online here or in the PDF here. You can also achieve the same thing by modifying your Makefile so that one source file gets compiled at -O2 instead of -O3.
Also, are you sure the error message you reported starting with tea.cpp:27:26 came from IBM XL C/C++ for AIX V13.1? It doesn't look like it's in the format of that product's diagnostic messages.
We will continue to monitor for your comments on Stack Overflow (tagging with xlc helps us find it), but you may find you can get a faster response time if you post your questions on our forum at http://ibm.biz/xl-power-compilers-forum, which the IBM compiler development team monitors more actively.
I have tried to compile to assembler my source code with next flags:
1. -flto
2. -flto -ffat-lto-objects
3. -flto -fno-fat-lto-objects
Third one provides optimized slim LTO code as written in documentation, but I don't see any difference in the output assembly file between first and second, why?
OS: linux
Compiler: GCC 4.7
The difference between fat and non-fat object files is that fat object files contains both intermediate language as well as the normally compiled code. At linktime, if you invoke compiler without -flto, fat objects will be handled as normal object files (and LTO information discarded), while slim objects will invoke LTO optimizers because there is no way to handle them without it.
If you both compile and link with -flto, both fat and slim objects ought to give you the same binary, just slim objects will be smaller and faster to compile, because you will avoid the redundant code generation.
Probably it will be helpful to someone:
Here wrote next:
The current implementation only produces “fat” objects, effectively doubling compilation time and increasing file sizes up to 5x the original size
So as I think it's the main reason.