Near eof syntax error unexpected end of source code

I am new to this forum as well as to VERILOG!! I wrote a code for the multiplication of two 8 bit numbers using shift operator and adder ..... i have completed my code but while simulating,I am getting two error and to rectify these errors,I need your help (expert advice) :grin: this is my...

Skip to main content

Forum for Electronics

Forum for Electronics

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals… and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

  • Digital Design and Embedded Programming

  • ASIC Design Methodologies and Tools (Digital)

You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.

Error in VERILOG Code using MODELSIM !!


  • Thread starter

    Pankaj Dhingra


  • Start date

    Dec 21, 2013

Status
Not open for further replies.

  • #1

Newbie level 1

Joined
Dec 21, 2013
Messages
1
Helped
0
Reputation

0

Reaction score
0
Trophy points
1
Activity points

21


I am new to this forum as well as to VERILOG!! I wrote a code for the multiplication of two 8 bit numbers using shift operator and adder ….. i have completed my code but while simulating,I am getting two error and to rectify these errors,I need your help (expert advice) :grin:

this is my code: 1. there are two modules, first one is the TEST-BENCH (stimulus block) followed by my code !!

module multiplication_2_8bit_numbers_tb;

reg [6:0] A,B;
reg Qs,E,X,As,Bs,clk;
reg [12:0] Q;

multiplication_2_8bit_numbers_bhl multiply1 ( a,
as,
b,
bs,
rst,
e,
x,
qs,
q);

initial // intial block to initialise all register to zero
begin
e=0; x=0;qs=0;q=0;clk=0;
end

always
# 5 clk=~clk;

initial
begin
{as,a} = 11_000_101;
{bs,b} = 10_101_010;
end

initial
begin
#80 $display («{as,a}=%dn»,{as,a});
$display («{bs,b} =%dn»,{bs,b});
$display («{qs,q} =%dn»,{qs,q});
end

module multiplication_2_8bit_numbers_bhl (A, //magnitude of first number A
As, // sign bit of first number A
B, // magnitude of second number B
Bs, // sign bit of second number B
rst, // reset
E, // overload (extra bit after addition)
X, // signaling that muliplication is done
Qs, //sign bit of Q(answer after multiplication)
Q); // magnitude of Q

integer i=0;
input As,Bs,rst;
input [6:0] A,B;
output E,X,Qs,Q;
reg Qs,E,X;
reg [12:0] Q;

assign Qs = As ^ Bs; // As e-xor Bs = Qs

always@(rst,posedge clk)
begin //begin of always
if(rst)
{Qs,E,Q} = 0;
else begin // this begin is of else1
for(i=0;i<7;i=i+1)
begin //begin of for loop
if(B==1)
if(i==0) {E,Q}=A;
else begin //begin of else2
A=A<<(i-1);
{E,Q}=A+{E,Q};
end //end of esle2
else
begin //begin of else 3
if(i==0) {E,Q}=0;
else
{E,Q}=(((6+i){0})+({E,Q})); :arrow: // one error is in this line, SYNTAX ERROR —> UNEXPECTED `{‘
end //end of else3
end //end of for looP // multiplication is done
X=1’B1;
end // end of else 1
end //end of always
endmodule // THE END

:arrow: 1 MORE ERROR : error in last line near ‘EOF’ . unexpected «end of source code»

Thanks in advance!!! :)

  • #2

The tb module is incomplete. It has to be finished with endmodule before starting a new module. There may be more syntax errors.
Status
Not open for further replies.

Similar threads

  • Digital Design and Embedded Programming

  • ASIC Design Methodologies and Tools (Digital)

  • This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.

You are running a Bash script, and you see a syntax error: Unexpected end of file.

What does it mean?

This can happen if you create your script using Windows.

Why?

Because Windows uses a combination of two characters, Carriage Return and Line Feed, as line break in text files (also known as CRLF).

On the other side Unix (or Linux) only use the Line Feed character as line break.

So, let’s see what happens if we save a script using Windows and then we execute it in Linux.

Using the Windows notepad I have created a Bash script called end_of_file.sh:

#/bin/bash

