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 31225

Article: 31225
Subject: Comparator
From: "vi" <vi_ismyname@hotmail.com>
Date: Tue, 15 May 2001 15:17:03 -0700
Links: << >>  << T >>  << A >>
Can anyone supply me or direct me to a source that has a 24-bit
comparator(GT or LT output) in schematic format for FPGA?  I use Xilinx.

Thanks




Article: 31226
Subject: Re: Virtex-2 - experiences ?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 15 May 2001 23:35:05 +0100
Links: << >>  << T >>  << A >>


hamish@cloud.net.au wrote:
> 
> Rick Filipkiewicz <rick@algor.co.uk> wrote:
> > extends to V2-4 <=> V-E-7 then I'll gladly pay the extra price.
> 
> Is that roughly right? Virtex-II -4 equivalent to a Virtex-E -7?
> 
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

If you look back in this thread you'll see Ausin Lesea saying that the
V-2 -5 speed is ``faster'' than the V-E -8 so I extrapolated downwards
[destrapolated ?] to the equivalence above.

Don't worry Austin we won't absolutely hold you to your statement, we're
grown-ups around here -   excepting any lawyers who might have wandered
in off the playground.

Article: 31227
Subject: BargainsHotLine.com New Free Way To SAVE $ MONEY $
From: contactus@bargainshotline.com
Date: Tue, 15 May 2001 23:38:40 GMT
Links: << >>  << T >>  << A >>
--_NextPart_000090A2-00001B1E-36559C2B-62CF
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

--_NextPart_000090A2-00001B1E-36559C2B-62CF
Content-Type: text/plain; name="personalemail.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: Attachment; filename=personalemail.txt; size=984

Hi,

My name is Nick, I shop on the internet allot!
I noticed that I have to go through 20 to 30 links
before I can even find the product I am looking for!
Then when I find the product I don't even know if it really 
is a bargain or not! There for I designed a web site
that will save you and me hours of time on the Internet to find 
REAL bargains. Would you be interested to receive a FREE newsletter 
that will tell you where the REAL bargains are on-line?


Interested? Yes, I want to subscribe! 
visit: http://www.bargainshotline.com


Not? Please remove my name from your mailing list. 
Visit: http://www.bargainshotline.com/unsubscribe.asp


Disclaimer
##########

Our research indicates the following material is of interest
to you. If you prefer not to be on this mailing list, please
let us knows, and you will be promptly removed.


**************************
Nick@bargainshotline.com
Lake Forest,CA 92630
Tel 949.598.0078
Fax 949.598.0585
--_NextPart_000090A2-00001B1E-36559C2B-62CF--

Article: 31228
Subject: Re: SRAM fpga cell
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 16 May 2001 00:12:22 GMT
Links: << >>  << T >>  << A >>
Peter Alfke <peter.alfke@xilinx.com> writes:

>This is really a moot discussion.
>There is no exact scientific relationship between an ASIC gate count 
>and the logic implemented on a LUT-based FPGA. The value of a LUT 
>can vary from 0 to 20 gates! And what's the value of a RAM bit? 
>And what if it's dual-ported? No, I mean True Dual-Ported !
>And there are lots of things (  DLLs,  carry logic, multipliers, 
>Clock multiplexers etc ) that would not show up in any "gate count". 
>This leaves the field wide open to Creative Marketing, and the 
>two main players try to outdo each other.

I mostly agree with this.  The gate count, as I know it for ASICs,
is the number of transistors divided by the number of transistors in
a NAND gate.  This is hard to apply to an FPGA.  The number, though,
should fairly represent the number of equivalent gates one might be
able to use for a typical design.  I don't think the problem is much
worse than benchmark speeds for processors.  Both depend on the specific
application that one is using.

Maybe someone (like SPEC) could make a set of benchmark designs that
one could synthesize, place, and route.  Maybe scalable designs so
one could adjust the scale factor to find the largest such design
that would fit.

-- glen

