--- Quote Start ---
--- Quote Start ---
According to me, it should have been stuck to "000".
--- Quote End ---
Actually this isn't true.The signal will be set to "UUU" in a simulator, which means "uninitialized" and a synthesizer may decide to choose whatever value or expression it wants to optimize the synthesis, potentially giving strange results. I don't know how Quartus works in this case, but looking at the RTL viewer could help find out what it did. You may get a warning message somewhere about that. Anyway if you try and simulate your SOPC system with this uninitialized vector you'll probably end up with some 'X's on several control signals from the DMA.
--- Quote End ---
'U', 'X', etc. are for simulation.
In the 'real', 'physical' world, whatever the synthesizer choosed to do, signal in_empty[2:0] can only be "000", "001", "010", "011", "100", "101", "110" or "111".
So 1 of the 8 conditions from sgdma.vhd, line 1946, has to be true, so m_write_byteenable_reg should not be "00000000".
Using the RTL viewer is a good idea, I'll do that.
--- Quote Start ---
--- Quote Start ---
BTW this is what it looked like into the waves.
--- Quote End ---
I don't know how signaltap works in this case, but if the hole part that processes in_empty was optimized away by Quartus, it may just have put a default value to signaltap, unrelated to what the DMA does. Again the RTL viewer may shed some light on this.
--- Quote End ---
It is indeed possible that in_empty[2:0] has been synthesized "000" for signal_tap and differently somewhere else.
Honored Contributor
