Modelsim 1

[naraic]

Hi all,

Can anyone tell me why, when I add signals to the waveform viewer window in Modelsim (as in add->wave->signals in region, or if i drag and drop), Modelsim closes itself?

Thanks

 

[naraic]

Bit more info.

I am also getting an error when I try to synthesize the VHDL files (zerorunlength.vhd). The console reads as follows when the error occurs

>>Started process "Synthesize".
>>
>>
>>=========================================================================
>>* HDL Compilation *
>>=========================================================================
>>Compiling vhdl file C:/JPEG_VHDL/JPEG/zeroRunLength.vhd in Library work.
>>Entity <zerorunlength> (Architecture <logic>) compiled.
>>
>>=========================================================================
>>* HDL Analysis *
>>=========================================================================
>>
>>Analyzing Entity <zerorunlength> (Architecture <logic>).
>>ERROR:Xst:1312 - Loop has iterated 64 times. Use &quot;set -loop_iteration_limit >>XX&quot; to iterate more.
>>-->
>>
>>Total memory usage is 268168 kilobytes
>>
>>
>>Error: XST failed
>>Reason:
>>
>>Completed process &quot;Synthesize&quot;.

This doesn't occur when I run the synthesis tool on any of my other files. Also, I have a test-bench waveform for this file. When I try to run the tbw in Modelsim, Modelsim closes itself when signals are added to the waveform viewer window. This also does not occur on the other testbench waveforms that I have, which makes me think the two problems are related.

Thanks
Ciaran

 

[VHDLguy]

Maybe you have an infinite loop?

One way to do that would be a process with no sensitivity list and no wait statement. Modelsim would usually generate a warning for this when compiling.

The other possibility is a signal that never stabilizes. An easy example is:

INF_LOOP : process (Q)
begin
Q <= not Q;
end process INF_LOOP;

So each time the process runs the output changes and causes the process to run again.

