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 101375

Article: 101375
Subject: Re: Reset
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 29 Apr 2006 19:29:44 -0700
Links: << >>  << T >>  << A >>
As the name implies, an asynchronous reset resets the flip-flop or
register immediately, without a clock.
A synchronous reset input effectively forces the D input Low, sotat the
flip-flop or register gets reset by the next clock, not immediately.

Synchronous resets, in conjunction with low-skew global clocks, result
in the best predictive behavior.

But in certain special cases, you might need an asynchronous reset, to
get the flip-flop reset before the next clock comes around. The penalty
is less predictable, "sloppier" timing, especially if the asynchronous
line has to drive many loads.
Peter Alfke, Xilinx


Article: 101376
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Sat, 29 Apr 2006 19:38:38 -0700
Links: << >>  << T >>  << A >>
On 28 Apr 2006 11:30:00 -0700, "rickman" <spamgoeshere4@yahoo.com>
wrote:

>People here are driving me crazy insisting that the Xilinx factory has
>told them that you *MUST* tie the mode pins to either Vaux or GND.
>After finding all the info in the data sheet and talking with support,
>it looks pretty clear to me that the S3 parts have a very stiff
>internal pull up and there is no need for an external pull up of any
>kind, resistor or direct connection to Vaux.
>
>Am I misunderstanding?  Why did the factory tell us before that the
>mode pins *MUST* be tied to Vaux?  Did we misunderstand what they were
>saying?
>
>I promise this is the last time I will ask about this.  I am totally
>sick of going around this loop with everyone here.


We leave them open, slave serial. Works fine.

John


Article: 101377
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sun, 30 Apr 2006 14:56:48 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> John, this is analog territory, and there is NOT just ONE right answer.
> 
> Obviously, a short circuit will always work, if you never need the pin
> for any other purpose.
>    But we will not force you to do that, since you may have reasons not
> to like it. It's a free country!
>    There is no mystery here, the purpose is only to establish a High
> logic level. Nothing more, nothing less.
> Obviously, a built-in pull-up resistor will establish a High logic
> level, but it might be sensitive to crosstalk coming from your
> pc-board..
> Obviously, any external resistor reduces the pull-up impedance, and
> improves the situation.
> Obviously an external pull-down resistor must be low enough in value to
> overcome the internal pull-up resistance.
> 
> And I still favor a multimeter for getting a grip on fundamentals.

