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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 37775

Article: 37775
Subject: Re: anyone in comp.arch.fpga in irc?
From: "Domagoj" <domagoj@engineer.com>
Date: Thu, 20 Dec 2001 12:01:19 +0100
Links: << >>  << T >>  << A >>
As far as I know, there are no chanels available,
but we might open one :)

regards,
Domagoj

"AH" <akha@attbi.com> wrote in message
news:%ZWP7.7496$ER5.259797@rwcrnsc52...
> This newsgroup has been very helpful the short time I've been here.  I've
> been on IRC for 6 years and maybe only once or twice found other hardware
> engineers to talk to that actually know something.  Are there any channels
> on efnet that comp.arch.fpga people hang out in?
>
> Andy
>
>
>



Article: 37776
Subject: Ann: FPGA board Super-Value-Pack released
From: "Tony Burch" <tony@BurchED.com.au>
Date: Thu, 20 Dec 2001 23:17:51 +1100
Links: << >>  << T >>  << A >>

Burch Electronic Designs announces the new
(and amazing :) )

B5-SUPER-VALUE-PACK
http://www.burched.com.au/B5SuperValuePack.html

Main FPGA board, with Xilinx XC2S200 200K gate FPGA,
and a complete set of expansion plug-on modules.

* Complete set of units, provides excellent
   platform for FPGA education

* Ideal for System-On-Chip and FPGA-CPU prototyping

* Works with the free Xilinx WebPACK software

The B5-SUPER-VALUE-PACK includes:
1 x B5-SPARTAN2+ FPGA Main Board
1 x B5-SRAM
1 x B5-SWITCHES
1 x B5-LEDS
1 x B5-PERIPHERAL-CONNECTORS
1 x B5-PARALLEL-PORT-INTERFACE
1 x B5-IDE-INTERFACE
1 x B5-SOLIDSTATE-HARDDISK Flash Memory Disk
1 x 7SEG-DISPLAYS

Amazing introductory price, US$359.00
(whole set).

B5-SPARTAN2+ FPGA Main Board is also
available separately, US$149.00 !

In stock now.  International orders are very welcome.

Best regards and season's greetings
Tony Burch
http://www.BurchED.com.au
Low cost FPGA boards, for seriously
powerful prototyping and education !




Article: 37777
Subject: Re: Clock pins in Virtex-E
From: "none" <x@y.z>
Date: Thu, 20 Dec 2001 13:28:29 -0000
Links: << >>  << T >>  << A >>
Hi Harris,

> I have a small question. I work in a Virtex-E FPGA, my model has 4 clocks
(3
> in 155MHz and the other one slower~100MHz) as inputs. In the ucf file I
> located all clocks in the GCK pins, is that right?
Yup

> If yes, is this the only constraint that ensures proper distribution of
the
> signals?
I think it is likely that your synthesis tool will infer clock buffers for
you (provided you use the dedicated clock pins).
Alternatively you could instantiate the components directly to remove any
doubt (I needed to 'cos at the time it was the only was to get the LVPECL
input standard that I needed).
I used IBUFG to get the clock on chip, then BUFG to distribute it for simple
clocking and
IBUFG then CLKDLLE then BUFG in a more complex setup.
You could do this if your synthesis tool doesn't infer clock distribution
directly (try it and see).

> Ah , and another one :) .. one of the processes (VHDL coding) in my model
> that i want to implement uses the falling edge of the slow clock while the
> others use the rising edge of all clocks, is this going to be a problem?
No problem, an entity can contain rising edge clocked processes and falling
edge clocked process, you just can't have rising & falling in one process.

Fred




Article: 37778
Subject: Re: Hardware FPGA questions
From: Keith R. Williams <krw@btv.ibm.com>
Date: Thu, 20 Dec 2001 10:20:05 -0500
Links: << >>  << T >>  << A >>
In article <9vs55r$nm4$1@casey.uvic.ca>, yeah_spam_me@thisaddress.com 
says...
> The Virtex-E just has more BlockRAM available, IIRC...

I think the comparison is on Xilinx' site, but IIRC.

- Processes: Virtex-E is .18u 6-layer.  Virtex is .22u 5-layer
  (Virtex-E is faster and denser)
