Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 38200

Article: 38200
Subject: Re: Repost: Should clock skew be included for setup time analysis?
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Tue, 8 Jan 2002 22:55:14 +0100
Links: << >>  << T >>  << A >>
"Kevin Brace" <nospamtomekevinbraceusenet@nospamtomehotmail.com> schrieb im
Newsbeitrag news:a1fjd2$l1s$1@newsreader.mailgate.org...

> Yes, I do realize that at a temperature lower than 85 degrees Celsius,
> the gate delays for LUTs and FFs will also decrease, therefore even if
> the clock skew decreases that shouldn't cause a major problem, however,
> no one really knows which one will decrease faster.

I think that the delay will roughly decrease by the same relative amount
(percent), so if clock skew is 2ns and logic delay is 4 ns the logic delay
decreases more and so still hold the calculation of setup time (it gets even
better). But this is just a guess.

> not it is a different speed grade, all the chips come from the same
> silicon wafer.

I think this is the case with every IC (Microprocessors etc.)

> The concern I have here is that even though the chip is marked as a
> Virtex speed grade -4, isn't it possible that chip could have been
> marked as a speed grade -6 device because it was manufactured recently?
> (let's say in 2001)

??
You mean you get a chip labeled -4 but its truely a (faster) -6. So be happy
;-) If you have a clean synchronous design, this wont matter, because the
logic is faster too.

--
MfG
Falk





Article: 38201
Subject: Re: ROM synthesis question
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Tue, 8 Jan 2002 22:58:22 +0100
Links: << >>  << T >>  << A >>
"Dr. Jeff Jackson" <jjackson@eng.ua.edu> schrieb im Newsbeitrag
news:3C3B5A39.D4B6068B@eng.ua.edu...
> Brad,
>
> I have no experience with the Xilinx toolset, but I know that Altera
> MAX+PLUSII will not place this into an EAB block. The only luck I have
> had in getting constructs like this to be implemented in the EAB blocks
> is to use the built-in LPM functions. In your case, you would want the
> LPM_ROM function.
>
> Since you are generating the programming file with an external tool, I
> would look into using the Altera Megawizard Plug-in Manager to create an
> instance of the LPM_ROM function. You can specify the ROM contents in
> either an Altera MIF (.mif) format or an Intel HEX (.hex) formatted
> file.
>
> Alternately, use the Leonardo-Spectrum tool and it should give you an
> EAB implementation that you can then import into MAX+PLUS2 for place and
> route.

Same applies to Xilinx compilers I know (XST and FPGA Express). You have to
use the core generator to use the BlockRam. For this you have to convert the
VHDL description of the ROM content into a *.coe file, should be easy with a
small script (Perl/ Visual Basic whatever)

--
MfG
Falk





Article: 38202
Subject: Re: Repost: Should clock skew be included for setup time analysis?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 08 Jan 2002 14:28:59 -0800
Links: << >>  << T >>  << A >>
Kevin Brace wrote:

> Hi, I will like to know how the readers of this newsgroup think of
> including clock skew for setup time analysis?

Clock tree synthesis is a significant issue for ASICs 
but not for FPGAs.

As long as you are using the dedicated clock network, 
clock skew is insignificant compared to gate and routing
delays.

  --Mike Treseler

Article: 38203
Subject: Re: ROM synthesis question
From: Ray Andraka <ray@andraka.com>
Date: Tue, 08 Jan 2002 22:34:13 GMT
Links: << >>  << T >>  << A >>
Depends on your synthesizer.  Synplicity can infer a ROM.  You can also build a
ROM from the RAMB4 primitives, which I find preferable to using the coregen ROMs
because a) I can put placement on it and b) I can easily simulate it without
having to mess with the *.coe files.

Falk Brunner wrote:

