static task verilog

SystemVerilog Static Variables & Functions

Each class instance would normally have a copy of each of its internal variables.

Each of the class objects p1 , p2 , p3 will have addr and data variables within it.

Static Variables

When a variable inside a class is declared as static , that variable will be the only copy in all class instances. To demonstrate an example we'll compare a static counter vs a non-static counter. The static counter is declared with static keyword and named as static_ctr while the normal counter variable is named as ctr . Both counters will be incremented within the new() function so that they are updated everytime an object is created.

You'll see that the static counter is shared between all class objects p1 , p2 and p3 and hence will increment to 3 when three packets are created. On the other hand, the normal counter variable ctr is not declared as static and hence every class object will have its own copy. This is the reason why ctr is still 1 after all three objects are created.

Declaring a variable as static can be very useful in cases where you want to know the total number of packets generated until a particular time.

Static functions

A static method follows all class scoping and access rules, but the only difference being that it can be called outside the class even with no class instantiation. A static method has no access to non-static members but it can directly access static class properties or call static methods of the same class. Also static methods cannot be virtual . Static function calls using class names need to be made through the scope operator :: .

Let's add in a non-static member called mode and try to call that from our static function.

It's not allowed and will result in a compilation error.

Using Tasks and Functions in Verilog

In this post we look at how we use tasks and functions in verilog. Collectively, these are known as subprograms and they allow us to write verilog code which is reusable .

As with most programming languages, we should try to make as much of our verilog code as possible reusable. This allows us to reduce development time for future projects as we can more easily port code from one design to another.

Whilst functions should be familiar to anyone with experience in other programming languages, tasks are less common in other languages.

There are two main differences between functions and tasks.

When we write a verilog function, it performs a calculation and returns a single value.

In contrast, a verilog task executes a number of sequential statements but doesn't return a value. Instead, the task can have an unlimited number of outputs

In addition to this, verilog functions execute immediately and can't contain time consuming constructs such as delays, posedge macros or wait statements

A verilog task , on the other hand, can contain time consuming constructs.

We will discuss both of these constructs in depth in the rest of this post. This includes giving examples of how we write and call functions and tasks in verilog.

Verilog Function

In verilog, a function is a subprogram which takes one or more input values, performs some calculation and returns an output value.

We use functions to implement small portions of code which we want to use in multiple places in our design.

By using a function instead of repeating the same code in several places, we make our code more maintainable .

We write the code for functions in the verilog module which we will use to call the function.

The code snippet below shows the general syntax for a function in verilog.

We must give every function a name, as denoted by the <name> field in the above example.

We can either declare the inputs inline with the function declaration or as part of the function body. The method we use to declare the input arguments has no affect on the performance of the function.

However, when we use inline declaration we can also omit the begin and end keywords if we want to.

We use the <arguments> field in the above example to declare the inputs to our function.

We use the <return_type> field to declare which verilog data type the function returns. If we exclude this part of the function declaration, then the function will return a 1 bit value by default.

When we return a value we do it by assigning a value to the name of the function. The code snippet below shows how we would simply return the input to a function. We can also simulate this example on EDA playground .

• Rules for Using Functions in Verilog

Although functions are often fairly simple, there are a few basic rules which we must follow when we write a verilog function.

One of the most important rules of a function is that they can't contain any time consuming constructs such as delays, posedge macros or wait statements.

When we want to write a subprogram which consumes time we should use a verilog task instead.

As a result of this, we are also not able to call tasks from within a function. In contrast, we can call another function from within the body of a function.

As functions execute immediately, we can only use blocking assignment in our verilog functions.

When we write functions in verilog, we can declare and use local variables . This means that we can declare variables in the function which can't be accessed outside of the function it is declared in.

In addition to this, we can also access all global variables within a verilog function.

For example, if we declare a function within a module block then all of the variables declared in that module can be accessed and modified by the function.

The table below summarises the rules for using a function in verilog.

• Verilog Function Example

To better demonstrate how to use a verilog function, let's consider a basic example.

For this example, we will write a function which takes 2 input arguments and returns the sum of them.

We use verilog integer types for the input arguments and the return types.

We must also make use of the verilog addition operator in order to calculate the sum of the inputs.

The code snippet below shows the implementation of this example function in verilog.

As we have previously discussed, there are two methods we can use to declare verilog functions and both of these are shown in the code below.

We can also simulate this example using EDA playground .

• Calling a Function in Verilog

When we want to use a function in another part of our verilog design, we have to call it. The method we use to do this is similar to other programming languages.

When we call a function we pass parameters to the function in the same order as we declared them. This is known as positional association and it means that the order we declare our arguments in is very important.

The code snippet below shows how we would use positional association to call the addition example function .

In the example below, in_a would map to the a argument and in_b would map to b.

• Automatic Functions in Verilog

We can also use the verilog automatic keyword to declare a function as reentrant .

However, the automatic keyword was introduced in the verilog 2001 standard meaning that we can't write reentrant functions when working with the verilog 1995 standard.

When we declare a function as reentrant, the variables and arguments within the function are dynamically allocated . In contrast, normal functions use static allocation for internal variables and arguments.

When we we write a normal function, all of the memory which is used to perform the processing of the function is allocated only once. This is process is known as static memory allocation in computer science.

As a result of this, our simulation software must execute the function in it's entirety before it can use the function again.

This also means that the memory the function uses is never deallocated . As a result of this, any values stored in this memory will maintain their value between calls to the function.

In contrast, functions which use the automatic keyword allocate memory whenever the function is called. The memory is then deallocated once the function has finished with it.

This process is known as automatic or dynamic memory allocation in computer science.

As a result of this, our simulation software can execute multiple instances of an automatic function.

We can use the automatic keyword to write recursive functions in verilog. This means we can create functions which call themselves to perform a calculation.

As an example, one common use case for recursive functions is calculating the factorial of a given number.

The code snippet below shows how we would use the automatic keyword to write a recursive function in verilog. We can also simulate this example using  EDA playground .

Verilog Task

We use verilog tasks to write small sections of code that we can reuse throughout our design.

