1
\$\begingroup\$

Im new to VHDL, so my apologies if this question doesnt fit this forum. Here goes:

I have the following variables:

...
variable distanceToLight : integer;
variable lightLevel : integer;
...

I have a bug vhdl-file with lots of logic, and I have boiled my issues down to the following section:

...
if(lightLevel >= 0 and lightLevel <= 255)
then
    lightLevel := lightLevel*100/255;
    if(lightLevel >= 0 and lightLevel <= 255)
    then
        currentColor := (lightLevel,lightLevel,lightLevel);
    elsif (lightLevel < 0)
    then
        currentColor := PURPLE;
    else
        currentColor := YELLOW;
    end if;
else
    currentColor := RED; -- sanity testing that this is not hit
end if;
...

I have som logic that renders all pixels on the screen according this this function, sequentially, a single pixel at a time.

I experience, that lots of the outputs are actually YELLOW. Not all, but the far majority is. non is purple. This means that lightLevel ends up as a value higher then 255.

The case is: A) if lightLevel is between 0 and 255. Then lightLevel *100/255 can never be outside the range 0 to 255 either, e.g. should never be higher than the initial value if lightLevel.

So, logically this should never happen. So I need inputs to if i am using too complex math for the function to be syntesized? Or if I have mistaken the behaviour of integers and its range of values?

Another ting is: Some values seem to be constantly inside 0 and 255, some constantly above 255 and then there is som flickering on some of the pixels indicating that the same input values (x and y) gives varying output for each calculation.

Lots of complex calculations have been going in above this section, so could it be that there is an upper limit to the complexity of calculations possible to be syntesized?

I have been looking at this code for days now, almost going crazy :)

I use Quartus Prime Lite version 18.1 and I deploy to a De10-nano.

\$\endgroup\$
7
  • \$\begingroup\$ From your description I gather that you debug on real hardware. But what numbers do you see in your VHDL test-bench? If you tell me, you have no test-bench you should start on that first. \$\endgroup\$
    – Oldfart
    Nov 3, 2019 at 12:53
  • \$\begingroup\$ As @Oldfart says, this kind of problem is exactly why we invest time in creating and using a simulation testbench. At this point we don't know how CurrentColor, PURPLE, and YELLOW are defined or what sort of logic they synthesize to. \$\endgroup\$ Nov 3, 2019 at 13:01
  • \$\begingroup\$ Notice first that there is no path leading to the PURPLE assignment. Beyond that, there isn't enough code to assess. Write an MCVE including testbench. \$\endgroup\$
    – user16324
    Nov 3, 2019 at 13:20
  • \$\begingroup\$ Thanks for your comments! By "testbench", you mean a simulator, right? \$\endgroup\$ Nov 3, 2019 at 13:25
  • \$\begingroup\$ You always write a test-bench and simulate. I do that even on simple circuits and I have 30+ year experience in HDL. I might skip it on trivial code, but I have been bitten there too! \$\endgroup\$
    – Oldfart
    Nov 3, 2019 at 14:35

1 Answer 1

1
\$\begingroup\$

After consulting a senior fpga developer, I realized that the inconsistency determined by flickering output was caused by timing issues, e.g. too many calculations within a single clock cycle.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Maybe you should rewrite "lightLevel*100/255". Divisions by something that is not a power of two is complex. Try to divide by 256, or, if you want something very precise *201/512, *803/2048, ... It's still better than a division. \$\endgroup\$
    – Grabul
    Apr 26, 2020 at 21:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.