I cant work this out!

[Altera_Forum]

This is to adjust volume of incoming audio samples by just multiplying by a constant value (SW). I wanted to be able to control the volume value with the switches on the DE2 but i get no sound at all. The switches are connect in the top level as SW[15..0] 

However, it works fine when i type a static binary value into the code eg.. sample_in * ("0000000000011111")  Surely the switches are just doing the same thing.   I'm confused!!  --amp.vhd library IEEE; use IEEE.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_signed.all; entity volume is port ( -- data sample_in: in std_logic_vector(15 downto 0); sample_out: out std_logic_vector(15 downto 0); -- params SW: in std_logic_vector(15 downto 0) ); end entity volume; architecture beh of volume is signal signal_unnormalized: std_logic_vector(31 downto 0); signal sample_reg: std_logic_vector(15 downto 0); begin signal_unnormalized <= sample_in * SW; sample_out <= signal_unnormalized(31) & signal_unnormalized(22 downto 8); sample_out<=sample reg; end architecture beh;

[Altera_Forum]

have you assigned the switches to the correct pins? 

and whya re you not using a clock for a synchronous design?

[Altera_Forum]

yep pins are all assigned - i connected the leds as well to be sure.  

 This should be a 'process' is that what you mean?  anyway for now, although i'm still a beginner, im totally baffled!

[Altera_Forum]

Couple of points: 

 1. You didn't do a good job of copy/pasting because you have a signal called 'sample_reg' but you have an assignment that cannot compile: sample_out<=sample reg; -- Note the space between 'sample' and 'reg' 2. The output of the entity sample_out even if it was connected to 'sample_reg' as you no doubt intended, still has a problem in that you never assigned anything to 'sample_reg' so 'sample_out' will get set to all zeros since sample_reg is unassigned. 3. You have two assignments to sample_out. This would never make it through any synthesis tool because it would mean that there are two drivers for sample_out and the tool would end with an error. Simulation would show that there are two drivers after you scratch your head for a few minutes debugging. However, if you use std_ulogic_vector rather than std_logic_vector (similarly, use std_ulogic rather than std_logic for bits) than the simulator will flag the error during a compile as well...without having to debug anything.   Since you're a beginner, I would suggest learning how to use a simulator. Once you're even mildly proficient, you will be far more productive debugging problems in a simulation environment...much more so than debugging hardware or asking on a forum (not a criticism, just a suggestion).   For your current problem, you can ignore Tricky's question about why you are not using a clock for a synchronous design. Your design as posted has no need for a clock, or a process. It's fine except for the items I noted above (assuming that you did get the pin numbering correct as Tricky suggested that you verify, which you say you did).   Kevin Jennings

[Altera_Forum]

One additional thing to add is the some editors / IDE's catch this sort of thing before even attempting to compile. This alleviates headaches when trying to discern if there is an actual problem with hardware. My personal favorite is the Sigasi HDT editor. I've attached an image of how it found the "multiple markers at line 65" error, because of the issue with  

 sample_out<=sample reg; -- Note the space between 'sample' and 'reg'  James

[Altera_Forum]

Thanks for the replies. Your right, i messed the copy/pasting up. However, my problem still stands.  

 As soon as i change the multiply by SW to a binary value eg ("0000000000111111") then the volume changes as expected.  Both version compile fine. All i want to do is have the the switches represent that 16 bit binary multiplying value.   I've done things more complicated than this but for some reason i just cant see whats going wrong here. There is no audio output suggesting all the samples are being multiplied by zeros. The switches are connected on the top level in block diagram format. SW[15..0]   library IEEE; use IEEE.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_signed.all; entity volume is port ( -- data sample_in: in std_logic_vector(15 downto 0); --zero is msb sample_out: out std_logic_vector(15 downto 0); -- params SW: in std_logic_vector(15 downto 0) ); end entity volume; architecture beh of volume is signal signal_unnormalized: std_logic_vector(31 downto 0); begin signal_unnormalized <= sample_in * SW; sample_out <= signal_unnormalized(31) & signal_unnormalized(22 downto 8); end architecture beh;

[Altera_Forum]

