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
"homoalteraiensis" <fpgaengineerfrankfurt@arcor.de> wrote in message news:1155228893.682178.172540@p79g2000cwp.googlegroups.com... >I got a "circuit", which is doing integer division with large values. I > instantiated a MEGAWIZ-devider with currently 48bits / 16 Bits, which > ist fed with some more bits (done be shifting) in order to obtain a > result with a higher accuracy than 1 in one step without proceeding the > remainder. > > E.g. I am shifting with 10 Bits and fill the rest with zero: > input <= "0000" & Value (33 downto 0) & "0000000000" > > I recognize, that Quartus is obviously capable of synthesizing away to > signals / paths in the devider which are not needed. > > Now, what is about the range of values ? In my design, the A / B have a > certain relationship, so that the result can never exceed 18 bits, > whereby the vector of the result (devider out) has of course 48 bits. > > Is it of an advantage if the range of values is restricted? > > Currently I am cutting away the first bits, which will always be zero. > s there anything more, I can do, to keep the design small ? If the result never exceeds 18 bits, I'd suggest writing the routine yourself. If your device supports an add/subtract structure, you need 18 stages to get 18 bits of result while the 48 stages produced with the MegaWizard might be more of a problem to optimize. By having the dividend start off in the correct range relative to the divisor, you only need 34 bits divided by 18 bits to give you your consistent 18 bit result. Any more bits just change add fractional bits to the remainder. If you could specify whether either value is signed and what the dividend and divisor ranges are, I'd happily email you an excel spreadsheet showing how the equations come together for the add/sub stages. Also please verify that you don't need the remainder.Article: 106501
Ah ha, I knew that somewhere the ranges had to be described. Since I don't code in VHDL, I didn't know. Thanks. Mystery solved. AustinArticle: 106502
"John_H" <newsgroup@johnhandwork.com> wrote in message news:un1Eg.7568$oa1.3750@news02.roc.ny... > By having the dividend start off in the correct range relative to the > divisor, you only need 34 bits divided by 18 bits to give you your > consistent 18 bit result. Any more bits just change add fractional bits > to the remainder. That should be "34 bits divided by 16 bits to give you your consistent 18 bit result"Article: 106503
>>>> You almost never want to have a fixed number of wait states but want to simply have the Avalon slave provide a wait request >>>> output and tell Avalon that by specifying that in the PTF file. >>> >>> Completely agree. When not writing and reading too many posts >>> I'm working on that version of the SRAM interface. It was just >>> a quick start as shown in the Quartus manual. >> >> BTW (to KJ): Do you have this type of Avalon slave >> for an SRAM? Would save some time and errors for me ;-) >> > No, over the past several years my use of async SRAMs has gone to 0 even though I used to use them quite heavily. They've been > replaced by internal > I'm assuming that you've checked and that Altera didn't toss one in as a MegaCore? Too bad. Their core for the (older) NIOS boards just uses the tri-state bridge .PTF approach - no VHDL > > Oh well, I'll stop posting and let you get back to work. > KJ Ok, I have now two versions of the SRAM interface: the plain PTF version and the VHDL version (with I/O registers at the FPGA pins to access a 15ns SRAM in two cycles at 100 MHz, and the nwr with the neg. clock to save one cycle on write). Here are some performance numbers of this JOP/SRAM interface on an embedded benchmark. It measures iterations/s and therefore higher numbers are better. All versions are clocked at 100 MHz, 4 KB instruction cache and 512 Byte stack cache. FPGA is Cyclone EP1C6-6, Memory is 32-bit SRAM 15ns. The only difference is the memory interface. SimpCon: 16,633 Avalon (PTF version): 14,015 Avalon (VHDL version): 13,920 So for me, the additional latency cycle(s) and not having the early ack information for the CPU pipeline degrades JOP's performance. Perhaps some Avalon specialist can do better. However, it is compensated by the many peripherals that are now just a mous click away ;-) MartinArticle: 106504
"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:4kbjdbFb9mhbU1@individual.net...
>> post-route sim is an attempt to give the warm fuzzies because of
>> inadequate or incorrect static timing analysis or incomplete testbench
>> coverage.
>
> A post-route sim is a final check-off item to
> prove that synthesis and my design rules
> have worked for at least one case.
I agree. To the extent that one has high quality functional test coverage
and has performed static timing analysis, post-route sim 'should be' just a
formality final check-off item, something that needs to be done but doesn't
provide much value (because of the above mentioned 'high quality....')
If you don't have that high quality test coverage or don't properly perform
static timing analysis in the first place then post-route sim's value might
increase dramatically but is still inferior to just doing the 'high
quality...' work in the first place.
> I keep it out of the edit, sim, edit loop
> because it is slow to run, adds
> little to timing or functional coverage,
> and rarely fails.
>
Yep, start it up on Friday afternoon and see if it has completed on Monday
morning.
> It is more efficient to work on coverage
> at full speed.
Tons more efficient ('mucho kilograms' for those outside the US)
> An interesting measurement
> is to sim the clock frequency outside the
> specified range to see if there are
> any logical limits built into the design.
>
Yep, and more specifically not just a single out of range frequency but run
it at several different frequencies both in and out of the design range to
catch those logical limits that you don't quite realize are in there.
KJ
Article: 106505Table 7-3 is in the RocketIO manual (UG076 v3.0, May 23, 2006)... /Mikhail "Peter Mendham" <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> wrote in message news:ebq05h$1h2$1@dux.dundee.ac.uk... > Dear all, > > I am struggling to find the information I need from the Xilinx > datasheet, perhaps someone could provide me with some pointers. I am > working with a Virtex 4 FX100 in a FF1152 package. I have 20 MGTs to > play with, arranged in 10 tiles numbered 101, 102, 103, 105, 106, 109, > 110, 112, 113 and 114. These are further arranged into columns. There > must be a simple method for determining which tiles are in which > columns, but I haven't worked it out. Perhaps a related problem is that > I have no idea where the odd numbering scheme comes from. Any help > would be greatly appreciated. > > TIA, > > -- PeterArticle: 106506
> Here are some performance numbers of this JOP/SRAM > interface on an embedded benchmark. It measures iterations/s > and therefore higher numbers are better. All versions are clocked > at 100 MHz, 4 KB instruction cache and 512 Byte stack cache. > FPGA is Cyclone EP1C6-6, Memory is 32-bit SRAM 15ns. The only > difference is the memory interface. > > SimpCon: 16,633 > Avalon (PTF version): 14,015 > Avalon (VHDL version): 13,920 > some additional numbers from the Altera DE2 board with Cyclone II at 100 MHz with SDRAM and using on-chip memory (the EP2C35 is big enough to run the benchmark in on-chip memory). Avalon SDRAM: 7,288 Avalon on-chip memory: 15,769 The performance issue with the SDRAM is clear. Just needs some more caching to get a big (8 MB) memory with acceptable performance ;-) However, even the fast on-chip memory Avalon solution is slightly slower than the two cycle SRAM connected via SimpCon. MartinArticle: 106507
ADEPT shows the MGT map in Excel. The tool is freely available at
http://home.comcast.net/~jimwu88/tools/adept/
Below is what you need to do:
* Select and load Device
* View->Display MGT
* Excel->Show MGT Map in Excel
HTH,
Jim
Peter Mendham wrote:
> Dear all,
>
> I am struggling to find the information I need from the Xilinx
> datasheet, perhaps someone could provide me with some pointers. I am
> working with a Virtex 4 FX100 in a FF1152 package. I have 20 MGTs to
> play with, arranged in 10 tiles numbered 101, 102, 103, 105, 106, 109,
> 110, 112, 113 and 114. These are further arranged into columns. There
> must be a simple method for determining which tiles are in which
> columns, but I haven't worked it out. Perhaps a related problem is that
> I have no idea where the odd numbering scheme comes from. Any help
> would be greatly appreciated.
>
> TIA,
>
> -- Peter
Article: 106508Hello, Will a USB keyboard work with the Spartan3 dev board? I know that USB keyboards will work with a PS2 connector on a desktop computer... all you need is a USB to PS2 adaptor plug.. anyway, one's on it's way and I'll find out then, I guess. Thanks! RichArticle: 106509
Hello all, In my quest to evaluate multicast performance on the ML403 board I have downloaded the mpmc2 example. I am attempting to build the ml403_ddr_idpoc_100mhz_gsrd on winXP and it bombs out with the following error: Running DRC Tcl procedures for OPTION IPLEVEL_DRC_PROC... ERROR:MDT - No Bus with instance name cdmac_to_gmac_0 found ERROR:MDT - No Bus with instance name gmac_to_cdmac_0 found Anyone else seen this? Any pointers as to how to fix it? thanksArticle: 106510
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> wrote in message news:44e0b13c$0$11352 > However, even the fast on-chip memory Avalon solution is > slightly slower than the two cycle SRAM connected via > SimpCon. > Well now THAT is incredibly surprising since the on-chip memory should be giving you 0 wait state, 0 latency performance (i.e. WaitRequest should always be low when accessing memory). That would seem to point to either some issue that comes up every now and then in your 'CPU to Avalon' bridge master interface logic or something equally odd inside the Avalon fabric itself connecting the CPU to the memory. I'd be interested to hear what you find. KJArticle: 106511
I've seen something similar to this, but I had somewhat modified the project before trying to build it, so I was kind of expecting errors... I don't remember precisely what was the problem, but I guess you should be able to figure it out by looking at the MHS file and possibly at MPMC2 MPD file... /Mikhail "Jeremy Price" <jpriceelvis.removeme.andme@gmail.com> wrote in message news:ee9dae7.-1@webx.sUN8CHnE... > Hello all, > > In my quest to evaluate multicast performance on the ML403 board I have downloaded the mpmc2 example. I am attempting to build the ml403_ddr_idpoc_100mhz_gsrd on winXP and it bombs out with the following error: Running DRC Tcl procedures for OPTION IPLEVEL_DRC_PROC... ERROR:MDT - No Bus with instance name cdmac_to_gmac_0 found ERROR:MDT - No Bus with instance name gmac_to_cdmac_0 found > > Anyone else seen this? Any pointers as to how to fix it? > > thanksArticle: 106512
Hi all, working on DDR2 controllers generated with MIG V1.6 I did notice the reduction in max speed for "Direct Clocking Mode" Up to now a speedgrade -11 LX60 Virtex-IV device did support up to 267MHz in Clock Synchronous mode. Using the MIG V1.6 that has some fixes this technique can only be used for ~210 MHz, a reduction of 20% in speed. I haven't found any information on the Xilinx Web-Site why this is so. I get the impression that from the beginning on up to now, Xilinx did reduce the max speed for their devices from time to time. The problem I face, is that we have boards that require at least 250 MHz in Direct Clocking Techniques Mode, and I really would like to understand, why Xilinx did this reduction in terms of max speed using a 512MBit DDR2 from Micron -37. Any Idea? Best Regards Markus BTW the post layout simulation on the DDR2 controllers with a build in Testbench is not working properly. On the Data Mask pins after calibration, these signals drive XX and the comparison fails. Seems to be in the Sim Library ...Article: 106513
I have been working with a group that reverse-engineered the PureDigital "one-time-use" cameras based on a chipset from SMaL Inc. The CPU core was licensed from Arc Internation, who bought the IP from vAutomation. It is presently called the Arclite, but was previously sold as the v8 uRISC. In the process of disassembling the firmware for the camera, the group modified the WLA assembler and linker, and wrote a new disassembler and simulator for the v8 uRISC architecture. With all these tools handy, I decided to rewrite the v8 uRISC core from scratch using documentation available on the web. As far as I know, there should be no legal issues with the core, but I can't guarantee that. I plan to release my core with a different name to avoid trademark issues, but I haven't selected a name as yet. The core is written in VHDL, and should be '93 compliant. I have pretty well debugged the ALU and microcode, but I haven't had a chance to test the interrupt system yet. Although the core does strive to be 100% compatible with the orginal v8 ISA, I have added some enhancements (which can be disabled via generics) such as the ability to allow RSP instruction to actively place the stack pointer, instead of merely resetting it, and the ability to do auto-increments on indexed load & store instructions. In addition, I replaced the unused USR and USR2 instructions with a DBNZ (Decrement, and Branch if Not Zero) and MUL (Multiply) instruction. Lastly, I made the interrupt mask immediately available to the core through to unmapped opcodes SMSK and GMSK, which transfer the contents of R0 to the mask, and vice-versa. This was the first CPU I've developed in VHDL, and may not be 100% optimal - so I could use some extra eyes to suggest performance enhancements or look for bugs. As it is, the core will run at > 112 MHz (by itself) on an Altera Cyclone II 2C35-C6. I have a small SoC design with UART, LCD interface, 7-segment display interface, 32kB RAM, 8kB ROM, and a 16-bit timer running on an Altera DE2 board at > 75 Mhz. The modules are connected in a wired-or configuration, where they only drive data when selected to eliminate muxing. I realize there are a plethora of 8-bit microprocessor cores floating around, but I would be curious to know if there is any interest in this CPU. I had planned to release it to Opencores.org under the GPL. I understand there was some interest in porting gcc to this processor, but it looks like it never happened - so at the moment, there is only the HiTech compiler, or raw assembly. However, the current open-source assembler is based on WLA, which has a lot of nice features. If there is any interest, I'll start trying to package the documentation, which presently exists in the form of notebooks and Excel spreadsheets.Article: 106514
Ben Popoola wrote: > What about small order quantities in the U.K? Mouser ships worldwide and has stated that their shipping time is very good to Europe and Asia. http://www.mouser.com/latticesemi/ If you do try Mouser for your shipment for the U.K., please let me know how your experience is, how long it took, etc. Thanks! Regards, Bart Borosky, Manager, Online Marketing Lattice SemiconductorArticle: 106515
I am posting this just as a suggestion for future FPGAs. It would be nice if a crystal can be connected to FPGA to provide clock instead of a oscillator. The cost difference between an oscillator and a crystal is significant. A 50MHz oscillator (2.5v) fro S3E costs $3.27. A 100MHz one is around $6. But all the crystals are less than $1. I have worked with PIC microcontrollers in past and they have the option of connecting both. I may be missing something here or may be this is already solved in some other way. I searched through Xilinx website but could not find anything. Please let me know if there is an existing solutiuon. Thanks SumitArticle: 106516
shrutisumit@gmail.com wrote: > I am posting this just as a suggestion for future FPGAs. It would be > nice if a crystal can be connected to FPGA to provide clock instead of > a oscillator. The cost difference between an oscillator and a crystal > is significant. A 50MHz oscillator (2.5v) fro S3E costs $3.27. A 100MHz > one is around $6. But all the crystals are less than $1. I have worked > with PIC microcontrollers in past and they have the option of > connecting both. > > I may be missing something here or may be this is already solved in > some other way. I searched through Xilinx website but could not find > anything. Please let me know if there is an existing solutiuon. > > Thanks > Sumit > If you're counting pennies like that, consider rolling your own crystal oscillator using one of the tiny logic inverters (M74VHC1GU04 or equivalent). The inverter will cost pennies, the crystal will still be a buck, you'll still need the handful of parts you'd need with the PIC, and you'll still need the months of engineering time and hassle with purchasing and manufacturing to get and keep things at a rock-solid reliable level under all conditions and manufacturing variations. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 106517
rickman wrote: > Jim Granville wrote: > >> What we need is a CPLD like the Freescale RS08, or the SiLabs >>C8051F41x - that works from 1.8V to 5.5V, and draws 1uA static Icc :) >> [ ATF1502BE draws 2.3uA, but needs two rails.... ] > > > The Coolrunner XPLA3 parts are pretty good. Other than not having > schmitt trigger inputs, what don't you like about them? I like their JTAG enable pin, so you don't have to loose valuable pins for JTAG - but they are narrow Vcc operation, and only promise < 100uA, and Xilinx do not have them on the on-line store, and are sparse elsewhere, so have that NFND look about them.... How long is your product lifetime ? >>Two Pin A : Bidirectional pins ( see 4046 ) Open Collector, Res Pullups, >>Swings from GND to VthP, Nominally 50% duty cycle. Gates very well >>Can VCO modulate. > > > I don't get this one at all. I looked up the 4046 but all descriptions > I could find treat the VCO as a black box. I am guessing that the two > pins are driven with opposite polarity and the cap is grounded at one > end or the other all the time. So it would be charged like the one pin > approach and then discharged like the one pin approach. So this is a > pair of the one pin drivers to give you 50/50 duty cycle? > > This seems simple. Any issues with startup? Does it need FFs anywhere > to make it work without noise? I would think that the lack of schmitt > trigger inputs would require a FF. Yes, normally it is simply a SR latch, with some logic to catch S=R=H. When running, S,R cross their thresholds only briefly, to trigger the other phase. -jgArticle: 106518
shrutisumit@gmail.com wrote: > I am posting this just as a suggestion for future FPGAs. It would be > nice if a crystal can be connected to FPGA to provide clock instead of > a oscillator. The cost difference between an oscillator and a crystal > is significant. A 50MHz oscillator (2.5v) fro S3E costs $3.27. A 100MHz > one is around $6. But all the crystals are less than $1. I have worked > with PIC microcontrollers in past and they have the option of > connecting both. > > I may be missing something here or may be this is already solved in > some other way. I searched through Xilinx website but could not find > anything. Please let me know if there is an existing solutiuon. XTAL osc were there, but removed many generations ago. These days, you can get cheap SOT23 Osc from Linear/maxim, that can clock FPGAs in many applications. -jgArticle: 106519
Been there, done that. XC3000 had (has) two pins that wrap around a single-stage buffer, and are meant to be connected to a xtal. Add a biaing resistor plus the obligatory caps to form a Colpitts oscillator. It was a support nightmare. Even if 99% of applications had no problem, the remaining 1% drove us crazy. Too little gain, too much gain, too low a frequency (32 kHz), too high a frequency (>100 MHz), doesn't start at cold, bad pc-board layout, etc Canned oscillators are made by experts, using exactly the best chip for the particular frequency, and use the smallest amount of power. And they are surprisingly cheap, far less than the $6 quoted in the posting here. You can even get a 312.5 MHz oscillator for a few dollars...(Sits in every cellphone) Never again will we put that driver into an FPGA ! Peter Alfke, Xilinx PS: when I was at AMD, we second-sourced the 8051. Most of Intel's mask revisions were caused by their oscillator circuit... ===================================Article: 106520
On 14 Aug 2006 10:50:39 -0700, aiiadict@gmail.com wrote: >Hello, > >Will a USB keyboard work with the Spartan3 dev board? > >I know that USB keyboards will work with a PS2 connector >on a desktop computer... all you need is a USB to PS2 >adaptor plug.. These are not strictly USB keyboards. They are dual mode USB/PS2 keyboards that decide which language to talk by detecting what they are plugged into. Assuming it is one of these, and the S3 hardware looks sufficiently like a real PS2 port, then it ought to work, no different from a real PS2 keyboard.Article: 106521
Tim Wescott wrote: > shrutisumit@gmail.com wrote: > >> I am posting this just as a suggestion for future FPGAs. It would be >> nice if a crystal can be connected to FPGA to provide clock instead of >> a oscillator. The cost difference between an oscillator and a crystal >> is significant. A 50MHz oscillator (2.5v) fro S3E costs $3.27. A 100MHz >> one is around $6. But all the crystals are less than $1. I have worked >> with PIC microcontrollers in past and they have the option of >> connecting both. >> >> I may be missing something here or may be this is already solved in >> some other way. I searched through Xilinx website but could not find >> anything. Please let me know if there is an existing solutiuon. >> >> Thanks >> Sumit >> > If you're counting pennies like that, consider rolling your own crystal > oscillator using one of the tiny logic inverters (M74VHC1GU04 or > equivalent). The inverter will cost pennies, the crystal will still be > a buck, you'll still need the handful of parts you'd need with the PIC, > and you'll still need the months of engineering time and hassle with > purchasing and manufacturing to get and keep things at a rock-solid > reliable level under all conditions and manufacturing variations. Good idea, but the FPGA will NOT like the sine drive - there are 1G variants, that ARE designed for Crystal Osc, [1GU04+1G14 in one package] Philips have a couple, TI have one, eg 74AUP1Z04 -jgArticle: 106522
All, Nothing like failure to cause one to abandon a feature forever. A crystal oscillator that: always starts, is always the right frequency, and is cheap -- is best left to those who have solved it for a few dozen useful frequencies (and even they have their share of headaches). It would be (and is) a horrible business risk to attempt to supply a circuit that would always work for every possible crystal from near DC to daylight. Can anyone guess how many different parameters there are to specify for a crystal? It is not just the frequency.... AustinArticle: 106523
In article <1154993195.996004.266830@m73g2000cwd.googlegroups.com>, fpgakid@gmail.com <fpgakid@gmail.com> wrote: >I've written a Xilinx JTAG programmer. It runs on Win32 and Linux > >Following cables are supported: > >Parallel III >Digilent USB (on Linux it needs libusb, Win32 needs the original driver >from digilent, utilizes full USB transfer speed!) > >Following chips are implemented: >Spartan-3 Family >XCF Family >Virtex-II Pro family > >If it seems people are interested I'll clean up the code and put it up >on sourceforge.net. >The most interesting part is the Digilent USB driver. It could be used >in other applications too :) > I'd be interested. Is the code available? I've been having some problems with xc3sprog - specifically getting it to program a Spartan 3 1500 - so I'd like to give your program a try. PhilArticle: 106524
Austin Lesea wrote: > All, > > Nothing like failure to cause one to abandon a feature forever. > > A crystal oscillator that: always starts, is always the right frequency, > and is cheap -- is best left to those who have solved it for a few dozen > useful frequencies (and even they have their share of headaches). > > It would be (and is) a horrible business risk to attempt to supply a > circuit that would always work for every possible crystal from near DC > to daylight. > > Can anyone guess how many different parameters there are to specify for > a crystal? It is not just the frequency.... The companies that do this properly, typically have 4 gm's or transfer gains selectable by fuses, that cover 1-2 decades of frequency/option. Most vanilla Osc circuits struggle with overtone crystals (above appx 25-40MHz), and for FPGAs that is on the 'low' side of useful. So above this, and you are pretty much into Osc-Modules (or the cheaper SOT23's if you can tolerate their precision ) Silicon MEMS 'crystals' have been talked about, but still seem niche devices. - and no, these will not appear inside your FPGAs :) -jg
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