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 98725

Article: 98725
Subject: Re: FPGA imple. of aes
From: fpga_toys@yahoo.com
Date: 15 Mar 2006 06:28:23 -0800
Links: << >>  << T >>  << A >>

fpga_toys@yahoo.com wrote:
> Allan Herriman wrote:
> > How about inferring BRAM for the sboxes?  That's what many
> > implementations do.  (I'm assuming the point of the exercise is to
> > compare the results of an implementation written in C with one written
> > in a more conventional HDL.)
>
> May seem strange, but the point wasn't to do a head to head comparison
> with other HDL's. I've some interest in crypto algorithms and have been
> on a search for "projects" which I can use as examples for the FpgaC
> release.  The changes for technology mapping F5/F6 muxes has been on my
> list since last summer. AES and PCI examples just drove the point home
> it should be now, not later.

Well after a few hours of google I did find:
       http://web.nps.navy.mil/~dcanrig/pub/sboxalg.c

Which after some serious hacking to reduce to define macros compiles
into just over a hundred luts or so, about a 15-20% savings over using
LUT rams and MUX's which would be a little over 128 LUT's per Sbox. I
suspect with some floorplanning that's faster than routing to use
BRAMs.

He has some HDL for the same algorithm, so when I'm done we can do a
head to head with XST.


Article: 98726
Subject: Re: Variable problem
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Wed, 15 Mar 2006 06:49:17 -0800
Links: << >>  << T >>  << A >>
ywz.oct13@gmail.com wrote:

> the question is if i do not use variable for the 1st mtd; hw else can i
> do to get rid of that error.
> Is there a data type which i can use to make it work? or is there
> something which i overlooked? 

The variable declaration must be inside
a process and must include a type.
See the testbench here:

    http://home.comcast.net/~mike_treseler/

Article: 98727
Subject: Re: Question about multi write ports RAM in FPGA?
From: "fpga" <hy34@njit.edu>
Date: 15 Mar 2006 07:31:26 -0800
Links: << >>  << T >>  << A >>
I got the listed number, say, 287.9Mhz and 72Mhz without put the multi
RAM block into the  data pipeline. That's why I don't understnd why the
maximum frequency of clk isn't 1/3 of that of clkx3. Because in the
whole synthesis, the usage of clk is to provide the input to DCM, which
generates clkx3.
Will it bother you too much if I put my code here? 
Thanks a lot.


Article: 98728
Subject: Re: About Altera FPGA Board
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Wed, 15 Mar 2006 16:35:29 +0100
Links: << >>  << T >>  << A >>
laura_pretty05@yahoo.com.hk wrote:

> My Altera FPGA boards is UP2 development kit-programmable logic for
> education, with MAX EPM7128S &FLEX 10K EPF10K70 devices.

