i don't have any idea to select write mode at ASMI_PARALLEL

P

PaulHam

Guest
Hi,all

I'm Paul Ham in Korea and have some difficulties in using ASMI_PARALLEL
altera ip core.
Anyone who knows well this problem could advice to me.

I've used both single-byte write and page write.
My problem is on "busy" signal after write operation.
First, when I used page write(256 bytes) operation, the "busy" signal from
ip core kept "high" during 30 us.
Second I tried to use single byte write operation, however, the ip core
gave me the "busy" signal during 300 us !!

It's unbelievable and different from the asmi_parallel data sheet.
The data sheet shows that only 3 us is needed after single byte write
operation.

So, I'd like to get some advice here what makes unexpected result.
The signals I give asmi_parallel ip core, the write/wren/addr/data are
exact.

Thanks in advanced
Regards
Paul

---------------------------------------
Posted through http://www.FPGARelated.com
 
It's unbelievable and different from the asmi_parallel data sheet.
The data sheet shows that only 3 us is needed after single byte write
operation.
So, I'd like to get some advice here what makes unexpected result.
The signals I give asmi_parallel ip core, the write/wren/addr/data are
exact.
Click to expand...

I'd check the data sheet for whatever flash device you're using, that will
be what determines the delay (mostly), not the core.



Nial.
 
It's unbelievable and different from the asmi_parallel data sheet.
The data sheet shows that only 3 us is needed after single byte write
operation.
So, I'd like to get some advice here what makes unexpected result.
The signals I give asmi_parallel ip core, the write/wren/addr/data are
exact.


I'd check the data sheet for whatever flash device you're using, tha
will
be what determines the delay (mostly), not the core.



Nial.
Click to expand...

Thanks for checking my question.
You mean, the Serial Configuration Device determines the speed of writin
?

Paul.


---------------------------------------
Posted through http://www.FPGARelated.com
 
On Oct 13, 6:50 pm, "PaulHam"
<hamsdeji@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
It's unbelievable and different from theasmi_paralleldata sheet.
The data sheet shows that only 3 us is needed after single byte write
operation.
So, I'd like to get some advice here what makes unexpected result.
The signals I giveasmi_parallelip core, the write/wren/addr/data are
exact.

I'd check the data sheet for whatever flash device you're using, that
will
be what determines the delay (mostly), not the core.

Nial.

Thanks for checking my question.
You mean, the Serial Configuration Device determines the speed of writing
?

Paul.

---------------------------------------        
Posted throughhttp://www.FPGARelated.com
Click to expand...
Hi Paul,

Take note that the waveforms in the ALTASMI_PARALLEL user guide do not
reflect the real time operation. Just like Nial said, the speed of
writing depends on the flash device used.

When the IP receives any write command (either byte write or page
write), it will follow this procedure:
- Stage 1: read status register
- Stage 2: issue write enable command
- Stage 3: write data
- Stage 4: read busy bit from status register to end operation
If you are using single byte write, only 1 byte of data is sent at
stage 3 and repeat the process for the subsequent bytes. When page
write is used, the whole bunch of data can be transferred one shot in
stage 3. So if you are using single byte write to write a bunch of
data, it will definitely take longer time. The single byte write
shouldn't take longer time than page write if only 1 byte of data is
transferred. As for the 300us delay, is it the time taken to write a
bunch of data or you are just transferring a single byte?
 
On Oct 13, 6:50=A0pm, "PaulHam"
hamsdeji@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
It's unbelievable and different from theasmi_paralleldata sheet.
The data sheet shows that only 3 us is needed after single byt
write
operation.
So, I'd like to get some advice here what makes unexpected result.
The signals I giveasmi_parallelip core, the write/wren/addr/data are
exact.

I'd check the data sheet for whatever flash device you're using, that
will
be what determines the delay (mostly), not the core.

Nial.

Thanks for checking my question.
You mean, the Serial Configuration Device determines the speed o
writing
?

Paul.

