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 39025

Article: 39025
Subject: Re: Flex10KA vs MAX7000S
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 30 Jan 2002 08:56:05 +0000
Links: << >>  << T >>  << A >>
chrisjc31415@yahoo.co.uk (Chris Cowdery) writes:

> I've got a cut down PCI design which works nicely in a
> MAX7256SQC208-7. I have changed device to a FLEX10KA30-1 to port it to
> CardBus.
> 
> What I do not understand is why the simulation shows that the design
> on the FLEX10K part has delays of about twice that of the 7256, even
> though the flex part is a -1, and the max is a -7? Thus the timing
> becomes marginal to say the least, yet the datasheet claims PCI 33MHz
> compliance.
> 

IIRC the -7 is a pin to pin delay for the MAX parts, whereas the -1 is
the propogation delay through a LE in the FLEX parts, or somethingl
ike that.  Anyway, the arhcitectures are completely different, so the
'speed' number means something completely different.  In fact in the
FLEX parts going up a device size in the same speed grade can slow the
design down due to the longer 'wires' used in the larger parts...

> Any ideas?
> 

Wide logic is more expensive timewise in the FLEX archtecture than in
MAX chips, as the 4-LUTs need to be cascaded using the cascade chain,
whereas the MAX logic element has a larger number of inputs (can't
remember how many, its been a while since I used a MAX chip).  You
have more registers in the FLEX part so pipelining can help, but I
imagine not in this case as it's a PCI interface!

All I can suggest is using the timing analyser to find the critical
paths and see how you can optimise them.  Or go back to the 7256...

Sorry not to be more help!

Cheers,
Martin

-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 39026
Subject: Re: FPGA or Micro-controller in Lowpower designs?
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Wed, 30 Jan 2002 09:20:29 -0000
Links: << >>  << T >>  << A >>

>I don't remember the output voltage of a Li-ion battery. Is it higher
>than 3.3 volts so that a simple LDO regulator is sufficient? I seem to
>recall that the MSP430 will operate down to 1.8 volts but needs more
>like 2.7 volts to program it's internal flash. BTW, the high end
>MSP430F148/9 have 48/60 KB of Flash on chip. If your program only takes
>1 or 2 kBytes, you might be able to use the internal Flash for your
>data. But I assume you need it to be removable. 
>
>Just for my own benifit, how many mAHours can you get from a Li-ion cell
>running a device at 2.7 or 3.3 volts? You might also consider using a
>small switcher to optimize your efficiency and make the unit run when
>the cell drops below (or starts below) the operating voltage of your
>chips. They can be very small, but of course they cost a bit more than
>an LDO. 

The Li-ion battery from my digital camera (Sony) says 3.6V 4.1Wh.

Camcorders have bigger batteries which are, well bigger, and
heavier and hold more power.

NiMH AAs get a lot of use in digital cameras.  Raw lithum is
generally better (more power per pound/cell) if you are willing
to work with non-rechargable technology.

Digital cameras are nasty to batteries because of the high
current drain.  Other technologies may work better for very
low loads.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 39027
Subject: Re: configuring an FPGA from an Hard-drive with a 80c51 (Stupid idea ?)
From: Steven Derrien <sderrien@irisa.fr>
Date: Wed, 30 Jan 2002 10:33:17 +0100
Links: << >>  << T >>  << A >>


Geert Van Doorselaer wrote:

> > Our idea is to use the Hard-drive memory to store the various FPGA
> > configurations, and to use a small 32 I/O MCU (8051) to perform the FPGA
> > reconfiguration from the HDD. (the 8051 would share the IDE bus with the
> > FPGA, but they would have a mutual  exclusive use of the HDD, since the
> > MCU would only be used during reconfiguration)
>
> This means that your FPGA should contain 'code' to access your hard drive.

Absolutely !

>
> Why not assigning this job to the MCU (as it is already implemented for the
> (re)configuration of the FPGA). This will create less overhead in your FPGA.

Yes, but the interface is likely to be very slow (in don't imagine getting close
to
the ATA-5 timing (>33Mhz) with a 80C51).

> > Now we are wondering whether this idea is good or not :), we are
> > specifically concerned with :
>
> The idea itself looks challenging ... If power consumption is not a big
> issue here ... Why not?

> > - PCB layout and signal integrity problems due to the fact that the IDE
> > connection is shared between the MCU and the FPGA. For ex. would it be
> > possible to use high-speed IDE (50Mhz clock) protocols from the FPGA ?
> >
>
> Is this 50MHz clock really needed? If not, the MCU can handle this task.