Article: 31229
Subject: Re: Finally, an FPGA tool chain for Linux (Altera Quartus II)
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 16 May 2001 00:29:23 GMT
Links: << >>  << T >>  << A >>
Neil Franklin <neil@franklin.ch.remove> writes:

>Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:

>> Neil Franklin <neil@franklin.ch.remove> writes:
>> > Methinks, you do not know, that you can still get TOPS-20 v7.xx
>> > together with fitting hardware TOAD-1 [1] (an KL-10 clone with 30bit
>> > extended addressing) from XKL (http://www.xkl.com/).
>>
>> Bzzzt!  No longer commercially available.

>Not any more? Bummer.

>All the more reason for me to get on with my clone then. :-)

There is now a software emulator that runs under most unix
systems.  The remaining bugs are rapidly being worked out.

I forget if they have TOPS-20 running yet.  Maybe only TOPS-10.

See the pdp10 newsgroup.

-- glen

Article: 31230
Subject: Counter problem in Altera AHDL...
From: Michael Kohne <mhkohne@discordia.org>
Date: Wed, 16 May 2001 01:57:43 GMT
Links: << >>  << T >>  << A >>
I've got a stupid problem with a counter. The code is written in
Altera's AHDL language, and an older version of the code works just
fine. I have the feeling that I'm doing something really stupid to
cause this problem, and if anyone could point me in the right
direction of a solution to it, I'd really appreciate it.

The problem is that the FAD outputs seem to glitch a lot. I've only
seen single bit glitches. Basically, the counter will do something
like count from 1E to 1F, then 3/4 of the way until it should count to
20, it becomes 3F. When the time comes, it then correctly becomes 20.
The problem lies in that the rams are always enabled, so these address
glitches cause glitches in the ram outputs, which is a BIG problem for
the rest of our product.

I've attempted adding an extra registration step after the counter
(FADCNT_R[].clk = 17_5MHz; FADCNT_R[].d = FADCNT[].q;) but that had NO
effect on the problem. 