> "Dr. Jeff Jackson" <jjackson@eng.ua.edu> schrieb im Newsbeitrag
> news:3C3B5A39.D4B6068B@eng.ua.edu...
> > Brad,
> >
> > I have no experience with the Xilinx toolset, but I know that Altera
> > MAX+PLUSII will not place this into an EAB block. The only luck I have
> > had in getting constructs like this to be implemented in the EAB blocks
> > is to use the built-in LPM functions. In your case, you would want the
> > LPM_ROM function.
> >
> > Since you are generating the programming file with an external tool, I
> > would look into using the Altera Megawizard Plug-in Manager to create an
> > instance of the LPM_ROM function. You can specify the ROM contents in
> > either an Altera MIF (.mif) format or an Intel HEX (.hex) formatted
> > file.
> >
> > Alternately, use the Leonardo-Spectrum tool and it should give you an
> > EAB implementation that you can then import into MAX+PLUS2 for place and
> > route.
>
> Same applies to Xilinx compilers I know (XST and FPGA Express). You have to
> use the core generator to use the BlockRam. For this you have to convert the
> VHDL description of the ROM content into a *.coe file, should be easy with a
> small script (Perl/ Visual Basic whatever)
>
> --
> MfG
> Falk

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 38204
Subject: Re: latch vs. register
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 08 Jan 2002 15:00:28 -0800
Links: << >>  << T >>  << A >>
John, thanks, you just saved me a long explanation. It is exactly as you
described it .
I date back to the introduction of the 7474 and the equivalent Fairchild dual
flip-flops.
Nowadays we shelter the reader from this kind of nitty-gritty.
Most users appreciate that, some don't...
Peter Alfke
====================================
John_H wrote:

> Eric Smith wrote:
>
> > It seems to me that the plain
> > old 7474 D flip-flop is edge-triggered but not master-slave.  The output
> > is valid after a short delay from the active edge, whereas on a
> > master-slave the output would not be valid until after the opposite
> > clock edge.
>
> This is one of the fun parts of looking into other people's hardware.  I
> think it was an old TI databook that I really got to understand how the
> master-slave thing works - I think it was the 7474.  Using your terminology
> above, before the active edge (when the clock is low) the input latch (the
> master?  Thanks, Peter) is transparent allowing the incoming data to show up
> at the input of the output latch (the slave) but blocked.  When the clock
> polarity changes, the output latch becomes transparent allowing the data
> from the input latch to show up on the output;  in the mean time the input
> latch no longer tracks the input data because it's no longer transparent.
> So after the active edge, the output is looking at the data "in the middle"
> through a transparent output latch.
>
> When the opposite edge comes by the transparent output latch turns
> non-transparent (opaque?) and the data is held for the second half of the
> clock cycle as the input latch begins once again to look at the input data.
>
> Ahhhh, for the days when the data books gave all the gate level description
> you needed  :-)
>
> - John


Article: 38205
Subject: Re: Repost: Should clock skew be included for setup time analysis?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 08 Jan 2002 15:25:45 -0800
Links: << >>  << T >>  << A >>
See my comments below, regarding both postings:

Bob Perlman wrote:

> Hi -
>
> I assume you're talking about setup time margins within the chip,
> i.e., both the source and destination flip-flops are on-chip.
>
> The question boils down to how well the data delay tracks the clock
> skew delay over temperature, voltage, and process.  Xilinx used to
> claim (and maybe still does)

yes, I was the one who started that

> that gate delays track to 70%, i.e., if a
> gate is at its maximum delay, no other gate on the die will have a
> delay of less than 70% of its maximum.  Someone at Xilinx can correct
> me, but I believe that the actual tracking of delays on a die is far
> better than that, and that the 70% tracking number was chosen because
> there was absolutely no chance of it ever being violated.

True. If the delays are caused by the same physical phenomenon, then the
tracking is much better. But when it is transistor delay vs Longline RC delay,
the tracking is less  perfect.

>
>
> I tend to obsess over timing, but have to admit that I don't worry too
> much about Xilinx subtracting the clock skew from setup time.  In
> essense, they're guaranteeing that the resulting setup time is
> correct, and that you can design to it.

