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 89275

Article: 89275
Subject: Re: implementing the tristate bus
From: stud_lang_jap@yahoo.com
Date: 9 Sep 2005 17:45:03 -0700
Links: << >>  << T >>  << A >>
Hello Vladislav,

Thanks for the reply.

Yes i also think my implementation is correct. I have ported it to FPGA
and i am facing the same problem.
I am able to read the internal  register (reset value) in only slave
interface but if i trisatate the bus for
interfacing the master and slave i reading all zeros. After probing the
internal signal through chipscope
i came to know that all the signal which i am tristating is being
connected to ground.
I am using synplify for synthesis and then EDF being implemented on
ISE.

Thanks and regards
williams


Article: 89276
Subject: Re: Cyclone conf flash - 25p10 !
From: "Luis Cupido" <cupidoREMOVE@REMOVEua.pt>
Date: Sat, 10 Sep 2005 02:27:35 +0100
Links: << >>  << T >>  << A >>
Folks,

The 25P10A from ST do work fine.

> Looking at the *.pof for a Cyclone configured to load from an EPCS4, the
> string EPCS4 is included at the start.

Yes the *.pof  knows what is the target device.

> I'm not sure of why I think this, but I've an idea that the devices check
> the device ID at the start of config, although this might be wrong.

That info on the *.pof file is for the programmer soft-module to know how to
program, and that doesn't go into the device.

> If this is the case you'd have to use a device with the same ID.

The Cyclone device check the device ID to know how much data it
may have to load, just that... I think.

I can't tell what ID's are recognized by the Cyclone load engine... but
at least the ones corresponding to the EPCS1 and EPCS4 are for sure.


The bottom line is still, ST25P10A has the exact same ID as the EPCS1 and 
quartus II
still fails to load them.
However is a fact that once programmed (by other means) Cyclone devices
do read them without trouble.


Luis C.



"Nial Stewart" <nial@nialstewartdevelopments.co.uk> wrote in message 
news:4321c8d9$0$21184$db0fefd9@news.zen.co.uk...
>> I have no idea which of these parts might work. The SST parts are pin
>> compatible but have different IDs. They probably cannot program from
>> quartus but they might read OK.
>
>
> Looking at the *.pof for a Cyclone configured to load from an EPCS4, the
> string EPCS4 is included at the start.
>
> I'm not sure of why I think this, but I've an idea that the devices check
> the device ID at the start of config, although this might be wrong.
>
> If this is the case you'd have to use a device with the same ID.
>
>
> Nial.
>
>
>
> -------------------------------------------------------------
> Nial Stewart Developments Ltd
> FPGA and High Speed Digital Design
> www.nialstewartdevelopments.co.uk
> 



Article: 89277
Subject: Re: Reading a PAL fusemap with a microscope
From: "logjam" <grant@cmosxray.com>
Date: 9 Sep 2005 19:27:52 -0700
Links: << >>  << T >>  << A >>
I'm very excited to be traveling home Saturday!  To see the chip!  :)

The inputs to the chip are:

01 - CLK - 16MHz
02 - I - D0
03 - I - D1
04 - I - D2
05 - I - D3
06 - I - D4
07 - I - D5
08 - I - /DMA
09 - I - TC
11 - /OE - TSEN

12 - R - /DMALD
13 - R - PWM
14 - R - NC
15 - R - NC
16 - R - NC
17 - R - NC
18 - R - NC
19 - R - NC

So its a pretty simple device.  I'm going to try to ignore those output
pins when I am reading the device.  I want to make sure I try doing
this blind.  :)


Article: 89278
Subject: Re: implementing the tristate bus
From: "vssumesh" <vssumesh_asic@yahoo.com>
Date: 9 Sep 2005 21:50:17 -0700
Links: << >>  << T >>  << A >>
Please go through the topic "Disconnect the FPGA I/O pads from the
outside world". I think our problem is similar.


Article: 89279
Subject: Re: Best FPGA for floating point performance
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 09 Sep 2005 22:11:55 -0700
Links: << >>  << T >>  << A >>
Marc Battyani wrote:

(snip)

> In fact I'm not sure that full IEEE floating point accuracy is needed. For
> sure single precision is not enough but probably double precision is not
> really needed. The problem is that people who write the algorithms do it in
> C(++) using double precision floats and they use double precision libraries,
> etc. So it's not obvious to see what precision is really needed. After all
> in an FPGA we can use the exact number of bit needed. (In fact it is even
> possible that a fixed point format could work)