Usually modelsim would quickly hit an iteration limit, but I seem to remember doing this some way once and not hitting the iteration limit. (I just don't remember what I did).

 

[naraic]

The Modelsim thing I managed to fix. I still get the error above when I try to synthesise the code. I have two loops in the code, which are as follows

....
lp1: for i in 10 downto 0 loop
  if abs(input) <= bnds(i) then
    catVal := cats(i);
  else
    if input(10) = '0' then
      addBitsTemp := input;
    else	
      addBitsTemp := input + bnds(i+1);
    end if;
    
    exit lp1;
  end if;
end loop;
....
lp2: while zeros >= 16 loop
  zeros := zeros - 16;
  zrlBuf(count1) <= X&quot;F&quot;;
  catBuf(count1) <= X&quot;0&quot;;
  addBitsBuf(count1) <= (others => '0');
  count1 := count1 + 1;
end loop lp2;
....[\code]

The first is a for loop, so probably doesn't cause this error. The second loops exit is dependant on the value of [code]zeros[\code], so may cause the problem. Thing is, the behavioural simulation of the code works perfect.

What do you think?

 

[VHDLguy]

Just because something will simulate properly doesn't mean that it will synthesize. Have you tried to think what this code will create in hardware?

Im not really sure from your code what it is you are trying to achieve. lp2 looks like you are trying to create an array of hex numbers created by the variable zeros. Is zeros limited in range? (the most likely problem, i think) What is the maximum size it can be?

lp1 I can't really tell what you are attempting to do without more info, but it looks like it could easily be rolled out into a bif if statement, so I concentrated looking at the other loop.

 

[naraic]

I fixed the problem by replacing lp2 with

lp2: for i in 3 downto 0 loop
  exit lp2 when zeros < 16;
  zeros := zeros - 16;
  zrlBuf(count1) <= X&quot;F&quot;;
  catBuf(count1) <= X&quot;0&quot;;
  addBitsBuf(count1) <= (others => '0');
  count1 := count1 + 1;
end loop lp2;[\code]

zeros is a 8-bit wide std_logic_vector. When that value is over 16, I need to place &quot;1111&quot; on the zrlBuf array, and &quot;0000&quot; on the catBuf array. I need to do this until zeros is less than 16.

I realised that the loop did not need to iterate more than 4 times, so I added the for loop. I don't get that error when I synthesise it now, but I get an unrelated error, which I'll start a new thread for.

Thanks,
Ciaran

P.S. I do know that if something simulates correctly it doesn't necessarily mean that it will synthesise.

 

[VHDLguy]

Just out of curiosity. What are you trying to do here with the arrays?

 

[VHDLguy]

Let me rephrase that. I see you are putting &quot;1111&quot; in zrlBuf and &quot;0000&quot; in catBuf until zeros is less than 16.

But what is the ultimate goal.

I am having a hard time tryingto imagine the hardware this is creating. If it is creating a whole bunch of subtractors then you might have problems getting this to work at any speed.

 

[naraic]

I am trying to code a JPEG encoder in VHDL. One of the stages of JPEG encoding is Zero Run Length Encoding, where the number of zeros before a non-zero value is counted, and then stored as a 4-bit unsigned integer, followed by the four bits that are the non-zero value.

e.g. 1 0 0 0 0 3 0 0 0 0 0 0 A
would be 0 1 4 3 6 A

However, if the run of zeros is 16 or greater, a special symbol is inserted (F 0 - ZRL symbol).

e.g. 1 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A
would be 0 1 4 3 F 0 3 A

If the run of zeros is greater than 32, then F 0 F 0 is inserted, and so on.

Also, the max length of the string of values before the zer-run-length is 64, so there is never more than four of the ZRL symbols.

I could use an if-elsif block to do this. Would that synthesise better?

if zeros >= 48 then
  zrlBuf(count1) <= X&quot;F&quot;;
  zrlBuf(count1 + 1) <= X&quot;F&quot;;
  zrlBuf(count1 + 2) <= X&quot;F&quot;;
  catBuf(count1) <= X&quot;0&quot;;
  catBuf(count1 + 1) <= X&quot;0&quot;;
  catBuf(count1 + 2) <= X&quot;0&quot;;
  count := count + 3;
elsif zeros >= 32 then
  zrlBuf(count1) <= X&quot;F&quot;;
  zrlBuf(count1 + 1) <= X&quot;F&quot;;
  catBuf(count1) <= X&quot;0&quot;;
  catBuf(count1 + 1) <= X&quot;0&quot;;
  count := count + 2;
elsif zeros >= 16 then
  zrlBuf(count1) <= X&quot;F&quot;;
  catBuf(count1) <= X&quot;0&quot;;
  count := count + 1;
end if;[\code]

Thanks
Ciaran

 

[naraic]

Or perhaps

if zeros >= 16 then
  zrlBuf(count1) <= X&quot;F&quot;;
  catBuf(count1) <= X&quot;0&quot;;
  count := count + 1;
  zeros := zeros - 1;
end if;

if zeros >= 16 then
  zrlBuf(count1) <= X&quot;F&quot;;
  catBuf(count1) <= X&quot;0&quot;;
  count := count + 1;
  zeros := zeros - 1;
end if;

if zeros >= 16 then
  zrlBuf(count1) <= X&quot;F&quot;;
  catBuf(count1) <= X&quot;0&quot;;
  count := count + 1;
  zeros := zeros - 1;
end if;[\code]

 

[naraic]

That should be zeros - 16 (not zeros - 1)

 

[VHDLguy]

I would go with the if-then-else that you first implemented with the 3 different cases (>= 48, >= 32, >= 16).

The reason for that is
1. Its more obvious what the synthesizer would do, and therefore more likely that the synthesizer will do a better job of it.
2. there are no loops with adders etc. Take your original loop or your last if-then-else example. It is having to subtract 16 from zeros, then 16 from that, then 16 from that etc, and it has to do this all in one clock cycle.

So you end up with 3 subtractions all in series. Maybe if the synthesizer were smart it might implement 3 parallel subtractor's (one -16, one -32 and one -48), but that is not guaranteed and might be hard to determine. If the synthesizer doesn't do it the smart way, there might be a way to force it, but it would require going through all the manuals to find an answer. Even then the logic may be slower than the comparitor example (or maybe not).

I find that sticking to &quot;easy&quot; VHDL leads to better results. That is, avoiding loops, variables, functions etc. Just sticking to the basic, if-then-else and case statements.

Of course that isn't always practical, so sometimes the loops are useful rather than writing 1000 lines of code. But in those cases I like to look at it and see what it would roll out too in a big if-then-else, if it looks hard (from the perspective of imagining the resulting hardware) I might try a different approach.

Unfortunetly, unlike say C, the best code is not always the easiest to read, or the most obvious with respect to functionality.