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 34175

Article: 34175
Subject: Re: Replication of FFs in Xilinx XC4000
From: Phil Hays <spampostmaster@home.com>
Date: Thu, 16 Aug 2001 01:50:56 GMT
Links: << >>  << T >>  << A >>
Rick Collins wrote:
> 
> We are working on a design in an XC4000 about 64K gates and are having a
> problem with register replication. The P$R tool is replicating a FF that
> is the critical element of a cross clock domain synchronizer. I call
> this a "bad thing".
> 
> We looked at the Xilinx web site and found Answer #3813. This says that
> PAR can split a net and duplicate the FF driving it. Of course this will
> break a synchronizer, they even mention this. The solution is to use an
> environment variable to control this feature. This seems like a very odd
> way to control the PAR tool! Is there no option that can be set for
> this??? Has anyone else been bitten by this "issue"? Any other
> solutions?
> 
> I don't really understand why PAR wants to split this net. The
> synchronizer consists of two FFs on the same clock with an AND gate
> detecting the two FFs being of different values to generate a single
> clock wide pulse. The first FF output feeds only three inputs, yet this
> is the net that was split. Anyone understand why this is happening?

I've been bit by this, with a fanout of two(!).  I did the following:

1) Set the magic word (environment variable).  This alone would probably solve
the problem.

2) Forced the PAR tool to do the correct thing even if the magic word didn't
work:
LOCed the FF to a CLB
LOCed an unrelated FF to the same CLB (repeat for all similar synchronizer FFs)
(I could have RLOCed rather than LOCed for somewhat more reusable code.)
The FF will only be duplicated if the other FF in the CLB is unused.  This alone
would probably solve the problem.

3) Added one more stage to the synchronizer.  With a fanout of 1 the added FF
will not be duplicated.  This alone would probably solve the problem.

4) Verified that these FF were correctly built manually each time before
releasing a bit file.

Yea, this was more than a bit paranoid, but just because I'm paranoid doesn't
mean that something isn't out to get me.

The reason why this happens is that some programmer in X-land added an
optimization to PAR for XC4000's that will add a duplicate FF if any time or
routing resource can be saved.  This is good, if your design has a single
clock.  This is very evil if you have multiple clocks.


-- 
Phil Hays

Article: 34176
Subject: star-wars ascii-animation:)
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Thu, 16 Aug 2001 13:38:06 +1000
Links: << >>  << T >>  << A >>
http://www.asciimation.co.nz

Article: 34177
Subject: Re: Major performance problem with Modelsim
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Thu, 16 Aug 2001 04:44:52 GMT
Links: << >>  << T >>  << A >>
On 15 Aug 2001 14:10:31 -0700, fr_a69@hotmail.com (Frederic Antonin)
wrote:

>I discover a major performance problem with Modelsim
>
>When your simulating a design using a ram the memory array is usually
>describe that way in verilog:
>
>reg [mem_with - 1 :0] my_memory [0: mem_deep - 1];
>
>If your memory deep is more than a couple to hundred (mine is 521k for
>example)
>you can't even display a single memory location (16 bit) without
>having all your system ressources used and all you ram used (i have
>1Gb or ram and it use all)
>
>If you'r lucky and patient and you PC doesn't crash when you drag your
>memory location from the signal window to the wave window don't think
>your done.
>Running a simulation is just impossible the sumulator just rumm
>forever to do nothing.
>
>I think the worste about it is that I contact them to report the
>problem but they don't seems to care about it.
>
>If any of you know a "smart" simulator that is able to handle that
>kind of case let me know.

Fred,

You could try to work within the limitations of your simulator, and
modify your model of the ram to save its contents to a file when given
a command (e.g. an edge on a signal).  You can then look at the saved
file using your favourite editor.

That's how I do it, anyway.

Allan.

Article: 34178
Subject: Re: Replication of FFs in Xilinx XC4000
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Thu, 16 Aug 2001 06:20:32 -0000
Links: << >>  << T >>  << A >>

>We are working on a design in an XC4000 about 64K gates and are having a
>problem with register replication. The P$R tool is replicating a FF that
>is the critical element of a cross clock domain synchronizer. I call
>this a "bad thing". 

Did you spot this by eyeball?  Or did you encounter a problem and track
it back?

The normal synchronizer setup is a FF, a short wire, then another FF,
with both FFs running on the same clock.