Wasn't there some question on just WHEN these pullups are 'alive' ?
- a multimeter is not going to be much help there....  :(

But a simple table in the data sheet, giving defined values, for
all phases of Config state (includes Vcc's ), and what is needed
(or not needed) for a legal logic condition, should nail it ?

-jg



Article: 101378
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 29 Apr 2006 22:46:34 -0700
Links: << >>  << T >>  << A >>
Jim, please give us the benefit of the doubt, that we are not totally
stupid.
The mode pins are of interest at the very beginning of the
configuration process.
That's obviously when the pull-ups are active.
I do not know when they are being de-activated, but trust us that they
are active when it matters.
We have 22 years experience in this technology, and have shipped many
hundreds of millions of FPGAs...
But you are right, there is always an opportunity for better
documentation.
Remember: This whole lengthy discussion never mentioned a technical
problem or malfunction, only a diversity of suggestions, all of them
correct.

Peter Alfke, Xilinx, from home


Article: 101379
Subject: Re: Book Software for XC3190A?
From: tuxfriend <tuxfriend@arcor.de>
Date: Sun, 30 Apr 2006 08:51:30 +0200
Links: << >>  << T >>  << A >>
Hello Peter,
thank you for the answer. But the XC3190A is big enougth for my small
projects and the package is good for hand soldering...
..and at last I have the parts but not the money;)
For any projects I use the XC9536 and webpack 8.1i (21st century stuff!).
The Book price is about 25eur and even if the Software is not comfortable I
think its good enougth for my home build stuff.
That is the reason for my question:
Can I use the Book Software for my XC3190A?

Thank you
tuxfriend 
 
Peter Alfke wrote:

> The XC3190A was introduced 15 years ago, which makes it hopelessly
> obsolete. Even if you find the hardware sufficient (no on-chip RAM!),
> the software is so antiquated that nobody should be forced to use it.
> Get yourself a modern chip of Spartan or Virtex caliber and of 2003+
> vintage. The hardware is cheap, and the software is free, and both are
> very competent.
> Happy designing with 21st century stuff!
> Peter Alfke, Xilinx



Article: 101380
Subject: FPGA Single LED Demos: FPGA board for a good ideas/suggestions
From: "Antti Lukats" <antti@openchip.org>
Date: Sun, 30 Apr 2006 09:48:14 +0200
Links: << >>  << T >>  << A >>
Hi all

I am looking for ideas for: "FPGA Single LED Demos", The requirements for 
the demo Application are following:

* Display visible 'sign of live' or 'self-test passed' message
* Impemented in FPGA Vendor neutral HDL
* <= 3000 LUT
* <= 4KB of Block RAM
* uncalibrated (+-50%) high frequency oscillator
* 1 user LED for display

The Demo application should have some sort of LED visible 'message' to 
indicate the demo is working or has passed internal self test code. There is 
no user interface byeound one single LED.

Current list of Applications
==================
1) LED Blink (MSB of counter) - VHDL
2) LED Blink (MSB of counter) - Verilog
3) LED Blink (MSB of counter) - MyHDL (Python)
4) LED Fade with PWM (waveform from counter bits)
5) LED Fade with Delta-Sigma DAC (waveform from counter bits)
6) LED Fade with DDS and Delta-Sigma (waveform from ROM Table)
7) PacoBlaze LED Blink with Assembler Program
8) PacoBlaze LED Blink with C Program
9) SPoC(bit-serial-processor) LED Blink with Assembler Program
8) AVR like MCU LED Blink with Basic Program
10) PIC like MCU LED Blink with Assembler Program
11) C16 (16 Bit CPU) LED Blink with C Program
12) LED Blink with 32-bit Programmable Micro-Sequencer
13) Frequency Measurement demo (use stop watch and calculator)
14) ? your idea ?

The above is my current list of demo applications, I am considering some 
more soft-core CPU's, but all those demos would be very similar to the 
existing soft-core demos. So any ideas to demo some other functionality are 
welcome.

Best ideas can be rewarded with an FPGA evaluation board (with your idea 
pre-programmed). Suggestions a-la "soft-core cpu acme/xyz" will not count.

Antti






Article: 101381
Subject: Re: Spartan 3 documentation confusing...
From: "Ulf Samuelsson" <ulf@a-t-m-e-l.com>
Date: Sun, 30 Apr 2006 11:27:35 +0200
Links: << >>  << T >>  << A >>
Michael Hennebry wrote:
> rickman wrote:
>
>> I am asking that you not wait until a frustrated user reports your
>> mistakes.  I am asking that you have someone look at what it takes to
>> find all the info that an engineer needs to configure these parts and
>> make the info consistent and more usable.
>
> Documentation by the designer is notoriously awful,
> but to start with, the designer is who is available.
> It takes a truly wonderful designer to put himself in the
> position of someone encountering his design for the first time.
> Just ask the people trying to use my documentation.
> Input from frustrated users is necessary.
> I don't have the information to know whether the documentation
> for this part is as good as it could be given the user input.

If they guy making development board for a part would not have
access to anything except the datasheet, then maybe there would be
improvements.

Documentation is improved if it can be measured against a standard
on what the documentation should contain.


-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB



Article: 101382
Subject: Xilinx PROM
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Sun, 30 Apr 2006 04:33:27 -0500
Links: << >>  << T >>  << A >>
I may have overlooked something but I cant seem to find the dimensions of
the platform flash PROM in a FS48 package. I have the datasheet but it
appears not to be in it. Also had a look on the Xilinx website but again
no luck. Can someone point me to the right place?

Cheers

Jon

Article: 101383
Subject: Re: FPGA Single LED Demos: FPGA board for a good ideas/suggestions
From: Hans <hans64@ht-lab.com>
Date: Sun, 30 Apr 2006 10:06:05 GMT
Links: << >>  << T >>  << A >>
Hi Antti,

What about morse code to give the status?

I should have some code in VHDL which I will dig out and send to you,

Regards,
Hans
www.ht-lab.com