- Core voltage: Virtex-E = 1.8V Virtex = 2.5V  
- 5V tolerant: Virtex-E = "sorta", Virtex = yes
- I/O types: Virtex-E <= Virtex + [LVPECL, LVDS...]
- Differential I/O: Virtex = No, Virtex-E = Yes
- DLLs: Virtex = 4, Virtex-E = 8

I'm sure there is something else I've forgotten.

----
  Keith



Article: 37779
Subject: Re: Virtex 2 & Trace
From: Quiet Desperation <a@b.invalid>
Date: Thu, 20 Dec 2001 08:19:40 -0800
Links: << >>  << T >>  << A >>
In article <3C216B3B.88F475B1@andraka.com>, Ray Andraka
<ray@andraka.com> wrote:

> Yup, and those glue on pentium heatsinks with the fans on them come in handy
> for some of those high clock high density designs.

Oh, I work in a big company, so we have guys who do nothing specialize
in thermal analysis, so no problems there. The actual design speed is
only 500 Mbps. Ths chips are well heat sunk and we have fans on this
unit that coiuld be vectored to give it vertical takeoff and land
capability. :-) Even at 800 they barely got warm.

-- 
- Quiet Desperation -
"The mass of men lead lives of quiet desperation." -- Henry David Thoreau

Article: 37780
Subject: Re: Clocks and Synplify
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 20 Dec 2001 18:14:30 +0100
Links: << >>  << T >>  << A >>
"Antonio" <dottavio@ised.it> schrieb im Newsbeitrag
news:fb35ea96.0112190733.19044bb@posting.google.com...
> In my project I've a master clock and a clock derived by it via
> combinatorial logic, in Synplify I could apply constrain to the first,

This is no good idea. Deriving a low frequency clock from a high frequency
clock by using DIRECTLY a combinatorical logic will generate glitches on
this clock signal. What this means can bee seen on

digital.burned-fuses.de

At least you have to generate this low frequency clock dirctly from a
FlipFlop Output, which is always glitch free (unless you violate setup/hold
times) Or better for FPGA design, use a low frequency clock enable and run
everything on the high frequency clock.

--
MfG
Falk





Article: 37781
Subject: Re: clk_dll general question
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 20 Dec 2001 18:15:09 +0100
Links: << >>  << T >>  << A >>
"Antonio" <dottavio@ised.it> schrieb im Newsbeitrag
news:fb35ea96.0112190727.7a65d9df@posting.google.com...
> I would want to use clk_dll to divide a clock by 3, where can I found
> an example of this ?? Can I also apply some constrain to the clk_dll

There is an application note on the Xilinx website.

--
MfG
Falk




Article: 37782
Subject: Re: How can I reduce Spartan-II routing delays to meet 33MHz PCI's Tsu < 7 ns?
From: "Milos Becvar" <becvarm@fel.cvut.cz>
Date: Thu, 20 Dec 2001 18:15:51 +0100
Links: << >>  << T >>  << A >>
Dear Kevin,

we have recently solved simillar problem with our own PCI Core. You have to
improve your design !

Try to rearange your logic that  input signals (IRDY, FRAME, DEVSEL, TRDY -
from the
most crucial paths) has the lowest number of logic levels.

In VHDL you should move these signals  to outer IF's expresions (whatever
duplication of inner conditional statements is introduced) to give it the
highest priority.
 Internal signals (from DFFs) have 30 ns to propagate through the comb.
logic (they can pass more logic levels that IRDY, TRDY etc.).
For example use IRDY  to choose between the subexpression (where IRDY='1')
and subexpression (where IRDY='0'). STOP has generally lower fanout than
IRDY and FRAME, so it can be the second  in the IF statements tree. Normally
there is no difference for
this to be synthesised as a mux or a LUT.

All this can be done in HDL without vendor specific modifications.
Check it visually after the synthesis step whether the logic is such as
described.

In our case (Virtex xcv100-4) 7 ns Tsu is achieveable only if
there are two levels of logic for IRDY, FRAME and DEVSEL.
We also applied about 6 hand placements, mostly for these critical
paths, to move the comb.logic luts as close to the IOB DFF's as it is
posible.
(It is an iterative process and takes time until you find the best
placement, in the -5 device
this can be easily achievable).