If fixed point will do it, even significantly wider than floating
point, it is likely the best way.  Floating point add is a lot more 
expensive than fixed point.  The difference is much smaller for
multiply and divide, not counting any overhead specific to full IEEE 
implementations.

-- glen


Article: 89280
Subject: Re: Need advice: old Xilinx schematic design -> VHDL...GSR issue(s)
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Fri, 09 Sep 2005 22:21:23 -0700
Links: << >>  << T >>  << A >>
Bob Myers wrote:

> I'm used to having an external reset line feed one of the pins, that
> could be
> specified to Leonardo 4.22 as the global_sr signal.

Actually, Leo will find the external reset and put
it on a global line for you if you use a standard
synchronous template.

> When I try to read in the design, I get told by Leonardo that the GSR
> net name
> that I'm using does not have a source --> looking at the schematic
> viewer, I
> find that all of the GSR nets get grounded.

Use of the GSR in your design description
is optional and the Leo default
is to not use it. I think this is a good thing
as it makes your design more portable and
easier to simulate.

Consider using an external pin for reset.

       -- Mike Treseler

Article: 89281
Subject: future of antifuse fpgas?
From: Adam Megacz <megacz@cs.berkeley.edu>
Date: Fri, 09 Sep 2005 23:38:15 -0700
Links: << >>  << T >>  << A >>

Does anybody have a general feel for whether or not Actel (or any
other vendor) is going to bring out a new generation of antifuse fpgas
on a newer process (90nm)?  Or has this device style basically been
shelved as only a specialty item for people who are ultra-sensitive to
soft errors above all other factors?

I'm mainly curious about whether or not the speed advantages will
continue on newer processes.  In theory, an antifuse should have less
capacitance than an SRAM-based pip, giving you lower propagation
delays and hence higher clock rates.  It looks like this was probably
true doing a 150nm-to-150nm comparison of the Axcellerator versus
FPGAs made on a similar generation of process technology.

However, I have to believe that the antifuse stuff requires a special
process/fab, and that fab isn't going to be doing anywhere close to
the volume that a strictly-CMOS fab would.  That in turn drives up
prices or else forces compromises that affect performance (in order to
bring down costs).

So, ultimately, I'm wondering how this will play out.  Obviously any
comments at this point are pure speculation, but I'd appreciate
speculation from somebody who knows more about this stuff than myself.

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

Article: 89282
Subject: Re: creating a custom opb bus master
From: Paul Hartke <phartke@Stanford.EDU>
Date: Sat, 10 Sep 2005 00:01:52 -0700
Links: << >>  << T >>  << A >>
I'm the guy that usually says to use the wizard but its not appropriate
for your case.  Directly implementing an opb master is quite
straightforward--plb is more complicated.  The CoreConnect OPB Bus
specification will give you all the signals, but OPB has a pretty simple
request-grant scheme.

A colleague created a master in HDL to interface with the opb_ddr
controller.  It was only a couple of lines of code.  

Paul 

"arincm@hotmail.com" wrote:
> 
> Hello fpga-faq,
> 
> I want to create a user module that will act as a master on an opb bus.
>  I am using xilinx Platform Studio, version 7.1i. Now before you say
> it, I have read the http://www.xilinx.com/ise/embedded/est_rm.pdf guide
> on using the create/import wizard for xps.  I have read it, and seen
> the skeleton, but have not been successful with a master bus.  I have
> created a custom slave module, and succeeded...
> Has anyone done this?  I just want some sample code that does anything
> as a master on an opb bus.
> In case it is not clear why this would be a good thing, there are many
> edk tools that will only work over an opb bus- but in many fpga
> designs, you don't really need a processor, just custom code.  All I
> want is the edk uartlite over a opb bus, but I have to be the opb
> master to do it.
> 
> thank you,
> ~arin

Article: 89283
Subject: Re: Has anyone successfully used opencores PCI in FPGA desings?
From: Kevin Brace <sa0les1@brac2ed3esi4gns5olut6ions.com>
Date: Sat, 10 Sep 2005 08:07:15 GMT
Links: << >>  << T >>  << A >>
Hi Robert,