As near as I can tell from the timing analysis, there shouldn't be a
timing issue (that's why we went with the -1 version of the 10K250).

Any and all help GREATLY appreciated.

Thanks!




Target is an EPF10K250ABC600-1. I've got EPC1 roms in the board, but
I'm loading new code via a byteblaster.


Software is MAX+plus II version 10.0 9/14/2000 (2000.09)
I'm NOT using the quartus fitter. That is because this design has a
very bad pin layout and the use of Cliques in the older fitter allows
me to get the fits to meet timing much better. I have several Cliques
defined, including one that contains all the FAD and FADCNT signals.

Here's the relevant parts of the code:
(the FAD output runs to the address lines of a set of rams. When it's
in count mode, it's clocking pre-loaded data out of the rams).

FAD[18..0] : OUTPUT;

FADCNT[18..0] : DFF; 

FADCNT[18..0].clk = 17_5MHZ; -- 17_5MHZ is a 35 MHZ input divided
				-- by two

FADCNT[18..0].clrn = WOODGATE_RR; -- when this signal is not active,
				-- we don't want to run

IF (XMTN_R63) THEN	-- XMTN_R63 is a registered copy of an input
   FADCNT[18..0].d = 0;
ELSE
   FADCNT[18..0].d = FADCNT[18..0].q + 1;
END IF;



Michael Kohne
mhkohne@discordia.org
3000 pound of wood moving at 300 feet per minute. Don't get in the
way...


Article: 31231
Subject: Re: SRAM fpga cell
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Wed, 16 May 2001 13:39:58 +1000
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
> 
> Peter Alfke <peter.alfke@xilinx.com> writes:
> 
> >This is really a moot discussion.
> >There is no exact scientific relationship between an ASIC gate count
> >and the logic implemented on a LUT-based FPGA. The value of a LUT
> >can vary from 0 to 20 gates! And what's the value of a RAM bit?
> >And what if it's dual-ported? No, I mean True Dual-Ported !
> >And there are lots of things (  DLLs,  carry logic, multipliers,
> >Clock multiplexers etc ) that would not show up in any "gate count".
> >This leaves the field wide open to Creative Marketing, and the
> >two main players try to outdo each other.
> 
> I mostly agree with this.  The gate count, as I know it for ASICs,
> is the number of transistors divided by the number of transistors in
> a NAND gate.  This is hard to apply to an FPGA.  The number, though,
> should fairly represent the number of equivalent gates one might be
> able to use for a typical design.  I don't think the problem is much
> worse than benchmark speeds for processors.  Both depend on the specific
> application that one is using.
> 
> Maybe someone (like SPEC) could make a set of benchmark designs that
> one could synthesize, place, and route.  Maybe scalable designs so
> one could adjust the scale factor to find the largest such design
> that would fit.
 
About a decade ago there was a benchmark called "Prep" but it isn't used
anymore.  I'm not quite sure why, but I think it had something to do
with Prep not being a realistic measure of the performance of a part. 
IIRC, one of the measures was the number of 16 bit counters that would
fit.  Obviously, this mapped quite well to one particular vendor's part
that has groupings of 16 flip flops.

I propose a new benchmark: the number of traffic light or vending
machine controllers that will fit in the FPGA.  :)

Regards,
Allan.

Article: 31232
Subject: Re: Can't drive?
From: kfalser@REMOVETHISdurst.it (Klaus Falser)
Date: Wed, 16 May 2001 06:32:51 GMT
Links: << >>  << T >>  << A >>
On Tue, 15 May 2001 16:33:36 +0200, "Noddy" <g9731642@campus.ru.ac.za>
wrote:

>Hi,
>
>Sorry, new at designing on FPGA's. I have made a design with two macro
>symbols, the first driving the second. Simulation by themselves works fine,
>but as soon as  I connect the first macro to the second, it appears the the
>outputs of the first symbol can't drive the second - could be due to excess
>circuitry etc. Thus, the outputs just go to X when they are supposed to go
>high.
>
>What is the most common technique on FPGA's to rectify this problem?
>
>adrian
>
>

Usually there is no limit for how many signals can be driven by a
signal during simulation.
I think you must have done a mistake elsewhere.  

If you give us more information maybe someone can help you better.

Best regards
 
Falser Klaus
R&D Electronics Department
Company	: Durst Phototechnik AG
	Vittorio Veneto Str. 59
	I-39042 Brixen
Voice	: +0472/810235
	: +0472/810111
FAX	: +0472/830980
Email	: kfalser@IHATESPAMdurst.it 

Article: 31233
Subject: Re: Fine phase shift in Virtex2
From: Srinivasan Venkataramanan <srini@realchip.co.in>
Date: Wed, 16 May 2001 12:15:30 +0530
Links: << >>  << T >>  << A >>
Brian,
     I am not an FPGA expert, but was rather interested in this
discussion.

Brian Philofsky wrote:
> 
> Meelis,
> 
<SNIP>

> As far as I know,
> VHDL attributes are ignored by most simulators and therefore can not pass
> information to simulation models however generics can.  

  I think you are correct, but why can't a simulator "understand"
attributes - I remember reading that attributes are mainly used by
Synthesis tools, but essentially it is a VHDL compiler's job to
interpret these attributes - am I right? If so IMHO a simulator in
principle *CAN* understand attributes. They don't is a different
issue.

Could someone explain if there is any problem with this?

TIA

Srini

-- 
Srinivasan Venkataramanan (Srini)
ASIC Design Engineer,
Chennai (Madras), India

Article: 31234
Subject: Re: Fine phase shift in Virtex2
From: Alan Fitch <alan.fitch@doulos.com>
Date: Wed, 16 May 2001 10:07:50 +0100
Links: << >>  << T >>  << A >>
In article <3B02220A.790435AC@realchip.co.in>, Srinivasan Venkataramanan
<srini@realchip.co.in> writes
>Brian,
>     I am not an FPGA expert, but was rather interested in this
>discussion.
>
>Brian Philofsky wrote:
>> 
>> Meelis,
>> 
><SNIP>
>
>> As far as I know,
>> VHDL attributes are ignored by most simulators and therefore can not pass
>> information to simulation models however generics can.  
>
>  I think you are correct, but why can't a simulator "understand"
>attributes - I remember reading that attributes are mainly used by
>Synthesis tools, but essentially it is a VHDL compiler's job to
>interpret these attributes - am I right? If so IMHO a simulator in
>principle *CAN* understand attributes. They don't is a different
>issue.
>
>Could someone explain if there is any problem with this?
>
>TIA
>
>Srini
>

My guess is that (as Microsoft always say) "this behaviour is by
design", i.e. attributes are intended for annotating arbitrary
information on to objects in VHDL, but are not intended for altering the
behaviour of simulation. Though when you read the standard, it doesn't
say that, and clearly the built-in attributes *do* have an effect on
simulatin.


I suppose simulators could look at attributes, but if they did it would
be nice to have a standard so that all simulators understood the same
attributes!

regards

Alan

-- 
Alan Fitch
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                        Email: alan.fitch@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: 31235
Subject: Re: Leonardo Spectrum Level 1 vs Level 3
From: Alan Fitch <alan.fitch@doulos.com>
Date: Wed, 16 May 2001 10:09:10 +0100
Links: << >>  << T >>  << A >>
In article <2kn2gt8nnns5hat9q5bsaqseo2t4vll9aq@4ax.com>, Muzaffer Kal
<muzaffer@dspia.com> writes
>On Tue, 15 May 2001 11:21:33 +0200, Roy Shoshani <roy@harmonic.co.il>
>wrote:
>
>>What is the difference between Level 1 and Level 3 Version in Leonardo
>>Spectrum (Exemplar Logic)?
>
>Level 3 has asic synthesis option. Level 1 & 2 are for strictly fpga.
>1&2 probably has optimization capability differences.
>
>Muzaffer
>
>FPGA DSP Consulting
>http://www.dspia.com

Also Level 1 is the "OEM" version, and is limited to target just one
technology (depending on who the OEM is of course!)

Alan
-- 
Alan Fitch
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223                        Email: alan.fitch@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: 31236
Subject: Handel C question
From: "Brendan Lynskey" <brendan.lynskey@pace.co.uk>
Date: Wed, 16 May 2001 10:48:51 +0100
Links: << >>  << T >>  << A >>
Hi.

I'm evaluating Handel C, (DK1 eval), and believe one of the Tutorial
Examples is being simulated wrongly.

I'm playing with example 3, (queue), and am seeing the following in
simulation:

        State 0 State 1 State 2 State 3
Clk

1    0    0    0    0
2    0    0    0    0
3    0    0    0    0
4    97    0    0    0
5    97    0    0    0
6    97    0    0    0
7    97    97     97    97

(please excuse the shabby table!)

Would I be right in thinking that this is wrong? I assumed that the 'state'
variables map to registers, and the channels map to drivers.

Any help appreciated,

    Bren





Article: 31237
Subject: interfacing:keyboard/displays
From: bhupesh <bhupeshr@softhome.net>
Date: Wed, 16 May 2001 03:30:47 -0700
Links: << >>  << T >>  << A >>
Hi I am trying to build a functionality around xc9500xv family of CPLDs. It requires interfacing the CPLD to keyboard and seven segment displays. If anyone has a prior experience interfacing a keyboard and/or seven segment display to this family of CPLDs, I am looking forward to your advice Thanking you in anticipation bhupesh bhupeshr@softhome.net

Article: 31238
Subject: Re: Handel C question
From: "Brendan Lynskey" <brendan.lynskey@pace.co.uk>
Date: Wed, 16 May 2001 11:49:16 +0100
Links: << >>  << T >>  << A >>

Please ignore the above post - my mistake!

"Brendan Lynskey" <brendan.lynskey@pace.co.uk> wrote in message
news:9dti6a$abc$1@nh.pace.co.uk...
> Hi.
>
> I'm evaluating Handel C, (DK1 eval), and believe one of the Tutorial
> Examples is being simulated wrongly.
>
> I'm playing with example 3, (queue), and am seeing the following in
> simulation:
>
>         State 0 State 1 State 2 State 3
> Clk
>
> 1    0    0    0    0
> 2    0    0    0    0
> 3    0    0    0    0
> 4    97    0    0    0
> 5    97    0    0    0
> 6    97    0    0    0
> 7    97    97     97    97
>
> (please excuse the shabby table!)
>
> Would I be right in thinking that this is wrong? I assumed that the
'state'
> variables map to registers, and the channels map to drivers.
>
> Any help appreciated,
>
>     Bren
>
>
>
>



Article: 31239
Subject: Re: Bizarre PAR phenomenon
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Wed, 16 May 2001 14:42:13 +0300
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:

> For some time now I've noticed that every now & again PAR would hang up
> in the ``route PWR/GND'' phase of iteration 2. Or, at least, progress
> would slow to a crawl. Since I've only got 722 such connections none of
> the answers on the web seemed at all relevant.

Rick,

If I remember correctly, there was a discussion on PWR/GND distribution
at this newsgroup long ago (I don't know if you can find these postings
in http://groups.google.com (formerly http://www.deja.com) since they lost
old mails or whatever).

Can it be the problem how PWR/GND is modelled in HDL? Maybe 722 PWR/GND
connections is used from only one Verilog assignment. Or, are these
potentially unroutable connections centralized within some small region
(module) of the chip? Maybe warning/errors of unrouted PWR/GND might
inform on it.

Utku



Article: 31240
Subject: Re: SRAM fpga cell
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 16 May 2001 13:50:09 +0100
Links: << >>  << T >>  << A >>


Allan Herriman wrote:
> 
> glen herrmannsfeldt wrote:
> >
> I propose a new benchmark: the number of traffic light or vending
> machine controllers that will fit in the FPGA.  :)
> 
> Regards,
> Allan.

