FPGA Central

I got the problem while receiving the value of "count" (i.e. of
integer type with value positive as well as negative) in MICROBLAZE
that was send from custom IP named as encoder module using "User
Logic Software Register" IPIF. Encoder module counts the value of
encoder pulses ranges from -5000 to +5000.

I assigned value of "count" to IP2Bus_Data by converting it to
std_logic_vector type and receive this value in microblaze software
application using variable "Data_receive" of int type. and
"Data_received" was displayed into Hyper Terminal But data received
was not as expecting mainly the negative numbers.....so how this
problem is resolved to get exact data, positive as well as negative.

Can i receive the data in Microblaze application in std_logic_vector
form?? i mean std_logic_vector equivalent form....

OR is there any easier method of transferring negative data ...??

Another problem is...... i found SIGNED(N downto 0) is same as
std_logic_vector except it represents +ve as well as -ve
numbers....But it didn't work in my program...why??

my code written in "user_logic".vhd template is given below.....
------------------------------------------------------------------------------------------------------------------------------
signal cnt: integer range -5000 to 5000:=0;

my_uut1rocess(channel_A) is
begin
if(channel_A 'event and channel_A='1') then
direction<= '1' and channel_B;
end if;
end process;

my_uut2rocess(channel_A) is
begin
if(channel_A 'event and channel_A='1') then
if(direction='0') then
cnt<=cnt+1;
else
cnt<=cnt-1;
end if;
end if;
end process;

IP2Bus_Data(0 to 15) <= (others=>'0');
IP2Bus_Data(16 to 31) <= conv_std_logic_vector(cnt,16);
-----------------------------------------------------------------------------------------------------------------------------
SOFTWARE APPLICATION IN MICROBLAZE

Xint DataRead;

encoder_module_p = (Xuint32 *)XPAR_ENCODER_MODULE_0_BASEADDR;
XASSERT_NONVOID(encoder_module_p != XNULL);
encoder_module = (Xuint32 *)encoder_module_p;



while(1){

DataRead = ENCODER_MODULE_mReadSlaveReg0(encoder_module, 0);
xil_printf("Received data: %d\r\n", DataRead);

}
----------------------------------------------------------------------------------------------------------------------------------------

any suggestion is greatly appreciated!!

On Oct 11, 9:05*am, GrIsH <grishkun...@gmail.com> wrote:
> I got the problem while receiving the value of "count" (i.e. of
> integer type with value positive as well as negative) in MICROBLAZE
> that was send from custom IP *named as encoder module using "User
> Logic Software Register" *IPIF. Encoder module counts the value of
> encoder pulses ranges from -5000 to +5000.
>
> I assigned value of * "count" *to *IP2Bus_Data by converting it to
> std_logic_vector type and receive this value in microblaze software
> application using variable "Data_receive" of int type. and
> "Data_received" was displayed into Hyper Terminal But data received
> was not as expecting mainly the negative numbers.....so how this
> problem is resolved to get exact data, positive as well as negative.
>
> Can i receive the data in Microblaze application in std_logic_vector
> form?? i mean std_logic_vector equivalent form....
>
> OR is there any easier method of transferring negative data ...??
>
> Another problem is...... i found SIGNED(N downto 0) is same as
> std_logic_vector except it represents +ve as well as -ve
> numbers....But it didn't work in my program...why??
>
> my code written in "user_logic".vhd template is given below.....
> ------------------------------------------------------------------------------------------------------------------------------
> signal cnt: * * * * * * * * * * * * * * * * * * integer range -5000 to 5000:=0;
>
> *my_uut1rocess(channel_A) is
> * * begin
> * * * * if(channel_A 'event and channel_A='1') then
> * * * * * * direction<= '1' and channel_B;
> * * * * end if;
> * * end process;
>
> * * my_uut2rocess(channel_A) is
> * * begin
> * * * * if(channel_A 'event and channel_A='1') then
> * * * * * * if(direction='0') then
> * * * * * * * * cnt<=cnt+1;
> * * * * * * else
> * * * * * * * * cnt<=cnt-1;
> * * * * * * end if;
> * * * * end if;
> * * end process;
>
> IP2Bus_Data(0 to 15) *<= (others=>'0');
> IP2Bus_Data(16 to 31) <= conv_std_logic_vector(cnt,16);
> -----------------------------------------------------------------------------------------------------------------------------
> SOFTWARE APPLICATION IN MICROBLAZE
>
> Xint DataRead;
>
> encoder_module_p = (Xuint32 *)XPAR_ENCODER_MODULE_0_BASEADDR;
> XASSERT_NONVOID(encoder_module_p != XNULL);
> encoder_module = (Xuint32 *)encoder_module_p;
>
> * * * * while(1){
>
> * * * * * * * * DataRead = ENCODER_MODULE_mReadSlaveReg0(encoder_module, 0);
> * * * * * * * * xil_printf("Received data: %d\r\n", DataRead);
>
> * * * * }

You only included part of your code, I don't see your library
declarations and the other signal declarations. I guess IP2Bus_Data
is an output maybe?

Your problem likely is in the numbering of your bus. How was it
declared, 31 downto 0 (the most common convention) or 0 to 31 (not so
common)? You are assigning the msb of the integer to bit 16 of your
SLV which is in the middle of the vector. I can see why uBlaze is
confused.

I also recommend that you not use std_logic_arith. This has been
covered many, many times here and elsewhere. There are some sticky
issues with using this package. It is highly recommended to use
ieee.std_logic_1164 and ieee.numeric_std. I won't go into the details
of why this is better, but if you continue to use std_logic_arith
don't say you weren't warned.

Rick

On Oct 12, 9:02*am, rickman <gnu...@gmail.com> wrote:
> On Oct 11, 9:05*am, GrIsH <grishkun...@gmail.com> wrote:
>
>
>
> > I got the problem while receiving the value of "count" (i.e. of
> > integer type with value positive as well as negative) in MICROBLAZE
> > that was send from custom IP *named as encoder module using "User
> > Logic Software Register" *IPIF. Encoder module counts the value of
> > encoder pulses ranges from -5000 to +5000.
>
> > I assigned value of * "count" *to *IP2Bus_Data by converting it to
> > std_logic_vector type and receive this value in microblaze software
> > application using variable "Data_receive" of int type. and
> > "Data_received" was displayed into Hyper Terminal But data received
> > was not as expecting mainly the negative numbers.....so how this
> > problem is resolved to get exact data, positive as well as negative.
>
> > Can i receive the data in Microblaze application in std_logic_vector
> > form?? i mean std_logic_vector equivalent form....
>
> > OR is there any easier method of transferring negative data ...??
>
> > Another problem is...... i found SIGNED(N downto 0) is same as
> > std_logic_vector except it represents +ve as well as -ve
> > numbers....But it didn't work in my program...why??
>
> > my code written in "user_logic".vhd template is given below.....
> > ------------------------------------------------------------------------------------------------------------------------------
> > signal cnt: * * * * * * * * * * * * * * ** * * integer range -5000 to 5000:=0;
>
> > *my_uut1rocess(channel_A) is
> > * * begin
> > * * * * if(channel_A 'event and channel_A='1') then
> > * * * * * * direction<= '1' and channel_B;
> > * * * * end if;
> > * * end process;
>
> > * * my_uut2rocess(channel_A) is
> > * * begin
> > * * * * if(channel_A 'event and channel_A='1') then
> > * * * * * * if(direction='0') then
> > * * * * * * * * cnt<=cnt+1;
> > * * * * * * else
> > * * * * * * * * cnt<=cnt-1;
> > * * * * * * end if;
> > * * * * end if;
> > * * end process;
>
> > IP2Bus_Data(0 to 15) *<= (others=>'0');
> > IP2Bus_Data(16 to 31) <= conv_std_logic_vector(cnt,16);
> > -----------------------------------------------------------------------------------------------------------------------------
> > SOFTWARE APPLICATION IN MICROBLAZE
>
> > Xint DataRead;
>
> > encoder_module_p = (Xuint32 *)XPAR_ENCODER_MODULE_0_BASEADDR;
> > XASSERT_NONVOID(encoder_module_p != XNULL);
> > encoder_module = (Xuint32 *)encoder_module_p;
>
> > * * * * while(1){
>
> > * * * * * * * * DataRead = ENCODER_MODULE_mReadSlaveReg0(encoder_module, 0);
> > * * * * * * * * xil_printf("Received data: %d\r\n", DataRead);
>
> > * * * * }
>
> You only included part of your code, I don't see your library
> declarations and the other signal declarations. *I guess IP2Bus_Data
> is an output maybe?
>
> Your problem likely is in the numbering of your bus. *How was it
> declared, 31 downto 0 (the most common convention) or 0 to 31 (not so
> common)? *You are assigning the msb of the integer to bit 16 of your
> SLV which is in the middle of the vector. *I can see why uBlaze is
> confused.
>
> I also recommend that you not use std_logic_arith. *This has been
> covered many, many times here and elsewhere. *There are some sticky
> issues with using this package. *It is highly recommended to use
> ieee.std_logic_1164 and ieee.numeric_std. *I won't go into the details
> of why this is better, but if you continue to use std_logic_arith
> don't say you weren't warned.
>
> Rick


Here is my complete code:

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;

library proc_common_v2_00_a;
use proc_common_v2_00_a.proc_common_pkg.all;

-- DO NOT EDIT ABOVE THIS LINE --------------------

--USER libraries added here

------------------------------------------------------------------------------
-- Entity section
------------------------------------------------------------------------------
-- Definition of Generics:
-- C_SLV_DWIDTH -- Slave interface data bus width
-- C_NUM_REG -- Number of software accessible
registers
--
-- Definition of Ports:
-- Bus2IP_Clk -- Bus to IP clock
-- Bus2IP_Reset -- Bus to IP reset
-- Bus2IP_Data -- Bus to IP data bus
-- Bus2IP_BE -- Bus to IP byte enables
-- Bus2IP_RdCE -- Bus to IP read chip enable
-- Bus2IP_WrCE -- Bus to IP write chip enable
-- IP2Bus_Data -- IP to Bus data bus
-- IP2Bus_RdAck -- IP to Bus read transfer
acknowledgement
-- IP2Bus_WrAck -- IP to Bus write transfer
acknowledgement
-- IP2Bus_Error -- IP to Bus error response
------------------------------------------------------------------------------

entity user_logic is
generic
(
-- ADD USER GENERICS BELOW THIS LINE ---------------
--USER generics added here
-- ADD USER GENERICS ABOVE THIS LINE ---------------

-- DO NOT EDIT BELOW THIS LINE ---------------------
-- Bus protocol parameters, do not add to or delete
C_SLV_DWIDTH : integer := 32;
C_NUM_REG : integer := 1
-- DO NOT EDIT ABOVE THIS LINE ---------------------
);
port
(
-- ADD USER PORTS BELOW THIS LINE ------------------
channel_A: in std_logic;
channel_B: in std_logic;
-- ADD USER PORTS ABOVE THIS LINE ------------------

-- DO NOT EDIT BELOW THIS LINE ---------------------
-- Bus protocol ports, do not add to or delete
Bus2IP_Clk : in std_logic;
Bus2IP_Reset : in std_logic;
Bus2IP_Data : in std_logic_vector(0 to
C_SLV_DWIDTH-1);
Bus2IP_BE : in std_logic_vector(0 to
C_SLV_DWIDTH/8-1);
Bus2IP_RdCE : in std_logic_vector(0 to
C_NUM_REG-1);
Bus2IP_WrCE : in std_logic_vector(0 to
C_NUM_REG-1);
IP2Bus_Data : out std_logic_vector(0 to
C_SLV_DWIDTH-1);
IP2Bus_RdAck : out std_logic;
IP2Bus_WrAck : out std_logic;
IP2Bus_Error : out std_logic
-- DO NOT EDIT ABOVE THIS LINE ---------------------
);

attribute SIGIS : string;
attribute SIGIS of Bus2IP_Clk : signal is "CLK";
attribute SIGIS of Bus2IP_Reset : signal is "RST";

end entity user_logic;

------------------------------------------------------------------------------
-- Architecture section
------------------------------------------------------------------------------

architecture IMP of user_logic is

--USER signal declarations added here, as needed for user logic

------------------------------------------
-- Signals for user logic slave model s/w accessible register
example
------------------------------------------
signal slv_reg0 : std_logic_vector(0 to
C_SLV_DWIDTH-1);
signal slv_reg_write_sel : std_logic_vector(0 to 0);
signal slv_reg_read_sel : std_logic_vector(0 to 0);
signal slv_ip2bus_data : std_logic_vector(0 to
C_SLV_DWIDTH-1);
signal slv_read_ack : std_logic;
signal slv_write_ack : std_logic;

signal cnt: integer range -1000 to 1000:=0;
signal direction: std_logic;

begin

--USER logic implementation added here

------------------------------------------
-- Example code to read/write user logic slave model s/w accessible
registers
--
-- Note:
-- The example code presented here is to show you one way of reading/
writing
-- software accessible registers implemented in the user logic slave
model.
-- Each bit of the Bus2IP_WrCE/Bus2IP_RdCE signals is configured to
correspond
-- to one software accessible register by the top level template.
For example,
-- if you have four 32 bit software accessible registers in the user
logic,
-- you are basically operating on the following memory mapped
registers:
--
-- Bus2IP_WrCE/Bus2IP_RdCE Memory Mapped Register
-- "1000" C_BASEADDR + 0x0
-- "0100" C_BASEADDR + 0x4
-- "0010" C_BASEADDR + 0x8
-- "0001" C_BASEADDR + 0xC
--
------------------------------------------
slv_reg_write_sel <= Bus2IP_WrCE(0 to 0);
slv_reg_read_sel <= Bus2IP_RdCE(0 to 0);
slv_write_ack <= Bus2IP_WrCE(0);
slv_read_ack <= Bus2IP_RdCE(0);


-- Encoder Module Code
-----------------------------------------------

----------------------------------------------------------------------

my_uut1rocess(channel_A) is
begin
if(channel_A 'event and channel_A='1') then
direction<= '1' and channel_B;
end if;
end process;

my_uut2rocess(channel_A) is
begin
if(channel_A 'event and channel_A='1') then
if(direction='0') then
cnt<=cnt+1;
else
cnt<=cnt-1;
end if;
end if;
end process;


----------------------------------------------------------------------

----------------------------------------------------------------------



-- implement slave model software accessible register(s)
SLAVE_REG_WRITE_PROC : process( Bus2IP_Clk ) is
begin

if Bus2IP_Clk'event and Bus2IP_Clk = '1' then
if Bus2IP_Reset = '1' then
slv_reg0 <= (others => '0');
else
case slv_reg_write_sel is
when "1" =>
for byte_index in 0 to (C_SLV_DWIDTH/8)-1 loop
if ( Bus2IP_BE(byte_index) = '1' ) then
slv_reg0(byte_index*8 to byte_index*8+7) <= Bus2IP_Data
(byte_index*8 to byte_index*8+7);
end if;
end loop;
when others => null;
end case;
end if;
end if;

end process SLAVE_REG_WRITE_PROC;

-- implement slave model software accessible register(s) read mux
SLAVE_REG_READ_PROC : process( slv_reg_read_sel, slv_reg0 ) is
begin

case slv_reg_read_sel is
when "1" => slv_ip2bus_data <= slv_reg0;
when others => slv_ip2bus_data <= (others => '0');
end case;

end process SLAVE_REG_READ_PROC;

------------------------------------------
-- Example code to drive IP to Bus signals
------------------------------------------
--IP2Bus_Data <= slv_ip2bus_data when slv_read_ack = '1' else
--(others => '0');

-- my logic--------------------------------------------------------

-------------------------------------------------------------------
IP2Bus_Data(0 to 15) <= (others=>'0');
IP2Bus_Data(16 to 31) <= conv_std_logic_vector(cnt,16);
-------------------------------------------------------------------
-------------------------------------------------------------------


IP2Bus_WrAck <= slv_write_ack;
IP2Bus_RdAck <= slv_read_ack;
IP2Bus_Error <= '0';

end IMP;

On Oct 12, 1:08 pm, GrIsH <grishkun...@gmail.com> wrote:
> On Oct 12, 9:02 am, rickman <gnu...@gmail.com> wrote:
>
> > On Oct 11, 9:05 am, GrIsH <grishkun...@gmail.com> wrote:
>
> > > I got the problem while receiving the value of "count" (i.e. of
> > > integer type with value positive as well as negative) in MICROBLAZE
> > > that was send from custom IP named as encoder module using "User
> > > Logic Software Register" IPIF. Encoder module counts the value of
> > > encoder pulses ranges from -5000 to +5000.
>
> > > I assigned value of "count" to IP2Bus_Data by converting it to
> > > std_logic_vector type and receive this value in microblaze software
> > > application using variable "Data_receive" of int type. and
> > > "Data_received" was displayed into Hyper Terminal But data received
> > > was not as expecting mainly the negative numbers.....so how this
> > > problem is resolved to get exact data, positive as well as negative.
>
> > > Can i receive the data in Microblaze application in std_logic_vector
> > > form?? i mean std_logic_vector equivalent form....
>
> > > OR is there any easier method of transferring negative data ...??
>
> > > Another problem is...... i found SIGNED(N downto 0) is same as
> > > std_logic_vector except it represents +ve as well as -ve
> > > numbers....But it didn't work in my program...why??
>
> > > my code written in "user_logic".vhd template is given below.....
> > > ------------------------------------------------------------------------------------------------------------------------------
> > > signal cnt: integer range -5000 to 5000:=0;
>
> > > my_uut1rocess(channel_A) is
> > > begin
> > > if(channel_A 'event and channel_A='1') then
> > > direction<= '1' and channel_B;
> > > end if;
> > > end process;
>
> > > my_uut2rocess(channel_A) is
> > > begin
> > > if(channel_A 'event and channel_A='1') then
> > > if(direction='0') then
> > > cnt<=cnt+1;
> > > else
> > > cnt<=cnt-1;
> > > end if;
> > > end if;
> > > end process;
>
> > > IP2Bus_Data(0 to 15) <= (others=>'0');
> > > IP2Bus_Data(16 to 31) <= conv_std_logic_vector(cnt,16);
> > > -----------------------------------------------------------------------------------------------------------------------------
> > > SOFTWARE APPLICATION IN MICROBLAZE
>
> > > Xint DataRead;
>
> > > encoder_module_p = (Xuint32 *)XPAR_ENCODER_MODULE_0_BASEADDR;
> > > XASSERT_NONVOID(encoder_module_p != XNULL);
> > > encoder_module = (Xuint32 *)encoder_module_p;
>
> > > while(1){
>
> > > DataRead = ENCODER_MODULE_mReadSlaveReg0(encoder_module, 0);
> > > xil_printf("Received data: %d\r\n", DataRead);
>
> > > }
>
> > You only included part of your code, I don't see your library
> > declarations and the other signal declarations. I guess IP2Bus_Data
> > is an output maybe?
>
> > Your problem likely is in the numbering of your bus. How was it
> > declared, 31 downto 0 (the most common convention) or 0 to 31 (not so
> > common)? You are assigning the msb of the integer to bit 16 of your
> > SLV which is in the middle of the vector. I can see why uBlaze is
> > confused.
>
> > I also recommend that you not use std_logic_arith. This has been
> > covered many, many times here and elsewhere. There are some sticky
> > issues with using this package. It is highly recommended to use
> > ieee.std_logic_1164 and ieee.numeric_std. I won't go into the details
> > of why this is better, but if you continue to use std_logic_arith
> > don't say you weren't warned.
>
> > Rick
>
> Here is my complete code:
>
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_arith.all;
> use ieee.std_logic_unsigned.all;
>
> library proc_common_v2_00_a;
> use proc_common_v2_00_a.proc_common_pkg.all;
>
> -- DO NOT EDIT ABOVE THIS LINE --------------------
>
> --USER libraries added here
>
> ------------------------------------------------------------------------------
> -- Entity section
> ------------------------------------------------------------------------------
> -- Definition of Generics:
> -- C_SLV_DWIDTH -- Slave interface data bus width
> -- C_NUM_REG -- Number of software accessible
> registers
> --
> -- Definition of Ports:
> -- Bus2IP_Clk -- Bus to IP clock
> -- Bus2IP_Reset -- Bus to IP reset
> -- Bus2IP_Data -- Bus to IP data bus
> -- Bus2IP_BE -- Bus to IP byte enables
> -- Bus2IP_RdCE -- Bus to IP read chip enable
> -- Bus2IP_WrCE -- Bus to IP write chip enable
> -- IP2Bus_Data -- IP to Bus data bus
> -- IP2Bus_RdAck -- IP to Bus read transfer
> acknowledgement
> -- IP2Bus_WrAck -- IP to Bus write transfer
> acknowledgement
> -- IP2Bus_Error -- IP to Bus error response
> ------------------------------------------------------------------------------
>
> entity user_logic is
> generic
> (
> -- ADD USER GENERICS BELOW THIS LINE ---------------
> --USER generics added here
> -- ADD USER GENERICS ABOVE THIS LINE ---------------
>
> -- DO NOT EDIT BELOW THIS LINE ---------------------
> -- Bus protocol parameters, do not add to or delete
> C_SLV_DWIDTH : integer := 32;
> C_NUM_REG : integer := 1
> -- DO NOT EDIT ABOVE THIS LINE ---------------------
> );
> port
> (
> -- ADD USER PORTS BELOW THIS LINE ------------------
> channel_A: in std_logic;
> channel_B: in std_logic;
> -- ADD USER PORTS ABOVE THIS LINE ------------------
>
> -- DO NOT EDIT BELOW THIS LINE ---------------------
> -- Bus protocol ports, do not add to or delete
> Bus2IP_Clk : in std_logic;
> Bus2IP_Reset : in std_logic;
> Bus2IP_Data : in std_logic_vector(0 to
> C_SLV_DWIDTH-1);
> Bus2IP_BE : in std_logic_vector(0 to
> C_SLV_DWIDTH/8-1);
> Bus2IP_RdCE : in std_logic_vector(0 to
> C_NUM_REG-1);
> Bus2IP_WrCE : in std_logic_vector(0 to
> C_NUM_REG-1);
> IP2Bus_Data : out std_logic_vector(0 to
> C_SLV_DWIDTH-1);
> IP2Bus_RdAck : out std_logic;
> IP2Bus_WrAck : out std_logic;
> IP2Bus_Error : out std_logic
> -- DO NOT EDIT ABOVE THIS LINE ---------------------
> );
>
> attribute SIGIS : string;
> attribute SIGIS of Bus2IP_Clk : signal is "CLK";
> attribute SIGIS of Bus2IP_Reset : signal is "RST";
>
> end entity user_logic;
>
> ------------------------------------------------------------------------------
> -- Architecture section
> ------------------------------------------------------------------------------
>
> architecture IMP of user_logic is
>
> --USER signal declarations added here, as needed for user logic
>
> ------------------------------------------
> -- Signals for user logic slave model s/w accessible register
> example
> ------------------------------------------
> signal slv_reg0 : std_logic_vector(0 to
> C_SLV_DWIDTH-1);
> signal slv_reg_write_sel : std_logic_vector(0 to 0);
> signal slv_reg_read_sel : std_logic_vector(0 to 0);
> signal slv_ip2bus_data : std_logic_vector(0 to
> C_SLV_DWIDTH-1);
> signal slv_read_ack : std_logic;
> signal slv_write_ack : std_logic;
>
> signal cnt: integer range -1000 to 1000:=0;
> signal direction: std_logic;
>
> begin
>
> --USER logic implementation added here
>
> ------------------------------------------
> -- Example code to read/write user logic slave model s/w accessible
> registers
> --
> -- Note:
> -- The example code presented here is to show you one way of reading/
> writing
> -- software accessible registers implemented in the user logic slave
> model.
> -- Each bit of the Bus2IP_WrCE/Bus2IP_RdCE signals is configured to
> correspond
> -- to one software accessible register by the top level template.
> For example,
> -- if you have four 32 bit software accessible registers in the user
> logic,
> -- you are basically operating on the following memory mapped
> registers:
> --
> -- Bus2IP_WrCE/Bus2IP_RdCE Memory Mapped Register
> -- "1000" C_BASEADDR + 0x0
> -- "0100" C_BASEADDR + 0x4
> -- "0010" C_BASEADDR + 0x8
> -- "0001" C_BASEADDR + 0xC
> --
> ------------------------------------------
> slv_reg_write_sel <= Bus2IP_WrCE(0 to 0);
> slv_reg_read_sel <= Bus2IP_RdCE(0 to 0);
> slv_write_ack <= Bus2IP_WrCE(0);
> slv_read_ack <= Bus2IP_RdCE(0);
>
> -- Encoder Module Code
> -----------------------------------------------
>
> ----------------------------------------------------------------------
>
> my_uut1rocess(channel_A) is
> begin
> if(channel_A 'event and channel_A='1') then
> direction<= '1' and channel_B;
> end if;
> end process;
>
> my_uut2rocess(channel_A) is
> begin
> if(channel_A 'event and channel_A='1') then
> if(direction='0') then
> cnt<=cnt+1;
> else
> cnt<=cnt-1;
> end if;
> end if;
> end process;
>
> ----------------------------------------------------------------------
>
> ----------------------------------------------------------------------
>
> -- implement slave model software accessible register(s)
> SLAVE_REG_WRITE_PROC : process( Bus2IP_Clk ) is
> begin
>
> if Bus2IP_Clk'event and Bus2IP_Clk = '1' then
> if Bus2IP_Reset = '1' then
> slv_reg0 <= (others => '0');
> else
> case slv_reg_write_sel is
> when "1" =>
> for byte_index in 0 to (C_SLV_DWIDTH/8)-1 loop
> if ( Bus2IP_BE(byte_index) = '1' ) then
> slv_reg0(byte_index*8 to byte_index*8+7) <= Bus2IP_Data
> (byte_index*8 to byte_index*8+7);
> end if;
> end loop;
> when others => null;
> end case;
> end if;
> end if;
>
> end process SLAVE_REG_WRITE_PROC;
>
> -- implement slave model software accessible register(s) read mux
> SLAVE_REG_READ_PROC : process( slv_reg_read_sel, slv_reg0 ) is
> begin
>
> case slv_reg_read_sel is
> when "1" => slv_ip2bus_data <= slv_reg0;
> when others => slv_ip2bus_data <= (others => '0');
> end case;
>
> end process SLAVE_REG_READ_PROC;
>
> ------------------------------------------
> -- Example code to drive IP to Bus signals
> ------------------------------------------
> --IP2Bus_Data <= slv_ip2bus_data when slv_read_ack = '1' else
> --(others => '0');
>
> -- my logic--------------------------------------------------------
>
> -------------------------------------------------------------------
> IP2Bus_Data(0 to 15) <= (others=>'0');
> IP2Bus_Data(16 to 31) <= conv_std_logic_vector(cnt,16);
> -------------------------------------------------------------------
> -------------------------------------------------------------------
>
> IP2Bus_WrAck <= slv_write_ack;
> IP2Bus_RdAck <= slv_read_ack;
> IP2Bus_Error <= '0';
>
> end IMP;

It looks like IP2Bus_Data is declared 0 to N rather than N downto 0.
This is the signal that goes to the mBlaze, right? How does uBlaze
declare this? Have you checked this in simulation? You should be
able to see what is happening there. But like I said, I believe you
are doing this wrong. You are putting the sign bit in the middle of
the 32 bit word. Is that what you intended? Is uBlaze reading just a
16 bit quanity or do you need to sign extend the value?

What values *are* being seen in the terminal display? Are they all
positive? Do you see *any* negative numbers from this data path?

I also suggest strongly that you replace

use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;

with

use ieee.numeric_std.all;

The conversion functions have different names, but they are easy to
remember. to_integer() works for the types defined in numeric_std
(signed and unsigned). to_signed() and to_unsigned() work for
integer. To convert between integer and SLV you need to use
to_integer, to_signed or to_unsigned to convert between integer and
either signed or unsigned, then you can use "implicit type conversion"
to convert between signed/unsigned and SLV. e.g. std_logic_vector
(signed_signal)

under numeric_std signed, unsigned and SLV are "closely related types"
which do not need a function for conversion. They will be converted
just by connecting the corresponding "wires" (elements of the array)
between the two types. Since closely related types use the same
element types, this is defined without requiring any "conversion"
between them.

The reason that you can't convert directly between integer and SLV is
because that would require a specification of the format somehow. By
converting to unsigned or signed in the middle, the format is
specified clearly.

Rick

On Oct 12, 1:04*pm, rickman <gnu...@gmail.com> wrote:
> On Oct 12, 1:08 pm, GrIsH <grishkun...@gmail.com> wrote:
>
> > On Oct 12, 9:02 am, rickman <gnu...@gmail.com> wrote:
>
> > > On Oct 11, 9:05 am, GrIsH <grishkun...@gmail.com> wrote:
>
> > > > I got the problem while receiving the value of "count" (i.e. of
> > > > integer type with value positive as well as negative) in MICROBLAZE
> > > > that was send from custom IP *named as encoder module using "User
> > > > Logic Software Register" *IPIF. Encoder module counts the value of
> > > > encoder pulses ranges from -5000 to +5000.
>
> > > > I assigned value of * "count" *to *IP2Bus_Data by converting it to
> > > > std_logic_vector type and receive this value in microblaze software
> > > > application using variable "Data_receive" of int type. and
> > > > "Data_received" was displayed into Hyper Terminal But data received
> > > > was not as expecting mainly the negative numbers.....so how this
> > > > problem is resolved to get exact data, positive as well as negative..
>
> > > > Can i receive the data in Microblaze application in std_logic_vector
> > > > form?? i mean std_logic_vector equivalent form....
>
> > > > OR is there any easier method of transferring negative data ...??
>
> > > > Another problem is...... i found SIGNED(N downto 0) is same as
> > > > std_logic_vector except it represents +ve as well as -ve
> > > > numbers....But it didn't work in my program...why??
>
> > > > my code written in "user_logic".vhd template is given below.....
> > > > ------------------------------------------------------------------------------------------------------------------------------
> > > > signal cnt: * * * * * * * * * * * * * ** * * * integer range -5000 to 5000:=0;
>
> > > > *my_uut1rocess(channel_A) is
> > > > * * begin
> > > > * * * * if(channel_A 'event and channel_A='1') then
> > > > * * * * * * direction<= '1' and channel_B;
> > > > * * * * end if;
> > > > * * end process;
>
> > > > * * my_uut2rocess(channel_A) is
> > > > * * begin
> > > > * * * * if(channel_A 'event and channel_A='1') then
> > > > * * * * * * if(direction='0') then
> > > > * * * * * * * * cnt<=cnt+1;
> > > > * * * * * * else
> > > > * * * * * * * * cnt<=cnt-1;
> > > > * * * * * * end if;
> > > > * * * * end if;
> > > > * * end process;
>
> > > > IP2Bus_Data(0 to 15) *<= (others=>'0');
> > > > IP2Bus_Data(16 to 31) <= conv_std_logic_vector(cnt,16);
> > > > -----------------------------------------------------------------------------------------------------------------------------
> > > > SOFTWARE APPLICATION IN MICROBLAZE
>
> > > > Xint DataRead;
>
> > > > encoder_module_p = (Xuint32 *)XPAR_ENCODER_MODULE_0_BASEADDR;
> > > > XASSERT_NONVOID(encoder_module_p != XNULL);
> > > > encoder_module = (Xuint32 *)encoder_module_p;
>
> > > > * * * * while(1){
>
> > > > * * * * * * * * DataRead = ENCODER_MODULE_mReadSlaveReg0(encoder_module, 0);
> > > > * * * * * * * * xil_printf("Received data: %d\r\n",DataRead);
>
> > > > * * * * }
>
> > > You only included part of your code, I don't see your library
> > > declarations and the other signal declarations. *I guess IP2Bus_Data
> > > is an output maybe?
>
> > > Your problem likely is in the numbering of your bus. *How was it
> > > declared, 31 downto 0 (the most common convention) or 0 to 31 (not so
> > > common)? *You are assigning the msb of the integer to bit 16 of your
> > > SLV which is in the middle of the vector. *I can see why uBlaze is
> > > confused.
>
> > > I also recommend that you not use std_logic_arith. *This has been
> > > covered many, many times here and elsewhere. *There are some sticky
> > > issues with using this package. *It is highly recommended to use
> > > ieee.std_logic_1164 and ieee.numeric_std. *I won't go into the details
> > > of why this is better, but if you continue to use std_logic_arith
> > > don't say you weren't warned.
>
> > > Rick
>
> > Here is my complete code:
>
> > library ieee;
> > use ieee.std_logic_1164.all;
> > use ieee.std_logic_arith.all;
> > use ieee.std_logic_unsigned.all;
>
> > library proc_common_v2_00_a;
> > use proc_common_v2_00_a.proc_common_pkg.all;
>
> > -- DO NOT EDIT ABOVE THIS LINE --------------------
>
> > --USER libraries added here
>
> > ------------------------------------------------------------------------------
> > -- Entity section
> > ------------------------------------------------------------------------------
> > -- Definition of Generics:
> > -- * C_SLV_DWIDTH * * * * * * * * -- Slave interface data bus width
> > -- * C_NUM_REG * * * * * * * * * *-- Number of software accessible
> > registers
> > --
> > -- Definition of Ports:
> > -- * Bus2IP_Clk * * * * * * * * * -- Bus to IP clock
> > -- * Bus2IP_Reset * * * * * * * * -- Bus to IP reset
> > -- * Bus2IP_Data * * * * * * * * *-- Bus to IP databus
> > -- * Bus2IP_BE * * * * * * * * * *-- Bus to IP byte enables
> > -- * Bus2IP_RdCE * * * * * * * * *-- Bus to IP readchip enable
> > -- * Bus2IP_WrCE * * * * * * * * *-- Bus to IP write chip enable
> > -- * IP2Bus_Data * * * * * * * * *-- IP to Bus databus
> > -- * IP2Bus_RdAck * * * * * * * * -- IP to Bus read transfer
> > acknowledgement
> > -- * IP2Bus_WrAck * * * * * * * * -- IP to Bus write transfer
> > acknowledgement
> > -- * IP2Bus_Error * * * * * * * * -- IP to Bus error response
> > ------------------------------------------------------------------------------
>
> > entity user_logic is
> > * generic
> > * (
> > * * -- ADD USER GENERICS BELOW THIS LINE ---------------
> > * * --USER generics added here
> > * * -- ADD USER GENERICS ABOVE THIS LINE ---------------
>
> > * * -- DO NOT EDIT BELOW THIS LINE ---------------------
> > * * -- Bus protocol parameters, do not add to or delete
> > * * C_SLV_DWIDTH * * * * * * * * * : integer * * * * * * *:= 32;
> > * * C_NUM_REG * * * * * * * * * * *: integer * * * * * * *:= 1
> > * * -- DO NOT EDIT ABOVE THIS LINE ---------------------
> > * );
> > * port
> > * (
> > * * -- ADD USER PORTS BELOW THIS LINE ------------------
> > * * channel_A: * * * * *in std_logic;
> > * * * * *channel_B: * * * * * * in std_logic;
> > * * -- ADD USER PORTS ABOVE THIS LINE ------------------
>
> > * * -- DO NOT EDIT BELOW THIS LINE ---------------------
> > * * -- Bus protocol ports, do not add to or delete
> > * * Bus2IP_Clk * * * * * * * * * * : in *std_logic;
> > * * Bus2IP_Reset * * * * * * * * * : in *std_logic;
> > * * Bus2IP_Data * * * * * * * * * *: in *std_logic_vector(0 to
> > C_SLV_DWIDTH-1);
> > * * Bus2IP_BE * * * * * * * * * * *: in *std_logic_vector(0 to
> > C_SLV_DWIDTH/8-1);
> > * * Bus2IP_RdCE * * * * * * * * * *: in *std_logic_vector(0 to
> > C_NUM_REG-1);
> > * * Bus2IP_WrCE * * * * * * * * * *: in *std_logic_vector(0 to
> > C_NUM_REG-1);
> > * * IP2Bus_Data * * * * * * * * * *: out std_logic_vector(0 to
> > C_SLV_DWIDTH-1);
> > * * IP2Bus_RdAck * * * * * * * * * : out std_logic;
> > * * IP2Bus_WrAck * * * * * * * * * : out std_logic;
> > * * IP2Bus_Error * * * * * * * * * : out std_logic
> > * * -- DO NOT EDIT ABOVE THIS LINE ---------------------
> > * );
>
> > * attribute SIGIS : string;
> > * attribute SIGIS of Bus2IP_Clk * *: signal is "CLK";
> > * attribute SIGIS of Bus2IP_Reset *: signal is "RST";
>
> > end entity user_logic;
>
> > ------------------------------------------------------------------------------
> > -- Architecture section
> > ------------------------------------------------------------------------------
>
> > architecture IMP of user_logic is
>
> > * --USER signal declarations added here, as needed for user logic
>
> > * ------------------------------------------
> > * -- Signals for user logic slave model s/w accessible register
> > example
> > * ------------------------------------------
> > * signal slv_reg0 * * * * * * * * * * * : std_logic_vector(0 to
> > C_SLV_DWIDTH-1);
> > * signal slv_reg_write_sel * * * * * * *: std_logic_vector(0 to 0);
> > * signal slv_reg_read_sel * * * * * * * : std_logic_vector(0 to 0);
> > * signal slv_ip2bus_data * * * * * * * *: std_logic_vector(0 to
> > C_SLV_DWIDTH-1);
> > * signal slv_read_ack * * * * * * * * * : std_logic;
> > * signal slv_write_ack * * * * * * * * *: std_logic;
>
> > * signal cnt: * * * * * * * * * * * * * ** * * integer range -1000 to 1000:=0;
> > * signal direction: * std_logic;
>
> > begin
>
> > * --USER logic implementation added here
>
> > * ------------------------------------------
> > * -- Example code to read/write user logic slave model s/w accessible
> > registers
> > * --
> > * -- Note:
> > * -- The example code presented here is to show you one way of reading/
> > writing
> > * -- software accessible registers implemented in the user logic slave
> > model.
> > * -- Each bit of the Bus2IP_WrCE/Bus2IP_RdCE signals is configured to
> > correspond
> > * -- to one software accessible register by the top level template.
> > For example,
> > * -- if you have four 32 bit software accessible registers in the user
> > logic,
> > * -- you are basically operating on the following memory mapped
> > registers:
> > * --
> > * -- * *Bus2IP_WrCE/Bus2IP_RdCE * Memory Mapped Register
> > * -- * * * * * * * * * * "1000" * C_BASEADDR + 0x0
> > * -- * * * * * * * * * * "0100" * C_BASEADDR + 0x4
> > * -- * * * * * * * * * * "0010" * C_BASEADDR + 0x8
> > * -- * * * * * * * * * * "0001" * C_BASEADDR + 0xC
> > * --
> > * ------------------------------------------
> > * slv_reg_write_sel <= Bus2IP_WrCE(0 to 0);
> > * slv_reg_read_sel *<= Bus2IP_RdCE(0 to 0);
> > * slv_write_ack * * <= Bus2IP_WrCE(0);
> > * slv_read_ack * * *<= Bus2IP_RdCE(0);
>
> > * -- Encoder Module Code
> > -----------------------------------------------
>
> > ----------------------------------------------------------------------
>
> > * * * * *my_uut1rocess(channel_A) is
> > * * begin
> > * * * * if(channel_A 'event and channel_A='1') then
> > * * * * * * direction<= '1' and channel_B;
> > * * * * end if;
> > * * end process;
>
> > * * my_uut2rocess(channel_A) is
> > * * begin
> > * * * * if(channel_A 'event and channel_A='1') then
> > * * * * * * if(direction='0') then
> > * * * * * * * * cnt<=cnt+1;
> > * * * * * * else
> > * * * * * * * * cnt<=cnt-1;
> > * * * * * * end if;
> > * * * * end if;
> > * * end process;
>
> > ----------------------------------------------------------------------
>
> > ----------------------------------------------------------------------
>
> > * -- implement slave model software accessible register(s)
> > * SLAVE_REG_WRITE_PROC : process( Bus2IP_Clk ) is
> > * begin
>
> > * * if Bus2IP_Clk'event and Bus2IP_Clk = '1' then
> > * * * if Bus2IP_Reset = '1' then
> > * * * * slv_reg0 <= (others => '0');
> > * * * else
> > * * * * case slv_reg_write_sel is
> > * * * * * when "1" =>
> > * * * * * * for byte_index in 0 to (C_SLV_DWIDTH/8)-1 loop
> > * * * * * * * if ( Bus2IP_BE(byte_index) = '1' ) then
> > * * * * * * * * slv_reg0(byte_index*8 to byte_index*8+7) <= Bus2IP_Data
> > (byte_index*8 to byte_index*8+7);
> > * * * * * * * end if;
> > * * * * * * end loop;
> > * * * * * when others => null;
> > * * * * end case;
> > * * * end if;
> > * * end if;
>
> > * end process SLAVE_REG_WRITE_PROC;
>
> > * -- implement slave model software accessible register(s) read mux
> > * SLAVE_REG_READ_PROC : process( slv_reg_read_sel, slv_reg0 ) is
> > * begin
>
> > * * case slv_reg_read_sel is
> > * * * when "1" => slv_ip2bus_data <= slv_reg0;
> > * * * when others => slv_ip2bus_data <= (others => '0');
> > * * end case;
>
> > * end process SLAVE_REG_READ_PROC;
>
> > * ------------------------------------------
> > * -- Example code to drive IP to Bus signals
> > * ------------------------------------------
> > * --IP2Bus_Data *<= slv_ip2bus_data when slv_read_ack = '1' else
> > * * * * * * * * * --(others => '0');
>
> > * -- my logic--------------------------------------------------------
>
> > -------------------------------------------------------------------
> > * IP2Bus_Data(0 to 15) *<= (others=>'0');
> > * IP2Bus_Data(16 to 31) <= conv_std_logic_vector(cnt,16);
> > * -------------------------------------------------------------------
> > * -------------------------------------------------------------------
>
> > * IP2Bus_WrAck <= slv_write_ack;
> > * IP2Bus_RdAck <= slv_read_ack;
> > * IP2Bus_Error <= '0';
>
> > end IMP;
>
> It looks like IP2Bus_Data is declared 0 to N rather than N downto 0.
> This is the signal that goes to the mBlaze, right? *How does uBlaze
> declare this? *Have you checked this in simulation? *You should be
> able to see what is happening there. * But like I said, I believe you
> are doing this wrong. *You are putting the sign bit in the middle of
> the 32 bit word. *Is that what you intended? *Is uBlaze reading just a
> 16 bit quanity or do you need to sign extend the value?

As you mentioned above, IP2Bus_Data should be declare N downto 0
rather than 0 to N.....I tried this but got the error message
IP2Bus_Data type can not be declared as DOWNTO .......i didn't have
any simulation for this till now and i just check the received number
in hyperterminal.....

This time i hav used 32 bit instead of 16 bit format(i.e.IP2Bus_Data(0
to 31)<=conv_std_logic_vector(cnt,32)) .........
>
> What values *are* being seen in the terminal display? *Are they all
> positive? *Do you see *any* negative numbers from this data path?

it shows positive as well as negative numbers but in random
order....

>
> I also suggest strongly that you replace
>
> use ieee.std_logic_arith.all;
> use ieee.std_logic_unsigned.all;
>
> with
>
> use ieee.numeric_std.all;
>
> The conversion functions have different names, but they are easy to
> remember. *to_integer() works for the types defined in numeric_std
> (signed and unsigned). *to_signed() and to_unsigned() work for
> integer. *To convert between integer and SLV you need to use
> to_integer, to_signed or to_unsigned to convert between integer and
> either signed or unsigned, then you can use "implicit type conversion"
> to convert between signed/unsigned and SLV. *e.g. std_logic_vector
> (signed_signal)
>
> under numeric_std signed, unsigned and SLV are "closely related types"
> which do not need a function for conversion. *They will be converted
> just by connecting the corresponding "wires" (elements of the array)
> between the two types. *Since closely related types use the same
> element types, this is defined without requiring any "conversion"
> between them.
>
> The reason that you can't convert directly between integer and SLV is
> because that would require a specification of the format somehow. *By
> converting to unsigned or signed in the middle, the format is
> specified clearly.
>

I tried lots of data types and the conversion function but didn't
get the result what i want......
So iam going to put my problem straight forward to you.......your any
idea will be gr8ly appreciated....

Problem:
1. i need to count the pulses from quadrature encoder , value of count
can be +ve as well as -ve depending upon direction of rotation of
encoder...
2.This value is to be send to uBlaze....
3.I have a code for counting the encoder pulses that is included in
the "user_logic"....
4.I have used "user software register" method of transferring data
from my custom IP to uBlaze..
5.In phase of transferring the value of count from IP to uBlaze, the
value of count must be mapped to IP2Bus_Data in SLV format data
type....
6.Here i had defined "count " that counts value of pulses as integer
and it should be converted SLV while transferring...
7.But this method didn't work as i expected while receiving data in
uBlaze.....
So...Plz suggest me in....

what should be the data type of "count" that support +ve as well -ve
numbers and supports operation count<=count+1/-1
??
and how -ve values of count are represented in SLV format??



> Rick

On Oct 13, 1:06*am, GrIsH <grishkun...@gmail.com> wrote:
>
> * *I tried lots of data types and the conversion function but didn't
> get the result what i want......
> So iam going to put my problem straight forward to you.......your any
> idea will be gr8ly appreciated....
>
> Problem:
> 1. i need to count the pulses from quadrature encoder , value of count
> can be +ve as well as -ve depending upon direction of rotation of
> encoder...
> 2.This value is to be send to uBlaze....
> 3.I have a code for counting the encoder pulses that is included in
> the "user_logic"....
> 4.I have used "user software register" method of transferring data
> from my custom IP to uBlaze..
> 5.In phase of transferring the value of count from IP to uBlaze, the
> value of count must be mapped to IP2Bus_Data in SLV format data
> type....
> 6.Here i had defined "count " that counts value of pulses as integer
> and it should be converted SLV while transferring...
> 7.But this method didn't work as i expected while receiving data in
> uBlaze.....
> So...Plz suggest me in....
>
> what should be the data type of "count" that support +ve as well -ve
> numbers and supports operation count<=count+1/-1
> ??
> and how -ve values of count are represented in SLV format??

I don't know that your problem is one of converting data types. You
clearly are placing the 16 bit data in an odd location on a 32 bit bus
and you have not told me that you are certain that this is correct. I
have not worked with the uBlaze, so I'm not familiar with its data bus
numbering. Is it 0 to N or N downto 0?

Have you simulated your design? Before putting a design into the
chip, you should always simulate it first to get your logic right.
Then you can load it into the chip and see if it works with the real
hardware.

If you don't answer my questions and follow my advice, I can't help
you.

To answer your last question, the SLV signal type does not know
anything about numbers. It is just an array, or a bus, of std_logic
signals. There is no intended interpretation of this bus as a
number. That is why the signed and unsigned types were developed.
They have an explicit representation of signed and unsigned numbers
respectively. When you talk about "converting" a signed value to an
SLV, there really is no conversion. It is more like just connecting
the wires. So the SLV ends up receiving the exact same set of 1s and
0s that were in the signed signal, according to the way that they
connected.

I have never worked with SLV in the 0 to N direction. To be honest, I
don't remember the details of how assignments are made between buses
using different directions of indexes. I wouldn't expect any
surprises, but then I have no experience with them. Is there a reason
that you are using 0 to N numbering instead of N downto 0 on your SLV
arrays? This may not be a problem, but if you are stuck, why use this
uncommon convention?

But before changing anything you need to simulate your design. That
means you will need a testbench which can be automatically generated
by many VHDL tools. Then edit the resulting testbench file to add
stimulus to your inputs and you will be able to observe any signal in
the design in the waveform window. That will let you see each and
every change of data in the path from the counter to the uBlaze CPU.

Rick

On Oct 14, 11:35*am, rickman <gnu...@gmail.com> wrote:
> On Oct 13, 1:06*am, GrIsH <grishkun...@gmail.com> wrote:
>
>
>
>
>
> > * *I tried lots of data types and the conversion function but didn't
> > get the result what i want......
> > So iam going to put my problem straight forward to you.......your any
> > idea will be gr8ly appreciated....
>
> > Problem:
> > 1. i need to count the pulses from quadrature encoder , value of count
> > can be +ve as well as -ve depending upon direction of rotation of
> > encoder...
> > 2.This value is to be send to uBlaze....
> > 3.I have a code for counting the encoder pulses that is included in
> > the "user_logic"....
> > 4.I have used "user software register" method of transferring data
> > from my custom IP to uBlaze..
> > 5.In phase of transferring the value of count from IP to uBlaze, the
> > value of count must be mapped to IP2Bus_Data in SLV format data
> > type....
> > 6.Here i had defined "count " that counts value of pulses as integer
> > and it should be converted SLV while transferring...
> > 7.But this method didn't work as i expected while receiving data in
> > uBlaze.....
> > So...Plz suggest me in....
>
> > what should be the data type of "count" that support +ve as well -ve
> > numbers and supports operation count<=count+1/-1
> > ??
> > and how -ve values of count are represented in SLV format??
>
> I don't know that your problem is one of converting data types. *You
> clearly are placing the 16 bit data in an odd location on a 32 bit bus
> and you have not told me that you are certain that this is correct. *I
> have not worked with the uBlaze, so I'm not familiar with its data bus
> numbering. *Is it 0 to N or N downto 0?
>
> Have you simulated your design? *Before putting a design into the
> chip, you should always simulate it first to get your logic right.
> Then you can load it into the chip and see if it works with the real
> hardware.
>
> If you don't answer my questions and follow my advice, I can't help
> you.

iam trying to simulate my design and lets see what will be the
result...
>
> To answer your last question, the SLV signal type does not know
> anything about numbers. *It is just an array, or a bus, of std_logic
> signals. *There is no intended interpretation of this bus as a
> number. *That is why the signed and unsigned types were developed.
> They have an explicit representation of signed and unsigned numbers
> respectively. *When you talk about "converting" a signed value to an
> SLV, there really is no conversion. *It is more like just connecting
> the wires. *So the SLV ends up receiving the exact same set of 1s and
> 0s that were in the signed signal, according to the way that they
> connected.
>
> I have never worked with SLV in the 0 to N direction. *To be honest, I
> don't remember the details of how assignments are made between buses
> using different directions of indexes. *I wouldn't expect any
> surprises, but then I have no experience with them. *Is there a reason
> that you are using 0 to N numbering instead of N downto 0 on your SLV
> arrays? *This may not be a problem, but if you are stuck, why use this
> uncommon convention?

for IP2Bus_Data we are not allowed to make this convention of N
downto 0 that's why i didn't use this convention.

>
> But before changing anything you need to simulate your design. *That
> means you will need a testbench which can be automatically generated
> by many VHDL tools. *Then edit the resulting testbench file to add
> stimulus to your inputs and you will be able to observe any signal in
> the design in the waveform window. *That will let you see each and
> every change of data in the path from the counter to the uBlaze CPU.
>
> Rick

On Oct 15, 12:51*am, GrIsH <grishkun...@gmail.com> wrote:
> On Oct 14, 11:35*am, rickman <gnu...@gmail.com> wrote:
>
> > I have never worked with SLV in the 0 to N direction. *To be honest, I
> > don't remember the details of how assignments are made between buses
> > using different directions of indexes. *I wouldn't expect any
> > surprises, but then I have no experience with them. *Is there a reason
> > that you are using 0 to N numbering instead of N downto 0 on your SLV
> > arrays? *This may not be a problem, but if you are stuck, why use this
> > uncommon convention?
>
> * * for IP2Bus_Data we are not allowed to make this convention of N
> downto 0 that's why i didn't use this convention.

Ok, it shouldn't matter really, as long as you use it correctly. Can
you explain what this bus is and why it is 0 to 31? Is this a port on
the uBlaze? Where exactly does this restriction come from. Why do
you assign your counter result to bits 16 to 31?

I don't know how the uBlaze reads memory, it's possible that it can
read the low 16 bits of the bus as a 16 bit quantity... *if you are
using the right instruction* to to read a 16 bit quantity, not 16 bits
of a 32 bit quantity. If you are coding in C, you are relying on the
compiler to generate the correct code. The easy way to fix this
problem in hardware is to assign the upper 16 bits of the bus the
value of the sign bit of your result instead of always using zeros.

Of course, all of this assumes that bit 31 is the lsb. Do you know
that for sure? How do you connect the IP2Bus_Data to the uBlaze data
bus? That is what really matters.

Rick

On Oct 15, 8:14*am, rickman <gnu...@gmail.com> wrote:
> On Oct 15, 12:51*am, GrIsH <grishkun...@gmail.com> wrote:
>
> > On Oct 14, 11:35*am, rickman <gnu...@gmail.com> wrote:
>
> > > I have never worked with SLV in the 0 to N direction. *To be honest, I
> > > don't remember the details of how assignments are made between buses
> > > using different directions of indexes. *I wouldn't expect any
> > > surprises, but then I have no experience with them. *Is there a reason
> > > that you are using 0 to N numbering instead of N downto 0 on your SLV
> > > arrays? *This may not be a problem, but if you are stuck, why use this
> > > uncommon convention?
>
> > * * for IP2Bus_Data we are not allowed to make this convention of N
> > downto 0 that's why i didn't use this convention.
>
> Ok, it shouldn't matter really, as long as you use it correctly. *Can
> you explain what this bus is and why it is 0 to 31? *Is this a port on
> the uBlaze? *Where exactly does this restriction come from. *Why do
> you assign your counter result to bits 16 to 31?

MicroBlaze is big endian. Bits 16 to 31 are the two least significant
bytes in a 32-bit word (bit 31 is the right-most bit).

-a

On Oct 14, 9:51*pm, GrIsH <grishkun...@gmail.com> wrote:
> On Oct 14, 11:35*am, rickman <gnu...@gmail.com> wrote:
> > I have never worked with SLV in the 0 to N direction. *To be honest, I
> > don't remember the details of how assignments are made between buses
> > using different directions of indexes. *I wouldn't expect any
> > surprises, but then I have no experience with them. *Is there a reason
> > that you are using 0 to N numbering instead of N downto 0 on your SLV
> > arrays? *This may not be a problem, but if you are stuck, why use this
> > uncommon convention?
>
> * * for IP2Bus_Data we are not allowed to make this convention of N
> downto 0 that's why i didn't use this convention.

You can freely assign little-endian (foo downto bar) vectors to big-
endian vectors (bar to foo). You just have to remember that the bit
lanes are always in the same order:

foo(16 downto 0) <= bar(0 to 16);

will put the least-significant bit (right-most bit) in bar (bit 16)
into foo(0), and so forth.

The only time you will have issues is when you use a loop to iterate
over all bits in a vector and you don't pay attention to this (you
don't want to assign bar(0) to foo(0), unless that's what you want to
do!).

-a

On Oct 15, 1:10*pm, Andy Peters <goo...@latke.net> wrote:
> On Oct 15, 8:14*am, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Oct 15, 12:51*am, GrIsH <grishkun...@gmail.com> wrote:
>
> > > On Oct 14, 11:35*am, rickman <gnu...@gmail.com> wrote:
>
> > > > I have never worked with SLV in the 0 to N direction. *To be honest, I
> > > > don't remember the details of how assignments are made between buses
> > > > using different directions of indexes. *I wouldn't expect any
> > > > surprises, but then I have no experience with them. *Is there a reason
> > > > that you are using 0 to N numbering instead of N downto 0 on your SLV
> > > > arrays? *This may not be a problem, but if you are stuck, why usethis
> > > > uncommon convention?
>
> > > * * for IP2Bus_Data we are not allowed to make this convention ofN
> > > downto 0 that's why i didn't use this convention.
>
> > Ok, it shouldn't matter really, as long as you use it correctly. *Can
> > you explain what this bus is and why it is 0 to 31? *Is this a port on
> > the uBlaze? *Where exactly does this restriction come from. *Why do
> > you assign your counter result to bits 16 to 31?
>
> MicroBlaze is big endian. Bits 16 to 31 are the two least significant
> bytes in a 32-bit word (bit 31 is the right-most bit).
>
> -a

I wonder why they do that. I have only seen bit zero as the most
significant bit in a handful of designs and I expect the first was
done for fairly obscure reasons and the rest were done to be
compatible. Did the uBlaze need to be compatible with something in
this regard?

Rick

rickman <[email protected]> wrote:
(snip)

> I wonder why they do that. I have only seen bit zero as the most
> significant bit in a handful of designs and I expect the first was
> done for fairly obscure reasons and the rest were done to be
> compatible. Did the uBlaze need to be compatible with something in
> this regard?

I don't know about the design, but all the documentation for IBM
S/360, S/370, ESA/390, and z/Architecture numbers the bits with 0
as the MSB. That complicates the description change from 32 bit
(through ESA/390) to 64 bit (z/Architecture), but otherwise it is
more consistent with big-endian byte order.

For an architecture without bit addressing it isn't so obvious
that the documentation needs to be consistent with the byte ordering,
but sometimes consistency is nice.

As far as uBlaze and big endian, it would seem that [8*n,8*n+7]
where n is a byte number would be somewhat more convenient than
the other way around.

-- glen

On Oct 16, 7:29*pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip)
>
> > I wonder why they do that. *I have only seen bit zero as the most
> > significant bit in a handful of designs and I expect the first was
> > done for fairly obscure reasons and the rest were done to be
> > compatible. *Did the uBlaze need to be compatible with something in
> > this regard?
>
> I don't know about the design, but all the documentation for IBM
> S/360, S/370, ESA/390, and z/Architecture numbers the bits with 0
> as the MSB. *That complicates the description change from 32 bit
> (through ESA/390) to 64 bit (z/Architecture), but otherwise it is
> more consistent with big-endian byte order.
>
> For an architecture without bit addressing it isn't so obvious
> that the documentation needs to be consistent with the byte ordering,
> but sometimes consistency is nice.
>
> As far as uBlaze and big endian, it would seem that [8*n,8*n+7]
> where n is a byte number would be somewhat more convenient than
> the other way around.
>
> -- glen

I don't follow that at all. N downto 0 numbering allows the weight of
the bit to be 2**N. That is the overriding factor for me. Switching
it around to "be consistent" with byte addressing when you don't have
bit addressing seems pretty low on the priority list.

Rick

rickman <[email protected]> wrote:
(snip of long explanation before I wrote)

>> As far as uBlaze and big endian, it would seem that [8*n,8*n+7]
>> where n is a byte number would be somewhat more convenient than
>> the other way around.

> I don't follow that at all. N downto 0 numbering allows the weight of
> the bit to be 2**N. That is the overriding factor for me. Switching
> it around to "be consistent" with byte addressing when you don't have
> bit addressing seems pretty low on the priority list.

Which seems simpler and more natural:

[8*n,8*n+7] or [31-8*n,24-8*n]

I do know that it took me longer to write the second one and
to verify that it did what I wanted it to do.

Or are you asking about the preference of big-endian for
processor design?

-- glen

On Oct 17, 2:28*am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip of long explanation before I wrote)
>
> >> As far as uBlaze and big endian, it would seem that [8*n,8*n+7]
> >> where n is a byte number would be somewhat more convenient than
> >> the other way around.
> > I don't follow that at all. *N downto 0 numbering allows the weight of
> > the bit to be 2**N. *That is the overriding factor for me. *Switching
> > it around to "be consistent" with byte addressing when you don't have
> > bit addressing seems pretty low on the priority list.
>
> Which seems simpler and more natural: *
>
> * * * * * [8*n,8*n+7] * *or * *[31-8*n,24-8*n]
>
> I do know that it took me longer to write the second one and
> to verify that it did what I wanted it to do. *
>
> Or are you asking about the preference of big-endian for
> processor design?

I don't know what the above equations are for. I have never used
either forms for anything that I can recall.

I address bits in words all the time in VHDL. I often use notation
like (foo'high-bar'high downto 0) which gives the lsbs of foo where
bar is a shorter length than foo. Or conversely (foo'high downto
bar'high) for the msbs in foo that are wider than bar. I have never
used any notation like you have shown.

Rick

rickman <[email protected]> wrote:
(snip, then I wrote)

>> Which seems simpler and more natural: ?

>> ? ? ? ? ? [8*n,8*n+7] ? ?or ? ?[31-8*n,24-8*n]

>> I do know that it took me longer to write the second one and
>> to verify that it did what I wanted it to do. ?

>> Or are you asking about the preference of big-endian for
>> processor design?
>
> I don't know what the above equations are for. I have never used
> either forms for anything that I can recall.

That is the verilog from. Most of the time I can read VHDL and
get the right idea, but I have never written it. (I did some
VHDL to verilog conversions that worked, never the other way.)

> I address bits in words all the time in VHDL. I often use notation
> like (foo'high-bar'high downto 0) which gives the lsbs of foo where
> bar is a shorter length than foo. Or conversely (foo'high downto
> bar'high) for the msbs in foo that are wider than bar. I have never
> used any notation like you have shown.

OK,

(8*n upto 8*n+7) or (31-8*n downto 24-8*n)

I believe in some cases verilog can do that with a variable n,
otherwise it can defintely do it with a constant n. Also, note
that the one on the right depends on knowing the width of the
word, while the one on the left does not.

-- glen

On Oct 17, 3:11*pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip, then I wrote)
>
> >> Which seems simpler and more natural: ?
> >> ? ? ? ? ? [8*n,8*n+7] ? ?or ? ?[31-8*n,24-8*n]
> >> I do know that it took me longer to write the second one and
> >> to verify that it did what I wanted it to do. ?
> >> Or are you asking about the preference of big-endian for
> >> processor design?
>
> > I don't know what the above equations are for. *I have never used
> > either forms for anything that I can recall.
>
> That is the verilog from. *Most of the time I can read VHDL and
> get the right idea, but I have never written it. *(I did some
> VHDL to verilog conversions that worked, never the other way.)

The verilog form for what? I have never used a calculation like
that. What is n? Why are you performing this calculation? What is
the context.


> > I address bits in words all the time in VHDL. *I often use notation
> > like (foo'high-bar'high downto 0) which gives the lsbs of foo where
> > bar is a shorter length than foo. *Or conversely (foo'high downto
> > bar'high) for the msbs in foo that are wider than bar. *I have never
> > used any notation like you have shown.
>
> OK,
>
> * * * * (8*n upto 8*n+7) * or *(31-8*n downto 24-8*n)
>
> I believe in some cases verilog can do that with a variable n,
> otherwise it can defintely do it with a constant n. *Also, note
> that the one on the right depends on knowing the width of the
> word, while the one on the left does not.

Like I said above, I have no idea why you are using a complicated
calculation to specify the bit of a word. It is extremely seldom that
I need to select a bit range based on a byte address the way you have
shown. In fact, I can't remember ever doing that.

Ignoring that, I don't see this one calculation as being a driving
reason to choose a numbering scheme for a bus. It seems to me to be
infinitely more useful to have the index correspond to the weight of
each bit to facilitate the calculation of the values in this signal.

Rick

rickman <[email protected]> wrote:
(snip, then I wrote)

>> That is the verilog from. ?Most of the time I can read VHDL and
>> get the right idea, but I have never written it. ?(I did some
>> VHDL to verilog conversions that worked, never the other way.)

> The verilog form for what? I have never used a calculation like
> that. What is n? Why are you performing this calculation? What is
> the context.

(snip)

>> ? ? ? ? (8*n upto 8*n+7) ? or ?(31-8*n downto 24-8*n)

>> I believe in some cases verilog can do that with a variable n,
>> otherwise it can defintely do it with a constant n. ?Also, note
>> that the one on the right depends on knowing the width of the
>> word, while the one on the left does not.

> Like I said above, I have no idea why you are using a complicated
> calculation to specify the bit of a word. It is extremely seldom that
> I need to select a bit range based on a byte address the way you have
> shown. In fact, I can't remember ever doing that.

Select a byte from a word. I haven't looked at the internals
of microblaze at all, but it isn't unusual to address bytes in
a 32 bit word.

assign n=x[0:1];
assign byte=word[8*n,8*n+7];

> Ignoring that, I don't see this one calculation as being a driving
> reason to choose a numbering scheme for a bus. It seems to me to be
> infinitely more useful to have the index correspond to the weight of
> each bit to facilitate the calculation of the values in this signal.

I would expect selecting bytes from words to happen much more
often in processor hardware than calculating the value of bits.

Sometimes software has to compute the value of bits, but even
that is pretty rare.

As I said before, you might make the arguement for little-endian
over big-endian, but when designing a big-endian processor, a
decision that someone else might have made for you, you do it
in the most appropriate way.

-- glen

On Oct 17, 7:01*pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> *(snip, then I wrote)
>
> >> That is the verilog from. ?Most of the time I can read VHDL and
> >> get the right idea, but I have never written it. ?(I did some
> >> VHDL to verilog conversions that worked, never the other way.)
> > The verilog form for what? *I have never used a calculation like
> > that. *What is n? *Why are you performing this calculation? *Whatis
> > the context.
>
> (snip)
>
> >> ? ? ? ? (8*n upto 8*n+7) ? or ?(31-8*n downto 24-8*n)
> >> I believe in some cases verilog can do that with a variable n,
> >> otherwise it can defintely do it with a constant n. ?Also, note
> >> that the one on the right depends on knowing the width of the
> >> word, while the one on the left does not.
> > Like I said above, I have no idea why you are using a complicated
> > calculation to specify the bit of a word. *It is extremely seldom that
> > I need to select a bit range based on a byte address the way you have
> > shown. *In fact, I can't remember ever doing that.
>
> Select a byte from a word. *I haven't looked at the internals
> of microblaze at all, but it isn't unusual to address bytes in
> a 32 bit word.
>
> * *assign n=x[0:1];
> * *assign byte=word[8*n,8*n+7];
>
> > Ignoring that, I don't see this one calculation as being a driving
> > reason to choose a numbering scheme for a bus. *It seems to me to be
> > infinitely more useful to have the index correspond to the weight of
> > each bit to facilitate the calculation of the values in this signal.
>
> I would expect selecting bytes from words to happen much more
> often in processor hardware than calculating the value of bits.
>
> Sometimes software has to compute the value of bits, but even
> that is pretty rare. *
>
> As I said before, you might make the arguement for little-endian
> over big-endian, but when designing a big-endian processor, a
> decision that someone else might have made for you, you do it
> in the most appropriate way.

I don't care about the endianness. I just have never needed to use
that one calculation before. I would code a mux the way I code a mux
for arbitrary inputs.

with x select
byte <= word(31 downto 24) when “00”,
word(23 downto 16) when “01”,
word(15 downto 8) when “10”,
word( 7 downto 0) when “11”;

It may be more verbose, but I think it is more clear than any
calculation, especially since it is the same form as used elsewhere.
I recognize instantly that this is a 4 input mux. But then I code a
hardware description so that I have some idea of what hardware will be
produced. I know a lot of people like to treat HDLs like software
where they depend on the tools to optimize the design.

The calculations I showed had to do with assigning values between
buses of different sizes which is about the only place I can think to
use calculations for array indexes. But then I'm sure there are
others I just am not thinking of.

Like I said, short of some special reason, I would always use N downto
0 notation because it indicates the bit weights. What is the value of
bit 4 and 7 set? In this notation I know it is 144 without even
knowing the width of the word.

Rick

On Oct 16, 6:59*pm, rickman <gnu...@gmail.com> wrote:
> On Oct 15, 1:10*pm, Andy Peters <goo...@latke.net> wrote:
>
>
>
> > On Oct 15, 8:14*am, rickman <gnu...@gmail.com> wrote:
>
> > > On Oct 15, 12:51*am, GrIsH <grishkun...@gmail.com> wrote:
>
> > > > On Oct 14, 11:35*am, rickman <gnu...@gmail.com> wrote:
>
> > > > > I have never worked with SLV in the 0 to N direction. *To be honest, I
> > > > > don't remember the details of how assignments are made between buses
> > > > > using different directions of indexes. *I wouldn't expect any
> > > > > surprises, but then I have no experience with them. *Is there areason
> > > > > that you are using 0 to N numbering instead of N downto 0 on yourSLV
> > > > > arrays? *This may not be a problem, but if you are stuck, why use this
> > > > > uncommon convention?
>
> > > > * * for IP2Bus_Data we are not allowed to make this convention of N
> > > > downto 0 that's why i didn't use this convention.
>
> > > Ok, it shouldn't matter really, as long as you use it correctly. *Can
> > > you explain what this bus is and why it is 0 to 31? *Is this a porton
> > > the uBlaze? *Where exactly does this restriction come from. *Why do
> > > you assign your counter result to bits 16 to 31?
>
> > MicroBlaze is big endian. Bits 16 to 31 are the two least significant
> > bytes in a 32-bit word (bit 31 is the right-most bit).
>
> > -a
>
> I wonder why they do that. *I have only seen bit zero as the most
> significant bit in a handful of designs and I expect the first was
> done for fairly obscure reasons and the rest were done to be
> compatible. *Did the uBlaze need to be compatible with something in
> this regard?
>
> Rick

The historical reason is that IBM's Power PC is big endian, so
all of the V2 pro tools were big endian, and microBlaze came
later. Sticking with big endian at that stage in the game
was better than re-writing a bunch of supporting software.

Regards,
Gabor

On Oct 19, 9:58*am, Gabor <ga...@alacron.com> wrote:
> On Oct 16, 6:59*pm, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Oct 15, 1:10*pm, Andy Peters <goo...@latke.net> wrote:
>
> > > On Oct 15, 8:14*am, rickman <gnu...@gmail.com> wrote:
>
> > > > On Oct 15, 12:51*am, GrIsH <grishkun...@gmail.com> wrote:
>
> > > > > On Oct 14, 11:35*am, rickman <gnu...@gmail.com> wrote:
>
> > > > > > I have never worked with SLV in the 0 to N direction. *To be honest, I
> > > > > > don't remember the details of how assignments are made between buses
> > > > > > using different directions of indexes. *I wouldn't expect any
> > > > > > surprises, but then I have no experience with them. *Is therea reason
> > > > > > that you are using 0 to N numbering instead of N downto 0 on your SLV
> > > > > > arrays? *This may not be a problem, but if you are stuck, whyuse this
> > > > > > uncommon convention?
>
> > > > > * * for IP2Bus_Data we are not allowed to make this convention of N
> > > > > downto 0 that's why i didn't use this convention.
>
> > > > Ok, it shouldn't matter really, as long as you use it correctly. *Can
> > > > you explain what this bus is and why it is 0 to 31? *Is this a port on
> > > > the uBlaze? *Where exactly does this restriction come from. *Why do
> > > > you assign your counter result to bits 16 to 31?
>
> > > MicroBlaze is big endian. Bits 16 to 31 are the two least significant
> > > bytes in a 32-bit word (bit 31 is the right-most bit).
>
> > > -a
>
> > I wonder why they do that. *I have only seen bit zero as the most
> > significant bit in a handful of designs and I expect the first was
> > done for fairly obscure reasons and the rest were done to be
> > compatible. *Did the uBlaze need to be compatible with something in
> > this regard?
>
> > Rick
>
> The historical reason is that IBM's Power PC is big endian, so
> all of the V2 pro tools were big endian, and microBlaze came
> later. *Sticking with big endian at that stage in the game
> was better than re-writing a bunch of supporting software.
>
> Regards,
> Gabor

Are you saying that on the Power PC they number bits in the data bus
with 0 as msb and 31 as lsb? How about address bits, is the lsb
numbered 31 and the msb numbered 0? I would find that very
confusing.

I could care less if the byte addressing is big-endian or little-
endian. I don't see that having much import when defining the bits in
a bus.

Rick

rickman <[email protected]> writes:

> On Oct 19, 9:58*am, Gabor <ga...@alacron.com> wrote:
> Are you saying that on the Power PC they number bits in the data bus
> with 0 as msb and 31 as lsb? How about address bits, is the lsb
> numbered 31 and the msb numbered 0?

Yes. And IIRC on the Motorola 88110 which preceded it, on which the
PowerPC 601 was based (buswise anyway).

> I would find that very confusing.
>
> I could care less if the byte addressing is big-endian or little-
> endian. I don't see that having much import when defining the bits in
> a bus.
>

If you look at address 0, it corresponds with bits 0 to 7 of the data
bus, address 1 is bits 8 to 15. Just like on a little-endian processor.
(Would you want address 0 on bits 31 downto 24? Maybe?)

Anyway, once they've taken that convention, making the address bus
numbered the same way makes more sense than making it opposite to the
databus!

(But nothing beats the SHARC DSP booting from an 8 bit EPROM on bits 16-23 of
the 48 bit address bus

Cheers,
Martin

--
[email protected]
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

On Oct 20, 8:32*am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> rickman <gnu...@gmail.com> writes:
> > On Oct 19, 9:58*am, Gabor <ga...@alacron.com> wrote:
> > Are you saying that on the Power PC they number bits in the data bus
> > with 0 as msb and 31 as lsb? *How about address bits, is the lsb
> > numbered 31 and the msb numbered 0? *
>
> Yes. *And IIRC on the Motorola 88110 which preceded it, on which the
> PowerPC 601 was based (buswise anyway).
>
> > I would find that very confusing.
>
> > I could care less if the byte addressing is big-endian or little-
> > endian. *I don't see that having much import when defining the bits in
> > a bus.
>
> If you look at address 0, it corresponds with bits 0 to 7 of the data
> bus, address 1 is bits 8 to 15. *Just like on a little-endian processor..
> (Would you want address 0 on bits 31 downto 24? *Maybe?)
>
> Anyway, once they've taken that convention, making the address bus
> numbered the same way makes more sense than making it opposite to the
> databus!
>
> (But nothing beats the SHARC DSP booting from an 8 bit EPROM on bits 16-23 of
> the 48 bit address bus
>
> Cheers,
> Martin
>
> --
> martin.j.thomp...@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html

By the way the "hard" big endian numbering was IBM's not Motorola's.
The
Power-PC originated at IBM and was later a joint venture with
Motorola.
Motorola's own processors, 68K series, use a mix of big endian byte
numbering
and little endian bit numbering, so in fact bits 31:24 of a 32-bit
word
on a 32-bit bus would be byte 0.

How did we get on this topic?

Regards,
Gabor

On Oct 20, 8:32*am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> rickman <gnu...@gmail.com> writes:
> > On Oct 19, 9:58*am, Gabor <ga...@alacron.com> wrote:
> > Are you saying that on the Power PC they number bits in the data bus
> > with 0 as msb and 31 as lsb? *How about address bits, is the lsb
> > numbered 31 and the msb numbered 0? *
>
> Yes. *And IIRC on the Motorola 88110 which preceded it, on which the
> PowerPC 601 was based (buswise anyway).
>
> > I would find that very confusing.
>
> > I could care less if the byte addressing is big-endian or little-
> > endian. *I don't see that having much import when defining the bits in
> > a bus.
>
> If you look at address 0, it corresponds with bits 0 to 7 of the data
> bus, address 1 is bits 8 to 15. *Just like on a little-endian processor..
> (Would you want address 0 on bits 31 downto 24? *Maybe?)
>
> Anyway, once they've taken that convention, making the address bus
> numbered the same way makes more sense than making it opposite to the
> databus!
>
> (But nothing beats the SHARC DSP booting from an 8 bit EPROM on bits 16-23 of
> the 48 bit address bus

Why would I care what the numeric name of the bits for a given byte
are? I much prefer to be able to determine the weights of each bit
without messy arithmetic.

The part that would really confuse me is if the address bus were
numbered with 0 as the msb. Do the big endian processors do that as
well? Is the uBlaze really done this way?

Rick

rickman <[email protected]> wrote:
(snip)

> Why would I care what the numeric name of the bits for a given byte
> are? I much prefer to be able to determine the weights of each bit
> without messy arithmetic.

> The part that would really confuse me is if the address bus were
> numbered with 0 as the msb. Do the big endian processors do that as
> well? Is the uBlaze really done this way?

IBM consistently numbered the MSB 0 on S/360, S/370, XA/370,
ESA/370, ESA/390, and z/Architecture.

Note that z/ is the 64 bit extension, where all general registers
and addresses are now 64 bits. The 32 bit instructions consistently
operate on bits 32 to 63 of general registers, leaving 0 to 31
unchanged.

Even more, z/ can operate on code using 64, 31, or 24 bit addressing
as appropriate, and instructions change as the addressing mode changes.

It is nice and consistent, and not so hard to get used to.

-- glen