It is needed, since we want to perform processing on the data stream coming from
the
hard-drive (we are building a kind of network attached storage device).

> > - Feasibility  : How difficult would it be to design and debug such a
> > system ?
>
> Less development and debug time when you don't implement the IDE interface
> on your FPGA.
>
> >
> > Any advice, comments, critics, ideas are welcome,
> >
>
> Just my thoughts ...

Thanks,

> > Thank you in advance.
> > Steven
> >
>
> You are welcome,
> Geert


Article: 39028
Subject: Re: FPGA or Micro-controller in Lowpower designs?
From: "Arash Salarian" <arash.salarian@epfl.ch>
Date: Wed, 30 Jan 2002 11:07:30 +0100
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3C575644.364D6C8F@yahoo.com...
> Arash Salarian wrote:
> >
> > First of all, thank you all for your answers and help.
> >
> > "Ulf Samuelsson" <ulf@atmel.REMOVE.com> wrote in message
> > news:CYu58.6963$O5.17299@nntpserver.swip.net...
> > > > > I'm starting a new design in which I'm using a multi-channel A/D
with
> > a
> > > low
> > > > > sampling-rate and Flash memory for the storage and the system is
going
> > > to be
> > > > > powered by battery. In this stage, I'm not yet sure if using a
FPGA
> > > would be
> > > > > wise, as I'm very concerned with the power consumption. The gate
count
> > > of
> > >
> > > You need to tighter specify what your requirements
> > > How much data?
> > I'm going to use 4 channels of A/D at 200Hz, but only to store 3 of them
> > (one is used to monitor the battery). Data is stored on a Flash,
MultiMedia
> > Card (i.e. SPI interface...) with 64+Mbytes. That means the the system
> > should be able to function over 15 hours by using a small Litium-Ion
> > battery.
>
> I don't remember the output voltage of a Li-ion battery. Is it higher
> than 3.3 volts so that a simple LDO regulator is sufficient? I seem to
> recall that the MSP430 will operate down to 1.8 volts but needs more
> like 2.7 volts to program it's internal flash. BTW, the high end
> MSP430F148/9 have 48/60 KB of Flash on chip. If your program only takes
> 1 or 2 kBytes, you might be able to use the internal Flash for your
> data. But I assume you need it to be removable.
>
> Just for my own benifit, how many mAHours can you get from a Li-ion cell
> running a device at 2.7 or 3.3 volts? You might also consider using a
> small switcher to optimize your efficiency and make the unit run when
> the cell drops below (or starts below) the operating voltage of your
> chips. They can be very small, but of course they cost a bit more than
> an LDO.

I'm considering using a Li-ion battery from Renata (ICP633027) wich is small
is size (27x30x6.3 mm) and has a 300mAh capacity. The voltage is between 4.1
to 2.75 over the dicharge period and I guess although the 4.1v is more than
the recommened value for the MCU, yet as it's within the absolute maximum
range, would be OK. Well I'm not sure if this is a good practice, an have to
investigate more as omitting the LDO is so nice but the effect of running
the device out if it's recomended rating for a long period is not that
beautiful...

Anyway, I'm going to use one channel of the A/D to monitor the battery
level, so switching the LDO on a certian point of the discharge curve is an
option but all this means area and weight and I'm too conservative about
them in this design..

>
> > > How often  do you want to store it.
> > Interface to the MultiMedia card is packet based, so data is going to be
> > soted in packets of 512 bytes....
> >
> > > Resolution/speed of A/D.
> > 12 bit A/D with 200Hz sampling rate.
>
> This is a very low performance task. If you don't need high timing
> resolution, you can get away with a 32 kHz clock on either the MCU or
> the FPGA. But Jim's idea of running at a higher clock speed while
> writing to the Flash card is good. The Flash card can be powered down
> between writes saving a lot of power.
>
> If you use an FPGA, you will need an external ADC (which can be as
> simple as some high tolerance resistors and a comparator depending on
> how consistent the output drive voltage is) . But at a 200 Hz sample
> rate, this can be powered down between samples as well. You will also
> need an external oscillator. I don't have a part number for you, but I
> am sure there are small, very low power 32 kHz devices available either
> with or without a crystal included.
>
> But this is starting to make the MCU look cheap in comparison.
>
> > > An FPGA does not have an ADC internally, so you need to add power for
> > that.
> > >
> > > The Atmel AVR will draw less power than the Atmel 8051.
> > > I'd try out with an ATmega8, which has internal R/C oscillator and
power
> > > down mode.
>
> This sounds like a good idea. The MSP430 has that as well as do many
> chips. But certainly the Atmel devices have a lot to offer.
>
> > > --
> > > Best Regards
> > > Ulf at atmel dot com
> > > These comments are intended to be my own opinion and they
> > > may, or may not be shared by my employer, Atmel Sweden.
> > >
> >
> > Btw Ulf, What's your idea about MSP430 series suggested by Jim
Granville?
>
> Ulf is an Atmel representative, so it is not likely he will say much
> about a TI product. He would be ill advised to say anything good for the
> sake of his job and won't say anything bad for being thought of as
> badmouthing the competition.  :)  Even if we ask...
>
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX



Article: 39029
Subject: RLOCS with combinatorial logic
From: newman5382@aol.com (newman)
Date: 30 Jan 2002 04:44:16 -0800
Links: << >>  << T >>  << A >>
I've got a module that has a bunch of combinatorial logic that is
instantiated via generate statements, and also has two synchronization
registers.  For various reasons, that I cannot go into, I don't want
the synthesizer to optimize out redundant logic, so I put a dont_touch
attribute on the module ... so far so good.  When I look in the FPGA
editor, it looks like the combinatorial logic has been compacted into
the LUT's, so there does not appear to be a 1:1 correspondence between
the instantiated combinatorial logic and the LUT's.
What I want to do, but don't know how best to proceed, is to be able
to locate this module to a specific area of the FPGA.

My first preference would be to put attributes or something in the
VHDL to do this.
My second preference would be to use the UCF if possible.
My third preference is to use the floorplanner or whatever.

I currently am using FPGA Express, but would be willing to go through
the hassle of sharing a dongle with my co-workers if Synplicity gets
me there via the VHDL approach.

Thanks for taking the time to read about my dilemma.

Newman

Article: 39030
Subject: Re: The LUT puzzle, Iam on the way
From: Ray Andraka <ray@andraka.com>
Date: Wed, 30 Jan 2002 13:46:10 GMT
Links: << >>  << T >>  << A >>
Exactly.  Beats the heck out of boolean analysis to figure out how many cells it
will occupy.  I remember using the Atmel 6K extensively for bit serial stuff in
the early 90's (see my FIR filter paper from '92).  With that device you had to
become best of friends with deMorgan, and you spent an inordinate amount of time
doing logic analysis to get a fast compact design.  For it's time though, the
device could be extremetly fast, and it had more flip-flops than any other FPGA by
a significant margin.

Peter Alfke wrote:

> Whether it is 65,000 or only a few thousand, a LUT is a very versatile tool. I
> still remember my enthusiasm when, arriving here at Xilinx, I could draw a
> circle around any piece of logic with 4 inputs + one output ( and no flip-flop
> inside) and I could say: "Fits into one LUT, I don't care how, let's go on".
> Gets your mind off the nitty-gritty :-)
>
> Peter Alfke

--
--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: 39031
Subject: Java or bytecode processors??
From: "Scott Thibault" <thibault@gmvhdl.com>
Date: Wed, 30 Jan 2002 08:54:55 -0500
Links: << >>  << T >>  << A >>
What are you're thoughts about Java and other bytecode processors?

Is anyone out there using them?

We are developing a bytecode processor for a high-level language (i.e. NOT
Java), and I'm curious as to what people think of these things.


--Scott Thibault
Green Mountain Computing Systems, Inc.
http://www.gmvhdl.com




Article: 39032
Subject: Re: configuring an FPGA from an Hard-drive with a 80c51 (Stupid idea ?)
From: Iwo Mergler <Iwo.mergler@soton.sc.philips.com>
Date: Wed, 30 Jan 2002 14:36:16 +0000
Links: << >>  << T >>  << A >>
Steven Derrien wrote:
> 
> Hello,
> 
> This post is just for submitting an idea to those who are familiar with
> embedded system design, in order to get some feed-back (with respect to
> feasibility, cost, usefulness and so on?).
> 
> The basic idea is the following :
> 
> We want to design a reconfigurable SoC, which will be connected to an
> IDE hard-drive,  used by the application running on the SoC. One of the
> key point, is that we need to perform dynamic reconfiguration of the
> FPGA.
> 
> Our idea is to use the Hard-drive memory to store the various FPGA
> configurations, and to use a small 32 I/O MCU (8051) to perform the FPGA
> reconfiguration from the HDD. (the 8051 would share the IDE bus with the
> FPGA, but they would have a mutual  exclusive use of the HDD, since the
> MCU would only be used during reconfiguration)
> 
> Since the FPGA should be a relatively big Virtex/Spartan-II, and since a
> large density configuration EEPROMs (several Mbits) are quite expensive
> compared to a small MCU, we feel that this could be a nice way to reduce
> the total system cost.
> 
> Now we are wondering whether this idea is good or not :), we are
> specifically concerned with :
> 
> - PCB layout and signal integrity problems due to the fact that the IDE
> connection is shared between the MCU and the FPGA. For ex. would it be
> possible to use high-speed IDE (50Mhz clock) protocols from the FPGA ?

