Ok, after running your sim, no audio out. (0.001 seconds in real life)
After increasing the sim end time by 10x, still nothing. (0.01 seconds in real life)
After increasing the sim end time by another 10x, still nothing. (0.1 seconds in real life)
After increasing the sim end time by another 10x, still nothing. (1 second in real life)
(
Pathetic PSG if it cannot produce a tone within 1 second of the issued command.)
Well, after that sim:
Looking at the 1 000 000 000ns point (1 second), your f_count made it past 1785714 times, or 1785714Hz. Plus a few extra fractional 0.xxx hz as it reached that count just before the 1 second point. This should match your calculated hz. (Fin=100 000 000hz / divider 56 = 1785714.286 hz)
Assuming you sent the commands correctly and the same way you have been doing it currently with the 'Z80', you may have just identified your first bug. Now, this may be an issue with the way the VHDL is either configured, or the way it is designed to interface with.
Ok, your setup is ok, in a Verilog way, though you did not need to write such code, but I will make a suggestion for the reset, place it inside the initial like this:
initial begin
clk = 1'b0 ;
f_count = 24'b0 ;
step = 3'b0 ;
reset = 1'b0 ;
#(CLK_PERIOD*5) reset = 1'b1 ; // release reset after 5 clocks
end
In fact, get rid of your verilog at the bottom and do this:
initial begin
clk = 1'b0 ;
f_count = 24'b0 ;
step = 3'b0 ;
reset = 1'b0 ;
#(CLK_PERIOD*CMD_CLKS) // Wait for CMD_CLKS oscillations of the system clk period before releasing reset
reset = 1'b1 ; // release reset.
#(CLK_PERIOD*CMD_CLKS) // Wait for CMD_CLKS oscillations of the system clk period before sending commands.
// Count the command counter until the end, waiting a CMD_CLKS between each command step.
for (step = 0; step < (CMD_COUNT -1); step++ ) #(CLK_PERIOD*CMD_CLKS) ;
end
With this new parameter at the top:
// Test parameters
parameter DIVISOR = 28'd56 ; // clock divisor value
parameter CMD_CLKS = DIVISOR ; // numbers of clk per command.
This With this, you can now set the CMD_CLKS to anything, like 1 which would send a command every 100MHz system clock.
I also added a blank dead '0' beginning command. (See attached updated source _tb code).
Now, we know the PSG is doing something as after the last command is sent, the 'pcm14s_o' output changes to 0x0353 at the last transmitted command byte, but, nothing after that.
Playing with then new 'CMD_CLKS' parameter doesn't seem to help.
I made it 4x longer and the 'pcm14s_o' now changes before the last command is sent.
Perhaps your command output is wrong in some way?
I made it literally equal to 1 and 2, but now, nothing happens. This confirms that the poor VHDL PSG needs the commands to be slowed down, though I suspect it was done for backwards compatibility with the original IC. I also tried 1/2 your divisor 'DIVISOR' parameter making the command exactly twice as fast and it still fails.
I also tried inverting the 'bc' and nothing again.
So, we can assume you are sending a proper command timing, but something is missing in the commands as there is no triangle waveform coming out.
There is also that verilog version of the Yamaha PSG I linked to earlier which you may give a try. It should have the same IO ports. If it has the same slow input road-block, you might be able to easily bypass it and write commands right up to the top 100MHz clk input speed.