Byte lane select

J

Jan

Guest
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 8) 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$14726298@news.sunsite.dk...
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 8) 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.
Click to expand...
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.
Click to expand...
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?
Click to expand...
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.
Click to expand...
It is pretty straight forward to use a simulator also.

The function Im trying to make is:
pixel(24bit) is input to the module.
Click to expand...
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
Click to expand...
to the module.

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

Any help is greatly appreciated!
Click to expand...
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$14726298@news.sunsite.dk...
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
Click to expand...
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
Click to expand...
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
Click to expand...
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$14726298@news.sunsite.dk...
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.
Click to expand...
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
 
On Mon, 20 Oct 2008 09:27:34 +0200, Jan
<webpjat@future-design_DELETE.dk> wrote:

KJ wrote:
"Jan" <webpjat@future-design_DELETE.dk> wrote in message
news:48f97a4e$0$90266$14726298@news.sunsite.dk...
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..
Click to expand...
This is pretty much the wrong way round.

The compiler usually optimizes some important net to neverland because
it is actually unused for some not very obvious reason; that reason
generally means the code would never have passed simulation.

- Brian
 
Jan wrote:
the simulator will not help me when the
compiler optimizes some important NET to neverland..
Click to expand...
The synthesizer doesn't optimize important nets away. If the
net is optimized away, either it wasn't driving anything, or it
had a constant value, or it was driving only circuitry that resulted
in a constant value.

The simulator *will* help. If you have nets that you think are
important, but are actually not working correctly in such a way
that the synthesizer might remove them, you'll be able to see that
in the simulation results.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top