• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About HansDR

  • Rank

Contact Methods

  • Website URL http://keasigmadelta.co.nz/

Profile Information

  • Gender Male
  • Location Wellington, New Zealand
  1. Thanks Jack, I'll try that out some time. Hans
  2. Thanks. I wasn't thinking about generating the bootloader; just the hardware. Have you ever built the bitfile on Windows? I'm guessing that something extra needs to be done so that make knows where to find ISE's binaries.
  3. Has anyone had success building the ZPUino on Windows? If so, what's the easiest way to set up the tools that you need? It uses makefiles intended for GNU make. On Linux you've got make already, but not on Windows. And I don't think that it's as simple as installing mingw, either.
  4. Yes, I'm not sure what to make of that either. Based on the timing report, it looks like it's treating each bit in the address register as independent with 0 levels of logic. Considering that it's connected to an adder, that's wrong. EDIT: Okay, I just noticed that the ROM is using a different clock from the address counter: -- The memory containing the audio data ROM : entity work.ROM generic map ( DataWidth => DataWidth, AddressWidth => AddressWidth, ROMFileName => ROMFileName) port map ( CLK => CLK_AudioData, Address => AudioAddress, Data => AudioData); -- Read the audio data from memory AudioPlay_p : process(CLK_IN, CLK_AudioData) begin if (rising_edge(CLK_IN) AND CLK_AudioData = '1') then AudioAddress <= STD_LOGIC_VECTOR(UNSIGNED(AudioAddress) + 1); end if; end process;Notice how the ROM is clocked with CLK_AudioData, whereas the address counter is clocked by CLK_IN, and uses CLK_AudioData as an enable signal. That's asking for trouble, isn't it? The timing analyzer may not be smart enough to work out what's going on in such a case. EDIT2: After changing the ROM's clock to CLK_IN, the timing report makes a lot more sense, and it's correctly checking whether the data path delay fits within the rising to falling clock edge period. Hans
  5. @Hamster Your comment about the bad ROM pointed me in the right direction. The problem was that the address counter was being updated on the clock's rising edge, while data was clocked out of the ROM on the falling edge, and being read by the DAC on the rising edge again. This was causing timing problems that resulted in invalid data being sent to the DAC. I guess that the address counter's output wasn't stable yet when the ROM was being read. This would also explain why outputting to just the left or right channel changed the crackling; it also changed the layout in the FPGA and, therefore, the timing. With everything being clocked on the rising edge, the crackling is gone. @alex While file IO is mostly used in simulation, this is a perfectly valid way of loading data into a ROM. I personally prefer keeping the ROM data in a separate file when it gets this big. It's cleaner and more compact than sticking it in a dirty big array in a VHDL file. I had hoped to directly read in binary data directly, but it appears that VHDL's IO functions aren't flexible enough to do that (or, I'm missing something). The biggest downside to loading ROM data from an external file, is that Xilinx ISE is unaware of this dependency, and won't recompile the appropriate files if the ROM's contents change. @all Thanks for your help. Hans
  6. Project attached. The test audio data is the first few seconds of a tune that came with my phone. Audio.zip
  7. I just checked the code, and: -- The output latch DACOut_latch : process(clk) begin if (rising_edge(CLK)) then DACOut <= dataOut; end if; end process;So yes, the output is direct from a register.
  8. I just tried it, and crackling is still there, but different. Cracking and distortion is worst with just the left channel in use. With the right channel only, the the crackling is more muffled, but the sound is more distorted. Audio quality is actually best if both channels play the same thing. The DAC's output bitstream is the same in each case, so that's a bit weird. I also tried bypassing the board's RC filters by removing the arcade wing, and connecting the speaker input directly to the Papilio Pro board's pins, and this odd behaviour persisted. In fact, shifting the audio output to a different pin, changes the noise/distortion. The above suggests that what I'm hearing could well be noise from within the chip. I've been thinking of the digital output as a clean stream of 1's and 0's, but there can be a heap of analog noise on top of it. That noise would make it straight through the RC filters, and into my speakers. Alas, I don't have an oscilloscope to check it out. Maybe running the DAC at 32 MHz is particularly bad for added noise. Version 1.2. Hans
  9. I'm using the Arcade MegaWing, and I've connected both (passive) headphones and my monitor's speakers. The crackling isn't present with other designs (e.g., PacMan), so I highly doubt that the analog side is the problem. I think that pre-filtering might help because I'm not doing proper upsampling from 11 KHz to 32 MHz; it's just holding each value until the next one comes along (i.e., zero-order-hold). That means that the signal can have rather jagged edges at 11 KHz, which should add noise in the audible 5.5 KHz+ range. I'm not sure if that's the cause of the crackle, but it certainly doesn't help. From what I've read, commercial audio sigma-delta DACs are typically 5th order, which implies that there is some sort of filtering going on. Thanks. Right now, I'm more interested to see if I can improve the sigma-delta DAC output. The Super Audio CD format (that never took off) delivers hifi audio with a 1-bit DSD datastream at 2.8224 MHz, so I should be able to get much better sound than I am. Hans
  10. While going through hamster's Intro to FPGA & VHDL book (great resource BTW), I had a go at outputting 8-bit audio at 11 KHz through a sigma-delta DAC. It worked, but the audio quality was pretty poor. Yes, 8-bit @ 11 KHz audio is low-fi, but the same audio data is much less noisy when played through a computer's sound-card. The DAC itself was clocked at 32 MHz, which I think should be more than enough for decent quality output. I set myself the goal of improving quality to be similar to a sound-card (without increasing the number of bits or the input sample-rate). So far, I have managed to improve the quality by using a second-order sigma-delta DAC, but it still has crackling noise audible that shouldn't be there. Has anybody else experimented with sigma-delta DACs and 8-bit audio? If so, what kind quality did you get? I'm wondering if there's something wrong with the DAC, or if I should be doing something like digitally low-pass filtering the 8-bit @ 11 KHz audio data before passing it on to the DAC. Hans