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 91350

Article: 91350
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: Ray Andraka <ray@andraka.com>
Date: Thu, 03 Nov 2005 18:01:25 -0500
Links: << >>  << T >>  << A >>
Robin Bruce wrote:

>well, much 'hackery' obviously has happened, as there are tools that
>map C well to hardware. We're not talking about what might happen,
>we're talking about what is happening.
>
>  
>
What tools would those be?  I've yet to see a tool that will take C 
code  that has not been so badly bastardized that it no longer looks 
much like C code and turn out even half decent hardware.  All of them 
require proprietary extensions to the C language to sufficiently 
describe hardware, as well as a very specific and stilted programming 
style that is as foriegn to C programmers as VHDL or verilog is.

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 91351
Subject: Re: clock detection
From: sebastien.coquet@techway-dot-fr.no-spam.invalid (seb_tech_fr)
Date: Thu, 03 Nov 2005 19:16:06 -0600
Links: << >>  << T >>  << A >>
Yes, it's a very good idea... if it works !! :lol:

> dcm.pdfwrote:
If only the DFS outputs are used (CLKFX & CLKFX180), this status
bit will not go
> high if CLKIN stops.

That means, I have to use the clock CLKFX or CLFX180 somewhere in my
design :?

I will try ..

Thanks everybody.

I will give results in a few days...

> Ben Gwrote:
Hi,
> 
> there are a couple of general control signals for the DCM, i.e. 
> STATUS[7:0], one of which STATUS[1], indicates if CLKIN is stopped.
> 
> I've never used this myself and I'm not sure if it will be of help
to 
> you but there's more details in the V2Pro platform handbook should
you 
> need it.
> 
> Good luck,
> Ben.
> 
> seb_tech_fr wrote:
> Hi !
> I need advice to build a very small firmware which will detect if a
> clock signal is active or not.
> Indeed, My FPGA (V2Pro) is connected to other devices/boards and
> receives a clock signal. However, this clock signal is not active
at
> the begining and I would like to inform other devices/boards if
clock
> signal is ready or not.
> 
> My question is : How can I do to know if a signal clock is active?
> 
> I thought to implement a counter driven by this clock. But this
will
> not ensure me that signal is a clock at X MHz.
> 
> May I use a DCM, and look at the LOCKED signal?
> 
> All ideas are welcomed.
> 
> 
> Thank you.
> [/quote:944cb05437]


Article: 91352
Subject: Re: I have received a job offer
From: "Peter Alfke" <peter@xilinx.com>
Date: 3 Nov 2005 17:17:10 -0800
Links: << >>  << T >>  << A >>
Marco, do not automatically assume that we all live in the same global
village.
Salaries differ from country to country, often by a factor of 2 or
more.
American and Italian salaries are probably quite different. They even
differ within the US.
Ask some italian engineering friends or organizations. They may have a
more realistic opinion.
Peter Alfke


Article: 91353
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: air_bits@yahoo.com
Date: 3 Nov 2005 17:31:06 -0800
Links: << >>  << T >>  << A >>

Ray Andraka wrote:
> What tools would those be?  I've yet to see a tool that will take C
> code  that has not been so badly bastardized that it no longer looks
> much like C code and turn out even half decent hardware.  All of them
> require proprietary extensions to the C language to sufficiently
> describe hardware, as well as a very specific and stilted programming
> style that is as foriegn to C programmers as VHDL or verilog is.

Which is very true, Celoxica being a prime example as code written for
their target as an HDL would be very tough to get to run on a RISC/CISC
machine and do anything meaningful.

You have to move up the food chain to a C++ design with heavy operator
overloading before you can get close to having the same source target
both enviroments if you are going to introduce HDL features into C. Std
C
just lacks the native types that get introduced with HDL features in
Handel-C.

SO, that leaves two distinctly different camps each tring to use the
same or
similar tools for two opposite goals ... the HDL guys designing
hardware, and
the reconfigurable computing guys just trying to gain a faster
computing platform
with FPGAs.