Nice idea &, since we are now in the 21st century, I propose that this
becomes a multi-media benchmark. So that it can be easily determined if
anyone's faking it

(1) Each of the traffic light controllers should be connected to an
output that drives one of those combined red/yellow/green LEDs.

(2) Each vending machine should have a simple audio synthesiser to give
realistic sounds of coins going in, the item required falling into the
out tray, the item shooting out of the slot & smashing on the floor
because the flap had stuck open, the machine having the ^%$*& kicked out
of it when the coins jam due to a metastability error in the code. 

This last should also apply to the traffic light controller with sounds
of multiple pile-ups and agruments between drivers ending in outbursts
of mindless violence.

Article: 31241
Subject: Re: Bizarre PAR phenomenon
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 16 May 2001 13:54:04 +0100
Links: << >>  << T >>  << A >>


Utku Ozcan wrote:
> 
> Rick Filipkiewicz wrote:
> 
> > For some time now I've noticed that every now & again PAR would hang up
> > in the ``route PWR/GND'' phase of iteration 2. Or, at least, progress
> > would slow to a crawl. Since I've only got 722 such connections none of
> > the answers on the web seemed at all relevant.
> 
> Rick,
> 
> If I remember correctly, there was a discussion on PWR/GND distribution
> at this newsgroup long ago (I don't know if you can find these postings
> in http://groups.google.com (formerly http://www.deja.com) since they lost
> old mails or whatever).
> 
> Can it be the problem how PWR/GND is modelled in HDL? Maybe 722 PWR/GND
> connections is used from only one Verilog assignment. Or, are these
> potentially unroutable connections centralized within some small region
> (module) of the chip? Maybe warning/errors of unrouted PWR/GND might
> inform on it.
> 
> Utku

