WHAT SITUATION I NEED A BUFFER

I am a newer for FPGA. I am reading some vhdl codes of others. I find
they often use some buffers in design, such as IBUF, OBUF, FDCE,
FDCE_1,etc.I have checked these buffer function but still not very sure
the reason why these buffers put there. Is there anybody kindly tell me
what situation we need a buffer? Or just give me some materials of it.
I can check it by myself. Thanks

ZHI wrote:
> I am a newer for FPGA. I am reading some vhdl codes of others. I find
> they often use some buffers in design, such as IBUF, OBUF, FDCE,
> FDCE_1,etc.I have checked these buffer function but still not very sure
> the reason why these buffers put there. 

Maybe you are looking at a vhdl netlist.
Creating a netlist of buffers registers
and luts from vhdl source code is the
job of synthesis.

     -- Mike Treseler

Thanks Mike Treseler
 I am not reading a vhdl netlist.  I am reading a uart application
codes. For example, the input signal (RXD signal) of FPGA  firstly
go through a IBUF then a BUFG. What's the uses of them respectively?
Why need use these buffers? When need use them?
Or we actually don't need to care these buffers at all.

Mike Treseler wrote:
> ZHI wrote:
> > I am a newer for FPGA. I am reading some vhdl codes of others. I find
> > they often use some buffers in design, such as IBUF, OBUF, FDCE,
> > FDCE_1,etc.I have checked these buffer function but still not very sure
> > the reason why these buffers put there.
>
> Maybe you are looking at a vhdl netlist.
> Creating a netlist of buffers registers
> and luts from vhdl source code is the
> job of synthesis.
> 
>      -- Mike Treseler

ZHI wrote:
> Thanks Mike Treseler
>  I am not reading a vhdl netlist.  I am reading a uart application
> codes. 

Maybe it is a vendor-specific example.
Here is a generic uart example that will work for any device:
http://home.comcast.net/~mike_treseler/uart.vhd

> For example, the input signal (RXD signal) of FPGA  firstly
> go through a IBUF then a BUFG. What's the uses of them respectively?

You could use them to sell devices
to customers who don't know synthesis.

> Why need use these buffers? When need use them?

I would never use them directly.
Let synthesis do its job.

> Or we actually don't need to care these buffers at all.

That's it.

         -- Mike Treseler

OK, I see. Thank you , Mike Treseler.

By the way, I am using the Xilinx Virtex-II Pro board now. Could you
introuduce a good way to learn how to design FPGA? Is this a correct
way to read through the Virtex-II Pro and Virtex-II X FPGA User Guide?
Many thanks!

Zhi

Mike Treseler wrote:
> ZHI wrote:
> > Thanks Mike Treseler
> >  I am not reading a vhdl netlist.  I am reading a uart application
> > codes.
>
> Maybe it is a vendor-specific example.
> Here is a generic uart example that will work for any device:
> http://home.comcast.net/~mike_treseler/uart.vhd
>
> > For example, the input signal (RXD signal) of FPGA  firstly
> > go through a IBUF then a BUFG. What's the uses of them respectively?
>
> You could use them to sell devices
> to customers who don't know synthesis.
>
> > Why need use these buffers? When need use them?
>
> I would never use them directly.
> Let synthesis do its job.
>
> > Or we actually don't need to care these buffers at all.
> 
> That's it.
> 
>          -- Mike Treseler

ZHI wrote:

> By the way, I am using the Xilinx Virtex-II Pro board now. Could you
> introuduce a good way to learn how to design FPGA? Is this a correct
> way to read through the Virtex-II Pro and Virtex-II X FPGA User Guide?

You only really need an editor and simulator to get started.
Once you know how to write and simulate HDL code for
synthesis, you can try the design in hardware.
Until then, all you can do with the board
is run the canned demos and flash the LEDs.

           -- Mike Treseler

ZHI wrote:
> Thanks Mike Treseler
>  I am not reading a vhdl netlist.  I am reading a uart application
> codes. For example, the input signal (RXD signal) of FPGA  firstly
> go through a IBUF then a BUFG. What's the uses of them respectively?
> Why need use these buffers? When need use them?
> Or we actually don't need to care these buffers at all.