A standard IDE interface supports 2 devices on the cable, that is, 2 cmos
inputs per signal. I have the PCB of an old IDE drive in front of me and
it looks like they use a series termination of 330 Ohm between the cable
and the ASIC.

My suggestion is to have a close look at a modern harddrive and mime that
circuitry for your microcontroller. Then you connect the controller instead
of the second disk. This way, the micro will load the signals like a slave
disk does. For the transfer speeds you are going to achieve with the micro,
the weird cable shape shouldn't matter.

    #============#=====#
IDE PORT       HDD1  HDD0

    #============#=====#
  FPGA          uC    HDD

> 
> - Reliability   : since the hard-drive will be used for both read and
> write operation during the application, we must ensure that some part of
> the HDD storage is locked (to guarantee that the configurations are not
> overwritten by mistake)

I don't think there is an easy way to 'lock' part of the disk without changing
the disk's firmware. If you can control the IDE IP in your FPGA, you could
ignore write requests for a certain block range...

> 
> - Feasibility  : How difficult would it be to design and debug such a
> system ?

Not having done it myself - it shouldn't be too hard, as long as you have a 
good logic analyser... ;^)

Have a nice day,

Iwo

Article: 39033
Subject: Re: Dont care simulation
From: Ray Andraka <ray@andraka.com>
Date: Wed, 30 Jan 2002 15:31:01 GMT
Links: << >>  << T >>  << A >>
synthesis generally doesn't allow don't cares as a mask to compares.  Instead
use the std_match function in ieee.numeric_std.

Falk Brunner wrote:

> Hello everyone,
>
> Iam using ISE & modelsim for a few weeks, things are getting better ;-) But
> doing a plain functional simulation of comparators using dont cares does not
> work. Yes, there is a warning in the docu of ISE about the use of dont
> cares, but is thereno workaround for this?? Can I write my own resolution
> function to make a dont care really dont care?Anyone has done this before
> and got some code?
>
> --
> Regards
> 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: 39034
Subject: Re: Spartan II power-up current - again
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 30 Jan 2002 07:31:12 -0800
Links: << >>  << T >>  << A >>
Rick,

True, the I grade improvement is smaller than the C grade improvement.

Kick starting that 'bike on those cold -40C mornings is hell.

Austin

rickman wrote:

> Tim wrote:
> >
> > Sorry to return to this topic yet again...
> >
> > XAPP450/451 show the SpartanII power-up current requirement as
> > 500mA for _all_ parts, provided the temperature requirements
> > are met.
> >
> > However, I have a distant recollection that someone (Austin?)
> > has at one time posted that the smaller parts need less than
> > this?  Any ideas on the slope of the curve from the 2S15
> > to the 2S200?
> >
> > I am particularly interested in the 2S30.
>
> I'm not a Xilinx rep, but I have had a couple of conversations with Kim
> Goldblatt about this. Basically, they are very confident that they will
> be able to reduce the curve somewhat, but I seem to recall that the
> improvement was not large. But that may be due to the chip I was asking
> about, the XC2S50, IIRC. This device was said to be expected to pass 1.5
> Amp at industrial temps vs. 2 Amps in the data sheet. Better for sure,
> but not a large improvement.
>
> But you should contact Kim directly about it. He is the expert. :)
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 39035
Subject: Re: Books on DSP
From: Ray Andraka <ray@andraka.com>
Date: Wed, 30 Jan 2002 16:00:06 GMT
Links: << >>  << T >>  << A >>
Thanks.

I posted my review comments from the earlier NG post as well as my comments to an amazon review.
Thanks for the suggestion.

Tom Burgess wrote:

