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 56475

Article: 56475
Subject: Re: An FPGA is flying to Mars
From: rk <stellare@nospamplease.erols.com>
Date: 6 Jun 2003 03:15:27 GMT
Links: << >>  << T >>  << A >>
Well, the FPGA on MGS altimeter worked fine (knock on wood, that one was 
mine), was done 100% in schematic, and the scientists were quite happy 
with the results.

Interestingly, most failures involve a series of things going wrong or 
things that could have prevented it.  And most of them you can figure 
out exactly what went wrong, or narrow it down quite well, even without 
retrieving the device.  That is a pretty surprising result.

The one with the cover blowing off was neither act of God or VHDL.  Or 
Verilog.  A design oops with the FPGA application, a design oops with 
the crystal oscillator application, a test oops, system design oops, 
test equipment oops, test results analysis oops, another test equipment 
oops, a paperwork oops, a review oops, another review oops, and perhaps 
a few more oopses all tied in together.  But that many oopses isn't as 
hard to have come together as one might think.    These are not 
forgiving applications which make many of us paranoided.

And I agree, much of the reliability of FPGA devices as seen by the 
system is out of the hands and control of the manufacturer (one 
manufacturer did a nice paper on exactly that about two years ago).  But 
the manufacturer can do things to influence how their parts are used and 
used successfully.  Publish metastable state numbers.  Over temperature 
and voltage.  Good, predictable, controlled turn-on sequences.  Clear 
documentation that is not confusing.  No power squencing restrictions.  
Easy to meet power-on slew rate requirements.  Reasonable input signal 
slew rate requirements.  Good noise margin on the inputs, perhaps with a 
bit more hysteresis.  Good static timing analysis tools that give 
trusted bounded answers (both min and max) with adequate margin.  
Eliminate quirks and other gotchas that result in many users making 
common errors.  Control ground bounce.  Good control on outputs for good 
signal integrity.  ...  Just a few of the things that I consider 
important.

Cheers,

-- rk


Austin Lesea wrote:

> rk,
> 
> One thing that one manufacturer learned the hard way awhile ago was
> that if you brag about having your part on the spacecraft before
> the mission, and the mission does not go well (ie the hatches blow
> off too soon, it goes out of control, and the payload is lost), you
> might suddenly not want a lot of attention on whose part it was
> that was controlling the hatches..... 
> 
> The problem may have nothing to do with the part.  It may have been
> an "act of God" or a design flaw (so who reviewed the VHDL?).  The
> problem might have been present before launch, and no one
> understood what the test results meant.  (Oh, those little lights
> mean that the hatches blow off now?)  Who is to say?  It isn't like
> you have anything left that you can do failure analysis on.....or
> you can get an RMA. 
> 
> So, when it lands (flys, images, etc) then the bragging might
> start.  Before that, we are all a little gun shy after some
> spectacularly bad goofs.....that may, or may not have had anything
> to do with the underlying technology that we provide.
> 
> A successful mission depends on a massive amount of stuff going
> right, and absolutely nothing going wrong.  Very little of which
> actually falls under the manufacturers control at all.
> 
> Austin
> 
> rk wrote:
> 
>> Mike Butts wrote:
>>
>> > The May 2003 issue of IEEE Spectrum has a nifty and
>> > detailed article on the exciting British Beagle 2
>> > lander hitching a ride on ESA's Mars Express orbiter, set to
>> > launch soon and arrive in December. 
>> >
>> > Its robotic arm carries a bunch of instruments and
>> > other devices.  "Discrete electronic interfaces
>> > between each instrument and the lander would have
>> > been complex to build and heavy as well.  So the
>> > PAW uses a single interface with a field-programmable
>> > gate array that can reconfigure itself to match each
>> > instrument's needs."
>> >
>> > Excellent!  One of you must be able to tell us more.
>> > Who's the clever designer?  Who's the lucky vendor?
>> > What device?  Rad-hard?  Fault-tolerant?  Designed
>> > in what language?  Verified how?  Bitstreams stored
>> > where and loaded by what?  Can they upload new
>> > bitstreams from Earth?  (Now that's an UPload!)
>> > What if DONE doesn't go high?
>> >
>> > Will this be the first FPGA in Mars space?
>>
>> I don't recall if there were any on Mars Pathfinder but there was
>> definitely an FPGA on Mars Global Survey on the laser altimeter. 
>> The FPGA got put onto the instrument as it was upgraded; the
>> original laser altimeter was on the ill-fated Mars Explorer.
>>
>> There are also FPGAs on the way to Saturn on the Cassini
>> spacecraft. 
>>
>>
>> > Most important of all, will they send a paper to
>> > FPL 2003 or FPGA 2004 or FCCM 2004?
>>
>> MAPLD 2003?  ;-)
>>
>> --
>> rk, Citizen, Noooo Yawk
>> "Sometimes when you connect the dots you get a picture.  Other
>> times you just have a bunch of dots." -- rk, January 23, 2003
> 
> 