Clock skew over a large Virtex-II device ( i.e. difference in arrival time
between any two places on the die, irrespective of position and loading,) is
less than 100 ps, which should eliminate all chip-internal hold-time concerns.

For the I/), we can now measure data-to-clock pin set-up and negative hold times
with very high accuracy, especially when you use the DCM for clock-delay
cancellation.

> If you want something to worry about, wonder whether the speed files
> are correct.  The nice thing is, this concern is vendor-independent
> and will never go away no matter how much you worry, something that
> can be appreciated by those of us seeking constancy in an
> ever-changing, chaotic world.

Yes Bob, ever-changing, but we try to fight the chaos as best we can...
Peter

>
>
> Bob Perlman
> Cambrian Design Works
>
> On Tue, 08 Jan 2002 14:12:06 -0600, Kevin Brace wrote:
>
> Hi, I will like to know how the readers of this newsgroup think of
> >including clock skew for setup time analysis?
> >
> >        Another problem I can think is that in the case of Xilinx
> >devices, several Xilinx employees have written publicly in this
> >newsgroup (I know those are their own opinions, and not necessarily the
> >company's official position on the issues being raised) that whether or
> >not it is a different speed grade, all the chips come from the same
> >silicon wafer.

This is common industry practice, and is not controversial at all. Even memories
and microprocessors are treated this way. Everybody does it, so it is
acceptable.

>
> >That will mean that in the case of Virtex, speed grade -4, -5, or -6
> >devices come from the same silicon wafer.
> >...
> >The concern I have here is that even though the chip is marked as a
> >Virtex speed grade -4, isn't it possible that chip could have been
> >marked as a speed grade -6 device because it was manufactured recently?
> >(let's say in 2001)

Yes, that's called down-binning, and is a common practice in this industry, and
is one of the reasons we try to avoid double-ended specifications ( max and
min).
The user might not like it, but it is an important degree of freedom that we
take for economic reasons.

>
> >If so, won't the clock skew assumption made during the setup time
> >analysis be off for such Virtex speed grade -4 device, perhaps by 1ns to
> >2ns depending on the device size?

I don't understand this at all.
Clock skew is a "bad" parameter, you always must assume that it works against
you. The less skew, the better! If clock skew mystically got smaller or
disappeared, everybody should be happy.

>
> >I am not criticizing Xilinx for bin splitting devices, but I think it
> >seems risky to use maximum clock skew during setup time analysis.
> >Are there any ways to disable using maximum clock skew from being used
> >in MAP/PAR/TRCE/TimingAn?

See above.
Peter Alfke, Xilinx Applications

>


Article: 38206
Subject: Re: latch vs. register
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 09 Jan 2002 00:02:57 +0000
Links: << >>  << T >>  << A >>


Peter Alfke wrote:

> John, thanks, you just saved me a long explanation. It is exactly as you
> described it .
> I date back to the introduction of the 7474 and the equivalent Fairchild dual
> flip-flops.
> Nowadays we shelter the reader from this kind of nitty-gritty.
> Most users appreciate that, some don't...
> Peter Alfke
> ====================================
>

Wasn't it true that the large flip-flop speed up obtained by Fairchild's `F'ast
TTL series was down to using a long-tailed pair (aka diff amp) at the core of an
F74 instead of a master-slave latch ?




Article: 38207
Subject: Re: Repost: Should clock skew be included for setup time analysis?
From: "Marc Klingelhofer" <marc_klingelhofer@hotmail.com>
Date: Tue, 8 Jan 2002 16:10:35 -0800
Links: << >>  << T >>  << A >>
"Kevin Brace" <nospamtomekevinbraceusenet@nospamtomehotmail.com> wrote in
message news:a1fjd2$l1s$1@newsreader.mailgate.org...

<snip>

> Hi, I will like to know how the readers of this newsgroup think of
> including clock skew for setup time analysis?
> I am working on a PCI IP core which with various suggestions from the
> readers of this newsgroup, I was able to improve setup timings (Tsu)
> through reduction of logic levels (reduction of levels of LUTs).
> I am using ISE WebPack 4.1 and targeting Spartan-II 150K system gate
> part for my PCI IP core.
> In ISE WebPack when I ran TRCE to generate a timing error report, the
> timing report for setup time includes clock skew occurring, and this
> clock skew time subtracts some time off the data path delay (data path
> delay = gate delay + routing delay) which becomes total or final delay,
> and the worst time here is shown in the timing summary section.
> However, if I think carefully about the timing data shown in the report,
> the temperature assumed here is 85 degrees celsius, and since
> semiconductor devices have less delays in a lower temperature, at room
> temperature (20 degrees Celsius) the clock skew will likely be much less
> than what the report suggests, and even lower at a freezing temperature
> (0 degrees Celsius, the lowest temperature commercial package version of
> Spartan-II is guaranteed to function).
> Yes, I do realize that at a temperature lower than 85 degrees Celsius,
> the gate delays for LUTs and FFs will also decrease, therefore even if
> the clock skew decreases that shouldn't cause a major problem, however,
> no one really knows which one will decrease faster.

Kevin,

    The 3.1i and 4.1i documentation state positive clock skew is truncated
to 0.
That's the only skew that should improve your setup time. If the WebPack
tools
perform analysis differently, that sounds like a bug to me.


                Marc




Article: 38208
Subject: Re: Repost: Should clock skew be included for setup time analysis?
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Wed, 09 Jan 2002 00:22:27 GMT
Links: << >>  << T >>  << A >>
On Tue, 08 Jan 2002 14:28:59 -0800, Mike Treseler
<mike.treseler@flukenetworks.com> wrote:

>Kevin Brace wrote:
>
>> Hi, I will like to know how the readers of this newsgroup think of
>> including clock skew for setup time analysis?
>
>Clock tree synthesis is a significant issue for ASICs 
>but not for FPGAs.
>
>As long as you are using the dedicated clock network, 
>clock skew is insignificant compared to gate and routing
>delays.

My personal experience with large, fast Virtex-E-8 designs is that
clock skew on the dedicated clock network can be almost 10% of the
gate and routing delays.  You may or may not consider that to be
significant.

Allan.

Article: 38209
Subject: Re: latch vs. register
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Tue, 08 Jan 2002 16:44:59 -0800
Links: << >>  << T >>  << A >>


Rick Filipkiewicz wrote:

> Wasn't it true that the large flip-flop speed up obtained by Fairchild's `F'ast
> TTL series was down to using a long-tailed pair (aka diff amp) at the core of an
> F74 instead of a master-slave latch ?

Not to my knowledge, and I was responsible for Digital Applications there from 1969
to 1976. There were some strange "ones-catching" flip-flops around, but, after a
while, everybody ( including today's CMOS ) settled on the dual-latch master-slave
edge-triggered version.

I tried in vain to kill the word "hold-time" and substitute it with "min. set-up
time", but TI, who needed to defend their poorly designed flip-flop sporting
positive hold time, was too dominant.
Those were the days of cultural battles, Californians against Texans.
Californians counting 0,1,2,3 but Texans counting 1,2,3,4.
We felt so superior, but were beaten by the almighty 7400 series.
Nostalgia...

Peter Alfke



Article: 38210
Subject: Re: S-video -> VGA
From: "David G." <dgeerinck@yahoo.com>
Date: Wed, 9 Jan 2002 01:46:48 +0100
Links: << >>  << T >>  << A >>
I know this isn't really the appropriate newsgroup but I did not found
better. I'll look again or if you know one could you tell me wich one. That
will spare me a lot off time.

There's a little rectification about the name of the chip. It's a AN5396K
and not a SDB00022AEB.
I didn't make myself really clear.
I'd like to use the Twinview of my PC's video card. Therefor I need a second
screen with a s-video or composite input. Such a screen a don't have but I
have a VGA monitor. I could go to the store a by a video-convertor but those
interfaces are quet expensive. So a good thing would be make on myself, with
just what I need.

What I didn't know is that I should look wheter the GeForce2 sends PAL/SECAM
signals. I know it matter when you use a SCART connection, but didn't know
it makes a different when using s-video signals. I think I will find it out
real soon. Thanks.

Thank you.

David


"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
news:qhd70klh9t.fsf@ruckus.brouhaha.com...
> "David G." <dgeerinck@yahoo.com> writes:
> > I would like to connect a s-video (SVHS) output to the VGA input of my
> > monitor.
> > A found the SDB00022AEB chip of panasonic who a think allows me to do
that.
>
> This isn't really an FPGA or VHDL question; you might have better luck
> in a more appropriate newsgroup.
>
> Anyhow, your VGA monitor is unlikely to support the NTSC scan rate.  Most
> VGA monitors made in the last ten years have had a minimum horizontal
> rate of 31.5 KHz, while NTSC horizontal rate is only about 15.734 KHz.
> So unless the panasonic chip includes a frame buffer, you'll be
> out of luck.
>
> Your best bet would be to run the signal through a PC by using a video
> card that has a video input.



Article: 38211
Subject: Re: how do i program a Spartan FPGA
From: swan <>
Date: Tue, 8 Jan 2002 20:29:11 -0800
Links: << >>  << T >>  << A >>
isnt it high time that xilinx introduce a better solution for doing that? 

i really wonder if xapp 58 has really helped anyone

Article: 38212
Subject: ADPCM?
From: "Anthony Ellis" <anthony@ams.co.za>
Date: Wed, 9 Jan 2002 08:41:00 +0200
Links: << >>  << T >>  << A >>
Hi,

We are interested in implementing ADPCM in an FPGA. Any idea where one can
get the algorithms (tested) for this compression technique?
Anthony



Article: 38213
Subject: How can I relate Virtex2 pin names and Slice XY loc?
From: axilon <axilon@attbi.com>
Date: Wed, 09 Jan 2002 06:54:54 GMT
Links: << >>  << T >>  << A >>
How can I relate the package pin names and Slice XY locations in Xilinx
Virtex2 device?  I need it to put LOC constraint to IOB.
I looked into the pinout_text_files at DataSource CD-ROM but its
Slice X/Y Location data doesn't match with Physical names appeared at
FPGA editor screen.  For an example, in 2v40cs144.txt file, X15Y14
location has 6 pads (PAD21-PAD26) - that doesn't make sense since
each Slice location can have max 4 pads.  Am I just discovered
documentation error?
Can any Xilinx folks out there answer my question?
TIA
Ax


Article: 38214
Subject: Re: ROM synthesis question
From: dottavio@ised.it (Antonio)
Date: 9 Jan 2002 00:20:41 -0800
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> wrote in message news:<3C3B746B.8E1B4A72@andraka.com>...
> Depends on your synthesizer.  Synplicity can infer a ROM.  

Does synplify 7.02 automatically recognize the ROM and put it inside the blockram ??

Article: 38215
Subject: Re: latch vs. register
From: Jonathan Bromley <Jonathan.Bromley@doulos.com>
Date: Wed, 9 Jan 2002 09:33:50 +0000
Links: << >>  << T >>  << A >>
In article <3C3B5B70.AC2A89C8@mail.com>, John_H <johnhandwork@mail.com>
writes

[snip master/slave FF description]
>
>Ahhhh, for the days when the data books gave all the gate level description
>you needed  :-)

DANGER, maudlin nostalgic post follows:

When I was very, very much younger than I am now, I remember being
mightily troubled by how a divide-by-2 (toggle FF) worked.  I just
couldn't see how the thing could cope with an output that changed
because of the input, which was in fact the changed output.....

After much head-scratching and looking at books that I really 
didn't understand, with pictures of dual-triode Eccles-Jordan
relays (that's a vacuum-tube R-S latch to you young'uns), I 
came up with the master-slave idea.  Off to the garden shed.
Ten BC108 transistors with their cans shoved in to ten little
holes in a piece of wood, legs in the air.  1k resistors for
collector pull-ups.  10k resistors for base current limiting.
Much soldering and cursing, far and away the most difficult
circuit I had ever built.  One more transistor to buffer the
output on to a flashlight bulb.  Hardwire the thing as a 
toggle FF because I didn't understand any kind of sequential
logic other than a counter.  Connect the clock input
to a bit of wire (no money to buy real switches).  Spend
an afternoon utterly mystified by the circuit's almost
random behaviour when clocked by flicking this wire on
and off the battery terminal.

That way I learned some hard lessons about fan-in and switch
bounce.  But the right answers, learnt "properly" a few
years later, made much more sense because of the childhood
experience.  And "RTL" doesn't just mean Register Transfer
Level for me!
-- 
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                     Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573                             Web: http://www.doulos.com

                   **********************************
                   **  Developing design know-how  **
                   **********************************

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves
all rights of privilege in  respect thereof. It is intended for the  use of
the addressee only. If you are not the intended  recipient please delete it
from  your  system, any  use, disclosure, or copying  of this  document  is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.




Article: 38216
Subject: distributed ram bits in XCVxxxx series
From: Matthias Weber <msweber@onlinehome.de>
Date: Wed, 09 Jan 2002 10:27:50 GMT
Links: << >>  << T >>  << A >>
hi,

i have read in the fgpa spezifications (preliminary product spezification v2.2) about distributed ram bits (e.g 614,400 within XCV2000E)
is this kind of ram for the fpgas configuration or for user specific usage  (= 2 flipflops/latches in each logic cell or are they extra bits? if latter, are extra bits chosen
for reducing singal prpagation delays?

thanks,

matthias




Article: 38217
Subject: function generators of Xilinx XCVxxxxE series
From: Matthias Weber <msweber@onlinehome.de>
Date: Wed, 09 Jan 2002 11:18:29 GMT
Links: << >>  << T >>  << A >>
hi,

the architectural description of xilinxs fpga explains, that 4 logic cells of a CLB can be combined for executing selected functions up to 19 inputs.
before it is explained that the function generator of each logic cells works with 4 inputs. thus there are all in all 16 inputs at each CLB.
where are the last 19 - 16 = 3 inputs are comming from? are the carry inputs used?

thanks,

matthias



Article: 38218
Subject: bufg instantiation in ISE 4.1
From: k_mc_a@yahoo.co.uk (k.)
Date: 9 Jan 2002 03:23:21 -0800
Links: << >>  << T >>  << A >>
I am instantiating clock buffers in ISE 4.1 using XST with the
following
code -

	component bufg
	port (
		i : in std_logic;
		o : out std_logic
	);
	end component;

	ua : bufg
	port map (
		i => clk,
		o => clk_bufg
	);

this will implement ok. But when I try to load the design into
ModelSim I get
the following error -

# WARNING[1]: master.vhd(345): No default binding for component:
"bufg". (No entity named "bufg" was found)

What am I missing? I've gone through the Xilinx and ModelSim
documentation, but I can't find anything relevent. Any help would be
appreciated.

Article: 38219
Subject: Xilinx XC2000, XC3000, XC4000 families
From: satya@iwavesystems.net (satya)
Date: 9 Jan 2002 03:36:31 -0800
Links: << >>  << T >>  << A >>
Hi Keith,
In your previous message you mentioned that Clock skew can be
minimized by routing the clocks over global resources.As for my
knowledge,routing clocks on horizontal and vertical longlines will
give minimum skew.Please explain me how global clock resources routing
will give the minimum clock skew.
Please correct me if I am wrong.

Thanks and Regards
- satya

Article: 38220
Subject: Re: bufg instantiation in ISE 4.1
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Wed, 09 Jan 2002 12:09:03 GMT
Links: << >>  << T >>  << A >>
On 9 Jan 2002 03:23:21 -0800, k_mc_a@yahoo.co.uk (k.) wrote:

>I am instantiating clock buffers in ISE 4.1 using XST with the
>following
>code -
>
>	component bufg
>	port (
>		i : in std_logic;
>		o : out std_logic
>	);
>	end component;
>
>	ua : bufg
>	port map (
>		i => clk,
>		o => clk_bufg
>	);
>
>this will implement ok. But when I try to load the design into
>ModelSim I get
>the following error -
>
># WARNING[1]: master.vhd(345): No default binding for component:
>"bufg". (No entity named "bufg" was found)
>
>What am I missing? I've gone through the Xilinx and ModelSim
>documentation, but I can't find anything relevent. Any help would be
>appreciated.

You should do two things:

1.  In your source code, you need the lines:
library unisim;
use unisim.vcomponents.all;

2.  Use Modelsim create a library called "unisim".  Compile the
following unisim source files into it:
unisim_vcomp.vhd
unsim_vpkg.vhd
unisim_vital.vhd
You'll be able to find these files in your Xilinx software
installation.

Regards,
Allan.

Article: 38221
Subject: Interpreting Xilinx Timing Analyser report files
From: richard.padovan@wktest.com (Richard Padovan)
Date: 9 Jan 2002 04:24:20 -0800
Links: << >>  << T >>  << A >>
Where can I find a list explaining all the delay types detailed in the
Timing Analyser report file ? Sure most are self-explanatory but some
not: eg Tf_fgm.

Article: 38222
Subject: comp.arch.fpga : Problem with modelsim and ISE4.1
From: "Hua Wang" <maverickman@263.net>
Date: Wed, 9 Jan 2002 04:46:09 -0800
Links: << >>  << T >>  << A >>
Help!
Every time I launched the modelsim in ISE4.1 there was error occured. Messages displayed in the modelsim window are as follows;
Warning: Could not open log file vsim.wlf, using C;\document settings\...\temp\vismw10 instead.

Problem with simulator....vsim U/I closing(2)

Problem with simluator...vism U/I closing(1)

Then the modelsim was terminated.
I have followed the instructions on Xilinx site to compile the libs of Xilinx into Modlesim.
Could anybody please help me solve this problem.

Article: 38223
Subject: Re: Xilinx XC2000, XC3000, XC4000 families
From: Keith R. Williams <krw@btv.ibm.com>
Date: Wed, 9 Jan 2002 09:16:02 -0500
Links: << >>  << T >>  << A >>
In article <82741d43.0201090336.ebfa6eb@posting.google.com>, 
satya@iwavesystems.net says...
> Hi Keith,
> In your previous message you mentioned that Clock skew can be
> minimized by routing the clocks over global resources.As for my
> knowledge,routing clocks on horizontal and vertical longlines will
> give minimum skew.Please explain me how global clock resources routing
> will give the minimum clock skew.
> Please correct me if I am wrong.

The global clock distribution is designed for zero skew to each FF.  
I'm not privy to what Xilinx uses for a clock distribution topology, 
but it may be a grid, 'H', or some other balanced tree. Essentially 
there will be delays built into the distribution such that all FF's get 
the clock at the same time. FFs closer to the clock source will have a 
delay added to balance those further from the source.  

If you use the long-lines there is a wire delay from the top to the 
bottom (and left to right) of the chip.  These delays won't be 
balanced.

Use the dedicated clock routing if at all possible.  The tools assume 
zero (or specified) skew. If signal routing resources are used for 
clocks the clock timing will vary depending on the placement.  Timing 
is next to impossible if you route clocks on signal traces.  

I hope I got this right (and made sense).  

----
  Keith 

Article: 38224
Subject: Re: ADPCM?
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Wed, 09 Jan 2002 16:33:30 +0200
Links: << >>  << T >>  << A >>
Anthony Ellis wrote:
> 
> Hi,
> 
> We are interested in implementing ADPCM in an FPGA. Any idea where one can
> get the algorithms (tested) for this compression technique?
> Anthony

  Xilinx has ADPCM core for Virtex/-E and Spartan-II technologies
  but not other families. It is free, providing you have chosen
  Xilinx for your design.

  Utku



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search