Personally, I'm comfortable with using VHDL/Verilog for HDL and a
fairly generic
C to netlist tool (FpgaC) for general reconfigurable computing, and a
mix of tools for gluing
projects togather (SoC's).

The which HDL is better debate is pretty much preference and
requirements based,
and impossible to win as a general case.

I do think we will see HLLs that target particular techologies that are
well defined and
difficult to easily code ... the whole pipelined data path problem for
distributed arithmetic
and filters is already shaping up that way with core generators (which
are in fact simple
forms based HLLs).


Article: 91354
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: Benjamin Ylvisaker <benjaminy@alumni.cmu.edu>
Date: Thu, 3 Nov 2005 18:15:23 -0800
Links: << >>  << T >>  << A >>
On 3 Nov 2005 12:15:30 -0800
air_bits@yahoo.com wrote:

> 
> Martin Ellis wrote:
> > Nobody's pretending C-based synthesis is a complete replacement
> > for HDL, only that for some applications/projects it's a very
> > compelling alternative.
> 
> Choke, cough .... ummmm ... Celoxica, ASH, and a few other projects
> really have that goal. Celoxica has very clear guidelines, just as
> VHDL and Verilog have, to allow the coder to understand just what
> registers and logic will be instantiated.

If by ASH you mean the application specific hardware project run by
Seth Goldstein and Mihai Budiu (until he graduated) at CMU, then you
have gotten the wrong impression.  I spent a semester in that research
group, and they most certainly do not intend to replace HDLs with C.
They have developed some very interesting compiler technologies that
can generate surprisingly efficient circuits from nearly arbitrary C
code, but even they wouldn't claim that C is an appropriate
replacement for HDLs in all cases.  They are spinning their compiler
as a tool that can be used by many more people than traditional HDL
synthesis tools, but the quality of the circuits they produce is still
far from optimized HDL-based designs.

Benjamin

Article: 91355
Subject: Re: FPGA : PCI core needed
From: Kevin Brace <sa0les1@brac2ed3esi4gns5olut6ions.com>
Date: Fri, 04 Nov 2005 02:20:26 GMT
Links: << >>  << T >>  << A >>
Hi Eric,

Here is a comparison of BDS XPCI PCI IP core's configuration register 
block in MUX (It gets directly map to LUTs by XST.) and internal 
tri-state buffers.
The first result is the MUX version.

____________________________
Release 6.3.03i Map G.38
Xilinx Mapping Report File for Design 'pcim_top_BDS_XPCI32'

Design Information
------------------
Command Line   : C:/Xilinx_webpack_6_3/bin/nt/map.exe -intstyle ise -p
xc3s200-ft256-4 -cm area -pr b -k 4 -c 100 -tx off -o
pcim_top_BDS_XPCI32_map.ncd pcim_top_BDS_XPCI32.ngd pcim_top_BDS_XPCI32.pcf
Target Device  : x3s200
Target Package : ft256
Target Speed   : -4
Mapper Version : spartan3 -- $Revision: 1.16.8.2 $
Mapped Date    : Thu Nov 03 19:45:18 2005

Design Summary
--------------
Number of errors:      0
Number of warnings:   32
Logic Utilization:
   Number of Slice Flip Flops:         289 out of   3,840    7%
   Number of 4 input LUTs:             498 out of   3,840   12%
Logic Distribution:
   Number of occupied Slices:                          380 out of 
1,920   19%
     Number of Slices containing only related logic:     380 out of 
380  100%
     Number of Slices containing unrelated logic:          0 out of 
380    0%
       *See NOTES below for an explanation of the effects of unrelated logic
Total Number 4 input LUTs:            530 out of   3,840   13%
   Number used as logic:                498
   Number used as 16x1 RAMs:             32
   Number of bonded IOBs:               49 out of     173   28%
     IOB Flip Flops:                    91
   Number of GCLKs:                     1 out of       8   12%

Total equivalent gate count for design:  10,268
Additional JTAG gate count for IOBs:  2,352
Peak Memory Usage:  80 MB
____________________________



The second result is the internal tri-state buffer version which gets 
converted to LUTs by MAP.

____________________________
Release 6.3.03i Map G.38
Xilinx Mapping Report File for Design 'pcim_top_BDS_XPCI32'

Design Information
------------------
Command Line   : C:/Xilinx_webpack_6_3/bin/nt/map.exe -intstyle ise -p
xc3s200-ft256-4 -cm area -pr b -k 4 -c 100 -tx off -o
pcim_top_BDS_XPCI32_map.ncd pcim_top_BDS_XPCI32.ngd pcim_top_BDS_XPCI32.pcf
Target Device  : x3s200
Target Package : ft256
Target Speed   : -4
Mapper Version : spartan3 -- $Revision: 1.16.8.2 $
Mapped Date    : Thu Nov 03 19:54:28 2005

Design Summary
--------------
Number of errors:      0
Number of warnings:   32
Logic Utilization:
   Number of Slice Flip Flops:         283 out of   3,840    7%
   Number of 4 input LUTs:             567 out of   3,840   14%
Logic Distribution:
   Number of occupied Slices:                          422 out of 
1,920   21%
     Number of Slices containing only related logic:     422 out of 
422  100%
     Number of Slices containing unrelated logic:          0 out of 
422    0%
       *See NOTES below for an explanation of the effects of unrelated logic
Total Number 4 input LUTs:            600 out of   3,840   15%
   Number used as logic:                567
   Number used as a route-thru:           1
   Number used as 16x1 RAMs:             32
   Number of bonded IOBs:               49 out of     173   28%
     IOB Flip Flops:                    97
   Number of GCLKs:                     1 out of       8   12%

Total equivalent gate count for design:  11,258
Additional JTAG gate count for IOBs:  2,352
Peak Memory Usage:  80 MB
____________________________



The backend design is a simple 16 byte long I/O mapped memory 
synthesized by XST.
Subtracting the backend logic usage from the total logic usage will give 
you the BDS XPCI PCI IP core's logic usage.

____________________________
=========================================================================
*                            Final Report                               *
=========================================================================

Device utilization summary:
---------------------------

Selected Device : 3s200ft256-4

  Number of Slices:                      43  out of   1920     2%
  Number of Slice Flip Flops:            39  out of   3840     1%
  Number of 4 input LUTs:                44  out of   3840     1%
  Number of bonded IOBs:                 50  out of    173    28%
  Number of TBUFs:                       32  out of    960     3%
  Number of GCLKs:                        1  out of      8    12%
____________________________


Neither versions used a constraint file (UCF), so the FF count might be 
somewhat different if a constraint file was used, but that shouldn't 
affect the LUT count too much.
Both versions (MUX version and internal tri-state buffer version) of 
netlist of the BDS XPCI PCI IP core were synthesized by ISE 4.2i's XST 
for Spartan-II (ISE 4.2i's XST was used because that the last version of 
XST that can generate an EDIF netlist using a secret "-ofmt EDIF" switch.)
I am myself surprised that the use of MUX inside the BDS XPCI PCI IP 
core reduced the LUT this much, but what is interesting is that trying 
to emulate internal tri-state buffer with LUTs increases the LUT usage 
quite a bit.
         One more thing to note.
ISE WebPACK 6.3i was used for this test instead of 7.1i.
For some reason, Xilinx messed up the internal tri-state buffer 
conversion algorithm in 7.1i (The problem still lingers even in SP4.) 
that the above design won't map at all in 7.1i.
Answer record #20048 discusses this issue, but is not very helpful.


Kevin Brace


Eric Smith wrote:
> Kevin Brace <sa0les1@brac2ed3esi4gns5olut6ions.com> writes:
> 
>>         If the number we presented is not satisfactory, we have several
>>ideas to reducing the LUT count such as:
>>
>>* Using multiplexer instead of internal tri-state buffers for
>>configuration register part of the PCI IP core
> 
> 
> Will that help?  Don't the synthesis tools translate use of tri-state
> buffers into multiplexers on most of the newer Xilinx FPGAs anyhow,
> since the parts don't have actual tri-state buffers?


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

Xilinx and LogiCORE are registered trademarks of Xilinx, Inc.

Article: 91356
Subject: Re: use ppc405 on virtex-II pro
From: "Nitro" <nitro-57@no_spam_please_usa.net>
Date: Thu, 03 Nov 2005 22:39:42 -0500 (EST)
Links: << >>  << T >>  << A >>
I have not tired using both at once, the class I took only went into detail
on using one.  If you are using the VP40 or larger with two hard PPC405
macros I believe you would simply add the second one in as you would the
first, building a separate local bus with a separate set of blockram etc.  If
you would like them to work together on a problem you would need to have one
hand off pieces to the other or build a logic block or even drop in a
microblaze core to handle the partitioning of the workload and common memory
access etc. 

Bart

On 3 Nov 2005 12:49:13 -0800, Eric wrote:

>
>
>Does anyone have reference on how to use the second ppc405 in virtex-II
>pro?
>I'm trying to write an application on each ppc, and see how two
>processors work together.
>xilinx reference manual didn't talk about how to use the second ppc,
>from what i read.
>any pointer is appreciated. Thanks.
>
>-Eric
>




Article: 91357
Subject: Re: use ppc405 on virtex-II pro
From: Matthieu Michon <matthieu.michonRemove@laposte.net>
Date: Fri, 04 Nov 2005 12:42:25 +0900
Links: << >>  << T >>  << A >>
Eric wrote:
> Does anyone have reference on how to use the second ppc405 in virtex-II
> pro?
> I'm trying to write an application on each ppc, and see how two
> processors work together.
> xilinx reference manual didn't talk about how to use the second ppc,
> from what i read.
> any pointer is appreciated. Thanks.
> 
> -Eric
> 

Hi Eric,

Well nothing prohibits you from using both PPC405 in a 2VP20+ at the 
same time.  However if you intend to use a CPU clock frequency above 300 
MHz, you'd better take a look to the XAPP-755, which described a special 
clock macro to be used against the PPC405.

Article: 91358
Subject: Re: Spartan-3E starter kit
From: "Brian Davis" <brimdavis@aol.com>
Date: 3 Nov 2005 20:06:43 -0800
Links: << >>  << T >>  << A >>
Peter wrote:
>
> your older comments must have fallen on good ears
>
  I suspect Steven Knapp's past comments on the I/O connector grounding
were far more effective than mine...

>
> The S3e500-based evaluation board uses a two-row 100-pin connector with
> (almost) one whole row dedicated to Ground.
>
 Great!!!
 Is that the Hirose 100 pin as used on the XUP-V2Pro board?

>
>  Plus two legacy connectors that are much smaller.
>
 OK; the S3E board webpage description says "three 40-Pin Expansion
Connection Ports", which is what had me worried about high-speed I/O.

>
> The manual is still being written, and I offered some help.
>
 Even a rough draft with schematics & connector pinouts would let folks
get a head start on designs.


thanks,
Brian


Article: 91359
Subject: Clock J4
From: johngalil@hotmail.com
Date: 3 Nov 2005 22:38:43 -0800
Links: << >>  << T >>  << A >>
Dear,

I have a question regarding the "SMA connector J4" available on the
Nios Development board, Stratix Edition. Can we use it only for an
external clock? would it be possible to read any input signal from it,
I have an idea how to get the clock so this is not an issue.

Thanks in advance,
John.


Article: 91360
Subject: Re: I have received a job offer
From: "Marco" <marcotoschi@nospam.it>
Date: Fri, 4 Nov 2005 09:22:56 +0100
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in message 
news:1131067030.877901.142080@z14g2000cwz.googlegroups.com...
> Marco, do not automatically assume that we all live in the same global
> village.
> Salaries differ from country to country, often by a factor of 2 or
> more.
> American and Italian salaries are probably quite different. They even
> differ within the US.
> Ask some italian engineering friends or organizations. They may have a
> more realistic opinion.
> Peter Alfke
>

I'll do it.

Many Thanks to everyone has replied.
Marco 



Article: 91361
Subject: Re: clock detection
From: Ben G <user@example.net>
Date: Fri, 04 Nov 2005 09:32:20 +0000
Links: << >>  << T >>  << A >>
Hi Sebastien,

> If only the DFS outputs are used (CLKFX & CLKFX180), this status
> bit will not go high if CLKIN stops.

My reading of that would be that as long as you are not using CLKFX or 
CLKFX180 then it should work, i.e. use any of the DLL outputs such as CLKO.

> That means, I have to use the clock CLKFX or CLFX180 somewhere in my
> design :?

You can check this but as above I would say it's the opposite to this.


Good luck,
Ben.

Article: 91362
Subject: ChipScope and Spartan-3 Starter Kit (DO-SPAR3-DK)
From: "=?iso-8859-1?B?R2FMYUt0SWtVc5k=?=" <taileb.mehdi@gmail.com>
Date: 4 Nov 2005 01:33:54 -0800
Links: << >>  << T >>  << A >>
Hi all!
Can the ChipScope Pro be used with the Spartan-3 Starter Kit
(DO-SPAR3-DK) ?
This board is bundelled with a "JTAG3 Programming Cable" can I connect
a Xilinx PC4 or USB cable instead of that cable (JTAG3 Programming
Cable)? Or the board wouldn't support them?

Mehdi


Article: 91363
Subject: Re: I have received a job offer
From: "Luis Vaccaro" <lvaccaro@hotmail.com>
Date: Fri, 4 Nov 2005 10:54:50 +0100
Links: << >>  << T >>  << A >>
I'm Italian and here salaries are very low, I think that 3000 ? /month will
be very hard to get, may be 2000 ? will be very good in Italy....


in bocca al lupo!

-- 
Luis Vaccaro


"Marco" <marcotoschi@nospam.it> wrote in message
news:dkf5p6$j2p$1@nnrp.ngi.it...
>
> "Peter Alfke" <peter@xilinx.com> wrote in message
> news:1131067030.877901.142080@z14g2000cwz.googlegroups.com...
> > Marco, do not automatically assume that we all live in the same global
> > village.
> > Salaries differ from country to country, often by a factor of 2 or
> > more.
> > American and Italian salaries are probably quite different. They even
> > differ within the US.
> > Ask some italian engineering friends or organizations. They may have a
> > more realistic opinion.
> > Peter Alfke
> >
>
> I'll do it.
>
> Many Thanks to everyone has replied.
> Marco
>
>



Article: 91364
Subject: Re: I have received a job offer
From: "Luis Vaccaro" <lvaccaro@hotmail.com>
Date: Fri, 4 Nov 2005 10:56:14 +0100
Links: << >>  << T >>  << A >>
? = euro, problems with unicode...

-- 
Luis Vaccaro


"Luis Vaccaro" <lvaccaro@hotmail.com> wrote in message
news:436b2e93$0$6018$4fafbaef@reader4.news.tin.it...
> I'm Italian and here salaries are very low, I think that 3000 ? /month
will
> be very hard to get, may be 2000 ? will be very good in Italy....
>
>
> in bocca al lupo!
>
> -- 
> Luis Vaccaro
>
>
> "Marco" <marcotoschi@nospam.it> wrote in message
> news:dkf5p6$j2p$1@nnrp.ngi.it...
> >
> > "Peter Alfke" <peter@xilinx.com> wrote in message
> > news:1131067030.877901.142080@z14g2000cwz.googlegroups.com...
> > > Marco, do not automatically assume that we all live in the same global
> > > village.
> > > Salaries differ from country to country, often by a factor of 2 or
> > > more.
> > > American and Italian salaries are probably quite different. They even
> > > differ within the US.
> > > Ask some italian engineering friends or organizations. They may have a
> > > more realistic opinion.
> > > Peter Alfke
> > >
> >
> > I'll do it.
> >
> > Many Thanks to everyone has replied.
> > Marco
> >
> >
>
>



Article: 91365
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: "Robin Bruce" <robin.bruce@gmail.com>
Date: 4 Nov 2005 03:59:47 -0800
Links: << >>  << T >>  << A >>
Ray,

OK, maybe I should rephrase what I said, reading it again myself I
don't quite agree with it :). What I meant was that there are tools out
there that can map HLL well to hardware. I didn't mean to suggest that
they are ANSI C. I realise it's a bit of an abuse of the language to
describe these things as C, but I tend to describe the C-inspired
languages of these tools as C, and talk about ANSI C when I want to
make it clear I'm talking about canonical C.

It does seem that most of the tools out there are extensions to C. I
should say at this point that I've never used any of the tools that
have been discussed so far on this board, so I'll leave it to someone
else to talk about how close they are to C. I'm a research engineer
based in Nallatech, and I've been working with a tool being developed
there, DIME-C. I can safely say that DIME-C is to all intents and
purposes a subset of C, so everything you do in it can be compiled with
a gcc compiler. You can't have pointers, and you have to go round the
houses sometimes to avoid breaking your pipelines, but it's definitely
recognisable as C. If anyone is particularly interested, I could send
them some examples of the code. I don't want to bring DIME-C into the
debate though, I'm interested in finding out more about what's out
there, rather than in doing marketing :)