--------------------------------------- =A0 =A0 =A0 =A0
Posted throughhttp://www.FPGARelated.com

Hi Paul,

Take note that the waveforms in the ALTASMI_PARALLEL user guide do not
reflect the real time operation. Just like Nial said, the speed of
writing depends on the flash device used.

When the IP receives any write command (either byte write or page
write), it will follow this procedure:
- Stage 1: read status register
- Stage 2: issue write enable command
- Stage 3: write data
- Stage 4: read busy bit from status register to end operation
If you are using single byte write, only 1 byte of data is sent at
stage 3 and repeat the process for the subsequent bytes. When page
write is used, the whole bunch of data can be transferred one shot in
stage 3. So if you are using single byte write to write a bunch of
data, it will definitely take longer time. The single byte write
shouldn't take longer time than page write if only 1 byte of data is
transferred. As for the 300us delay, is it the time taken to write a
bunch of data or you are just transferring a single byte?
Click to expand...


Thanks for your concern.
I understand 4 step stage you said.
But I compare the only single byte "busy delay" with page(bunch) write.
Every single byte write makes 300us "busy delay".
So entirely, a single byte write takes (300us X 256)us differently with
30us of page write.

As you said, single byte write shouldnot take longer time than page write.
However, I found that they are quitely different.

Actually, I use the EPCS4 as serial configuration device.
But I think EPCS4,16,64,... have almost same performance
except of flash memory size.

I'm trying to find the missing point at that project today.
But I have a confidence due to your help & advice.

Thanks
Paul


---------------------------------------
Posted through http://www.FPGARelated.com
 
On Oct 13, 6:50=A0pm, "PaulHam"
hamsdeji@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
It's unbelievable and different from theasmi_paralleldata sheet.
The data sheet shows that only 3 us is needed after single byte
write
operation.
So, I'd like to get some advice here what makes unexpected result.
The signals I giveasmi_parallelip core, the write/wren/addr/dat
are
exact.

I'd check the data sheet for whatever flash device you're using, that
will
be what determines the delay (mostly), not the core.

Nial.

Thanks for checking my question.
You mean, the Serial Configuration Device determines the speed of
writing
?

Paul.

--------------------------------------- =A0 =A0 =A0 =A0
Posted throughhttp://www.FPGARelated.com

Hi Paul,

Take note that the waveforms in the ALTASMI_PARALLEL user guide do not
reflect the real time operation. Just like Nial said, the speed of
writing depends on the flash device used.

When the IP receives any write command (either byte write or page
write), it will follow this procedure:
- Stage 1: read status register
- Stage 2: issue write enable command
- Stage 3: write data
- Stage 4: read busy bit from status register to end operation
If you are using single byte write, only 1 byte of data is sent at
stage 3 and repeat the process for the subsequent bytes. When page
write is used, the whole bunch of data can be transferred one shot in
stage 3. So if you are using single byte write to write a bunch of
data, it will definitely take longer time. The single byte write
shouldn't take longer time than page write if only 1 byte of data is
transferred. As for the 300us delay, is it the time taken to write a
bunch of data or you are just transferring a single byte?




Thanks for your concern.
I understand 4 step stage you said.
But I compare the only single byte "busy delay" with page(bunch) write.
Every single byte write makes 300us "busy delay".
So entirely, a single byte write takes (300us X 256)us differently with
30us of page write.

As you said, single byte write shouldnot take longer time than pag
write.
However, I found that they are quitely different.

Actually, I use the EPCS4 as serial configuration device.
But I think EPCS4,16,64,... have almost same performance
except of flash memory size.

I'm trying to find the missing point at that project today.
But I have a confidence due to your help & advice.

Thanks
Paul


---------------------------------------
Posted through http://www.FPGARelated.com
Click to expand...

I found my fault.
The busy time delay of page write is longer than single byte write.
It was probed about 440us by oscilloscope.

However, the busy time delay of single byte write is still to
longer(300us)
than datasheet(3us).




---------------------------------------
Posted through http://www.FPGARelated.com
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top