Hello!
Thanks for your reply!
And for the solution! It was really a silly question. Indeed, I was incrementing at every step.
It works now.
By the way, I have asked a few times, but how can I format the code with colored syntax?
Is it something only moderators can do?
Thanks,
Pastel
- - - Updated - - -
Hello!
Thanks for your reply!
BRAM requires 1+ cycle of read/write latency but is the most dense.
As far as I can tell, there is not much latency. The clock spins at 100 MHz, and I can output samples at 50 Ms/s.
So yes, 1 cycle to put the data at the DAC input, and the next cycle to latch it. But I think it's the least I can do
to keep the timing safe.
Your design looks like it should be using BRAM as the table is large enough and you don't do anything that would prevent this.
Just to be sure (not english native, sorry). You mean that my design is currently not using BRAM and I
should change it so that it uses BRAM?
Or you mean that looking at the code, it's likely that my design actually uses BRAM?
the table is large enough and you don't do anything that would prevent this.
To prevent the table to be large, or to prevent my design to use BRAM?
By the way, I have another question. I'm using the
MAX5875 DAC which can work at 200 Msps.
I have noticed that whatever I do, it works. I mean: this works:
Code:
if(max_clk == 0) begin
max_clk <= 1;
end
else begin
DA <= Sine[sinindex];
DB <= Sine[cosindex];
max_clk <= 0;
end
And this also works:
Code:
if(max_clk == 0) begin
DA <= Sine[sinindex];
DB <= Sine[cosindex];
max_clk <= 1;
end
else begin
max_clk <= 0;
end
I suppose that if I set the clock and the data at the same time, there is anyway a
delay between the data and the clock, so it works. In one case, the data is latched
immediately, and in the other case, the data from the previous cycle is latched.
There is no difference in matters of noise at the DAC output.
Can anybody tell me why it works in both case (is my explanation right)?
Thanks,
Pastel