> Thanks! - This is much more like it - Your contents listing would make
> a useful review comment for other prospective buyers since Amazon
> didn't provide ANY detailed info, hence my visit to the competition.
> You can expect your kickback from my purchase whenever Amazon gets
> around to it :)
>
> regards, tom
>
> Ray Andraka wrote:
> >
> > Looks like they truncated the table of contents.  The chapters are:
> >
> > 1. Intro, which goes over FPGA architectures, 25 pages
> >
> > 2. Computer arithmetic.  Covers computer arithmetic from the slant of hardware.  Includes
> > distributed arithmetic and cordic discussion, 46 pages,
> >
> > 3. FIR filters 34 pages
> >
> > 4. IIR filters 24 pages
> >
> > 5. Multirate signal processing -- decimation &interpolation, polyphase decomp, CIC filters,
> > Multistage decimators, Frequency sampling, filterbanks, wavelets.  59 pages
> >
> > 6.  Fourier Transforms -- 42 pages
> >
> > 7. Advanced topics  -- Rectangular and number theoretic transforms, error control and
> > cryptography, modulation & demodulation --76 pages
> >
> > 8 . references and source code 76 pages
> >
> > If you decide to buy this book please use this link:
> > http://www.amazon.com/exec/obidos/ASIN/3540413413/andraka/102-6110898-2675311
> > or go through the link on my website bookstore.  The sales commision I get helps to support
> > the website.  Thanks.
> >
> > Tom Burgess wrote:
> >
> > > From the table of contents (found on http://www.barnesandnoble.com) it appears that
> > > basic arithmetic, MACs, and SOPs take up the first 66 pages, then there's about 270
> > > pages on computation of special functions using Cordic, and it ends with about 90 pages
> > > of references and source code. Is this an accurate description of the contents?
> > >
> > > It looks useful to me as I am interested in practical Cordic details and can always use
> > > good HDL examples, but I wonder if someone hoping for a more comprehensive treatment of
> > > DSP with FPGAs would be disappointed.
> > >
>
> --
> Tom Burgess
> Digital Engineer
> Dominion Radio Astrophysical Observatory
> P.O. Box 248, Penticton, B.C.
> Canada V2A 6K3

--
--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: 39036
Subject: Re: function synthesis.
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Wed, 30 Jan 2002 16:38:02 -0000
Links: << >>  << T >>  << A >>

"Sudip Saha" wrote

> I want to know about synthesis of a function package.
> I have a design(in VHDL) which includes a file where I have declared three
functions.
> In design I am using only two functions. When I am synthesizing I am getting a
certain percentage of device utilization. What I want to know, does this include
the unused function also or is it optimized since I am not calling this function
any time in design?

Unused functions are not included.  Think of a VHDL function
as a macro definition.

comp.lang.vhdl is the place for VHDL queries.






Article: 39037
Subject: Re: Flex10KA vs MAX7000S
From: chrisjc31415@yahoo.co.uk (Chris Cowdery)
Date: 30 Jan 2002 08:59:00 -0800
Links: << >>  << T >>  << A >>
Kevin Brace <ihatespamkevinbraceusenet@ihatespamhotmail.com> wrote in message news:<a3809f$aau$1@newsreader.mailgate.org>...
> Chris Cowdery wrote:
> > 
> > I've got a cut down PCI design which works nicely in a
> > MAX7256SQC208-7. I have changed device to a FLEX10KA30-1 to port it to
> > CardBus.
> > 
> 
>         Why use FLEX 10KA?
> If you want to stick with Altera parts, why not use FLEX 10KE or ACEX
> 1K?

Mostly because I've got a drawer full, and on paper they look like
they will support a PCI core. Also, 10KE won't drive a 5V TTL part,
and I suspect ACEX is the same.
 
>         It looks like for Altera FLEX FPGAs (Altera ridiculously calls
> it CPLDs), a device with a smaller speed grade number is a faster part.
> You may want to download FLEX 10KA datasheet to verify that.
> PCI compliance means that it is electrically compatible with PCI, but it
> doesn't in any way guarantee that your design (your PCI IP core) will
> meet 33MHz PCI timings.
>         It sounds like you didn't buy your PCI IP core from Altera, so
> you can make modifications to it.

I can.

> I think the hardest part of 33MHz PCI design is meeting Tsu < 7ns setup
> time requirement, and since FLEX 10KE or ACEX 1K are faster devices,
> they will fare better in terms of meeting Tsu, but even on those
> devices, you may still have to do manual floorplanning.
> What I learned from my experience of trying to get my PCI IP core to
> meet 33MHz PCI setup timings of Tsu < 7ns is that a signal path starting
> from an unregistered input (a raw input) going through several levels of
> LUT to an output FF or a tri-state buffer control FF often tends to be
> the part that doesn't meet the setup timings.
> Yes, such a signal path I described is not taking advantage of
> registering inputs, but in PCI, it is not always possible to use
> registered inputs.
> For example, when a PCI target is asserting STOP#, but waiting for the
> initiator to deassert FRAME# so that AD[31:0] can be tri-stated
> immediately during a target read cycle.
> Registered version of FRAME# cannot be used in this case.
> For 4-input LUT-based FPGAs, from my own experience, the levels of LUT
> should be kept at or below 3 levels as much as possible.
> In target part of a PCI IP core, signal paths starting from FRAME# and
> IRDY# going towards AD[31:0] often tends to be timing critical.
> That path is the most I had problems with my own design because the
> routing distance was fairly long, so I couldn't have too much LUT
> delays.
> Keeping the levels of LUT to 3 for such a path was pretty tough, but I
> did it through simplifying my Verilog RTL code.
> If the code is simple, it might be possible to implement such a path in
> 2 levels of LUT.
>         If your PCI IP core's parity generator was designed for a CPLD
> (a wide product term-based device) in mind, you may need to redesign it
> a little bit with a 4-input LUT-based FPGA's architecture in mind.
> I am not an expert in arithmetic, but I heard that a parity of 36-bit
> can be computed with carry chain logic or with combinational logic
> (LUT).

Parity isn't a problem hopefully - I will ignore incoming parity,
and for outgoing parity, I pregenerate it and store it along with
the registers, effectively a 33bit register. You get a clock period
to calculate it whilst the address is being latched.

I am using the Quartus fitter - free license at the moment, which
doesn't support timing driven fitting. If I get the full version,
is it smart enough to give me a working design if I tell it about
Tsu for example?

Thanks,

Chris.

Article: 39038
(removed)


Article: 39039
Subject: Re: 18bit counter
From: "Arash Salarian" <arash.salarian@epfl.ch>
Date: Wed, 30 Jan 2002 18:48:28 +0100
Links: << >>  << T >>  << A >>

"Davis Moore" <davis.moore@xilinx.com> wrote in message
news:3C571986.3BA5959F@ieeeNOSPAM.org...
> Muzaffer Kal wrote:
>
> >
> > > else
> > >  counter<=counter;
> > >end
> >
> > It is OK except you don't need the final else block. counter remembers
> > its value when there are no events which change it.
> >
>
> That depends on what synthesis tool is being used. In earlier
> versions of FPGA Express (I haven't used it in a while, so I don't know
> if this still applies) an undefined state would cause a latch to be
inferred.
> For example, if the default: option was not provided in a case statement,
> a latch would be inferred.

This is not exactly like this. That rule is for desing of combinational
circuits and here, infering a "register" is excatly what we need...

>
> When I learned Verilog, we were taught the importance of making sure that
> all states were defined - don't let the synthesis tool guess
> what to do in the case of an undefined state.
>
> --
> Davis Moore
>



Article: 39040
Subject: Re: function synthesis.
From: Ray Andraka <ray@andraka.com>
Date: Wed, 30 Jan 2002 18:03:31 GMT
Links: << >>  << T >>  << A >>
No, only what is used is included in the design, in fact if you have unused outputs in your design, the synthesizer and/or the mapper will optimize out all the logic that only affects the unused outputs unless you take extraordinary steps to prevent it.

Sudip Saha wrote:

> Hi,
>
> I want to know about synthesis of a function package.
> I have a design(in VHDL) which includes a file where I have declared three functions.
> In design I am using only two functions. When I am synthesizing I am getting a certain percentage of device utilization. What I want to know, does this include the unused function also or is it optimized since I am not calling this function any time in design?
>
> Waiting for reply.

--
--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: 39041
Subject: Re: Java or bytecode processors??
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Wed, 30 Jan 2002 18:03:54 -0000
Links: << >>  << T >>  << A >>
>We are developing a bytecode processor for a high-level language (i.e. NOT
>Java), and I'm curious as to what people think of these things.

It's a great way to save memory but you pay for it in decoding
time/resources.  Memory is cheap these days.

Do you have a lot of code?

Compare with a RISC type system, or an even wider instruction
as used in (old) microcoded machines.  FPGAs can do many things
in parallel.  It's harder to take advantage of that if you
are starting from an instruction set that thinks you have a
single ALU.

Another potential advantage is that you might be able to
get an off-the-shelf programming environment if you pick
a byte code like Java that many other people are using.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 39042
Subject: Re: Dynamic Reconfiguration of single Xilinx FPGA
From: "Steve Casselman" <sc@vcc.com>
Date: Wed, 30 Jan 2002 18:17:47 GMT
Links: << >>  << T >>  << A >>
The Hot 2 system works this way. You just route a I/O to the program pin
(make sure you pull it up and come up tristated). 300ns after you drive the
pin low you force the internal state machine into the "clear memory" state
and then your device will be reset. You have to have some way to reprogram
it from there. I have a little xc9500 that looks at all the signals and
starts to feed the fpga a configuration when it want to reboot (either from
a flash or a static ram).


Steve


"Fong Chii Biao" <ericfcb@tm.net.my> wrote in message
news:3c50130f_1@news.tm.net.my...
> Hi, i really need help bout this, as i worked for this for a week, no
result
> turns out.
> first, any one ever try reconfigure Xilinx FPGA using the chip itself?
(i'm
> using a single XC4010XL)
>
> the problem is.. when i connect the user I/O to the /program pin, the
> configuration can't even complete at power start up..
> when i disconnect the I/O .. the configuration working pretty well.. whats
> the solution for this?
>
> anyone, anyone at all, who has any idea, ple reply to me, thnaks
>
> chiibiao
>
>



Article: 39043
Subject: Re: Spartan II power-up current - again
From: "Deli Geng (David)" <deli.geng@ncl.ac.uk>
Date: Wed, 30 Jan 2002 18:21:24 -0000
Links: << >>  << T >>  << A >>
>
> I'm not a Xilinx rep, but I have had a couple of conversations with Kim
> Goldblatt about this. Basically, they are very confident that they will
> be able to reduce the curve somewhat, but I seem to recall that the
> improvement was not large. But that may be due to the chip I was asking
> about, the XC2S50, IIRC. This device was said to be expected to pass 1.5
> Amp at industrial temps vs. 2 Amps in the data sheet. Better for sure,
> but not a large improvement.
>

Wow!!! So big current. How about its working current?



Article: 39044
Subject: 9 or 8 bits for image processing ?
From: "Hristo Stevic" <hristostev@yahoo.com>
Date: Wed, 30 Jan 2002 18:22:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hello,

for image processing applications, having gray scale of 255. the pixel
values go from 0 to 255, so i need 9 bits to represent them in 2's
compliment...

so why the authors use 8 bits instead? do they suppose that the dynamic
is half?


-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 39045
Subject: Re: 9 or 8 bits for image processing ?
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Wed, 30 Jan 2002 19:49:55 +0100
Links: << >>  << T >>  << A >>
"Hristo Stevic" <hristostev@yahoo.com> schrieb im Newsbeitrag
news:0fac03ce0a49908fa1e14106e8ce01fd.52609@mygate.mailgate.org...

> for image processing applications, having gray scale of 255. the pixel
> values go from 0 to 255, so i need 9 bits to represent them in 2's
> compliment...

Why do you need 2's complement? Is there negative brightness?? (Black holes?
;-))