I am not sure this is what you are looking for, but my company Brace 
Design Solutions has just released a Xilinx (TM) LogiCORE (TM) PCI 
compatible PCI IP core called BDS XPCI PCI IP core.
BDS XPCI32 PCI IP core is available for as little as $100 for 
non-commercial, personal use, and the 64-bit version BDS XPCI64 PCI IP 
core (Includes BDS XPCI32 PCI IP core) goes for $200.
Obviously, this version is going to restrict the use to non-commercial, 
personal use, but that shouldn't be a problem for FPGA beginners, FPGA 
hobbyists, computer hardware enthusiasts, or student graduation projects.
With this PCI IP core, almost anyone can make their own PCI device for 
as little as $400. ($275 Insight Electronics Spartan-II 200 PCI 
Development Kit + $100 BDS XPCI32 PCI IP core.)
Insight Electronics Spartan-II 200 PCI Development Kit is fully 
supported by this PCI IP core, and Avnet Xilinx Spartan-3 Evaluation Kit 
support will be added in the future. (The PCI IP core works fine with 
Spartan-3.)
For commercial users who want to modify BDS XPCI PCI IP core or want to 
convert a design that uses Xilinx LogiCORE PCI to an ASIC, BDS XPCI PCI 
IP core is available in Verilog HDL RTL, although it isn't cheap like 
the non-commercial, personal use version.
For more information, visit Brace Design Solutions website at 
http://www.bracedesignsolutions.com.


Kevin Brace



Robert wrote:
> Hi!
> 
> Has anyone successfully used opencores PCI in FPGA desings?
> 
> I have seen this question posted a few years ago and I would like to
> see if there  are new answers to it.
> 


-- 
Brace Design Solutions
Xilinx (TM) LogiCORE (TM) PCI compatible BDS XPCI PCI IP core available 
for as little as $100 for non-commercial, personal use.
http://www.bracedesignsolutions.com

Xilinx and LogiCORE are registered trademarks of Xilinx, Inc.

Article: 89284
Subject: Re: Fastest input IOB on a Spartan-3?
From: austin <austin@xilinx.com>
Date: Sat, 10 Sep 2005 08:00:42 -0700
Links: << >>  << T >>  << A >>
Brian,

Thanks for your comments.

All accurate.

Why they The ML450 pcb team) used the external 100 ohms is beyond me. 
If we don't meet the C spec, then why bother to be concerned about the R 
spec.

You are correct instating the resukts work better with the internal R.

We'd love to "slim down" the IOBs.  Anyone have a list of standards that 
are useless?  Seems like there are a few out there that folks don't use 
much, but then again ...

Austin

Brian Davis wrote:

> Austin wrote:
> 
>>It really is 5pF across 100 ohms
>>
> 
> 
>  As presently documented in your datasheets and IBIS files, it's
> really two 10 pFs in shunt to ground across a 100 ohm +/-20% R.
> 
>  It may appeal to your inner marketeer to call it 5 pF, but that
> won't make your parts work any better.
> 
>  If you're going to continue to 'correct' folks who quote your
> own documentation, at least have the technical honesty to point
> out that modeling two shunt C's as an across-the-pair 1/2 C is
> ONLY valid if the input signal is perfectly differential.
> 
>  Here's to hoping that when you eventually publish S3E IBIS and
> SSO info, those slimmed-down DCI-less I/O buffers have a lower C.
> ( And I'd still love to see some of the smaller S3E parts appear
> in a ground-paddle VQFP or QFN package )
> 
> 
>>As well, "they" use an external 100 ohms for all their simulations,
>>where we recommend use of the internal 100 ohms for all high speed
>>interfaces (really makes things look worse due to the stub).
>>
> 
> 
>  Perhaps you should review your own documentation before throwing
> stones at others.
> 
>  The last time we went round on this, you pointed to the ML450 V4
> evaluation board as a shining example of SI design.
> 
>  If you look at the ML450 schematic, BOM, and board layout, you'll
> notice that the HyperTransport input lines are terminated using
> external 100 ohm resistors, with stub lengths of about half an inch.
> 
>  Maybe this was done because you can't meet the HyperTransport +/- 10%
> terminator R spec with the _DT terminators, but I'd wager that the
> internal R's would work better than those big stubs, especially with
> the non-compliant Cin values of your HyperTransport inputs.
> 
>  I didn't spot any supporting IBIS sims for the ML450 layout anywhere;
> perhaps you could publish some 500 MT/s and 1 GT/s simulations in
> the user guide, using a fast HyperTransport compliant driver, with
> waveforms plotted both at the internal FPGA Rx and at a HyperTransport
> bus probe connector on the driving board :)
> 
>  From HyperTransport 2.0:
> 
>   internal terminator Rt           : 100 ohm +/- 10%
> 
>   single ended Cin (400-800 MT/s)  : 5 pF
>   single ended Cin (1-2 GT/s)      : 2 pF
> 
>   single ended Cout (400-800 MT/s) : 5 pF
>   single ended Cout (1-2 GT/s)     : 3 pF
> 
>  Any mention of HyperTransport in your datsheets, app notes, and
> user guides should be appropriately footnoted as non-compliant.
> 
> 
> Brian
> 

