I have a piece of Verilog code here
$size(data);
where data is a 16-bit number.
But, it gives an error in Vivado.
error: system call size not allowed in this dialect use system Verilog mode
I have tried searching for a solution, but no luck, hence posting it here.
The error message means that the $size system function can only be used if SystemVerilog features are enabled in Vivado. One way to do so is to give your files a .sv extension.
Related
I am working on making a pretty trivial change to an old existing pascal source file. I have the source code, but need to generate a new hex file with my changes.
First, I tried compiling with "Embedded Pascal", which is the program used by my predecessor. Unfortunately, it is an unregistered copy and gives the message that the file is too large for the unregistered version. Support for and even the homepage for the project has disappeared (old), so I have no idea how I would register.
I tried a couple other compilers, "Free Pascal" and "Turbo51", and they are both giving similar errors:
Filename.pas (79): Error 36: BEGIN expected.
Linkcode $2E
^
The source code begins with
Linkcode $2E
LinkData $0A // normally 8 - make room for capacitance data
Program Main; Vector LongJmp Startup_Vector; //This inserts the start to the main routine.
uses IntLib;
I'm not well-versed in Pascal or embedded programming, but as I understand it, the Linkcode and LinkData lines are required to set up the RAM as needed. Following the "Const" and "var" declarations are subroutines that indeed start with procedure... begin... end.
I realize that Pascal is a bit out of date, but we are stuck with it and our old micro. Any ideas why previously working source code with trivial changes cannot be compiled? I am willing to consider other compilers, including paid options, if any are available with decent support. I am using Windows 10 x64 processor to compile, and flashing to an Atmel 89C51RC2.
If more source code is needed for diagnosis, please let me know what in particular, as I'll need to change some proprietary information before posting. Thanks!
Statements like linkcode and linkdata are not general, but target and compiler specific. Unless you have the know-how to reengineer to a different compiler, getting the original one is best.
Thanks to all for the information. While I didn't find an exact solution here, your comments were helpful for me to understand just how compiler-specific the Pascal code was.
In the end, I was able to get into my predecessors files and transfer registration, solving the issue for now. As suggested, I think I will port to C in the future to avoid fighting all the unsupported compiler nonsense.
I just encountered a case where Verilog module inputs were being assigned to from within the module itself!
I thought for sure this would error out any Verilog simulator, but no, one (at least) lets this pass!
How can this be?!
Isn't this just inviting an "X" tragedy, as soon as something outside the module assigns a different value to the input?
Am I REALLY missing something here?
In case it matters, the module in question came as part of a behavioral simulation library provided to us by our foundry.
The Verilog language does not have any rules about the flow of data based on port direction. The SystemVerilog LRM has a section 23.3.3.1 Port coercion that explicily describes places where inputs can be coerced to output and vice versa. However, Synthesis tools have coding requirements that prevent multiple drivers on the same signal. So if there are drivers from both inside and outside the instatiated module, you will get synthesis errors.
SystemVerilog has a number of coding styles that can catch multiple drivers on a signal as part of the simulation flow, so you don't have to wait until you get to synthesis, or use a separate linting tool.
I am using Vivado for running my Verilog codes. Even though I do not see any errors while running synthesis and implementation, bitstream cannot be built.
This is the error I get:
ERROR: [Drc 23-20] Rule violation (NSTD-1) Unspecified I/O Standard - 12 out of 12 logical ports use I/O standard (IOSTANDARD) value 'DEFAULT', instead of a user assigned specific value. This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected.
Which also suggests:
To correct this violation, specify all I/O standards. This design will fail to generate a bitstream unless all logical ports have a user specified I/O standard value defined. To allow bitstream creation with unspecified I/O standard values (not recommended), use this command:
set_property SEVERITY {Warning} [get_drc_checks NSTD-1]
NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run.
Which comes down to how can I script in Tcl using Vivado? I added the suggested command to the tcl console but I still get the same error.
I sugest you do what the tool is telling to do, which is specify IO standard for your top level ports, for example, if you have sys_rst_n top level port you may add the following line to your .xdc constraint file:
set_property IOSTANDARD LVCMOS18 [get_ports sys_rst_n]
of course you should change LVCMOS18 to match IO standard of you port.
The error you get is really not a Tcl issue.
YOU WANT to fix these IOs, otherwise you may damage your hardware.
open the routed checkpoint (dcp)
using the IO port window fix the IOs that have default IO standard (one by one if needed)
create the bitstream from the tcl window
Here's how to create a .tcl to fix this without having to re-implement the whole project:
copy the commands that ran to fix the IOs from above (from the tcl console) and put the commands in a tcl file
add this tcl file as a hook to "post route physopt" so the tcl runs automatically when this last step in the implementation flow.
if you'll be rerunning implementation in the future, you should just place the commands in the project xdc file instead.
I'm relatively new in ARM Cortex M4 series micro-controller.
When I'm trying to debug a simple project(blinky which easily just blinks a led on and off) using KEIL 5 simulator, I get an error like this:
* error 65: access violation at 0x400FE608 : no 'read' permission
* error 65: access violation at 0x400FE608 : no 'write' permission
I searched on internet for a solution, and I get this one:
http://www.keil.com/support/docs/814.htm
But actually it is not easy and not logical to mention all the addresses to which I want to access in my whole code like the method mentioned above.
could anybody suggest something else for me please?
(Actually I get this error with all projects which I intended to simulate so I can't simulate anything).
Here is the simple code which I have been using:
#define GCGPIOR (*((int*)0x400FE608))
int main(void)
{
GCGPIOR |= 0x20;
return 0;
}
and I am using this mc: TM4C1294NCPDT
I have a similar problem with KEIL V5, in a CMSIS project with LPC1768 microcontroller.
When debugging with real microcontroller as target, everything works fine. Debugging with simulator as target, when CMSIS tries to initialize the System core clock I get:
*** error 65: access violation at 0x400FC1A0 : no 'write' permission
Is this really sample code from the chip vendor? The definition of GCGPIOR should be volatile.
#define GCGPIOR (*((volatile int*)0x400FE608)))
Have you selected the correct device in the simulator/project configuration? Have you installed the Keil::TM4C_DFP device package and are you using the correct device configuration?
The problem appears to be that the memory map used by the simulator is automatically set up from the linker memory map. If you make direct memory mapped I/O accesses not known to the linker, then it will raise an exception (when this mechanism detects a bug in your code you may be glad of that - it is not a bug in uVision - it is intentional behaviour).
If the MAP command or dialogue did not work for you, Occam's razor suggest to me that you did not perform the operation correctly. You should map the entire I/O region given in your part's data sheet or user manual. It may work I suppose if you define the I/O region in the linker scatter file - but that may be getting a bit too complicated.
I'm compiling a piece of Delphi code with Free Pascal with a JVM backend.
On an off chance that someone who's involved in porting Free Pascal to the JVM back-end is reading this, here's a compilation error message I'm getting:
MyFile.j:379326: JAS Error: reference from line 10039 exceed size for short.
The file is pretty big (>6000 lines), and the functions in it are, too. So there can be some resource that's getting exhausted. Can one hint me as what exactly to to simplify to get rid of this?
Tracked down the error message to the Jasmin assembler: http://www.java2s.com/Open-Source/Java/Byte-Code/Jasmin-2.4/jas/InsnOperand.java.htm
Looks like the error manifests when there's a goto command in the bytecode assembly file that points to a label that's more than 32KB away. So it seems that block size is to blame - the assembly generator in FPC assumes the byte code for a single if/loop body fits into a 64K block. I couldn't find any goto_w commands in generated assembly - guess FPC does not emit them.
The issue was fixed in Jasmin - it now replaces goto with goto_w where appropriate. Grab a copy at ftp://ftp.freepascal.org/pub/fpc/contrib/jvm/fpcjvmutilities.zip