Unlike functions, we can use time consuming constructs such as wait, posedge or delays (#) within a task. As a result of this, we can use both blocking and non-blocking assignment in verilog tasks.

Verilog tasks can also have any number of inputs and can also generate any number of outputs. This is in contrast to functions which can only return a single value.

These features mean tasks are best used to implement simple pieces of code which are repeated several times in our design. A good example of this would be driving the pins on a known interface, such as SPI or I2C .

We often write the code for tasks in the verilog module which will be used to call the task.

When we do this, we can also read or write any of the module's global variables inside of the task body.

We can also create global tasks which are shared by all modules in a given file. To do this we simply write the code for the task outside of the module declarations in the file.

The code snippet below shows the general syntax for a task in verilog.

As with functions, there are two ways in which we can declare a task but the performance of both approaches is the same.

We must give every task a name, as denoted by the <name> field above.

When we write tasks in verilog, we can declare and use local variables. This means that we can create variables in the task which can't be accessed outside of the task it is declared in.

In addition to this, we can also access all global variables within a verilog task.

Unlike verilog functions, we can call another task from within a task. We can also make calls to functions from within a task.

• Verilog Task Example

Let's consider a simple example to better demonstrate how to write a verilog task.

For this example, we will write a basic task which can be used to generate a pulse. The length of the pulse can be specified when we call the task in our design.

In order to do this, we must declare a single time type input in our task.

We will generate the pulse on a global reg type signal so there is no need to declare any outputs for the task.

The verilog code below shows the implementation of this example using the two different styles of task. We can also simulate this example on EDA playground .

Although this example is quite simple, we can see here how we can use the verilog delay operator (#) in a task. If we attempted to write this code in a function, this would cause an error when we tried to compile it.

We can also see from this example that we don't return a value in the same way as we do with a function.

Instead, we simply assign values to any signals that we have access to either as inputs or as global variables.

We can include and drive as many signals as we want when we write a task in verilog.

• Calling a Task in Verilog

As with functions, we must call a task when we want to use it in another part of our verilog design.

The method we use to do this is similar to the method used to call a function.

However, there is one important difference between calling tasks and functions in verilog.

When we call a task in verilog, we can't use it as part of an expression in the same way as we can a function.

We should instead think of task calls as being a short hand way of including a block of code into our design.

As with functions, we use positional association to pass paramaters to the task when we call it.

This simply means that we pass parameters to the task in the same order as we declared them when we wrote the task code.

The code snippet below shows how we would use positional association to call the pulse_generate task which we previously considered.

In this case, the pulse_length input is mapped to the pulse_time variable and the pulse output is mapped to the pulse_out variable.

• Automatic Tasks in Verilog

We can also use the automatic keyword with verilog tasks in order to make them reentrant. Again, this keyword was introduced in the verilog 2001 standard meaning it can't be used with verilog 1995 compatible code.

As we talked about previously, using the automatic keyword means that our simulation tool uses dynamic memory allocation.

As with functions, tasks use static memory allocation by default which means that only one instance of a task can be run by the simulation software.

In contrast, tasks which use the automatic keyword allocate memory whenever the task is called. The memory is then freed once the task has finished with it.

Let's consider a basic example to show automatic tasks are used and how they differ from normals task.

For this example, we will use a simple task which increments the value of a local variable by a given amount.

We can then run this a number of times in a simulation tool to see how the local variable behaves using an automatic task and a normal task.

The code below shows how we write a static task to implement this example.

Running this code in the icarus verilog simulation tool results in the following output:

As we can see from this, the value of the local variable i is static and stored in a single memory location.

As a result of this, the value of i is persistent and it maintains it's value between calls to the task.

When we call the task we are incrementing the value which is already stored in the given memory location.

The code snippet below shows the same task except that this time we use the automatic keyword.

From this we can now see how the local variable i is dynamic and is created whenever the task is called. After it has been created, it is then assigned the value of 1.

When the task has finished running, the dynamically allocated memory is freed and the local variable no longer exists.

There are two main differences between tasks and functions, what are they?

A task can have ore than one output but a function can only have one. A function can not consume time but a task can.

What is the difference between an automatic function and a normal function in verilog?

Normal verilog functions use static memory allocation whereas automatic functions use dynamic memory allocation.

Write the code for a function which takes 3 integer inputs and returns the product of them.

Write the code for a task which returns the sum of 2 numbers. However, the result should be delayed by a fixed amount of time before it is returned. The task should take three inputs - one of time type which sets the delay time and the 2 integers that will be summed together. In addition, the task should have one output which is the result of the summation.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Table of Contents

Sign Up to our Mailing List

Join our mailing list and be the first to hear about our latest FPGA themed articles and tutorials .

Task – Verilog Example

Write synthesizable and automatic tasks in verilog.

Tasks are sections of Verilog code that allow the Digital Designer to write more reusable, easier to read code. Tasks are very handy in testbench simulations because tasks can include timing delays . This is one of the main differences between tasks and functions , functions do not allow time delays .

Tasks should be utilized when the same operation is done over and over throughout Verilog code. Rather than rewriting code, one can just call the task. This reduces copy/paste errors in your code and allows quicker development time. It also makes the code much cleaner and easier to read. Yes, tasks can be synthesized!

Below is a list of rules for tasks:

• Tasks can have any number of inputs and outputs
• The order of inputs/outputs to a task dictates how it should be wired up when called
• Tasks can have time delay (posedge, # delay, etc)
• Tasks can call other tasks and functions
• Tasks can drive global variables external to the task
• Variables declared inside a task are local to that task
• Tasks can use non-blocking and blocking assignments
• Tasks can be automatic (see below for more detail)

Often tasks are created in the file they are used in. The example below demonstrates this. However tasks can also be included via the `include compile directive.

task_example.v:

The Modelsim simulation screenshot below shows the result of the operation of the task.

Automatic Tasks

Tasks can be declared as automatic tasks as of Verilog 2001.

Automatic is a term borrowed from C which allows the task to be re-entrant. A re-entrant task is one in which the items declared within the task are allocated upon every individual call of the task, as opposed to being shared between all calls of the task. This could be a problem in a simulation environment if code is forked and calls the same task at the same time. Race conditions can develop.

In C, all variables are automatic by default. In order to make them not automatic, they must be declared as static . Verilog is the opposite with tasks. All tasks are static by default and should be declared automatic if they are called simultaneously. A good practice is to declare your tasks as automatic by default. The example below displays the difference between a re-entrant task and a regular task. The non-automatic task is likely not behaving the way the user intended!

Learn Verilog

Leave A Comment Cancel reply

Save my name, email, and website in this browser for the next time I comment.

SystemVerilog Tasks

A task that may or may not consume simulation time, returns values as output or inout argument type, and may or may not take arguments.

• Automatic tasks
• Static task

Task Examples

A basic example with arguments and directions, premature task return example, static and automatic tasks.

• By default, tasks declared are static except they are declared inside a class scope. If the task is declared within class scope, they behave like an automatic task by default unless they are specifically mentioned as static tasks. We will discuss more on this concept in class (OOP) concepts.
• All variables declared in a static task are static variables unless they are specifically mentioned as an automatic variable.
• All variables declared in an automatic task are automatic variables unless they are specifically mentioned as a static variable.

To understand the scope of variables in tasks, static and automatic variables are declared in each static, automatic, and normal task.

Pass by value Tasks

A pass by value argument passing mechanism does copy arguments locally and operate on those variables. Any changes in variables in the task will not be visible outside of the task.

Default values in the argument:

If no arguments are passed, default values are considered in the function/ task otherwise, default values will be overridden in case of passing any arguments

Pass by reference Tasks

A pass by reference argument passing mechanism does not copy arguments locally but reference to the original arguments is passed. This also means that any change in values for the argument inside the subroutine will affect the original values of the variables,

The ref keyword is used to denote pass by reference arguments.

With const ref keyword

To ensure that the subroutine should not update any values, the ‘const ref’ keyword is used.

With static task

It is illegal to use pass by reference argument for static tasks.

Similarities between function and task

• Can declare a static variable in automatic function
• Can declare an automatic variable in a static function
• Both support default arguments and arguments have input direction by default unless it is specified.
• Multiple statements can be written without using a begin .. end block.
• The default argument data type is logic unless it is specified.
• Passing value by name, reference, value, and position is allowed.
• The “return” keyword is used to premature return from a task or function. The only difference is that function can return a value and a task can not return any value when the “return” keyword is used.
• By default tasks and functions are automatic in classes and they are commonly known as class methods.

Difference between function and task

System Verilog Tutorials

• Verilog functions and tasks

18 Sep 2021

When we write a code, we may need to use some line of code repeatedly in various places. Writing the same line of code leads to errors in code and decreases the readability of the code. Thus to execute the same code several times, there are functions in a programming language (also known as a subroutine). In Verilog, there are two types of subroutines, functions and tasks. A function is the same as functions in any programming language, but tasks are slightly different. Let us see them in detail.

What are subroutines?

Before learning more about functions and tasks, let us see what a subroutine is. A routine defines the execution flow of a code. A subroutine is some code that is executed only when called by the main programme. Once the execution of the subroutine is complete, the pointer moves back to the main programme.

A function, as discussed earlier, is the same as that found in other programming languages. To write a function, first, we need to declare it. This step is known as a functional declaration. After declaration, we write the function's body, which is nothing but the function's functionality and is known as a function definition. Please remember, we cannot define a function before declaring it.

Function declaration consists of 3 parts:

• Function name – This is the function's name that will be used to call the function. The name can be any valid identifier.
• Automatic - This keyword is used to make the function automatic. Detailed explanation about automatic function is discussed later in this lesson.
• Return type – This is the data type of the value that is returned by the function. If no value needs to be returned, then void is used.
• Arguments – This is the input to the functions. There can be no or even more than one argument in a function. Arguments are similar to the port list in modules.

A function is declared using a function keyword, and the function definition ends with the endfunction keyword. The function definition goes inside begin end block.

Rules to remember

In Verilog, while declaring a function, some rules need to be remembered. These rules are:

• A function should have at least one argument.
• Function argument can only have input as direction. output or inout cannot be used in function arguments.
• Function definition should have any delay statement or @ statements, as functions cannot consume time.
• Function definition should not have a non-blocking assignment or procedural-continuous assignment.

In Verilog, a task is a particular subroutine type, which can consume time. As we know, Verilog is a time-dependent simulator. Thus, in some cases, we need to provide a delay in subroutines. However, delays cannot be used in functions as they should not consume time; otherwise, a compile-time error is shown. A task helps to tackle this problem. Similar to functions, a task is also declared first and then defined. However, a task declaration does not consist of a return type. Instead, we use a port with output direction in the arguments.

In Verilog, global functions or tasks are invalid. It is only valid in System Verilog . Declaring a global function or task will give a compile-time error. The concept of global declaration will be discussed in System Verilog. This fact is mentioned here as people tend to confuse whether they can use global declaration in Verilog.

Task vs Functions

Static vs automatic.

Both functions and tasks are of 2 types, static and automatic.

By default, all functions and tasks are static in Verilog. Static tasks mean that the variable or nets declared inside a task will retain their previous value whenever the task is called. Therefore, it can be said that the memory allocated for the function or task remains the same during each call, making it static. Whereas in Automatic function or task, a new memory location is allocated each time they are called. Thus any internal variable present inside the task would not retain its previous value.

• Introduction to Verilog
• Verilog Event Semantics
• Basics of Verilog
• Verilog Syntax
• Data Types in Verilog
• Verilog Vectors
• Verilog Arrays
• Verilog Modules
• Verilog Ports
• Verilog Operators
• Verilog Procedural Blocks
• Verilog Assignments
• Different types of loops in Verilog
• Conditional Statements in Verilog
• Compiler Directives in Verilog
• Verilog System Functions
• Delays in Verilog

Introduction to SystemVerilog pp 715–743 Cite as

Tasks and Functions

• Ashok B. Mehta 2  
• First Online: 07 July 2021

2139 Accesses

This chapter discusses SystemVerilog “tasks” and “functions,” including static/automatic tasks and functions, parameterized tasks/functions, etc. Argument passing and argument binding are also discussed.

Electronic Supplementary Material The online version of this chapter ( https://doi.org/10.1007/978-3-030-71319-5_22 ) contains supplementary material, which is available to authorized users.

This is a preview of subscription content, access via your institution .

Buying options

• Available as PDF
• Read on any device
• Instant download
• Own it forever
• Available as EPUB and PDF
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info
• Durable hardcover edition

Tax calculation will be finalised at checkout

Purchases are for personal use only

Author information

Authors and affiliations.

DefineView Consulting, Los Gatos, CA, USA

Ashok B. Mehta

You can also search for this author in PubMed   Google Scholar

Rights and permissions

Reprints and Permissions

Copyright information

© 2021 The Author(s), under exclusive license to Springer Nature Switzerland AG

About this chapter

Cite this chapter.

Mehta, A.B. (2021). Tasks and Functions. In: Introduction to SystemVerilog. Springer, Cham. https://doi.org/10.1007/978-3-030-71319-5_22

Download citation

DOI : https://doi.org/10.1007/978-3-030-71319-5_22

Published : 07 July 2021

Publisher Name : Springer, Cham

Print ISBN : 978-3-030-71318-8

Online ISBN : 978-3-030-71319-5

eBook Packages : Engineering Engineering (R0)

Share this chapter

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Find a journal
• Publish with us

SystemVerilog Static Methods

Introduction.

In my last post , you learned how to create a class with a static property. This variable acts like a global variable in that only one copy exists, no matter how many objects you create. This post shows how you can create methods that access those static properties.

Any class method can read and write these static properties, just like dynamic properties. However, if you declare the method as static, you can call the method without needing to construct an object. Here is the Thing class with a static method to print the count of Thing objects. You can call Thing::print_count(), even if no Thing objects were constructed.

Static methods can only access static properties. Remember, a static property acts like a global variable in that it is always around. Dynamic properties are stored in objects. The id property only exists in individual objects, so print_count() could not see it.

Here is a simple error handler class that keeps track of how many error messages have printed and exits when you reach the maximum. Notice that there are no ErrorH handles or objects created. Copy this code and try on your simulator.

The uvm_config_db class is built on static methods, which is why you need to call with the following syntax.

Without static methods, you would have to construct a DB object, and pass its handle around to every corner of the testbench. That defeats the whole goal of simplifying sharing of configuration information.

The specialization is not shown. Look for more details in an upcoming blog post.

Enjoy your verification journey! Chris Spear

Keep learning at mentor.com/training Questions or ideas? verificationacademy.com/ask-chris-spear View my recent webinar on UVM Coding Guidelines and the Questions and Answers

What to read next:

Leave a Reply Cancel reply

You must be logged in to post a comment.

Verification Guide

SystemVerilog Static Class Members

Static class members.

Table of Contents

Class members can be created with the keyword static. class members with the keyword static are called as static class members. the class can have static properties and static methods (functions and tasks). a single copy of static variables is shared across multiple instances.

Static Properties

• The class can have multiple instances, each instance of the class will be having its own copy of variables.
• Sometimes only one version of a variable is required to be shared by all instances. These class properties are created using the keyword static .

Static Methods

Static methods are the same as static properties,

• a static method can access only static properties of the class and access to the non-static properties is illegal and lead to a compilation error.
• Static methods cannot be virtual

Note: Static class properties and methods can be used without creating an object of that type.

Static properties example

In the below example, The class has the variable packet_id, which is the unique ID assigned to the packet; Static variable no_of_pkts_created, no_of_pkts_created will get incremented on every object creation.

no_of_pkts_created is assigned to packet_id.

Simulator Output

Static method example

Below example shows the declaration of a static function.

Static method trying to access a non-static variable

In the below example, The static function tries to access the non-static variable of the class, which leads to a compilation error.

Accessing static class properties without creating an object

In the below example,

Static class variable (no_of_pkts_created) and Static class function (display_packets_created) is accessed with class handle which is not constructed (new() is not done).

❮ Previous Next ❯

Gotcha: “static” function/task in SystemVerilog

• Aurelian Ionel Munteanu
• Friday, August 5th, 2016
• gotcha , SystemVerilog

While working with static methods from SystemVerilog I found a non-intuitive behaviour that I would like to share with you. I could not find it documented anywhere within the SystemVerilog LRM.

What do static and its automatic counterpart mean?

In SystemVerilog IEEE 1800-2012 LRM (Chapter 8.10 page 141), a static method is defined as:

“A static method is subject to all the class scoping and access rules, but behaves like a regular subroutine that can be called outside the class, even with no class instantiation“

whereas automatic is seen as (Chapter 6.21 page 90):

“Variables declared in an automatic task, function, or block are local in scope, default to the lifetime of the call or block, and are initialized on each entry to the call or block.”

Simple example

We’ll use the following example to illustrate some static related aspects:

Never call a static method using an object

Since the foo() method is non-static, we need to create an object, named my_object , in order to call it. Similarly, my_object can be used to call the other two methods, foo_static_1() and foo_static_2(), but this is NOT recommended since static fields/methods don’t “belong” to objects. For static methods it is highly recommended to use the class scope resolution operator (see next chapter).

Calling a static method using the class scope resolution operator ::

Even if no object of type my_class is created, we can call the static methods by using class scope resolution operator :: like this:

Twice static?

You might have already asked yourself, what is the difference between foo_static_1 and foo_static_2 . The only difference is that foo_static_2 has an extra static keyword interpolated between the function keyword and the int return type. What does that mean? The second static keyword from foo_static_2 says that both the arguments of the method and the variables inside the method are implicitly declared as static. Let’s see this in action:

Using class scope operator, you can actually alter the value of the method’s argument. Moreover, that’s done from outside the method, without actually calling it. This is not a typical behavior than one might expect.

Each function has an implicit variable, named after the function’s name. The value of that implicit variable will be returned at the end of the function. Now, with the second static in place, we can also access this implicit variable. It’s interesting to notice that the implicit variable is set to the default value, 0, if the function has not been called yet. But, after calling the function, the implicit variable has changed to the value computed by the function. Check it out below:

What about tasks?

Tasks, usually, are time consuming methods, When they don’t consume time, they behave as functions that don’t return values. If simulation time is being consumed by the task as seen below, interesting scenarios may pop up. For example foo_static_task starts with a set of values for the argument a and variable b. The task itself does not change the values of a and b, but after a simulation delay #2 their values are not the same anymore. Argument a and variable b were changed from outside the body of the task. This is because both the method ( foo_static_task ) and the variables ( a,b ) are static:

Conclusions

A static function is useful when you need global functions encapsulated under a common scope (usually a class); e.g. mathematical functions,  string processing functions,  etc. Having a static task seems to be less useful compared to functions. An use case in which I’ve used a static task is to implement a wait task that waits as many simulation cycles as mentioned via the task’s argument. I consider these type of methods to be a kind of an utility library, stored within one utility class.

Having static function static or static task static is not that intuitive since the SystemVerilog IEEE 1800-2012 LRM doesn’t mention anything about it. Even if this distinction, between static function and static function static , is absent from the LRM, I find it important. What do you think? Do you have any scenarios where using static function static , is helpful? Share your thoughts on this.

Tudor Timi August 8th, 2016 09:41:52

You seem to be confusing concepts. There is the concept of ‘static’ and ‘dynamic’ (i.e. being called on classes or objects) and ‘static’ and ‘automatic’ (i.e. lifetime). It’s unfortunate that SV uses the same keyword for two different concepts. Normal ‘staticness’ (the one we’re used to in OOP) is defined in section 8.10 Static methods. Lifetime is defined in 13.3.1 Static and automatic tasks.

The ‘double static’ you talk of is a static class method with static lifetime. The behavior you see (variables carrying over across invocations and allowed to be referenced) is as per the LRM for statically allocated methods.

Aurelian Ionel Munteanu August 10th, 2016 18:30:43

I think that most would agree that ‘static function static’ looks strange and this is what I tried to illustrate and explain. First ‘static’ is for the function, second ‘static’ is for the variables.

Speaking of confusion, how do you see static class variables? They are ‘static’ as opposed to ‘dynamic’ (to paraphrase you “being accessed on classes, not on objects”)? Or do they have a ‘static’ lifetime? Both?

Tudor Timi August 18th, 2016 00:58:10

Well, the whole concept of static (as opposed to automatic) is pretty strange for a programmer. I guess it has something to do with RTL modeling and it’s leftover baggage from Verilog, but I’m just speculating here.

Since this concept (of static/automatic lifetime) is defined for methods, I don’t think we can can reason about it when talking about static class variables.

Tim October 17th, 2022 14:10:13

It’s not very strange for a C++ programmer since these are exactly the same as in C++ (as far as I can tell). It also has the same overloading of `static` to mean two slightly different things. The only difference with SV is the crazy ability to access arguments and return values directly, and the weird syntax to change all variable declarations to static or automatic. In C++ they’re all automatic unless you explicitly set each one to static.

The C++ equivalent would be:

Note that you can’t access `b` at all from outside its function (this is the correct behaviour; SV is insane here).

The reason for static functions is obvious. The reason for static variables is less obvious. They are equivalent to global variables in all ways except scope. So instead of writing

You could easily just write:

The reasons to use the former approach are:

1. It logically groups `b` into the place where it is actually used, and (in C++, but apparently not SV!) it prevents other bits of code from accessing it. 2. It avoids stack allocation. This is a crazy crazy not at all important stupid optimisation that you should never care about.

Maybe there are more subtleties in SV but in C++ you should *almost* never use `static` variables. They are a huge red flag.

Tudor Timi August 18th, 2016 01:01:16

Also, I have to nit-pick and say that you’re making an “unfair” side-by-side comparison right in the beginning of the post where you define what static (as in static/dynamic) and automatic (as in static/automatic) are.

Aurelian Ionel Munteanu September 2nd, 2016 13:06:33

Well, the standard allows for such comparisons since it uses the same keyword for 2 separate concepts. If the standard would be clear and it would separate them in a clear way, such ambiguities would go away.

If you would ask me, I would rename the keyword for defining static / automatic lifetime with the keywords static_lifetime and automatic_lifetime .

Also keep in mind that there is no such “dynamic” as opposed to static the standard only talks about static and non-static (which is not a keyword). The standard defines the class_item_qualifier::= static | protected | local . So, when it talks about non-static most probably it refers to the keywords protected and local .

Dave Rich December 6th, 2016 20:09:06

The twice static function foo_static_2 is illegal in the IEEE 1800-2012 standard. Class methods always have automatic lifetimes and you cannot change that anymore.

Aldo Tamaela June 29th, 2017 12:30:57

In 13.3.1, only “tasks” within class are always automatic lifetime. In other word, it is still possible to define “function” within class with static lifetime. So twice static function within class is legal.

Arun Dsouza November 7th, 2017 21:44:27

@Aldo Tamaela, I think you missed 13.4.2 which says the same thing as 13.3.1 w.r.t. functions. Section 8.6 clarifies that “The lifetime of methods declared as part of a class type shall be automatic. It shall be illegal to declare a class method with a static lifetime.”

Leave a Comment: Cancel reply

Your comment will be visible after approval.

Save my name, email, and website in this browser for the next time I comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Recent Posts

• 64b66b encoding
• 8b10b encoding
• Agile&Scrum
• AMIQ Education Program
• Co-emulation
• CoverageLens
• deep learning
• formal verification
• functional coverage
• functional verification
• functional verification pattern
• IEEE P1800.2
• IEEE1800 Standard
• Machine Learning
• methodology
• portable stimulus
• project management
• randomization
• recommended articles
• register model
• regression automation
• Robochallenge
• stimulus generation
• SystemVerilog
• SystemVerilogAssertion
• utility library
• verification
• verification automation

Privacy Overview

© 2003-2023 AMIQ Consulting - ALL Rights Reserved. Privacy Policy .

404 Not found

• Open access
• Published: 07 December 2023

Does lower extremity alignment during normal stance predict lower limb kinematics and kinetics during drop landings?

• Mark G.L. Sayers 1 ,
• Robert L. Buhmann 1 ,
• Tyler J. Collings 1 , 2 ,
• Daniel B. Mellifont 1 &
• Max C. Stuelcken 1  

BMC Sports Science, Medicine and Rehabilitation volume  15 , Article number:  167 ( 2023 ) Cite this article

68 Accesses

Metrics details

Static lower extremity alignment (LEA) during normal stance has been used clinically as a tool to determine the presence of known anterior cruciate ligament (ACL) risk factors during dynamic tasks. Previous work investigating the relationship between static LEA during normal stance and risk factors for ACL injury is limited by the use of imprecise methods or because it focuses on knee valgus only and no other potentially important variables. The aim of this investigation was to determine the relationships between static LEA and the corresponding LEA during drop landings.

Forty-one female athletes were recruited for the study (age: 19.8 ± 2.5 years, height: 1.73 ± 0.06 m, mass: 64.03 ± 6.66 kg). Lower limb kinematic data were collected using a 10 camera infrared motion capture system (500 Hz) with retro-reflective markers placed over key anatomical landmarks. This system was linked to two force platforms (1000 Hz) with subsequent three-dimensional kinematic and kinetic data developed using standard software (Visual3D). Following an appropriate warm-up, data collection involved participants standing with their arms partially abducted to record static LEA. This was following by a series of drop landings from a 0.4 m box onto the force platforms. Maximum LEA data during drop landings were then compared with static LEA.

Analyses showed that in comparison to static stance, during landings the anterior tilt of the pelvis decreased while hip abduction and knee internal rotation increased. At best, static LEA variables were moderately correlated (r = -0.51 to 0.58) with peak values measured during drop landings. Additionally, regression analysis did not yield any significant predictors of any key peak hip or knee variables measured during drop landings (p = 0.15 to 0.89).

When combined, the poor relationships observed between kinematics during static LEA and LEA during drop landings calls into question the practice of using static measures to predict LEA during even simple landing tasks. These findings suggest static assessments of LEA may have minimal value as an ACL injury screening tool.

Peer Review reports

Introduction

Rupture of the anterior cruciate ligament (ACL) is a debilitating injury requiring extensive and expensive rehabilitation with substantial time lost from sport participation [ 1 ]. More than 70% of ACL injuries are non-contact in nature [ 2 ] and occur typically during landing, sudden deceleration, or cutting tasks [ 1 , 3 , 4 , 5 ]. Research on risk factors for non-contact ACL injury is extensive and acknowledges that the aetiology is multifactorial in nature [ 3 , 6 , 7 ]. The consensus is that certain movement patterns during landing and/or cutting tasks such as reduced knee flexion [ 3 , 8 , 9 ], excessive knee valgus [ 3 , 10 ] and internal rotation [ 11 , 12 ] and excessive frontal plane loading on the knee [ 10 , 13 , 14 ] are all linked to an increased likelihood of ACL injury. Similarly, reduced hip flexion [ 3 , 8 , 9 ], and excessive hip adduction [ 15 ] and internal rotation [ 15 , 16 , 17 ] during jump landing tasks are all suggested to increase the ACL injury risk. Key consensus statements in this domain highlight that the identification of these modifiable risk factors is an important precursor for the development of effective injury prevention programs [ 7 , 18 ].

Not surprisingly, a considerable body of literature focuses on the development of efficacious ACL injury screening tools [ 7 , 10 , 18 , 19 , 20 ]. A common approach supports the use of static postural assessments as part of the athlete injury screening processes [ 21 ]. Researchers in this domain focus on the links between static lower extremity alignment (LEA) during normal stance [ 22 , 23 , 24 , 25 , 26 , 27 , 28 ] and the biomechanics associated with ACL injury risk during dynamic tasks. Typically, these studies use inclinometers, goniometry or 2-dimensional images to quantify variables such as anterior pelvic tilt, frontal plane alignment of both the femur (relative to the pelvis) and tibia (relative to the femur), sagittal plane alignment of the tibia (relative to the femur) and bilateral tibia and femoral lengths [ 23 , 24 , 25 , 26 ]. However, care should be taken when interpreting these data as the inter-tester reliability for some of these measures is often poor (e.g. pelvic tilt [ 23 ]) and questions have been raised about the absolute precision of these techniques [ 23 , 27 ].

To address issues with two dimensional and/or manual data collection techniques, Nilstad, Krosshaug, Mok, Bahr and Andersen [ 22 ] used a different approach to assess static LEA, collecting data from static calibration trials performed prior to standard infra-red motion capture. These data were compared subsequently with assessments of 3-dimensional lower limb kinematics during drop landing tasks. Notably, the focus of the research by Nilstad, Krosshaug, Mok, Bahr and Andersen [ 22 ] was on the prediction of peak landing knee valgus angles only, concluding that just 11% of the variance in this variable is explained by the combination of increased standing height and static knee valgus. The focus on a single variable by these researchers is limiting, with other researchers noting that static LEA variables are part of the lower limb kinetic chain and do not function independently [ 25 , 29 ]. In an attempt to address the latter Nguyen, Shultz and Schmitz [ 26 ] clustered participants from manual static LEA assessments into those with knee valgus and either internal (C1) or external hip rotation (C3) and those with neutral hip and knee alignment (C2) prior to assessing lower limb kinematics and kinetics during drop landings. They reported participants with static knee valgus alignments (C1 and C3) also demonstrated biomechanics associated with greater risk of ACL injury during drop landings, highlighting the value of using gross LEA measures. In a later study using similar protocols to these researchers Uota, Nguyen, Aminaka and Shimokochi [ 30 ] reported significant relationships between measures of static hip internal rotation and knee valgus during drop landings. Importantly these researchers indicated stronger correlations between hip and knee angular motion during the drop landings than between any of these data and static LEA measures. The data collection methods in these studies (i.e. manual assessment of static LEA and electro-magnetic motion capture) rely on different processes to quantify limb position and so some care should be taken when interpreting these data as they may not be comparable. To address the latter, it would appear advantageous to use infra-red motion capture to determine both static LEA and dynamic lower extremity kinematics as systems such as these provide good to excellent within and between test reliability [ 31 ].

Accordingly, the purpose of this investigation was to examine the relationships between static LEA and lower extremity kinematics and kinetics during a series of drop landings. To address issues relating to consistency in static LEA assessments, these will be quantified using the static captures that form part of standard motion capture protocols. Analyses will focus on quantifying the relationships between static LEA variables and the key kinematic and kinetic variables during drop landings that are known risk factors for ACL injury [ 3 , 8 , 10 , 13 , 14 , 15 , 16 , 17 ]. The potential findings of this work will add to the literature by assessing relationships between static LEA and lower limb kinematics and kinetics during this fundamental injury movement screening task.

Forty-one female athletes provided their written informed consent prior to participating in this investigation (age: 19.8 ± 2.5 years, height: 1.73 ± 0.06 m, mass: 64.03 ± 6.66 kg). Female athletes were chosen as this group is 3–5 times more likely to sustain an ACL injury than males competing in similar sports [ 32 ]. All participants were actively involved in sports requiring lower limb power and change of direction ability and competed regularly in state-wide competitions. Inclusion criteria required participants to be both injury free at the time of data collection and to also not have sustained an injury in the preceding 2 months that prevented them from participating in sport for more than 2 weeks. Participants also had to report no joint instability or pain, no history of lower limb or back surgery and were also excluded if they were pregnant. This study was approved by the institutional ethics committee (A/16/878), with all data collection and analysis conducted in accordance with national guidelines and regulations.

Testing occurred during a single session. At the completion of a 10 min self-structured warm-up, which included standard lower body locomotor activities and several practice drop landings, participants were then asked to stand in their “normal stance” for a 3 s data capture with each foot on one of two force platforms (Bertec, Columbus, OH, USA). Data from this static capture were used to define the participants’ static LEA and segmental lengths during the modelling procedures. Following the collection of static data, participants performed a series of six drop landings. The drop landing was chosen as it is one of the most common tasks used to investigate landing biomechanics as a screening tool for ACL injury risk [ 33 ]. Standard drop landing test protocols were followed requiring participants to step off a 0.40 m high wooden box, minimising lowering or raising the centre of mass (COM) prior to take-off, before dropping and landing on both feet [ 33 ]. There was a rest period of at least 30 s between each trial to minimise the effect of fatigue.

Prior to testing 30 retroreflective spherical markers (10 mm) were placed adjacent to standard anatomical landmarks on the torso, pelvis, thighs, shanks and shoes, with rigid clusters attached bilaterally to the lateral mid shank and thigh [ 34 ]. Marker trajectories were recorded at 500 Hz using a 10-camera system (Qualisys Motion Capture System, Gothenburg, Sweden), while ground reaction force (GRF) data were recorded at 1000 Hz. Subsequent 3D motion capture and GRF data were then imported into Visual 3D (C-Motion, Inc., Rockville, MD, USA) where a standard seven segment model of the pelvis and lower limbs was constructed. Marker trajectories were filtered using a low pass, fourth order (zero lag), 12 Hz Butterworth filter, while GRF data were filtered at 38 Hz with cut-off frequencies determined using residual analyses. A global reference system was defined relative to the static capture positions so that the positive Y-axis was directed anteriorly, the X-axis laterally (positive direction to the right) and the positive Z-axis pointing vertically upwards. Joint angles were calculated between adjacent segments with flexion, adduction (and inversion) and internal rotation defined as positive rotations about each segment’s respective X, Y and Z-axes. [ 34 ]. External joint moments were calculated with the proximal segment as the resolution coordinate system using standard inverse dynamic procedures and were normalised to body weight (BW) multiplied by height (m). The GRF data were normalised to BW.

Peak values for biomechanical variables were extracted during the landing phase of each trial, with the latter defined as the period from initial ground contact (indicated by a vertical GRF greater than 10 N) to the instance of maximum knee flexion. Variables of particular interest during the landing phase were those linked to risk factors for ACL injury such as large knee valgus angles and moments [ 10 ], high peak GRF vert [ 4 ], and low knee and hip flexion angles [ 4 ]. External joint moments were calculated with the proximal segment as the resolution coordinate system using standard inverse dynamic procedures and were normalised to body weight (BW) multiplied by height (m). The vertical GRF data (GRF vert ) were normalised to body weight (BW) [ 9 ]. All data used in this investigation are available in the associated data set that has been provided with this manuscript.

Shapiro-Wilks tests for normality were conducted for static LEA variables and the equivalent peak values from the landing phase (SPSS Inc., Chicago, IL). Potential differences between static LEA and landing phase data were tested using paired t- tests or equivalent non-parametric procedures. This was particularly relevant for the frontal and transverse plane LEA values, as there are obvious increases in hip and knee flexion during landing to facilitate shock attenuation. Effect sizes (Cohen’s d ) were calculated with the relative magnitude of these effects interpreted as either trivial (< 0.20), small (0.20 to 0.60), moderate (0.60 to 1.20), large (1.20 to 2.00), or very large (> 2.00) [ 35 ]. A priori power analysis (G*Power version 3.1.9.6) indicated that the minimum sample size required to achieve 80% power to detect a medium change ( P  = 0.05) in the frontal and transverse plane data was n  = 34. In an endeavour to compare our data to that developed by Nguyen, Shultz and Schmitz [ 26 ] we assessed for potential clustering of static LEA groupings using the same Ward hierarchical clustering techniques adopted by these researchers. However, no clear clusters centring on static knee valgus orientation were apparent in our data and so this procedure was not continued. Pearson Product Moment correlation tests were conducted to determine the relative relationships between these static LEA and drop landing data. The descriptors small (0.1), moderate (0.3), large (0.5), very large (0.7) and extremely large (0.9) were used to describe the relative strength of the correlation coefficients [ 35 ]. Multiple linear regression analyses were used to determine whether any combination of static LEA variables significantly determined peak values in lower limb alignment during landing. In order to avoid any assumptions of symmetry, all analyses were conducted with respect to side (i.e. Left or Right). Significance for all statistical tests was set at P  < 0.05 and all data are presented as means ± 1 standard deviation (SD) unless stated otherwise.

Mean static LEA values indicate that participants’ typical standing posture was characterised by slight anterior pelvic tilt, hip adduction and external rotation and neutral frontal and transverse plane knee alignment (Table  1 ). The sample population presented with a heterogeneous static LEA, with SD values for hip and knee being 0.7 to 5.3 times the magnitude of the respective means. In comparison to static stance, during the landing phase of the drop landing the pelvis became less anteriorly tilted, the hips became more abducted, and the knees became more internally rotated and moved into valgus. The transverse plane alignment of the hips were the only data to present with non-significant trivial to small changes between the static LEA and landing phase. Participants flexed their hips and knees during landing, with approximately 17° less flexion at their hips than at their knees. Peak GRF vert together with the hip and knee valgus and internal rotation moments during the landing phase are presented in Table  2 .

None of the static LEA variables achieved more than moderate correlations with the peak values for lower limb alignment recorded during the landing phase (Tables  3 and 4 ). Similarly, none of the static LEA variables used previously [ 22 ] combined significantly during the step-wise multiple regression analyses to predict peak values for any of the peak hip or knee variables during the landing task (P = 0.148 to 0.886).

This investigation examined the relationships between static LEA and lower extremity kinematics and kinetics during a series of drop landings. Static postural assessments are a common component of the athlete injury screening processes [ 21 ]. In our project, static LEA was quantified using the static captures that form part of standard motion capture protocols, with these data compared directly with LEA data during the drop landings. The specific focus of our analysis was to assess the efficacy of using these static LEA data to predict the key kinematic and kinetic variables during drop landings that are known risk factors for ACL injury [ 3 , 8 , 10 , 13 , 14 , 15 , 16 , 17 ].

Our static LEA hip data shows the typical static posture of this sample of athletic females is characterised by a combination of slight bilateral hip adduction and external rotation. These adduction data are similar to those from earlier studies assessing frontal hip LEA using goniometers and two-dimensional images [ 23 , 24 , 25 , 26 ]. Similarly, our peak hip kinematic and kinetic data during the drop landing task are comparable to published data from studies using similar protocols and data capture techniques [ 16 , 36 ]. The first key finding from our analyses concerns the poor relationships between static hip LEA and our lower limb kinematic and kinetic data during landing. This highlights the potential risks involved in using static stance measures to estimate lower limb motion and joint moments during drop landing tasks. Clinicians and trainers should be wary of assuming that an individual’s hip orientation during static stance provides a useful indicator of hip movements during landing tasks.

Our static LEA knee data shows this sample of athletic females presented typically with neutral knee alignment. The reported values are analogous to data from earlier research using similar procedures to determine static frontal plane knee alignment [ 22 ]. Our varus/valgus data are considerably smaller than the tibiofemoral angle data reported from frontal plane imagery and/or goniometry [ 23 , 24 , 25 , 26 ]. Differences between these data (~ 8° less in this study) highlights that care should be taken before comparing studies that use different techniques to measure similar variables. Importantly, participants’ static varus/valgus knee alignment achieved only small non-significant correlations with the corresponding peak values during the drop landing task. This finding diverges from research indicating that individuals with static valgus knee alignments present with greater knee valgus during drop landing tasks than those with neutral knee alignments [ 22 , 26 ]. Differences between our data and those of Nguyen, Shultz and Schmitz [ 26 ] are likely to be a function of a combination of the lower level athletes (recreationally active participants in their study versus our well trained athletes) and the exaggeration of these alignments caused by the use of goniometry for assessing static knee varus/valgus alignment [ 26 ]. Similarly, the research by Nilstad, Krosshaug, Mok, Bahr and Andersen [ 22 ] was based on drop vertical jump landings, tasks that results in different muscle activity and greater ground reaction forces than drop landings [ 37 ]. Regardless of these differences, the relatively poor relationships between static knee LEA and our lower limb kinematic and kinetic landing data again questions the practice of using static stance measures to estimate lower limb kinematics and kinetics during drop landing tasks.

The findings in this study also need to be considered in relation to the relative simplicity of the drop landing task itself. Although there is some argument regarding the representativeness of this movement to sport specific landing tasks (see review by Collings, Gorman, Stuelcken, Mellifont and Sayers [ 33 ]), a drop landing test is easy to perform and allows researchers to minimise the exposure of study participants to potential injury risk factors. However, it would appear that even relatively minor manipulations in task constraints during landings can have profound effects on the usefulness of static LEA testing. For example, the methods for assessing static LEA and landing kinematics and kinetics in this study are almost identical to those presented by Nilstad, Krosshaug, Mok, Bahr and Andersen [ 22 ], with the fundamental difference between these investigations centring on their use of a drop vertical jump instead of a drop landing. In contrast to these findings Barrios, Heitkamp, Smith, Sturgeon, Suckow and Sutton [ 28 ] show that participants with greater static knee valgus alignment (approximately 3°- 4°) present with greater knee valgus during walking, running and in single leg drop landings. However, the differences in these data between their control and experimental groups was typically the same magnitude as the difference that defined each group (i.e. less than 4°), suggesting these alignments are not altered during these dynamic tasks. In research investigating complex movements such as side-stepping (cutting), Mueske, Abousamra, Katzel, Vandenberg, Pace, Feifer and Wren [ 38 ] indicate that static assessments of frontal plane knee alignment do not contribute to the prediction of dynamic knee valgus moments. These researchers highlight that dynamic measures of trunk, pelvic and LEA provide more useful predictors of knee valgus moments during these tasks than any static postural variables. It would appear that the usefulness of static LEA testing as a predictive tool for assessing dynamic landing activities decreases markedly with even relatively small changes in task constraints. While some static LEA variables are associated with some knee and hip kinematic and kinetic variables during drop landing tasks, these relationships are typically small . When combined with other research in this domain, we question the efficacy of static LEA assessments for the determination of landing techniques during dynamic tasks.

There are obvious limitations associated with this project. The static position was not standardised between participants, with participants instructed to stand in “normal stance” with feet approximately shoulder width apart. The measures of static LEA in our participants were typical of the research in this domain but may not have been extreme enough to result in changes during the drop landing task [ 38 ]. Most importantly, our results may be representative of our test population only and may not be generalizable to other sports, age groups, or competition levels. Static LEA assessment may be a useful tool for determining landing performance for athletes with previous injury, as research highlights differences in the landing mechanics adopted by participants following ACL reconstruction [ 39 ]. It is therefore possible that static LEA assessment may be a useful predictive tool with these populations. Similarly, our data are limited to well-trained female athletes and so may not be representative of male and/or untrained athletes [ 9 , 16 ]. We also focussed primarily on the use of static LEA assessments to predict the key kinematic and kinetic variables during drop landings that are known risk factors for ACL injury. It is possible that static LEA can be used to predict other variables associated with drop landing technique.

Conclusions

This investigation examined the relationships between static LEA and lower extremity kinematics and kinetics during a series of drop landings in well trained female athletes. Results question the use of static LEA as a predictive tool for the determination of the key kinematic and kinetic variables that are known risk factors for ACL injury during these tasks. Clinicians and trainers should be wary of assuming that an individual’s static stance provides a useful indicator of their lower limb kinematics and kinetics during drop landings.

Data Availability

All data generated or analysed during this study are included in this published article [and its supplementary information files ].

Webster KE, Hewett TE. Meta-analysis of meta-analyses of anterior cruciate ligament injury reduction training programs. J Orthop Res. 2018;36(10):2696–708.

Article   PubMed   Google Scholar  

Yoo JH, Lim BO, Ha M, Lee SW, Oh SJ, Lee YS, Kim JG. A meta-analysis of the effect of neuromuscular training on the prevention of the anterior cruciate ligament injury in female athletes. Knee Surg Sports Traumatol Arthrosc. 2010;18(6):824–30.

Hewett TE, Myer GD, Ford KR. Anterior cruciate ligament injuries in female athletes - part 1, mechanisms and risk factors. Am J Sports Med. 2006;34(2):299–311.

Leppänen M, Pasanen K, Krosshaug T, Kannus P, Vasankari T, Kujala UM, Bahr R, Perttunen J, Parkkari J. Sagittal plane hip, knee, and ankle biomechanics and the risk of anterior cruciate ligament injury: a prospective study. Orthop J Sports Med. 2017;5(12):2325967117745487.

Article   PubMed   PubMed Central   Google Scholar  

Stuelcken MC, Mellifont DB, Gorman AD, Sayers MG. Mechanisms of anterior cruciate ligament injuries in elite women’s netball: a systematic video analysis. J Sports Sci. 2016;34(16):1516–22.

Hewett TE, Myer GD, Ford KR, Paterno MV, Quatman CE. Mechanisms, prediction, and prevention of ACL injuries: cut risk with three sharpened and validated tools. J Orthop Res. 2016;34(11):1843–55.

Shultz SJ, Schmitz RJ, Cameron KL, Ford KR, Grooms DR, Lepley LK, Myer GD, Pietrosimone B. Anterior cruciate ligament research retreat viii summary statement: an update on injury risk identification and prevention across the anterior cruciate ligament injury continuum, march 14–16, 2019, greensboro, Nc. J Athl Train. 2019;54(9):970–84.

Yu B, Garrett WE. Mechanisms of non-contact ACL injuries. Brit J Sport Med. 2007;41(Suppl 1):i47–i51.

Article   Google Scholar  

Decker MJ, Torry MR, Wyland DJ, Sterett WI, Steadman JR. Gender differences in lower extremity kinematics, kinetics and energy absorption during landing. Clin Biomech. 2003;18(7):662–9.

Hewett TE, Myer GD, Ford KR, Heidt RS Jr., Colosimo AJ, McLean SG, van den Bogert AJ, Paterno MV, Succop P. Biomechanical measures of neuromuscular control and valgus loading of the knee predict anterior cruciate ligament injury risk in female athletes: a prospective study. Am J Sports Med. 2005;33(4):492–01.

Beaulieu ML, Oh YK, Bedi A, Ashton-Miller JA, Wojtys EM. Does limited internal femoral rotation increase peak anterior cruciate ligament strain during a simulated pivot landing? Am J Sports Med. 2014;42(12):2955–63.

Shin CS, Chaudhari AM, Andriacchi TP. Valgus plus internal rotation moments increase anterior cruciate ligament strain more than either alone. Med Sci Sports Exerc. 2011;43(8):1484–91.

Frank B, Bell DR, Norcross MF, Blackburn JT, Goerger BM, Padua DA. Trunk and hip biomechanics influence anterior cruciate loading mechanisms in physically active participants. Am J Sports Med. 2013;41(11):2676–83.

Myer GD, Ford KR, Di Stasi SL, Foss KD, Micheli LJ, Hewett TE. High knee abduction moments are common risk factors for patellofemoral pain (PFP) and anterior cruciate ligament (ACL) injury in girls: is pfp itself a predictor for subsequent acl injury? Br J Sports Med. 2015;49(2):118–22.

Powers CM. The influence of abnormal hip mechanics on knee injury: a biomechanical perspective. J Orthop Sports Phys Ther. 2010;40(2):42–51.

Fox AS, Bonacci J, McLean SG, Spittle M, Saunders N. What is normal? Female lower limb kinematic profiles during athletic tasks used to examine anterior cruciate ligament injury risk: a systematic review. Sports Med. 2014;44(6):815–32.

McLean SG, Huang X, van den Bogert AJ. Association between lower extremity posture at contact and peak knee valgus moment during sidestepping: implications for ACL injury. Clin Biomech. 2005;20(8):863–70.

Shultz SJ, Schmitz RJ, Benjaminse A, Collins M, Ford KR, Kulas AS. ACL research retreat vii: an update on anterior cruciate ligament injury risk factor identification screening, and prevention. J Athl Train. 2015;50(10):1076–93.

Padua DA, DiStefano LJ, Beutler AI, de la Motte SJ, DiStefano MJ, Marshall SW. The landing error scoring system as a screening tool for an anterior cruciate ligament injury-prevention program in elite-youth soccer athletes. J Athl Train. 2015;50(6):589–95.

Myer GD, Ford KR, Hewett TE. New method to identify athletes at high risk of ACL injury using clinic-based measurements and freeware computer analysis. Br J Sports Med. 2011;45(4):238–44.

Brukner P, Khan K. Brukner & Khan’s clinical sports medicine. Volume 1: injuries. 5th ed. North Ryde, N.S.W: McGraw-Hill Education Australia; 2017.

Google Scholar  

Nilstad A, Krosshaug T, Mok KM, Bahr R, Andersen TE. Association between anatomical characteristics, knee laxity, muscle strength, and peak knee valgus during vertical drop-jump landings. J Orthop Sports Phys Ther. 2015;45(12):998–1005.

Nguyen AD, Boling MC, Slye CA, Hartley EM, Parisi GL. Various methods for assessing static lower extremity alignment: implications for prospective risk-factor screenings. J Athl Train. 2013;48(2):248–57.

Nguyen AD, Shultz SJ. Sex differences in clinical measures of lower extremity alignment. J Orthop Sports Phys Ther. 2007;37(7):389–98.

Nguyen AD, Shultz SJ. Identifying relationships among lower extremity alignment characteristics. J Athl Train. 2009;44(5):511–8.

Nguyen AD, Shultz SJ, Schmitz RJ. Landing biomechanics in participants with different static lower extremity alignment profiles. J Athl Train. 2015;50(5):498–507.

Shultz SJ, Nguyen AD, Windley TC, Kulas AS, Botic TL, Beynnon BD. Intratester and intertester reliability of clinical measures of lower extremity anatomic characteristics: implications for multicenter studies. Clin J Sport Med. 2006;16(2):155–61.

Barrios JA, Heitkamp CA, Smith BP, Sturgeon MM, Suckow DW, Sutton CR. Three-dimensional hip and knee kinematics during walking, running, and single-limb drop landing in females with and without genu valgum. Clin Biomech. 2016;31:7–11.

Riegger-Krugh C, Keysor JJ. Skeletal malalignments of the lower quarter: correlated and compensatory motions and postures. J Orthop Sports Phys Ther. 1996;23(2):164–70.

Article   CAS   PubMed   Google Scholar  

Uota S, Nguyen AD, Aminaka N, Shimokochi Y. Relationship of knee motions with static leg alignments and hip motions in frontal and transverse planes during double-leg landing in healthy athletes. J Sport Rehabil. 2017;26(5):396–405.

Ford KR, Myer GD, Hewett TE. Reliability of landing 3d motion analysis: implications for longitudinal analyses. Med Sci Sports Exerc. 2007;39(11):2021–8.

Prodromos CC, Han Y, Rogowski J, Joyce B, Shi K. A meta-analysis of the incidence of anterior cruciate ligament tears as a function of gender, sport, and a knee injury-reduction regimen. Arthroscopy. 2007;23(12):1320–5. e6.

Collings TJ, Gorman AD, Stuelcken MC, Mellifont DB, Sayers MGL. Exploring the justifications for selecting a drop landing task to assess injury biomechanics: a narrative review and analysis of landings performed by female netball players. Sports Med. 2019;49(3):385–95.

Wu G, Siegler S, Allard P, Kirtley C, Leardini A, Rosenbaum D, Whittle M, D’Lima D, Cristofolini L, Witte H. Isb recommendation on definitions of joint coordinate system of various joints for the reporting of human joint motion—part i: ankle, hip, and spine. J Biomech. 2002;35(4):543–48.

Hopkins WG, Marshall SW, Batterham AM, Hanin J. Progressive statistics for studies in sports medicine and exercise science. Med Sci Sports Exerc. 2009;41(1):3–13.

Collings TJ, Gorman AD, Stuelcken MC, Mellifont DB, Sayers MGL. Do the landing mechanics of experienced netball players differ from those of trained athletes competing in sports that do not require frequent landings? J Sci Med Sport. 2020;23(1):48–52.

Ambegaonkar JP, Shultz SJ, Perrin DH. A subsequent movement alters lower extremity muscle activity and kinetics in drop jumps vs. drop landings. J Strength Cond Res. 2011;25(10):2781–8.

Mueske NM, Abousamra O, Katzel MJ, Vandenberg CD, Pace JL, Feifer D, et al. Effect of static alignment on dynamic knee abduction moments in adolescent athletes with recent ACL reconstruction. Med Sci Sports Exerc. 2021;53(8):1555–60.

Decker MJ, Torry MR, Noonan TJ, Riviere A, Sterett WI. Landing adaptations after ACL reconstruction. Med Sci Sports Exerc. 2002;34(9):1408–13.

Download references

Acknowledgements

The authors would like to acknowledge the assistance of Dr Adam Gorman (Queensland University of Technology) for his assistance during some of the data collection.

This project was funded using internal institutional sources only, with no external funding bodies.

Author information

Authors and affiliations.

School of Health, University of the Sunshine Coast, Queensland, Australia

Mark G.L. Sayers, Robert L. Buhmann, Tyler J. Collings, Daniel B. Mellifont & Max C. Stuelcken

School of Health Sciences and Social Work, Griffith University, Queensland, Australia

Tyler J. Collings

You can also search for this author in PubMed   Google Scholar

Contributions

MGLS, RB, DM and MCS contributed to project design. MGLS, TC, DM and MCS contributed to data collection. MGLS conducted the data reduction and analysis. MGLS, RB, TC, DM and MCS all contributed to manuscript preparation

Corresponding author

Correspondence to Mark G.L. Sayers .

Ethics declarations

Ethics approval and consent to participate.

This study was approved by the human research ethics committee at the University of the Sunshine Coast (A/16/878), with all participants providing their written informed consent prior to any data collection.

Consent for publication

Not applicable.

Competing interests

The authors declare that they have no competing interests.

Additional information

Publisher’s note.

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Electronic supplementary material

Below is the link to the electronic supplementary material.

Supplementary Material 1

Rights and permissions.

Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/ . The Creative Commons Public Domain Dedication waiver ( http://creativecommons.org/publicdomain/zero/1.0/ ) applies to the data made available in this article, unless otherwise stated in a credit line to the data.

Reprints and Permissions

About this article

Cite this article.

Sayers, M.G., Buhmann, R.L., Collings, T.J. et al. Does lower extremity alignment during normal stance predict lower limb kinematics and kinetics during drop landings?. BMC Sports Sci Med Rehabil 15 , 167 (2023). https://doi.org/10.1186/s13102-023-00781-6

Download citation

Received : 12 July 2023

Accepted : 01 December 2023

Published : 07 December 2023

DOI : https://doi.org/10.1186/s13102-023-00781-6

Share this article

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Static lower limb alignment
• ACL screening

BMC Sports Science, Medicine and Rehabilitation

ISSN: 2052-1847

• Submission enquiries: [email protected]
• General enquiries: [email protected]