Look at the board: there all pins of the FLEX_EXPAN_X pin rows are 
numbered. (Only the numbers for pin 1,2 and 59,60 are printed. This is 
the one row on the FLEX_EXPAN_X tables. The other row gives the internal 
pin number of the FDGA. If you make pin assignments, this internal pin 
number has to be used.

Ralf

Article: 98729
Subject: Re: xiilnx spartan 3 starter kit connection to Ethernet LAN
From: cs_posting@hotmail.com
Date: 15 Mar 2006 07:51:05 -0800
Links: << >>  << T >>  << A >>
drmali2001@gmail.com wrote:

> Does anybody have a suggestion on how to make the Spartan 3 starter
> board a host on a LAN?

You will need an ethernet adapter.  The usual approach is to buy it as
an add-on module or to use an old ISA ethernet card that is fully
documented (vs one of the ones that itsn't).  If you buy an add-on
module all the protocol stuff may be taken care of for you, if you use
the card you are going to have to have something on the FPGA capable or
running what is basically "software" - in theory you might do it with
logic, but in practice you will want a processor core in there to runa
program.

It is also possible to couple the ethernet signals fairly directly into
the FPGA.  See fpga4fun.com for an example - but again, you'll need to
run protocol "software" somewhere in the device.

> Also, how can we connect a USB camera device to the Spartan 3 starter
> board? What hardware and software are required for this purpose?

This is close to impossible.  Implementing device side USB has several
possibilities, but talking to a USB device is a far more complicated
task because you must play the host function.  You'll either need to
add a USB host controller chip and software to run it, or make your own
USB host controller in the FPGA.

Both of your questions suggest that an FPGA, or at least an FPGA alone,
may not be the right platform for your application.  Have you
considered a small controller board which might already include
ethernet and USB host capabilities?  What is the driving requirment for
an FPGA architecture?   Perhaps you can find a controller board that
also has a user FPGA.


Article: 98730
Subject: Multiple clocks design
From: patrick.melet@dmradiocom.fr
Date: 15 Mar 2006 09:21:33 -0800
Links: << >>  << T >>  << A >>
Hi all,

I've got a VHDL design for Stratix Altera FPGA with several differents
clocks (5).

There's a clock generator which is configured by the user. So some
parts in design can work at different clock frequency.

How can I P&R under Quartus 5.1 for these differents clocks frequency.
I have synthesize it with one clock.

Do I synthesise with all the differents clocks (each design with each
clocks) and test which design works better ?

Or synthesize the module where the clock frequency can change and put
the 5 architectures and select the good architecture for the desired
clock used by "soft" VHDL ?

Do you have ideas for these multi-clocks design ?

Thanks.


Article: 98731
Subject: Re: Why does Xilinx hate version control?
From: Steve Lass <lass@xilinx.com>
Date: Wed, 15 Mar 2006 10:51:34 -0700
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> Hi Steve,
>   Good to hear from someone in Xilinx
> 
> Steve Lass wrote:
> 
>> First, let me try to address the reason why the ISE file is binary.  A 
>> binary file
>> allows us to manage concurrent reads/writes which is critical in 
>> making all
>> the GUI applications work together.  Binary files are faster and more 
>> efficient.
>> Right now, there is a bug that is making the ISE file much larger than 
>> it needs to be.  
> 
> 
> So how can _that_ be faster and more efficent ? Did no one notice this ?
> Such an error would have been spotted very quickly with ASCII files....
I will not claim to know all the details, but suffice it to say, if the 
ncd was
ASCII, runtimes would be much longer.
> 
> Also, a binary file can be more robust and requires less error
> 
>> checking.
> 
> 
> Yeeessss, only until said file gets corrupted, and then it becomes a 
> brick wall. Moving across tool versions also a risk area, and likely
> to be a minefield....
> 
>>
>> Access to the data in the ISE file is often important, so providing 
>> the capability
>> to import and export is key.  Check answer record 21067 for info on 
>> how to
>> do this.  Other than the GUI, the standard way to add info into the 
>> ISE file is
>> Tcl, however, 8.2i will be required for this capability.
> 
> 
> and recovery from a corrupted file is done the same way ?
> 
>  Seems to me if you must use binary for your convenience, that you 
> should also provide an easy ASCII import/export as well.
I agree 100%.
> 
>  That way, users CAN archive  a 100% ASCII project ( and some (most?) 
> WILL prefer to do this ), but they can also reap the benefits(?) of 
> binary files during re-iterations.
> 
>>

> When is 8,2i due for release ?
June.

Steve
> 
> -jg
> 


Article: 98732
Subject: CSV files available for Xilinx FPGA parts pinouts?
From: weingart@cs.ualberta.ca (Tobias Weingartner)
Date: Wed, 15 Mar 2006 18:32:36 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hello all,

Are there any CSV formated files available with the pinout/names/etc
information for xilinx FPGA parts?  I've been using the BSDL files to
get most of the information, but hand-coding 1k plus pins is both error-
prone and tedious...  Anyone know of a place that has this sort of
information:

A1,PWR,BANK0,...
B13,TDI,BANK0,...
B13,/FOOSIG,BANK0,...


I don't mind multiple lines (one for each type of signal a pin can be
configured for).  If this is currently not available, would xilinx be
able to make something like this available?  I figure that the data is
already available in some form, and would just need to be massaged some
to be able to be put up for a download...


Thanks for any info,

-- 
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax

Article: 98733
Subject: Re: Why does Xilinx hate version control?
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 15 Mar 2006 11:05:31 -0800
Links: << >>  << T >>  << A >>
Steve Lass wrote:
> First, let me try to address the reason why the ISE file is binary.  A
> binary file
> allows us to manage concurrent reads/writes which is critical in making all
> the GUI applications work together.  Binary files are faster and more
> efficient.

"Faster and more efficient?"  We're using fairly fast machines and
while I understand that parsing a text file might be inefficient, it's
certainly not going to be the limiting factor when compiling, placing
and routing.

Being able to hand-edit and diff a configuration file, as well as
adding comments to one, far outweighs any slight performance hits.

> Right now, there is a bug that is making the ISE file much larger than
> it needs
> to be.  Also, a binary file can be more robust and requires less error
> checking.

I would imagine that it's easier for the human being who needs to use
the project file to spot and fix errors if the file is plain text.

What sort of errors are we talking about?  It's a binary file now, and
as such can only be created and modified by your tools.  If there's a
problem in the file, it was probably caused by a tool bug.

> Regarding keeping intermediate files in a separate directory, that is a
> great
> idea.  We are planning on allowing you to specify the directory structure in
> the future.

If Xilinx has just now realized this is a great idea, then it's clear
that you don't eat your own dog food.  (Sorry for reusing this
metaphor, but it's apropos.)

> Regarding creating a batch file from the GUI, you can just cut and paste the
> commands from the command_log file.
>
> We do not hate version control and have plans to allow for integration with
> your source control systems.

Subversion!  Subversion!  Subversion!

-a


Article: 98734
Subject: Re: Why does Xilinx hate version control?
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 15 Mar 2006 11:14:28 -0800
Links: << >>  << T >>  << A >>
Steve Lass wrote:

> I will not claim to know all the details, but suffice it to say, if the
> ncd was ASCII, runtimes would be much longer.

The NCD is an intermediate file created by the tools and I wouldn't put
it into my repository.

The files that need to be in revision control are the HDL sources
(obviously), constraint files (UCF remains, thankfully, plain text),
and a Makefile or the project file.  In other words, anything that's
used to drive the build process.   These files need to be plain text so
they can be diffed.  But by all means, intermediate files should be
considered transient, and should be designed for efficiency.  (And put
into their own directory so they can be deleted easily.)

Note that binaries and build results are not normally kept in the
repository.  However, when I tag a design build for release, I include
the .mcs or .jed or whatever is used to actually program the part.
Tags are (either by agreement or enforced) write-once then read-only
and immutable.

-a


Article: 98735
Subject: Re: Any PCAD users here by any chance?
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 15 Mar 2006 11:15:18 -0800
Links: << >>  << T >>  << A >>
MM wrote:
> Since I upgraded Xilinx tools to ISE8.1SP2 I can start PCAD2004 while ISE is
> running... This is all on XP...
>
> Any ideas?

You CAN start PCAD or you CAN'T start PCAD?

If you CAN'T start PCAD, perhaps you don't have enough memory?

-a


Article: 98736
Subject: Any PCAD users here by any chance?
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 15 Mar 2006 14:16:10 -0500
Links: << >>  << T >>  << A >>
Since I upgraded Xilinx tools to ISE8.1SP2 I can start PCAD2004 while ISE is
running... This is all on XP...

Any ideas?

Thanks,
/Mikhail



Article: 98737
Subject: Re: synthesis time with XST
From: Fabio Rodrigues de la Rocha <fabio.rocha@gmail.com>
Date: Wed, 15 Mar 2006 13:45:41 -0600
Links: << >>  << T >>  << A >>
Fabio Rodrigues de la Rocha wrote:
>   Hello,
> 
>   I'm using ISE 8.1 and I'm facing problems to synthesize my VHDL 
> project. This project was simulated in modsim without problems.  The 
> synthesis process is on-going for several minutes. I would like to know 
> which kind of problem in my project could cause such behavior?
>   Thank you in advance,
>      Fabio

Hello,

   I forgot to mention that I'm using the ISE webpack. I wonder if the 
webpack has some kind of delay in the synthesis step comparing with the 
ISE Foundation.

   Fabio

Article: 98738
Subject: Re: Any PCAD users here by any chance?
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 15 Mar 2006 15:02:36 -0500
Links: << >>  << T >>  << A >>
"Andy Peters" <Bassman59a@yahoo.com> wrote in message
news:1142450118.100247.244370@j33g2000cwa.googlegroups.com...
>
> You CAN start PCAD or you CAN'T start PCAD?
>
> If you CAN'T start PCAD, perhaps you don't have enough memory?

Sorry, the finger slipped off the key... I woudn't have asked the question
if I could start it :)Memory is hardly an issue. I have 1GB, and the thing
used to work before. Also, closing other apps doesn't seem to help either...
But I should admit I haven't tried all possible combinations...

