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
"glen herrmannsfeldt": > Jan Bruns <testzugang_janbruns@arcor.de> wrote: >> Will that Spartan6 have internal tristatable interconnects, > As far as I know, that will never happen again. It is part > of the scaling laws for MOS circuits that as the circuitry > gets smaller the RC time constant of wires increases. > R increases faster than C decreases, resulting in slower > circuits. The fix is to add buffers on longer lines, > but those are directional. That's probably not 100% fpga related, but why would R and C change with smaller devices? Shouldn't R be constant for wires (halfed length and width), and C shrink with either the wire's surface or at most be constant shorter distance to other lines, but shorter)? BTW.: I mean a way to get wired a AND/OR, using some driver enable (to avoid MUXing many lines). >> and/or better capabilites to build large MUXes? > This should be possible. As far as I know, AND/OR logic, > where the signal and its enable drive an AND gate, then > all the AND outputs drive an OR gate to generate the > result. That can be distributed back to where it is needed. Sure, but there are only two options for an input to a mux: register or combinatorial. If it is combinatorial, there might be a chance to absorb the AND with enable. If it's a register, we have a "wasted" LUT per MUX-input. The large OR at the end also adds levels of logic. >> In Spartan3, a usual way to make a 32:1 MUX requires 16 LUT4 >> (8 Slices, 2 CLBs) + F5MUX + 3 levels of FXMUXes and because >> both CLBs won't absorb much of any logic following the mux32, >> the result has to be routed far away. > > Can you replace that with AND/OR logic? That could probably mean 32 LUT4s for (en & src & a0 & a1) 11 LUT4s to OR the 32 signals 8 LUT4s for a a2..a4 3->8 decoder ======== 61 LUT4s (much more then the 16 LUTs using a standard spartan3 MUX32) >> It seems obvious to me that giving the spartan3 CLB additional full mux32 >> logic wasn't a theoretical problem nor would it blow up required routing >> resources (since a CLB already has enough external interconnects), and >> the remaining logic would still be theoretically usable without any >> external routing blow up (maybe non-registered adders or registered >> counters; not sure if these would mean exactly no blowup, but nearly). Or what about a minimal hardwired (yet impossible) modification to the F5MUX: module new_f5mux(f,g,f4,g4,f3,g3,bx,ce, o); parameter static_fsel = 1'b0; parameter static_gsel = 1'b0; input g,g,f3,f4,g3,g4,bx,ce; output o; wire mf = (ce) ? f3 : f4; // hardwired, but wire mg = (ce) ? g3 : g4; // dynamic wire fq = (static_fsel) ? f : mf; // config-time wire gq = (static_gsel) ? g : mg; // static assign o = (bx) ? fq : gq; endmodule This would still allow a MUX16 per CLB or MUX32 per 2 CLBs, but would free many other resources in the CLBs (carrychains, LUT2, FlipFlops driven local, without ce, but still with reset option). How does this compare to "dualport-ram option" the SLICEMs have. Gruss Jan BrunsArticle: 138001
On Feb 3, 1:53=A0pm, "kristian" <kri...@gmx.de> wrote: > >> Kris, > > >> No idea about the details of the Xilinx core, but if you have real > >> valued input data and complex output data, you can expect that the > >> output (if you reverse the output samples, with the DC value at the > >> middle) is the negative complex conjugate (see Wikipedia or a standard > >> textbook). That means you could just swap the real and imaginary > >> output, assuming it's a real bug that you want to hack up a fix for. > > >Mental misfire... negative complex conjugate is just inverting the > >real part; no swap required. Aargh...simple conjugate... have to remember to do the math before I open my mouth. > > >> Alternatively, the behaviour you describe for a simple sinusoid could > >> be correct, since you didn't specify the start phase. A sinusoid > >> that's off by 180 degrees (pi radians) will have its value (dirac fft > >> coeffs) multiplied by exp(i*pi) =3D3D -1. > > >> =3DA0- Kenn > > Hi Kenn, > > to verify the results of the fft core I used a java applet > (http://sepwww.stanford.edu/oldsep/hale/FftLab.html). When I put at the > input of the core a sinus for the real part and a cosinus for the imagina= ry > part then the java applet show only a positiv dirac puls at x(k) at the > imaginary frequency domain. This result I also expect at the fft core > output. But I get at x(N-k) a positiv dirac puls. > > Regards, > Kris Interesting. If you consider a sine input at pi/2, the input data looks like [0,+1,0,-1,...] For a 16-point FFT, the exponential term exp(-j2pi*nk/N) in the fft series for X[4] looks like [1, -i, -1, +i, ...] So the sum of products should be negative imaginary at X[4]. I can see this expected value out of Matlab's fft as well, and it matches your measured output. But when I type this data into your java simulator, it doesn't give me what I expect. So, assuming your input data is the same, perhaps your testbench rather than your implementation has the bug :-) - KennArticle: 138002
On Feb 4, 4:12=A0am, jhal...@TheWorld.com (Joseph H Allen) wrote: > I'm surprised that the Spartan-6 integrated memory controller does not su= pport > DIMMs. =A0Also surprised that there are no integrated memory controllers = in > Virtex-6. > > Note the Virtex-6 Select-IO voltage range: only up to 2.5V! =A02.5V is th= e > new 5V... The Spartan 6 Guide says Standards up to 3.3V ? Where is the 2.5V limit given ? -jgArticle: 138003
> "One Spartan-6 FPGA, an LX16 device, is already sampling..." > "The Spartan-6 family is priced at between about $3 and $54 in high > volume of 10,000 units..." 10,000 is not really 'high volumes' ? Xilinx used to quote "Over the Horizon" prices, eg for parts 250,000 pcs, delivered at the end of 2010. Maybe sense finally prevails....? -jgArticle: 138004
On Feb 4, 5:56=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > Anyone know anything about > > =A0www.tabula.com > > ??? =A0They are operating very firmly in "stealth" mode > right now, but they have money, lots of patents and > some high-profile people. > > A very quick scan of their patents suggests that they > may be doing something with very fast - truly dynamic - > reconfiguration of FPGA logic; one of the abstracts > tantalisingly talks about reconfiguration faster > than the system clock. =A0Lack of time, and frustration > with the way the USPTO website fools around with > QuickTime when you try to view images, has stopped > me from going any further. > > Their "early adopter" pages don't seem to be up just yet. > > Maybe, just maybe, this and Achronix represent a real > change in the FPGA game. =A0Interesting. > -- > Jonathan Bromley, Consultant Too early to extract much from their website, but History is against them. The further they move from standard FPGAs, the less existing Software work they can leverage, and cracking BOTH the Silicon and Software is the double hurdle FPGA startups face. Also, not a great time to be pitching new devices... -jgArticle: 138005
On Feb 4, 3:47=A0am, "freesp...@gmail.com" <freesp...@gmail.com> wrote: > > Even thought I emailed digilent about it pre-Christmas, I haven't had > an email from the with a link to the new software, which I will try > tomorrow morning. Hope it fixes my woes. > > Cheers, > Steve Hrm, it would appear I already had the latest version of adept and export, and using the 2.0 version from the coolrunner package as Red suggested didn't work either. I still can't initalise the scan chain due to too many invalid devices showing up (see my link in the previous post for a detailed account of my problems). At this point I am all out of idea, but would like to ask those if you who have working Nexys2 boards to kindly post: * your OS version * whether you are shorting any pins on the JTAG port * setting of the MODE jumper (jp9) Cheers, SteveArticle: 138006
On Dec 8 2008, 7:44=A0pm, "freesp...@gmail.com" <freesp...@gmail.com> wrote: > I will ask the Digilent people. I have to use their ExPort program to > communicate with my Nexys2 since it uses some usb-jtag magic. I might > just by the Xilinx cable though if this continues to be a problem. > > Thank you for your advice. Have asked digilent people, so far no progress and no advice besides what has been said here and elsewhere on the net. The last I heard from them their lead engineer is looking into it, and the board might be broken leading to a broken chain. I If the latter is the case, then their QC and self test is not doing its job. Cheers, SteveArticle: 138007
Simon <google@gornall.net> writes: > well, this is all very nice, but more importantly, when are they going > to actually start delivering these things, and how much will they > cost ? > > I can't really believe they haven't *got* that information, so why the > staged release of info ? When was the last time that a semiconductor vendor gave you such information about a major new product release, and the information actually proved to be reasonably accurate?Article: 138008
-jg <Jim.Granville@gmail.com> writes: > The Spartan 6 Guide says Standards up to 3.3V ? > Where is the 2.5V limit given ? In the Virtex 6 guide.Article: 138009
On Feb 3, 9:42=A0pm, -jg <Jim.Granvi...@gmail.com> wrote: > > "One Spartan-6 FPGA, an LX16 device, is already sampling..." > > "The Spartan-6 family is priced at between about $3 and $54 in high > > volume of 10,000 units..." > > 10,000 is not really 'high volumes' ? > > Xilinx used to quote =A0"Over the Horizon" prices, > eg for parts 250,000 pcs, delivered at the end of 2010. > > Maybe sense finally prevails....? I agree that their previous pricing was pretty absurd. I wonder if *any* customers ever got those numbers. Still, I think 10,000 is not very realistic for many of us, but then anyone buying less than 10,000 is likely not even on the Xilinx radar screen. Personally, I like the way TI does it listing the 1000 piece price and giving direct links to the disti's web pages showing real prices. I will very surprised if they can really sell any of the Spartan 6 parts for $3. The smallest part they sell has 100 I/Os and who knows how much logic. I think it is about 2K LUTs and 4K FFs. From what I have been told most of the cost of a small part is from the testing and that is dominated by the I/O count. The cheapest part is likely going to be around $10 at qty 1000 IMHO. RickArticle: 138010
Eric Smith wrote: > When was the last time that a semiconductor vendor gave you such > information about a major new product release, and the information > actually proved to be reasonably accurate? Under NDA for bigger customers the vendors give very accurate information way before the launch and quite accurate estimates on sample deliveries etc. Of course there are possible slips but they estimate then new schedules. Many people do designs for those chips way before the public release, and have own product launch schedules also. --KimArticle: 138011
Hi, I would like to use a Spartan 3 100K FPGA to implement 16 serial ports. The ports will be fairly simple: 1200 to 115200 baud, Tx, Rx, and two flow control lines per port. I already have a working serial port and could make sixteen instances of it. This would chew up a lot of the FPGA. Is there a better way to build sixteen serial ports? Would it make sense to build one serial port and try to time division multiplex it to the sixteen sets of inputs, perhaps keeping all state information in RAM? Is this a feasible or reasonable approach? thanks in advance Bob SmithArticle: 138012
Hi, In trying to conform to good design practices, I have been doubting lately my old ways. Until now, I've interfaced most of my cores to the external system using standard 2/4-phase asynchronous handshake protocols. Was wondering how good of a practice is this and whether there is a definitive handbook out there in the literature that tackles these issues. Don't want to sink into SoC bussing literature with overly complicated arbitration since most of the designs I work on are of the simple and tightly-coupled sort. Would appreciate any pointers on this. Regards, MannyArticle: 138013
Jan Bruns wrote: > That's probably not 100% fpga related, but why would R and C > change with smaller devices? Shouldn't R be constant for wires > (halfed length and width), and C shrink with either the > wire's surface or at most be constant shorter distance to > other lines, but shorter)? The problem is that with smaller nodes the geometry of the wires is changed. They have become very narrow but tall compared to the old more rectangular ones. Also the length might not be halved, because the chip has more logic. The die sizes have been quite constant all the time (io-pads create the first limit how small the die can become). Also the propagation delay in the metal wire is proportional to the square of the wire length, with repeaters that can be changed to linear dependency. That is one big reason to remove tristate busses inside the chips, they would not work very fast. --KimArticle: 138014
Joseph H Allen wrote: > No, 3.3V was the old new 5V. The new new 5V is 2.5V. Altera Straitx-IV > also does not support 3.3V I/O. Also in some of the new chips that still support the 3.3v volt the drive strength might be very low, even so low that is is almost unusable. --KimArticle: 138015
I have the following problem. The input clock to the FPGA, Virtex4-vlx100 (-11) is 80MHz. For the design, I'll need to generate a 160Mhz and 320Mhz clock. The 160Mhz clock is not a problem. However, using the single DCM, I'm not able to generate this 320Mhz clock. As CLKFX output only goes up to 315MHz, according to COREGEN. SO single DCM is out of the question and decided on trying cascade DCM. From the COREGEN, there is a function "Cascading in Series with 2 DCM_ADVs" for Virtex-4. So I think it's better to use that. a. I've configured ... "Select clock for cascading" to be CLK2X. b. Then I select the "Input frequency" of the 1st DCM to be 80MHz but COREGEN pop-up an error message "Only low frequency mode is valid for Cascading in series Please enter an Input Clock Frequency value within the valid Low Frequency rang. DLL Low frequency mode 32.000Mhz - 75.000 MHz." This 75MHz doesn't seem to agree with what is written in the datasheet (eg. 150MHz) So, my questions are 1. Are there any better way to achieve 320MHz without cascading DCM? 2. Is the 75MHz limit defined on purpose to prevent excessive jitter? 3. Should I just instantiate and cascade the DCMs, to avoid the COREGEN limitation? thanks for any help. edArticle: 138016
> Using libusb. > Connecting to cable (Usb Port - USB21). > Checking cable driver. > File version of /tools/Xilinx_10.1_x86_64/ISE/bin/lin64/xusbdfwu.hex = > 1030. > File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 1030. > Using libusb. > Max current requested during enumeration is 74 mA. > Type = 0x0004. > Cable Type = 3, Revision = 0. > Setting cable speed to 6 MHz. > Cable connection established. > Firmware version = 1303. > File version of /tools/Xilinx_10.1_x86_64/ISE/data/xusb_xlp.hex = > 1303. > Firmware hex file version = 1303. > PLD file version = 0012h. > PLD version = 0012h. This is my log with ise10.1 sp3 and libusb, maybe it helps to update the firmware files being loaded? do you use the udev-rules suggested by xilinx? ($XILINX/bin/lin64/xusbdfwu.rules) Using libusb. Connecting to cable (Usb Port - USB21). Checking cable driver. File version of /opt/Xilinx/10.1/ISE/bin/lin64/xusbdfwu.hex = 1100. File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 1100. Using libusb. Max current requested during enumeration is 74 mA. Type = 0x0004. Cable Type = 3, Revision = 0. Setting cable speed to 6 MHz. Cable connection established. Firmware version = 1303. File version of /opt/Xilinx/10.1/ISE/data/xusb_xlp.hex = 1303. Firmware hex file version = 1303. PLD file version = 0012h. PLD version = 0012h.Article: 138017
On Feb 3, 5:56=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > Anyone know anything about > > =A0www.tabula.com > > ??? =A0They are operating very firmly in "stealth" mode > right now, but they have money, lots of patents and > some high-profile people. Sounds like 90% of all startups homepage text if you ask me. > > A very quick scan of their patents suggests that they > may be doing something with very fast - truly dynamic - > reconfiguration of FPGA logic; one of the abstracts > tantalisingly talks about reconfiguration faster > than the system clock. =A0Lack of time, and frustration > with the way the USPTO website fools around with > QuickTime when you try to view images, has stopped > me from going any further. went over to www.google.com/patents and searched for tabula.inc and got a few hits. At least on my setup with firefox it was no problem to view the patents and even download them as pdf if I wanted. I did also not have good luck at uspto with their tiff offer. I don't know if all patents on uspto are available at google, but that's probably a minor detail. > > Their "early adopter" pages don't seem to be up just yet. As long as they are in "stealth mode" they probably don't have any real devices or customers, just hot air and press releases. They are polishing the bride. > > Maybe, just maybe, this and Achronix represent a real > change in the FPGA game. =A0Interesting. Anything new may lead to a change if they are bought by the right company. This is more or less outsourced business development for companies too big to get it done themselves. Startups are highly dynamic (hire and fire) organisations that suits well to ride the storm of bringing an idea to something worth putting into mass- production, as long as the venture capital doesn't dry out half-way there. -- SvennArticle: 138018
On Wed, 4 Feb 2009 01:10:22 -0800 (PST), Svenn Are Bjerkem wrote: >Anything new may lead to a change if they are bought by the right >company. This is more or less outsourced business development for >companies too big to get it done themselves. Startups are highly >dynamic (hire and fire) organisations that suits well to ride the >storm of bringing an idea to something worth putting into mass- >production, as long as the venture capital doesn't dry out half-way >there. Nice to know I'm not the only curmudgeonly cynic out there :-) You're probably right. Pessimists are rarely disappointed. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 138019
Jan Bruns <testzugang_janbruns@arcor.de> wrote: > "glen herrmannsfeldt": >> Jan Bruns <testzugang_janbruns@arcor.de> wrote: >>> Will that Spartan6 have internal tristatable interconnects, >> As far as I know, that will never happen again. It is part >> of the scaling laws for MOS circuits that as the circuitry >> gets smaller the RC time constant of wires increases. >> R increases faster than C decreases, resulting in slower >> circuits. The fix is to add buffers on longer lines, >> but those are directional. > That's probably not 100% fpga related, but why would R and C > change with smaller devices? Shouldn't R be constant for wires > (halfed length and width), and C shrink with either the > wire's surface or at most be constant shorter distance to > other lines, but shorter)? Wires shrink in width and height, both of which change the resistance, C depends (mostly) just on width. Shrink by a factor of 2, R increases by a factor of (about) 4, C decreases by a factor of 2. If you actually shrink the die then the length would also decrease, but it is more usual to keep the die size and put more CLBs on. > BTW.: I mean a way to get wired a AND/OR, using some > driver enable (to avoid MUXing many lines). >>> and/or better capabilites to build large MUXes? >> This should be possible. As far as I know, AND/OR logic, (snip) > Sure, but there are only two options for an input to a mux: > register or combinatorial. If it is combinatorial, there might > be a chance to absorb the AND with enable. If it's a register, > we have a "wasted" LUT per MUX-input. > The large OR at the end also adds levels of logic. When you did have tristate devices on the chip interior they were in special places, complicating routing. >>> In Spartan3, a usual way to make a 32:1 MUX requires 16 LUT4 >>> (8 Slices, 2 CLBs) + F5MUX + 3 levels of FXMUXes and because >>> both CLBs won't absorb much of any logic following the mux32, >>> the result has to be routed far away. >> Can you replace that with AND/OR logic? > That could probably mean > 32 LUT4s for (en & src & a0 & a1) > 11 LUT4s to OR the 32 signals > 8 LUT4s for a a2..a4 3->8 decoder > ======== > 61 LUT4s (much more then the 16 LUTs using a standard spartan3 MUX32) Plus the priority encoder to use for the MUX inputs? As I understand it, some tools will convert a wide (bus) MUX into a decode and AND/OR logic. For a single MUX that doesn't seem to help. -- glenArticle: 138020
Bob Smith <usenet@linuxtoys.org> wrote: > I would like to use a Spartan 3 100K FPGA to implement 16 > serial ports. The ports will be fairly simple: 1200 to > 115200 baud, Tx, Rx, and two flow control lines per port. > I already have a working serial port and could make sixteen > instances of it. This would chew up a lot of the FPGA. > Is there a better way to build sixteen serial ports? > Would it make sense to build one serial port and try to > time division multiplex it to the sixteen sets of inputs, > perhaps keeping all state information in RAM? Is this a > feasible or reasonable approach? So only one data bus for all 16? My first thought is, assuming you have FIFOs on them, would be to multiplex the FIFOs (write the port and data into the FIFO) for the receiver, and then when you read it read the data and port. For the transmitter, that probably doesn't work, but you could use one RAM and 32 pointer registers. (top and bottom for each UART.) Can you use the SRL16 for the shift registers? Otherwise, a UART shouldn't be all that big. -- glenArticle: 138021
On Feb 4, 7:32=A0pm, Bob Smith <use...@linuxtoys.org> wrote: > Hi, > > I would like to use a Spartan 3 100K FPGA to implement 16 > serial ports. =A0The ports will be fairly simple: 1200 to > 115200 baud, Tx, Rx, and two flow control lines per port. > > I already have a working serial port and could make sixteen > instances of it. =A0This would chew up a lot of the FPGA. > > Is there a better way to build sixteen serial ports? > > Would it make sense to build one serial port and try to > time division multiplex it to the sixteen sets of inputs, > perhaps keeping all state information in RAM? =A0Is this a > feasible or reasonable approach? What did your calculator say ? 115200 baud is 8.68us, at x8 or 16 sampling, that's ~2MHz. Split that 16 ways and you have ~32MHz - does not sound high..... 15-16 byte fifos would likely fit into a ~byte sized state variable.Article: 138022
On Feb 4, 6:59=A0pm, rickman <gnu...@gmail.com> wrote: > I will very surprised if they can really sell any of the Spartan 6 > parts for $3. =A0The smallest part they sell has 100 I/Os and who knows > how much logic. =A0I think it is about 2K LUTs and 4K FFs. =A0From what I > have been told most of the cost of a small part is from the testing > and that is dominated by the I/O count. =A0The cheapest part is likely > going to be around $10 at qty 1000 IMHO. Sounds about right. Smallest part says 3366 Logic cells, 9101 for larger sibling, and largest in TQFG144. I would paste in the table but Xilinx has disabled COPY in the PDF, and I would give a link to a google find that would allow you to View as HTML, but google cannot find the named pdf, even when pointed to Xilinx.com. Seems Xilinx really is doing everything to prevent anyone sharing this information!! [I wonder if they even realize this....] -jgArticle: 138023
On Feb 4, 5:58=A0pm, Eric Smith <e...@brouhaha.com> wrote: > -jg <Jim.Granvi...@gmail.com> writes: > > The Spartan 6 Guide says Standards up to 3.3V ? > > Where is the 2.5V limit given ? > > In the Virtex 6 guide. So it seems they made a deliberate process decision, for Virtex 6 to be 2.5V, and Spartan 6 to be 3.3V ? That's a large market to isolate your devices from - one hopes the few picoseconds of speed that might have gained, turn out to be wrth it!! :) -jg .Article: 138024
-jg wrote: > So it seems they made a deliberate process decision, for Virtex 6 to > be > 2.5V, and Spartan 6 to be 3.3V ? One decision maker might be, that usually new expensive designs are not interfacing very old chips. But on the other hand cheap chips can be used to cost reduce old designs or replace old ASICs. > That's a large market to isolate your devices from - one hopes the > few picoseconds of speed that might have gained, turn out to be wrth > it!! :) It more a question of die space. 3.3v tolerant IO is huge in 40/45nm. In V6 they are trying to reach the high end of IO and LUT counts. On the other hand with S6 the LUT counts are not that high and also the IO count is lower than in V6 so they can waste space for the IO. --Kim
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