Article: 89285
Subject: Re: future of antifuse fpgas?
From: austin <austin@xilinx.com>
Date: Sat, 10 Sep 2005 08:08:49 -0700
Links: << >>  << T >>  << A >>
Adam,

I think you have it well understood.

I am sure there is work on better and smaller efuse technologies, as 
even non-fuse based FPGAs may use fuses (for redundancy).  Also, ASICs 
and ASSPs use fuses for redundancy, repair, and setting bias voltages.

A big fuse cell is a pain in the neck.  Smaller is better.

However, right now Actel has a bigger problem:  the issue of their fuses 
blowing on their parts (see NASA/JPL advisory notice 'do not use') due 
to SI issues (large overshoot/undershoot on IOs).  They have claimed 
this is solved, and is not a problem on any family other than the one 
affected, but it has had a huge sobering effect on the fuse FPGA 
mil-aero community ("how can I ever trust these parts ever again? my 
mission was scrapped ... I lost my job because the contract was 
canceled" - heard in the hallways of JPL ...).

I love fuses, when they work.

Austin

Adam Megacz wrote:

> Does anybody have a general feel for whether or not Actel (or any
> other vendor) is going to bring out a new generation of antifuse fpgas
> on a newer process (90nm)?  Or has this device style basically been
> shelved as only a specialty item for people who are ultra-sensitive to
> soft errors above all other factors?
> 
> I'm mainly curious about whether or not the speed advantages will
> continue on newer processes.  In theory, an antifuse should have less
> capacitance than an SRAM-based pip, giving you lower propagation
> delays and hence higher clock rates.  It looks like this was probably
> true doing a 150nm-to-150nm comparison of the Axcellerator versus
> FPGAs made on a similar generation of process technology.
> 
> However, I have to believe that the antifuse stuff requires a special
> process/fab, and that fab isn't going to be doing anywhere close to
> the volume that a strictly-CMOS fab would.  That in turn drives up
> prices or else forces compromises that affect performance (in order to
> bring down costs).
> 
> So, ultimately, I'm wondering how this will play out.  Obviously any
> comments at this point are pure speculation, but I'd appreciate
> speculation from somebody who knows more about this stuff than myself.
> 
>   - a
> 

Article: 89286
Subject: Re: creating a custom opb bus master
From: "beeraka@gmail.com" <beeraka@gmail.com>
Date: 10 Sep 2005 11:28:08 -0700
Links: << >>  << T >>  << A >>
Hi ,
      Do u have Xilinx EDK 6.2 tools, in case u have them then , if u
go to /hw/XilinxReferenceDesigns/pcores/opb_core_msp0_v1_00_b/ , thats
nothing but a OPB Bus Master design with Write capability. The only
catch is that it uses a very old version of IPIF. If you are ok with
that then you can go ahead and use it.
       In case u dont have EDK 6.2 , then just send me an e-mail and I
can tar the file and send it to you ..

--
Parag Beeraka


Article: 89287
Subject: Which JTAG cable for Xilinx & Linux?
From: Ram <r_fpga_dev@yahoo.com>
Date: Sun, 11 Sep 2005 01:22:51 GMT
Links: << >>  << T >>  << A >>
Hi,

I have an old Xilinx XChecker Serial cable which has served me well. 
Apparently (not that I can tell) and unfortunately, it is not supported in
the newer ISE 7.1i tools.

Which cable do you guys suggest to use?  My only real restriction is that it
needs to work with Linux / Linux versions of the ISE 7.1i tools.  USB
cables seem too flaky, but maybe that's changed?

I'm also wondering if I should consider the Chameleon POD which can emulate
many useful JTAG adaptors.

Ideas?

Thanks.
RAM

Article: 89288
Subject: Re: Signed addition
From: "Simon Peacock" <simon$actrix.co.nz>
Date: Sun, 11 Sep 2005 18:40:39 +1200
Links: << >>  << T >>  << A >>
you could make them all signed... but have you ever looked at symplify's
output?  if you use a signed 8 bit number for a counter counting from 0 to
255, then it will generate a 'warning count<8> is not used'
I personally check every warning and every error... I've had designs
producing several hundred warnings ... all of which are just junk (code
portability).  but try to get it down to less than 20 warnings by the time
the project is finished.  so I will stick to signed types.. and unsigned
types... unsigned by default as unsigned math is easier and signed only when
absolutely necessary

Simon


"Marko" <cantsay@comcast.net> wrote in message
news:gea3i15r0ucrnuggagmil1ug8jj7v22669@4ax.com...
> In Verilog, I do it by defining all variables as signed.  Then it's
> automatic.
>
> reg         [7:0] p1;
> reg         [7:0] p2
> wire signed [8:0] p1s;
> wire signed [8:0] p2s;
> wire signed [8:0] diff;
>
> assign p1s = p1;
> assign p2s = p2;
> assign diff = p1s - p2s;
>
> Notice that I made all variables 9-bits to ensure that values up to
> 255 will be treated as positive numbers and so that the result can
> represent the full range of -255 to +255.
>
> Marko
>
>
> On Wed, 7 Sep 2005 06:21:37 +0200, "news.green.ch" <rb@freesurf.ch>
> wrote:
>
> >Hi
> >I'am a newbe, and know how to add unsigned numbers in Verilog HDL, but
how
> >to define a signed number?
> >I've the following situation:
> >
> >reg [7..0] p1 //(is an unsigned value from AD converter) 0..255
> >reg [7..0] p2 // is the unsigned value that we should have 0..255
> >
> >now I want to substract p1-p2, to have the differenz, to correct the
error
> >reg[7..0] diff //should be a signed value
> >
> >how do I define this in Verilog HDL
> >
> >
> >best regards remo
> >
> >
> >
> >----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet
News==----
> >http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+
Newsgroups
> >----= East and West-Coast Server Farms - Total Privacy via Encryption
=----
>



Article: 89289
Subject: Re: Which JTAG cable for Xilinx & Linux?
From: Grahame Kelly <nospam-news@wildpossum.com>
Date: Mon, 12 Sep 2005 00:23:22 +1000
Links: << >>  << T >>  << A >>
Ram wrote:

> Hi,
> 
> I have an old Xilinx XChecker Serial cable which has served me well.
> Apparently (not that I can tell) and unfortunately, it is not supported in
> the newer ISE 7.1i tools.
> 
> Which cable do you guys suggest to use?  My only real restriction is that
> it
> needs to work with Linux / Linux versions of the ISE 7.1i tools.  USB
> cables seem too flaky, but maybe that's changed?
> 
> I'm also wondering if I should consider the Chameleon POD which can
> emulate many useful JTAG adaptors.
> 

Hi RAM.

The Xilinx CPLD=DK I got last week from Xilinx Jtag Cable connects to the
DB25 Pin parallel port and works correctly on ISEi 7.1 and 7.1.1a.

http://toolbox.xilinx.com/docsan/data/alliance/jtg/fig26.htm

gives it all to you. On the RHS of the schematic there are two pinouts. Top
one is for direct connect to CPLD Jtag SIL header, the bottom RHS
connection is for the FPGA connection.

Hope this assists you. 
-------------
Cheers Grahame


Article: 89290
Subject: Re: Need advice: old Xilinx schematic design -> VHDL...GSR issue(s)
From: Duane Clark <dclark@junkmail.com>
Date: Sun, 11 Sep 2005 16:29:47 GMT
Links: << >>  << T >>  << A >>
Bob Myers wrote:
> I have converted an old Xilinx schematic design into VHDL.  However, 
> I'm running into a problem with how to implement the GSR function 
> properly.
> 
> I'm used to having an external reset line feed one of the pins, that
>  could be specified to Leonardo 4.22 as the global_sr signal.  This 
> design, however, used an internally generated pulse from the 
> configuration section to pulse the registers.
> 

The method I use in VHDL to implement the GSR is to instantiate within 
the design a ROC primitive (which is in the Xilinx unisim library). All 
of the Xilinx tools for many years have understood that this net is the 
GSR, and I would assume that Leonardo would too. ROC simply outputs a 
reset pulse of a few 100nS, just like the real GSR.

-- synthesis translate_off
library UNISIM;
use UNISIM.VCOMPONENTS.ALL;
-- synthesis translate_on

...
    component roc
       port (
       O    : out std_logic
       );
    end component;

...
    roc_e: roc
    port map(
       O => RESET
    );

Article: 89291
Subject: Block RAM problem (spartan 3)
From: ni.neofpga@gmail.com
Date: 11 Sep 2005 13:41:09 -0700
Links: << >>  << T >>  << A >>
Hey
i have spartan 3 and i wanna know about Block RAM available with
it.from xilinx website i came to know that i have 12 number of 18Kb
block's .
now i want to use 4 blocks for my work .
how to instantiate all these 4 . just give me a sample of that
(my confusion is with the module name .... what will be the name of
these 4 ) if i want to use  SelectRAM_A9_B9 , just tell me how to
instantiate it

another problem is if i want to make a block of 8k . now i need 4
numbers of 2k blocks . how to group these 4 .

u just give me example of joining 2 blocks , i will do the rest.

what is DCM and how to use it with spartan FPGA ??

 

nitin


Article: 89292
Subject: Re: Has anyone successfully used opencores PCI in FPGA desings?
From: Mark McDougall <markm@vl.com.au>
Date: Mon, 12 Sep 2005 10:18:15 +1000
Links: << >>  << T >>  << A >>
Robert wrote:

> Has anyone successfully used opencores PCI in FPGA desings?

Yes, we're using one atm. It is yet to be released but is fully functional.

Regards,
Mark

Article: 89293
Subject: Re: Reading a PAL fusemap with a microscope
From: "logjam" <grant@cmosxray.com>
Date: 11 Sep 2005 18:29:23 -0700
Links: << >>  << T >>  << A >>
When I got home I tried to take my own higher resolution pictures, but
it seems the chip has corroded...?  Or maybe my imaging technique is
bad.  Take a look:
http://media.diywelder.com/images3/091105-40xASG_DSCF0724.jpg

I am going to the university on Monday to use ther metallurgy
microscope.  It has a video camera mounted to it, and will go higher
than 40x.

Here is an image I took with a 40x microscope with my 3x camera zoomed
held to the eye piece  ;)  I'm pretty sure I'm zoomed in on the block
for pin 7.