Thanks,
/Mikhail




Article: 98739
Subject: Re: Why does Xilinx hate version control?
From: pbdelete@spamnuke.ludd.luthdelete.se.invalid
Date: 15 Mar 2006 20:05:05 GMT
Links: << >>  << T >>  << A >>
Steve Lass <lass@xilinx.com> wrote:
>First, let me try to address the reason why the ISE file is binary.  A 
>binary file allows us to manage concurrent reads/writes which is critical
>in making all the GUI applications work together.  Binary files are faster
>and more efficient.

If IPC (InterProcess Communication) is needed, why not use shared memory or
pipes (local stream) ..?

And such files if they need to exist should be seperate from any kind of
source data.

>Right now, there is a bug that is making the ISE file much larger than 
>it needs to be.  Also, a binary file can be more robust and requires less
>error checking.

Binary files are hard to rescue for anyone without access to the sourcecode.

If specification on how to generate the bitstream(s) were available.
It would enable independent developers to write tools. And avoid the issues
discussed to some extent.

>Access to the data in the ISE file is often important, so providing the 
>capability to import and export is key.  Check answer record 21067 for
>info on how to do this.  Other than the GUI, the standard way to add
>info into the ISE file is
>Tcl, however, 8.2i will be required for this capability.

>Regarding keeping intermediate files in a separate directory, that is a 
>great idea.  We are planning on allowing you to specify the directory
>structure in the future.