Article: 56476
Subject: Masters Project Topic
From: priyal1977@yahoo.com (Priyal)
Date: 5 Jun 2003 20:34:16 -0700
Links: << >>  << T >>  << A >>
Thanks Rickman and kumaran for your suggestions.
Rickman, i looked through that website, and found some interesting topics.
Let me know if u have some other websites too.

Thanks,
Priyal

Article: 56477
Subject: fifo or bram in spartan2e vs spartan3
From: "Theron Hicks" <hicksthe@egr.msu.edu>
Date: Fri, 6 Jun 2003 00:47:04 -0400
Links: << >>  << T >>  << A >>
Hello,
    I am looking at a possible design where I need many small FIFOs or
possibly BRAMs to hold data temporarily.  In particular this device has many
(up to 32) channels.  for reasons of simplicity, it would be nice if the
data from each cahnnel could go into its own FIFO.  The data would then be
sent via USB to a main PC where the data could be directly sent to an array
for the correct channel rather that being parsed out to the various arrays.
By the way, the data being sent is coming in to the FIFOs from different
channels at different rates.  That is why I need 32 different FIFOs.  The
data bus is 16 bits wide if that is of importance.  The prefered chip is a
Spartan2e or possibly a Spartan3.  I need to avoid any BGA type packages to
allow for small production runs with reliable assembly.  (no toaster ovens,
etc.)  Production date is early Fall, '03.  Prototypes to start immediately.
Thanks,
Theron Hicks



Article: 56478
Subject: Re: Xilinx Block RAM
From: Patrik Eriksson <patrik.eriksson@netinsight.net>
Date: Fri, 06 Jun 2003 09:26:24 +0200
Links: << >>  << T >>  << A >>


Peter Alfke wrote:

> "parity bit" is just a name, suggesting one possible application. We
> might have called it "extra bit", or "Xilinx Ninth"...
> Use to store parity must be very rare.
> 
> Peter Alfke
> 

Why not call them data bit(s). E.g. D[31:0], DP[3:0] => D[35:0]. This 
should make it much easier for synthesis tools to use the 'parity' bits 
which e.g. synplify doesn't do today. If you try to use a 33 bits wide 
and 512 entries deep memory today the synthesis will end up with two 
BRAMs instead of one. This is waist of memory! Of course you could 
manually instantiate the RAM primitives but why should you do the work 
that the tools should do?

/Patrik



-- 
Patrik Eriksson              |  patrik.eriksson@netinsight.net
Net Insight AB               |  phone:  +46 8 685 04 89
Västberga Allé 9             |  fax:    +46 8 685 04 20
SE-126 30 STOCKHOLM, Sweden  |  http://www.netinsight.net


Article: 56479
Subject: Quartus II time delay
From: "Jens Nowack" <its.me.hates-spam@uni.de>
Date: Fri, 6 Jun 2003 10:08:47 +0200
Links: << >>  << T >>  << A >>
Hallo,

I have a clock e.g.: s_asck and a delayed clock: s_asck_delay

s_asck_delay <= s_asck after 50ns;

q1<=s_asck;
q2<=s_asck_delay;

When I simulate it with Quartus II the two graphs show the same
characteristics. But the Output q2 should be delayed 50 ns to q1.
How can I show it in Quartus II correctly?

best regards



Article: 56480
Subject: Re: Quartus II time delay
From: "Paul Baxter" <pauljnospambaxter@hotnospammail.com>
Date: Fri, 6 Jun 2003 12:37:54 +0100
Links: << >>  << T >>  << A >>
Quartus simulator only deals with synthesised code. You cannot synthesise
such time delays (they are ignored) hence the problem.
Use the Mentor Modelsim provided with Quartus if you need to simulate
testbenches or other non-synthesisable code.

Paul

