«

Dear all,

I've been trying for hours now to get a MUX written in VHDL to work. But
now I'm giving up

Here is my VHDL:

architecture Behavioral of pixel_clusterX3 is
signal pixels : STD_LOGIC_VECTOR (23 downto 0);;
signal color_values : STD_LOGIC_VECTOR (7 downto 0);

begin
-- This process takes one pixel and splits it into colors.
-- The color value is then forwarded to the color_value signal.
color_select: WITH color_pointer(1 downto 0) SELECT
color_values <=
pixels(7 downto 0) WHEN "00",
pixels(15 downto WHEN "01",
pixels(23 downto 16) WHEN "10",
(others => '0') WHEN OTHERS;
end Behavioral;

pixels are MAPPED to a memory.
color_values are MAPPED to another component.

It compiles fine however, when I examine the RTL Schematic I discovered
that the compiler converts my VHDL into a MUX. So far so good. The
problem is that the SEL input on the mux isn't connected.

Can someone see what I'm doing wrong? It should be pretty straight
forward, but it isn't.

The function Im trying to make is:
pixel(24bit) is input to the module.
color_pointer(2bit) is input to the module.
color_values(8bit) is output from the module.

color_pointer selects which of the 3 bytes in pixel is forwarded to
color_values.

Any help is greatly appreciated!

regards
Jan

"Jan" <webpjat@future-design_DELETE.dk> wrote in message
news:48f97a4e$0$90266$...
> Dear all,
>
> I've been trying for hours now to get a MUX written in VHDL to work. But
> now I'm giving up
>
> Here is my VHDL:
>
> architecture Behavioral of pixel_clusterX3 is
> signal pixels : STD_LOGIC_VECTOR (23 downto 0);;
> signal color_values : STD_LOGIC_VECTOR (7 downto 0);
>
> begin
> -- This process takes one pixel and splits it into colors.
> -- The color value is then forwarded to the color_value signal.
> color_select: WITH color_pointer(1 downto 0) SELECT
> color_values <=
> pixels(7 downto 0) WHEN "00",
> pixels(15 downto WHEN "01",
> pixels(23 downto 16) WHEN "10",
> (others => '0') WHEN OTHERS;
> end Behavioral;
>
> pixels are MAPPED to a memory.
> color_values are MAPPED to another component.
>
> It compiles fine however, when I examine the RTL Schematic I discovered
> that the compiler converts my VHDL into a MUX. So far so good.

Don't bother looking at schematics, use a simulator to get the function
correct first. You'll be much more productive and won't find yourself
having to ask a newsgroup to debug your stuff.

> The problem is that the SEL input on the mux isn't connected.
>

What is driving the color_pointer signal? If that signal was really not
connected though the whole mux would disappear since the whole thing could
be optimized to just setting color_values always to all zeros. Again, the
simulator is the proper tool for debug to get the function correct, not
newsgroups.

> Can someone see what I'm doing wrong?

You're not using a simulator. Also there really isn't enough info in your
posting for anyone to find the problem for you.

> It should be pretty straight forward, but it isn't.
>

It is pretty straight forward to use a simulator also.

> The function Im trying to make is:
> pixel(24bit) is input to the module.

And yet it is shown above not as an input but an internal signal to the
module.

> color_pointer(2bit) is input to the module.
> color_values(8bit) is output from the module.
>
And yet color_values is shown above not as an output but an internal signal
to the module.

> color_pointer selects which of the 3 bytes in pixel is forwarded to
> color_values.
>
> Any help is greatly appreciated!
>

The exercise of writing up a description as you've done is usually a good
way to flesh out the design errors. In fact, several times people post
something and then want to say 'Doh', because they just figured it out. In
your case, you've described input and output signals (which would then be on
the entity) which your posted code says are internal signals...I'd start
there if I were you...and run the simulator next.

Kevin Jennings

KJ wrote:
> "Jan" <webpjat@future-design_DELETE.dk> wrote in message
> news:48f97a4e$0$90266$...
>> It compiles fine however, when I examine the RTL Schematic I discovered
>> that the compiler converts my VHDL into a MUX. So far so good.
>
> Don't bother looking at schematics, use a simulator to get the function
> correct first. You'll be much more productive and won't find yourself
> having to ask a newsgroup to debug your stuff.
Thank you for the advice. But the simulator will not help me when the
compiler optimizes some important NET to neverland..
I was not asking for someone to DEBUG the functionality of my code. It
was simply a matter of wrong syntax...

>
>> The problem is that the SEL input on the mux isn't connected.
>>
>
> What is driving the color_pointer signal? If that signal was really not
> connected though the whole mux would disappear since the whole thing could
> be optimized to just setting color_values always to all zeros. Again, the
> simulator is the proper tool for debug to get the function correct, not
> newsgroups.
Again... The MUX is there in the NET, but the SELECT net was removed and
left OPEN. Now... How will you debug what in the simulator? I don't have
to use the simulator, I can figure out the outcome without. IE, It won't
work

>
>> Can someone see what I'm doing wrong?
>
> You're not using a simulator. Also there really isn't enough info in your
> posting for anyone to find the problem for you.
>
>> It should be pretty straight forward, but it isn't.
>>
>
> It is pretty straight forward to use a simulator also.
Yes. I know. And I use it all the time (When the NET is intact)
>
>> Any help is greatly appreciated!
>>
>
> The exercise of writing up a description as you've done is usually a good
> way to flesh out the design errors. In fact, several times people post
> something and then want to say 'Doh', because they just figured it out. In
> your case, you've described input and output signals (which would then be on
> the entity) which your posted code says are internal signals...I'd start
> there if I were you...and run the simulator next.
Sorry. The code I wrote in the post, was not the exact code from my
project. I wrote up the problem in a clean form in the POST and got the
signal definition wrong. I still haven't solved THAT problem, but got
around it.

