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
On Mar 26, 4:54=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > On Mar 26, 3:26=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > > > > >> Second problem, how do you avoid having more than one level > > >> transaction in the oscillation ring? > > >> (e.g. 01010). > > > That would speed up the count. =A0If you can route to an output > > pin without changing the oscillator too much, then look at it > > on a scope. > > There's a strong possibility the I/O won't have the bandwidth to pass > the full signal. =A0A short back and forth for a small pulse might get > lost in the I/O. Normally a ring with a single enable input wouldn't behave that way. The ring consists of one NAND (or NOR) gate and the rest of the elements are just inverters. When the ring is disabled all elements find a static state and the gate element injects just one edge into the ring, assuming the enable signal is not glitchy itself.Article: 146726
This isn't strictly a FPGA question, but I figured someone here might be able to point me in the right direction. I am designing a board with an Altera EP3C40 in the 240-pin QFP and a Cypress CY7C1792 static SRAM in the 100 pin QFP. I would like to operate the SRAM at 200MHz, so I know the routing needs to be somewhat careful. (I'm internally "dual-porting" the SRAM, and each port needs to run at 100MHz) Right now, I have the SRAM on the flip-side of the board from the FPGA. The RAM has a rectangular footprint, which means that some of the traces are proportionally longer than others, but the routing is fairly tight, with traces between 250 and 750mils. Naturally, every signal is going through a via in this design, but the vias are literally right next to the pad, so the top-level trace is practically non-existent for most signals. The questions are, 1) Do I need to further tighten these up? I have some room left under the SRAM to lengthen traces (not much, but I might could improve the delta by 10-20%), 2) Should I try to make the clock line equal the longest non-clock signal, or leave it at its natural length, which is about midway (400mil point-to-point)? 3) With the traces this short, does it still make sense to source terminate the clock? I'm guessing yes, but the density is getting pretty high around this thing. I've only done one other "high speed" design, with a Gig-E PHY, but I was able to get all of the signals to within +/- 5 mils on that board. It's also not entirely tested yet, so before I spin another board running even faster, I'd like to get it right. Note, this is a personal project, so I'm trying to avoid BGA's. Thanks!Article: 146727
In comp.arch.fpga Thomas Entner <thomas.entner@entner-electronics.com> wrote: (snip) > I do not know the book, but it is hard for me to not disagree with the > statement, that a digital logic designer is not responsible for the > speed of the circuit. Especially when you are talking about domino > logic, etc. in your other posts, when I remember right ;-) I disagree. In many FPGA projects, speed is the reason for doing the project. Many things can be done on existing processors, but not quite fast enough. The primary goal, then, is to design the logic to be fast. In the case of pipelined arrays, one might need to maximize speed/cost, which is, again, a logic design problem. There are also many problems where speed isn't so important. -- glenArticle: 146728
Jonathan Bromley <jonathan.bromley@mycompany.com> wrote: (snip, I wrote) >>Some drivers can pull up almost as much as down. > True, for sure. But in the olden days (and remember, I'm an > olden-days person) ground, but never power, was used as a > reference for inputs. Is that still true? My gut tells me > that CMOS inputs need both power and ground to be well- > behaved if they are to act sensibly. Does anyone know > different? TTL is pretty much ground referenced, where the switch point is related to forward bias on PN junctions. The first CMOS had the switch point at (Vss+Vdd)/2, symmetric as you would expect. Later, to be compatible with TTL, CMOS circuits were changed such that the range matched the TTL (0.8V and 2.0V) points. It seems that might make it more sensitive to ground bounce than Vdd bounce, but it isn't so obvious to me. -- glenArticle: 146729
On Mar 27, 9:09=A0am, Gabor <ga...@alacron.com> wrote: > > Normally a ring with a single enable input wouldn't behave that > way. =A0The ring consists of one NAND (or NOR) gate and the > rest of the elements are just inverters. =A0When the ring is > disabled all elements find a static state and the gate > element injects just one edge into the ring, assuming the > enable signal is not glitchy itself. Correct, you should use an Enable to ensure correct 'start' of a Ring oscillator. Even tho you might think a Tphl/tplh shift should remove narrower pulses, that's only true if the path is monotonic, and local LCR effects mean there can be 'stable' regions. You can also code a Ring oscillator, as alternating inverters, and nand/nor elements, and that can sometime help persuade to tools to not optimize things away... The best way to test Osc stability is to probe a Divided pin, NOT the raw Osc, as in most cases, it will not make it out in any useful way. A divided pin easily shows errant effects, and a scope is important. A ring oscillator will locally heat, so for best stability use a Power- Up Enable and gate the divider, not the oscillator itself. -jgArticle: 146730
On Mar 27, 9:13=A0am, radarman <jsham...@gmail.com> wrote: > This isn't strictly a FPGA question, but I figured someone here might > be able to point me in the right direction. > > I am designing a board with an Altera EP3C40 in the 240-pin QFP and a > Cypress CY7C1792 static SRAM in the 100 pin QFP. I would like to > operate the SRAM at 200MHz, so I know the routing needs to be somewhat > careful. (I'm internally "dual-porting" the SRAM, and each port needs > to run at 100MHz) > > Right now, I have the SRAM on the flip-side of the board from the > FPGA. The RAM has a rectangular footprint, which means that some of > the traces are proportionally longer than others, but the routing is > fairly tight, with traces between 250 and 750mils. Naturally, every > signal is going through a via in this design, but the vias are > literally right next to the pad, so the top-level trace is practically > non-existent for most signals. > > The questions are, > 1) Do I need to further tighten these up? I have some room left under > the SRAM to lengthen traces (not much, but I might could improve the > delta by 10-20%), > 2) Should I try to make the clock line equal the longest non-clock > signal, or leave it at its natural length, which is about midway > (400mil point-to-point)? > 3) With the traces this short, does it still make sense to source > terminate the clock? I'm guessing yes, but the density is getting > pretty high around this thing. > > I've only done one other "high speed" design, with a Gig-E PHY, but I > was able to get all of the signals to within +/- 5 mils on that board. > It's also not entirely tested yet, so before I spin another board > running even faster, I'd like to get it right. > > Note, this is a personal project, so I'm trying to avoid BGA's. > > Thanks! You can reality check this with a Trace-delay ballpark of "150 ps/ inch and 190 ps/inch". The clock signal is always the most important, and I have seen designs generate a CLK, & !CLK to lower EMC. Everything else should change of the other edge, so balancing only gets critical on very tight time budgets.Article: 146731
Hi, I am using the XC6SLX9 FPGA in my new design. I would like to know what version of XILINX ISE is required for Spartan-6 series? Can Webpack work with Spartan 6? Thank you, Aditi.Article: 146732
On Mar 26, 4:26=A0pm, Aditi <aditi...@gmail.com> wrote: > Hi, > > I am using the XC6SLX9 FPGA in my new design. > I would like to know what version of XILINX ISE is required for > Spartan-6 series? =A0Can Webpack work with > Spartan 6? > > Thank you, > Aditi. The ISE 11.5 Webpack version supports most of the Spartan-6 devices including the XC6SLX9. Ed McGettigan -- Xilinx Inc.Article: 146733
On Mar 26, 4:14=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > I disagree. =A0In many FPGA projects, speed is the reason for doing > the project. =A0Many things can be done on existing processors, but > not quite fast enough. =A0The primary goal, then, is to design > the logic to be fast. =A0In the case of pipelined arrays, one > might need to maximize speed/cost, which is, again, a logic > design problem. =A0 > > There are also many problems where speed isn't so important. Well, to be fair, the discussion about speed was about CMOS design, and transistor-level CMOS is a different skill than digital design (although it often resides in the same individual). But to your point about FPGAs, I agree that an "FPGA designer" often needs to be acutely aware of how to make things go fast in an FPGA (which is often more a matter of being willing to experiment, and certainly doesn't require the same low-level hardware understanding as dealing with domino logic does). Where I work, we build real chips, but emulate them in FPGAs. Gates are so cheap these days, and the real silicon is so fast, that my mantra to the digital designers is always to make it work well and fast in the FPGA, and the chip will take care of itself. If you code in a fashion that is designed to be highly optimized for real silicon, sure you might save a milli-cent per chip, but if you weren't able to emulate it at speed (or even if you were able to emulate it at speed, but only through heroic work by the FPGA emulator guy and multiple 30 hour PAR sessions), that could cost you a lot more than your putative savings. Regards, PatArticle: 146734
On Mar 26, 5:13=A0pm, radarman <jsham...@gmail.com> wrote: > > The questions are, > 1) Do I need to further tighten these up? I have some room left under > the SRAM to lengthen traces (not much, but I might could improve the > delta by 10-20%), 6 inches is approximately 1 ns of delay =3D> your 250 - 750 mils is approximately 40 - 120 ps =3D 0.41% - 1.2% of the timing budget for one way, double that for the round trip...worth keeping track of, but likely not a cause for concern. Clock to output delays and setup time requirements are going to chew up much more of the timing budget. > 2) Should I try to make the clock line equal the longest non-clock > signal, or leave it at its natural length, which is about midway > (400mil point-to-point)? Clock line lengths should be matched to other clock line lengths (which is not your situation), not other data signals. Leave it at the natural length. > 3) With the traces this short, does it still make sense to source > terminate the clock? I'm guessing yes, but the density is getting > pretty high around this thing. > A better question to ask yourself is "If I find out later that I need to terminate the clock, how the heck am I going to do it since I didn't provision for one?" Viewed that way, the answer should be obvious. Series terminate with a ~22 ohm resistor and you'll not have any worries about signal quality. Since the runs are so short anyway, I'd suggest surface route only for the clock since a fair sized percentage of the route will be surface traces just because of the parts placement you've described so there is no reason not to make it 100% surface, then the only impedance discontinuity is the one via that takes you from top to bottom. Kevin JenningsArticle: 146735
On 3/26/2010 3:15 PM, Thomas Stanka wrote: > On 25 Mrz., 17:18, Jason Thibodeau<jason.p.thibod...@gmail.com> > Second problem, how do you avoid having more than one level > transaction in the oscillation ring? > (e.g. 01010). > > bye Thomas > > Isn't the 01010 thing gonna resolve itself PDQ? It must be an unstable state. Syms.Article: 146736
On Mar 26, 5:13=A0pm, radarman <jsham...@gmail.com> wrote: > This isn't strictly a FPGA question, but I figured someone here might > be able to point me in the right direction. > > I am designing a board with an Altera EP3C40 in the 240-pin QFP and a > Cypress CY7C1792 static SRAM in the 100 pin QFP. I would like to > operate the SRAM at 200MHz, so I know the routing needs to be somewhat > careful. (I'm internally "dual-porting" the SRAM, and each port needs > to run at 100MHz) > > Right now, I have the SRAM on the flip-side of the board from the > FPGA. The RAM has a rectangular footprint, which means that some of > the traces are proportionally longer than others, but the routing is > fairly tight, with traces between 250 and 750mils. Naturally, every > signal is going through a via in this design, but the vias are > literally right next to the pad, so the top-level trace is practically > non-existent for most signals. > > The questions are, > 1) Do I need to further tighten these up? I have some room left under > the SRAM to lengthen traces (not much, but I might could improve the > delta by 10-20%), > 2) Should I try to make the clock line equal the longest non-clock > signal, or leave it at its natural length, which is about midway > (400mil point-to-point)? > 3) With the traces this short, does it still make sense to source > terminate the clock? I'm guessing yes, but the density is getting > pretty high around this thing. > > I've only done one other "high speed" design, with a Gig-E PHY, but I > was able to get all of the signals to within +/- 5 mils on that board. > It's also not entirely tested yet, so before I spin another board > running even faster, I'd like to get it right. > > Note, this is a personal project, so I'm trying to avoid BGA's. > > Thanks! I'm a little surprised that there are no cares about clock versus data from others. CARE! Your synchronous SRAM doesn't have a DLL like SDRAMs. There's one clock that you provide, nothing provided back. The amount of length matching required is determined by your timing budget. You NEED to put together a timing budget to make sure your clock and data are related better than second cousins once removed. My *opinion* is that the traces are so extremely short that ther would be little benefit from terminations or matching any better than what you have. The reality may be that there's no WAY you could get the speed you're looking for if you generate the clock FROM the FPGA without some extra work. I believe what I did in my own sync SRAM hookup was to feed the clock to the memory chip AND take the clock from the I/O back to the internals so the clock-to-out delay wasn't a concern; the "input clock" and data aligned. At least they did before the mapper started routing the signal back through an internal logic path rather than the actual pad. What is your clock source? If you have a 200MHz clock feeding both the SRAM and the FPGA externally, you have a common external reference to work from. Getting the input sampling and clock to out times to behave may be difficult. Timing budget! As for terminations, series terminations are typically used to deal with reflections. You won't get a reflection off 750 mils. But you might get a cleaner clock if there's series impedance (even if it doesn't damp reflections) and/or an AC load impedance for the clock. Resistors are pretty tiny these days; if it's hobbyist stuff, get a microscope or get your nose dangerously close to your soldering iron by using a loop. We used 0402 caps between pads under the balls on a BGA for decoupling, surely you could put an 0402 or perhaps even a "large" 0603 inline near the escapes on your QFP. The timing budget is crucial to your ability to achieve timing for both reads and writes. The data's there in the SRAM data sheet. You need to figure out what you need to make it happen for you. You have clock delays in and out, clock-to-out and setup/hold to deal with as well as absolute delays and delay skew. It can be done but you won't get it working without working the budget first.Article: 146737
On Mar 26, 9:34=A0pm, Symon <symon_bre...@hotmail.com> wrote: > On 3/26/2010 3:15 PM, Thomas Stanka wrote:> On 25 Mrz., 17:18, Jason Thib= odeau<jason.p.thibod...@gmail.com> > > Second problem, how do you avoid having more than one level > > transaction in the oscillation ring? > > (e.g. 01010). > > > bye Thomas > > Isn't the 01010 thing gonna resolve itself PDQ? It must be an unstable > state. > > Syms. It may be unstable in the long run but how long? Any idea how solitons work? Me neither. Weird stuff happens. It could be that the falling edge travels slower than a rising edge but at the same time builds up a short time-duration effect that slows a rising edge down below the falling edge speed. The rising edge gets close enough to the falling edge to be slowed down to match the speed. Precisely. Ring oscillators DO often support multiple pulses. Gabor pointed out that "Normally a ring with a single enable input wouldn't behave that way" (having multiple transitions) but what we have is code created by an individual. Did he design the "normal" ring oscillator or an abnormal one? Since there were questions, concerns, and doubts I'm not confident the ring was designed with the ability to exclude glitches. "Normal" comes from experience.Article: 146738
Hi, I'm looking for a device that will perform something on the order of hundreds of millions of 12x12 multiplies per second, and I need it small. I only need about 30-40 pins of I/O. Is the Xilinx CoolRunner series completely out of the picture? Any suggestions would be appreciated. -- Randy Yates % "Bird, on the wing, Digital Signal Labs % goes floating by mailto://yates@ieee.org % but there's a teardrop in his eye..." http://www.digitalsignallabs.com % 'One Summer Dream', *Face The Music*, ELOArticle: 146739
Randy Yates <yates@ieee.org> writes: > Hi, > > I'm looking for a device that will perform something on > the order of hundreds of millions of 12x12 multiplies > per second, and I need it small. I only need about > 30-40 pins of I/O. > > Is the Xilinx CoolRunner series completely out of the > picture? Any suggestions would be appreciated. PS: I'm hoping for a size on the order of ~20-30 mm^2. -- Randy Yates % "My Shangri-la has gone away, fading like Digital Signal Labs % the Beatles on 'Hey Jude'" mailto://yates@ieee.org % http://www.digitalsignallabs.com % 'Shangri-La', *A New World Record*, ELOArticle: 146740
Uncompressed, standard bitstream sizes for Spartan-6 are listed in UG380 (Table 5-5 in v2.1). Ranges anywhere from 2,724,832 for the LX4 and LX9 up to 33,761,696 for the LX150/T. Besides the other recommendations, also be aware that Spartan-6 SPI configuration supports the newer Multi-I/O Flash. This allows you to increase your configuration rate by reading back the SPI Flash in x2 or x4 modes. Take a look at the Spansion S25FL family or the Numonyx N25Q. The S25FL comes in 32, 64, or 128. Smallest package is a 5x6mm. Xilinx iMPACT supports this family as of 11.4. http://www.spansion.com/Products/Pages/MirrorBitSPIMulti_IO.aspx Only the 128 version is available in the N25Q family. Smallest package is a 6x8mm. I believe Xilinx iMPACT support is slated in 12.1. http://www.numonyx.com/en-US/MemoryProducts/NORserial/Pages/N25Q.aspx I have experimented with both families with Spartan-6, and both work well, with the added benefit of potentially configuring 4x faster. BryanArticle: 146741
Randy Yates <yates@ieee.org> wrote: > I'm looking for a device that will perform something on > the order of hundreds of millions of 12x12 multiplies > per second, and I need it small. I only need about > 30-40 pins of I/O. > Is the Xilinx CoolRunner series completely out of the > picture? Any suggestions would be appreciated. I would have thought Spartan-6, but mostly because I don't know CoolRunner that well. Spartan-6 has block multipliers (at least I think it does), but you could also do a pipelined multiplier pretty easily in LUTs. Since you don't seem to have a lot of I/O, I will assume that it is a pipeline, such as systolic array. You should be able to easily do 100MHz in Spartan-6, maybe closer to 200MHz. It might do well in the smaller Spartan-6 devices. -- glenArticle: 146742
On Mar 27, 1:34=A0pm, Symon <symon_bre...@hotmail.com> wrote: > On 3/26/2010 3:15 PM, Thomas Stanka wrote:> On 25 Mrz., 17:18, Jason Thib= odeau<jason.p.thibod...@gmail.com> > > Second problem, how do you avoid having more than one level > > transaction in the oscillation ring? > > (e.g. 01010). > > > bye Thomas > > Isn't the 01010 thing gonna resolve itself PDQ? It must be an unstable > state. Hehe.. perhaps in theory... ;) - I went looking for this on the bench a while ago, and it is not as 'unstable' as you might think! I managed to start, and run, ring oscillators with shorter periods... My conclusion was that local LCR artifacts meant the trend lines were not monotonic... and so a reset line is always a good idea. -jgArticle: 146743
On Mar 27, 3:39=A0pm, Randy Yates <ya...@ieee.org> wrote: > Hi, > > I'm looking for a device that will perform something on > the order of hundreds of millions of 12x12 multiplies > per second, and I need it small. I only need about > 30-40 pins of I/O. "hundreds of millions" is where in the 100..999 range ? (or even 100..1999 for those who routinely say Nineteen Hundred MHz !) > Is the Xilinx CoolRunner series completely out of the > picture? Probably. > Any suggestions would be appreciated. What else does it need to do ? -jgArticle: 146744
Randy Yates <yates@ieee.org> wrote: >Hi, > >I'm looking for a device that will perform something on >the order of hundreds of millions of 12x12 multiplies >per second, and I need it small. I only need about >30-40 pins of I/O. Is spartan 3 an option? They come in a 100 pin package. The highest speed grade should be able to do 200 million multiplies per second per multiplier. Be sure to use 1s complement numbers otherwise you'll need to sign extend which requires using all output bits which makes the multiplier much slower. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 146745
Bryan <bryan.fletcher@avnet.com> wrote: > Uncompressed, standard bitstream sizes for Spartan-6 are listed in > UG380 (Table 5-5 in v2.1). Ranges anywhere from 2,724,832 for the LX4 > and LX9 up to 33,761,696 for the LX150/T. > Besides the other recommendations, also be aware that Spartan-6 SPI > configuration supports the newer Multi-I/O Flash. This allows you to > increase your configuration rate by reading back the SPI Flash in x2 > or x4 modes. Take a look at the Spansion S25FL family or the Numonyx > N25Q. > The S25FL comes in 32, 64, or 128. Smallest package is a 5x6mm. > Xilinx iMPACT supports this family as of 11.4. > http://www.spansion.com/Products/Pages/MirrorBitSPIMulti_IO.aspx > Only the 128 version is available in the N25Q family. Smallest > package is a 6x8mm. I believe Xilinx iMPACT support is slated in > 12.1. > http://www.numonyx.com/en-US/MemoryProducts/NORserial/Pages/N25Q.aspx > I have experimented with both families with Spartan-6, and both work > well, with the added benefit of potentially configuring 4x faster. Availability of these parts is another thing to consider -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 146746
On Mar 26, 11:39=A0pm, Randy Yates <ya...@ieee.org> wrote: > Hi, > > I'm looking for a device that will perform something on > the order of hundreds of millions of 12x12 multiplies > per second, and I need it small. I only need about > 30-40 pins of I/O. > > Is the Xilinx CoolRunner series completely out of the > picture? Any suggestions would be appreciated. > -- > Randy Yates =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0% "Bird, on the wi= ng, > Digital Signal Labs =A0 =A0 =A0 =A0 =A0 =A0 =A0% =A0 goes floating by > mailto://ya...@ieee.org =A0 =A0 =A0 =A0 =A0% =A0 but there's a teardrop i= n his eye..."http://www.digitalsignallabs.com% 'One Summer Dream', *Face Th= e Music*, ELO How do you expect to get hundreds of millions of operands onto and off the chip through 30-40 IO? Depending on the operations you're doing, some tricks might be available to you but your best bet is probably to get the smallest FPGA-with-multipliers to do your dirty work. But to fully scope out what part is needed you need to figure out not only I/O bandwidth and multiplier throughput but also what you intend to do with all those operands. Are you storing operands, constants, or results? The coolrunner most probably won't do you any good. There are no embedded multipliers and no storage beyond the macrocells (at least per my recollection).Article: 146747
John_H <newsgroup@johnhandwork.com> writes: > On Mar 26, 11:39 pm, Randy Yates <ya...@ieee.org> wrote: >> Hi, >> >> I'm looking for a device that will perform something on >> the order of hundreds of millions of 12x12 multiplies >> per second, and I need it small. I only need about >> 30-40 pins of I/O. >> >> Is the Xilinx CoolRunner series completely out of the >> picture? Any suggestions would be appreciated. >> -- >> Randy Yates % "Bird, on the wing, >> Digital Signal Labs % goes floating by >> mailto://ya...@ieee.org % but there's a teardrop in his eye..."http://www.digitalsignallabs.com% 'One Summer Dream', *Face The Music*, ELO > Hi John, > How do you expect to get hundreds of millions of operands onto and off > the chip through 30-40 IO? It's a SOQPSK modulator, so the input data is 2 bits per baud. OK, that takes 2 bits. The output is 14-bit I/Q. Ok, thats total 30 bits. Add a few for control. Done. > Depending on the operations you're doing, some tricks might be > available to you but your best bet is probably to get the smallest > FPGA-with-multipliers to do your dirty work. But to fully scope out > what part is needed you need to figure out not only I/O bandwidth and > multiplier throughput but also what you intend to do with all those > operands. Are you storing operands, constants, or results? It's basically a filter, with perhaps some FEC on top. I don't know myself, and yes, I'm being way too premature. > The coolrunner most probably won't do you any good. There are no > embedded multipliers and no storage beyond the macrocells (at least > per my recollection). That was my feeling too, but I wanted to get a more professional opinion. -- Randy Yates % "Watching all the days go by... Digital Signal Labs % Who are you and who am I?" mailto://yates@ieee.org % 'Mission (A World Record)', http://www.digitalsignallabs.com % *A New World Record*, ELOArticle: 146748
On 3/27/2010 2:07 PM, Randy Yates wrote: > >> The coolrunner most probably won't do you any good. There are no >> embedded multipliers and no storage beyond the macrocells (at least >> per my recollection). > > That was my feeling too, but I wanted to get a more professional > opinion. Hi Randy, I don't have much experience of CPLDs, but you may well be able to get the multiplier performance you need. Even though a CPLD probably won't have dedicated multipliers, there's more than one way to skin a cat. Check out distributed arithmetic solutions. http://www.andraka.com/distribu.htm Also, you mention FEC. This might use up a fair chunk of hardware, but again you can serialise it, if timing permits. As for your size requirements, I thought the smallest Coolrunner was 6x6 = 36mm², too big for your spec. Cheers, Syms.Article: 146749
On Mar 27, 10:07=A0am, Randy Yates <ya...@ieee.org> wrote: > > > How do you expect to get hundreds of millions of operands onto and off > > the chip through 30-40 IO? > > It's a SOQPSK modulator, so the input data is 2 bits per baud. OK, > that takes 2 bits. The output is 14-bit I/Q. Ok, thats total 30 bits. > Add a few for control. Done. > <snip> > > It's basically a filter, with perhaps some FEC on top. I don't know > myself, and yes, I'm being way too premature. I'd recommend you prototype with an FPGA. Whether filters are the right approach or simple lookups into an I/Q "response" table for a short few codes of the sequence, you'll be able to trade off complexity with results. If you want to do a receiver, you have work to do. If you have a transmitter only, I'd think the implementation could be much simpler than you're imagining. My quick glance at SOQPSK with the various weightings suggests that the inter-symbol interference from shaping the bits at the phase or frequency level is very limited. Perhaps my glance sincerely simplifies the issue. If you pursued a lookup approach, something as cheap as the MAX-II might even give you the performance you need because it's LE based rather than product term and can get you down to 25 mm^2. Some Actel offerings might get you to a similar size/performance without multipliers. If your issues are centered on cost, the Spartan3A(N) might be a good offering with the smaller XC3S50A(N) though the smallest packages are huge by your square millimeter suggestion.
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