I believe that this answer which got 22 upvotes is wrong for the following reason:

• The author's claim that "s_out is only going to change once - to the value it was when the loop ended, which in this case is s_in shifted by 4" is wrong since it has been proven wrong by observing the simulation result. The technical reason is that signal values get updated at the end of the delta cycle.

• The author uses a Finite State machine that copies a parallel value to the shift register after n shifts, instead of storing the value.

I also commented on the author's answer why I felt it was wrong.

As none of the other suggestions mentioned worked for me, I have decided to take the last alternative and discuss about this answer on Meta.

• Having (allegedly) incorrect information as the collective statement of our site in indeed frustrating. That said, this is a fairly obscure and specialized question, and it's not clear than enough people are going to wade through the details to change the votes much. Fortunately HDL's are an area where anyone sane starts with simulation, so if the vote-preferred answer is indeed wrong, someone will probably find the issue before they've gone too far down the wrong path, and your alternative is well visible; this isn't quite the situation of dangerously wrong advice on charging a battery. – Chris Stratton Dec 8 '20 at 17:32

I suppose I should weigh in on this, since my answer is under scrutiny here.

I'll point out that this answer was written by myself 7 years ago, and has amassed 37 thousand views over that time. In all that time, it is expected that someone would have found issue with the answer if it was factually incorrect. There are several other highly reputable HDL coders on this site, several of which I interacted with regularly years ago, and they did not say anything about this answer.

Additionally, the OPs question actually was regarding the for loop working: "I don't think the for loop is working,... Where am I going wrong?"

So I did answer the question, and the OP even commented saying my answer was useful to them.

There is no obligation on this site to supply complete code, and this is not a tutorial site where you google "Shift register" and get a complete example. I'm under no obligation to even put code in my answer.

Indeed, I even commented in response to you the following,

I wrote this answer 7 years ago with the intention of demonstrating the thinking behind using a state machine to solve problems like this. The intention is to demonstrate a general concept. The OP is welcome to modify it to his needs. My coding practices have changed since then and I'm sure there are multiple things anyone could fine wrong with this, since I wrote it in my free time and not as a rigorous academic exercise. You are welcome to write an answer if you think mine is inadequate.

Additionally, there are regional and industry differences in how terms are used, depending on how people are trained and their educational background.

Anyway, regarding your actual complaints. I am under no obligation to address these but will link to relevant resources for you to take a look at.

#1, please see https://vhdlwhiz.com/for-loop/ Where it demonstrates the behaviour of a for loop, note that this code:

entity T04_ForLoopTb is
end entity;

architecture sim of T04_ForLoopTb is
begin

process is
begin

for i in 1 to 10 loop
report "i=" & integer'image(i);
end loop;
wait;

end process;

end architecture;


Produces this:

# ** Note: i=1
#    Time: 0 ns  Iteration: 0  Instance: /t04_forlooptb
# ** Note: i=2
#    Time: 0 ns  Iteration: 0  Instance: /t04_forlooptb
# ** Note: i=3
#    Time: 0 ns  Iteration: 0  Instance: /t04_forlooptb
# ** Note: i=4
#    Time: 0 ns  Iteration: 0  Instance: /t04_forlooptb
# ** Note: i=5


And secondly:

As I said in my comment:

parallel_in supplies the reset value of the internal shift register. So I kept it with the same name and function. It is otherwise unused, OP must explain what it was originally intended for. I agree that a SISO register should be otherwise strictly serial.

Or in other words, I kept as closely as possible to the OPs code so that they can understand what changes I made that are relevant to their application. Again, I was under no obligation to write an actual shift register, if the OP wanted a parallel-serial monstrosity, then that's what they got!

• Thank you for your answer! Please see the waveform obtained on simulating OP's code: edaplayground.com/w/x/2_K . The link to the EDA Playground: edaplayground.com/x/dAsg. You can simulate it yourself and see that s_in is not shifted by 4 as you expected. – Shashank V M Dec 9 '20 at 14:33
• I hope you would see that your interpretation of for loops in VHDL is partially incorrect, since here a signal is used, and not a variable. If a variable is used, it will, of course, execute in zero time and the variable would be updated with the value of the last iteration in a single clock cycle. – Shashank V M Dec 9 '20 at 14:37
• @ShashankVM I don't have the time to test this. Not every simulator is the same, I use modelsim to test. I didn't even run the simulation code then. It is very possible I'm wrong, I'll take you at your word at it and have edited my answer to exclude the resulting value from the for loop. – stanri Dec 9 '20 at 14:57

Generally, incorrect answers should be down voted and you should leave a comment stating why the answer is incorrect. This goes for the vast majority of all posts.

In very special cases, where a highly up-voted post is factually incorrect to the point where it is harmful and can't be salvaged without major edits, we can bring it up on meta. When doing so, always leave a comment to the author of the disputed post with a link to the meta discussion!

Once on meta, it is implicitly a call for domain experts to chime in and come up with a consensus about what to do with the post. Ideally with input from several VHDL gurus (in this case), such as the top tag users. Once a strong community consensus is reached regarding what to do with the post, a diamond moderator can then carry it out.