«

Hi Rob,
Have you tried:

(this_q, that_q, the_other_q) <= (this, that, the_other) when
rising_edge(clk);

I haven't tried it and am concerned there may be a type ambiguity
problem.

In general, if I wanted to block things together like this,
I would use the array as the input and define index constants
to extract the values when necessary:

package CritterPkg is
constant THIS_INDEX : integer := 0 ;
constant THAT_INDEX : integer := THIS + 1 ;
constant THE_OTHER_INDEX : integer := THAT + 1 ;
subtype critter_type is std_logic_vector (THE_OTHER_INDEX downto
THIS_INDEX) ;

end package CritterPkg ;

entity Critter is
Port (
Critter_In : in critter_type ;
Critter_Out : out critter_type ;

clk : in std_logic
);
end entity Critter;

architecture Behavioural of Critter is
signal this_int : std_logic ;

begin

Critter_out <= Critter_in when rising_edge(clk);

-- to reference individual values:
this_int <= Critter_in(THIS_INDEX) ;

end architecture Behavioural;

At the port map:

U_Critter : critter
port map (
Critter_in(THIS_INDEX) => this,
Critter_in(THAT_INDEX) => that,
Critter_in(THE_OTHER_INDEX) => the_other,
Critter_out(THIS_INDEX) => this_q,
Critter_out(THAT_INDEX) => that_q,
Critter_out(THE_OTHER_INDEX) => the_other_q,
Clk => Clk
) ;

Record fields would also work well if your synthesis tool does
not complain about records.

On that note, does anyone know if the following is portable
(particularly concerned about some of the ASIC tools):
outputs <= inputs when rising_edge(clk);

Cheers,
Jim

JimLewis <> writes:

> Have you tried:
>
> (this_q, that_q, the_other_q) <= (this, that, the_other) when
> rising_edge(clk);
>
> I haven't tried it and am concerned there may be a type ambiguity
> problem.
>

From recent experience (last month), I had Synplify fail on trying to
handle an aggregate assignmnent. AFAIK, this is a tool bug; it was a
well typed expression and Modelsim was quite happy to do the right
thing. I was trying to be all elegant and clean, and then, whammo,
another dumb tool limitation. Sigh...

>
> On that note, does anyone know if the following is portable
> (particularly concerned about some of the ASIC tools):
> outputs <= inputs when rising_edge(clk);
>
> Cheers,
> Jim

I took a look at IEEE 1076.6-1999, sec 8.9.5.1 : conditional
assignments. It looks like an assignment with a last "when" condition is
explicitly disallowed. Maybe that's out of date, though.

- Kenn

--------------------------------
“ A man is as happy as he makes up his mind to be.”-- Abraham Lincoln
---------------------------------

On Nov 26, 8:29*am, Kenn Heinrich <kwhei...@uwaterloo.ca> wrote:
>
> > On that note, does anyone know if the following is portable
> > (particularly concerned about some of the ASIC tools):
> > * * outputs <= inputs when rising_edge(clk);
>
> > Cheers,
> > Jim
>
> I took a look at IEEE 1076.6-1999, sec 8.9.5.1 : conditional
> assignments. It looks like an assignment with a last "when" condition is
> explicitly disallowed. Maybe that's out of date, though.
>

Quartus is quite happy with...
outputs <= inputs when rising_edge(clk);

It's also quite happy with the somewhat more complex...
X1_Dlyd <= X1 when (REGISTER_INPUTS = '0') else X1 when rising_edge
(Clock);

where 'REGISTER_INPUTS' is a generic input to the entity that controls
whether I want to add some flops to improve timing on a case by case
basis for a reusable entity. That entity also has other generics for
controlling whether or not to add output flops as well as flops
internally during the calculation.

When written as indicated above, the code stays relatively clean, not
losing the intent of the algorithm buried beneath implementation
options. If put into the standard form of "process(clk)..." it got
kind of ugly. Haven't tried it when REGISTER_INPUTS is a signal (nor
do I see any need to do so).

This doesn't say anything about Jim's concern about portability to
ASIC tools, but it is a data point about tool capabilities.

Kevin Jennings