But, Utku, why only on a Sunday ?

Article: 31242
Subject: Re: PCI The Real Hardware
From: Iwo Mergler <Iwo.Mergler@soton.sc.philips.com>
Date: Wed, 16 May 2001 13:55:20 +0100
Links: << >>  << T >>  << A >>
cyber_spook wrote:
> 
> I have a question regarding the bit of PCI outside the chip - the bus!?
> 
> I know that running at 33/66 Mhz is entering the RF range of problems -
> but how far can I push it, and it still work?
> 
> It should reay have a short bus with minimal stubs to each card / device
> as you see in a standard pc, with good grouding and tracks layed
> correctly. corret?
> 
> But.....
> 
> and here are my questions:-
> 
> How long can the bus be at 66Mhz?
> How much veriation in track length can I have? (1 inch, 5 inch, 10inch
> difference?)
> How long can a stub be? (1 inch, 5 inch?)
> How close can I lay tracks to each other or other data lines without
> cross talk?
> What problems am I ligthy to see? bit errors, parity etc?
> 
> also... If I have one device that is 32bit and three that are 64bit -
> should the 32bit device sit in the middle or can it sit off one end (ie
> extending the lower part of the bus beond the top 32bits)?
> 
> And lastly - is there somwhere I can find this information?
> 
> Many - Many thanks
> 
> cyber_spook_man

