Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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: 91351Yes, 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
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 AlfkeArticle: 91353
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
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. BenjaminArticle: 91355
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: 91356I 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
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
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, BrianArticle: 91359
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
"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. MarcoArticle: 91361
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
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? MehdiArticle: 91363
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
? = 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
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, RobinArticle: 91366
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, RobinArticle: 91367
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 SulimmaArticle: 91368
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
Thanks to all of you! Thanks Eric for sending me it mail!Article: 91370
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. -EliArticle: 91371
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
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
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
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:
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