From: chrisdekoh on
Hi

1) I am having some EDK simulation problems. I am using EDK9.2i with
microblaze 7.
I have attached a peripheral to the FSL bus using EDK's configure
coprocessor and written its corresponding drivers for the peripheral
which has commands like the one below. ie..

#include "mb_interface.h"

.....
microblaze_bwrite_fsl(data,0);



I tried generating simulation libraries to test my drivers
interfacing with the attached peripheral. I created a test bench
system_tb which would instantiate system.vhd. In addition, I had also
added the following lines:

configuration system_tb_conf of system_tb is
for all
for all : system use configuration work.system_conf;
end;
end for;
end system_tb_conf;

to ensure that the initialised BRAM by data2mem is picked up correctly
with the command:

vsim -t ps system_tb_conf

.. I have also ensured that microblaze + its peripherals do come out of
resets correctly.

however, when I probe the FSL bus from the microblaze processor, only
data from FSL0_M_data has data. The write signals from FSL0_M_write
are never asserted. In addition, no other signals from the microblaze
driving the FSL bus is asserted.

Did I miss out anything? I have set up EDK for simulation before
whilst using EDK9.1i and have done exactly the same things to get the
simulation up and running. However, it just does not seem to work in
this case.

the system I am using is the default base from the xsb provided by
Avnet with the exception to the FSL buses which is required to link to
the peripheral. I am using FSL link 0.



thanks for your help in advance!

Chris
From: G�ran Bilski on
Hi,

It's hard to tell with so little information.

Did MicroBlaze get out of reset in the simulation?
Did MicroBlaze start to execute code from your application?

If MicroBlaze gets to the instruction that writes data to FSL, the only
thing stopping it is if the fsl_full flag is asserted.

G�ran

<chrisdekoh(a)gmail.com> wrote in message
news:9ae5b725-6219-4ac9-b5ff-af7ce4d50df8(a)w1g2000prd.googlegroups.com...
> Hi
>
> 1) I am having some EDK simulation problems. I am using EDK9.2i with
> microblaze 7.
> I have attached a peripheral to the FSL bus using EDK's configure
> coprocessor and written its corresponding drivers for the peripheral
> which has commands like the one below. ie..
>
> #include "mb_interface.h"
>
> ....
> microblaze_bwrite_fsl(data,0);
>
>
>
> I tried generating simulation libraries to test my drivers
> interfacing with the attached peripheral. I created a test bench
> system_tb which would instantiate system.vhd. In addition, I had also
> added the following lines:
>
> configuration system_tb_conf of system_tb is
> for all
> for all : system use configuration work.system_conf;
> end;
> end for;
> end system_tb_conf;
>
> to ensure that the initialised BRAM by data2mem is picked up correctly
> with the command:
>
> vsim -t ps system_tb_conf
>
> . I have also ensured that microblaze + its peripherals do come out of
> resets correctly.
>
> however, when I probe the FSL bus from the microblaze processor, only
> data from FSL0_M_data has data. The write signals from FSL0_M_write
> are never asserted. In addition, no other signals from the microblaze
> driving the FSL bus is asserted.
>
> Did I miss out anything? I have set up EDK for simulation before
> whilst using EDK9.1i and have done exactly the same things to get the
> simulation up and running. However, it just does not seem to work in
> this case.
>
> the system I am using is the default base from the xsb provided by
> Avnet with the exception to the FSL buses which is required to link to
> the peripheral. I am using FSL link 0.
>
>
>
> thanks for your help in advance!
>
> Chris


From: chrisdekoh on
Hi Goran,
The FSL_Full Flag is not asserted. Also, the microblaze came out of
reset. I know cos I probed the addr and data bus signals and there is
information on the bus in the modelsim simulator, wrt to when the
microblaze is not out of reset.

anyway, i found something else. This was what I wrote in my
firmware code running on microblaze:

#include "float.h"
#include "mb_interface.h"


typdef unsigned long long uint_64; //64 bits wide
typedef union {
uint_64 long_t;
double double_t;
} Union_double_t;



int main(){
Union_double_t a;
Xuint32 temp;
a= 3.0;

//extract the lower word to put into the peripheral

temp = (Xuint32) a.long_t & 0xffffffff;
microblaze_bwrite_fsl(temp,0);
//extract the upper word to put into the peripheral
temp = ((Xuint32) a.long_t >>32) | 0xffffffff;
microblaze_bwrite_fsl(temp,0);
return 1;
}

the code above does not work. In short, when i try to send a double
precision word onto the FSL bus like the manner described above by
breaking it into the lower word and the upper word, it fails to work.

However, for a single precision word sent in exactly the same way, it
works just fine.

any idea? :)
Chris

From: G�ran Bilski on
Hi,

Easiest way to find out what is happening is to disassemble the program.
Just do a "mb_objdump -S" on the .elf file.

G�ran

<chrisdekoh(a)gmail.com> wrote in message
news:6a6c57ff-bc59-4477-83e3-c85ac0e6664d(a)a9g2000prl.googlegroups.com...
> Hi Goran,
> The FSL_Full Flag is not asserted. Also, the microblaze came out of
> reset. I know cos I probed the addr and data bus signals and there is
> information on the bus in the modelsim simulator, wrt to when the
> microblaze is not out of reset.
>
> anyway, i found something else. This was what I wrote in my
> firmware code running on microblaze:
>
> #include "float.h"
> #include "mb_interface.h"
>
>
> typdef unsigned long long uint_64; //64 bits wide
> typedef union {
> uint_64 long_t;
> double double_t;
> } Union_double_t;
>
>
>
> int main(){
> Union_double_t a;
> Xuint32 temp;
> a= 3.0;
>
> //extract the lower word to put into the peripheral
>
> temp = (Xuint32) a.long_t & 0xffffffff;
> microblaze_bwrite_fsl(temp,0);
> //extract the upper word to put into the peripheral
> temp = ((Xuint32) a.long_t >>32) | 0xffffffff;
> microblaze_bwrite_fsl(temp,0);
> return 1;
> }
>
> the code above does not work. In short, when i try to send a double
> precision word onto the FSL bus like the manner described above by
> breaking it into the lower word and the upper word, it fails to work.
>
> However, for a single precision word sent in exactly the same way, it
> works just fine.
>
> any idea? :)
> Chris
>