Anyone else need bigger parts in small (low pin count) packages
in [FPGA]
|
Prev: Programming Digilent Nexys 2 from Linux
Next: Estimating resource utilization of cores (from Xilinx CoreGen)
From: Marc Jet on 1 Jun 2010 13:26 rickman wrote: > I would love to ditch the FPGA > and go 100% software, but there is one interface that makes that > impossible I think. The app configuration data (not FPGA > configuration) comes over a serial port that has timing requirements > for read that you can't meet with software. In the past I have found that more often than not, software can be very powerful when it's combined with a little bit of hardware. For example, a single 74-type gate chip can convert a micro without SPI interface into a working SPI slave. It requires 100% dedication of the software into the job, and dedicating a few I/O pins as well. Of course, wonders can't be done with these tricks. But you can get gate latency out of software loops, and possibly also reduce the software IO bandwidth. Post more about your specific problem (here or in comp.arch.embedded) if you think that there's not too much missing to reach the timing goal.
From: Nico Coesel on 1 Jun 2010 13:57 Rob Gaddi <rgaddi(a)technologyhighland.com> wrote: >On 5/29/2010 5:22 PM, Symon wrote: >> On 5/29/2010 9:57 AM, Michael Kellett wrote: >>> "Symon"<symon_brewer(a)hotmail.com> wrote in message >>> news:htpkq7$435$1(a)news.eternal-september.org... >>>> You can't meet the SI requirements of modern sub-ns rise time silicon's >>>> I/O in 'easy to solder' packages. It's because of the loop area. >>>> >>>> BGAs "are harder to probe" made me laugh! I bet you still have a logic >>>> analyser! >>> in 100 >>> pin TQFP would be very nice. >>> But I accept that the number I might buy wouldn't make the supplier very >>> rich. >>> >>> Michael Kellett >>> >> Hi Michael, >> >> Lighten up? About FPGA design? OK, I'll try! Anyway, it made me laugh, >> how light do you want? And then you talk about serious work. Talk about >> bringing the mood down! :-) >> >> Anyway, I have a 'scope too. I use it a fair bit, but not as much as >> LTSpice. I don't have a logic analyser. I have used Chipscope as a last >> resort, but a simulator like ModelSIM is my preferred tool for catching >> logic bugs. My spectrum analyser is far more useful than a logic >> analyser could be. >> >> Here's the skinny. You're correct that TQFPs are easier to hand solder >> than BGAs. Also, they are easier to probe. That's just as well because >> the SI of a TQFP because of the leads' loop area is poor enough that you >> >> Anyway, I don't know your specific circumstances, and I'm sure you have >> excellent reasons for choosing the parts you do. I would just like to >> point out that there are some jolly good incentives for ditching leaded >> parts, and that some investment in decent simulation tools and a toaster >> oven is the way forward! >> >> Cheers, Syms. >> > >The logic analyzer's not because you don't understand what your FPGA is >doing. The logic analyzer's because you don't understand what the >complex ASSP your FPGA is hooked up to is doing, because the data sheet >is both 800 pages long and woefully incomplete. And so you take your >best guess at how it behaves, throw together a simulation model of it, >and crank out your logic, but then you put it on the copper and use the >LA to find out that you vastly misunderstood the bus interface because >the translation from Japanese to English by way of Sanskrit wasn't clear. > >Simulate, but verify. My idea. Simulation doesn't catch mistakes and/or shortcomings in models. I do a lot of verification using a LA and many times I find potential problems even though the system (software + hardware) seems to be working fine. Besides, SI is not an issue for all designs. A TQFP package is OK for many mainstream applications. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico(a)nctdevpuntnl (punt=.) --------------------------------------------------------------
From: Symon on 1 Jun 2010 15:08 On 6/1/2010 4:58 PM, Rob Gaddi wrote: > > The logic analyzer's not because you don't understand what your FPGA is > doing. The logic analyzer's because you don't understand what the > complex ASSP your FPGA is hooked up to is doing, because the data sheet > is both 800 pages long and woefully incomplete. And so you take your > best guess at how it behaves, throw together a simulation model of it, > and crank out your logic, but then you put it on the copper and use the > LA to find out that you vastly misunderstood the bus interface because > the translation from Japanese to English by way of Sanskrit wasn't clear. > > Simulate, but verify. > Instead of using chipscope in an FPGA, you layout the board with a connector for your LA? You probe these signals, possibly differential, going at 100's of MHz, maybe GHz? Doesn't that mean that your SI is compromised by having to provide physical access to the signals, so you have more chance of failure? Crikey. Why doesn't borrowing a demo board from your ASSP vendor not solve your interface debugging problems? Cheers, Syms.
From: rickman on 1 Jun 2010 15:25 On Jun 1, 1:26 pm, Marc Jet <jetm...(a)hotmail.com> wrote: > rickman wrote: > > I would love to ditch the FPGA > > and go 100% software, but there is one interface that makes that > > impossible I think. The app configuration data (not FPGA > > configuration) comes over a serial port that has timing requirements > > for read that you can't meet with software. > > In the past I have found that more often than not, software can be > very powerful when it's combined with a little bit of hardware. > > For example, a single 74-type gate chip can convert a micro without > SPI interface into a working SPI slave. It requires 100% dedication > of the software into the job, and dedicating a few I/O pins as well. > > Of course, wonders can't be done with these tricks. But you can get > gate latency out of software loops, and possibly also reduce the > software IO bandwidth. > > Post more about your specific problem (here or in comp.arch.embedded) > if you think that there's not too much missing to reach the timing > goal. Sure, I don't mind sharing. I am pretty sure I've explored the solution space though. This interface has two parallel data bits as input which are used for data and address. There is a separate single output for data output. A strobe provides the clock and a command signal indicates the last clock of the transaction into the peripheral. The transaction consists of N 2 bit "chunks" of data followed by M 2 bit "chunks" of address and a single "chunk" of command. During the command "chunk" the two data bits indicate if the transaction is a read or a write. After the command "chunk" all following strobes clock read data out on the output bit, both for reads and writes. A read transaction does not require the data phase. The number of "chunks" used for the address for a write is implied by the peripheral. The timing problem is that the data in is on the rising edge and the data out is also on the rising edge with the master accepting on the falling edge. The first output bit is actually during the command cycle. So the first output bit has to be presented in less than a clock cycle from the command flag being asserted and less than 30 ns from the rising edge of the clock in the command "chunk". In the FPGA I use the address to drive a mux to select the data for read and output the lsb directly because of the short timing. The rest of the addressed register is loaded into an output register to be shifted out. The software would have about 100 ns from the last address "chunk" being clocked, 60 ns from the command flag going high and much less than 30 ns from the command being clocked to driving the first output bit. I doubt it can be done at 62.5 MIPs. Rick
From: -jg on 1 Jun 2010 21:11
On Jun 2, 7:25 am, rickman <gnu...(a)gmail.com> wrote: > > The software would have about 100 ns from the last address "chunk" > being clocked, 60 ns from the command flag going high and much less > than 30 ns from the command being clocked to driving the first output > bit. I doubt it can be done at 62.5 MIPs. What's the data rate ? We have done a number of systems, where a smallish CPLD takes the ns- level stuff, and dual-edge etc and converts it into a more micro- compatible form. Sometimes that has been parallel, and sometimes SPI/SSC -jg |