--- Quote Start ---    Thanks for the replies. Your right, i messed the copy/pasting up. However, my problem still stands.    As soon as i change the multiply by SW to a binary value eg ("0000000000111111") then the volume changes as expected.   --- Quote End ---   Since you later refer to a "top level in block diagram format" this implies to me that there is some other level to the hierarchy. So one suggestion would be to connect "0000000000111111" on that level to the SW input of the volume entity and see if it still works.   Some other easy thing to check are: - You should have a timing path from each of the SW input pins to each of the output pins. If not, then it suggests you're not connecting SW correctly to your 'volume' entity. - Take a look at the post-route netlist viewer and see if there is a logic path all the way from the SW input pins to all of the output pins     --- Quote Start ---  I've done things more complicated than this but for some reason i just cant see whats going wrong here. There is no audio output suggesting all the samples are being multiplied by zeros. The switches are connected on the top level in block diagram format. SW[15..0]  --- Quote End ---  The other thing that it suggests is that SW is not really connected. This could be because of pin assignments being wrong (as you already checked) or because their is an error in the top level connection to this entity. Since you've probably already eyeballed the connection and not found anything, the next step would be to look at output reports to see if things that should be true really are (i.e. the timing paths and netlist view that I mentioned).   Kevin Jennings

[Altera_Forum]

Thanks Kevin,  

I connected vccs in the top level, replacing the switches and it worked - lower volume audio on channel1 as expected  http://farm8.staticflickr.com/7015/6754948481_5471b4c4cd.jpg    As soon as i connect the switches i get nothing from the audio http://farm8.staticflickr.com/7003/6754963697_ac5eaf3c83.jpg    I looked in the RTL viewer, technology map viewer post mapping and post fitting in Quartus and the switches are connected right down to the lowest level.  I'm not sure what you mean by timing path from input pins to output pins?   Is there something totally obvious i am missing here?

[Altera_Forum]

Looking at your design, SW8-16 will probably be set to 0. 

Because of your truncation, the maximum audio gain you can get is just less than 1, and thats when all switches are set to 1. Are you setting all switches to 1? Is your input big enough in the first place?

[Altera_Forum]

--- Quote Start ---  Looking at your design, SW8-16 will probably be set to 0. Because of your truncation, the maximum audio gain you can get is just less than 1, and thats when all switches are set to 1. Are you setting all switches to 1? Is your input big enough in the first place?  --- Quote End ---    Tricky, i only connected half of the switches here just to test it. I still should get audio out though even though, like you say, will be lower in amplitude.  The problem is that i get no audio at all when the switches are connected (as above)  whereas connecting the same pins to high/vcc (as above) i get the lower amplitude audio as expected.   This isn't the complete design but i cant/wont go any further until i can use the DE2s switches to control the value of the multiplier.   I really hope someone spots something i haven't   cheers

[Altera_Forum]

--- Quote Start ---    I looked in the RTL viewer, technology map viewer post mapping and post fitting in Quartus and the switches are connected right down to the lowest level.   I'm not sure what you mean by timing path from input pins to output pins?   --- Quote End ---   I meant simply to look in the timing report to see if Quartus is reporting a Tpd path from every input pin to every output pin. It should since your design as posted should result in a totally combinatorial logic path. The thought is that somehow things didn't get connected in a higher up level which if they didn't would result in some pins not having such a path. However, since you've used the netlist viewer on the post map to verify that there are indeed all of the logic paths there is no need to look for a timing path.      --- Quote Start ---  Is there something totally obvious i am missing here?  --- Quote End ---   About the only thing left is that the switches are not hooked up on the board to the pins that you are specifying in the FPGA design. Verify with a scope or meter that when you change a particular switch setting that the pin in question really does toggle and go to the expected voltage level.   Kevin Jennings

[Altera_Forum]

--- Quote Start ---  I meant simply to look in the timing report to see if Quartus is reporting a Tpd path from every input pin to every output pin. It should since your design as posted should result in a totally combinatorial logic path. The thought is that somehow things didn't get connected in a higher up level which if they didn't would result in some pins not having such a path. However, since you've used the netlist viewer on the post map to verify that there are indeed all of the logic paths there is no need to look for a timing path.     About the only thing left is that the switches are not hooked up on the board to the pins that you are specifying in the FPGA design. Verify with a scope or meter that when you change a particular switch setting that the pin in question really does toggle and go to the expected voltage level.   Kevin Jennings  --- Quote End ---    The switches are definitely connected, i used them to control the on board LEDS.  I've tried so many different things here!  The only other thing i can think of is that maybe its some kind of syntax problem for example do i need to specify i want to use the binary value of 'SW' and multiply this. I'm guessing this is assumed though.