--
MfG
Falk





Article: 39046
Subject: Re: MSP430 + Xilinx via JTAG
From: "Elizabeth D. Rather" <erather@forth.com>
Date: Wed, 30 Jan 2002 19:07:58 GMT
Links: << >>  << T >>  << A >>
DG_1 wrote:
> 
> > I have also ordered the Flash
> > Emulation Tool, so I will be able to check it out myself in a few days.
> > I belive this includes the same emulation HW/SW are the IAR toolset. It
> > is just limited in program size.
> Well, MSP430 comes _only_ with IAR's tool set. Smaller (free) version
> is called KickStart but essentially it's a stripped-down version of their
> IAR Workbench where assembler is full, but C compiler can generate only
> up to 2K of binary code. Full IAR Workbench costs $2500.
> Recently I hears over Atmel mailer-list that ImageCraft Inc is preparing
> their ICC, a C compile, to be ported onto MSP430. Well, will see..
> That emulator you were talking about is probably a Eval Board with just a
> JTAG emulator, a nice small package of QFP socket on a  small 3x3" PCB
> with a JTAG connector. The "real" emulator, according to TI supprt, costs
> 'about' $3000.

The CD that comes with the FET also includes information about the
SwiftX
development system, including a link to download a free trial version
(also
limited in program size).  SwiftX is available for only $450, including
a royalty-free multitasking kernel, library of several hundred
functions,
full support for low-power mode, etc.  The HLL is Forth, but assembler
is also supported. 

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310-491-3356
5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Article: 39047
Subject: Re: 9 or 8 bits for image processing ?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 30 Jan 2002 19:10:53 GMT
Links: << >>  << T >>  << A >>
Your grey scale never goes negative, so that 9th bit is always 0.  Use
unsigned arithmetic instead.  Note that if your processing can produce
negative values, you'll probably want to clamp it so that it doesn't
over/underflow the 8 bits.

