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 27400

Article: 27400
Subject: Re: Synthesizable VHDL
From: Scott Schlachter <scott.schlachter@xilinx.com>
Date: Mon, 20 Nov 2000 17:15:43 -0800
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------961C48C6CEDFAD43BCAC025D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

One of my favorite reference books for synthesizable code, for both VHDL and
Verilog is "VHDL and Verilog HDL Chip Design" by Douglas J. Smith, Doone
Publications - also known unofficially as the 'big blue meatgrinder book'.
It's particularly good if you want to compare synthesizable VHDL to
synthesizable Verilog (if you already know one, and you're trying to learn the
other, for example).  Regardless, I consider it as one of the best
beginner/intermediate level synthesis reference books out there.  There might
be something better for advanced VHDL techniques - I don't know, perhaps
someone can comment...
-Scott Schlachter

V Ram wrote:

> Hello!
>
> I have a few questions regarding synthesizing VHDL...
>
> Is there a website or document that describes what parts of VHDL
> are/aren't synthesizable? I have the Designer's Guide to VHDL (Ashenden)
> but I have no clue how synthesizable his code is...
>
> Typically the code I've written is simple enough that is has
> synthesized(MaxPlus II & FPGA Express), but I might want to use variables
> or do a few other things and I don't know what's suggested or not.
>
> My biggest complaint about Ashenden's book is that he doesn't really give
> you clues as to what design method(s) you should take if you want your
> designs to be synthesizable.
>
> Any hints, tips, website or recommended books would be nice to know about.
>
> Really any website that has code that *has* been synthesized would be
> fantastic. I know about the Leon SPARC core and the Hamburgh VHDL archive
> but lots of the models there aren't synthesizable.
>
> Thanks,
> V Ram.

--------------961C48C6CEDFAD43BCAC025D
Content-Type: text/x-vcard; charset=us-ascii;
 name="scott.schlachter.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Scott Schlachter
Content-Disposition: attachment;
 filename="scott.schlachter.vcf"

begin:vcard 
n:Schlachter;Scott
tel;work:408-879-6876
x-mozilla-html:TRUE
url:www.xilinx.com
org:Xilinx;General Products Division
adr:;;2100 Logic Drive;San Jose;CA;95124-3400;USA
version:2.1
email;internet:scott.schlachter@xilinx.com
title:Systems Engineer
fn:Scott Schlachter
end:vcard

--------------961C48C6CEDFAD43BCAC025D--


Article: 27401
Subject: Re: ANNOUNCE: Checksum and CRC Code/Article
From: Herman Oosthuysen <aerosoft@AerospaceSoftware.com>
Date: Tue, 21 Nov 2000 01:16:30 GMT
Links: << >>  << T >>  << A >>
I posted the common telecom rules of thumb in another CRC thread.  These
things can be calculated, but it is rather tedious.  I have read some
good articles in IEEE comms years ago (which is where these rules of
thumb come from), so you can search their online library for references
to CRCs.

Cheers,

Herman
http://www.AerospaceSoftware.com