Cheers,

Robin


Article: 91366
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: "Robin Bruce" <robin.bruce@gmail.com>
Date: 4 Nov 2005 04:02:07 -0800
Links: << >>  << T >>  << A >>
Jim,

I agree with you about the value of mixing and matching HLL and HDL
solutions in your system. You might want to design the core of your
algorithm using an HLL tool, then link it up to control and memory
systems that you've designed using HDL.

I also can see the constant changing of the underlying hardware as
being a challenge to those who are developing C-to-hardware tools. I
think perhaps it favours those who target their systems at a single
architecture, like SRC with their Carte programming environment.
HandelC has seen a lot of real success, the most notable in my mind is
it being used in an effort by Lockheed Martin to create a space system
to dock with Hubble
(http://klabs.org/mapld05/presento/220_feifarek_p.ppt). My
understanding of HandelC is that the basic package contains generic HDL
routines for the common operations (data array storage and retrieval,
fixed-point multiplication etc.) bu the user is given the option to
supplement this with implementation specific routines. So in Xilinx
V-II this would be BRAMs for data array storage and use of the 18x18
multipliers for the fixed-point stuff.

With each new generation of FPGA, you'll need to update your underlying
library routines. As I recall Peter Alfke saying at this year's FPL, to
get the best out of FPGAs, you need to target your architectures,
generic just won't cut it (apologies to Peter if that's not what he was
getting at).

