PortMapping inside if statement?

[Bman900]

Well I have some code that basically takes 3 buttons and to increase counters and then I add them together and store in a register. This is used to enter amount of a product some one might want for example.

But then I want to use these same 3 buttons to simulate the entering of money into the system. So the way I was thinking is using a switch to actually switch between the 2 occasion I will need.

Now I now you can't simply do this since portmaping can not be used inside a process which is where an if statement lives.

I then tried generate but that did not work either. So any one have any idea?

Here is the code that am talking about, but only works with 1 register and for one thing.

L1: block1 generic map(8) port map(BUTTON1, BUTTON2, RST, CIN, COUT,SUM1);	--adds the 2 values toghter from 2 counters that 
	--is controled by button 1 and 2
	L2: count10 generic map(8) port map(BUTTON3, RST, BUTTON3COUNT);	--this will control another counter with button 3
	L3: FA generic map(8) port map(SUM1,BUTTON3COUNT,CIN2,SUM2,COUT2); -- now we add the sum from the first 2 counters with 
	--the value from counter 2

 

[FvM]

Regarding the question addressed in the title: Yes you're right, it simply doesn't work.

I then tried generate but that did not work either.

You should look sharp and analyze which error is brought up in this case. I guess, its a "multiple drivers" issue, because the same signal is driven concurrently by multiple component instances. That's not a reasonable way to implement alternative data pathes. Each instance needs it's individual output signal, then you need to switch between the signals, e.g. using a conditional assignment, or in a process.

 

[Bman900]

Regarding the question addressed in the title: Yes you're right, it simply doesn't work.

You should look sharp and analyze which error is brought up in this case. I guess, its a "multiple drivers" issue, because the same signal is driven concurrently by multiple component instances. That's not a reasonable way to implement alternative data pathes. Each instance needs it's individual output signal, then you need to switch between the signals, e.g. using a conditional assignment, or in a process.

Yes, I know what you are talking about and this is exactly how I switch between my 3 registers to display them on the 7 segment but the problem in this case is that in the first instance I have to work on 8 bits since it will be multiplied and in the second case I must work with 15 bits. I tried using a signal inside the generic map() but I have found out it needs to be static which is not good for me.

If there would be a way to somehow make the number inside the generic map() changeable I can just use the signal method you talked about above.

 

[FvM]

If you need to change the generic value, you either have to redefine the component, or use multiple instances with different generic value, and multiplex the output signals.

 

[Bman900]

What do you mean by redefine the component?

This is how one of my components look like:

component block1 is	
	generic(N: natural);
	port(COUNT1,COUNT2, RST : in std_logic;
	CIN: in std_logic;
	COUT: out std_logic;
	SUM: out std_logic_vector(N-1 downto 0));
end component;

 

[TrickyDicky]

If you need to change a generic at run time, why is it a generic and not a port?

 

[Bman900]

If you need to change a generic at run time, why is it a generic and not a port?

Well I don't know how to set natural numbers with ports but I think I solved the problem by introducing an enable.

 

[TrickyDicky]

you can have any type in a port map:

entity my_ent is
  port (
    a : in std_logic_vector(3 downto 0);
    b : in natural;
    c : in boolean;
    d : out my_exotic_type;
    e : out real;  --this is not synthesisable
    f : out integer
  );
end entity my_ent;

 

[FvM]

Yes of course natural type can be used in ports. But referring to your post #5, changing a generic value dynamically that sets port signal widths doesn't make sense. But may be this is, because you never showed an example of the real problem.