This would be very useful for complex setups.

>Regarding creating a batch file from the GUI, you can just cut and paste the
>commands from the command_log file.

A configuration file would be better. To allow version control, loading from
a previous setup - modify and save.

>We do not hate version control and have plans to allow for integration with
>your source control systems.

What will this integration mean in practice ?
(so that potential users may give input)

>We are listening and taking your input seriously.

Not all corporations listen to their customers, so it's nice to see a positive
approach.

   Regards
    /Peter


Article: 98740
Subject: Re: DDR SDRAM Controller
From: "ada" <annedorianashley@googlemail.com>
Date: Wed, 15 Mar 2006 14:28:27 -0600
Links: << >>  << T >>  << A >>

>What are you doing with the data you read from the memory ?
>Could it be that they are not used so that the synthesis tool
>optimizes the complete read path away ?
>
>Rgds
>Andr=E9

Thanks that you're trying to help me. data is my 64-bit data bus. So as
you could see below I'm puting some data on the data bus during write op
using output buffer primitives and buffer the data bus using inpit buffers
for read op. 

GEN_D3: for n in 0 to DDR_DATA_WIDTH-1 generate

 DQ_OBUFT : OBUFT_SSTL2_II port map
 ( 
   I => d2sdr(n),
   T => tristate_q(n),
   O => data(n)
 );

 DQ_IBUF :  IBUF_SSTL2_II port map
 ( 
   I => data(n),
   O => read_data(n)
 );

