VHDL for problem

I have the following code:

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;

ENTITY ECROSSOVER IS
PORT (
CLK : IN bit := '0';
dad, mom : IN STD_ULOGIC_VECTOR(31 DOWNTO 0); -- 31 should be a
constant
son : OUT STD_ULOGIC_VECTOR(31 DOWNTO 0); -- 31 should be a constant
crosspoint : OUT STD_ULOGIC_VECTOR(7 DOWNTO 0)
);
END ECROSSOVER;

ARCHITECTURE ACROSSOVER OF ECROSSOVER IS
BEGIN
CROSS : PROCESS (CLK)
BEGIN
FOR1:
FOR i IN 0 TO 16 LOOP -- 16 should be crosspoint parameter
son(i) <= dad(i);
END LOOP FOR1;

FOR2:
FOR i IN 16 TO 31 LOOP -- 31 should be the same constant as in the
entity
son(i) <= mom(i);
END LOOP FOR2;
END PROCESS CROSS;
END ACROSSOVER;

My problem: I have to build a unit to do a crossover of two chromosome
and a crossover point, I did use fixed values in the declarations but I
should use constants, but I get compiler error when doing that. My idea
is to use 2 for loops copy the first part of one chromosome and
complete the rest of my new chromosome with the rest of the second
chromosome, like this:

father: 11110000
mother: 00001111
crosspoint : 4 (decimal value)

The result must be: 11111111

But I can't use signal or a variable in the for loop, is there any
other way to do this? or to correct my problem?

sergio.rolanski@gmail.com

On 22 Sep 2005 05:21:51 -0700, wrote:

>My problem: I have to build a unit to do a crossover of two chromosome
>and a crossover point, I did use fixed values in the declarations but I
>should use constants, but I get compiler error when doing that. My idea
>is to use 2 for loops copy the first part of one chromosome and
>complete the rest of my new chromosome with the rest of the second
>chromosome, like this:
>
>father: 11110000
>mother: 00001111
>crosspoint : 4 (decimal value)
>
>The result must be: 11111111

>ENTITY ECROSSOVER IS
> PORT (
> CLK : IN bit := '0';
> dad, mom : IN STD_ULOGIC_VECTOR(31 DOWNTO 0);
> son : OUT STD_ULOGIC_VECTOR(31 DOWNTO 0);
> crosspoint : OUT STD_ULOGIC_VECTOR(7 DOWNTO 0)
> );
>END ECROSSOVER;

Surely "crosspoint" should be an IN port????

Let me be sure I have this straight: Each bit in the output word
should be the corresponding bit (same bit number) chosen from
one of the two input words. Leftmost bits come from one of the
inputs, rightmost bits from the other. The bit number at which
the crossover happens should be dynamically specified by the
numeric value of "crosspoint".

Note: if "crosspoint" is fixed for each instance of this entity,
then you could make it a generic and life is much easier. But I
guess you want it to be dynamically variable.

So, assuming crosspoint is an input, how about this...

architecture A_jb of ECROSSOVER is
begin
process (CLK)
begin
if CLK'event and CLK='1' then -- Looks like you forgot this!
for i in son'range loop
if i > unsigned(crosspoint) then
son(i) <= dad(i);
else
son(i) <= mom(i);
end if;
end loop;
end if; -- rising_edge test
end process;
end;

However, this will create a LOT of logic because you will need
one arithmetic comparator for each bit of the "chromosome" word.
~~~~~~~~~~~~~~~~~~~
Here's another implementation that uses a "ripple carry" scheme.
Use a decoder to choose which is the FIRST bit to come from "mom".
All subsequent bits also come from "mom" because of the carry.

process (CLK)
variable from_mom: boolean;
begin
if CLK'event and CLK='1' then
from_mom := FALSE;
for i in son'range loop
if i = unsigned(crosspoint) then
from_mom := TRUE;
end if;
if from_mom then
son(i) <= mom(i);
else
son(i) <= dad(i);
end if;
end loop;
end if; -- rising_edge test
end process;

Because variable "from_mom" is given a new value each time
the process runs, it will not create a flip-flop - it will
make a cascade of logic. You need a new equality comparator
at each bit position because of the test
if i = unsigned(crosspoint)
but comparing a signal for equality with a constant is
very cheap (only an AND gate) so the logic is much smaller
than the previous version that had 32 arithmetic comparators.