So I assume it replicated the second FF.  I don't see any problem with
that as long as both wires from the first FF are short.  I would
get uncomfortable if it put the second FF on the opposite of the chip.
(I'd be uncomfortable with that even if it didn't replicate the FF.)

The idea is that the first FF may go metastable.  If so, you have
most of a clock cycle for it to stabalize.  You have to subtract
the setup time, the clock to output time, and the routing time from
the cycle time to get the stabalizing time.  Adding a second FF
shouldn't change that much.  If it matters you have much more
interesting problems.

Am I missing something?

-- 
These are my opinions, not necessarily my employeers.  I hate spam.


Article: 34179
Subject: Re: Slowing PCI for FPGA
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Thu, 16 Aug 2001 06:28:49 -0000
Links: << >>  << T >>  << A >>

>I am doing a prototype with a PCI interface and there isn't a prayer of
>making it work at 25mhz bus transfer (my slowest machine available)
>without a lot of effort. What would you do to easily slow things down?

You could try slowing down the crystal on the CPU (without telling it).


Here is a way to cheat.  Put a PCI-PCI bridge chip on your board.  It
will meet the specs for the main PCI bus.

Now comes the hard part.  You have to read the PCI specs enough to
understand their timing budget.  They allocate x ns for the signals
to get from one chip to another.  That's a big part of the cycle.

Since you just have the bridge chip and your chip on your own
private PCI bus, you can use that "get to the other chip" time
as extra setup time and/or to relax the clock-output time.


You can get 10% or so by just making sure your
VCC doesn't go low and that your chip doesn't get hot.

-- 
These are my opinions, not necessarily my employeers.  I hate spam.


Article: 34180
Subject: Re: Slowing PCI for FPGA
From: kevinbraceusenet@hotmail.com (Kevin Brace)
Date: 15 Aug 2001 23:31:33 -0700
Links: << >>  << T >>  << A >>
Although 5V PCI bus can run at any frequency between 0 to 33MHz, I
believe 25MHz is the lowest frequency you can get from most
motherboards (old Socket 5/7 motherboards offered this option to
accommodate Pentium 75MHz), and in newer motherboards, 33MHz seems to
be the only frequency supported.
How much logic simulation did you do before firing up the PCI board?
If your logic simulation went okay, but the board doesn't work when
you put it into the system, then your design is likely not meeting the
timings of the PCI specification.
Tsu (Input Setup Time to CLK) has to be within 7ns, and Tval (CLK to
Signal Valid Delay) has to be within 11ns.
Although the maximum for Ton (Float to Active Delay) is not specified
(minimum 2ns), in my opinion, it will nice to get that to within 11ns
(same as Tval).
        I recently fired up Insight Electronics Spartan II PCI