http://media.diywelder.com/images3/091105-findingthemap_DSCF0724.jpg

And this is what the block should look like empty.  I'm having a hard
time locating the input and output feedback connections.  They don't
seem to be where I'd expect them.

http://media.diywelder.com/images3/091105-pin7fusemap.jpg

Here is an image showing how I identified the pins:

http://media.diywelder.com/images3/091105-ASGwithpinout.jpg

Is the gold blob I identified a fuse that has not been removed? Or in
this case since its a HAL a fuse that was deposited?  HALs probably
just wouldn't have a fuse where as a pal should have one burnt?

Any suggestions at all?  And is there a chance with this HAL that its
fusemap visually would be different from the datasheet organization or
a regular PAL?  Since its not programmed but manufactured at a factory?

Any industry contacts anyone could recomend?  I'd love to figure this
out.  :)  I'll try to get some better pictures on Monday.


Article: 89294
Subject: Re: future of antifuse fpgas?
From: Adam Megacz <megacz@cs.berkeley.edu>
Date: Sun, 11 Sep 2005 20:07:38 -0700
Links: << >>  << T >>  << A >>

austin <austin@xilinx.com> writes:
> However, right now Actel has a bigger problem:  the issue of their
> fuses blowing on their parts

Yeah, although this is the part of the whole antifuse debate that
kinda annoys me.  Whenever the issue comes up, people only talk about
reliability and radiation.  Obviously those are important for a really
big market, but not for me.

