Port assignment question

Hi

in VHDL , i want to assign, say a 32 bit bus to another excpet some
bits

Example :

signal bus_1 : std_logic_vector(31 downto 0);
signal bus_2 : std_logic_vector(31 downto 0);
signal pin_11 :std_logic;
signal pin_22 :std_logic;

i want :
bus_1(31 downto 23) <= bus_2(31 downto 23);
bus_1(22) <= pin_22;
bus_1(21 downto 12) <= bus_2(21 downto 12);
bus_1(11) <= pin_11;
bus_1(10 downto 0) <= bus_2(10 downto 0);

uff, is there an easy way to do that ?

Best Regards,
barme2i.

barme2i@gmail.com wrote:
> Hi
> 
> in VHDL , i want to assign, say a 32 bit bus to another excpet some
> bits
> 
> Example :
> 
> signal bus_1 : std_logic_vector(31 downto 0);
> signal bus_2 : std_logic_vector(31 downto 0);
> signal pin_11 :std_logic;
> signal pin_22 :std_logic;
> 
> i want :
> bus_1(31 downto 23) <= bus_2(31 downto 23);
> bus_1(22) <= pin_22;
> bus_1(21 downto 12) <= bus_2(21 downto 12);
> bus_1(11) <= pin_11;
> bus_1(10 downto 0) <= bus_2(10 downto 0);
> 
> uff, is there an easy way to do that ?

Not really. There's a few possibilities to do it "differently", though,
maybe one of them suits you better:

1. Put it all in one single statement:
bus_1 <= bus_2(31 downto 23) & pin_22 & bus_2(21 downto 12) & pin_11 &
bus_2(10 downto 0);

2. Put these statements inside a process (doesn't matter if it's clocked
or not):

bus_1 <= bus_2;
bus_1 <= (22 => pin_22, 11 => pin_11);

The latter, as I mentioned, works only inside a process, otherwise
you'll get a "multiple drivers" error.

Disclaimer: Haven't verfied this, might not work (as expected). :)

HTH,
Sean

-- 
Replace "MONTH" with the three-letter abbreviation of the current month
(simple, eh?).

I agree with Sean, there is no "except" statement or so to handle this
kind of issues

The quickest way is to put ur buses in a process, assign them normally
with (bus_1 <= bus_2; in your example)
then override the "except " pins at the end or the process.

put a clock in your process : process(clk) but don't use it inernally,
it is just a syntax issue .

Tested with Xilinx XST !

Hassen KARRAY

On Wed, 20 May 2009 10:42:13 +0200, Sean Durkin wrote:

>2. Put these statements inside a process 
>(doesn't matter if it's clocked or not):
>
>bus_1 <= bus_2;
>bus_1 <= (22 => pin_22, 11 => pin_11);

Not quite; the aggregate has lots of missing subscripts
and won't work.  This will, though:

  process ....
  begin
    ....
    bus_1 <= bus_2;  -- get all the defaults
    bus_1(22) <= pin_22;  -- exception #1
    bus_1(11) <= pin_11;  -- exception #2
    ...
  end process;

Here's another possibility, rather more VHDL syntax trouble,
 but perhaps prettier and more flexible.  Create a
data type that represents an "exception": a bit
number, and the std_logic value to put into it...

  type exception is record
    subscript: natural;
    value    : std_logic;
  end record;

And now make an unconstrained array of them:

  type exception_list is array (natural range <>) of exception;