So I guess I agree with you Jim, in that C -> registers is not the best
approach.

Apologies for my ignorance, but can I ask you to expand on "alternative
of HLL -> FPGA Running HLL amd the best tool set". I wasn't sure what
you meant.

Cheers,

Robin


Article: 91367
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: Kolja Sulimma <news@sulimma.de>
Date: Fri, 04 Nov 2005 14:05:45 +0100
Links: << >>  << T >>  << A >>
air_bits@yahoo.com schrieb:
> There are a few hundred thousand engineers on the planet that can
> express large complex algorithms in C, 
Yes, but Java and C# have essentially the same syntax without any of the
defunct side effect issues that make C so damn hard to synthesize but do
not have any real use anyway.

But instead of using an existing standard lagnuage that can be
synthesized they define a new language of their own and call it "C, but
you are not allowed to use this and that"

BTW, VHDL has the same issues.

> There are clear advantages to being able write, test, and debug large
> complex algorithms on a traditional processor with a source code
> debugger and moving the nearly finished product to FPGAs for deployment
> and performance. So access to advanced software development tools is
> two.

Yes, but it also is a clear advantage to have a language that allows for
explicit parallelism, processes, signals and events on a finer grain
that threads.

Such languages exist for traditional processors for a long time now.
Algol comes to mind as a very old example.
You know, it is very easy to map explicit parallelism on a serial
machine. But it is very hard to extract parallelism from a serial
description.