end generate GEN_D3;

After I'm fetching low- and hi-words from the buffered data bus
(read_data) on rising and falling edges of the clock. So it does not seem
that the synthesis tool (XSE in my case) optimizes the complete read path
away. 

Article: 98741
Subject: Re: CSV files available for Xilinx FPGA parts pinouts?
From: "Steve Knapp (Xilinx Spartan-3 Generation FPGAs)" <steve.knapp@xilinx.com>
Date: 15 Mar 2006 12:34:04 -0800
Links: << >>  << T >>  << A >>

Tobias Weingartner wrote:

> Are there any CSV formated files available with the pinout/names/etc
> information for xilinx FPGA parts?  I've been using the BSDL files to
> get most of the information, but hand-coding 1k plus pins is both error-
> prone and tedious...  Anyone know of a place that has this sort of
> information:

[ ... snip ...]

I'm not sure which Xilinx FPGA family that you are using.  Here are
locations to the Spartan-3 and Spartan-3E pinout files.  They're in CSV
format but be sure to read the readme file for additional details.

Spartan-3 FPGAs:
http://www.xilinx.com/bvdocs/publications/s3_pin.zip

Spartan-3E FPGAs:
http://www.xilinx.com/bvdocs/publications/s3e_pin.zip

---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
General Products Division
Spartan-3/-3E FPGAs
http://www.xilinx.com/spartan3e
---------------------------------
The Spartan(tm)-3 Generation:  The World's Lowest-Cost FPGAs.


Article: 98742
Subject: Re: CSV files available for Xilinx FPGA parts pinouts?
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Wed, 15 Mar 2006 20:35:00 +0000 (UTC)
Links: << >>  << T >>  << A >>
Tobias Weingartner <weingart@cs.ualberta.ca> wrote:
> Hello all,

> Are there any CSV formated files available with the pinout/names/etc
> information for xilinx FPGA parts?  I've been using the BSDL files to
> get most of the information, but hand-coding 1k plus pins is both error-
> prone and tedious...  Anyone know of a place that has this sort of
> information:

> A1,PWR,BANK0,...
> B13,TDI,BANK0,...
> B13,/FOOSIG,BANK0,...


> I don't mind multiple lines (one for each type of signal a pin can be
> configured for).  If this is currently not available, would xilinx be
> able to make something like this available?  I figure that the data is
> already available in some form, and would just need to be massaged some
> to be able to be put up for a download...


> Thanks for any info,

Look for "Spartan-3 FPGA Pinout Descriptions" under Support for the family
required.
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 98743
Subject: Re: Why does Xilinx hate version control?
From: Josh Rosen <bjrosen@polybusPleaseDontSPAMme.com>
Date: Wed, 15 Mar 2006 16:19:00 -0500
Links: << >>  << T >>  << A >>
On Wed, 15 Mar 2006 11:14:28 -0800, Andy Peters wrote:

> Steve Lass wrote:
> 
>> I will not claim to know all the details, but suffice it to say, if the
>> ncd was ASCII, runtimes would be much longer.
> 
> The NCD is an intermediate file created by the tools and I wouldn't put
> it into my repository.
> 
> The files that need to be in revision control are the HDL sources
> (obviously), constraint files (UCF remains, thankfully, plain text), and
> a Makefile or the project file.  In other words, anything that's used to
> drive the build process.   These files need to be plain text so they can
> be diffed.  But by all means, intermediate files should be considered
> transient, and should be designed for efficiency.  (And put into their
> own directory so they can be deleted easily.)
> 
> Note that binaries and build results are not normally kept in the
> repository.  However, when I tag a design build for release, I include
> the .mcs or .jed or whatever is used to actually program the part. Tags
> are (either by agreement or enforced) write-once then read-only and
> immutable.
> 
> -a