Next time I use the group I will make sure to be more precise when
describing my problem...

Regards
Jan

You said that color_pointer(2bit) is input to the module. Something
wrong with port mapping?

/Peter

On Oct 20, 3:27*am, Jan <webpjat@future-design_DELETE.dk> wrote:
> KJ wrote:
> > "Jan" <webpjat@future-design_DELETE.dk> wrote in message
> >news:48f97a4e$0$90266$. ..
> >> It compiles fine however, when I examine the RTL Schematic I discovered
> >> that the compiler converts my VHDL into a MUX. So far so good.
>
> > Don't bother looking at schematics, use a simulator to get the function
> > correct first. *You'll be much more productive and won't find yourself
> > having to ask a newsgroup to debug your stuff.
>
> Thank you for the advice. But the simulator will not help me when the
> compiler optimizes some important NET to neverland..
> I was not asking for someone to DEBUG the functionality of my code.

You stated 'it compiled fine' but that is a far stretch from 'it
simulates correctly'. Until it simulates correctly it is rather
pointless in my opinion to worry about what sort of synthesis results
you get in an RTL viewer. Something silly like a single unconnected
input or output pin (as an example) causes logic to be optimized away
during synthesis, during simulation it causes some output to be 'X'.
You can scratch your head all day pondering why the synthesis result
is 'wrong' (it's not, the unconnected pin is likely shown as a
synthesis 'warning') or you can use simulation to debug and fix the
problem.

Maybe you really have run across a bug in the synthesis tool, but to
demonstrate that you need to have a pre-synthesis simulation that
shows one behaviour and a post-synthesis result that shows something
else...then you open a case with the synthesis tool supplier. Most of
the time though it's not the tool that has the problem.

As far as help out here, posting actual code is more useful then some
stripped down code that does not actually demonstrate the problem
you're asking for help with. It is helpful to clean up the code
before posting it, but you should also take the time to actually test
that cleaned up code to see that it really does demonstrate the
problem before posting.

Kevin Jennings