"Jens Nowack" <its.me.hates-spam@uni.de> wrote in message
news:bbpi2g$c80fu$1@ID-192450.news.dfncis.de...
> Hallo,
>
> I have a clock e.g.: s_asck and a delayed clock: s_asck_delay
>
> s_asck_delay <= s_asck after 50ns;
>
> q1<=s_asck;
> q2<=s_asck_delay;
>
> When I simulate it with Quartus II the two graphs show the same
> characteristics. But the Output q2 should be delayed 50 ns to q1.
> How can I show it in Quartus II correctly?
>
> best regards
>
>



Article: 56481
Subject: Re: Virtex 2 evaluation board
From: "Manfred Kraus" <news@cesys.com>
Date: Fri, 6 Jun 2003 13:54:48 +0200
Links: << >>  << T >>  << A >>
Have you checked the XV2DDR board from CESYS (approx. 995,- Euro) ?
Short facts: XC2V1000-5FG456C, Micron MT46V16M16-75 DDR-SDRAM
XC18V04 ISP Conf. Prom, 219 I/O Pins wired to two 140-pin small-pitch
connectors,
Eval-board with mating connectors available.

Datasheet: http://www.cesys.com/english/resources/SPEC01.pdf


A free "light-version" of the DDR SDRAM controller can be downloaded from
www.opencores.org/projects/ddr_sdr.
This free version reaches 130 Mbytes/s with 100MHz system-clock. It consumes
about 180 Slices in a Virtex II device.
The controller is tested on the XV2DDR board. UCF-file is available.

-Manfred Kraus, cesys gmbh




Article: 56482
Subject: Re: Level Converters
From: "Manfred Kraus" <news@cesys.com>
Date: Fri, 6 Jun 2003 14:00:12 +0200
Links: << >>  << T >>  << A >>
Check this:

http://www.idt.com/products/pages/Bus_Switches-QS316245.html

QuickSwitch® Products QS316245

FEATURES/BENEFITS

. Enhanced N channel FET with no inherent diode to VCC
. 5W bidirectional switches connect inputs to outputs
. Pin compatible with FCT16245
. Flowthrough pinout for easy layout
. Zero propagation delay, zero ground bounce
. Undershoot clamp diodes on all switch and control inputs
. TTL-compatible control inputs
. Available in 48-pin SSOP (PV)

APPLICATIONS
. Hot-docking, hot-swapping (Application Note AN-13)
. Voltage translation (5V to 3.3V; Application Note AN-11)
. Bus switching, isolation
. Power conservation, clock gating
. Logic replacement



- Manfred Kraus



Article: 56483
Subject: Re: Xilinx Block RAM
From: Colin Marquardt <c.marquardt@alcatel.de>
Date: Fri, 06 Jun 2003 15:30:49 +0200
Links: << >>  << T >>  << A >>
muthu_nano@yahoo.co.in (Muthu) writes:

> In all Xilinx block RAM Primitives, they have allocated Parity bits (1
> per byte) for each locations. If we see the 32bits with RAM,
> additional 4 bits being provided for the Parity.

As has been said already, this is just a name suggesting a possible
usage.

> In most of the cases, we are not using this. This is because, all our
> RAM is internal, there is not possibility of data corruption.

You might want to be careful here. If this RAM stores data that is
rarely refreshed, over the course of several days or weeks, it could
still be that your data is corrupted due to environmental influences
like radiation. Be pessimistic.

Cheers,
  Colin

Article: 56484
Subject: Re: Is it possible to simulate Nios designs with Quartus?
From: Jesus Jimenez <jjimherr@eresmas.com>
Date: Fri, 6 Jun 2003 17:56:28 +0200
Links: << >>  << T >>  << A >>
In article <BwzDa.4269$IR1.488918@news20.bellglobal.com>, 
warpawn@sympatico.ca says...
> So I'd say try simulating for a longer time as a start.  you should also
> take a look at where nios is fetching from.

I finally solved it, I didn't saw that reset was activated with a low 
level, so I was resetting the cpu most of the time (a very stupid 
error). When I fixed it, I had to rebuild the cpu in order to set the 
internal rom (where I put my program) base address to 0, then all 
started working.

Thanks for your response
-- 
Jesus Jimenez
jesjimenez@NOSPAMtelefonica.net

Article: 56485
(removed)


Article: 56486
Subject: Re: Simulation problem with XILINX library component
From: "Richard Erlacher" <richard_no_junk_mail_4_me at idcomm.com>
Date: Fri, 6 Jun 2003 10:54:28 -0600
Links: << >>  << T >>  << A >>
... er ... that should have said ...AND the quite static CLOCK ENABLE input.

BTW, what I find odd is that this particular instance behaves differently
than the other two in the circuit.

Richard Erlacher