BUFG is a buffer which drives a global clock network.
IBUF is a buffer from the input pin.

IBUF->BUFG would typically be used when an external pin is used to drive 
  a clock signal and the pin is NOT a dedicated clock input.

Ideally a synthesizer would handle this automatically. Sometimes the 
tool is not smart enough. Instantiating BUFG directly forces it to route 
the signal on a global clock net.

Having said that, treating a UART RXD signal as a global clock sounds 
rather bizarre.

-Jeff

Thank you all.

I have a strange thing now. I implemented one algorithm into FPGA
board.
I sent data generated by Matlab from PC to FPGA board. And the results
are sent back to Matlab. Becuause I need caculate the bit error rate, I

tried it many times. I set the number of trials is 10000. It did work
in some trials at first but stopped at a random trial. The Matlab
always
show busy but not continue to next trial. I have to close Matlab and
try again. The phenomenon happens every time. Is this the problem of my

vhdl codes=EF=BC=9F But how can it successuflly work for some trials (even
reached 9883 trial)?  How to fix it?


Jeff Cunningham wrote:
> ZHI wrote:
> > Thanks Mike Treseler
> >  I am not reading a vhdl netlist.  I am reading a uart application
> > codes. For example, the input signal (RXD signal) of FPGA  firstly
> > go through a IBUF then a BUFG. What's the uses of them respectively?
> > Why need use these buffers? When need use them?
> > Or we actually don't need to care these buffers at all.
>
> BUFG is a buffer which drives a global clock network.
> IBUF is a buffer from the input pin.
>
> IBUF->BUFG would typically be used when an external pin is used to drive
>   a clock signal and the pin is NOT a dedicated clock input.
>
> Ideally a synthesizer would handle this automatically. Sometimes the
> tool is not smart enough. Instantiating BUFG directly forces it to route
> the signal on a global clock net.
>
> Having said that, treating a UART RXD signal as a global clock sounds
> rather bizarre.
>=20
> -Jeff

ZHI wrote:

> The Matlab
> always
> show busy but not continue to next trial. I have to close Matlab and
> try again. The phenomenon happens every time. Is this the problem of my
> vhdl codes？

Sounds like a Matlab bug. Open a case with them.

> But how can it successuflly work for some trials (even
> reached 9883 trial)?

Memory leaks are like that.

>   How to fix it?

Upgrade Matlab.
Maybe try a different computer.

  -- Mike Treseler

My algorithm is to solve the linear equation R.h=3Db, (R matrix ,b vector
is known, generated in Matlab). R,b are  transmitted to FPGA board.
After the application caculation, h is sent back to Matlab.
I set the number of trials is 100. it will no problem. If
trials=3D100000, it will happen the "accidently stop" in Matlab.
I guess you are right that it looks like memory leak. I tried a simple
test.
Numbers from 1 to 100 transmit from Matlab to FPGA board(UART) and send
them back. These numbers are sent back correctly. If i send the number
from 1 to 1000 to UART. The matlab will show like that:
(InputBufferSize=3D512 in my matlab version)
----------------------------------------------------------------
 Error using =3D=3D> serial.fread
SIZE * PRECISION must be less than or equal to InputBufferSize.
Error in =3D=3D> testuart at 17
y=3D fread(s,1000,'uint8');
-------------------------------------------------------
I am not sure if i say it clearly. Hope you can help me to figure it
out.
Thanks a lot.

Zhi



Mike Treseler wrote:
> ZHI wrote:
>
> > The Matlab
> > always
> > show busy but not continue to next trial. I have to close Matlab and
> > try again. The phenomenon happens every time. Is this the problem of my
> > vhdl codes=EF=BC=9F
>
> Sounds like a Matlab bug. Open a case with them.
>
> > But how can it successuflly work for some trials (even
> > reached 9883 trial)?
>
> Memory leaks are like that.
>
> >   How to fix it?
>
> Upgrade Matlab.
> Maybe try a different computer.
>=20
>   -- Mike Treseler