Hristo Stevic wrote:

> Hello,
>
> for image processing applications, having gray scale of 255. the pixel
> values go from 0 to 255, so i need 9 bits to represent them in 2's
> compliment...
>
> so why the authors use 8 bits instead? do they suppose that the dynamic
> is half?
>
> --
> Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

--
--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: 39048
Subject: Re: Memory Question on Virtex
From: Tom Burgess <tom.burgess@nrc.ca>
Date: Wed, 30 Jan 2002 11:23:20 -0800
Links: << >>  << T >>  << A >>
I'll have to let others answer questions 1-3 but re #4, the answer depends
on whether you can arrange the tables that you are selecting so that each
starts at a nice binary offset in the longer BlockROM, not worrying about
"wasted" memory. If not, you could use a more complicated addressing scheme,
for example a small ROM containing pointers into the BlockROM (like an array
of index registers) and an adder to compute the final indexed address. But
if multiplexing the outputs of separate ROMs will fit and is fast enough, go
for it - it's a lot simpler. I have assumed that dynamically reconfiguring
the part for each table is not an option.

regards, tom

Antonio wrote:
> 
> Buongiorno Cher,
> I hope you will excuse me but I've some other questions :
> 1) When I choose to fit in a ROM using the case, I see in FPGA Editor
> that everything is well ordered but inside CLB, does this means that
> the design is slower and the routing more difficult, in practice,
> what's the difference between the case that the synthesizer discover
> the ROM and the case it does not discover it ??
> 
> 2) Why for RAM is required the clock and not for ROM (I know it's a
> stupid question but I don't know the answer)
> 
> 3) Have sense a ROM with a clock port ??
> 
> 4) Do you suggest to use a blockram for each block of memory or a
> blockram for all three block of memory in the case the dimension of
> the three blocks isn't equal ??
> 
>  Thanks                                 Antonio