Now you can create a function that copies one std_logic_vector
to another, providing a default but also allowing for exceptions:

  function patchup
    ( vec: std_logic_vector  -- the original vector
    ; diffs: exception_list  -- bits to update
    ) return std_logic_vector
  is
    variable result: std_logic_vector(vec'range);
  begin
    result := vec;  -- get most of the bits from original
    for i in diffs'range loop -- scan the exceptions
      result(diffs(i).subscript) := diffs(i).value;
    end loop;
    return result;
  end;

And your copy operation might look like this:

  bus_1 <= patchup( bus_2, ( (11, pin_11), (22, pin_22) ) );

Note the nested aggregate: each inner value such as (11, pin_11)
represents one "exception" record, and the outer parentheses 
enclose an "exception_list" array.  The array will be 
numbered (0 to 1), but you don't care about that.

This should be synthesisable.  I reckon that the trouble of 
writing the function is well worth it if you are going to 
do that sort of thing more than once.  And of course the 
type definitions and the function are not locked to any
specific design, so they could go in a package.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

hassen.karray@gmail.com a �crit :

> put a clock in your process : process(clk) but don't use it inernally,
> it is just a syntax issue .


WHAT ?!
This is pure nonsense. Put your input signals in the sensitivity list : 
process (bus2, pin_11, pin_22)

Nicolas

On 20 mai, 23:19, Nicolas Matringe <nicolas.matri...@fre.fre> wrote:
> hassen.kar...@gmail.com a =E9crit :
>
> > put a clock in your process : process(clk) but don't use it inernally,
> > it is just a syntax issue .
>
> WHAT ?!
> This is pure nonsense. Put your input signals in the sensitivity list :
> process (bus2, pin_11, pin_22)
>
> Nicolas

Dear Nicolas,

You can put input signals in your sensitivity list ! you can also put
your clock ...

As long he'll not use any rising or falling edges , it will be
synthesized the same way.

Now, Talking about " pure nonsense " , assigning the same signal twice
or more in the very same single process is theorically "pure nonsence"
too, since only one single driver will be allowed finally ;)

Either ways here, Synthsis tool will handle the design the same way
and will finally put direct assignments , no clock, no input signals
sensitive FF or latches ...

We are talking here about a kind of tip to do things rapidly ... i
agree with you that it is not academic though !

I have seen people with deep knowledge about synthesis and
implementation tools doing awesome things with VHDL, they code in a "
pure nonsence " style and get things working very quickly ... i
somehow like that even though it doesn't garantee portability ...

Best Regards,
Hassen KARRAY.

Hassen,

Putting clock (and only clock) in the sensitivity list of a non-
clocked process is pure nonsense when you (attempt to) simulate it.

Recommending practices that categorically exclude simulation is pure
nonsense.

Andy

On 21 mai, 16:15, Andy <jonesa...@comcast.net> wrote:
> Hassen,
>
> Putting clock (and only clock) in the sensitivity list of a non-
> clocked process is pure nonsense when you (attempt to) simulate it.
>
> Recommending practices that categorically exclude simulation is pure
> nonsense.
>
> Andy

right :) hehe

Actually, to be clear, i do not recommand excluding simulation and i
don't see where i did.

Anyway, when considering simulation, process without sensiticvity list
is possible ( talking about syntax ) !

Here we are in a case where normally no sensitivity list is required.
no clocked process, nothing !

I have a question for you. will you put a sensitivity list when
simulating ???  i won't !  because i need that process just for
sequential issues.

Now, if we put no signals in the sensitivity list when simulating, why
would we put that when synthesising ?

XST or other vendor synthesisers should accept such process. XST do
but requires but its syntax checker don't accept process with no
signals !

I didn't try that with Altera or actel or any other. but i was talking
about Xilinx tools , and mentioned that since its a kind of syntax
BUG , he can put any signal in the sensitivity list then just don't
use it.

To summerise, if i had to do that, i would simulate with no
sensitivity list : process().
i would then consider putting any signal to calm down XST ! example :
process (any_signal) -- any_signal added just for syntax reasons ...

This would avoid putting an eventual hundred signals in the
sensitivity list ( academic style ).

And remember the main concern of Barme2i is time. i don't think he'd
be happy with a solution that makes him put 10 lines sensitivity
list...

Hope you get my point ..

Hassen.

<hassen.karray@gmail.com> wrote in message news:2e641a95-6aa1-4fb9-bb9a->
> Here we are in a case where normally no sensitivity list is required.
> no clocked process, nothing !
>

