Cyclone III code compatibility and configuration issues

Hi, so here's my situation:

I'm currently working on a project involving a PCM3060 ADC/DAC and a Cyclone III FPGA. At the moment, I have all of my code written and working on a Terasic DEO dev board with the PCM3060 on a breadboard wired through the GPIO. This is running on an EP3C16F484C6 cyclone III configured in JTAG mode

I also have a PCB that I have designed containing just the ADC/DAC, the EPCS16 AS configuration device, and voltage regs. This is running an EP3C25E144C8 configured in Active Serial mode.

----
The issue is this:

The code that I have working on the DEO board does not function properly on the PCB. When I probe the IO's with my Scope everything appears to be working, only the DAC just outputs noise, so the data it's receiving is wrong/distorted. I would expect this to be my code, but last week everything had been working. I have an older converted .pof file that runs without a hitch on the PCB, unfortunately the code has changed significantly since then, and I don't have a relevant backup to reference.

----
SO my question is:

Any idea on where to begin troubleshooting this? All of my code changes to run the ADC/DAC, down to cutting out all but the necessary components function fine on my DEO board, but refuses to work on the PCB. I'm able to toggle pins on the PCB with new code, and am able to output clocks. Currently I'm starting from the bottom up, adding things back in until something breaks. Are there any incompatibilities with code that I should worry about? common .sof to .pof conversion issues or settings that might have been accidentally changed?

I know that I'm grabbing at straws at this point, but any help or ideas would be greatly appreciated. I can post code or anything else that you might need, Thanks!

Stirfadur said:

Hi, so here's my situation:

I'm currently working on a project involving a PCM3060 ADC/DAC and a Cyclone III FPGA. At the moment, I have all of my code written and working on a Terasic DEO dev board with the PCM3060 on a breadboard wired through the GPIO. This is running on an EP3C16F484C6 cyclone III configured in JTAG mode

I also have a PCB that I have designed containing just the ADC/DAC, the EPCS16 AS configuration device, and voltage regs. This is running an EP3C25E144C8 configured in Active Serial mode.
----

Click to expand...

The part change and the different programming option shouldn't be an issue if you changed the project to use the correct device. Have you tried configuring with JTAG directly to remove the AS mode from the equation?

The code that I have working on the DEO board does not function properly on the PCB. When I probe the IO's with my Scope everything appears to be working, only the DAC just outputs noise, so the data it's receiving is wrong/distorted. I would expect this to be my code, but last week everything had been working. I have an older converted .pof file that runs without a hitch on the PCB, unfortunately the code has changed significantly since then, and I don't have a relevant backup to reference.
----

Click to expand...

You can't go back to rebuild the older .pof....This is the reason FPGA engineers should use source control (like software engineers) even if there isn't an official requirement in your company you should make it your requirement, so you can always recover something later. Also don't make the mistake of not checking your files in at the end of the day because you haven't got it working yet. Revision numbers are cheap, you reinventing the wheel isn't. If you need to have revisions that can be used by others, tag them using the SC's tag or labeling capability. Okay getting off my soapbox.

