VHDL (weird output in the simulation)

[etoochy]

are you suggesting i should make DAC_CS high in falling edge for example? to sometimes stop the conversion.

i think i understood what you meant by the value being read in the next cycle after incrementation was made, but i still don't understand why i get totally irrelevant values for the 12 bits to the one i'm incrementing in the simulation (it just repeats itself and its not a factor of 372 at all). to me they are totally random wrong bits but i'm sure it has an explanation.

It's time to look again at what the code is supposed to do. Now it's setting DAC_CS permanently low, which isn't the right way to operate a SPI DAC, I think.

I'm not sure if you understand how signal assignments in a process work. If you have e.g.:

  data<=data+372; 
  if data>"011101000101" then 
    data<= data-372; 
  end if;

then data will be increased in one cycle and the new value compared to 372 in the next cycle.

The same thing happens to your state variables or bit counters. This is due to the fact, that the statements in a "sequential" block (a process) are not executed sequentially in time rather than simultaneously. Using variables, as you did in your first attempt, is hiding the actual logic processing and gives the appearance of a sequential execution flow. But it's translated by the design compiler to something different.

When starting HDL coding, it's important to understand how things work. Getting rid of the software programmers viewpoint is necessary, and it's more easy by omitting variables. Next is to learn, how to use signals in sequential code correctly.

 

[TrickyDicky]

are you taking into account overflow and underflow?

 

[etoochy]

i was trying to avoid any overflow by this line: if data>"011101000101" then

but i didn't take in to account the underflow you made me realise.

and because data<= data-372; this takes effect in the next cycle, whatever is decremented gets incremented again.

Thanks you made me realise something now.

are you taking into account overflow and underflow?

 

[lucbra]

And like suggested in one of the first posts - try figuring out what circuit you are describing. I mean a mux, FF, LUT are elements in an FPGA, adders, substractors, .... aren't.

 

[FvM]

are you suggesting i should make DAC_CS high in falling edge for example? to sometimes stop the conversion.

You didn't tell, which DAC is controlled by your logic, but the types I know don't update the output before CS is deasserted.

And like suggested in one of the first posts - try figuring out what circuit you are describing. I mean a mux, FF, LUT are elements in an FPGA, adders, substractors, .... aren't.

HDL designs have several levels of abstraction. If you go for a behavioral description, you're already loosing the direct relation to hardware elements. It's still important to understand this relation, but some more complex language elements don't directly show it. Once you learned to manage HDL design, you can also take advantage from this abstraction. You'll even use variables to improve the clarity of your code.

 

[lucbra]

HDL designs have several levels of abstraction. If you go for a behavioral description, you're already loosing the direct relation to hardware elements. It's still important to understand this relation, but some more complex language elements don't directly show it. Once you learned to manage HDL design, you can also take advantage from this abstraction. You'll even use variables to improve the clarity of your code.

Agreed, but first learn to walk, then to run is my advice.