Good luck !

Milos





Article: 37783
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: Ken McElvain <ken@synplicity.com>
Date: Thu, 20 Dec 2001 09:16:11 -0800
Links: << >>  << T >>  << A >>
Synplify does have a syn_useioff attribute that you can
set to 1 as a global attribute.  This will default all
packable boundary flip-flops into the IOB by putting the
IOB attribute on them.  You can then override the default
on a pin by pin basis with the same attribute.

Austin Franklin wrote:

> "Bret Wade" <bret.wade@xilinx.com> wrote in message
> news:3C2128F1.68274384@xilinx.com...
> 
>>
>>Austin Franklin wrote:
>>
>>
>>>>>>ALWAYS
>>>>>>
>>>>>>
>>>>>>>want my designs to use IOB flip flops if possible.  It seems to me
>>>>>>>
>>>that
>>>
>>>>>>That's what you get for using Design Mangler...er...Manager ;-)
>>>>>>
>>>>>heh.  I find that make does a fair job of managing builds.  But
>>>>>
> then, I
> 
>>>>>always did find CLIs more user friendly than GUIs.
>>>>>
>>>>>Even if you invoke map from the commandline or means other than
>>>>>
> through
> 
>>>>>DM, packing flops into I/Os is not done unless the -pr flag is
>>>>>
> supplied.
> 
>>>>>  So I suppose DM is following the defaults of map.
>>>>>
>>>>>M. Ramirez's question still holds good -- is there ever a reason not
>>>>>
> to
> 
>>>>>pack flops into IOBs?
>>>>>
>>>>>
>>>>I think that packing registers is not the default map option because
>>>>
> the
> 
>>>>expectation is that registers will have IOB=TRUE|FALSE attributes
>>>>
> applied
> 
>>>to
>>>
>>>>them by the front end tool. This attribute takes precedence over
>>>>
> the -pr
> 
>>>map
>>>
>>>>switch and allows for individual control of registers.
>>>>
>>>>Regards,
>>>>Bret Wade
>>>>Xilinx Product Applications
>>>>
>>>Bret,
>>>
>>>I don't know that that is true.  Even if Synplicity has that checked,
>>>
> the
> 
>>>Xilinx tools STILL need the "-pr b" to be added to the mapper from what
>>>
> I
> 
>>>remember.
>>>
>>>Regards,
>>>
>>>Austin
>>>
>>Austin,
>>
>>Using the IOB=TRUE attribute does take precedence and there is no need to
>>
> also
> 
>>use the "-pr b" switch. Likewise, using "-pr b" will not override an
>>
> IOB=FALSE
> 
>>attribute.
>>
>>Regards,
>>Bret
>>
> 
> Bret,
> 
> Where are you assigning these attributes?  You said in the "front end
> tools", yet Synplcity has an "syn_useioff" that doesn't appear to
> matter...you still need the "-pr b" in the mapper.  According to the
> Synplicity docs, there is no "iob" attribute...  Are you talking about in a
> constraint file?  That's really got nothing to do with the synthesis front
> end tools...
> 
> Austin
> 
> 
> 
> 


Article: 37784
Subject: Re: Kindergarten Stuff
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 20 Dec 2001 18:25:45 +0100
Links: << >>  << T >>  << A >>
"Bryan" <bryan@srccomp.com> schrieb im Newsbeitrag
news:3c20c0ef$0$25796$4c41069e@reader1.ash.ops.us.uu.net...

> ncd to hand route my couple nets.  What I am building into a macro is a 16
> bit FIFO, I have 16 of these FIFOs in the design and each one contains IOB

The question is, how fast are the clocks for this FIFOs. If it is not too
fast, you can use some oversampling methods to run everything on ONE clock.
Also, if the frequency of these FIFOs is considerably high, you should think
about a very small, fast synchronizer circuit to synchonize the incomming
datas to one clock domain and, again, work everything on one clock.

Its quite easy to run out of clock nets, but its engineering to solve the
problem without crying that much ;-)

--
MfG
Falk