I am a big fan of high level synthesis from algorithmic descriptions
that do not describe the hardware details, but I am sure that C is "A
Really Bad Choice (TM)".

Heck, C is a really bad choice for serial CPUs to begin with. If you
build hardware, you want your compiler to do as many compile time checks
as possible. There's not much that you can catch at compile time with
plain C.


Kolja Sulimma


Article: 91368
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: air_bits@yahoo.com
Date: 4 Nov 2005 05:49:42 -0800
Links: << >>  << T >>  << A >>

Benjamin Ylvisaker wrote:
> I spent a semester in that research
> group, and they most certainly do not intend to replace HDLs with C.
> They have developed some very interesting compiler technologies that
> can generate surprisingly efficient circuits from nearly arbitrary C
> code, but even they wouldn't claim that C is an appropriate
> replacement for HDLs in all cases.  They are spinning their compiler
> as a tool that can be used by many more people than traditional HDL
> synthesis tools, but the quality of the circuits they produce is still
> far from optimized HDL-based designs.

I was not suggesting that C syntax HDL's will obsolete VHDL/Verilog
and other technology specific HDL's, but just as you clearly state the
goal is to produce "efficient circuits from nearly arbitrary C" which
from
the presentations by the group are very very close to that of a good
HDL
with a good to excellent coder. With FPGAs increasing in size at
roughly
the same Moore's Law rate, and similar performance increases, the end
result is that "surprisingly efficient circuits from nearly arbitrary
C" is more
than good enough to replace VHDL/Verilog for the majority of
algorithmic
and systems level designs to allow faster time to market, with a larger
pool of talent (being able to draw on C coders), with good enough
performance
and fit so that expensive fine tuning and coding in VHDL/Verilog will
NOT
be required.