"Richard Erlacher" <richard_no_junk_mail_4_me at idcomm.com> wrote in
message news:3edfd43f$1@mindmeld.idcomm.com...
> I've run into an odd problem with the third stage of a 12-bit synchronous
> binary counter simulation.  This circuit consists of an FTRSE driving the
CE
> inputs of each of three CB4RE counters, concatenated in the obvious way.
An
> the FTRSE and the three counters are all clocked with a common clock, and
> the counters' enable is driven from the output of the FTRSE which is set
> from an external start strobe two clocks long, and cleared when the last
> stage generates its CEO (count enable out).  Unfortunately this output,
> clearly an entire clock cycle long (not one of the infamous glitches these
> can generate) occurs when the LSB of the third stage is false, which is
not
> what one would expect, since this output is not registered, but is gated
> from the synchronous outputs AND the quite static input.
>
> Has anyone else encountered this apparent anomaly?
>
> thanks,
>
> Richard Erlacher
>
>



Article: 56487
Subject: Re: IDE CUSTOM DRIVER
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 06 Jun 2003 17:31:03 -0000
Links: << >>  << T >>  << A >>
>Now I want to write a linux driver for this device.
>
>Do I write the driver from scratch or I can modify an existing driver?
>Which files Do I need to modify?

Most drivers are written by taking the closest driver
you can find and editing (hacking?) it until it work.

It helps if you had that in mind when you designed your
hardware - that is make your hardware as close to an existing
design as you can.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 56488
Subject: Re: fifo or bram in spartan2e vs spartan3
From: Amontec Team <laurent.gauch@DELALLCAPSamontec.com>
Date: Fri, 06 Jun 2003 19:58:32 +0200
Links: << >>  << T >>  << A >>
Theron Hicks wrote:
> Hello,
>     I am looking at a possible design where I need many small FIFOs or
> possibly BRAMs to hold data temporarily.  In particular this device has many
> (up to 32) channels.  for reasons of simplicity, it would be nice if the
> data from each cahnnel could go into its own FIFO.  The data would then be
> sent via USB to a main PC where the data could be directly sent to an array
> for the correct channel rather that being parsed out to the various arrays.
> By the way, the data being sent is coming in to the FIFOs from different
> channels at different rates.  That is why I need 32 different FIFOs.  The
> data bus is 16 bits wide if that is of importance.  The prefered chip is a
> Spartan2e or possibly a Spartan3.  I need to avoid any BGA type packages to
> allow for small production runs with reliable assembly.  (no toaster ovens,
> etc.)  Production date is early Fall, '03.  Prototypes to start immediately.
> Thanks,
> Theron Hicks
> 
> 

Hi,

Which USB device do you have?
Do you need external memories?

Since we are finalizing a similar product based USB, we can help, or do 
your project in a rapid time.

Actually, we have a proto board with a low cost USB solution ($8) 
connected directly to a SPartan2 (150k)device.
We are able to POWER / CONFIG THE FPGA / DIALOG WITH FPGA over USB.
(your JTAG emulation can program the SPROM for the FPGA).

This solution allows to save power input, to save external Xilinx 
Parallel POD -> to save money and time.

We are doing a final product with that ... will be ChameleonII (we just 
are waiting on SPARTAN3)

Contact
laurent.gauch@amontec

Amontec Team
www.amontec.com


Article: 56489
Subject: using USB
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 06 Jun 2003 11:42:31 -0700
Links: << >>  << T >>  << A >>
Glenn, this is from the newsgroup.
Something for "our" board?
Peter

Quoate from comp.arch.fpga:

Which USB device do you have?
Do you need external memories?

Since we are finalizing a similar product based USB, we can help, or do 
your project in a rapid time.

Actually, we have a proto board with a low cost USB solution ($8) 
connected directly to a SPartan2 (150k)device.
We are able to POWER / CONFIG THE FPGA / DIALOG WITH FPGA over USB.
(your JTAG emulation can program the SPROM for the FPGA).

This solution allows to save power input, to save external Xilinx 
Parallel POD -> to save money and time.