development board (http://www.insight-electronics.com/solutions/kits/xilinx/spartan-iipci.html)
with my own PCI IP core (I didn't use Xilinx's PCI IP core), and even
though the timing analyzer told me that some of the input signals 
require around 12ns Tsu, and around 15ns Tval for output signals, the
board was recognized as a PCI device by the BIOS, and Windows 98
detected the PCI card automatically at startup.
This means that the PCI card with my PCI IP core worked even though
the timings were not being met.
The motherboard had 430TX chipset on it, and the PCI bus ran at 33MHz.
My theory that the reason PCI card worked is that the PCI card used
some of the Tprop (10ns. bus propagation time (the time signals travel
on the PCB)) to meet the Tsu/Tval requirements.
For the P&R (Place & Route), I used the the one that came with
WebPack, and used only a User Constraint File to specify the timings I
wanted.
Since the PCI card with my PCI IP core that violated the timings
worked okay at 33MHz, I will suspect that your problem is not the
timings, but with your state machine design.




Regards,



Kevin Brace (don't respond to me directly, respond within the
newsgroup)




Joey Oravec <joey@sun.science.wayne.edu> wrote in message news:<9lesog$f65$1@cwis-1.wayne.edu>...
> Hi, surely somebody else has run into this before.
> 
> I am doing a prototype with a PCI interface and there isn't a prayer of
> making it work at 25mhz bus transfer (my slowest machine available)
> without a lot of effort. What would you do to easily slow things down? I
> know DINI group has a card for $600 that will halve the PCI clock and
> another for $3k which is more flexible. There's PCI-PCI bridge IP
> available but that's also expensive.
> 
> Unfortunately I'm cheap and I'm thinking there must be a better
> inexpensive solution. Any thoughts?

Article: 34181
Subject: Re: Replication of FFs in Xilinx XC4000
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Thu, 16 Aug 2001 07:43:31 +0100
Links: << >>  << T >>  << A >>


Phil Hays wrote:

<snip of perfectly reasonable paranoia, possibly not enough even>

>
> The reason why this happens is that some programmer in X-land added an
> optimization to PAR for XC4000's that will add a duplicate FF if any time or
> routing resource can be saved.  This is good, if your design has a single
> clock.  This is very evil if you have multiple clocks.
>
> --
> Phil Hays

... it would have been nice if the said programmer, just before he/she was sent to
"sleep with the fishes", had put some sort of message in the PAR report file.

Parenthetically this is a living breathing example of why the idea that you can
``leverage'' cheap s/w resource using things like Handle-C is a BAD IDEA.




Article: 34182
Subject: Re: Internal clock skew when using DLL
From: Philip Freidin <philip@fliptronics.com>
Date: Wed, 15 Aug 2001 23:45:20 -0700
Links: << >>  << T >>  << A >>
I created a test design to see what could be done. Here is a possible
solution:

33MHz mhz goes thru IBUFG then BUFG to be your clk_33

Output of IBUFG also goes to DCM CLKIN

DCM CLK2X goes to a BUFG, its output goes to CLKFB
DCM CLK2X180 goes to a BUFG, its output is your somewhat delayed CLK_66

(assume that the two BUFGs are reasonabbly matched. Remember that you
will be adding more loads to the CLK_66 net)

I ran the design successfully through M3.3.08i

Philip 

On Wed, 15 Aug 2001 14:06:36 -0400, "Jamie Sanderson" <jamie@nortelnetworks.com>
wrote:
>"Jamie Sanderson" <jamie@nortelnetworks.com> wrote in message
>news:9ledgn$gb5$1@bcarh8ab.ca.nortel.com...
>
>> I think what I'll do is use the CLK2X180 output, instead of CLK2X. I think
>> that allows me to use rising edge clocks everywhere, while providing a
>> quarter clock period of setup/hold between the clock domains.
>
>Hmm, this gives me a mapper error
>
>ERROR:MapLib:326 - DCM symbol "dcm0" (output signal=slow2x_clk) CLKFB is not
>
>driven by the CLK0 or CLK2X pin of the same DCM.
>
>Errors found during the mapping phase. Output files will not be written.
>
>That's annoying... Back to the drawing board.
>
>

Philip Freidin
Fliptronics

Article: 34183
Subject: Re: Replication of FFs in Xilinx XC4000
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Thu, 16 Aug 2001 06:58:22 GMT
Links: << >>  << T >>  << A >>
On Thu, 16 Aug 2001 06:20:32 -0000, hmurray-nospam@megapathdsl.net
(Hal Murray) wrote:

>
>>We are working on a design in an XC4000 about 64K gates and are having a
>>problem with register replication. The P$R tool is replicating a FF that
>>is the critical element of a cross clock domain synchronizer. I call
>>this a "bad thing". 
>
>Did you spot this by eyeball?  Or did you encounter a problem and track
>it back?
>
>The normal synchronizer setup is a FF, a short wire, then another FF,
>with both FFs running on the same clock.
>
>So I assume it replicated the second FF.  I don't see any problem with
>that as long as both wires from the first FF are short.  I would
>get uncomfortable if it put the second FF on the opposite of the chip.
>(I'd be uncomfortable with that even if it didn't replicate the FF.)
>
>The idea is that the first FF may go metastable.  If so, you have
>most of a clock cycle for it to stabalize.  You have to subtract
>the setup time, the clock to output time, and the routing time from
>the cycle time to get the stabalizing time.  Adding a second FF
>shouldn't change that much.  If it matters you have much more
>interesting problems.
>
>Am I missing something?

Yes.  The duplicated flip flops may settle to *different* values.

Allan.

Article: 34184
Subject: Re: star-wars ascii-animation:)
From: "Peter Seed" <spam magnet>
Date: Thu, 16 Aug 2001 08:15:07 +0100
Links: << >>  << T >>  << A >>
Even better

www.asciimation.co.nz\beer

Not sure what its got to do with embedded though...

Russell Shaw wrote in message <3B7B401E.E90A0168@iprimus.com.au>...
>http://www.asciimation.co.nz