The clear intent is to produce acceptable circuits with a less talented
engineers for a variety of target applications ranging from full
systems to
reconfigurable computing.


Article: 91369
Subject: Re: Memec Insight Spartan-3 LC Development Kit USB drivers needed! Help!
From: "Robert" <robertsolanki@gmail.com>
Date: 4 Nov 2005 06:12:38 -0800
Links: << >>  << T >>  << A >>
Thanks to all of you! Thanks Eric for sending me it mail!


Article: 91370
Subject: Re: ChipScope and Spartan-3 Starter Kit (DO-SPAR3-DK)
From: Eli Hughes <emh203@psu.edu>
Date: Fri, 04 Nov 2005 09:14:54 -0500
Links: << >>  << T >>  << A >>
GaLaKtIkUs™ wrote:
> Hi all!
> Can the ChipScope Pro be used with the Spartan-3 Starter Kit
> (DO-SPAR3-DK) ?
> This board is bundelled with a "JTAG3 Programming Cable" can I connect
> a Xilinx PC4 or USB cable instead of that cable (JTAG3 Programming
> Cable)? Or the board wouldn't support them?
> 
> Mehdi
> 


Yes, you can use the PC4 cable.  The standard JTAG header is available.

-Eli

Article: 91371
Subject: Re: FPGA C Compiler on sourceforge.net (TMCC derivative)
From: air_bits@yahoo.com
Date: 4 Nov 2005 06:15:28 -0800
Links: << >>  << T >>  << A >>