In your earlier posting you stated
The quickest way is to put ur buses in a process, assign them normally
with (bus_1 <= bus_2; in your example)
then override the "except " pins at the end or the process.

bus_2 is a signal (from the original post), therefore bus2 does belong in 
the sensitivity list.  Your claim that there are no signals required in the 
sensitivity list, or your later nonsense about putting 'clock' into the 
sensitivity list is off base.  bus_1 changes upon changes to bus_2, end of 
story.

> I have a question for you. will you put a sensitivity list when
> simulating ???  i won't !  because i need that process just for
> sequential issues.
>

I'll give you the benefit of the doubt that you're not explaining what you 
really mean correctly.  A sensitivity list should be used, and it has 
absolutely nothing to do with 'simulating' unless by that you're saying you 
don't care that your simulation model bears any relationship at all to what 
gets synthesized and implemented.  Unless you use wait statements within the 
process (which can cause synthesizers to reject your code) you won't even be 
able to successfully compile (for synthesis or simulation).

Example of a process with no sensitivity list (not necessarily recommended 
for designs intended to be synthesized)
process
begin
  wait until bus_2'event;
  bus_1 <= bus2;
  ...
end process;

Example of the equivalent but using a sensitivity list (recommended 
approach...and less typing to boot)
process(bus_2)
begin
  bus_1 <= bus2;
  ...
end process;

> Now, if we put no signals in the sensitivity list when simulating, why
> would we put that when synthesising ?
>
Because you want to get a working design and you want to have a simulation 
model that matches the actual implementation.  Debugging in a simulation 
environment is often times much more productive than doing so on hardware. 
Even if that's not your experience, what you're doing will inhibit you from 
being able to use a simulator to reliably do any debug.

> XST or other vendor synthesisers should accept such process. XST do
> but requires but its syntax checker don't accept process with no
> signals !
>

In the same sentence you're saying that XST does and that it doesn't accept 
processes with no signals.

> I didn't try that with Altera or actel or any other. but i was talking
> about Xilinx tools , and mentioned that since its a kind of syntax
> BUG , he can put any signal in the sensitivity list then just don't
> use it.
>

The bug is in your understanding of processes coupled with how current 
synthesis tools incorrectly treat processes.  When you have an incomplete 
sensitivity list (like an empty one), the sensitivity list will generate a 
warning about this.  The reason for the warning is that the synthesis tool 
is treating the process differently than the VHDL language specification 
requires it to do (i.e. it is violating the VHDL spec).  Another tool, like 
a simulator, probably wouldn't blatantly violate the language specification. 
Since the two tools are applying two different interpretations to the same 
source code input, it is quite likely that the simulation will produce 
different results than what gets implemented in the synthesized 
hardware...good luck debugging problems when you intentionally allow the 
creation of such avoidable issues.  Just because you would 'prefer' the 
language to be defined the way the synthesis tool is using it, doesn't mean 
that that's the way the language is defined.

> To summerise, if i had to do that, i would simulate with no
> sensitivity list : process().
> i would then consider putting any signal to calm down XST ! example :
> process (any_signal) -- any_signal added just for syntax reasons ...
>
> This would avoid putting an eventual hundred signals in the
> sensitivity list ( academic style ).
>

Am I to take from the above, that academics don't care whether the 
simulation model for something does NOT match what that real something does? 
Because that's exactly what you're doing with your approach.  As for the 
"eventual hundred signals in the sensitivity list", that pretty much says 
that you don't do a very good job at design in the first place...but help is 
on the way, VHDL 2008 will allow you to an easy way to properly handle this 
without listing those hundred signals, and not creating differences between 
the sim model and reality.

> And remember the main concern of Barme2i is time. i don't think he'd
> be happy with a solution that makes him put 10 lines sensitivity
> list...
>
One signal in the sensitivity list should not take 10 lines...

Kevin Jennings