Joe Durusau wrote:
> 
>         Well, in the olden days of mainframe computers, the larger IBM
> systems came with a memory that read something like 32 bits of data and
> 8 bits of crc with each memory reference.  There was a special trick
> that
> the service people did to find out if the memory controller was seeing
> (and correcting) errors.  Never did a day go by that there was not an
> error.
> Simple parity checks helped, but did not allow correction of the data.
> If the bit in question did something serious, like say "dump the air
> from
> the space station" or "reset and reboot all the flight contorl logic in
> the aircraft" the problems could be quite spectacular.  There are
> hardware
> implementations for crc in existance, for those who need speed.
> 
> I guess it just depends on how important the accuracy offthe data is.
> After
> all, in the telephone networkm if Aunt Minnie sounds a little off,
> nobody
> will likely care.  OTOH, if a missile gets launched at the wrong country
> because a bye gets exchanged with another, I suspect a lot of folks
> would
> care, at least for a short time.
> 
> Speaking only for myself,
> 
> Joe Durusua
> 
> Niall Murphy wrote:
> >
> > Dan Kotlow <dank@micrologic.com> wrote in message
> > news:3a138b05.91598579@news.ma.ultranet.com...
> > >
> > > I'm sure you get much better performance with the methods you suggest,
> > > provided that you don't count undetected errors as reducing
> > > performance.  However, if undetected errors are important in your
> > > application, then those arithmetic checks suck badly compared to real
> > > CRC.
> > >
> > > I, in particular, have the misfortune to be working with a satellite
> > > communications provider that uses the Fletcher checksum for error
> > > control.  We get corrupted data constantly.  It only takes two
> > > "well-placed" bit errors to fool the Fletcher checksum.
> > >
> > I agree with you completely, that the previous poster was misleading
> > everyone by implying that the IP checksum is as good as a CRC (and Michael's
> > articles referenced in the original post explain all that in detail). My
> > question is that I am curious if a CRC would solve your specific problem.
> > When you say that you get corrupted dataconstantly, do you mean that you get
> > data with a valid checksum, even though it has been corrupted?
> >
> > Mathematically CRC is definitly better than a checksum, I have just not come
> > across a real practical case where the difference could be identified. I
> > suspect that it is a function of how large the packets are - 16 bits as a
> > check on 100 bytes seems reasonable, but as a check on 10000 bytes seems
> > riskier to me (but I do not know if there is a simple mathematical
> > justification of that) - what is the ratio on your appication. If anyone
> > knows a recommended ratio where you should switch to CRC I would be curious.
> >     Niall Murphy (http://www.panelsoft.com)

Article: 27402
Subject: Re: Spartan 3.3V Driving 5v input tristate + pull up problem...
From: Scott Schlachter <scott.schlachter@xilinx.com>
Date: Mon, 20 Nov 2000 17:33:39 -0800
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------E45E885A1F5096C5F94BDCAC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I was wondering the same - if the ADC has a 5V CMOS level input threshhold, the
switching level should be about 2.5V.  Why use a pull-up/open drain configuration at
all?  Niel, you mentioned that it took 40ns to transition from 1V to 4V; is the ADC
switching from L->H at 4V???  Sounds a bit high... which ADC is this?
-Scott Schlachter

Ray Andraka wrote:

> I think he is using only one driver. His issue, if I'm reading this right is
> that the ADC needs to see a level higher than the 3.3v output (I don't know what
> ADC he's using), so he's using the FPGA output as an open drain to get the low
> level and a pull-up for the high.
>
> My first thought is to pick a different ADC.  There are several out there that
> provide an option for 3.3v interface and 5v Analog.  If for some reason you are
> stuck with that ADC, you might use a quickswitch as a level translator.  Those
> things get you a nearly transparent translation...propagation delay is well
> under a nanosecond.  I'm not sure Peter's suggestion of delaying the tristate
> will help or not, as I am not sure what will happen if the active output is
> externally pulled up to 5v.  I suspect it will continue on up close to 5v
> without incident as long as the protection diodes are enabled.
>
> Andy Peters wrote:
> >
> > Nial Stewart wrote:
> > >
> > > The guy who did the board I'm currently working on had a
> > > 3.3V IO spartan 2 driving (or not)  the 5V CMOS inputs
> > > on an ADC.
> > >
> > > I implemented the 'tri-state when driving high ie
> > >
> > >     signal_out <= 'Z' when (signal_internal = '1') else signal_i;
> > >
> > > with an external pull up' which allows the driven signals
> > > to reach 5V, but a couple of the lines are clocks and
> > > were taking 40nS to get from 1V -> 4V. I think this was
> > > causing problems with the DAC.
> >
> > What value of pullup resistor are you using?  Smaller = faster!
> >
> > One thing I don't understand: why are you using open-drain outputs to
> > drive a clock input?  Seems to me that you'd want to arrange your logic
> > such that one (and only one) driver clocks the ADC.
> >
> > -- a
> > ----------------------------
> > Andy Peters
> > Sr. Electrical Engineer
> > National Optical Astronomy Observatory
> > 950 N Cherry Ave
> > Tucson, AZ 85719
> > apeters (at) n o a o [dot] e d u
> >
> > "It is better to be silent and thought a fool,
> >  than to send an e-mail to the entire company
> >  and remove all doubt."
>
> --
> -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  or http://www.fpga-guru.com

--------------E45E885A1F5096C5F94BDCAC
Content-Type: text/x-vcard; charset=us-ascii;
 name="scott.schlachter.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Scott Schlachter
Content-Disposition: attachment;
 filename="scott.schlachter.vcf"

begin:vcard 
n:Schlachter;Scott
tel;work:408-879-6876
x-mozilla-html:TRUE
url:www.xilinx.com
org:Xilinx;General Products Division
adr:;;2100 Logic Drive;San Jose;CA;95124-3400;USA
version:2.1
email;internet:scott.schlachter@xilinx.com
title:Systems Engineer
fn:Scott Schlachter
end:vcard

--------------E45E885A1F5096C5F94BDCAC--


Article: 27403
Subject: Re: Spartan and XC4000 configuration
From: yuryws@my-deja.com
Date: Tue, 21 Nov 2000 03:49:53 GMT
Links: << >>  << T >>  << A >>
Express mode is supported by Spartan family and it is 8 bit parallel
mode.

-- Yury Wolf
In article <8vcf6r$1e3$1@wedge.sfu.ca>,
  "S.Ivanov" <stefan1@canada.com> wrote:
> Hello all,
>
> We have a board with 6 FPGAs. So far we have been using the XC4000
family
> for all the 6.
> The configuration is done from a 8-bit EEPROM via a daisy chain, where
the
> first device
> is in Parallel Master Mode and the rest are in Serial Slave Mode.
> Now we want to switch to Spartan devices. The Spartan devices,
however,
> don't have a
> parallel configuration mode. Since it is an existing board and we can
not
> change anything,
> I am considering the option of keeping the first device in the chain
as an
> XC4000 and
> replacing the other 5 with Spartans. Is this going to work? Is the
serial
> data stream coming
> out of the XC4000 devise compatible with the serial stream for Spartan
> devices?
>
> Thanks,
> Stefan Ivanov
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27404
Subject: Re: Long Island Verilog and VHDL people wanted!!
From: yuryws@my-deja.com
Date: Tue, 21 Nov 2000 04:01:13 GMT
Links: << >>  << T >>  << A >>
I don't think you are serious Barry.

-- Yury Wolf

In article <wl%R5.280335$4d.36048590@news02.optonline.net>,
  "Barry Schneider" <barry61s@optonline.com> wrote:
> I am presently working at a ASIC consulting company and we have a huge
> backlog of work.  We need help and will pay well.  We have a great
office
> and have very flexible hours.   We are looking for Verilog and/or VHDL
> experience.
> Synthesis and/or Mixed Signal a plus. If you are interested in a Good
Job
> e-mail me at barry61s@optonline.com
>   Hope to hear from you.
>
>                         Sincerely,
>                                         Barry
>
> PS: We have needs in:       Commack, Long Island New York,
>                                          Hazlet, New Jersey
>                                          Bethlehem, Pennsylvania.
>                                          Cherry Hill, New Jersey
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27405
Subject: Re: Spartan and XC4000 configuration
From: Philip Freidin <philip@fliptronics.com>
Date: Mon, 20 Nov 2000 22:22:57 -0800
Links: << >>  << T >>  << A >>
On Mon, 20 Nov 2000 16:27:01 -0800, "S.Ivanov" <stefan1@canada.com> wrote:
>Hello all,
>
>We have a board with 6 FPGAs. So far we have been using the XC4000 family
>for all the 6.
>The configuration is done from a 8-bit EEPROM via a daisy chain, where the
>first device
>is in Parallel Master Mode and the rest are in Serial Slave Mode.
>Now we want to switch to Spartan devices. The Spartan devices, however,
>don't have a
>parallel configuration mode. Since it is an existing board and we can not
>change anything,
>I am considering the option of keeping the first device in the chain as an
>XC4000 and
>replacing the other 5 with Spartans. Is this going to work? Is the serial
>data stream coming
>out of the XC4000 devise compatible with the serial stream for Spartan
>devices?

Yes, the bitstreams are compatible. But are you sure that you can drop
Spartans into the footprint of your existing XC4000 parts (the 5 you intend
to change). I ask, because the pinout of Spartan packages are not
identical to the XC4000E parts from which they are derived. For instance,
look at the mode pins. You say that "Since it is an existing board and
we can not change anything". I think you will have to make at least some
very minor board layout changes. Or much more ugly: rework.
>Thanks,
>Stefan Ivanov


Philip Freidin
Philip Freidin
Fliptronics

Article: 27406
Subject: HELP! Lucent ORCA datasheets needed!
From: Steve Oldridge <steveo@ece.ubc.ca>
Date: Mon, 20 Nov 2000 23:23:23 -0800
Links: << >>  << T >>  << A >>
I've been trying to access Lucent's website, in order to get datasheets
for their ORCA FPGAs.  Unfortunately for the past few weeks they've been
down (at least I can't access them)!  What I need to know specifically
is whether or not the LUTs in their logic clusters can be used as
memories.  If anyone can tell me this (or point me to a datasheet not on
Lucent's site) I'd be most appreciative.
  Thanks in Advance
      Steve

Steve Oldridge
M.A.Sc. Student (FPGA Architecture Research)
University of British Columbia
steveo@ece.ubc.ca.removethis


Article: 27407
Subject: Re: Can FPGA perform float point calculation?
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 21 Nov 2000 07:47:35 GMT
Links: << >>  << T >>  << A >>
Ben Franchuk <bfranchuk@jetnet.ab.ca> writes:

>glen herrmannsfeldt wrote:
>> 
>> If you don't need so many bits for mantissa or exponent, it might not
>> be too bad.  Multiply is big in an FPGA, either fixed or floating.
>> Divide is even worse, fixed or floating.
>> 
>> If you did it base 16 (like IBM S/360 and S/370), it would take less
>> barrel shift logic.

>But the round off errors kill you. Why not just go back to DECIMAL 
>Floating point.

Hmm.  I don't think the round-off is necessarily worse, but it is harder
to analyze.  IBM used 24 bits for a base 16 mantissa and 7 for the
characteristic.  Because the three high bits could be 0, it really is only
21 bits.  If you only expect 21 bits, but sometimes you get 24, is that bad?

If you use only 21 bits, you get three more bits for the characteristic,
but you need more bits to get the same exponent range.  Numerical analysis
people want to get every last bit they can, and this is more difficult.

The IBM double still uses a 7 bit characteristic (about 1e-78 to 7e75),
and 7 hex digits, or 53 to 56 bits.  IEEE double, is, if I remember,
53 bits, though with a larger exponent range.

I do believe that there would be some use for BCD floating point in
general purpose processors.  You need more bits to get the same precision,
though, and this probably makes it too expensive in FPGA's.

Maybe base 8 wouldn't be too far off?  I think an even power of two 
might be better for most FPGA's, though.

-- glen

Article: 27408
Subject: Re: Xilinx and Tri state I/O
From: Klaus Falser <kfalser@durst.it>
Date: Tue, 21 Nov 2000 08:04:16 GMT
Links: << >>  << T >>  << A >>
In article <3A195D6F.79D731CD@Connriver.net>,
  Hawker <Hawker@Connriver.net> wrote:
> (this may be a double post - sorry my browser is doing strange things)
>
> Hello all.
>
> I need to cost down some products that have a pile of 74LS244 and
> 74HC374s on them.  Ideally I would love to be able to use an XC9500 part
> for this.  The problem seems to be that I can't program a tri-state I/O
> in the 9500 if I understand correctly.  Seems the next step would be a
> regular Spartan, but that does not seem to have tri state outputs/inputs
> either.  This does not make sense as I thought I have seen folks use
> them for '8031 to i/o interfaces.  What am I missing.  What Xilinx Part
> (as that is the only toolset I have) would be good to use here.  There
> won't be much other logic going on - decode to 64 outputs, encode 16
> inputs and a few timers/dividers going on.  Cost is a big factor.
>
> I need a 5V part with 5V outputs not 3.3 than can dive 5v ins.  The end
> product needs to fire a pile (256) LEDs (2ma each) so I need to be able
> to sink some current as well. I assume I need to split this up into
> several small Xilinxs for current draw issues.  Hopefully each xilinx
> can fire 64 points (~150ma).
>
> Thanx.
>

You can also use the cheaper 3.3V parts to drive the LEDs from 5V.
Setting the output to high impedance switches the LED off.
The output of the CPLD will then be pulled up to 5V, but there is
not problem since they are 5 V tolerant.

Be avare that both the 5V versions and the 3V versions have TTL
levels on the inputs/outputs. The can be driven and drive exactly
the same devices.

Check the data sheet about the maximum current for the SUPPLY pins
to see how much LEDs you can drive. The currents in the single outputs
are summed up on the supply pins!

Hope this helps
    Klaus

--
Klaus Falser
Durst Phototechnik AG
I-39042 Brixen


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27409
Subject: Re: ANNOUNCE: Checksum and CRC Code/Article
From: Paul Keinanen <keinanen@sci.fi>
Date: Tue, 21 Nov 2000 10:40:03 +0200
Links: << >>  << T >>  << A >>
On Thu, 16 Nov 2000 06:53:04 -0800, Joe Durusau
<joseph.a.durusau@lmco.com> wrote:

>	Well, in the olden days of mainframe computers, the larger IBM
>systems came with a memory that read something like 32 bits of data and
>8 bits of crc with each memory reference.  There was a special trick
>that the service people did to find out if the memory controller was seeing
>(and correcting) errors.  

Are you sure that they used CRC (Cyclic Redundancy Check), since I
have never heard of anybody using CRC for error _correction_.

The PDP-11s I used, had a 32 bit memory word and 6 ECC (Error
Correction Code) bits capable on correcting a single bit error and
detecting and odd number of bit errors in the memory word. This was
some kind of Hamming ECC, definitely not CRC.

Paul


Article: 27410
Subject: Re: Rambus Reveals Plans To Collect Royalties From Chipset Makers
From: Eric Montreal <ervno_spam@sympatico.ca>
Date: Tue, 21 Nov 2000 09:21:12 GMT
Links: << >>  << T >>  << A >>
Andy Peters wrote:

>
> I guess Rambus is gonna come after my ass because I put an SDRAM
> controller into my last FPGA?
>

With memory makers, they attacked the weakest first before stepping up.

FPGA having the unique characteristic that the "infringing" circuit can be
built by much smaller entities, even individual designers unlike all other
kind of chips that are more or less "bigger guys" businesses.

I really see a risk here that they could try to "go after your ass", and others
to make them sign licences and NDA, thinking it will be a piece of cakeand
pave the way for more substantial lawsuits.

It's not only SDRAM related, they also patented an awful lot of commonly
used high speed design techniques such as clock feedback, high speed bus
or DLL.

To see the (124 at this time) patents that have been issued (do not forget that
a lot more that have been filed), go here :

http://www.delphion.com/
and type "rambus" in the search field.

here is a sample of what you'll find :
US05614855, US06125157 : Delay-locked loop circuitry for clock delay adjustment
http://www.delphion.com/details?pn=US06125157__
http://www.delphion.com/details?pn=US05614855__

http://www.delphion.com/details?pn=US06070222__
Synchronous memory device having identification register
(AFAIK this one is used against SDRam makers)

US06067592 : System having a synchronous memory device
http://www.delphion.com/details?pn=US06067592__
(roughly patents the concept of pipelined memory)

US05977798 : Low-latency small-swing clocked receiver
(this seems to apply to "gigabit" transceivers)

and more than 120 others of the same kind.

At first, they asked for royalties for their Rambus memories (normal),
then they asked for SDRAM, then DDR Sdram, now memory controllers
and processors with integrated SDRAM interface.

What's next ?
[Every known digital design technique] applied to static RAM
[Every known digital design technique] applied to Flash storage
[Every known digital design technique] applied to Processors
[Every known digital design technique] applied to network routers
[Every known digital design technique] applied to [Every possible application]

This business model, based on using a swarm of weak patents to collect a toll
on a broad range of digital circuit designs should be a reason for concern.


>
> Here's a thought: BUY MICRON MEMORY.
>

They're very litigious too, but this time, they're on the right side of it.
Buying from them is an indirect way to support this fight.

My point is that, if Rambus is successful in enforcing their swarm of patents,
others will soon follow the same litigious business model and designing a digital
device might soon become a matter of avoiding patent related trouble & litigation
or paying them skyrocketing tolls.

Eric.



Article: 27411
Subject: Re: Using FPGA as PCI target
From: John <talks4fun@yahoo.com>
Date: Tue, 21 Nov 2000 01:29:17 -0800
Links: << >>  << T >>  << A >>
Dynamic run-time reconfiguration of the PCI target is not feasible.
BIOS assigns PCI resources at startup.

But you might use "semi-dynamic" reconfiguration:
Use onboard EEPROM with enough space for two FPGA bitstreams.
First bitstream will be a PCI interface with ability to reprogram
EEPROM's upper part.
Second bitstream will be a real PCI function you want to use.
Bitstream selection could be done simply by jumper.

Interesting approach for reconfiguration is used in HOT II board
by VCC (http://www.vcc.com/Hotii.html). 

Another interesting site which can help is 
http://www.maxlock.com/products.htm
There are full VHDL source files of PCI Interface for FPGAs 

John

Article: 27412
Subject: Re: In the news
From: Eric Montreal <ervno_spam@sympatico.ca>
Date: Tue, 21 Nov 2000 09:40:45 GMT
Links: << >>  << T >>  << A >>
Andy Peters wrote:

>
> Xilinx = Rambus?
>

No, at least for one reason :

Xilinx makes products that *actually work* and relies on that
as a primary source of revenue.
Rambus relies on their lawsuits to extract a toll, that's a very
different business model.

Eric.




Article: 27413
Subject: Re: In the news
From: Magnus Homann <d0asta@licia.dtek.chalmers.se>
Date: 21 Nov 2000 10:57:01 +0100
Links: << >>  << T >>  << A >>
Neil Franklin <neil@franklin.ch.remove> writes:

> "Dines Justesen" <dcj_k@rescom.dk> writes:
> 
> > > While I could make quite a few comments on this,
> > > I think I will just give you the link:
> > >
> > >
> > >    http://www.xilinx.com/prs_rls/xilinxwin.htm
> >
> > Alteras response is here:
> >
> > http://www.altera.com/html/new/pressrel/pr_litigation1.html
> 
> Thanks for the other sides link.
> 
> Hmmm. Xilinx says Flex and all follow ups, Altera says only Flex8000
> is treatened. Anyone got any info on who is bending the truth by how
> much?

Both, a lot?

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 27414
Subject: Re: Xilinx and Tri state I/O
From: "Olaf Birkeland" <Olaf_Birkeland@coldmail.com>
Date: Tue, 21 Nov 2000 11:09:36 +0100
Links: << >>  << T >>  << A >>
"Hawker" <Hawker@Connriver.net> wrote in message
news:3A195D6F.79D731CD@Connriver.net...
> (this may be a double post - sorry my browser is doing strange things)
>
> Hello all.
>
> I need to cost down some products that have a pile of 74LS244 and
> 74HC374s on them.  Ideally I would love to be able to use an XC9500 part
> for this.  The problem seems to be that I can't program a tri-state I/O
> in the 9500 if I understand correctly.  Seems the next step would be a
> regular Spartan, but that does not seem to have tri state outputs/inputs
> either.  This does not make sense as I thought I have seen folks use
> them for '8031 to i/o interfaces.  What am I missing.  What Xilinx Part
> (as that is the only toolset I have) would be good to use here.  There
> won't be much other logic going on - decode to 64 outputs, encode 16
> inputs and a few timers/dividers going on.  Cost is a big factor.
>
> I need a 5V part with 5V outputs not 3.3 than can dive 5v ins.  The end
> product needs to fire a pile (256) LEDs (2ma each) so I need to be able
> to sink some current as well. I assume I need to split this up into
> several small Xilinxs for current draw issues.  Hopefully each xilinx
> can fire 64 points (~150ma).
>

Some comments:
* XC95xx has tristate
* The LED's could be lit by a pulldown to GND by the CPLD, thus real 5V
output is not an issue.
* Your LED's could most probably be operated on 3.3V, you'll just have to
adjust the current limiting resistors.
* If your 256 LEDs are intended for the human eye, you can most probably
time multiplex them, e.g. as a 16x16 array. Then you'll only need 32 pins to
drive them all and get into a cheaper (and only *one*) package. The only
concern here is the total current.... I'll guess the cost saving of using
one CPLD would more than pay for using some hefty 74xx244 buffers (24/48 mA
types) externally. Alternatively you can substitute the '244s for the row or
column drive with a '154 and get down to 20 CPLD pins. Some lab bench
experiments on the visual impact of 1/16th multiplex vs. frequency is
recommended though......

Regards,
- Olaf




Article: 27415
Subject: Help :asynchronous Reset has no effect
From: regal <regal@lma.cnrs-mrs.fr>
Date: Tue, 21 Nov 2000 10:22:38 +0000
Links: << >>  << T >>  << A >>
Hello,
I'm using Foundation Express 3.1i tools.
I want to implement a simple counter with a asynchronous Reset signal in
a Spartan FPGA.
This design is OK with a Virtex or Spartan II device but it's don't work
with Spartan (signal RST has no effect)  ...

I would like to know if anybody had a similar problem and what can I
do...

Is there something wrong in my code ?

Thanks,

Xavier Regal.


Here is my VHDL program :

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.ALL;

entity TEST is
  port (
    RST : in std_logic ;
    CK : in std_logic;
    CPT_OUT : out std_logic_vector(1 downto 0)
   );
 end TEST;

architecture ARCHI of TEST is

signal CPT_CK : std_logic_vector(1 downto 0); -- compteur diviseur de CK

begin

process(CK, RST) begin -- division de la frequence d'horloge par 4

 if RST = '1' then
   CPT_CK <= "00";
 elsif CK'event and CK = '1' then
   CPT_CK <= CPT_CK+1;
 end if;
end process;

CPT_OUT <= CPT_CK;
end ARCHI;


Article: 27416
Subject: Re: Schematics & VHDL
From: "Rune Baeverrud" <fpga@no.spam.iname.com>
Date: Tue, 21 Nov 2000 12:32:39 +0100
Links: << >>  << T >>  << A >>
> Thanks Edwin but I meant a program that allows me to make
> "black-boxes" out of my VHDL and then use standard primatives like NAND2,
> OR2, etc and graphically hook it up. As the other posted said one could
> make these components in Renoir and then hook it up, but that defeats the
> purpose...

I'm afraid you might have to go vendor-specific to do that. The newer tools
from Xilinx (Foundation ISE and WebPACK ISE) let you do exactly this. When
you draw a schematic in these tools, a VHDL file will be created for you
which instantiates library primitives (if you have used them in your
schematics).

Regards,
Rune Baeverrud



Article: 27417
Subject: Re: Spartan 3.3V Driving 5v input tristate + pull up problem...
From: Nial Stewart <nials@sqf.hp.com>
Date: Tue, 21 Nov 2000 13:37:13 +0000
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> I think he is using only one driver. His issue, if I'm reading this right is
> that the ADC needs to see a level higher than the 3.3v output (I don't know what
> ADC he's using), so he's using the FPGA output as an open drain to get the low
> level and a pull-up for the high.

That's correct.
 
> My first thought is to pick a different ADC.  There are several out there that
> provide an option for 3.3v interface and 5v Analog.  If for some reason you are
> stuck with that ADC, you might use a quickswitch as a level translator. 

Ray, I've had a look at the App note for these (AN-11A) and they only
seem to operate when using 5V logic with TTL input levels.

"The function of the 5v to 3V converter is to limit the voltage seen
by the 3V TTL device to acceptable levels, typically no more than
the 3.3V supply (minus) 0.5V."

This doesn't get me any further as the SpartanII (that is being
used) inputs are 5V tolerant anyway.


Does anyone know of an active 3v TTL -> 5V CMOS driver in a small
package (8 pin soic, two channel would be ideal)?


Nial.

Article: 27418
Subject: Resetting Flip-Flops in Virtex
From: "Kevin Breeding" <kevinb@xetron.com>
Date: Tue, 21 Nov 2000 09:44:14 -0500
Links: << >>  << T >>  << A >>
I am writing VHDL code for a Xilinx Virtex FPGA.  I do not have access to an
external reset signal.  How do I make sure my flip-flops are reset after
power-up?  I realize that after configuration the internal GSR signal is
high for a number of clock cycles to reset everything, but when I look at
the map.mrp file it does not show that the Startup block was instantiated.
Do I need to instantiate the Startup block in my VHDL code so that the GSR
signal is used, or are the Startup block and the GSR signal related to
different internal circuits?  If I instantiate a Startup block in my VHDL
code, do I need to specify an external reset input signal?  Or do I need to
use ROC?  Is ROC strictly for simulation so that a valid reset is generated
at the start of simulation, or does the ROC component get passed through
synthesis?  If ROC gets passed through synthesis does it become the Startup
block or GSR signal?

Best regards,
Kevin Breeding



Article: 27419
Subject: Cores for EPP
From: lkostov@my-deja.com
Date: Tue, 21 Nov 2000 15:06:49 GMT
Links: << >>  << T >>  << A >>
Hello,
I make a device with Xilinx XCS10 device for my diploma. I must
controll the device by parallel port of PC and get the result by it. Do
you know some cores of EPP interface (schematics not VHDL) which I
could use or look at them because I have some trouble to implement it
in the XCS10. When I test it by enabled buffers all the time it work
but when I connect it to Data Strobe it stop to work.

Thank you in advance!
Latchezar Kostov


Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27420
Subject: Re: Spartan 3.3V Driving 5v input tristate + pull up problem...
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 21 Nov 2000 08:16:53 -0800
Links: << >>  << T >>  << A >>
All,

It may be that there are reflections which result in 'ringing' that is messing up the
picture.  Neil thinks it is a "5 V CMOS interface issue".  It may be just bad signal
integrity, and the signal easily passes through 2.5 Vdc.  But it does so twice (or more)
on each edge!

With the tristate pull down, resistor pull up, the 40 ns edge is inviting disaster from
a noise sensitivity point of view.  Using the active pullup for part of the transistion
to a '1' may cause so much ringing due to the mis-match, the signal is again useless.

I would try a weaker IO strength output (LVTTL 6 mA is ~50 ohms), or a series resistor
at the driver (series termination) and no external pullup.

Austin

Scott Schlachter wrote:

> I was wondering the same - if the ADC has a 5V CMOS level input threshhold, the
> switching level should be about 2.5V.  Why use a pull-up/open drain configuration at
> all?  Niel, you mentioned that it took 40ns to transition from 1V to 4V; is the ADC
> switching from L->H at 4V???  Sounds a bit high... which ADC is this?
> -Scott Schlachter
>
> Ray Andraka wrote:
>
> > I think he is using only one driver. His issue, if I'm reading this right is
> > that the ADC needs to see a level higher than the 3.3v output (I don't know what
> > ADC he's using), so he's using the FPGA output as an open drain to get the low
> > level and a pull-up for the high.
> >
> > My first thought is to pick a different ADC.  There are several out there that
> > provide an option for 3.3v interface and 5v Analog.  If for some reason you are
> > stuck with that ADC, you might use a quickswitch as a level translator.  Those
> > things get you a nearly transparent translation...propagation delay is well
> > under a nanosecond.  I'm not sure Peter's suggestion of delaying the tristate
> > will help or not, as I am not sure what will happen if the active output is
> > externally pulled up to 5v.  I suspect it will continue on up close to 5v
> > without incident as long as the protection diodes are enabled.
> >
> > Andy Peters wrote:
> > >
> > > Nial Stewart wrote:
> > > >
> > > > The guy who did the board I'm currently working on had a
> > > > 3.3V IO spartan 2 driving (or not)  the 5V CMOS inputs
> > > > on an ADC.
> > > >
> > > > I implemented the 'tri-state when driving high ie
> > > >
> > > >     signal_out <= 'Z' when (signal_internal = '1') else signal_i;
> > > >
> > > > with an external pull up' which allows the driven signals
> > > > to reach 5V, but a couple of the lines are clocks and
> > > > were taking 40nS to get from 1V -> 4V. I think this was
> > > > causing problems with the DAC.
> > >
> > > What value of pullup resistor are you using?  Smaller = faster!
> > >
> > > One thing I don't understand: why are you using open-drain outputs to
> > > drive a clock input?  Seems to me that you'd want to arrange your logic
> > > such that one (and only one) driver clocks the ADC.
> > >
> > > -- a
> > > ----------------------------
> > > Andy Peters
> > > Sr. Electrical Engineer
> > > National Optical Astronomy Observatory
> > > 950 N Cherry Ave
> > > Tucson, AZ 85719
> > > apeters (at) n o a o [dot] e d u
> > >
> > > "It is better to be silent and thought a fool,
> > >  than to send an e-mail to the entire company
> > >  and remove all doubt."
> >
> > --
> > -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  or http://www.fpga-guru.com


Article: 27421
Subject: Webpack 3.2: Problem with Design Implementation
From: Roli Z. <rzi@uni.de>
Date: Tue, 21 Nov 2000 17:21:24 +0100
Links: << >>  << T >>  << A >>
I installed the Webpack 3.2 on Windows NT 4.0
If i run the Design Implementation it stops with exit code 0128
(EXEWRAP detected a return code of '128' from program 'ngdbuild.exe')

I tried it with several Example Projects.

How can i solve this problem?


Article: 27422
Subject: Low Power FPGA?
From: Steve Nordhauser <digital@nycap.rr.com>
Date: Tue, 21 Nov 2000 16:23:22 GMT
Links: << >>  << T >>  << A >>
I have a complex video processing application - wavelet or DCT
compression in an FPGA for a 1Kx1K 30 frame per second video
stream.  I need very low power consumption.  Ideally, I would like
to leave the FPGA powered down until I need it, but it would have
to be ready in under 100mSec.

I've only worked with the Xilinx FPGAs and was wondering if
someone out there with a more varied background could point me
in the right direction.   I need enough resources and speed to do
the algorithm, but at minimum power.

As an aside, anyone out there with compatible experience or can
point me towards a web site for real-time, high resolution compression?

Thanks,
Steve Nordhauser


Article: 27423
Subject: Re: HELP! Lucent ORCA datasheets needed!
From: husby@my-deja.com
Date: Tue, 21 Nov 2000 17:13:21 GMT
Links: << >>  << T >>  << A >>
Steve Oldridge <steveo@ece.ubc.ca> wrote:
> I've been trying to access Lucent's website, in order to get
> datasheets for their ORCA FPGAs.  Unfortunately for the past
> few weeks they've been down (at least I can't access them)!

In keeping with their minimalist marketing strategy, they sometimes
move their website so that only their dedicated customers know
where it is.  Currently it's at:
  http://www.lucent.com/micro/netcom/orca/


> What I need to know specifically is whether or not the
> LUTs in their logic clusters can be used as memories.
> If anyone can tell me this (or point me to a datasheet
> not on Lucent's site) I'd be most appreciative.

Yes.  Each logic block (PFU) has 8 LUTs and can be used
as a 32x4 dual-port synchronous RAM.  Note that Dual
port ram uses all the RAM bits, unlike the Xilinx parts
and Orca2, which use two 16x1 Luts to implement
a single 16x1 dual-port RAM.





Sent via Deja.com http://www.deja.com/
Before you buy.

Article: 27424
Subject: Re: Spartan and XC4000 configuration
From: "S.Ivanov" <stefan1@canada.com>
Date: Tue, 21 Nov 2000 09:33:03 -0800
Links: << >>  << T >>  << A >>
Yuri,

That's right, the Express Mode is 8-bit parallel, but it requires some logic
to
generate the addresses and the controlling signals for the EEPROM :-(
(and it is supported only by the Spartan-XL family, which is not the problem
in our case). And all the FPGAs have to be connected to the EEPROM.
The convenience of the Parallel Mode supported by the XC4000 family is, that
it
is glueless and very easy to implement.

Thanks,
Stefan

<yuryws@my-deja.com> wrote in message news:8vcrcv$kdr$1@nnrp1.deja.com...
> Express mode is supported by Spartan family and it is 8 bit parallel
> mode.
>
> -- Yury Wolf
> In article <8vcf6r$1e3$1@wedge.sfu.ca>,
>   "S.Ivanov" <stefan1@canada.com> wrote:
> > Hello all,
> >
> > We have a board with 6 FPGAs. So far we have been using the XC4000
> family
> > for all the 6.
> > The configuration is done from a 8-bit EEPROM via a daisy chain, where
> the
> > first device
> > is in Parallel Master Mode and the rest are in Serial Slave Mode.
> > Now we want to switch to Spartan devices. The Spartan devices,
> however,
> > don't have a
> > parallel configuration mode. Since it is an existing board and we can
> not
> > change anything,
> > I am considering the option of keeping the first device in the chain
> as an
> > XC4000 and
> > replacing the other 5 with Spartans. Is this going to work? Is the
> serial
> > data stream coming
> > out of the XC4000 devise compatible with the serial stream for Spartan
> > devices?
> >
> > Thanks,
> > Stefan Ivanov
> >
> >
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.





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