Kolja Sulimma wrote:
> Yes, but Java and C# have essentially the same syntax without any of the
> defunct side effect issues that make C so damn hard to synthesize but do
> not have any real use anyway.

The issue is having to subset a language and it's expected runtime
environment.
Both Java and C# barrow heavilty from the same subset of C syntax, and
both
have similar problems of porting arbitrary code from a traditional
sequential
execution environment to FPGA's. The lack of "real addressable memory"
results in difficulties in dynamic allocation, and runtime
architectures that
expect pointers to create and manage data objects.

Starting a "my language is better than your language debate" is really
non-productive,
as the real test is does it exist in a usable form today for this
application, and the
assumption or assertions are in the end only validated by availability
and use as the
true test of what is the best for target applications. One clear
standard is access to
trained labor pools, as frequently the "best" tools for briliant
experienced engineers
create unmanagable complexities for less talented, skilled, experienced
engineers
that will have to maintain the project over it's life. Managing
concurrency has always
been a tough one for less skilled engineers unable to grasp global
system architecture
and state enough to protect from the hazards and deadlocks.

There is a lot of room in this new HLL to netlist market ... we would
ALL like to
see affordable usable tools that do a better job. Bitching that C tools
are not
to some higher standard is pretty non-productive, when the existing
broadly used
tools are at even a lower standard.