-- 
Tom Burgess 
Digital Engineer
National Research Council of Canada
Herzberg Institute of Astrophysics
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3

Email:        tom.burgess@nrc.ca
Office:       (250) 490-4360 
Switch Board: (250) 493-2277
Fax:          (250) 493-7767

Article: 39049
Subject: Re: glitchless clock enable/disable in spartanII
From: Philip Freidin <philip@fliptronics.com>
Date: Wed, 30 Jan 2002 19:34:00 GMT
Links: << >>  << T >>  << A >>
On Tue, 29 Jan 2002 05:52:47 GMT, Peter Alfke <palfke@earthlink.net> wrote:
>
>My sugestion is to build any counter you want, synchronous or ripple, but have
>a one-bit prescaler toggle-flip-flop generate the clock.

So the clock is divided by 2 in the prescaler, and the Q is the clock
to the rest of the counter (via a BUFG, if it is a synchronous counter, or
nothing special if it is a ripple counter).

>This prescaler must
>use the Xilinx CE feature, which really is a multiplexer in the D input.

Right.

>Since CE changes asynchronously, but does not affect the clock, you never get
>a runt clock pulse, but you might ( once in a blue moon) get a longer Q
>delay.    It will be many thousands (millions?) of years between the worst
>happening, when this extra metastable delay swallows one incoming clock tick.
>
>Peter Alfke, Xilinx Applications
>==================================

Tragically, I disagree.

The asynchronous CE signal is just as bad to a FF as an asynchronous D
signal. The FF can go metastable, and you can get runt low or high
pulses from the FF. Since this feeds your follow on counter as its
clock, the results will be sub-optimal.

The only safe way to use the CE is with a synchronous signal, so the
asynchronous control signal should be passed through a multi stage
synchronizer, before being presented to the CE pin.


Philip Freidin



Philip Freidin
Fliptronics



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