Article: 37785
Subject: Re: Hardware FPGA questions
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 20 Dec 2001 18:33:16 +0100
Links: << >>  << T >>  << A >>
"Keith R. Williams" <krw@btv.ibm.com> schrieb im Newsbeitrag
news:MPG.168bc2501d45f6e09896d2@enews.newsguy.com...
> In article <9vs55r$nm4$1@casey.uvic.ca>, yeah_spam_me@thisaddress.com
> says...
> > The Virtex-E just has more BlockRAM available, IIRC...
>
> I think the comparison is on Xilinx' site, but IIRC.
>
> - Processes: Virtex-E is .18u 6-layer.  Virtex is .22u 5-layer
>   (Virtex-E is faster and denser)
> - Core voltage: Virtex-E = 1.8V Virtex = 2.5V
> - 5V tolerant: Virtex-E = "sorta", Virtex = yes
> - I/O types: Virtex-E <= Virtex + [LVPECL, LVDS...]
> - Differential I/O: Virtex = No, Virtex-E = Yes
> - DLLs: Virtex = 4, Virtex-E = 8
>
> I'm sure there is something else I've forgotten.

Due to the better (denser) process, Virtex-E is cheaper.

--
MfG
Falk





Article: 37786
Subject: Re: The speedest FPGA
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Thu, 20 Dec 2001 18:40:10 +0100
Links: << >>  << T >>  << A >>
"Antonio" <dottavio@ised.it> schrieb im Newsbeitrag
news:fb35ea96.0112132356.7f43b3fe@posting.google.com...
> I'm preparing a QPSK modulator,
> until now I arrange it for a VIRTEX 1000 -4 , but it seem that could
> be impossible to use it at a maximum clock speed of 165MHz especially

Virtex-E is faster (and cheaper).
Virtex-II is even more faster.
--
MfG
Falk




Article: 37787
Subject: Re: How to initialize the block ram of xilinx SpartanII FPGA?(Verilog)
From: kh05168 <khwnet@att.net>
Date: Thu, 20 Dec 2001 09:56:39 -0800
Links: << >>  << T >>  << A >>
Use Coregen. It is quite straightforward.

Article: 37788
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: "Austin Franklin" <austin@darkroom98.com>
Date: Thu, 20 Dec 2001 13:16:39 -0500
Links: << >>  << T >>  << A >>
Hi Ken,

If you read what I wrote in my reply, you would note that I mentioned the
syn_useioff "attribute" and also said that you still need the "pr -b"
option, as just the attribute alone does not put the FFs in the IOBs...at
least in the tool set I have been using...

Regards,

Austin

"Ken McElvain" <ken@synplicity.com> wrote in message
news:3C221CDB.2060207@synplicity.com...
> Synplify does have a syn_useioff attribute that you can
> set to 1 as a global attribute.  This will default all
> packable boundary flip-flops into the IOB by putting the
> IOB attribute on them.  You can then override the default
> on a pin by pin basis with the same attribute.
>
> Austin Franklin wrote:
>
> > "Bret Wade" <bret.wade@xilinx.com> wrote in message
> > news:3C2128F1.68274384@xilinx.com...
> >
> >>
> >>Austin Franklin wrote:
> >>
> >>
> >>>>>>ALWAYS
> >>>>>>
> >>>>>>
> >>>>>>>want my designs to use IOB flip flops if possible.  It seems to me
> >>>>>>>
> >>>that
> >>>
> >>>>>>That's what you get for using Design Mangler...er...Manager ;-)
> >>>>>>
> >>>>>heh.  I find that make does a fair job of managing builds.  But
> >>>>>
> > then, I
> >
> >>>>>always did find CLIs more user friendly than GUIs.
> >>>>>
> >>>>>Even if you invoke map from the commandline or means other than
> >>>>>
> > through
> >
> >>>>>DM, packing flops into I/Os is not done unless the -pr flag is
> >>>>>
> > supplied.
> >
> >>>>>  So I suppose DM is following the defaults of map.
> >>>>>
> >>>>>M. Ramirez's question still holds good -- is there ever a reason not
> >>>>>
> > to
> >
> >>>>>pack flops into IOBs?
> >>>>>
> >>>>>
> >>>>I think that packing registers is not the default map option because
> >>>>
> > the
> >
> >>>>expectation is that registers will have IOB=TRUE|FALSE attributes
> >>>>
> > applied
> >
> >>>to
> >>>
> >>>>them by the front end tool. This attribute takes precedence over
> >>>>
> > the -pr
> >
> >>>map
> >>>
> >>>>switch and allows for individual control of registers.
> >>>>
> >>>>Regards,
> >>>>Bret Wade
> >>>>Xilinx Product Applications
> >>>>
> >>>Bret,
> >>>
> >>>I don't know that that is true.  Even if Synplicity has that checked,
> >>>
> > the
> >
> >>>Xilinx tools STILL need the "-pr b" to be added to the mapper from what
> >>>
> > I
> >
> >>>remember.
> >>>
> >>>Regards,
> >>>
> >>>Austin
> >>>
> >>Austin,
> >>
> >>Using the IOB=TRUE attribute does take precedence and there is no need
to
> >>
> > also
> >
> >>use the "-pr b" switch. Likewise, using "-pr b" will not override an
> >>
> > IOB=FALSE
> >
> >>attribute.
> >>
> >>Regards,
> >>Bret
> >>
> >
> > Bret,
> >
> > Where are you assigning these attributes?  You said in the "front end
> > tools", yet Synplcity has an "syn_useioff" that doesn't appear to
> > matter...you still need the "-pr b" in the mapper.  According to the
> > Synplicity docs, there is no "iob" attribute...  Are you talking about
in a
> > constraint file?  That's really got nothing to do with the synthesis
front
> > end tools...
> >
> > Austin
> >
> >
> >
> >
>