if [ $# -gt 0 ]; then
  echo "More than one argument passed"
else
  echo "No arguments passed"
fi

And here is the output I get when I execute it:

[ec2-user@localhost scripts]$ ./end_of_file.sh 
./end_of_file.sh: line 2: $'r': command not found
./end_of_file.sh: line 8: syntax error: unexpected end of file 

How do we see where the problem is?

Edit the script with the vim editor using the -b flag that runs the editor in binary mode:

[ec2-user@localhost scripts]$ vim -b end_of_file.sh

(Below you can see the content of the script)

#/bin/bash^M
^M
if [ $# -gt 0 ]; then^M
  echo "More than one argument passed"^M
else^M
  echo "No arguments passed"^M
fi^M

At the end of each line we see the ^M character. What is that?

It’s the carriage return we have mentioned before. Used by Windows but not by Unix (Linux) in line breaks.

To solve both errors we need to convert our script into a format that Linux understands.

The most common tool to do that is called dos2unix.

If dos2unix is not present on your system you can use the package manager of your distribution to install it.

For instance, on my server I can use YUM (Yellowdog Updater Modified).

To search for the package I use the yum search command:

[root@localhost ~]$ yum search dos2unix
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
====================== N/S matched: dos2unix =====================================
dos2unix.x86_64 : Text file format converters

And then the yum install command to install it:

[root@localhost ~]$ yum install dos2unix
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
amzn2-core                                                   | 2.4 kB  00:00:00
amzn2extra-docker                                            | 1.8 kB  00:00:00     
Resolving Dependencies
--> Running transaction check
---> Package dos2unix.x86_64 0:6.0.3-7.amzn2.0.2 will be installed
--> Finished Dependency Resolution 

Dependencies Resolved 

==================================================================================
  Package       Arch        Version            Repository            Size
==================================================================================
 Installing:
  dos2unix      x86_64      6.0.3-7.amzn2.0.2  amzn2-core            75 k
 
 Transaction Summary
==================================================================================
 Install  1 Package

 Total download size: 75 k
 Installed size: 194 k
 Is this ok [y/d/N]: y
 Downloading packages:
 dos2unix-6.0.3-7.amzn2.0.2.x86_64.rpm                      |  75 kB  00:00:00     
 Running transaction check
 Running transaction test
 Transaction test succeeded
 Running transaction
   Installing : dos2unix-6.0.3-7.amzn2.0.2.x86_64                          1/1 
   Verifying  : dos2unix-6.0.3-7.amzn2.0.2.x86_64                          1/1 

 Installed:
   dos2unix.x86_64 0:6.0.3-7.amzn2.0.2                                                                                                                         
 Complete! 

We are ready to convert our script using dos2unix!

[ec2-user@localhost scripts]$ dos2unix end_of_file.sh 
dos2unix: converting file end_of_file.sh to Unix format ... 

And now it’s time to execute it:

[ec2-user@localhost scripts]$ ./end_of_file.sh  No arguments passed

It works!

If you are interested I have written an article that explains the basics of Bash script arguments.

Conclusion

I have found myself having to use the dos2unix command several times over the years.

And now you know what to do if you see the syntax error “Unexpected end of file” while running a Bash script 🙂


Related FREE Course: Decipher Bash Scripting

Related posts:

I’m a Tech Lead, Software Engineer and Programming Coach. I want to help you in your journey to become a Super Developer!

Table of Contents
Hide
  1. What is an unexpected EOF while parsing error in Python?
  2. How to fix SyntaxError: unexpected EOF while parsing?
    1. Scenario 1 – Missing parenthesis or Unclosed parenthesis
    2. Scenario 2: Incomplete functions along with statements, loops, try and except 
  3. Conclusion

The SyntaxError: unexpected EOF while parsing occurs if the Python interpreter reaches the end of your source code before executing all the code blocks. This happens if you forget to close the parenthesis or if you have forgotten to add the code in the blocks statements such as for, if, while, etc. To solve this error check if all the parenthesis are closed properly and you have at least one line of code written after the statements such as for, if, while, and functions.

What is an unexpected EOF while parsing error in Python?

EOF stands for End of File and SyntaxError: unexpected EOF while parsing error occurs where the control in the code reaches the end before all the code is executed. 

Generally, if you forget to complete a code block in python code, you will get an error “SyntaxError: unexpected EOF while parsing.”

Most programming languages like C, C++, and Java use curly braces { } to define a block of code. Python, on the other hand, is a “block-structured language” that uses indentation.

A Python program is constructed from code blocks. A block is a piece of Python program text that is executed as a unit. The following are blocks: a module, a function body, and a class definition. Each command typed interactively is a block.

There are several reasons why we get this error while writing the python code. Let us look into each of the scenarios and solve the issue.

Sometimes if the code is not indented properly you will get unindent does not match any outer indentation error.

Scenario 1 – Missing parenthesis or Unclosed parenthesis

One of the most common scenarios is an unclosed parenthesis (), brackets [], and curly braces {} in the Python code.

  • Parenthesis is mainly used in print statements, declaring tuples, calling the built-in or user-defined methods, etc.
  • Square brackets are used in declaring the Arrays, Lists, etc in Python
  • Curly braces are mainly used in creating the dictionary and JSON objects.

In the below example, we have taken simple use cases to demonstrate the issue. In larger applications, the code will be more complex and we should use IDEs such as VS Code, and PyCharm which detect and highlights these common issues to developers.

# Paranthesis is not closed properly in the Print Statement
print("Hello"

# Square bracket is not closed while declaring the list
items =[1,2,3,4,5


# Curly Braces is not closed while creating the dictionary
dictionary={ 'FirstName':'Jack'

Output

SyntaxError: unexpected EOF while parsing

If you look at the above code, we have a print statement where the parenthesis has not closed, a list where the square bracket is not closed, and a dictionary where the curly braces are not closed. Python interpreter will raise unexpected EOF while parsing.

Solution :

We can fix the issue by enclosing the braces, parenthesis, and square brackets properly in the code as shown below.

# Paranthesis is now closed properly in the Print Statement
print("Hello")

# Square bracket is now closed while declaring the list
items =[1,2,3,4,5]
print(items)

# Curly Braces is now closed while creating the dictionary
dictionary={ 'FirstName':'Jack'}
print(dictionary)

Output

Hello
[1, 2, 3, 4, 5]
{'FirstName': 'Jack'}

If we try to execute the program notice the error is gone and we will get the output as expected.

Scenario 2: Incomplete functions along with statements, loops, try and except 

The other scenario is if you have forgotten to add the code after the Python statements, loops, and methods.

  • if Statement / if else Statement
  • try-except statement
  • for loop
  • while loop
  • user-defined function

Python expects at least one line of code to be present right after these statements and loops. If you have forgotten or missed to add code inside these code blocks Python will raise SyntaxError: unexpected EOF while parsing

Let us look at some of these examples to demonstrate the issue. For demonstration, all the code blocks are added as a single code snippet.


# Code is missing after the for loop
fruits = ["apple","orange","grapes","pineapple"]
for i in fruits :

# Code is missing after the if statement
a=5
if (a>10):


# Code is missing after the else statement
a=15
if (a>10):
    print("Number is greater than 10")
else:


# Code is missing after the while loop
num=15
while(num<20):

# Code is missing after the method declaration
def add(a,b):

Output

SyntaxError: unexpected EOF while parsing

Solution :

We can fix the issue by addressing all the issues in each code block as mentioned below.

  • for loop: We have added the print statement after the for loop.
  • if else statement: After the conditional check we have added the print statement which fixes the issue.
  • while loop: We have added a print statement and also incremented the counter until the loop satisfies the condition.
  • method: The method definition cannot be empty we have added the print statement to fix the issue.
# For loop fixed
fruits = ["apple", "orange", "grapes", "pineapple"]
for i in fruits:
    print(i)

# if statement fixed
a = 5
if a > 10:
    print("number is greated than 10")
else:
    print("number is lesser than 10")

# if else statement fixed
a = 15
if a > 10:
    print("Number is greater than 10")
else:
    print("number is lesser than 10")


# while loop fixed
num = 15
while num < 20:
    print("Current Number is", num)
    num = num + 1


# Method fix
def add(a, b):
    print("Hello Python")


add(4, 5)

Output

apple
orange
grapes
pineapple
number is lesser than 10
Number is greater than 10
Current Number is 15
Current Number is 16
Current Number is 17
Current Number is 18
Current Number is 19
Hello Python

Conclusion

The SyntaxError: unexpected EOF while parsing occurs if the Python interpreter reaches the end of your source code before executing all the code blocks. To resolve the SyntaxError: unexpected EOF while parsing in Python, make sure that you follow the below steps.

  1. Check for Proper Indentation in the code.
  2. Make sure all the parenthesis, brackets, and curly braces are opened and closed correctly.
  3. At least one statement of code exists in loops, statements, and functions.
  4. Verify the syntax, parameters, and the closing statements

Ezoic

These few lines are not intended as a full-fledged debugging tutorial, but as hints and comments about debugging a Bash script.

Do not name your script test, for example! Why? test is the name of a UNIX®-command, and most likely built into your shell (it’s a built-in in Bash) — so you won’t be able to run a script with the name test in a normal way.

Don’t laugh! This is a classic mistake :-)

Many people come into IRC and ask something like «Why does my script fail? I get an error!». And when you ask them what the error message is, they don’t even know. Beautiful.

Reading and interpreting error messages is 50% of your job as debugger! Error messages actually mean something. At the very least, they can give you hints as to where to start debugging. READ YOUR ERROR MESSAGES!

You may ask yourself why is this mentioned as debugging tip? Well, you would be surprised how many shell users ignore the text of error messages! When I find some time, I’ll paste 2 or 3 IRC log-snips here, just to show you that annoying fact.

Your choice of editor is a matter of personal preference, but one with Bash syntax highlighting is highly recommended! Syntax highlighting helps you see (you guessed it) syntax errors, such as unclosed quotes and braces, typos, etc.

From my personal experience, I can suggest vim or GNU emacs.

For more complex scripts, it’s useful to write to a log file, or to the system log. Nobody can debug your script without knowing what actually happened and what went wrong.

An available syslog interface is logger ( online manpage).

Insert echos everywhere you can, and print to stderr:

echo "DEBUG: current i=$i" >&2

If you read input from anywhere, such as a file or command substitution, print the debug output with literal quotes, to see leading and trailing spaces!

pid=$(< fooservice.pid)
echo "DEBUG: read from file: pid="$pid"" >&2

Bash’s printf command has the %q format, which is handy for verifying whether strings are what they appear to be.

foo=$(< inputfile)
printf "DEBUG: foo is |%q|n" "$foo" >&2
# exposes whitespace (such as CRs, see below) and non-printing characters

There are two useful debug outputs for that task (both are written to stderr):

Hint: These modes can be entered when calling Bash:

Here’s a simple command (a string comparison using the classic test command) executed while in set -x mode:

set -x
foo="bar baz"
[ $foo = test ]

That fails. Why? Let’s see the xtrace output:

+ '[' bar baz = test ']'

And now you see that it’s («bar» and «baz») recognized as two separate words (which you would have realized if you READ THE ERROR MESSAGES ;) ). Let’s check it…

# next try
[ "$foo" = test ]

xtrace now gives

+ '[' 'bar baz' = test ']'
      ^       ^
    word markers!

(by AnMaster)

xtrace output would be more useful if it contained source file and line number. Add this assignment PS4 at the beginning of your script to enable the inclusion of that information:

export PS4='+(${BASH_SOURCE}:${LINENO}): ${FUNCNAME[0]:+${FUNCNAME[0]}(): }'

Be sure to use single quotes here!

The output would look like this when you trace code outside a function:

+(somefile.bash:412): echo 'Hello world'

…and like this when you trace code inside a function:

+(somefile.bash:412): myfunc(): echo 'Hello world'

That helps a lot when the script is long, or when the main script sources many other files.

Set flag variables with descriptive words

If you test variables that flag the state of options, such as with if [[ -n $option ]];, consider using descriptive words rather than short codes, such as 0, 1, Y, N, because xtrace will show [[ -n word ]] rather than [[ -n 1 ]] when the option is set.

Debugging commands depending on a set variable

For general debugging purposes you can also define a function and a variable to use:

debugme() {
 [[ $script_debug = 1 ]] && "$@" || :
 # be sure to append || : or || true here or use return 0, since the return code
 # of this function should always be 0 to not influence anything else with an unwanted
 # "false" return code (for example the script's exit code if this function is used
 # as the very last command in the script)
}

This function does nothing when script_debug is unset or empty, but it executes the given parameters as commands when script_debug is set. Use it like this:

script_debug=1
# to turn it off, set script_debug=0

debugme logger "Sorting the database"
database_sort
debugme logger "Finished sorting the database, exit code $?"

Of course this can be used to execute something other than echo during debugging:

debugme set -x
# ... some code ...
debugme set +x

Dry-run STDIN driven commands

Imagine you have a script that runs FTP commands using the standard FTP client:

ftp user@host <<FTP
cd /data
get current.log
dele current.log
FTP

A method to dry-run this with debug output is:

if [[ $DRY_RUN = yes ]]; then
  sed 's/^/DRY_RUN FTP: /'
else
  ftp user@host
fi <<FTP
cd /data
get current.log
dele current.log
FTP

This can be wrapped in a shell function for more readable code.

script.sh: line 100: syntax error: unexpected end of file

Usually indicates exactly what it says: An unexpected end of file. It’s unexpected because Bash waits for the closing of a compound command:

Note: It seems that here-documents (tested on versions 1.14.7, 2.05b, 3.1.17 and 4.0) are correctly terminated when there is an EOF before the end-of-here-document tag (see redirection). The reason is unknown, but it seems to be deliberate. Bash 4.0 added an extra message for this: warning: here-document at line <N> delimited by end-of-file (wanted `<MARKER>')

script.sh: line 50: unexpected EOF while looking for matching `"'
script.sh: line 100: syntax error: unexpected end of file

This one indicates the double-quote opened in line 50 does not have a matching closing quote.

These unmatched errors occur with:

bash: test: too many arguments

You most likely forgot to quote a variable expansion somewhere. See the example for xtrace output from above. External commands may display such an error message though in our example, it was the internal test-command that yielded the error.

$ echo "Hello world!"
bash: !": event not found

This is not an error per se. It happens in interactive shells, when the C-Shell-styled history expansion («!searchword«) is enabled. This is the default. Disable it like this:

set +H
# or
set +o histexpand

When this happens during a script function definition or on the commandline, e.g.

$ foo () { echo "Hello world"; }
bash: syntax error near unexpected token `('

you most likely have an alias defined with the same name as the function (here: foo). Alias expansion happens before the real language interpretion, thus the alias is expanded and makes your function definition invalid.

There’s a big difference in the way that UNIX® and Microsoft® (and possibly others) handle the line endings of plain text files. The difference lies in the use of the CR (Carriage Return) and LF (Line Feed) characters.

Keep in mind your script is a plain text file, and the CR character means nothing special to UNIX® — it is treated like any other character. If it’s printed to your terminal, a carriage return will effectively place the cursor at the beginning of the current line. This can cause much confusion and many headaches, since lines containing CRs are not what they appear to be when printed. In summary, CRs are a pain.

Some possible sources of CRs:

CRs can be a nuisance in various ways. They are especially bad when present in the shebang/interpreter specified with #! in the very first line of a script. Consider the following script, written with a Windows® text editor (^M is a symbolic representation of the CR carriage return character!):

#!/bin/bash^M
^M
echo "Hello world"^M
...

Here’s what happens because of the #!/bin/bash^M in our shebang:

The error message can vary. If you’re lucky, you’ll get:

bash: ./testing.sh: /bin/bash^M: bad interpreter: No such file or directory

which alerts you to the CR. But you may also get the following:

: bad interpreter: No such file or directory

Why? Because when printed literally, the ^M makes the cursor go back to the beginning of the line. The whole error message is printed, but you see only part of it!

It’s easy to imagine the ^M is bad in other places too. If you get weird and illogical messages from your script, rule out the possibility that^M is involved. Find and eliminate it!

How can I find and eliminate them?

To display CRs (these are only a few examples)

To eliminate them (only a few examples)

FIXME

Понравилась статья? Поделить с друзьями:
  • Ne is inaccessible since the communication is abnormal error code 98321
  • Ndis sys синий экран windows 7 как исправить
  • Ndis sys latencymon как исправить
  • Ndis 10400 как исправить
  • Nd3d11server unable to find any valid adapter on the system как исправить