The ripple carry arrangement will make the logic somewhat slow
and will limit your design's maximum clock speed. There are
some ingenious tree-structured schemes that would help if
this is a problem - but I suspect your first task is to get
something that works in simulation.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

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

Jonathan Bromley

Thanks a lot Jonathan, that will do the work. I'm not aiming for
performance at this point...things just have to work.

Jonathan Bromley wrote:
> On 22 Sep 2005 05:21:51 -0700, wrote:
>
> >My problem: I have to build a unit to do a crossover of two chromosome
> >and a crossover point, I did use fixed values in the declarations but I
> >should use constants, but I get compiler error when doing that. My idea
> >is to use 2 for loops copy the first part of one chromosome and
> >complete the rest of my new chromosome with the rest of the second
> >chromosome, like this:
> >
> >father: 11110000
> >mother: 00001111
> >crosspoint : 4 (decimal value)
> >
> >The result must be: 11111111
>
> >ENTITY ECROSSOVER IS
> > PORT (
> > CLK : IN bit := '0';
> > dad, mom : IN STD_ULOGIC_VECTOR(31 DOWNTO 0);
> > son : OUT STD_ULOGIC_VECTOR(31 DOWNTO 0);
> > crosspoint : OUT STD_ULOGIC_VECTOR(7 DOWNTO 0)
> > );
> >END ECROSSOVER;
>
> Surely "crosspoint" should be an IN port????
>
> Let me be sure I have this straight: Each bit in the output word
> should be the corresponding bit (same bit number) chosen from
> one of the two input words. Leftmost bits come from one of the
> inputs, rightmost bits from the other. The bit number at which
> the crossover happens should be dynamically specified by the
> numeric value of "crosspoint".
>
> Note: if "crosspoint" is fixed for each instance of this entity,
> then you could make it a generic and life is much easier. But I
> guess you want it to be dynamically variable.
>
> So, assuming crosspoint is an input, how about this...
>
> architecture A_jb of ECROSSOVER is
> begin
> process (CLK)
> begin
> if CLK'event and CLK='1' then -- Looks like you forgot this!
> for i in son'range loop
> if i > unsigned(crosspoint) then
> son(i) <= dad(i);
> else
> son(i) <= mom(i);
> end if;
> end loop;
> end if; -- rising_edge test
> end process;
> end;
>
> However, this will create a LOT of logic because you will need
> one arithmetic comparator for each bit of the "chromosome" word.
> ~~~~~~~~~~~~~~~~~~~
> Here's another implementation that uses a "ripple carry" scheme.
> Use a decoder to choose which is the FIRST bit to come from "mom".
> All subsequent bits also come from "mom" because of the carry.
>
> process (CLK)
> variable from_mom: boolean;
> begin
> if CLK'event and CLK='1' then
> from_mom := FALSE;
> for i in son'range loop
> if i = unsigned(crosspoint) then
> from_mom := TRUE;
> end if;
> if from_mom then
> son(i) <= mom(i);
> else
> son(i) <= dad(i);
> end if;
> end loop;
> end if; -- rising_edge test
> end process;
>
> Because variable "from_mom" is given a new value each time
> the process runs, it will not create a flip-flop - it will
> make a cascade of logic. You need a new equality comparator
> at each bit position because of the test
> if i = unsigned(crosspoint)
> but comparing a signal for equality with a constant is
> very cheap (only an AND gate) so the logic is much smaller
> than the previous version that had 32 arithmetic comparators.
>
> The ripple carry arrangement will make the logic somewhat slow
> and will limit your design's maximum clock speed. There are
> some ingenious tree-structured schemes that would help if
> this is a problem - but I suspect your first task is to get
> something that works in simulation.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services
>
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
> Tel: +44 (0)1425 471223 mail:
> Fax: +44 (0)1425 471573 Web: http://www.doulos.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

=?iso-8859-1?B?U+lyZ2lv?=

Jonathan Bromley wrote:

> Because variable "from_mom" is given a new value each time
> the process runs, it will not create a flip-flop - it will
> make a cascade of logic.

This is an excellent demonstration of how to
cover both combinational and registered
net descriptions concisely in a
single synchronous process, and how to
trade off delay for logic cells.

Well done Jonathan.


> The ripple carry arrangement will make the logic somewhat slow
> and will limit your design's maximum clock speed.

Yes.
Leo's estimate for a random device and default settings is:
83 LCs 32 flops 222.2 MHz in the first case
76 LCs 32 flops 39.1 MHz in the second case

-- Mike Treseler

Mike Treseler