Article: 37789
Subject: Array Divider
From: behrang@kimianet.com (Behrang)
Date: 20 Dec 2001 10:16:56 -0800
Links: << >>  << T >>  << A >>
Hi,

I'm searching for vhdl code of an 8 bit array divider. If you know
any, please introduce it.

Thanks in Advance,
Behrang.

Article: 37790
Subject: Floating point numbers in Handel C
From: robquigley@hotmail.com (rob)
Date: 20 Dec 2001 10:19:50 -0800
Links: << >>  << T >>  << A >>
Hey folks, howareyez?

Just wondering if anyone has any ideas about floating point numbers in
Handel C. I'm having a look at the Celoxica Floating-point library but
i'm wondering if anyone has discovered an easier way than this.

Anyone come across this or have their own way of using floating point
numbers in Handel C?

Cheers,

Rob.

Article: 37791
Subject: Re: Best-case timing?
From: Andy Peters <andy@exponentmedia.nospam.com>
Date: Thu, 20 Dec 2001 18:19:54 GMT
Links: << >>  << T >>  << A >>
Bob Perlman wrote:

> On Wed, 19 Dec 2001 17:19:58 GMT, Andy Peters
> <andy@exponentmedia.nospam.com> wrote:
> 
> 
>>Stephen Byrne wrote:
>>
>>
>>>I originally posted this yesterday on google groups, but I'm not seeing it
>>>on my home news server.  In case it is not visible to all, I'm reposting.
>>>
>>>Hello All,
>>>
>>>My company is currently comparing 66MHz PCI core solutions from Xilinx
>>>and Altera, as well as debating using a home-spun core.  One issue
>>>I've come upon is the PCI requirement for a MAX clock-to-out time of 6
>>>ns and MIN clock-to-out time of 2 ns.  Both the Xilinx ISE and Altera
>>>Quartus II tools seem very helpful in supplying MAX (worst-case) Tco
>>>times, but I don't see any info on best-case times.  Apparently the
>>>SDF files for back-annotated timing sim have the same worst-case
>>>numbers repeated 3 times, resulting in the same simulation regardless
>>>of case selection.  My question is: how is anyone (FPGA vendors
>>>included) guaranteeing a MIN Tco of 2 ns across all conditions and
>>>parts if the design tools don't even yield that information?
>>>
>>
>>You like to live dangerously if you depend on best-case timing information.
>>
> 
> What's the alternative?



Um, worst-case timing information?

--a


Article: 37792
Subject: Re: Hardware FPGA questions
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 20 Dec 2001 10:20:36 -0800
Links: << >>  << T >>  << A >>


Antonio wrote:

> Some hardware question on FPGA :
>
> 1) What's the difference between a part with speed -3 and another with
> speed -4 , the number is the number of metal layers ??

-4 -5 etc are the speed grades, determined by testing ( the actual silicon is
identical for all speed grades and also for com, ind and military parts. It's
the performance that differs).
Watch out for the direction of these numbers:
In the XC4000 series, we used the propagation delay through a look-up table ,
expressed in nanoseconds. So a lower number was faster. That got us in trouble
as the parts got faster and faster, below 1 ns.
So, for Virtex etc, we switched to "just numbers" without any physical
significance, and -since the parts are always getting faster - we use the
open-ended larger number to describe the faster part.

>
>
> 2) I read data sheet of Virtex and Virtex E, I didn't found really
> much difference, can you explain me which is better and why ??

Go to page 2 of the Virtex-E data sheet: "Virtex-E compared to Virtex"
Equally or more important is the price difference: Virtex-E is not only better,
but also cheaper, since the die is smaller, which leads to lower manufacturing
costs.

Peter Alfke, Xilinx Applications


Article: 37793
Subject: Re: Clock pins in Virtex-E
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 20 Dec 2001 10:26:05 -0800
Links: << >>  << T >>  << A >>


"H.L" wrote:

> Hello all and Merry Christmas,
> I have a small question. I work in a Virtex-E FPGA, my model has 4 clocks (3
> in 155MHz and the other one slower~100MHz) as inputs.

Why do you have 3 clocks with the same frequency? Use only one!
But if the phases or frequencies are not identical, then be very careful when
you cross from one frequency domain to the other

> In the ucf file I
> located all clocks in the GCK pins, is that right?

Yes

>
> If yes, is this the only constraint that ensures proper distribution of the
> signals?

Yes, you always get very good, low-skew distribution on the global clocks.

>
> Ah , and another one :) .. one of the processes (VHDL coding) in my model
> that i want to implement uses the falling edge of the slow clock while the
> others use the rising edge of all clocks, is this going to be a problem?

No problem

Peter Alfke



Article: 37794
(removed)


Article: 37795
Subject: Re: Hardware FPGA questions
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 20 Dec 2001 10:29:21 -0800
Links: << >>  << T >>  << A >>
It's more correct to say that the inevitable delays are shorter on the Virtex
parts with a higher speed-grade number. Therefore you can clock your design at a
higher clock rate.

Peter Alfke

"H.L" wrote:

> Hello ,
>
> That difference on speed is owing to "faster" flip-flops?
> So if you want to buy a FPGA you must determine the speed grade you want or
> the same FPGA has the ability to operate in different speeds (i.e 6,8)?
> I am a bit confused
> Harris
>


Article: 37796
Subject: Re: random number generator in Handel-C?
From: robquigley@hotmail.com (rob)
Date: 20 Dec 2001 10:29:50 -0800
Links: << >>  << T >>  << A >>
Cheers noel.

Rob.

Article: 37797
Subject: Re: You take the low road and I'll ......
From: "Pete Dudley" <padudle@sandia.gov>
Date: Thu, 20 Dec 2001 11:51:28 -0700
Links: << >>  << T >>  << A >>
Austin F. is right on the value of schematics vs. hdl and Austin L. is
wrong. It's best to use schematics to design the architectural hierarchy and
only use HDL within blocks where it makes sense.

When an HDL is used structurally you have to maintain a graphical block
diagram (schematic) on the side to keep track of how it all fits together.
In any case most schematic tools will write out a structural VHDL netlist
automatically if you're required to provide a pure HDL design.

HDL's have many valuable characteristics like portability but they have been
oversold as productivity enhancers.