Hi,

my PCI specs are gone walking so I can't check right now. You can
buy them from www.pcisig.org.

IIRC, the tracks on your card should be routed above a continuos
power plane and must be shorter than 1 inch. The PCI clock signal
must be 1.5 inches long. All signals drive exactly one CMOS input.
I might be completely wrong.

Regards,

Iwo

Article: 31243
Subject: help for BGA ?
From: "S.JULHES" <sjulhes@free.fr>
Date: Wed, 16 May 2001 12:57:07 GMT
Links: << >>  << T >>  << A >>
Hi,

I have to use a FPGA on an industrial card ( production : 1500 per year
).
I have the following choice :
- 1 Altera's APEX 200KE in BGA
- 2 Altera's APEX 100KE in PQFP.

My main constraint is the cost and i'm wondering for the total cost of
the project :

- Is the total card surface of the BGA chip equivalent to the 2 PQFP
card surface ( due to signal dispatchment )
- Is the card fabrication more expensive due to BGA use ( process,
tools, mount, etc .... )
- Is the card's test more expensive due to BGA use ( tools, measures
etc.... )

With my client's negociated prices, the APEX 200 is 30% more expensive
than the total cost of the 2 APEX 100 !!!!

If anyone has some knowledge on BGA industrialisation !

S.J


Article: 31244
Subject: PROGRAMMABLE LOGIC SEQUENCER CORRECTIONS
From: harvey_twyman@yahoo.com (Harvey Twyman)
Date: Wed, 16 May 2001 13:00:14 +0000 (UTC)
Links: << >>  << T >>  << A >>
Thank you to all who offered feedback regarding my
original Web Page.

All your comments were justified.

The one thing I've learnt from this exercise is that
if you post to newsgroups you must expect to be
crucified if you 'do' or 'say' anything slightly
wrong.

I feel that it's unlikely that good comments are ever
made through this type of media. It's a bit like
newspapers, they print more 'bad news' than 'good' -
it sells more copies. People get more enjoyment out of
'critism' than 'praise'.

So I've taken onboard all your comments and have
revised the original Web Page at:

http://www.Twyman.org.uk/PL-Sequencer

Comments again please...

Thanks everybody.

Harvey Twyman


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

-- 
Posted from web3501.mail.yahoo.com [204.71.203.68] 
via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 31245
Subject: RE: Counter problem in Altera AHDL...
From: Valeri Serebrianski <serebr@MailAndNews.com>
Date: Wed, 16 May 2001 09:03:30 -0400
Links: << >>  << T >>  << A >>
Hi Michael,
Why you just don't use the lpm_counter megafunction?
Simple example is listed below.
--------
include "lpm_counter";