Right now I'm interested in prototyping new/alternative fabrics for
FPGAs.  Short of doing a MOSIS run (which I will do eventually -- just
not yet), I'm trying to figure out the best way to do a mock-up
prototype.

All I care about is speed (aka propagation delay), size, and the
ability to map my "virtual CLBs" efficiently.  I only need to program
the device once.  Given those (admittedly unusual) constraints, I'm
trying to evaluate what's out there.  Additionally, most of my stuff
will be QDI self-timed, so clock distribution innovations aren't a big
feature for me.

> I love fuses, when they work.

Now Austin, you wouldn't be FUDding us just a *leeetle* bit there now
would you? ;)

Thanks for the reply though!

  - a

Article: 89295
Subject: several ucf files?
From: Stephane <stephane@nospam.fr>
Date: Mon, 12 Sep 2005 11:08:08 +0200
Links: << >>  << T >>  << A >>
How to manage several ucf files when working with different projects on 
the same chip?

i.e.  top_pads.ucf, that is always the same
and top_area_1.ucf or top_area2.ucf

any 'include' directive?

Article: 89296
Subject: SDRAM quality
From: Jon Schneider <jon@jschneider.tenreversed>
Date: Mon, 12 Sep 2005 10:16:35 +0100
Links: << >>  << T >>  << A >>
I've got my design talking to some (Kingston) KVR133X64/1G SDRAM
modules and running at only 66MHz, doing some simple testing (the
data=address or maybe data={address,address}) and have found some funnies.

