downto usage in EDK

Hi,

I vaguely seem to remember a provision on the use of downto in EDK. I
tried to dig this out before posting this with no luck---Can't
remember where I came across this though I tried a couple of keyword
searches in random EDK pdf docs. Kinda doubtful about something I've
just written in EDK using many downto's. Would appreciate a hint on
this.

BTW, is Xilinx planning any short-term remedy for this? Keeping track
of minor details is a bit daunting especially when you'r supposed to
do loads of things from electronic circuitry design, DSP algorithmic
development,  to VHDL coding---You know academia!

Regards,
-Manny

Manny <mloulah@hotmail.com> writes:
> I vaguely seem to remember a provision on the use of downto in EDK.

I haven't seen anything documented, but since Microblaze and PPC use
big-endian bit-numbering (bit 0 is MSB), the interfaces are normally
written using 0 to n-1 rather than n-1 downto 0.  This caused me
a fair bit of grief on my first home-grown EDK peripheral module.

If I'm not mistaken, VHDL vector port associations and signal
assignments occur in left-to right order when not explicitly stated
otherwise.  You can attach a 0 to 31 port on an EDK component to a 31
downto 0 port on a non-EDK component, and it will match 0 to 31, 1 to
30, etc.

If you're coding something specifically for use with the EDK, it's
probably best to use the big-endian bit numbering to avoid unnecessary
confusion.

Manny wrote:
> Hi,
> 
> I vaguely seem to remember a provision on the use of downto in EDK. I
> tried to dig this out before posting this with no luck---Can't
> remember where I came across this though I tried a couple of keyword
> searches in random EDK pdf docs. Kinda doubtful about something I've
> just written in EDK using many downto's. Would appreciate a hint on
> this.
> 
> BTW, is Xilinx planning any short-term remedy for this? Keeping track
> of minor details is a bit daunting especially when you'r supposed to
> do loads of things from electronic circuitry design, DSP algorithmic
> development,  to VHDL coding---You know academia!
> 
> Regards,
> -Manny
> 

The ordering in EDK caused me quite a headache too. I tend to use (N
downto 0) for my own HDL. The following function is very handy though:

signal dataA : std_logic_vector(0 to 31);
signal dataB : std_logic_vector(31 to 0);

function reverseVector (a: in std_logic_vector) return std_logic_vector is
  variable result: std_logic_vector(a'reverse_range);
begin
  for i in a'range loop
    result((a'length-1)-i) := a(i);
  end loop;
  return result;
end;

dataB <= reverseVector(dataA);

Hope that helps
Andy

Hi

> The ordering in EDK caused me quite a headache too. 
Me too :)
> I tend to use (N downto 0) for my own HDL. 
Me too
> The following function is very handy though:
> signal dataA : std_logic_vector(0 to 31);
> signal dataB : std_logic_vector(31 to 0);
> ...
I use only B <= A.
In the case of EDK:
signal Bus2IP_ArData_i, Bus2IP_Addr_i, IP_Bus_ArData_i : 
std_logic_vector(31 downto 0);

Bus2IP_ArData_i <= Bus2IP_ArData;
Bus2IP_Addr_i <= Bus2IP_Addr;
IP2Bus_ArData <= IP2Bus_ArData_i;

I do this because Bit31 (for example. Bus2IP_Addr(31)) is the LEAST 
significant Bit in the vector. I map it to Bus2IP_Addr_i(0), which 
sounds more least significant to me. If I would map it to ...(31) by 
reversing the vector, my bitorder would be wrong.
My Custom Peripheral works fine using those only "declaration-inverted" 
signals.