Antti Lukats wrote:
> Hi all
> 
> I am looking for ideas for: "FPGA Single LED Demos", The requirements for 
> the demo Application are following:
> 
> * Display visible 'sign of live' or 'self-test passed' message
> * Impemented in FPGA Vendor neutral HDL
> * <= 3000 LUT
> * <= 4KB of Block RAM
> * uncalibrated (+-50%) high frequency oscillator
> * 1 user LED for display
> 
> The Demo application should have some sort of LED visible 'message' to 
> indicate the demo is working or has passed internal self test code. There is 
> no user interface byeound one single LED.
> 
> Current list of Applications
> ==================
> 1) LED Blink (MSB of counter) - VHDL
> 2) LED Blink (MSB of counter) - Verilog
> 3) LED Blink (MSB of counter) - MyHDL (Python)
> 4) LED Fade with PWM (waveform from counter bits)
> 5) LED Fade with Delta-Sigma DAC (waveform from counter bits)
> 6) LED Fade with DDS and Delta-Sigma (waveform from ROM Table)
> 7) PacoBlaze LED Blink with Assembler Program
> 8) PacoBlaze LED Blink with C Program
> 9) SPoC(bit-serial-processor) LED Blink with Assembler Program
> 8) AVR like MCU LED Blink with Basic Program
> 10) PIC like MCU LED Blink with Assembler Program
> 11) C16 (16 Bit CPU) LED Blink with C Program
> 12) LED Blink with 32-bit Programmable Micro-Sequencer
> 13) Frequency Measurement demo (use stop watch and calculator)
> 14) ? your idea ?
> 
> The above is my current list of demo applications, I am considering some 
> more soft-core CPU's, but all those demos would be very similar to the 
> existing soft-core demos. So any ideas to demo some other functionality are 
> welcome.
> 
> Best ideas can be rewarded with an FPGA evaluation board (with your idea 
> pre-programmed). Suggestions a-la "soft-core cpu acme/xyz" will not count.
> 
> Antti
> 
> 
> 
> 
> 

Article: 101384
Subject: Re: FPGA Single LED Demos: FPGA board for a good ideas/suggestions
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sun, 30 Apr 2006 22:20:38 +1200
Links: << >>  << T >>  << A >>
Antti Lukats wrote:

> Hi all
> 
> I am looking for ideas for: "FPGA Single LED Demos", The requirements for 
> the demo Application are following:
> 
> * Display visible 'sign of live' or 'self-test passed' message
> * Impemented in FPGA Vendor neutral HDL
> * <= 3000 LUT
> * <= 4KB of Block RAM
> * uncalibrated (+-50%) high frequency oscillator
> * 1 user LED for display
> 
> The Demo application should have some sort of LED visible 'message' to 
> indicate the demo is working or has passed internal self test code. There is 
> no user interface byeound one single LED.
> 
> Current list of Applications
> ==================
> 1) LED Blink (MSB of counter) - VHDL
> 2) LED Blink (MSB of counter) - Verilog
> 3) LED Blink (MSB of counter) - MyHDL (Python)
> 4) LED Fade with PWM (waveform from counter bits)
> 5) LED Fade with Delta-Sigma DAC (waveform from counter bits)
> 6) LED Fade with DDS and Delta-Sigma (waveform from ROM Table)
> 7) PacoBlaze LED Blink with Assembler Program
> 8) PacoBlaze LED Blink with C Program
> 9) SPoC(bit-serial-processor) LED Blink with Assembler Program
> 8) AVR like MCU LED Blink with Basic Program
> 10) PIC like MCU LED Blink with Assembler Program
> 11) C16 (16 Bit CPU) LED Blink with C Program
> 12) LED Blink with 32-bit Programmable Micro-Sequencer
> 13) Frequency Measurement demo (use stop watch and calculator)
> 14) ? your idea ?
> 
> The above is my current list of demo applications, I am considering some 
> more soft-core CPU's, but all those demos would be very similar to the 
> existing soft-core demos. So any ideas to demo some other functionality are 
> welcome.

  Most obvious is to extend to a BiColour LED, Driven from 2 pins, so
that you can generate : Pure RED, Modulated RED (OE), Pure GREEN,
Modulated GREEN (OE) and Colour Modulated (PWM %R/100-% G)
Control lines are : R, R.oe, G, G.oe

  Then at eye-ball rates, you can signal something over 4 states, without