There are a few dozen single bit errors. There are also several
locations that come back with some F digits (as if the cells just
don't exist). Also they are mid-burst as much as not which indicates
it isn't a timing problem.

I have done testing on different FPGAs with different SDRAM modules
and the errors definitely go with the modules and are quite
repeatable.

I have checked the refresh timing and it's good.

Is Kingston SDRAM really that bad ? The fact they are made of
repainted Infineon chips such that you can't read the original part
number makes me suspicious that these might not be the real
thing. They claim 100% testing but I wonder what they do with modules
tested as bad. Is it because the FPGA can keep memory busy in a way a
processor can't ? Should I speed up the refresh ? We intend to try
some Micron parts anyway.

Jon

Article: 89297
Subject: Fatal errror in ISE 6.3 i
From: stud_lang_jap@yahoo.com
Date: 12 Sep 2005 03:35:12 -0700
Links: << >>  << T >>  << A >>
Hello Guys,

I am facing fatal error when i am synthesizing my RTL code. The same
code gets synthesized in synplify but not in ISE 6.3i.
I tried my luck for finding the answer in xilinx site but found no
information about.

FATAL_ERROR:Xst:Portability/export/Port_Main.h:127:1.13 - This
application has discovered an exceptional condition from which it
cannot recover.

Has anyone faced this type of problem. Can you please suggest how can i
solve this problem.

Thanks and Regards
Williams


Article: 89298
Subject: place and route
From: "=?iso-8859-1?B?R2FMYUt0SWtVc5k=?=" <taileb.mehdi@gmail.com>
Date: 12 Sep 2005 04:03:26 -0700
Links: << >>  << T >>  << A >>
Hi!
Is there a way to write a placer and router for Xilinx FPGAs. Or the
FPGA technology is closed at this level ??


Article: 89299
Subject: Re: Fatal errror in ISE 6.3 i
From: Sean Durkin <smd@despammed.com>
Date: Mon, 12 Sep 2005 13:33:43 +0200
Links: << >>  << T >>  << A >>
stud_lang_jap@yahoo.com wrote:
> FATAL_ERROR:Xst:Portability/export/Port_Main.h:127:1.13 - This
> application has discovered an exceptional condition from which it
> cannot recover.
I would start at having a closer look at the synthesis report file. Most
of the time when something like that happens there are earlier error or
warning messages that could hint at what's really wrong. You can open
the synthesis report either in ISE (but there the function to display it
usually only works when there are no fatal erros) or by opening the
*.syr-file ISE creates in your project directory with a text editor.

Maybe there are some clues there. Otherwise, there's really not much you
can do... FATAL_ERRORS are supossed to only show up when there's
something really terribly wrong somewhere... Mostly, bugs in the software...

Plus, have you looked at Xilinx Answer Records on
http://support.xilinx.com ? This looks similar to your problem, although
the ISE version doesn't match:

http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=17481

cu,
Sean



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