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
Will wrote: > By its very nature, TCP/IP is not real time. Network can have delays, > packets can get lost. I think TCP/IP lends itself better to a > software implementation. I agree, unless you have lots of data to send/receive. Then software can't keep up. > Well, it's interesting if you can jam all the TCP logic in a sub 1000 k gates > , do all the checksumming in one clock cycle, match IP's in a CAM, etc... The key phrase is "wire speed". -- Phil HaysArticle: 47851
In article <3D9F21D0.12AAC8B@attbi.com>, Phil Hays <SpamPostmaster@attbi.com> wrote: >> Well, it's interesting if you can jam all the TCP logic in a sub >> 1000 k gates , do all the checksumming in one clock cycle, match >> IP's in a CAM, etc... >The key phrase is "wire speed". However, until you are doing 1Gb+ packet processing, EL Cheapo Embedded PC (EG, the Via EPIA system, very cute) has enough horespower to keep up with TCP and have a fair amount left over. Gb+ is another kettle of fish. I WANT, WANT, WANT, a PCI card with a V2Pro and quad Gb ethernet. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 47852
>If b and c are in adjacent CLBs, the routing time could be extremely >small and a skew due to external jitter and/or internal clock net skew >could result in a metastable event. You don't need metastability to cause problems in that sort of setup. You can get in trouble with pure setup problems. If the clock on the second FF is a bit late it will see the new value rather than the old value. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 47853
On Thu, 03 Oct 2002 02:10:55 -0000, hmurray@suespammers.org (Hal Murray) wrote: > >>i want to implement a moving average filter in my FPGA. That's not the >>big problem, but the window size of the filter should be changeable >>during runtime... > >This isn't what you asked for, but it might be good enough. > >You can get a weighted-average without any memory if you can multiply. >The recent samples get more weight and the weight of older samples decays >exponentialy. > >Formula is: > new-avg = old-avg*(1-w) + sample*w >Where w is less than 1. > >Values of w like 1/8 are typically used in networking code to >"average" out round trip time measurements. > >If you pick w to be a power of 2 then the multiply is just a shift. >General barrel-shifters are ugly, but it might be OK if you only >want to use a few values of w. > >Or you could use a real multipler and then use any value of w that >you want. Note there are no glitches when changing w between samples. Another way to express this is out = out + (in-out)/n where n is a power of two, namely a right shift. OUT will obvioulsy need more bits than IN, in order not to lose the shifted stuff. JohnArticle: 47854
"Darryl Groom" <dgroom@continental-microwave.co.uk> wrote in message news:<ee795d5.-1@WebX.sUN8CHnE>... > Has anyone tried to implement a tone detector based around a goertzel algorithm filter. I am looking for an example in VHDL or schematic form as we are experiencing difficulty in getting the System Generator software working to be able to pull our Matlab/Simulink model into the Spartan-II device we are currently using. Is the first time I heard about goertzel and had to do a search with the google. Its very interesting but if you want a very fast and easy way to detect DTMF tones or other frequencies perhaps I may help you. 5 years ago I began a project whith the slowest CPU I know, the ST6, and was decoding DTMF from the telephone line to detect the numbers typed from any phone of a house. Early becomes evident that the methods learned in the university was unusables for that CPU and I began investigating and simulating other ways. The solution came from taking the essence of the Fourier Transform. I conver all analog signal to digital without using the ST6'ADC, I feed an smith trigger whith the analog line for doing right edges, and then directly to an ST6 digital input. The Fourier resulting coefficients were stored in 8 counters, each one representing a frequency. The counters with greater values showed the frequencies received . I will try to explain it in my poor english, for detecting the tones we dont need to calculate the exact values of the coeficients but only the ones with greater values thus we can eliminate the final calculations, making the resulting coeficients of the Fourier Transform obtained multiplicating the right point of the sine and cosine waves and adding or substracting the resulting value to others obtained before. First at all I calculate this waves and put them in a constant binary table which contains a "1" if the wave was >0 volts in this point and a "0" if was <0 volts. The sum of values for making the coeficients was stored in up-down counters, I thing 2 for every frequency. You also need 2*n tables, been n the number of frequencies detected. You dont need to multiplicate anything because the tables and the input are 1 bit values, you only XOR the two values. Dont add the resulting value to the others because is 1 bit wide, store it in a counter. When the result was "1" I incremented the right counter, and when was "0" I decremented it, or incremented another one. Well, I dont remember exactly how it was but the simulations on BorladC++ showed a strong correlation between the input frequences and the value of the counters. I remember to simulate a lot and as more samples taken more correlation done and the other counters had very low values. It was incredible to put that in so slow CPU but it worked very well, if you dont belive it you can simulate with a C++ program. If you implement that in a FPGA I am sure the wasted recurses will be much lower than whith the Goertzel Algorithm filter,and once the simulations were done you can implement it in few hours, even in schematics because it only has any counters, rom tables and xor gates. Of course if you are interested I can give you more details and look for the simulations. Narcís NadalArticle: 47855
People has been doing minimal TCP that is only a few pages of C code. The thing is why would I want to buy a 500 bucks TCP accelerator when the most I could get on my modem is 50 kbits/sec. There is not a market for TCP/IP in hardware. Not for the home user anyway. hmurray@suespammers.org (Hal Murray) wrote in message news:<upjioaku2e1le1@corp.supernews.com>... > [suggest software] > > iam not looking for such a solution TCP/IP in hardware is it feasible > > Look at the source code for a TCP stack. It's a huge state machine. > Just take a page or two of code and try to convert that to hardware. > > I haven't seen any reports of doing TCP in hardware, but I could > easily have missed something. (But somebody would probably mention > it here.) > > As an example, consider just routing, a small part of the TCP/IP stack. > High end routers do some of the table lookup in hardware, but they > normally drop back to software for the hard/rare cases.Article: 47856
I am working on a DDS-based pulse generator with 1 Hz to 1 GHz output frequency and a resolution of 10,000 steps per octave. For the GHz output, I need Virtex-IIPro, but 300 MHz (600Mbps) with LVDs could be done in an XC2V40. Even multiple independent outputs, and/or a built-in frequency counter. The problem is keeping the jitter down, well below one clock period... Send me e-mail, and we can talk about details. BTW, CoolRunner is a more modern CPLD family, and what's the problem with 24 bit accumulation? Speed? Peter Alfke, Xilinx Applications =============================== Peter Hiscocks wrote: > We're building a function generator that uses a 24 bit Direct Digital > Synthesis oscillator. It will fit into an FPGA with no problem, but I'd > really like to shoehorn this thing into a PLD to avoid the need for a boot > ROM chip and to keep the cost down. > > The Xilinx 9000 series PLD's I've tried won't do because of the requirement > for a 24 bit adder. Anyone have any suggestions of other chips I should > investigate for this? > > Thanks for the help - > Peter > > -- > Peter D. Hiscocks > Department of Electrical and Computer Engineering > Ryerson University, > 350 Victoria Street, > Toronto, Ontario, M5B 2K3, Canada > > Phone: (416) 979-5000 Ext 6109 > Fax: (416) 979-5280 > Email: phiscock@ee.ryerson.ca > URL: http://www.ee.ryerson.ca/~phiscockArticle: 47857
skillwood <skillwood@hotmail.com> wrote in message news:anh8fa$e1cg3$1@ID-159866.news.dfncis.de... > Hi , > anyone have good links for BIST and ATPG . > thanks > > begin 666 Design-for-Test Technical Papers.url M6T1%1D%53%1=#0I"05-%55),/6AT=' Z+R]W=W<N;65N=&]R+F-O;2]D9G0O M='!A<&5R<RYC9FT_=CTR,#4W,S(F<#TW,C8V,#DU)G,]-#,Q.#4T-B9C/61F M=%]O=F5R='5R95]K97EW;W)D+F=I9@T*#0I;26YT97)N9713:&]R=&-U=%T- M"E523#UH='1P.B\O=W=W+FUE;G1O<BYC;VTO9&9T+W1P87!E<G,N8V9M/W8] M,C U-S,R)G ]-S(V-C Y-29S/30S,3@U-#8F8SUD9G1?;W9E<G1U<F5?:V5Y G=V]R9"YG:68-"DUO9&EF:65D/44P-S4R-D,V0T0V0T,R,#$S1 T* ` endArticle: 47858
Hey all...
In the past I've used ActiveHDL (great product!) But this semester I had a
tighter budget so I'm giving the Xilinx WebPack ISE 5.1i + Service Pack 1 a
try.
I have a XC95108 CPLD next to my Virtex chip and need to download some
simple VHDL to the CPLD... but ISE won't Fit the code...
here's the error I get:
Started process "Fit".
can't read "xcpldFitDesFastConnectUIM": no such variable
while executing
"if { !$xcpldFitDesFastConnectUIM } {
lappend Options "-nouim"
}"
invoked from within
"if { [string equal $p_DevFamily xc9500] } {
if { !$xcpldFitDesFastConnectUIM } {
lappend Options "-nouim"
}
switch -- $xcpldFitDesLocal..."
(file "C:/Xilinx/data/projnav/scripts/_cpldfitrun.tcl" line 95)
Now... I disabled the FastConnect optimization routine in the options and it
still gives that error. What can I do? I'm not familiar enough yet with
ISE to figure this out on my own!
Thanks,
Tony
Article: 47859
Hello,
I'm having problems simulating
a design in Foundation 3.1i using
a Synchronous FIFO core. I'm
receiving an "undetermined input
pin state" error for a pin name
internal to the CORE. All external
signals are defined.
I've seen other postings with this
same problem but no solutions in
the threads. Does anyone have a
solution/suggestions for this
problem?
Thanks much,
Casey
Article: 47860>People has been doing minimal TCP that is only a few pages of C code. >The thing is why would I want to buy a 500 bucks TCP accelerator when >the most I could get on my modem is 50 kbits/sec. There is not a market >for TCP/IP in hardware. Not for the home user anyway. A "few pages of C" would be very impressive for a TCP stack. Don't forget the driver and buffer management and ... Just for calibration, TCP on this Linux box is 6 modules and 11K lines of code. (Yes, much of that could be pruned.) Modern PCs can run TCP benchmarks at line rates on gigabit Ethernet. Most of the CPU/memory is chewed up copying data to/from user/kernel. I expect the target is busy web/file servers and things like that rather than home users. In that context, $500 to double network performance would be a great deal. Might be good for some graphics workloads too - visualization on supercomputers. As Ray points out for DSP applications, if you can do it in software running on mainstream hardware that's probably cheaper/better. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 47861
Utku Ozcan <utku.ozcan@netas.com.tr.nospam> wrote: > Very sensible. Modelsim uses a Tcl bytecode virtual machine, like JVM. Really? Where did you get this information? I confess that I find Tcl to be one of the most awful languages I have ever used. IMHO it has no virtue whatsoever. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 47862
Dan <hombecker1962@hotmail.com> wrote: > hamish@cloud.net.au wrote in message news:<3d9adedd$0$30860$afc38c87@news.optusnet.com.au>... >> By the way, from what I hear, Windows applications can't use more than >> 2Gb anyway. If your route needs more, it will crash. So 3Gb of RAM might >> not be worth it, unless you will run other memory-intensive tasks at the >> same time as PAR. > > Hi I just wanted to say thanks for the advice, and to point out that > with special hooks you can get windows 2000/XP to use up to 3 gigs of > RAM but evidently there are some caveats to that, but it can be done > as the Xilinx manual points that out (at least for 5.1i) OK that's good news. I heard that there was a special version of NT that had a 3Gb/1Gb user/kernel split but didn't know about 2000/XP. It'd also be interesting to know whether running under Wine gets you the Windows 2Gb/2Gb split or the native Linux 3Gb/1Gb split. Thanks for the info, Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 47863
>Actually i am looking a solution which will internet enable 8 or 16 bit >devices .For applications such as remote sensors which communicate through >TCP/IP. What sort of bandwidth and physical link? Video cameras or temperature? Ethernet or RS-232? For something simple like a temperature sensor, I'd use UDP rather than TCP. That avoids keeping track of all the TCP state. (and timers) It pushes some of the work back to the other end, but you probably have something smart like a PC there. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 47864
In article <3d9fa193$0$22176$afc38c87@news.optusnet.com.au>, <hamish@cloud.net.au> wrote: >I confess that I find Tcl to be one of the most awful languages I have >ever used. IMHO it has no virtue whatsoever. It has one virtue, it drove the development of TK, which is quite tolerable when used with something like Scheme to make Scheme/Tk. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 47865
Peter Hiscocks wrote: > > We're building a function generator that uses a 24 bit Direct Digital > Synthesis oscillator. It will fit into an FPGA with no problem, but I'd > really like to shoehorn this thing into a PLD to avoid the need for a boot > ROM chip and to keep the cost down. > > The Xilinx 9000 series PLD's I've tried won't do because of the requirement > for a 24 bit adder. Anyone have any suggestions of other chips I should > investigate for this? > > Thanks for the help - The 'biggest CPLD' are tending to cost more than the 'smallest FPGA', but you could look at Coolrunner 2, and the newest wide fanin lattice devices. There are also other ways to keep the Loader costs down, such as using a uC, which could benefit in DDS interface / config as well -jgArticle: 47866
In article <3d9fa193$0$22176$afc38c87@news.optusnet.com.au>, <hamish@cloud.net.au> wrote: >Utku Ozcan <utku.ozcan@netas.com.tr.nospam> wrote: >> Very sensible. Modelsim uses a Tcl bytecode virtual machine, like JVM. > >Really? Where did you get this information? > If you've ever used ModelSim you'll notice that they allow you to script simulations with Tcl - which strongly implies that there is a Tcl interpreter embedded in ModelSim. Also, I believe that the ModelSim GUI is implemented in Tcl/Tk. >I confess that I find Tcl to be one of the most awful languages I have >ever used. IMHO it has no virtue whatsoever. > I would tend to agree with you, especially when you compare it to an elegant language like Ruby (http://rubycentral.org), for example. However, Tcl has been around for a while so there tend to be a lot of folks who know it and it's easy to embed Tcl in applications written in C/C++. I suspect that it's the latter reason that Tcl is used in ModelSim and several other EDA apps. There are better languages available now than Tcl (such as Ruby) but it might take a while before we start seeing them show up embedded in EDA apps. Also, I suspect that a hardware implementation of Ruby would be a lot more difficult to do than this hardware implementation of Tcl given the dynamic nature of Ruby (the same could be said for Python too, I suppose). PhilArticle: 47867
On 6 Oct 2002 06:23:57 GMT, ptkwt@shell1.aracnet.com (Phil Tomson) wrote: >In article <3d9fa193$0$22176$afc38c87@news.optusnet.com.au>, > <hamish@cloud.net.au> wrote: >>Utku Ozcan <utku.ozcan@netas.com.tr.nospam> wrote: >>> Very sensible. Modelsim uses a Tcl bytecode virtual machine, like JVM. >> >>Really? Where did you get this information? >> > >If you've ever used ModelSim you'll notice that they allow you to script >simulations with Tcl - which strongly implies that there is a Tcl >interpreter embedded in ModelSim. Also, I believe that the ModelSim GUI >is implemented in Tcl/Tk. >From http://www.tcl.tk/doc/compiler.html "Tcl 8.0 introduced an on-the-fly byte-code compiler for Tcl." I just learned something. I had always thought that Tcl was purely interpreted. Regards, Allan. >>I confess that I find Tcl to be one of the most awful languages I have >>ever used. IMHO it has no virtue whatsoever. >> > >I would tend to agree with you, especially when you compare it to an >elegant language like Ruby (http://rubycentral.org), for example. >However, Tcl has been around for a while so there tend to be a lot of >folks who know it and it's easy to embed Tcl in applications written in >C/C++. I suspect that it's the latter reason that Tcl is used in >ModelSim and several other EDA apps. > >There are better languages available now than Tcl (such as Ruby) but it >might take a while before we start seeing them show up embedded in EDA >apps. Also, I suspect that a hardware implementation of Ruby would be a >lot more difficult to do than this hardware implementation of Tcl given >the dynamic nature of Ruby (the same could be said for Python too, I >suppose). > > >PhilArticle: 47868
Hello,
I use Systronix POD for programming Xilinx CPLDs and it works file. But I
can't drive CPLD by myself (I wanted to check JTag in action getting the
IDCODE form CPLD). So, I've written small program in Delphi sending IDCODE
opcode (8 bits) + 32 bits of data shift bits and recorded all signals with
logic analyzer. The CPLD chip responded with the correct ID code.
The problem is that I can't read response (TDO) from LPT port at PC! All
I get are zeroes. The CPLD drives '1' out as 1.6V and my PC accepts it as
'0'.
How can iMPACT software read the correct value? The connection is the
same, i.e. TDO is connected to LPT pin13 (select).
Thanks.
Article: 47869Hi Ray, Sorry for the delay in my response, I'm traveling a bunch these days. Healthy skeptisim is great. I was actually skeptical when I started working on this technology about 3 years ago. Regarding your question on performance. In every case so far, we met or beat the performance targets for the device. In most cases we will beat area as well, but not all. The reason is that the compiler will do things (like share resources) that you simply will not because of the complexity of trying to manage it. I don't advocate using Handle-C. Everything I've seen as well brings it too close to hardware. For an algorithmic design, I want to leave my algorithm untouched. And to leave the algorithm untouched you must have, as someone pointed out, a very sophisticated compiler. We've already done designs such as image compression, encryption, filters, etc. where we've been able to create multiple RTL implementations with different area/performance tradeoffs in a fraction of the time it took to create a single version of the hardware by hand. And, in most cases, we were able to get a final end results (area vs. performance) than the customer got by hand. You'll say the same thing they did: "No Way!" -- that's ok, it's up to us to prove it. This is simply a progression in hardware design much as a C compiler was a progression beyond assembly in software. Yes, there will always cases where the HDL has to be so compact to meet the goals that you must write low level verilog (or even gates). As president of your company, I'm sure you would agree for certain applications, the value of time to market dramatically overshadows most other costs in the process. Clearly the design must meet timing - clearly it must be in some tolerance of area -- but if you can save 3,6, or more months to market -- what is the savings (or gain) there? For the "Show Me" part, let's talk about that - the proof is in real results. Thanks for the spirited discussion - Brett "Ray Andraka" <ray@andraka.com> wrote in message news:3D9A76DD.453A4B46@andraka.com... > > > Brett Cline wrote: > > > Hi All- > > > > Synthesis from a C/C++ algorithm is absolutely possible and has been in > > use for some time. Even "plain vanilla C" algorithms can be used with the > > right synthesis product. > > Show me. Nothing I've seen can handle C code that was not specifically written > to create hardware. I think your next sentence probably validates that as > well. Plain vanilla C has nothing in it to support concurrency, and I know of > no product that can infer that concurrency from existing (not written > specifically to map to hardware, usually using special extensions) code. > > > > Obviously it does take some amount of hardware > > knowledge to get reasonable hardware out the backend. All that should be > > required is to add the hardware interface structure to the C/C++ algorithm. > > For that we recommend using SystemC (there is a reference implementation > > available under an open source license at www.SystemC.org). SystemC provides > > the necessary abstraction in C++ to add concurrency, bit accuracy, and other > > hardware-isms to the C/C++ algorithm. > > > > To take the algorithm to hardware (RTL Verilog or VHDL) my company offers > > a product called "Cynthesizer" for high-level synthesis from SystemC. We've > > had a number of customers take generic algorithms (some even from the web) > > such as filters, encryption, multimedia, etc. and convert them directly to > > RTL Verilog and VHDL. The resulting RTL can be put into any FPGA or ASIC > > synthesis tool as well as any other tool that operates on RTL. > > But at what price? Is the performance and density reasonably close to a what a > skilled hardware designer can accomplish? > > > > > > > For more information check out our web site at www.ForteDS.com or feel free > > to email me directly. > > > > Best regards, > > Brett > > > > "Ray Andraka" <ray@andraka.com> wrote in message > > news:3D894809.ECF33E30@andraka.com... > > > Not exactly. There are several vendors that have C to hardware > > compilers, > > > but don't expect to take plain vanilla C and compile it directly to > > hardware. > > > For the most part, these tools use subsets and extensions to C to permit > > > description of hardware and all the parallelism that implies in a C-like > > > environment. It raises the level of abstraction, and as a result you tend > > to > > > get a design that is more bloated and slower than one done closer to the > > > hardware. The point is that there is no free lunch, there is a > > considerable > > > engineering effort to convert your software to something that will run at > > a > > > reasonable speed in an FPGA that you can afford to buy. > > > > > > mike wrote: > > > > > > > I can't claim to be an expert, but what I think you want to do isn't > > > > going to work. You can't take any arbitrary C/C++ program and convert > > it > > > > into VHDL code that will run on an FPGA. For making something like a > > > > hardware mp3 player, you may want to look at something like a > > > > programmable DSP board. Also, you should check on what, if any, analog > > > > outputs are avilable from the FPGA you're using. For example, on the > > > > Altera student board, the only analog output is for a VGA monitor, so if > > > > you wanted to make an mp3 player using one you'd need to build an > > > > interface to convert the decoded digital audio into analog audio. > > > > Mike > > > > > > > > On Tue, 17 Sep 2002 09:27:21 +0000, DJohn wrote: > > > > > > > > > Hi all VHDL experts, > > > > > Is there any tools which can convert a C\C++ source file to VHDL . > > For > > > > > example If I have a C source code for a MP3 decoder , Can any tool can > > > > > convert it into VHDL equivalent. There is some facility in FPGA > > > > > Advantage to generate a wrapper VHDL for a C File , what exactly is > > > > > that ? Does that mean I can synthesize a C\C++ file by creating a VHDL > > > > > Wrapper. Please help > > > > > > -- > > > --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 > > > > > > > > -- > --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: 47870
Phil Tomson <ptkwt@shell1.aracnet.com> wrote: > In article <3d9fa193$0$22176$afc38c87@news.optusnet.com.au>, > <hamish@cloud.net.au> wrote: >>Utku Ozcan <utku.ozcan@netas.com.tr.nospam> wrote: >>> Very sensible. Modelsim uses a Tcl bytecode virtual machine, like JVM. >>Really? Where did you get this information? > > If you've ever used ModelSim you'll notice that they allow you to script > simulations with Tcl - which strongly implies that there is a Tcl > interpreter embedded in ModelSim. Also, I believe that the ModelSim GUI > is implemented in Tcl/Tk. I'm aware that it has a Tcl interpreter, but haven't seen any evidence that there's any compilation going on. It's pretty obvious that plain old tclsh doesn't do any compilation, because if you change the source file on disk while you're running it it gets confused! ModelSim SE allows you to use Tk in user Tcl scripts, but PE doesn't. > However, Tcl has been around for a while so there tend to be a lot of > folks who know it and it's easy to embed Tcl in applications written in > C/C++. I suspect that it's the latter reason that Tcl is used in > ModelSim and several other EDA apps. I'm quite a fan of Perl. IMHO every VHDL or Verilog developer could benefit from a basic knowledge of Perl and particularly its regular expressions. And Tcl as well, because so many of the tools have integrated Tcl (ModelSim, Synplify, ...) It might be that Perl wouldn't make a very good interactive shell though. Perl certainly has its share of haters, most of whom are Python users now I think. Cheers, Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 47871
Allan Herriman <allan_herriman.hates.spam@agilent.com> wrote: > From http://www.tcl.tk/doc/compiler.html > "Tcl 8.0 introduced an on-the-fly byte-code compiler for Tcl." "On-the-fly" doesn't seem to be an advantage. Tcl still can't detect even basic syntax errors in advance. I can just imagine writing a Tcl script that collects samples for a week, then bombs out with a syntax error just before writing the report. Admittedly Perl doesn't detect missing subroutines in advance, but it does detect syntax errors. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 47872
I've realized one interesting thing, the iMPACT sw forces TDO at POD to be 5V (logic '1'), while my sequence (reset + IDCODE) forces TDO to 2V (logic '1') and LPT can't recognize it as '1'. What's a secret of output voltage? The logic analyzer I've buid is low speed and I can't record the sequence sent by iMPACT. I suppose I need to control some more signals than just TDI, TCK and TMS from PC. There is neened something to enable CPLD->TDO->PC data stream. I guess that Xilinx has inilially a mode driving TDO from PC to chenk cable presence and then enables tdo from device. Thanks for any advice.Article: 47873
I like to think of it like this: out <= (in * (x/8)) + (out * ((8-x)/8)) Where the proportions of the new in, and the old out, both sum to one whole new out. In this example, using 8 as an arbitrary but good power of 2 to reduce how many variables we are looking at, We see that the out will eventually settle to the correct solid state. The smaller x is, the higher the dampening factor. It would not be difficult to quickly verify this with a step response in Excel, trying values 1,2,3 for x. Just use a couple of zero rows to prime the output column, then copy this formula down the page, =(((B3)*((8-($C$1))/8))+((A3)*($C$1)/8)) Where column A has the step response data, column B has the output column, and cell C1 has x. Put a 1, 2 or 3 there), then insert a line chart. BB ========================================= > > Another way to express this is > > out = out + (in-out)/n > > > > >Formula is: > > new-avg = old-avg*(1-w) + sample*w > >Where w is less than 1. > > > >Values of w like 1/8 are typically used in networking code to > >"average" out round trip time measurements. > >Article: 47874
Brett Cline wrote: > Regarding your question on performance. In every case so far, we met or > beat the performance targets for the device. In most cases we will beat area > as well, but not all. The reason is that the compiler will do things (like > share resources) that you simply will not because of the complexity of > trying to manage it. <Set cynical> Meeting performance targets is easy if you pick low enough performance targets. <End cynical> Designs for high clock speeds usually can't do much resource sharing: routing and muxing of signals kills the performance. Usually the reverse is needed. I often find I need to duplicate resources to meet performance. That is, I'll make two copies of a group of logic so as to reduce the routing delays. As you seem to be selling Forte, does it make duplicate copies of logic based on the floorplan it creates? Can it make duplicate copies if told to? Oh, wait, I should ask this first: does Forte make or use a floorplan? If it doesn't, then how do you expect to match the speed of a design with a floorplan? Floorplans often reduce the clock cycle time of a design by 30%. So maybe I shouldn't expect a Forte based design to match the speed of a well crafted VHDL design? > I don't advocate using Handle-C. Perhaps you mean Handel-C? <Assume Handel-C is subject> > Everything I've seen as well brings it > too close to hardware. For an algorithmic design, I want to leave my > algorithm untouched. Handel-C is a somewhat higher level language than VHDL, however it is closer to the hardware than SystemC. And that is both a good thing, as you can build what you want, and a bad thing. I've been thinking about using Handel-C for the next design as it seemed to me to be getting close enough to a reasonable tool to be worth using. Not for the whole design, just of a part that is both complex and should be fairly easy to meet timing even if the tool doesn't do the best job. -- Phil Hays
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