needing long dividers.

[Well, yes, this is only partially vendor neutral: it works on all those 
vendors who actually gave this some thought, and installed a BiColour LED ]

  My preferred modulation is PDM (Rate Multiplier), rather than PWM : 
PDM uses the least resource in CPLDs, and filters better in DAC 
applications.


  Also not on your list, is a RC5 / manchester Encoded LED modulate.
Target the std IR-Remote Receivers, perhaps with an IR led in Parallel
if the RED energy is too low to activate a NearBy - StdIR RX unit.

  That allows actual BIT serial (status flags) info to be sent, into a 
simple receiver.

  One-Wire encoding is another way to send Freq tolerant information,
in an easily decoded manner.


> Best ideas can be rewarded with an FPGA evaluation board (with your idea 
> pre-programmed). Suggestions a-la "soft-core cpu acme/xyz" will not count.

-jg


Article: 101385
Subject: ML403 ZBT SRAM
From: "=?iso-8859-1?B?R2FMYUt0SWtVc5k=?=" <taileb.mehdi@gmail.com>
Date: 30 Apr 2006 03:31:22 -0700
Links: << >>  << T >>  << A >>
Hi all, I'm trying to develop a controller for the ZBT SRAM present on
the ML403 board. When I make a post P&R simulation (using manufacturer
verilog models of the memory) all is ok. But when I make on board tests
nothing works.
I even added a DCM for making board level clock deskewing.
Please help. I would like to have a small basic example of a
controller.

Cheers


Article: 101386
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: Dave <dave@comteck.com>
Date: Sun, 30 Apr 2006 05:33:53 -0500
Links: << >>  << T >>  << A >>
On Sat, 29 Apr 2006 18:54:31 -0700, Peter Alfke wrote:

> I am all for clear documentation, but it never hurts to keep the
> engineering mind alive.
> Compared to multi-gigabit receiver issues, this mode-pin level debate
> is really a trivial subject. 

Not if you are not doing multi-gigabit receivers.  The longer design
review issues go unresolved, the greater the probability they start
reaching non-engineering minds.  You do not want "help" from these people!


    ~Dave~

Article: 101387
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sun, 30 Apr 2006 22:33:55 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Jim, please give us the benefit of the doubt, that we are not totally
> stupid.

Where did I claim that ?

> The mode pins are of interest at the very beginning of the
> configuration process.
> That's obviously when the pull-ups are active.
> I do not know when they are being de-activated, but trust us that they
> are active when it matters.
> We have 22 years experience in this technology, and have shipped many
> hundreds of millions of FPGAs...
> But you are right, there is always an opportunity for better
> documentation.
> Remember: This whole lengthy discussion never mentioned a technical
> problem or malfunction, only a diversity of suggestions, all of them
> correct.

Just to remind you - the audience, here is not you, Austin, Rickman, 
etc, ( we ALL know 'it works' ) but those in rickman's reference :

" But some people here ("here" my work, not "here" the newsgroup) just 
won't let go of the bone.  They are insisting that the pins must be 
connected to Vaux directly because of what they were told a year ago."

ie they are saying to him : 'Prove it'.
He is asking for Xilinx to help him do that.

-jg




Article: 101388
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: Jim Granville <no.spam@designtools.co.nz>
Date: Sun, 30 Apr 2006 22:35:18 +1200
Links: << >>  << T >>  << A >>
Dave wrote:

> On Sat, 29 Apr 2006 18:54:31 -0700, Peter Alfke wrote:
> 
> 
>>I am all for clear documentation, but it never hurts to keep the
>>engineering mind alive.
>>Compared to multi-gigabit receiver issues, this mode-pin level debate
>>is really a trivial subject. 
> 
> 
> Not if you are not doing multi-gigabit receivers.  The longer design
> review issues go unresolved, the greater the probability they start
> reaching non-engineering minds.  You do not want "help" from these people!

Well said :) A little knowledge is a dangerous thing...

-jg


Article: 101389
Subject: Re: FPGA Single LED Demos: FPGA board for a good ideas/suggestions
From: pbdelete@spamnuke.ludd.luthdelete.se.invalid
Date: 30 Apr 2006 10:42:32 GMT
Links: << >>  << T >>  << A >>
Antti Lukats <antti@openchip.org> wrote:
>Hi all
>I am looking for ideas for: "FPGA Single LED Demos", The requirements for 
>the demo Application are following:

>* Display visible 'sign of live' or 'self-test passed' message
>* Impemented in FPGA Vendor neutral HDL
>* <= 3000 LUT
>* <= 4KB of Block RAM
>* uncalibrated (+-50%) high frequency oscillator
>* 1 user LED for display

>The Demo application should have some sort of LED visible 'message' to 
>indicate the demo is working or has passed internal self test code. There is 
>no user interface byeound one single LED.

*) RS232 signaling sending something like "POST ok".
   Then you could just direct it to any laptop with ir-serial. Possibly IrDA.

*) Morse code.

*) Maybe 10 Mbps ethernet is doable. Guess not thoe :-)

*) With an external mirror+stepper you could reflect the led light onto a
   paper and draw something.

With a more stable oscillator possibilities vastly increase.

contact at pb (a) ludd . luth DOT se


Article: 101390
Subject: Re: URGENT: Xilinx site
From: "Leon" <leon.heller@bulldoghome.com>
Date: 30 Apr 2006 04:13:47 -0700
Links: << >>  << T >>  << A >>

Peter Alfke wrote:
> We had a massive network problem inside Xilinx in San Jose, but that
> was resolved on Friday.
> Peter Alfke

It seems OK now.

Leon


Article: 101391
Subject: Xilinx MPPR failing
From: "=?iso-8859-1?B?R2FMYUt0SWtVc5k=?=" <taileb.mehdi@gmail.com>
Date: 30 Apr 2006 04:21:40 -0700
Links: << >>  << T >>  << A >>
Hi all, I have a problem with MPPR (MultiPass Place  and Route). The
first pass ends normally but at the begin of the place phase of the
second pass the processus fails and I get a {Process "Place & Route"
failed} message.
The problem apeared after I installed ISE8.1i service pack 03.
Any adea about the probelm?

Cheers


Article: 101392
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: nospam <nospam@please.invalid>
Date: Sun, 30 Apr 2006 12:34:59 +0100
Links: << >>  << T >>  << A >>
"Peter Alfke" <alfke@sbcglobal.net> wrote:

>I much rather spend 10 minutes with a multi-meter than indulge in
>contankerous debates in the newsgroup.
>We are all engineers and not scribes, aren't we?

I much rather chip manufacturers provide the required documentation so that
thousands of engineers don't have to independently waste 10 minutes with a
multimeter. 

Such questions need to be answered  before you have any hardware to poke
with a multimeter anyway. 

--

Article: 101393
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: "Leon" <leon.heller@bulldoghome.com>
Date: 30 Apr 2006 04:41:47 -0700
Links: << >>  << T >>  << A >>

Peter Alfke wrote:
> Jim, please give us the benefit of the doubt, that we are not totally
> stupid.
> The mode pins are of interest at the very beginning of the
> configuration process.
> That's obviously when the pull-ups are active.
> I do not know when they are being de-activated, but trust us that they
> are active when it matters.
> We have 22 years experience in this technology, and have shipped many
> hundreds of millions of FPGAs...
> But you are right, there is always an opportunity for better
> documentation.
> Remember: This whole lengthy discussion never mentioned a technical
> problem or malfunction, only a diversity of suggestions, all of them
> correct.
>
> Peter Alfke, Xilinx, from home

Lilliput in Gulliver's Travels comes to mind - wars fought over whether
to break boiled eggs at the big or small end!

Leon


Article: 101394
Subject: Re: Book Software for XC3190A?
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Sun, 30 Apr 2006 08:02:23 -0400
Links: << >>  << T >>  << A >>
On Sun, 30 Apr 2006 08:51:30 +0200, tuxfriend wrote:

> Hello Peter,
> thank you for the answer. But the XC3190A is big enougth for my small
> projects and the package is good for hand soldering... ..and at last I
> have the parts but not the money;) For any projects I use the XC9536 and
> webpack 8.1i (21st century stuff!). The Book price is about 25eur and
> even if the Software is not comfortable I think its good enougth for my
> home build stuff. That is the reason for my question: Can I use the Book
> Software for my XC3190A?
> 
> Thank you
> tuxfriend
>  
> Peter Alfke wrote:
> 
>> The XC3190A was introduced 15 years ago, which makes it hopelessly
>> obsolete. Even if you find the hardware sufficient (no on-chip RAM!),
>> the software is so antiquated that nobody should be forced to use it.
>> Get yourself a modern chip of Spartan or Virtex caliber and of 2003+
>> vintage. The hardware is cheap, and the software is free, and both are
>> very competent.
>> Happy designing with 21st century stuff! Peter Alfke, Xilinx

Software support for the 3000 series was dropped years ago. What's the
copyright date on the book that you are looking at? If the copyright is
from the early to mid-90s then the included software will support the 3000
series. If the book has been updated in recent years the chances are they
have a slightly obsolete version of Webpack included which won't support
the 3000 series. If the book is from the early 90s, what media are the
included tools on? Early 90s PCs had 5 1/4" floppies, good luck finding a
5 1/4" floppy drive. If it's on 3 1/2" floppies then you'll be able to
read them because 3 1/2" drives are still available, your system might
even have on if it's more than 2 years old. If the software is on a CDROM
that's a sure indicator that it won't have 3000 series support. By the
time that CDROMs became the standard means of distributing software
support for the 3000 series had already been dropped.

If what you want to do is to learn how to design with FPGAs it's not
necessary to actually build something. My suggestion would be to download
a copy of Icarus Verilog (it's free) and a copy of the current Xilinx
Webpack (also free). Do design in Verilog and debug it using Icarus. Then
you can place and route it using Webpack. 21st century FPGA designers
don't spend much time in the lab debugging on the actual hardware, the
debugging is done using a Verilog simulator.


Article: 101395
Subject: Re: FPGA Single LED Demos: FPGA board for a good ideas/suggestions
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Sun, 30 Apr 2006 14:21:28 +0200
Links: << >>  << T >>  << A >>
Hans wrote:

> Hi Antti,
> 
> What about morse code to give the status?
> 
> I should have some code in VHDL which I will dig out and send to you,
> 

Best to then blink the Morse dots using PWM at 1KHz and 50% duty cycle so
that you can also hear it with a solar cell and a piezo earpiece ;-)

Ben

Article: 101396
Subject: Re: Pull up resistors on Spartan 3 mode pins
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 30 Apr 2006 06:34:15 -0700
Links: << >>  << T >>  << A >>
John Larkin wrote:
> On 28 Apr 2006 11:30:00 -0700, "rickman" <spamgoeshere4@yahoo.com>
> wrote:
>
> >People here are driving me crazy insisting that the Xilinx factory has
> >told them that you *MUST* tie the mode pins to either Vaux or GND.
> >After finding all the info in the data sheet and talking with support,
> >it looks pretty clear to me that the S3 parts have a very stiff
> >internal pull up and there is no need for an external pull up of any
> >kind, resistor or direct connection to Vaux.
> >
> >Am I misunderstanding?  Why did the factory tell us before that the
> >mode pins *MUST* be tied to Vaux?  Did we misunderstand what they were
> >saying?
> >
> >I promise this is the last time I will ask about this.  I am totally
> >sick of going around this loop with everyone here.
>
>
> We leave them open, slave serial. Works fine.

At last, a clear, rational statement.  Thanks.

I can't say that solves my problem though.  I have little doubt that
there is any issue to the pullups working if you just leave them open.
The fact that they are such a low resistance seems to me to make it a
near certainty that they will pull up properly if left open.

This board is currenly ready to come out of layout with the only
remaining issues, SI on the data and address bus which we think is due
to an overly agressive TI IBIS model, it does not match the units we
can measure; and this stupid pullup resistor issue.

There is little doubt in my mind that the stiff internal pullups make
an external pullup unnecessary.  I spoke with the engineer who had
spoken with the Xilinx factory person and I had trouble finishing a
sentance without being interrupted.  It is very likely that she
misunderstood what Xilinx was saying to her.  I expect she was told
that the pull *down* resistors needed to be tied directly to GND and/or
the distinction between the pull ups and pull downs was not made.  The
fact that the data sheet and app notes show direct connections to Vaux
and GND does not make the matter any more clear.