[Altera_Forum]

You could try registering your signals and then use signal tap to check your circuits logic. If it works with registers then it is probably a timing issue. If it still isn't working you should be able to see where your errors are, like switches not working correctly.

[Altera_Forum]

--- Quote Start ---  The switches are definitely connected, i used them to control the on board LEDS.  --- Quote End ---   Not to be persnickety (since I don't know what you have and haven't actually done), but are you sure that each switch was controlling the correct LED? Same pins?     --- Quote Start ---    I've tried so many different things here!   The only other thing i can think of is that maybe its some kind of syntax problem for example do i need to specify i want to use the binary value of 'SW' and multiply this. I'm guessing this is assumed though.   --- Quote End ---   At this point, you can probably expect to only get more guesses, but fundamentally if you have the following things it will work so it is worth questioning and even re-checking to verify that you really do have all these items: - Correct pin assignments. Are you verifying the pins in the output report from Quartus match what you think they should be? - Correct synthesis: Try running the post-route simulation model to see if it works correctly. Are you really downloading the correct file to the device? How do you know? - Bad synthesis tool: Try running a different version of Quartus   I realize that these aren't likely to really help, but it looks like you're at the point where everything you should do you have done so the best advice would be for you to play your own devil's advocate and question everything at this point and accept nothing that you haven't proved as directly as possible. Don't accept things like 'well this worked so therefore xxx must be'. Measure xxx if at all possible.   Good luck, wish I could be more help, but I'm running short on ideas.   Kevin Jennings

[Altera_Forum]

Ok i got it working. It was something i had no idea would make a difference but thought i'd try it. I hope you might be able to explain or help me understand why this makes a difference 

 I added what a few other designs i've seen call a pipeline buffer- code below From looking at this, it just seems like the audio samples are being synced upto the system clock edge but i dont understand why that is necessary.    library IEEE; use IEEE.std_logic_1164.all; entity pipeline_buffer is port ( clk: in std_logic; lrclk: in std_logic; reset: in std_logic; -- data sample_in_left: in std_logic_vector(15 downto 0); sample_out_left: out std_logic_vector(15 downto 0); sample_in_right: in std_logic_vector(15 downto 0); sample_out_right: out std_logic_vector(15 downto 0) ); end entity pipeline_buffer; architecture beh of pipeline_buffer is signal last_lrclk: std_logic; begin process (clk, reset) begin if (reset='0') then sample_out_right <= (others => '0'); sample_out_left <= (others => '0'); elsif rising_edge(clk) then sample_out_right <= sample_in_right; sample_out_left <= sample_in_left; end if; end process; end architecture beh;

[Altera_Forum]

--- Quote Start ---  Ok i got it working. It was something i had no idea would make a difference but thought i'd try it. I hope you might be able to explain or help me understand why this makes a difference   I added what a few other designs i've seen call a pipeline buffer- code below From looking at this, it just seems like the audio samples are being synced upto the system clock edge but i dont understand why that is necessary.    --- Quote End ---     Nor will anyone else likely be able to figure out why is was necessary since you haven't posted your entire design (both the 'working' and the 'not working'). Synchronizing signals to a clock is necessary when asynchronous signals or signals from a different clock domain are used with synchronous logic, but the original code you posted has no clock so that wouldn't be the case...unless you haven't posted something that is relevant to the design. As an example, it is not even clear how your samples have morphed into a 'left' and a 'right'.   Kevin

[Altera_Forum]

--- Quote Start ---  Nor will anyone else likely be able to figure out why is was necessary since you haven't posted your entire design (both the 'working' and the 'not working'). Synchronizing signals to a clock is necessary when asynchronous signals or signals from a different clock domain are used with synchronous logic, but the original code you posted has no clock so that wouldn't be the case...unless you haven't posted something that is relevant to the design. As an example, it is not even clear how your samples have morphed into a 'left' and a 'right'.   Kevin  --- Quote End ---    Yeah i guess it makes sense. I creates a serial in parallel out which frames the serial stream from the CODEC out and extracts left and right.   Kevin, thanks very much for your time and help on this :-)   Now i can move on with the project