The 8.1 tools can still import the old .npl format, the problem is that
they can't save a new project in the .npl format. If Xilinx would add an
export to npl command I think everyone will be happy.

There was no good reason to switch from an ascii file to a binary file
because an ascii file is so much more flexible. The argument that there is
a performance advantage to a binary project file is ridiculous,
translating an ascii file to an internal format takes milliseconds. The
advantages of an ascii file are huge. First off you can read it and see
how everything is set. Secondly you can edit it, it's much easier to do
things in Emacs then it is in any GUI. And finally you can generate them.

I never generate ISE projects by hand. I do all of my designs with
HDLmaker, http://www.polybus.com/hdlmaker/users_guide/, which generates
scripts and make files for simulation (NCVerilog, ModelSim, VCS), scripts
and project files for synthesis (XST, Synplify, and Precision), and
project files for ISE (.npl) and for Quartus (.qpf and .qsf).

Although I almost never use the GUI, the one exception is in the lab when
running ChipScope, I have customers who are more comfortable with a GUI
particularly those who are still using Windows. For them I need to be able
to generate a project file. Fortunately .npl format still works but if
Xilinx ever drops support for the .npl format it won't be possible to
generate a project file anymore.



Article: 98744
Subject: Re: Why does Xilinx hate version control?
From: Kolja Sulimma <news@sulimma.de>
Date: Wed, 15 Mar 2006 22:51:33 +0100
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> These files need to be plain text so
> they can be diffed.  

Not necessarily. Xilinx could also provide a diff tool for the file
format. Of course with a FOSS source license so that you can create a
plugin for the versioning system of your choice.
But I agree that ASCII is the simpler way to go.

Steve Lass wrote:
> A binary file allows us to manage concurrent reads/writes which is
> critical in making all the GUI applications work together.

Maybe you should split into multiple files. Your comments sounds as if
the tools interact a lot via the project files. That is not something
that belongs into a repository.
What is needed there is mainly information about what files belong to
the project and the project settings selected by the user. This is only
a few hundred bytes. A lot of that information is ascii strings anyway.

Actually I do not see why concurrent read writes are easier in binary
files than in ascii files. Fixed field width vs. dynamic field width
makes a difference. But you can have fixed width ascii files as well.

Kolja Sulimma

Article: 98745
Subject: Re: Soldering SMT/BGA
From: Jeremy Stringer <jeremy@_NO_MORE_SPAM_endace.com>
Date: Thu, 16 Mar 2006 11:12:06 +1300
Links: << >>  << T >>  << A >>
metal wrote:
> I've done qfp's, but never had a need to do BGA's; but am now
> expecting it to come up soon; so I appreciate you taking the time to
> give that detailed process-description.

I'd second that :)  That was an interesting post.

Jeremy

Article: 98746
Subject: Re: synthesis time with XST
From: Steve Lass <lass@xilinx.com>
Date: Wed, 15 Mar 2006 15:42:01 -0700
Links: << >>  << T >>  << A >>
Fabio Rodrigues de la Rocha wrote:

> Fabio Rodrigues de la Rocha wrote:
> 
>>   Hello,
>>
>>   I'm using ISE 8.1 and I'm facing problems to synthesize my VHDL 
>> project. This project was simulated in modsim without problems.  The 
>> synthesis process is on-going for several minutes. I would like to 
>> know which kind of problem in my project could cause such behavior?
>>   Thank you in advance,
>>      Fabio
> 
> 
> Hello,
> 
>   I forgot to mention that I'm using the ISE webpack. I wonder if the 
> webpack has some kind of delay in the synthesis step comparing with the 
> ISE Foundation.

No.  The only difference between WebPACK and Foundation is device support.
If XST is taking too long, feel free to submit a webcase and we'll take 
a look
at it.