Just to be very clear that the difference between a resistor pullup and
a direct connection is not splitting hairs, we have a current part on a
board that does not work correctly because of a similar issue.  The pin
has three states for setting an I2C bus address; high, low and open.
Seems the part is having trouble distinguishing the difference between
high and open with most reistor values.  That data sheet also did not
make it clear what value resistor was required as well as the level of
noise immunity on the input.

That engineer is working a lot of unpaid overtime at the moment.  I
prefer to get this ironed out before I am done with layout and can
still make a change if *required*.


Article: 101397
Subject: Re: Book Software for XC3190A?
From: Phil Hays <Spampostmaster@comcast.net>
Date: Sun, 30 Apr 2006 07:59:33 -0700
Links: << >>  << T >>  << A >>
Josh Rosen wrote:

>If what you want to do is to learn how to design with FPGAs it's not
>necessary to actually build something. My suggestion would be to download
>a copy of Icarus Verilog (it's free) and a copy of the current Xilinx
>Webpack (also free). Do design in Verilog and debug it using Icarus. Then
>you can place and route it using Webpack. 21st century FPGA designers
>don't spend much time in the lab debugging on the actual hardware, the
>debugging is done using a Verilog simulator.

ModelSim XE starter is also a free simulator, and supports both VHDL
and Verilog.  Both languages are widely used.


--
Phil Hays
(Who is leaving on a trip today to get a Xilinx badge, among other
things.)


Article: 101398
Subject: Re: Book Software for XC3190A?
From: tuxfriend <tuxfriend@arcor.de>
Date: Sun, 30 Apr 2006 17:24:16 +0200
Links: << >>  << T >>  << A >>
> Software support for the 3000 series was dropped years ago. What's the
> copyright date on the book that you are looking at? If the copyright is
> from the early to mid-90s then the included software will support the 3000
> series. If the book has been updated in recent years the chances are they
> have a slightly obsolete version of Webpack included which won't support
> the 3000 series.
The Book is copyright 1999 and available at amazon.de:
http://www.amazon.de/exec/obidos/ASIN/0130216178/qid=1146409138/sr=8-10/ref=sr_8_xs_ap_i10_xgl/028-0087165-6861379
But for that ISBN there are 3 Versions of this book !?!?
http://dogbert.abebooks.com/servlet/SearchResults?isbn=0130216178

> If the book is from the early 90s, what media are the 
> included tools on? Early 90s PCs had 5 1/4" floppies, good luck finding a
> 5 1/4" floppy drive.
That is no problem, I have some of these in my personal museum ;)

> If it's on 3 1/2" floppies then you'll be able to 
> read them because 3 1/2" drives are still available, your system might
> even have on if it's more than 2 years old. If the software is on a CDROM
> that's a sure indicator that it won't have 3000 series support. By the
> time that CDROMs became the standard means of distributing software
> support for the 3000 series had already been dropped.
Oh, I think that will be the problem. 
> 

> If what you want to do is to learn how to design with FPGAs it's not
> necessary to actually build something. My suggestion would be to download
> a copy of Icarus Verilog (it's free) and a copy of the current Xilinx
> Webpack (also free). Do design in Verilog and debug it using Icarus. Then
> you can place and route it using Webpack. 21st century FPGA designers
> don't spend much time in the lab debugging on the actual hardware, the
> debugging is done using a Verilog simulator.
I would like to build something, and as I wrote before I did it with the
XC9536 now it should be a little bit more.

I think it would be the best I  try to find it in a library before to buy.

Thank you for the usefull information
tuxfriend


Article: 101399
Subject: design optimization
From: harikris@gmail.com
Date: 30 Apr 2006 09:14:31 -0700
Links: << >>  << T >>  << A >>
Hi,

 I am targeting the design for XC2C512 coolrunner device. That's the
biggest device i could find. Are you aware of any larger CPLD device?
I have a dual-edge triggered clock i.e i have no other CPLD choice
other than the coolrunner series.

 I find that i am falling short of a dozen macrocell counts. The
fitter report says it needs 524 macrocells and i have 512 macrocells
available to me :-(

 I have tried to optimize the design to my best possible knowledge (and
my knowledge is not that profound).

Can anybody here advise me on how to squeeze the design a LITTLE BIT
more
to make it fit into the XC2C512 device?

 Thanks.




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