You might have had some lucky timing in the working .pof. Have you really check the timing relationship between signals at the ADC/DAC part, instead of at the FPGA pins? Are you absolutely sure the signals between the FPGA and ADC/DAC are connected correctly? Is the ADC/DAC connected the same way as the development board (pullups/pulldowns, etc)? Did you constrain all the I/O between the FPGA and the ADC/DAC and are you sure they are correct (and that they haven't changed between the old .pof and the current design)?

SO my question is:
Any idea on where to begin troubleshooting this? All of my code changes to run the ADC/DAC, down to cutting out all but the necessary components function fine on my DEO board, but refuses to work on the PCB. I'm able to toggle pins on the PCB with new code, and am able to output clocks. Currently I'm starting from the bottom up, adding things back in until something breaks. Are there any incompatibilities with code that I should worry about? common .sof to .pof conversion issues or settings that might have been accidentally changed?

I know that I'm grabbing at straws at this point, but any help or ideas would be greatly appreciated. I can post code or anything else that you might need, Thanks!

Click to expand...

Without schematics of both the original setup, the current setup and more time than I can afford can't actually help you troubleshoot this, beyond the suggestions I already gave.

Regards

Thanks for the quick reply. This is a school project, but I agree, we need to be better about backing up files throughout the design process.

Right now we're looking at the timing, and it looks right; the dac refuses to respond properly so far. It just bugs me that it runs without any problems on the dev board, no problems last week, and that it works with the old .pof :-?

My guess is that it must be something in the parallel to series shift registers that's messing up the timing, but they still work with the dev board, so it's hard to find a reason why.

Stirfadur said:

My guess is that it must be something in the parallel to series shift registers that's messing up the timing, but they still work with the dev board, so it's hard to find a reason why.

Click to expand...

Debugging 101...

Then look at the relationship between the data and whatever controls the shifts.

If it's internal to the FPGA use Chipscope, if you have it, or (less optimal) run the signals out of the chip and look at them on some spare pins (make sure you know the delay of your probes as you'll have to account for it), if you can re-register them again at the I/O so you won't have to incur routing delay variations.

If the shift is in the DAC then you'll have to look carefully at the documentation of the DAC and see if the problem lies in the serial protocol you are sending to the device.

If nothing else consider this a learning opportunity for debugging designs.

Regards

Well, that's exactly what we did, but we didn't see anything suspicious. We were able to find an old project that works on the PCB. The VHDL looked identical, so we copied them to a new project, compiled that, and it didn't work.

So, maybe it's in some kind of project setting...? not too sure. We did use a PLL megafunction, I was wondering if maybe Quartus doesn't like it when you copy that from one project to the next?

Any ideas? We can work from the old file to meet our deadline, but whatever broke is bugging me.

I can't see how the PLL megafunction would cause this kind of issue if it's copied. It's just a bunch of files, and it's obviously generating a clock for you.

Compare the old project setting to the new project. Or copy the working project to a new location, compile, verify it still works, then updated said project with files from the project that doesn't work. If it's the project setting it shouldn't ever fail to work.

Have you checked that the old project that works has the exact same constraints as the new project you've been using?

Regards

All signals involved with the PCM3060 codec are pretty slow in FPGA terms and don't bring up timing issues if the logic is designed properly. But that's the problem. We know effectively nothing about the original DE0 targetted design and don't know if it's working just by chance or due to applying good engineering practice.

This would be one explanation, a hidden problem in the original design. Another possibility is a trivial problem when setting up the new hardware, finally there might be a more serious issue like bad PCB layout or missing bypass capacitors causing failure of the FPGA or the codec chip.

As far as I can tell, everything is set up the same. We checked the target device, grounding unused pins, .pof generation for the AS programming. We didn't change the IO voltage settings, or anything else. Is there anything pivotal that I missed or should look into?

We initially tried to create a new project from the functional vhdl and it failed. We can move the working project file though, and it compiles and runs fine. We tore it down to just the ADC/DAC code and are rebuilding everything else from there without a problem. It's just strange that it only wants to work from that project.

My worry about the PLL megafunction was that there might be some support files that aren't just the .VHD that I'm missing.

I guess we'll have to dig through it until something makes sense. Thanks

We initially tried to create a new project from the functional vhdl and it failed.

Click to expand...

Shouldn't happen. Failed in which way?

My worry about the PLL megafunction was that there might be some support files that aren't just the .VHD that I'm missing.

Click to expand...

Effectively everything is in the HDL code. But did you try to read the PLL section of the compilation report? It lists all relevant PLL parameters. You should be also able to setup the PLL from the scratch by just knowing the intended clock parameters.

last week everything had been working. I have an older converted .pof file that runs without a hitch on the PCB, unfortunately the code has changed significantly since then, and I don't have a relevant backup to reference.

Click to expand...

In other words you don't yet fully understand your code. That's no really unusual. It still happens to me from time to time.