Steve
> 
>   Fabio


Article: 98747
Subject: Re: Spread Spectrum Cores ??
From: metal <nospam@spaam.edu>
Date: Wed, 15 Mar 2006 16:30:35 -0800
Links: << >>  << T >>  << A >>
On Wed, 15 Mar 2006 12:47:45 +0100, Rene Tschaggelar <none@none.net>
wrote:

>metal wrote:
>
>> Does anyone know of freeware spread-spectrum cores; particularly DS ?
>> 
>> I'm looking for something which basically takes serial-data in and
>> drives a GMK modulator at the output.  Small, configurable, and with a
>> simple DS scheme that doesn't have stringent acquisition needs.
>> 
>> Issues are cost (complexity) and power; not security or speed (1mb/sec
>> is fine).
>> 
>> ps;  any suggestion of 'standard parts' would be appreciated as
>> well...
>> 
>> thanks much
>
>Yes, there is a spread spectrum clock generator :
>The LTC6902 5kHz to 20MHz multiphase capable.
>For 2.90$.
>
>Rene

hello Rene,

thanks for your reply....but that sounds like a motherboard/cpu clock
generator....not an SS radio chip.  I am looking for cores or IC's
which generate or modulate an RF signal.


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---

Article: 98748
Subject: Re: fpga to 5v ttl logic
From: metal <nospam@spaam.edu>
Date: Wed, 15 Mar 2006 16:55:22 -0800
Links: << >>  << T >>  << A >>
On Mon, 13 Mar 2006 07:20:31 +1300, Jim Granville
<no.spam@designtools.co.nz> wrote:

>Eric Smith wrote:
>
>> metal <nospam@spaam.edu> writes:
>> 
>>> agree 100%
>>> 
>>> it is the FPGA makers who are awkward; not the supply voltage.
>>> 
>>> imho, fpga makers have dropped the ball, by totally ignoring the
>>> enormous markets of various mixed-signal products; where 5v is VERY
>>> common...along with generally noisy environments.
>>> 
>>> I have always been amazed that not a single fpga-maker has made a line
>>> of small-to-medium sized parts targeted not for blazing speed and
>>> monster computing functions; but rather, for 5v I/O, all
>>> Schmitt-trigger inputs, and very low cost.
>>> 
>>> Imho, such a line would sell like hotcakes.  Instead of hard-silicon
>>> MAC's and such, where are the hard-silicon counter/timer modules, etc.
>>> ??
>>> 
>>> I'd love to be able to buy a $5 part with 64 or 128 flops, and a hard
>>> block of 8 timer/counters (hardly any chip area in modern silicon).
>>> I've got =dozens= of apps for such a part.
>>> 
>>> In any case, it's not the users who are mistaken about 5v; but rather,
>>> the fpga-makers...who are ignoring the -reality- of -ongoing demand-
>>> for it, instead of embracing it via a profitable targeted
>>> product-line.
>>> 
>>> just m-h-o as one of those pesky 5v users, of course... <g>
>
>
>> 
>> A good MAC is fairly complicated, and as a soft MAC takes up lots of
>> FPGA real estate, so it makes sense to stick one or two on the die of
>> larger parts since it's then a fairly small percentage of the part.  Not
>> all the customers benefit, but some benefit a lot, and the others aren't
>> penalized much.
>> 
>> But counter-timers don't take up much room in an FPGA, so if you go to
>> hardwiring those, you don't gain anything, and you lose tons of flexibility.
>> Inevitably the features of the hardwired timer-counter would never be quite
>> what you need for any given design.  There would be only a small penalty,
>> but it would be borne by all customers.  Very few would get any advantage,
>> and the advantage would be very modest.  The cost/benefit analysis is
>> much worse than with a MAC.
>> 
>> If you want them to build some other hardwired logic into their FPGAs, you'll
>> need to come up with a *much* better example than that.
>
>  How about speed ?
>
>  However, what metal was talking about, is a CPLD, not a FPGA.
>
>He is looking at the bottom end of the spectrum.
>Some vendors currently come close :
>
>Atmel have low power, 5V parts in the ATF150x series.
>Xilinx have the CoolRunner2, with the larger ones having a divider 
>chain, but not 5V.
>
>but right now, no one has the twin features of 5V Drive and Schmitt Pins.
>
>-jg
>

