etoochy
Newbie level 6
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.
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.:
then data will be increased in one cycle and the new value compared to 372 in the next cycle.Code:data<=data+372; if data>"011101000101" then data<= data-372; end if;
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.