variable 
FADCNT : lpm_counter with (lpm_width=19);
RESULT[18..0] : node;

begin
FADCNT.clock=17_5MHZ;
FADCNT.aclr=not WOODGATE_RR;
FADCNT.sclr=XMTN_R63;
RESULT[18..0]=FADCNT.q[18..0];
end;

Valeri Serebrianski.

>===== Original Message From Michael Kohne <mhkohne@discordia.org> =====
>I've got a stupid problem with a counter. The code is written in
>Altera's AHDL language, and an older version of the code works just
>fine. I have the feeling that I'm doing something really stupid to
>cause this problem, and if anyone could point me in the right
>direction of a solution to it, I'd really appreciate it.
>
>The problem is that the FAD outputs seem to glitch a lot. I've only
>seen single bit glitches. Basically, the counter will do something
>like count from 1E to 1F, then 3/4 of the way until it should count to
>20, it becomes 3F. When the time comes, it then correctly becomes 20.
>The problem lies in that the rams are always enabled, so these address
>glitches cause glitches in the ram outputs, which is a BIG problem for
>the rest of our product.
>
>I've attempted adding an extra registration step after the counter
>(FADCNT_R[].clk = 17_5MHz; FADCNT_R[].d = FADCNT[].q;) but that had NO
>effect on the problem.
>
>
>As near as I can tell from the timing analysis, there shouldn't be a
>timing issue (that's why we went with the -1 version of the 10K250).
>
>Any and all help GREATLY appreciated.
>
>Thanks!
>
>
>
>
>Target is an EPF10K250ABC600-1. I've got EPC1 roms in the board, but
>I'm loading new code via a byteblaster.
>
>
>Software is MAX+plus II version 10.0 9/14/2000 (2000.09)
>I'm NOT using the quartus fitter. That is because this design has a
>very bad pin layout and the use of Cliques in the older fitter allows
>me to get the fits to meet timing much better. I have several Cliques
>defined, including one that contains all the FAD and FADCNT signals.
>
>Here's the relevant parts of the code:
>(the FAD output runs to the address lines of a set of rams. When it's
>in count mode, it's clocking pre-loaded data out of the rams).
>
>FAD[18..0] : OUTPUT;
>
>FADCNT[18..0] : DFF;
>
>FADCNT[18..0].clk = 17_5MHZ; -- 17_5MHZ is a 35 MHZ input divided
>				-- by two
>
>FADCNT[18..0].clrn = WOODGATE_RR; -- when this signal is not active,
>				-- we don't want to run
>
>IF (XMTN_R63) THEN	-- XMTN_R63 is a registered copy of an input
>   FADCNT[18..0].d = 0;
>ELSE
>   FADCNT[18..0].d = FADCNT[18..0].q + 1;
>END IF;
>
>
>
>Michael Kohne
>mhkohne@discordia.org
>3000 pound of wood moving at 300 feet per minute. Don't get in the
>way...

------------------------------------------------------------
 Get your FREE web-based e-mail and newsgroup access at:
                http://MailAndNews.com

 Create a new mailbox, or access your existing IMAP4 or
 POP3 mailbox from anywhere with just a web browser.
------------------------------------------------------------


Article: 31246
Subject: XilinxCoreLib with Renoir
From: "Jean-Pierre Gehrig" <redbull@netplus.ch>
Date: Wed, 16 May 2001 15:54:44 +0200
Links: << >>  << T >>  << A >>
I'm trying to use a dual port RAM generated by the Xilinx Core Generator for
a Spartan-II.

Does anybody knows how to create a component from the VHO file with Renoir
(I use Leonardo for synthesis)?

Thanks,

Jean-Pierre Gehrig
Design Engineer
HEVs Switzerland



Article: 31247
Subject: Re: Counter problem in Altera AHDL...
From: Michael Kohne <mhkohne@discordia.org>
Date: Wed, 16 May 2001 15:06:39 GMT
Links: << >>  << T >>  << A >>
On Wed, 16 May 2001 09:03:30 -0400, Valeri Serebrianski
<serebr@MailAndNews.com> wrote:

>Hi Michael,
>Why you just don't use the lpm_counter megafunction?
>Simple example is listed below.
>--------
>include "lpm_counter";
>
>variable 
>FADCNT : lpm_counter with (lpm_width=19);
>RESULT[18..0] : node;
>
>begin
>FADCNT.clock=17_5MHZ;
>FADCNT.aclr=not WOODGATE_RR;
>FADCNT.sclr=XMTN_R63;
>RESULT[18..0]=FADCNT.q[18..0];
>end;
>
>Valeri Serebrianski.
>
>>===== Original Message From Michael Kohne <mhkohne@discordia.org> =====
>>I've got a stupid problem with a counter. 
<snip>
Well, the code was originally written by a contractor who didn't have
much knowledge of LPM, so he didn't use the lpm functions. I have
(just a few minutes ago) converted to using an LPM counter, as a test
to see if it makes things any better.

Thanks!


Michael Kohne
mhkohne@discordia.org

Article: 31248
Subject: Ideas for Faster XILINX compilations ?
From: "Andrew Webb" <andrew.webb@uk.thalesgroup.com>
Date: Wed, 16 May 2001 16:32:47 +0100
Links: << >>  << T >>  << A >>
Dear All,

 I have been asked by the FPGA developers at my company to recommend a
suitable platform and configuration to minimise the time they have to spend
waiting for XILINX compilations. They currently have to wait around 8 hours.
We tried a P4 with RAMBUS memory, but the performance increase over a P3
wasn't that great. Any ideas ... my boss gave me this brief.

Thanks,

Andrew Webb
Thales Defence

......
Our Software
Xilinx Foundation 3.1I with SP7

Devices
Devices are xcv1000, xcv1600e-6

The Problem
Our iteration cycles can take up to 8 hours (includes our final timing
constraints). We currently use Intel PIII 800MHz to 1GHz PCs.

Our Initial Solution
Part 1
We purchased a HP Vectra 800VL which is an Intel 1.5GHz P4, 0.5GB RAM
(400MHz Front Side Bus), SCSI 160 Controller. The initial installation was a
problem but we found the fix on your Web Site (java error) and then found
that our expectation of much reduced compilation times was not met. Design 1
(See Mapping Report File) took 3 hours 18min on a PIII and 2 hours 40min on
a P4. We were hoping for much more as we were assuming the 400MHz FSB would
improve CPU to Memory operations during compilation.
We now understand that you are releasing a new version of Xilinx that will
be optimised for P4 architectures in August.

Part 2
We have since been steered towards the AMD processors, which we are testing
today.

Our Aim
We need to reduce this iteration time to allow us to make more changes to
our designs within one day. Currently we are relaxing the timing constraints
during the initial stages, but having to then place our final constraints
within the design to meet the overall system requirements. This is where the
compile time increases to 8 hours.

Our Questions
Can you advise on the compilation platforms to yield the best performance,
short and long term.
Have you any hint or tips on Operating System optimisation or choice of O.S.
I want to take a more strategic view of this issue and formulate plan for
when we begin using even bigger gate Arrays.




Article: 31249
Subject: OPEN CORES design GUIDELINES
From: "Miha Dolenc" <mihad@opencores.org>
Date: Wed, 16 May 2001 18:11:12 +0200
Links: << >>  << T >>  << A >>
Hello everyone!

    Open cores group has published a design guideline document, to help
members of the group code HDL in similar fashion. Any comments on it would
be appreciated:

http://www.opencores.org/guidelines.shtml

Anyone with experience in HDL design is welcome to comment on this, so we
can prepare a solid and good design guideline document and minimize problems
that come up with different approaches to HDL coding.
That document is important to us, since many people with different
backgrounds participate in same design, so we have to standardize HDL coding
somehow (easier simulation, implementation etc.).

Thanks for your help,
        Miha Dolenc





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