"Ray Andraka" <ray@andraka.com> wrote in message
news:3C20F7F0.CCE642F6@andraka.com...
> Both schematics and HDL can be horrendous or stellar.  I've seen examples
both
> ways of both.  In either case, proper use of hierarchy is the key to a
> maintainable design.
>
> Austin Franklin wrote:
>
> > Hi Austin,
> >
> > > If I see hdl code, at least I can see where it is going, even if it is
> > written
> > > badly.
> >
> > For me, that is not true.  I have to wade around pages and pages of
> > text....where with a schematic, I can pick up what's going on almost
> > instantly.  Schematics offer, if done right that is, a built-in block
> > diagram...which can not be done with text files very easily.  The data
flow
> > is FAR easier to pick out in a schematic than in HDL, and control logic
may
> > or may not be easier to "understand" in HDL...it depends on how it's
done.
> >
> > > Nice thing about software is that people have figured out how to
manage
> > it, and
> > > document it.
> >
> > Why is that any different than schematics?
> >
> > > If I examine a design, from top to bottom, I can make a determination
of
> > the
> > > quality of the design by examining the hdl code.  It is possible, but
more
> > > difficult to see what is going on in schematic.
> >
> > I believe the exact opposite.
> >
> > > As a
> > > technical manager, code review is one tool that should be used to make
> > sure the
> > > project is on track, following the rules, and has a higher likelihood
of
> > > success.
> >
> > And you've never seen/done a schematic review?  I believe schematics are
FAR
> > easier to review than text files are.  Anyway, design reviews are
typically
> > NOT the source files, but the architecture...it's rare that one brings
> > source files to a design review and gives a copy to everyone in the
room,
> > and people just sit around flipping through hundreds of pages of text
> > discussing constructs...
> >
> > I think you should attend my lecture in the spring on mixed design entry
for
> > FPGA design ;-)
> >
> > Regards,
> >
> > Austin
>
> --
> --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: 37798
Subject: Re: Hardware FPGA questions
From: Keith R. Williams <krw@btv.ibm.com>
Date: Thu, 20 Dec 2001 14:14:06 -0500
Links: << >>  << T >>  << A >>
In article <9vt7ve$264h$1@ulysses.noc.ntua.gr>, alphaboran@yahoo.com 
says...
> Hello ,
> 
> That difference on speed is owing to "faster" flip-flops?

The logic is faster.  Gate delay lower => flops faster. 

I'm looking an an old Virtex and Virtex-E spec here.  Each speed grade 
seems to be about 10% faster than the next lower grade.  I'm fairly 
sure this only applies to the logic and not the interconnect though.

> So if you want to buy a FPGA you must determine the speed grade you want or
> the same FPGA has the ability to operate in different speeds (i.e 6,8)?
> I am a bit confused

You get what you pay for.  You buy the speed grade you need. It's 
rather like Intel processors.  If you need the fastest, get out your 
wallet!   

----
  Keith


Article: 37799
Subject: Re: The speedest FPGA
From: Ray Andraka <ray@andraka.com>
Date: Thu, 20 Dec 2001 19:20:52 GMT
Links: << >>  << T >>  << A >>
The V1000-4 is the slowest and oldest member of the Virtex families.  165 MHz is a bit on the high side
for that speed grade if you are doing anything with the carry chain,  the SRL16's or the Block RAM.  You
can get there just by moving up to the -6 speed grade, provided your design is very carefully executed.
Unless there is something holding you to that part (a military/space application requiring the QPRO part,
for example), you are better off migrating to VirtexE or VirexII parts.  Virtex E is basically the same
architecture (extra block rams and extra DLLs) but 1.8volt instead of 2.5 volt.  A virtex design can be
easily migrated to virtex E in most cases.  VirtexII is a similar architecture with more features such as
dedicated multipliers, larger Block RAM, a more flexible clock management scheme and impedance controlled
I/O.  It also has less logic elements for a given device size.

Altera's later parts are also capable, although for DSP applications, I find the Xilinx architecture to
be a better fit.

ron wrote:

> Why don't you use Virtex II?
>
> dottavio@ised.it (Antonio) wrote in message news:<fb35ea96.0112132356.7f43b3fe@posting.google.com>...
> > I'm preparing a QPSK modulator,
> > until now I arrange it for a VIRTEX 1000 -4 , but it seem that could
> > be impossible to use it at a maximum clock speed of 165MHz especially
> > 'cause I've to put in and out that speed and this seems not possible
> > (..or I'm wrong ??) I'm using less than 30% of VIRTEX 1000 so my
> > question is which FPGA is actually the one with best speed
> > performance, it could be not only Xilinx 'cause my scope is to verify
> > that there's actually a technology where my project could be
> > implemented. Thanks
> >
> >                                  Antonio

--
--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





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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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