Article: 34185
Subject: Re: Replication of FFs in Xilinx XC4000
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Thu, 16 Aug 2001 07:22:33 -0000
Links: << >>  << T >>  << A >>
> >Am I missing something?

> Yes.  The duplicated flip flops may settle to *different* values.

But if that happens, they one of them could just as easily have
gone metastable and the whole point of this circuit is to leave
enough time between FFs so that won't happen.

-- 
These are my opinions, not necessarily my employeers.  I hate spam.


Article: 34186
Subject: Development boards
From: John <john.daae@datarespons.no>
Date: Thu, 16 Aug 2001 09:23:55 +0200
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------97A4A7D504C3D951F6037440
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Do any of you kown some good starting point for finding FPGA development
boards. I have quite specific requirement such as PCI interface (or preferably
PMC interface), onboard (or SODIM) SDRAM (> 32MB) and lots of user IO (in
the range of 150 I/O). And I perfer using Xilinx.
<p>Thanks
<p>John
<br>&nbsp;</html>

--------------97A4A7D504C3D951F6037440
Content-Type: text/x-vcard; charset=us-ascii;
 name="john.daae.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John
Content-Disposition: attachment;
 filename="john.daae.vcf"

begin:vcard 
n:Daae;John
tel;cell:99 59 00 70 
tel;home:22 67 58 94
tel;work:67 11 20 89
x-mozilla-html:FALSE
url:http://www.datarespons.com/
org:Data Respons AS;Project Department
version:2.1
email;internet:John.Daae@datarespons.no
title:Senior Utviklingsingeniør
adr;quoted-printable:;;Ekebergveien 25 B=0D=0A0196 Oslo;;;;
fn:John Daae
end:vcard

--------------97A4A7D504C3D951F6037440--


Article: 34187
Subject: Readback Xilinx Vertex FPGA
From: walder@tik.ee.ethz.ch (Herbi)
Date: Thu, 16 Aug 2001 07:38:36 GMT
Links: << >>  << T >>  << A >>

Hi there

I'm trying to do readback (verify and capture) from Xilinx's Vertex devices.
Does anybody have some experiences with it???

We send the signals and readback commands according to Xilinx's XAPP138 but 
unfortunately, the FPGA only replys with  0xf9f1f3ff and after this all 
0xf9 ...
Obvioulsy, this is no meaningfull readback data.

Please help!!

Thanx
Herbi

Article: 34188
Subject: Re: Development boards
From: Lars Rzymianowicz <larsrzy@ti.uni-mannheim.de>
Date: Thu, 16 Aug 2001 09:45:21 +0200
Links: << >>  << T >>  << A >>
John wrote:
> Do any of you kown some good starting point for
> finding FPGA development boards.

http://www.optimagic.com -> Boards.

Lars
-- 
Address:  University of Mannheim; D7, 3-4; 68159 Mannheim, Germany
Tel:      +(49) 621 181-2716, Fax: -2713
email:    larsrzy@{ti.uni-mannheim.de, atoll-net.de, computer.org}
Homepage: http://mufasa.informatik.uni-mannheim.de/lsra/persons/lars/

Article: 34189
Subject: Help with ACEX1K100 device
From: "Andrew Gray" <s9813479@student.up.ac.za>
Date: Thu, 16 Aug 2001 09:47:07 +0200
Links: << >>  << T >>  << A >>
Hi

Can anyone tell me what the following pins are used for when they are not
used as user IO pins:

nCEO
CS
nCS
nRS
nWS
DEV_OE
DEV_nCLR
INIT_DONE
RDY_nBSY

Thank You

Andrew Gray




Article: 34190
Subject: Re: Replication of FFs in Xilinx XC4000
From: allan_herriman.hates.spam@agilent.com (Allan Herriman)
Date: Thu, 16 Aug 2001 07:52:37 GMT
Links: << >>  << T >>  << A >>
On Thu, 16 Aug 2001 07:22:33 -0000, hmurray-nospam@megapathdsl.net
(Hal Murray) wrote:

>> >Am I missing something?
>
>> Yes.  The duplicated flip flops may settle to *different* values.
>
>But if that happens, they one of them could just as easily have
>gone metastable and the whole point of this circuit is to leave
>enough time between FFs so that won't happen.

Oops.  I thought it was the first flip flop that was duplicated.

The second one is safe as long as sufficient time is allowed, as you
noted.

Allan.