thanks Jim, that's exactly correct.  I think Eric missed my point;
which was specifically about the industrial/mixed-signal market;
relative to the ongoing discussion of 5v i/o.

Eric, I also believe you're mistaken about timer/counters; which have
been hardwired into virtually -every- microcontroller made since the
dawn of time; and nobody has had a problem using them in their fixed
configurations.

And I think at least one or two engineers have found them to be an
"advantage"... LOL

Perhaps you are focused on "computing"; judging by your comment that a
MAC is more "useful" than a timer-counter.  I couldn't care less
whether my chip has a MAC....I don't -do- massive high-speed computing
with my logic.

Sounds like you do....but there are many many MANY uses for logic in
the world, besides running embedded linux...

ps;  jim is right, I had specifically mentioned a 64-128 cell part;
not a 3,000 register fpga.  In which case, using cells for timers eats
up a $10 chip REAL fast....while the silicon cost for a few 16b hard
counters on a chip like that would be near-zero...



----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---

Article: 98749
Subject: Re: fpga to 5v ttl logic
From: metal <nospam@spaam.edu>
Date: Wed, 15 Mar 2006 17:10:05 -0800
Links: << >>  << T >>  << A >>
On Mon, 13 Mar 2006 08:28:12 +0100, Kolja Sulimma <news@sulimma.de>
wrote:

>metal schrieb:
>>>Why ? - noise immunity, ease of interface : have you ever tried to
>>>find a power MOSFET that can be driven from 3.3V ?
>
>But the additional circuitry required to drive the MOSFET from an FPGA
>is so small and cheap compared to the power MOSFET that I do not see the
>economic advantage of selecting the FPGA based on that criterion.
>A driver in sc70-package will be hardly noticed in the layout next to a
>power MOSFET and the additional cost of 3ct doesn't matter at all.
>
>Inputs can be made 5V tolerant by a single resistors. These are
>available at virtually no cost in 0.5mm pitch 8x arrays.
>
>Schmitt-Triggers are only a little more cumbersome: You need a second
>FPGA-pin and a single resistor. Or no additional pin and a driver in
>sc70-package.
>
>If you dot need more than a few dozens of these pins the cost will not
>even add up to the price difference between a 3.3V and 5V part. And you
>are much more flexibale because you can also support all the other
>voltages that show up in the control industry: 5.2V (PECL), 6V, 6.2V,
>12V, 15V, 24V....
>
>Kolja Sulimma

Kolja, please tell me where to get these FET-drivers for 3 cents...<g>

Further, you have just -doubled- my parts count per function.  I'm mad
now... <grin>

Also, I think you are wrong to blithely dismiss a -doubling- of i/o
pin usage.  Perhaps you are thinking in terms of 500-pin chips; but
most of these apps use 40-128 pin chips.  I/O is -expensive-.

And I'm not sure how you see that technique achieving the same
noise-immunity of a true 5v schmitt input anyway.  And how do you use
the pins bidirectionally?  It just doesn't sound like a practical
thing to me.

Your technique of using resistors on the inputs, and feeding them with
5-24v signals is not a good technique, imho.  It can cause a lot of
current flow; and can actually float the fpga supply up out of spec
under certain conditions.

Every additional connection is a reliability issue...and every
additional part carries a penalty in board-space, assembly-cost, and
inventory-costs.

Basically, using a 5v logic chip is just far easier, cleaner, more
robust; and it's almost always worth the price-difference in order to
reduce parts-count, and size.


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---



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