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
Pete Fraser wrote: > > We're currently running a 3 GHz Pentium with 2 GB > memory under Windows 2000. > > We hope to speed things up by 15-20%, by going > to AMD X86-64 and / or Linux. > > Has anybody tried this? > Any feedback? I can't tell you what to expect from an AMD64 with today's software, but I expect this will be the platform of choice for the next couple of years. It may not be the best investment at the moment, but I expect by the end of the year, much of the software will be optimized for 64 bit operation and you will see over half the new engineering workstations running an AMD64 processor. IIRC, AMD is producing a low cost version of the AMD64. I expect sales will take off very quickly. Once these start showing up on the software developer's desks we will see them optimizing for it. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 66976
On Fri, 27 Feb 2004 15:04:46 -0800, Pete Fraser wrote: >We're currently running a 3 GHz Pentium with 2 GB >memory under Windows 2000. The server versions of Win2000 can handle up to 32GB of RAM, if that's the main limiting factor. Can get pricey, though :o(( >We hope to speed things up by 15-20%, by going >to AMD X86-64 and / or Linux. > >Has anybody tried this? >Any feedback? Unless there's a version of the compiler specifically for a 64-bit architecture, then you're unlikely to see any real speed gain to justify the cost, and even if there is, I doubt the gains would be all that impressive. 64-bit CPUs really only come into their own in applications that need to access very large virtual address spaces (>4GB). Mostly, that's server-type apps. The need for 64-bit arithmetic is likely very small in this case. Can the compiler multi-thread? If so, a mobo with a couple of HT Xeons (4 CPUs), will give you all the extra horsepower you'll need. If not, a dual-processor system would still perform a lot better, since one CPU can work flat-out on the compile, while the other is handling the OS and other background tasks. All this assumes that the compiler's performance is, in fact, CPU or memory bound as you imply. Are you actually certain that this is indeed the case? Might a faster disk system help? -- MaxArticle: 66977
I recently wrote a tutorial description of the Xilinx DCM features and limitations. It's a bit long, but it might help some people in this newsgroup: Xilinx DCMs This is a description of the capabilities and the limiatations of all Xilinx Digital Clock Manager (DCM) circuits. Basic functionality: In its simplest use, the DCM eliminates the clock delay between the incoming clock signal and the low-skew global clock distribution. With the appropriate feedback to its CLKFB input the DCM inserts the right amount of delay so that CLKIN and CLKO signals occur simultaneously (within a very small fraction of a nanosecond). Physically, CLKO is delayed by exactly one clock period, and this obviously requires a free-running, constant-frequency CLKIN. In BASE mode the incoming clock frequency can be multiplied by any integer from 1 to 32, or the clock frequency can be divided by any integer from 2 to 16, as well as divided by the non-integer values of 1.5, 2.5, 3.5, 4.5, 5.5, 6.5, and 7.5. The output is edge-aligned with the rising CLKIN edge whenever that is mathematically possible. (When divided by x.5, only every other output edge is aligned with the input edge). For integer multiply and divide ratios, the output is automatically adjusted to a 50% duty cycle. In BASE mode, the max frequency limit aplies to input and output frequencies, but the min frequency limit of 24 MHz applies only to the input frequency. In Frequency Synthesis mode,the incoming clock frequency can be simultaneously multiplied and divided by any integer from 1 through 32. A 200 MHz input, for example, can be multiplied by 19 and divided by 20 to generate a 190 MHz output. Since multiplication and division are performed mathematically, no 3.8 GHz internal frequency is generated. In FS mode, the max frequency limit aplies to input and output frequencyies, but the min frequency limit of 24 MHz applies only to the output (!) frequency. Note the difference: In BASE mode it's the input frequency that must be above 24 MHz, in FS mode it's the output frequency. Practical examples in BASE mode: 26 MHz : 13 = 2.0 MHz, 250 MHz : 2.5 = 100 MHz, 50 MHz x 5 = 250 MHz Practical examples in Frequency Synthesis mode: 10 MHz x 31 : 5 = 62 MHz 200 MHz x 27 : 20 = 270 MHz Not possible: 20 MHz : 5 = 4 MHz ( input frequency is too low for BASE mode, and output frequency is too low for FS mode. Use flip-flop dividers instead) 7 MHz x 6 : 5 = 8.4 MHz (output frequency is too low, change to 7MHz x 24 : 5 = 33.6 MHz and use two flip-flops to divide by the output by 4.) The flip-flops can then drive the global clock buffer, but do not guarantee the tight delay specification offered by the DCM. Note however that phase coherence in FS mode obviously can occur only once every D input cycles = once every M output cycles, and usually is irrelevant in a real application. Input Jitter: The DCM is guaranteed to tolerate max 1 ns of cycle to cycle jitter on its input. Higher jitter can cause the DCM to loose lock, which is then indicated on the Lock output going High, or the CLKFX_Stopped bit going High. Output jitter: Use the software tools to calculate the output jitter. There are additional software tools available to evaluate the effect of M and D on the output jitter. Contact your FAE.. Phase Shift Operation: The DCM can provide phase-shifted outputs. In BASE mode, it provides the input frequency with four phase angles ( 0, 90, 180, and 270 degrees), as well a the double frequency and the double frequency inverted (180 degr) In Phase Shifted (PS) mode, all outputs are shifted by a common amount, defined by an 8-bit control word N that specifies the phase shift of N/256 times the incoming clock period. The granularity is also limited by the delay chain increments, roughly 30 ps. This determines the effective resolution for frequencies above 150 MHz. The user can specify any one of 256 values, and the DCM will make the closest possible approximation, within 30 ps. The value N is usually set by configuration, but can also be adjusted dynamically during operation. I hope this long posting is helpful. Peter Alfke, Xilinx ApplicationsArticle: 66978
Hi,
Just a stupid question:
I need to implement something in high speed so I have to use RLOC_ORIGIN
statement as some experts suggested.
However, I couldn't find any information regarding to the "which CLB
(x?y?) associate with which output pin".
Does anyone know which Xilinx document to look at for the "addresses"
and phyiscal location of CLBs for certain FPGA? ( I am doing design with
Spartan 3 and Virtex 2 pro).
Thanks
Chris
Article: 66979"Pete Fraser" <pete@rgb.com> writes: > We're currently running a 3 GHz Pentium with 2 GB > memory under Windows 2000. > > We hope to speed things up by 15-20%, by going > to AMD X86-64 and / or Linux. > > Has anybody tried this? Quartus II 3.0 does not run on X86-64. See news:<87k76ox8ya.fsf@zener.home.gustad.com> or http://tinyurl.com/2pvlj The fix should be trivial since it's just the driver script which does not recognize the architecture. If it tried to run some X86 code rather than checking uname it would work. I dunno about 4.0 though. Anybody tried? Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 66980
http://www.opencores.org/projects.cgi/web/cpugen/overview http://www.opencores.org/cvsweb.shtml/cpugen/Article: 66981
There are various graphical tools to see the association of CLBs to IOBs, such as PACE, Floorplanner, and FPGA Editor. A straight ASCII file can be generated by running partgen - for example, "partgen -v 3s200ft256" which creates a 3s200ft256.pkg file. Chris Cheung wrote: > Hi, > > Just a stupid question: > > I need to implement something in high speed so I have to use RLOC_ORIGIN > statement as some experts suggested. > However, I couldn't find any information regarding to the "which CLB > (x?y?) associate with which output pin". > Does anyone know which Xilinx document to look at for the "addresses" > and phyiscal location of CLBs for certain FPGA? ( I am doing design with > Spartan 3 and Virtex 2 pro). > > Thanks > > Chris -- Marc Baker Xilinx Applications (408) 879-5375Article: 66982
"Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message news:c20bhk0319e@enews1.newsguy.com... ..snipping problems.. > Because of all this, I have simply ignored 6.1 and have been using 5.2, > which works. > > The question really is, should I bother to try 6.2 ? If your design fits and works as expected, I'd say don't get update-happy just yet. We have a CoolRunner XPLA design that requires 3 MC more in 6+ than 5.2 (and thus won't fit), even after we went over the settings ensuring they were identical. Always archive the required software with the project.. Another annoying thing in 6.2 is that apparently they haven't tried the java on a machine with regional settings set to Danish. Danish uses ',' as decimal separator and '.' as thousands separator, they haven't handled that, and the java code throws a conversion error at the end of the fitter run. /KasperArticle: 66983
I've discovered incompatability between the ModelSim dongle and certain notebook computer's printer ports: They are 1. Toshiba Satellite S150s (I would suspect all Satellites). I've experienced this personally. I had to returnthis notebook and get a CompaqPresario 2500 in its place to make sure the dongle works. 2. Sony notebooks ( my local distributor has had this problem). The rumor is that its a voltage incompatabilty issue, but I'm not sure. Ted Lechman Utica, NYArticle: 66984
Hi all,
I wonder if some one had already worked or bought this demo board
Xilinx Demonstration Board with XC3020A and XC4003A and
XChecker cable.
I want to use some sheap one to test some design at home, so
what do you think about this board and is there any documentation,
help or some project that targeted this feature in the net???
Thanks for ur help
Article: 66985Does Webpack 6.2w has any FPGA Editor functionality inside?Article: 66986
> I want to use some sheap one to test some design at home, so > what do you think about this board and is there any documentation, > help or some project that targeted this feature in the net??? Somebody asked about this same setup a few weeks ago. Try google-groups. Both of those chips are very old. You will have trouble finding software that supports them. -- 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: 66987
Seems to be a common misconception that 64bits just increases the amount of addressable memory. More importantly for most applications is that twice the data is moved or operated on per clock cycle. Ken "Max" <mtj2@btopenworld.com> wrote in message news:6ig9409fn2h2futm3hjjmkd4uiv4lpkmu2@4ax.com... > On Fri, 27 Feb 2004 15:04:46 -0800, Pete Fraser wrote: > > >We're currently running a 3 GHz Pentium with 2 GB > >memory under Windows 2000. > > The server versions of Win2000 can handle up to 32GB of RAM, if that's > the main limiting factor. Can get pricey, though :o(( > > >We hope to speed things up by 15-20%, by going > >to AMD X86-64 and / or Linux. > > > >Has anybody tried this? > >Any feedback? > > Unless there's a version of the compiler specifically for a 64-bit > architecture, then you're unlikely to see any real speed gain to > justify the cost, and even if there is, I doubt the gains would be all > that impressive. > > 64-bit CPUs really only come into their own in applications that need > to access very large virtual address spaces (>4GB). Mostly, that's > server-type apps. The need for 64-bit arithmetic is likely very small > in this case. > > Can the compiler multi-thread? If so, a mobo with a couple of HT Xeons > (4 CPUs), will give you all the extra horsepower you'll need. > If not, a dual-processor system would still perform a lot better, > since one CPU can work flat-out on the compile, while the other is > handling the OS and other background tasks. > > All this assumes that the compiler's performance is, in fact, CPU or > memory bound as you imply. Are you actually certain that this is > indeed the case? Might a faster disk system help? > > -- > MaxArticle: 66988
On the disk speed issue I have one data point. I upgraded my 1GHz PIII-M laptop drive from a slow 4200 RPM to the fastest 7200 RPM available (for laptops) and my Nios system build went from about 16 min. to about 15 min. Not worth the pain and expense of swapping the drive. On memory, I upgraded the memory in my 3.2 GHz P4 from 512 to 1GB and there was no noticable difference until I set the memory from 333MHz to 400MHz dual channel. Then my system build went from 5 min. to 4 min. - 20%. Ken "Max" <mtj2@btopenworld.com> wrote in message news:6ig9409fn2h2futm3hjjmkd4uiv4lpkmu2@4ax.com... > On Fri, 27 Feb 2004 15:04:46 -0800, Pete Fraser wrote: > > >We're currently running a 3 GHz Pentium with 2 GB > >memory under Windows 2000. > > The server versions of Win2000 can handle up to 32GB of RAM, if that's > the main limiting factor. Can get pricey, though :o(( > > >We hope to speed things up by 15-20%, by going > >to AMD X86-64 and / or Linux. > > > >Has anybody tried this? > >Any feedback? > > Unless there's a version of the compiler specifically for a 64-bit > architecture, then you're unlikely to see any real speed gain to > justify the cost, and even if there is, I doubt the gains would be all > that impressive. > > 64-bit CPUs really only come into their own in applications that need > to access very large virtual address spaces (>4GB). Mostly, that's > server-type apps. The need for 64-bit arithmetic is likely very small > in this case. > > Can the compiler multi-thread? If so, a mobo with a couple of HT Xeons > (4 CPUs), will give you all the extra horsepower you'll need. > If not, a dual-processor system would still perform a lot better, > since one CPU can work flat-out on the compile, while the other is > handling the OS and other background tasks. > > All this assumes that the compiler's performance is, in fact, CPU or > memory bound as you imply. Are you actually certain that this is > indeed the case? Might a faster disk system help? > > -- > MaxArticle: 66989
Hi there, Kindly send an email to synthesis_support@mentor.com, and we can take a look for you. I believe there are other ways of describing what you want, that will pass synthesis. B. Regards, Darren Zacher Mentor Graphics Corp.Article: 66990
Kasper Pedersen wrote: > "Chris Carlen" <crcarle@BOGUS.sandia.gov> wrote in message > news:c20bhk0319e@enews1.newsguy.com... > ..snipping problems.. > >>Because of all this, I have simply ignored 6.1 and have been using > > 5.2, > >>which works. >> >>The question really is, should I bother to try 6.2 ? > > > If your design fits and works as expected, I'd say don't get > update-happy just yet. > We have a CoolRunner XPLA design that requires 3 MC more in 6+ than 5.2 > (and thus won't fit), even after we went over the settings ensuring they > were identical. Always archive the required software with the project.. Indeed. Good advice. Thanks for the input! > -- _____________________ Christopher R. Carlen crobc@earthlink.net Suse 8.1 Linux 2.4.19Article: 66991
rickman wrote: > erojr wrote: >> >> The JTAG Standard defines a JTAG reset pin, TRST. This pin is little >> used. All Altera docs (Datasheets, ANs) define this pin but write >> nothing about its usage. Therefore we did not connect it at all. But we >> experience problems in the JTAG chain: some EPC chips (especially big >> ones, like EPC8) almost never finish the Verification phase. I am >> wondering if this can be due to the unconnected TRST pins? > > Absolutely. TRST will reset the JTAG state machine when it floats > high. In addition, you should *never* leave a CMOS input floating. > When at an intermediate voltage CMOS will draw large currents through > the two FETs between power and ground. This can create voltage > transients on the power rail inside the chip which can upset other > circuits. TRST should either be driven by the JTAG cable, if the > emulator supports it, or pulled to Vdd via a resistor; or both actually, > so that the input does not float when the cable is not connected. The IEEE 1149.1 specification mandates that the TRST* pin have an internal pullup (if present, it's an optional pin). Pulling the pin low will keep the TAP controller in the TEST-LOGIC-RESET state (device functional). Normally I hardwire the pin to ground to ensure that in the case of any electrical noise or disturbance the chips stay in the operational mode. If there is no TRST* pin on a device, then normally a free running clock (not the system clock) should be sent into TCK with TMS=1. This will logically guarantee that if there are any ooopses, the TAP controller will return to the TEST-LOGIC-RESET state in no more than 5 clock cycles. Note that this is a general statement. Some implementations do not have the mandated pull-up resistor on the TRST*, for instance, and are non-compliant. -- rkArticle: 66992
Hi, Im trying to implement the ARM and IA32 ISA on an fpga. Im looking for some small program to be testbenches for my ARM and IA32 fpga processor. The small program can either be asm or RBF or other source code, but I'd prefer asm because then I can check to see if I've implemented all the necessary instructions. Should any of you happen to have some around could you please direct me on how to acquire them. thanks heaps.Article: 66993
Hi Max, > All this assumes that the compiler's performance is, in fact, CPU or > memory bound as you imply. Are you actually certain that this is > indeed the case? Might a faster disk system help? Provided the peak memory consumption of Quartus for the compilation in question is less than the amount of physical memory in the system, increasing the amount of memory will not help compile time. For non-trivial designs, a Quartus compile will be most heavily influenced by CPU speed, and then by memory sub-system speed -- disk speed will have little influence. CAD tools process a lot of data. I don't know if a Xeon (bigger cache) is much faster than a normal P4 (smaller cache), but I wouldn't be surprised if this were the case for the same reason that a Xeon processor is supposedly better for server applications -- bigger cache helps applications whose data set doesn't fit into the cache. Regards, Paul Leventis Altera Corp.Article: 66994
> Seems to be a common misconception that 64bits just increases the amount of > addressable memory. More importantly for most applications is that twice > the data is moved or operated on per clock cycle. 64-bitness _is_ mostly about addressable memory -- it is rare that 64-bit integers help reduce run-time. Please see my previous postings on the topic and some of the replies to it: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=Paul+Leventis+64-bit Regards, Paul Leventis Altera Corp.Article: 66995
Paul Leventis (at home) wrote: >>Seems to be a common misconception that 64bits just increases the amount >>of addressable memory. More importantly for most applications is that twice >>the data is moved or operated on per clock cycle. > > 64-bitness _is_ mostly about addressable memory -- it is rare that 64-bit > integers help reduce run-time. Please see my previous postings on the topic > and some of the replies to it: > > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=Paul+Leventis+64-bit I think the OP was refering to the wider datapaths. I don't know the cycle level details of the AMD or Intel 64 bit but an obvious and simple speed gain can come from a wider HW fetch. (even running < 64 bit opcodes ) and then a simple check if the next opcode / next data value is in that block. This works in systems where the CPU must wait for slower downstream memories, and even the smaller single chip microcontrollers are starting to do this. eg Philips ARM uC has 128 bit FETCH. Clearly, random code or data will not be helped, but a large % of code will be sequential. I'm not sure the AMD/Intel offerings hit the SIMD (Single instruction/multiple data ) of other cores, but even without that, some HW gains would be expected. -jgArticle: 66996
Hi Group I am trying to find a board with Xilinx V2 pro having A/D converter module, Irda module , RS232 module etc. My application is Intelligent Robotics. I am having xilinx V2pro HW AFX board, Memec Insight V2pro board, so any daughter modules with A/D, IrDa, Rs232 etc.. is another product I am looking for. Any help would be appreciated Thank you n advance RamArticle: 66997
Hi I had the same problem. All you have to do is use pullup for TRSTNEG and HALTNEG pins using PACE. RamArticle: 66998
"Kelvin" <kelvin8157@hotmail.com> writes: > Does Webpack 6.2w has any FPGA Editor functionality inside? Version 6.2 of WebPack doesn't seem to be released yet, so it's hard to say. But none of the previous releases have had it.Article: 66999
You can use JBits ( http://www.xilinx.com/products/jbits/ ) to find out the frame address of all elements. Miguel Silva simon <ssteineg@ee.ethz.ch> wrote in message news:<40449456$1@pfaff2.ethz.ch>... > hurjy wrote: > > dear all > > > > Let me put a few questions.... > > > > During reading XAPP151, the length of frame (Xilinx Virtex) is unclear for > > me. (2 IOB each 18 bit, each CLB 18 bit ---> then how many CLB in each > > frame, and how long is each frame?.... > cite xapp151 p.5: "The number of configuration bits in a frame is 18 × > (# CLB_rows+2)... " > # CLB_rows depends on which (virtex)device you are using... see Table 3 > in xapp151. > > > > > 2nd thing is how many padding bits are attached into each frame? > cite again xapp151 p.5: "...and is padded with zeroes on the right > (bottom) to fit in 32-bit words." > > > > > 3rd thing unclear is the addressing .... it will be great if there is > > document (or web) which comprehensively explains how the addressing (via > > frame) works... > well, besides it is only for virtex (until now! update to xapp138 is > announced maybe some updates to xapp138 will appear there) xapp151 is > not that bad, maybe you should spend some more minutes reading it... > > > > > Thankyou > > from fpga novice > > simon
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