Article: 56490
Subject: Re: using USB
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 06 Jun 2003 12:16:42 -0700
Links: << >>  << T >>  << A >>
Sorry, this was not meant for public consumption. Just for a friend...
Shows my appreciation for a nifty USB interface.
Peter Alfke
============
Peter Alfke wrote:
> 
> Glenn, this is from the newsgroup.
> Something for "our" board?
> Peter
> 
> Quoate from comp.arch.fpga:
> 
> Which USB device do you have?
> Do you need external memories?
> 
> Since we are finalizing a similar product based USB, we can help, or do
> your project in a rapid time.
> 
> Actually, we have a proto board with a low cost USB solution ($8)
> connected directly to a SPartan2 (150k)device.
> We are able to POWER / CONFIG THE FPGA / DIALOG WITH FPGA over USB.
> (your JTAG emulation can program the SPROM for the FPGA).
> 
> This solution allows to save power input, to save external Xilinx
> Parallel POD -> to save money and time.

Article: 56491
Subject: Re: using USB
From: "Laurent Gauch, Amontec" <laurent.gauch@amontec.com>
Date: Fri, 06 Jun 2003 21:26:16 +0200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Glenn, this is from the newsgroup.
> Something for "our" board?
> Peter
> 
> Quoate from comp.arch.fpga:
> 
> Which USB device do you have?
> Do you need external memories?
> 
> Since we are finalizing a similar product based USB, we can help, or do 
> your project in a rapid time.
> 
> Actually, we have a proto board with a low cost USB solution ($8) 
> connected directly to a SPartan2 (150k)device.
> We are able to POWER / CONFIG THE FPGA / DIALOG WITH FPGA over USB.
> (your JTAG emulation can program the SPROM for the FPGA).
> 
> This solution allows to save power input, to save external Xilinx 
> Parallel POD -> to save money and time.
which board?


Article: 56492
Subject: Re: fifo or bram in spartan2e vs spartan3
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 6 Jun 2003 22:03:13 +0200
Links: << >>  << T >>  << A >>

"Theron Hicks" <hicksthe@egr.msu.edu> schrieb im Newsbeitrag
news:bbqght$bi7$1@msunews.cl.msu.edu...

> Hello,
>     I am looking at a possible design where I need many small FIFOs or
> possibly BRAMs to hold data temporarily.  In particular this device has
many
> (up to 32) channels.  for reasons of simplicity, it would be nice if the
> data from each cahnnel could go into its own FIFO.  The data would then be

So how deep must the FIFOs be? 16 words? 100 ? 1000 ?
A BRAM in Spartan2E is 4kbits, so it can hold 256 16 bit words.
Spartan3 is derived from Virtex-II so a BRAM is 18 kbits.
The rest can be easyly looked up in the datasheets.
If you need (much) smaller FIFOs, you can use distributed RAM.

--
MfG
Falk




Article: 56493
Subject: Re: Protel DXP or other schematic entry?
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Fri, 06 Jun 2003 15:59:53 -0500
Links: << >>  << T >>  << A >>


Jake Janovetz wrote:

>Is anyone out there using a third-party schematic entry tool (or even
>HDL tool) for Xilinx FPGAs?  I'll exclude Synplicity from my poking
>and prodding because I know it's used a lot.
>
>There are several situations where schematic entry would be a nice
>alternative to HDL for building an RPM.  ECS is a waste of bits in my
>opinion and Viewlogic isn't so hot anymore.  I know Protel offers
>schematic entry with Xilinx primitives and I assume OrCAD has
>something similar.  Are they worth using?
>  
>
I tried doing this some time ago, and ran into several layers of bugs.
First, the FPGA libraries are extremely old and out of date for
modern devices, like Spartan.  I got some more modern libraries
from older (how odd!) versions of Protel Advanced Schematic, but
they were FULL of bugs.  Obviously machine translated in some
fashion, which missed a buch of connection dots on clock lines, so
that many of the counter blocks flip flops had no clock.  I hand edited
a few, but then really hit the wall.  The Xilinx compatible output
file (.xnf) was reported to have invalid syntax by the Xilinx tools!
I sent this info to Protel 2 years ago, there has been no response from
them.

Protel will not do any Xilinx FPGAs by itself, I was trying to use
Protel only as a schematic front end to Xilinx Foundation, as the schematic
package before ECS was even worse!  I still feel that ECS is pretty awful,
and the rest of ISE is just a bit cumbersome, non-intuitive, etc.

The above all applies to Protel 99SE, I have no idea what they have
fixed, or broken, with the move to DXP.  But, to hear comments in
the mailing lists, DXP support for programmable logic is less, if
anything, than with 99SE.

Jon


Article: 56494
Subject: Re: Xilinx Spartan download with Parallel III cable
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Fri, 06 Jun 2003 16:11:58 -0500
Links: << >>  << T >>  << A >>


Falk Brunner wrote:

>"David Kinsell" <kinsell@poboxyz.com> schrieb im Newsbeitrag
>news:Z9eDa.62966$M01.39756@sccrnsc02...
>
>  
>
>>Those aren't classic low pass filters, the caps should be on the other
>>side of the resistors.  I've used 470 pf on the other side of the TCK
>>resistor and gotten much better results programming an original Spartan
>>part.
>>    
>>
>
>Those filters are just nonsense, IMHO. It has been said a few times, that
>the TCK line is VERY sensitive to glitches, since it is as fast as all other
>IOs. So it is a good idea to put RC-filter (330 Ohm, 1nF) followed by a
>schmitt-trigger (74HC14) in front of the TCK line (before the tristate
>driver). A second schmitt-trigger reveres the polarity to the original
>level, so from the software view its identical. In my download cable, I also
>removed the diode feeding VCC.
>  
>
I've found the Parallel cable III to be totally reliable on certain 
computers, and
anywhere from marinal to totally nonfunctional on some others.  I haven't
tried hacking the unit to find the specific signal that was the problem. 
 But,
it clearly was associated with specific characteristics of the parallel 
port chip
on the motherboard.  Probably some pull-ups to a real +5 V on the computer
end would help a lot, but there is no +5 available on the DB-25 connector.

Did you actually make the 74HC14 and RC change on a cable, and see it work
reliably on the same computer where it was marginal before?

Jon


Article: 56495
Subject: Zero for replication multiplier --Quartus Bug?
From: matt@ettus.com (Matt Ettus)
Date: 6 Jun 2003 14:29:34 -0700
Links: << >>  << T >>  << A >>
I have the following verilog code which gets flagged as an error in
quartus, but not in Icarus --

{{shift{yi[bitwidth-1]}},yi[bitwidth-1:shift]}

"shift" is a parameter, and the error gets flagged only when it is
equal to zero.  Quartus says "replication multiplier must be positive.

I'm pretty sure this is legal verilog.  

Matt

Article: 56496
Subject: Re: Xilinx Block RAM
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Fri, 06 Jun 2003 14:31:13 -0700
Links: << >>  << T >>  << A >>
???????

Tests show that the rate of upsets (soft errors) in a 2V1000 BRAM is one
every 800 years at sea level in San Jose.....

Weeks?  Days?  come on!

Do you have a nuclear reactor door open somewhere?

Austin

Colin Marquardt wrote:
-snip-

>
> You might want to be careful here. If this RAM stores data that is
> rarely refreshed, over the course of several days or weeks, it could
> still be that your data is corrupted due to environmental influences
> like radiation. Be pessimistic.
>
> Cheers,
>   Colin


Article: 56497
Subject: some book advises ??
From: yannick <ymorvan@m6net.fr>
Date: Fri, 06 Jun 2003 21:36:17 GMT
Links: << >>  << T >>  << A >>
Hi people,

I just started to worked with those funny FPGA's as a sudent
a few weeks ago. I'm doing some image processing with FPGA but, 
I've  lack of experience in those stuff and so i'd like to grabb a book
related to the subject.
for exemple:
I want to take care about the boundaries of the image when i aplly a 
kernel, is there a trick to manage this ( I mean the architecture in the
whole vhdl design)?
Or, how to resize the image, is there some technics in hardware design?

To sum up: is there a book which talks about signal processing (or better
image processing) which talk about tricks and architecture for vhdl and more
generally hardware architecture for image processing ??


Article: 56498
Subject: Re: spartan2e vs cyclone
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 06 Jun 2003 14:38:08 -0700
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:
> If even the BaseX system does not support devices beyond 3S200, I guess
> we can expect Webpack support to be pretty short for a long time to
> come, no?  
> 
> I really don't understand the idea behind not supporting the full
> Spartan3 line in the *paid for* tools.  I know BaseX is not expensive,
> but what is the rational behind *NOT* supporting any devices in the paid
> for tools?  

To encourage you to pay *more*.

Article: 56499
Subject: Re: Xilinx Block RAM
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 06 Jun 2003 14:40:23 -0700
Links: << >>  << T >>  << A >>
Colin Marquardt <c.marquardt@alcatel.de> writes:
> You might want to be careful here. If this RAM stores data that is
> rarely refreshed, over the course of several days or weeks, it could
> still be that your data is corrupted due to environmental influences
> like radiation. Be pessimistic.

If you've using a small number of BRAMs and a lot of logic cells, I'd
expect there to be a higher probability of an SEU in a logic cell, for
which parity is not, in general, going to help.



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