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
Paul Attilla Richards wrote: > > I'm interested in generating small-stepped delays with FPGA/CPLDs for > a phased array transmitter, and initially thinking of Xilinx 4000E & > 9500 series +M1.5 Foundation, though would happily consider others. > > I've done a bit of design with all synchronous components at 30MHz but > now need some small time shifts which are probably too small to be > done by clocking. I'd welcome any comments or pointers. > Any reasons (e.g. cost, power) for not using off-the-shelf programmable delay lines or common ECL parts like the 100E195 (2ns delay range, 20 ps step resolution). There are also parts like the Cypress Roboclock series which might be useful. Vitesse has some interesting octal deskew/timing parts coming out too for ATE applications (VSC 6048,6280/81/82) for 8ns range, 10 ps resolution. I guess the question is whether this is a self-imposed challenge (getting precise timing out of imprecise FPGAs) or if there is something I've missed (doesn't have to be precise, must be cheap, low power) regards, Tom Burgess -- Digital Engineer National Research Council of Canada Herzberg Institute of Astrophysics Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@hia.nrc.ca Office: (250) 490-4360 Switch Board: (250) 493-2277 Fax: (250) 493-7767Article: 14376
>
>> > void main() {
>>
>> Interesting, but not C. main returns int in C.
>
>Oh no, not again !
For my two cents, I can tell you all that I have written
many C programs that do not include a return type
declaration for the MAIN routine, and operating
systems (from Windows NT to VAX/VMS) seem to
be quite accepting of the constructions that I use.
If there is to be a requirement for a return type
declaration, then the statement above should
result in an error being issued by the compiler
upon compilation of the code. Since such an error
is not reported, then I have to say that it is not
required that a declaration be given.
It is better to be motivated by the practical than
the ideal (though ideals are often worth striving
for), given that the goal is to complete some
useful work.
William R. Buckley
Article: 14377If the clocks are truly asynchronous then the double d-type method only works if you know the probability distribution of the settling time. Note it could be arbitrarily long. This distibution is usually expressed as a MTBF based on (1) the process characteristics, (2) the async input frequency, and (3) the sampling frequency. Parameters for (1) have to come from your vendor - then you plug these values into a standard formula that will give you the MTBF or (inverted) the probablility that the output of the first d-type will settle withing the sampling clock period - Tsetup. If it doesn't then you need clock the d-types with sample-clock/n.Article: 14378
Peter, I am sure this is incorrect, for the XC3000 config clock input. After much work with a 350MHz scope (on a PCB with 32-off XC3064 which I used to make) I am very sure that even with an extremely clean waveform the *maximum* risetime is about 30ns. Any slower than that, and it misconfigures. >There has never been any problem with combinatorial inputs. >If they are slow, it just delays the signal and may add some >power dissipation. The problem is with clocks.In an >environment without any noise and without any ground-bounce, >even the incoming clock edges can be as slow as molasses. >But show me that kind of environment.... -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y. Please do NOT copy usenet posts to email - it is NOT necessary.Article: 14379
In article <78np73$gke$1@news-2.news.gte.net>, BuckSavage <wbuckley@transdyn.com> wrote: > [ Re: void main() ] > >For my two cents, I can tell you all that I have written >many C programs that do not include a return type >declaration for the MAIN routine, and operating >systems (from Windows NT to VAX/VMS) seem to >be quite accepting of the constructions that I use. Specifying no return type in C is the same as specifying "int." Fuction returns default to "int." Specifying a return type of "void" is another thing entirely. >It is better to be motivated by the practical than >the ideal (though ideals are often worth striving >for), given that the goal is to complete some >useful work. As long as your "practical" doesn't require the code work correctly on various systems, you are free to be "practical" and ignore the standard. Eric -- Eric Korpela | An object at rest can never be korpela@ssl.berkeley.edu | stopped. <a href="http://sag-www.ssl.berkeley.edu/~korpela">Click for home page.</a>Article: 14380
ems@riverside-machines.com.NOSPAM writes: > Interesting - are you sure about the '93 bits? I put a test case > through 1998.08 about a month ago, the last time I used DC, and it Reasonably. I think they have added some form of crude alias support, at least. I can't remember what other bits they have implemented. I can have a look tomorrow, if you want. I think I have some notes lying around somewhere at work. GeirArticle: 14381
I've been watching the comments on Synplicity with interest as we have
just bought it. It looks like
I'll have to be careful with CLB and timing estimates.
On my trial design (75% of the biggest Spartan) the final PAR CLB
count was 20% up on the initial estimates BUT I had MAP in minimum
packing mode. Looking further at the LUT count I could
see that the final value was only10% up. This comes down to 1% if I
subtract the ``LUTs used as route-throughs'' given by the MAP report.
Also all the other bugs mentioned relate to Sun WS's. Anybody had any
problems running Synplify 5.0.8 under NT on a Pentium II ? I haven't
had any so far.
BTW Synplify won out over Spectrum on :
o Speed +: Compiles a design that uses 45% of an XC4085 in just over 1
min.
o Language +: Get Verilog and VHDL
o Fanout +: Explicit fanout of heavily loaded signals good for the
initial stage and tells me where I
should go and do some more work.
o FSM compiler +:
o Interface +/-: If you insist on batch mode then you have to pay a 50%
premium for a floating license but then you get full Tcl scripting.
o Final results +/-: After running the respective EDIF files through
the Xilinx tools with no
timing constraints Synplify had these differences:
Avg Conn delay : +4%.
Max pin delay: -25%.
Avg delay on 10 worst: -10%.
I'll have to run the TRCE program to find out why
o Bottom Up (small -): Synplify doesn't accept EDIF files as source so
you can't merge pre-synthesised parts of a design together with
whatever source files you're working on.
I'll have to use NGDBUILD to do this.
The only thing I wish is that HDL Analyst was a little cheaper.
Only bug so far: If your license is near running out Synplify insists on
poping up a little message box
telling you this and you have to click on OK to make it go away. Very
irritating when this
happens in batch mode and you're running on a short eval license.
This will be fixed in 5.1.x.
Article: 14382We do not recruit!! Just an old fashioned engineering firm. http://www.cstn.comArticle: 14383
WHAT?? satish_me@hotmail.com wrote: > Hello I am in the research field of FPGA. Why the PLL's should be used for > FPGA reprogramming.Please intimate to my hotmail account > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14384
On Thu, 14 Jan 1999 22:56:03 +0100, aweas <aweas_rammal@elgems.com> wrote: >Hi >I think a lot of poeple made the transfer from altera's ahdl to vhdl. >those how did it , can you please give me some feed back about the >results. >and info about the transfer to VHDL . >I'll be happy to get as much answer's as possible VHDL was not designed as a synthesis language, and it shows. AHDL was, and it shows too. In most respects, I think AHDL is a superior language for the task of designing logic, but VHDL has other uses too, and of course is (approximately!) device and vendor-independent. At the end of the day, though, VHDL and AHDL are just two different programming languages; they're much closer to each other than to traditional schematic design. If you can write one, you can write the other. -- Steve Rencontre, Design Consultant http://www.rsn-tech.demon.co.uk/ -- remember to despam return addressArticle: 14385
FPGA Downloader for Altera FPGA/EPLD - ONLY $75.00 Works with any voltage from target board 1.8 V - 5.5 V Replaces Altera ByteBlaster and ByteBlaster MV downloader You will never need another downloader Please visit us at: http://welcome.to/nefdesign.com Sincerely, NEF Design, Inc. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 14386
seebs@plethora.net (Peter Seebach) writes: > >However, if you have the so-called free-standing environment, (which is > >the case with most embedded systems) the main() function: > > >- does not have to exist at all, but > >- if it exists, it can have any prototype you like, and > >- does not have to return at all > > Not any prototype *you* like. > Any prototype the vendor decided to use. > And they probably have fairly strict standards. The compiler vendor can not know what do I want to pass to my main() and can not force me to use their init stub which will call main. Actually I have never used the vendor supplied startup for they all assumed some BIOS-ed environment which has already set up a few things. In my systems main() is the main entry point of the system, entered immediatelly after the reset code set up enough hardware to run C code at all. Main never returns (where would it ?) thus it's always declared as void, actually volatile void under (cross) gcc. In a free-standing environment main() is just a function like any other. There's nothing special about it. > Anyway, if you refer to standard library functions, you're assuming a > hosted environment. No, I don't. I can happily use strcat() or sprintf() in a non-hosted environment. Of course you can not use functions like system() for there's no system but you can use the subset of the library which is meaningful without a hosting system. Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 14387
Many thanks to Ray, Peter, Tom - they were all very useful suggestions. Just to clarify a bit ... For some designs I'm interested in generating a few fixed phase shifted clocks to satisfy timing requirements of asynchronous external devices, provided that I can enforce a permissible range of phase (i.e. skew). If that could be done by adding some min/max timing constraints then whoopee! These output signals are not going to be fed back into any clock input on the FPGA. Perhaps it could employ some of the fixed delays inserted to deliberately delay clocks and data to manipulate the setup and hold times. Alternatively create some route-throughs. Admittedly it does seem "heretical", trying to do more than one thing per clock cycle, though this is not going to be at the speed limit of the device. Regarding the programmable delay line, I would like to keep that synchronous if it can be done fast enough, but not if it means running the ICs right at the limit of the spec. If I have to use external delay components but then feed the signals back into the FPGA/CPLD to form the final patterns, then channel matching across pins and devices must be good. I appreciate that if the logic funtion is implemented by a 4-input block on the FPGA, and since the output is not clocked it could flap about a lot as any input changes. I may be able to avoid that using combinational logic output-devices on 4000Xxx or using the CPLDs. I wasn't thinking of seriously using a tapped asynchronous delay line for my multi-channel waveform generator. It's worth trying out. My current working system could be improved by adding more channels. Ideally I'll keep the same board form factor and terminals, but get at least twice the number of channels per card. If all the logic/delay networks are compressed into one package (PLCC84?) it leaves room for extra power components and more self-testing facilities. The delay section is relatively small, so the bulk of the FPGA would be handling 7 sets of bitstreams/channel, frequency synthesis, a safety/watchdog system, and if there's room, some 32 bit arithmetic functions for the single chip microcontroller on each channel. Possibly the delay section could be in a separate CPLD, or in a manually placed & routed quadrant of the FPGA as suggested. I need to learn all about that too. Any fixed delay offset which is common to all channels across multiple FPGAs is acceptable, if I can obtain suitable bounds for it from manufacturers data or from inspection. Having a lot of relatively simple logic ICs is a waste of power - only the final outputs need the current drive cabability. I would hope to double the number of channels and yet reduce overall logic power consumption. (About 75W now.) Serveral of the ICs in the current design have become obsolete in the last year, though we bought enough stock for current jobs. I shall certianly have a look at the XC4000XLA and Virtex parts, and posibly set up some experiments to vary temperature & voltage, if I can't get any data. I'm intrigued by the 35ps/step delays mentioned, though 1ns would be fine enough for now. The ECL suggestions from Tom were very useful. I'm put off by the power consumption and added component space for this project, but I may find a use in GPS RTK systems. I considered generating an extra quadrature clock or clocks for one FPGA application, with some external means of adjusting the phase. But I didn't have any spare pins. I was even using the mode and JTAG port pins. On the one hand I'd like to use a bigger package with more pins. On the other, the output delays are even worse! -------- Thanks again for your comments and very speedy responses. Paul Richards SRD Ltd UKArticle: 14388
>As long as your "practical" doesn't require the code work
>correctly on various systems, you are free to be "practical"
>and ignore the standard.
I meant to suggest the "void" type, as opposed to specifying
no type. Doing so will render the code compilable and
executable on all systems that I have used, in spite of any
standard requirements to the contrary.
Practical can mean: Since standards are often not followed
exactly (consider RS-232), do what works and forget the
standard as necessary.
As for the desire for code to work "correctly on various
systems," I have yet to identify a system where a "void"
type specification on the "main" routine renders the code
error laden, non-functional, etc.
Give me a specific example of some system upon which
either:
a. such a specification yields a compile-time error, or
b. a run-time error, even if the error appear only upon
a normal termination of the program (i.e. the error
is determined when processor control is returned
to the operating system upon program termination).
IMHO, there are no operating systems which fail upon the
return of a program written in C which fails to provide a
return code, and if there are such operating systems, then
they contain design faults. I can think of many situations
in which a program does provide a return code, which
return code is not forwarded to the operating system. In
the cases that come to mind, the trouble will be external
to the program and the operating system. Clearly, the
stability of an operating system is questionable if it is
subject to failure simply because a program fails to
provide a return code.
William R. Buckley
Article: 14389In article <78np73$gke$1@news-2.news.gte.net>, BuckSavage <wbuckley@transdyn.com> wrote: >For my two cents, I can tell you all that I have written >many C programs that do not include a return type >declaration for the MAIN routine, and operating >systems (from Windows NT to VAX/VMS) seem to >be quite accepting of the constructions that I use. Well, of course! There's a lot of shoddy code out there. I know there exists at least one compiler which will notice i = ++i; but most will accept it. >If there is to be a requirement for a return type >declaration, then the statement above should >result in an error being issued by the compiler >upon compilation of the code. Many do. gcc does on a few platforms (especially in -Wall, as of about 2.8.x), and the old VAX C was famed for complaining about this when invoked in some common mode. >Since such an error >is not reported, then I have to say that it is not >required that a declaration be given. False conclusion. Not all errors require a diagnostic message; in fact, very few do. >It is better to be motivated by the practical than >the ideal (though ideals are often worth striving >for), given that the goal is to complete some >useful work. If it were harder to declare main correctly than incorrectly, this would be a wonderful argument. Note followups. -s -- Copyright 1999, All rights reserved. Peter Seebach / seebs@plethora.net C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon! Send me money - get cool programs and hardware! No commuting, please. Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!Article: 14390
In article <78ooaj$6cv$1@news-2.news.gte.net>, BuckSavage <wbuckley@transdyn.com> wrote: >I meant to suggest the "void" type, as opposed to specifying >no type. Doing so will render the code compilable and >executable on all systems that I have used, in spite of any >standard requirements to the contrary. You mentioned VAX/VMS, and yet, people have often reported that the normal system compiler there chokes on non-int declarations of main. You might want to double-check. >As for the desire for code to work "correctly on various >systems," I have yet to identify a system where a "void" >type specification on the "main" routine renders the code >error laden, non-functional, etc. So? What's the *advantage*? >Give me a specific example of some system upon which >either: > a. such a specification yields a compile-time error, or VAX/VMS, also 'gcc -Wall -Werror'. (Which is a good start.) > b. a run-time error, even if the error appear only upon > a normal termination of the program (i.e. the error > is determined when processor control is returned > to the operating system upon program termination). Almost everything; including, for instance, every Unix I've ever used. $ exec /bin/ksh # any POSIX shell will work $ PS1='$?:$ ' 0:$ /path/to/void/main/program 83:$ _ The number '83' may vary, may be 0, or may do just about anything - but it's an error return. >IMHO, there are no operating systems which fail upon the >return of a program written in C which fails to provide a >return code, and if there are such operating systems, then >they contain design faults. What do you expect them to do? They're expecting an exit status. What should they do when you give them random numbers? >stability of an operating system is questionable if it is >subject to failure simply because a program fails to >provide a return code. Define "failure" - perhaps just reporting that the program indicated failure by means of a return code which doesn't indicate success? Anyway, this is a FAQ. -s -- Copyright 1999, All rights reserved. Peter Seebach / seebs@plethora.net C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon! Send me money - get cool programs and hardware! No commuting, please. Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!Article: 14391
Rick Filipkiewicz wrote: > > > o Language +: Get Verilog and VHDL > > But you can't use verilog and vhdl in the same design ! Andrew.Article: 14392
Hi, look there: http://www.wotsit.org/binary.htm regards E. JOLLY On Fri, 15 Jan 1999 12:25:42 +0900, "Kang YI" <yk@comp.snu.ac.kr> wrote: >Hello, > >I'll appreciate if you let me know the Intel HEX file format. > >Thank you. > >Kang YI. > >Article: 14393
Hi, I have a problem on one design where there is one EPF10K50VRC240-3 which is configured at power-up by one EPC1-PC8. The schematics has been check by ALTERA's rep. in France and should be OK. The problem is the following: Sometimes, my design doesn't download from the EPC1 to the ALTERA. If I look at the signals with an oscilloscope I can see that CONF_DONE is low and nSTATUS is low also. According to AN59 nSTATUS should be high to enable the EPC1. As nSTATUS is low, the download process cannot take place. This problem is correlated with the temperature of the device. When the environnement is warm, the download process takes place but when I cool down the chip (with a cooling spray) it doesn't download. Any ideas?? Regards. E. JOLLYArticle: 14394
Andrew Brown wrote: > > But you can't use verilog and vhdl in the same design ! > > Andrew. And with Spectrum.... You can. -- Brian C. Boorman Harris RF Communications Rochester, NY 14610 XYZ.bboorman@harris.com <Remove the XYZ. for valid address>Article: 14395
In article <78ooaj$6cv$1@news-2.news.gte.net>, BuckSavage <wbuckley@transdyn.com> wrote: > >Give me a specific example of some system upon which >either: > > a. such a specification yields a compile-time error, or > b. a run-time error, even if the error appear only upon > a normal termination of the program (i.e. the error > is determined when processor control is returned > to the operating system upon program termination). Frankly, I would consider that to be any operating system that allows the caller to test for sucessful execution of a program. These operating systems include DOS, Windows, all unix systems, and VMS. The error is not by default reported to the user under these system. However the error indication does exist and may influence the execution of future programs. (Actually the DEC VAX C compiler will not allow a "void main()" at compile time.) >IMHO, there are no operating systems which fail upon the >return of a program written in C which fails to provide a >return code, and if there are such operating systems, then >they contain design faults. I would agree that any fault in a program should not affect the stability of an operating system. That doesn't mean your programs shouldn't work properly because they can't crash the system. Consider the follow unix shell script: #! /bin/sh if ( $* ) then echo Program $* executed sucessfully. else echo Program $* either didn't work. fi Often it will report that a program with a void main() declaration did not work properly. In some cases a reported failure could cause an exit from a batch job, command script, or another executable that calls the program. > I can think of many situations >in which a program does provide a return code, which >return code is not forwarded to the operating system. Feel free to provide an example of an OS that does not accept return codes from applications. I'm not sure I understand what your big problem with "int main()" is. Are you arguing that any code that works once is by definition correct everywhere? IMHO, the whole "if it doesn't generate an error it must be correct" is a poor standard for program quality. Eric -- Eric Korpela | An object at rest can never be korpela@ssl.berkeley.edu | stopped. <a href="http://sag-www.ssl.berkeley.edu/~korpela">Click for home page.</a>Article: 14396
Hi All, Has anybody ever used a Mirotech FPGA board ( X-CIM, ARISTOTLE...). These boards contains DSPs on boards. Any experience will be helpful. Cheers.Article: 14397
Hi Evan, It is what you have said in the first case. I tried to put an intermediate signal in between, but the problem remains. Khaled.Article: 14398
Austin Franklin wrote: > Even if I've identified the chips organization, I still don't understand > why 12 chips. 10 chips I would understand if it had 4 bit parity, and 8 > chips with no parity. > > Austin This is probably a "downgrade" module. The chips have been remarked by the downgrade memory module manufacturer. It looks like the module was made mainly from sorted x4 chips that only had x3 good bits. One or two of the chips may have sorted out at x1, or x2. Buyer beware.... -- Bill MoffittArticle: 14399
At the risk of being tiresome.... If the modules are instantiated in the .xnf, and their .xnf or .ngo files are in the directory when you optimize, then the logic connected to those signals must have ended up on the cut list in the optimization report. Is that the case? If so, you need to trace through the list to find out why. If one output is not connected because of a typo, then all the inputs associated with it could go away. bruce Khaled benkrid wrote in message <36AE7492.D1E29BA7@qub.ac.uk>... >Hi Bruce, > > The box your mentionned is checked. The problem is that there are some ports >which are connected >to IPAD and others not (I have already looked at the XNF file ). The description >of the warning message says : >"The pad mapping optimization step assumes that if a port in the top design does >not have a net attached to it that no pad cells ". These are inputs and >connected to input pins of lower components in the hierarchy, that's why they >are not attached to any net in the top level. There are no errors or warnings >before the optimization phase ( bug?). > > >Khaled. > > >
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