I cant work this out!

have you assigned the switches to the correct pins?

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

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!

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

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

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; 

--- 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

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?

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 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

--- 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