vhdl question

please someone let me know the effects of having "ibuf_lvcmos33" for
each input , "obuf_lvcmos33" for each output and "bufg" in some entity
declarations.
In addition please let me know the effect of mappimg clk to clock in
the following entity declaration.


entity test is port (clock : in std_logic )

end clock ;

architecture arch_test of test is

signal clk : std_logic ;
clk <= clock;

end architecture arch_test ;

in the remainder of the definition, only "clk" is used. "clock" is
never used. Why cant we just use "clock".

"CMOS" <manusha@millenniumit.com> wrote in message
news:1128352673.222085.168650@g49g2000cwa.googlegroups.com...
>
> in the remainder of the definition, only "clk" is used. "clock" is
> never used. Why cant we just use "clock".
>
This technique avoids excessive wear on the 'c' and 'o' keys of your
computer. It's important to keep these keys in pristine condition in case
you need to email for coffee or cocoa.
HTH, Syms.

CMOS wrote:
> please someone let me know the effects of having "ibuf_lvcmos33" for
> each input , "obuf_lvcmos33" for each output and "bufg" in some entity
> declarations.

These connect the device pins
to the design. If you are using synthesis,
these will be inferred where needed.

> In addition please let me know the effect of mappimg clk to clock in
> the following entity declaration.

No effect for syntheses, other than possible confusion.
An extra delta delay for simulation.
I would just change the port name to clk.

         -- Mike Treseler

thank you Mike Treseler.

y dont u try a porn group Symon. dont show off ur stupidity a..hole.
CMOS

there is an industry accepted method for creating abbreviated names....
First drop the vowels
    clock    => clck

then use industry standard TLA's if applicable...
    clock => clk

the exception is a reduction that becomes ambiguous

clear as mud I hope

Simon


"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:3qdb1rFegn59U1@individual.net...
> CMOS wrote:
> > please someone let me know the effects of having "ibuf_lvcmos33" for
> > each input , "obuf_lvcmos33" for each output and "bufg" in some entity
> > declarations.
>
> These connect the device pins
> to the design. If you are using synthesis,
> these will be inferred where needed.
>
> > In addition please let me know the effect of mappimg clk to clock in
> > the following entity declaration.
>
> No effect for syntheses, other than possible confusion.
> An extra delta delay for simulation.
> I would just change the port name to clk.
>
>          -- Mike Treseler

Name the clock signal the way you want. These are only symbolic names
and only the way you use them will determine whether they are clocks
signals or not (or sometimes a combination of both).

clk <= clock has no other effect than changing the signal name and
introducing some delta delays in simulation. The synthesizer will
simplify this code to keep only one signal and will decide whether it
inserts a clock buffer based on other considerations (synthesis
constraints, use of the signal, and so on).

Effects of having ibuf_/obuf_ in VHDL are : 1) specifying @ code-time
which electrical interface your FPGA will have w/ other components on
the board (important to properly identify logic values 0/1 wrt to
electrical voltages) 2) explicitely specifying propagation delays
through the I/O pads of the FPGA in order to take their effect into
account during the VHDL simulation (note however that w/ high-density
FPGA you miss an important contributor to the propagation delay eg the
interconnect capacitance that you'll have to add after a place&route
via a .sdc file).

Eric

The clk is sort of a standard style.

I do think it is a good idea on your top level to map the IO pin
to the clk signal in case you want to change that pin or switch
to another clock source. This will save you from having to replace
all the clk signals if you want to move your clock source.

If you have testbeds, too, these will probably
all be written with clk drivers, and so it is sometime a good idea
to write your subordinate modules with clk and map it on
the upper hierarchial modules with such an assignmnet
that you suggest below.

Brad Smallridge

> In addition please let me know the effect of mappimg clk to clock in
> the following entity declaration.
>
> entity test is port (clock : in std_logic )
>
> end clock ;
>
> architecture arch_test of test is
>
> signal clk : std_logic ;
> clk <= clock;
>
> end architecture arch_test ;
>
> in the remainder of the definition, only "clk" is used. "clock" is
> never used. Why cant we just use "clock". 

CMOS wrote:
> please someone let me know the effects of having "ibuf_lvcmos33" for
> each input , "obuf_lvcmos33" for each output and "bufg" in some entity
> declarations.

The ibuf and obufs tell the tools what sort of I/O structure is to be
used.  There's some detail on this in the device datasheets.

> In addition please let me know the effect of mappimg clk to clock in
> the following entity declaration.
>
> entity test is port (clock : in std_logic )
>
> end clock ;
>
> architecture arch_test of test is
>
> signal clk : std_logic ;
> clk <= clock;
>
> end architecture arch_test ;
>
> in the remainder of the definition, only "clk" is used. "clock" is
> never used. Why cant we just use "clock".

Perhaps there's a language barrier here, but I have no idea what you're
asking.  I suspect that Symon feels the same way.

-a

what im asking is, we have "clock", which is an input to the entity and
a signal called "clk" declared in the entity. The input "clock" is
mapped to the signal "clk". In all other places only "clk" is used, but
"clock" is never used. What is the difference of doing this from just
using "clock" everywhere and eliminating "clk" altogether? 

CMOS

CMOS wrote:
> what im asking is, we have "clock", which is an input to the entity and
> a signal called "clk" declared in the entity. The input "clock" is
> mapped to the signal "clk". In all other places only "clk" is used, but
> "clock" is never used. What is the difference of doing this from just
> using "clock" everywhere and eliminating "clk" altogether?

I'd ask the question the other way round: why not call the input port
'clk'?

Nicolas