Article: 34191
Subject: Re: Slowing PCI for FPGA
From: "Olaf Birkeland" <Olaf_Birkeland@coldmail.com>
Date: Thu, 16 Aug 2001 09:57:22 +0200
Links: << >>  << T >>  << A >>
Joey Oravec <joey@sun.science.wayne.edu> wrote in message
news:<9lesog$f65$1@cwis-1.wayne.edu>...
> Hi, surely somebody else has run into this before.
>
> I am doing a prototype with a PCI interface and there isn't a prayer of
> making it work at 25mhz bus transfer (my slowest machine available)
> without a lot of effort. What would you do to easily slow things down? I
> know DINI group has a card for $600 that will halve the PCI clock and
> another for $3k which is more flexible. There's PCI-PCI bridge IP
> available but that's also expensive.
>
> Unfortunately I'm cheap and I'm thinking there must be a better
> inexpensive solution. Any thoughts?

The safest option would be to get a motherboard that can be underclocked in
BIOS. I've successfully used the Abit SA6R, setting FSB to 60 MHz, clock
ratio to 4:4:1, resulting in 15 MHz PCI.

Alternatively, you can check if you motherboard is supported by CPUCooL
(http://www.podien.onlinehome.de/). It can change the PLL settings on many
motherboard, even if the BIOS doesn't support that. Even better, it can be
changed *runtime*, thus you can throttle your clock without rebooting
in-between each attempt (as long as you don't lock up the system.....)

Regards,
- Olaf



Article: 34192
Subject: Re: Help with ACEX1K100 device
From: walder@tik.ee.ethz.ch (Herbi)
Date: Thu, 16 Aug 2001 08:25:09 GMT
Links: << >>  << T >>  << A >>
In article <997947985.88785@nntp.up.ac.za>, "Andrew Gray" <s9813479@student.up.ac.za> wrote:
>Hi
>
>Can anyone tell me what the following pins are used for when they are not
>used as user IO pins:
>
>nCEO
>CS
>nCS
>nRS
>nWS
>DEV_OE
>DEV_nCLR
>INIT_DONE
>RDY_nBSY
>
>Thank You
>
>Andrew Gray
>
>
>


Hi Andrew

Please tell me the supplier's name of this device, then I probably can help 
you!
I've some experiences with Xilinx FPGAs. In this case, pins as CS means "Chip 
Select", INIT_DONE is used for clearing the device, etc. 
In general, some of the pins can be used either as configuration port or as 
general purpose/user pins.

cu
Herbi

Article: 34193
Subject: Re: Development boards
From: walder@tik.ee.ethz.ch (Herbi)
Date: Thu, 16 Aug 2001 08:28:22 GMT
Links: << >>  << T >>  << A >>
In article <3B7B750B.1C7D0C30@datarespons.no>, John <john.daae@datarespons.no> wrote:
>This is a multi-part message in MIME format.
>--------------97A4A7D504C3D951F6037440
>Content-Type: text/html; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
><html>
>Do any of you kown some good starting point for finding FPGA development
>boards. I have quite specific requirement such as PCI interface (or preferably
>PMC interface), onboard (or SODIM) SDRAM (> 32MB) and lots of user IO (in
>the range of 150 I/O). And I perfer using Xilinx.
><p>Thanks
><p>John
><br>&nbsp;</html>
>
>--------------97A4A7D504C3D951F6037440
>Content-Type: text/x-vcard; charset=us-ascii;
> name="john.daae.vcf"
>Content-Transfer-Encoding: 7bit
>Content-Description: Card for John
>Content-Disposition: attachment;
> filename="john.daae.vcf"
>
>begin:vcard 
>n:Daae;John
>tel;cell:99 59 00 70 
>tel;home:22 67 58 94
>tel;work:67 11 20 89
>x-mozilla-html:FALSE
>url:http://www.datarespons.com/
>org:Data Respons AS;Project Department
>version:2.1
>email;internet:John.Daae@datarespons.no
>title:Senior Utviklingsingeniør
>adr;quoted-printable:;;Ekebergveien 25 B=0D=0A0196 Oslo;;;;
>fn:John Daae
>end:vcard
>
>--------------97A4A7D504C3D951F6037440--
>

Hi there

Try out www.xess.com

We use the XSV-800 board from XESS and we're happy with it...  :-)

cu
Herbi

Article: 34194
Subject: Re: FPGA for Reconfigurable Computing
From: walder@tik.ee.ethz.ch (Herbi)
Date: Thu, 16 Aug 2001 08:40:29 GMT
Links: << >>  << T >>  << A >>
In article <97fd5b24.0108150319.36203c19@posting.google.com>, jhmorris47@hotmail.com (Jason) wrote:
>I'm just a newbie here and would like to know which FPGA would be best
>suited for reconfigurable computing in terms of logic units, speed of
>reconfigurability, etc. Any help would be appreciated.
>
>Thanks
>Jason H. Morris

Hi Jason

Of course, it depends on what exactly you plan to do with your FPGA.
I've some experiences with XILINX FPGAs Vertex Series. As you mentioned, you 
would like to do reconfiguration, these devices will be suitable for you. It's 
possible to dynamically and paritaly reconfigure, readback (verify and 
capture) etc. 
For more information, check out www.xilinx.com
There are also some "cool" prototyping boards from XESS (www.xess.com) 
available.

Hope this helps... :-)

cu
Herbi 

Article: 34195
Subject: Re: Help with ACEX1K100 device
From: Robert Staven <robert.staven@telenostra.com>
Date: Thu, 16 Aug 2001 11:11:58 +0200
Links: << >>  << T >>  << A >>
> Please tell me the supplier's name of this device

The ACEX1K is an Altera device

  )RST(

Article: 34196
Subject: Re: Help with ACEX1K100 device
From: "Andrew Gray" <s9813479@student.up.ac.za>
Date: Thu, 16 Aug 2001 11:39:20 +0200
Links: << >>  << T >>  << A >>
Hi

It is an Altera device:

Acex EP1K100

"Herbi" <walder@tik.ee.ethz.ch> wrote in message
news:3b7b8312$1@pfaff.ethz.ch...
> In article <997947985.88785@nntp.up.ac.za>, "Andrew Gray"
<s9813479@student.up.ac.za> wrote:
> >Hi
> >
> >Can anyone tell me what the following pins are used for when they are not
> >used as user IO pins:
> >
> >nCEO
> >CS
> >nCS
> >nRS
> >nWS
> >DEV_OE
> >DEV_nCLR
> >INIT_DONE
> >RDY_nBSY
> >
> >Thank You
> >
> >Andrew Gray
> >
> >
> >
>
>
> Hi Andrew
>
> Please tell me the supplier's name of this device, then I probably can
help
> you!
> I've some experiences with Xilinx FPGAs. In this case, pins as CS means
"Chip
> Select", INIT_DONE is used for clearing the device, etc.
> In general, some of the pins can be used either as configuration port or
as
> general purpose/user pins.
>
> cu
> Herbi



Article: 34197
Subject: Re: star-wars ascii-animation:)
From: Andrew <adpearson@optushome.com.au.nospam>
Date: Thu, 16 Aug 2001 11:36:19 GMT
Links: << >>  << T >>  << A >>
I like this guys jet powered beer cooler!!! 

