cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
246 Views
Registered: ‎01-10-2014

Bizarre synthesis bug?

Hello all,

I'm currently fighting a weird bug with implementing HDMI output on a Mimas A7 board which has a T50 Artix7 part.  I have the HDMI display working, and have been working on HDMI audio.  And this is where things started going strange.

My first test of the HDMI audio was to just feed it a simple sine wave table, to confirm that I could push anything out the HDMI audio.  However, when I tried to supply anything other than a static value to the audio_l and audio_r signals, the resulting bitstream would not result in any HDMI display at all.  After considerable debugging, I eventually added a counter into the dvid.vhdl file to try to confirm that it really was processing the audio samples -- without changing the audio I was feeding it -- and it suddenly started working with both audio and video. 

I was clearly seeing a bug in Vivado, as the behaviour of the synthesised model was changing in ways unrelated to the change I had made.  This was with Vivado Webpack 2017.4, so I downloaded Vivado Webpack 2019.2 (no mean feat over the satellite internet here. It would be REALLY nice to be able to select only the architectures you intend to target to reduce the download size, but that's a separate issue). 

With the new version of Vivado in place, this weird behaviour went away, and I was able to remove my debug counter, and still have a working HDMI video and audio output. So I thought I was out of the woods.... until I tried playing an audio sample out of a BRAM.

I am now back at the same point where a seemingly irrelevant change to the design affects whether the HDMI video works or not.  In fact, just having the _potential_ to feed the BRAM data to the audio signals is enough to stop the video working. 

What I mean here, is that I have a switch on the FPGA board, dip_sw(0), control whether to feed the BRAM data, or the sine table to the audio_l and audio_r signals.  Thus if that switch is in the position to use the sine table, the HDMI subsystem should be seeing exactly what it used to see when it was working without problem, and I should get an HDMI picture on the display.  It is only if the dip switch is set to the "use BRAM" position that it should even have the potential to be screwing up.  Here is the code fragment:

 

audio_counter <= 0;
sample_ready <= true;

audio_l <= (others => '0');
audio_r <= (others => '0');
led <= (others => '0');
if dip_sw(0)='0' then
-- audio_l(12 downto 5) <= sample_rdata_drive and sample_mask;
-- audio_r(12 downto 5) <= sample_rdata_drive and sample_mask;
audio_l(12 downto 5) <= x"00";
audio_r(12 downto 5) <= x"00";
audio_r(12) <= sample_rdata_drive(7) and sample_mask(7);
led <= sample_rdata_drive and sample_mask;
else
audio_l(12 downto 5) <= audio_data and sample_mask;
audio_r(12 downto 5) <= audio_data and sample_mask;
led <= audio_data and sample_mask;
end if;

 

(Unrelated, is there a reason why the "insert code snippet" option in this forum doesn't have VHDL as an option? Seems a bit of an oversight to me...)

So, we can see if dip_sw(0)='0', then we feed just the top bit of the signal sample_rdata_drive, which has come from the BRAM.  But if the switch is on, then that gets totally ignored, and the audio_data is used instead, which is the sine table values. 

But it doesn't matter what position the dipswitch is in, there is no HDMI picture or sound.

If we now modify it to be:

 

audio_counter <= 0;
sample_ready <= true;

audio_l <= (others => '0');
audio_r <= (others => '0');
led <= (others => '0');
if dip_sw(0)='0' then
-- audio_l(12 downto 5) <= sample_rdata_drive and sample_mask;
-- audio_r(12 downto 5) <= sample_rdata_drive and sample_mask;
audio_l(12 downto 5) <= x"00";
audio_r(12 downto 5) <= x"00";
-- audio_r(12) <= sample_rdata_drive(7) and sample_mask(7);
led <= sample_rdata_drive and sample_mask;
else
audio_l(12 downto 5) <= audio_data and sample_mask;
audio_r(12 downto 5) <= audio_data and sample_mask;
led <= audio_data and sample_mask;
end if;

 

Then the HDMI picture is there regardless of the position of dip_sw(0) -- the only difference is that in one position I hear the 200Hz sine tone, and in the other there is silence.

However, as mentioned, if dip_sw(0)='1', then the two designs should behave identically.  Thus I am forced into the belief that there is a bug in Vivado 2019.2 that is similar to the bug I saw in 2017.4.

The project is open-source, and you can download it from:

https://github.com/gardners/Minimig_ECS

(I've also attached a tarball with the project in there as a live git repository, currently set to a commit that has the problem, i.e., no HDMI video or sound, regardless of the dipswitch setting.)

To build the version that works (and doesn't use the BRAM data) (from Linux, assuming you have Vivado in /opt/Xilinx/Vivado/. If not, modify the vivado_wrapper file):

$ git clone https://github.com/gardners/Minimig_ECS.git

$ cd Minimig_ECS

$ git checkout 70e0aba0d94c37bd078e006c65ba964f76f29eca

$ rm bin/mimasa7.{bit,mcs} ; make bin/mimasa7.bit

To then build the failing one:

$ git checkout f2b6e18407032c2a74d6e056eb7b054cef8bc91d

$ rm bin/mimasa7.{bit,mcs} ; make bin/mimasa7.bit

Have I guilty of some terrible PEBCAC, or am I really hitting a bug in Vivado?

 

Any assistance to help me escape Wonderland on this one would be greatly appreciated.

 

Have others experienced similar weird problems?

 

Thanks,

Paul.

0 Kudos
1 Reply
Highlighted
Scholar
Scholar
118 Views
Registered: ‎09-16-2009

Re: Bizarre synthesis bug?

Just a quick preliminary look, but downloading your repo and browsing things - I see no timing constraints.  You have xdc files for your pin constraints:

mimasa7/mimasa7.xdc

(There's a few other XDC files in the repo too, but I think the above is your main source)

No timing constraints.  Timing constraint files could be in the form of TCL files too, but browsing those, I don't any timing constraints either.  Granted all a quick look on my part, and I didn't try running.  But dumb question - do you have timing constraints, and what are the results of the timing analysis?  The type of failure you're describing (works some builds, doesn't others) is very typical of wrong or missing timing constraints.

Again, if I'm just missing them from my eyeball glance of your repo, then my bad...

Regards,

Mark

0 Kudos