There are few affordable open source tools for students, hobbiests, and
small
development shops for FPGAs .... I don't see any that meet your minimum
requirements, maybe your talents will make them available?


Article: 91372
Subject: Re: ChipScope and Spartan-3 Starter Kit (DO-SPAR3-DK)
From: "=?iso-8859-1?B?R2FMYUt0SWtVc5k=?=" <taileb.mehdi@gmail.com>
Date: 4 Nov 2005 06:17:10 -0800
Links: << >>  << T >>  << A >>
So no problem with ChipScope? I can Buy the DO-SPAR3-DK board and use
the ChipScope and the PC4 cable (availlable in our university's lab) ?


Article: 91373
Subject: Re: ChipScope and Spartan-3 Starter Kit (DO-SPAR3-DK)
From: "Robert" <robertsolanki@gmail.com>
Date: 4 Nov 2005 06:17:21 -0800
Links: << >>  << T >>  << A >>
Hi Mehdi,
I am using Xilinx Parallel Cable IV with my spartan-3 board (from Memec
Insight) instead of the JTAG cable that came with the kit. It works
fine for me and I am sure it would work for you. Of course, I am using
it just to download my design on to the devices (FPGA and EPROM) and
not with Chipscope Pro. But in the documentation, I did find that
Chipscope Pro supports it.

Also, in cable setup, there is an option where you can select the kind
of parallel cable and both III and IV are in there.

When I tried my IV cable with Chipscope pro, it gave an error "Cable
not found". However, the reason may be because my Chipscope Pro is
expired!


Article: 91374
Subject: Re: Xilinx ISERDES
From: "???" <sinitron@cm1.hinet.net>
Date: Fri, 4 Nov 2005 22:29:24 +0800
Links: << >>  << T >>  << A >>
We use TI ads5270,and clock rate 33.33Mhz X 6= 200Mhz in XC4VLX25-10 .
 It is working OK!
You can try lvds-p and lvds-n at two ISERDES.
One pin has one ISERDES, So lvds have two ISERDES.
lvds-p and lvds-n to up ISERDES, lvds-n and lvds-p to down ISERDES, It is
used ddr technology.
The way can used 16 bits input to ISERDES.

Sinitron

"Kolja Sulimma" <news@sulimma.de> 
???????:4360ac7d$0$21955$9b4e6d93@newsread2.arcor-online.net...
> Sean Durkin schrieb:
>> Peter Alfke wrote_
>>
>>>No problem, not even with ten bits parallel.
>>
>> What do I do if I need 12?
>>
>> We use a lot of TI's ADS527X-ADCs, and those output 12bit-data-words
>> over LVDS-DDR-outputs running at 420MHz and higher.
>
> So these are 6-bit nibbles at 70MHz. Should be easy with the ISERDES.
>
> Kolja Sulimma 





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