http://www.asciimation.co.nz/beer


On Thu, 16 Aug 2001 13:38:06 +1000, Russell Shaw
<rjshaw@iprimus.com.au> wrote:

>http://www.asciimation.co.nz


Article: 34198
Subject: Re: Internal clock skew when using DLL
From: K.O <nospam@newsranger.com>
Date: Thu, 16 Aug 2001 11:37:27 GMT
Links: << >>  << T >>  << A >>
hi,

well, we will lose in terms of speed (till the half).

what about using the highest frequency to drive all the logic, and just CE for
the slower frequency ? (effect on power)

Do Xilinx approve this problem ? 
are they planning to tackle it ?

Regards



In article <3B7AAEDB.47875520@xilinx.com>, Peter Alfke says...
>
>Since your two clock frequencies are fundamentally phase-coherent, albeit
>perhaps with a certain unpredictable tolerance, you can cross the clock-domain
>boundary simply by using the opposite edge of the higher frequency clock. This
>does cut into your timing budget, but is safe otherwise.
>
>Peter Alfke
>
>



Article: 34199
Subject: Virtex-II and 5V devices
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Thu, 16 Aug 2001 14:34:24 +0200
Links: << >>  << T >>  << A >>
There is a Xilinx app note (vtt002) about using 5V devices with Virtex
devices but it states explicitely that this does not work with Virtex-II.

I need to connect some 5V AD devices to a Virtex-II. The ADs are TTL
compatible so no pb to drive them from the Virtex-II but I have to read
values form these ADs.

So what are the solutions for this ? (small ones please...)

Thanks

Marc Battyani






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