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
Johnson L wrote: > For my hobby work, I am looking for a low-cost development kit to > develope a simple embedded system. This system will measure the temperature > and heart beat rate, compare them with a predefined table which implements > some health-care knowledge, then provide some useful information. This > development kit should be low-cost, support C programming, debugging, better > with JTAG or other on-site debugging. It should support at least one type of > popular microprocessors, or a mainstream FPGA, > and easy to use. Could anybody recommend me some? Thank you in advance. > > Johnson > > It's hard to get a functional FPGA development kit that's more affordable than Avnet's Spartan-3A Eval Kit. (http://tinyurl.com/blhcar) $50 gets you an XC3S400A-4FTG256C, two types of flash, a USB bridge, several type of I/O, and a Cypress PSoC. Even better nothing else is required to program it (you don't need the $200 Xilinx cable). And for really cheap TI's eZ430 development kit is hard to beat - it's only $20. (http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html) The MSP430 is a pretty low end processor, but the kick-start version of the IAR tools does allow you to develop in C and debug on the target. There are lots of well done, not too expensive boards at Digilent (http://www.digilentinc.com), along with programming tools, various addons, and example code. They have been good about answering my questions too. (I have no commercial interest in any of these, they're just sources that I've found useful.) ChrisArticle: 139226
On Mar 24, 2:12=A0am, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > 2) the current numbers are reduces down, the smallest part at 32khz > 8uA (was 25 i think) That 8uA is typical, but it is also OPERATING at 32KHz "VCC Power Consumption for Device Filled with 16-Bit Binary Counters" The Static Standby power, is 3uA (so those 32Khz ctrs add 5uA) Quite good numbers :) -jgArticle: 139227
On Mar 24, 12:58=A0pm, rickman <gnu...@gmail.com> wrote: > > The Bank3 does support MDDR, so that seems to be what chopped the 3.3V > > I did a search, but I didn't find many details on MDDR; or is it > mDDR? =A0The supply voltage seems to be 1.8V and I believe it is > differential. =A0Banks 0, 1 and 2 support 1.8V LVCMOS voltages. =A0I gues= s > I wonder why MDDR can't be supported with hardware that is 3.3V > tolerant? My guess would be that the MDDR IP they got from the foundry, did not include 3V3 ?. -jgArticle: 139228
On Mar 24, 1:12=A0pm, rickman <gnu...@gmail.com> wrote: > > 5V is making something of a comeback, =A0more uC are now 5V too :) > > When you say "more", I never found many that dropped 5 volt tolerance, > even the newer, low core voltage parts. I am talking about 5V operation, and 5V CMOS drive, not merely 5V tolerant. It's an Important distinction, as you can properly drive a power fet, and eliminate multiple rails (and read 5V Analog too...). eg Newest Silabs Automotive devices (F58x) are 5V operation, as are newest CoreRiver variants, and even NXP have 5V versions of their LPC coming this year. -jgArticle: 139229
On Mar 23, 12:13 pm, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Mar 23, 6:01 pm, rickman <gnu...@gmail.com> wrote: > > > > > I was reading the data sheet the other day and I noticed that these > > parts have 5 volt compatible I/Os on three of the four banks. I'm > > pretty impressed with that... until I read that the fourth bank is not > > even 3.3 volt tolerant!!! What's up with that? Can do 5 volts on > > three banks and fourth can only do 2.5 just seems like a very strange > > combination. I can't for the life of me understand why or how this > > was done. Obviously there was some compelling reason to do this and I > > can only speculate that it was because of the additional I/O types in > > bank 3. Still, taking away from the number of 3.3 volt I/Os is a > > *very* poor marketing decision in my opinion. Now I would have to use > > a larger package to get the same number of *usable* I/O pins. > > > The other oddity I found was the lack of parity bits in the RAM > > blocks. There are a lot of designs that use the extra bits, including > > mine, that won't fit on these parts at all. > > > One other thing I noticed, they seem to be changing the planned > > packaging, which is not surprising I suppose. In the package list, > > they flag compatible pinouts using the same package. But I don't see > > the 04 and 08 as being compatible in the 196 pin package. This > > package was added since rev 1.1 of the data sheet, so it is surprising > > to me that these would not be compatible. > > > The CS132 package looks pretty interesting. The main reason that I > > avoid BGAs is the PCB requirements to provide routing from the inner > > pins. This package looks like it might be routable without running > > traces between the pads or even vias within the pads. But the > > innermost 16 pads seem to mess this up. Anyone have a good routing > > layout for this package? What PCB design rules are required to use > > this package? > > > Rick > > Hi > > yes 5V tolerant !! yipiie jee, and bank-3 unusuable unless 2.5V supply > is available > its not only that it is not 3.3V tolerant, you need 2.5V if you want > to use this bank at all, > so in both my current design bank-3 is unused and VCCIO3 is open > i bet that bank 3 uses completly different IO cell, hence the voltage > requirements > > http://www.microfpga.com/ > > both PCBs are 2 layer, no microvia, no trace between pads, no via in > pad, > no via between pads (but vias below the package where spacing areas > available) > smallest drilled hole 0.3mm > > but the number of IOs routable on 2 layers is limited, for both those > FPGA's in 132 8x8 package the number of ios routable out in 2 layers > is something between 40 and 50 To make sure I understand you, you are saying that you routed *part* of the I/Os on the 132 pin BGA? I guess if you don't route all of the I/Os that helps with the routing. I am concerned with the power pins in the center. How did you route G7, G8, H7 and H8? These can be routed through the pads next to them, but this makes for a higher impedance ground path. I guess this is not such an issue in a low power device like this: no fast edges (I assume) causing ground bounce and insignificant IR drops on the bond wires. Otherwise, I don't a way to route those four inner pads. Still, if you do want to route all of the I/Os, the empty ball rings don't appear to provide enough space for all of the pads on the two adjacent populated rings to be broken out with out using very small vias. RickArticle: 139230
Hello all,
I am working on a project which involves a simple BRAM, OPB-PLB,
Microblaze/PPC, and opb_ddr_sdram controller. I am reading 1280 bytes
of data from bram (32 bits each read, thus a total of 320 reads) and
writing it to DDR sdram. i am using Xilinx standalone OS. i use the
command XIo_in32(addr) to read from bram and use XIo_out32(addr,data)
to write to DDR sdram controller.
here is the c code i use to write to ddr.
for(p=0;p<320;p++) //number of reads from Bram = 320 (0:319)
{
a = XIo_In32(bram_addr);
XIo_Out32(ddr_addr+(p*4), a); //P*4 is to make sure we create room
for 32 bit data
}
I use chipscope pro to debug whats happenig inside.
stepa: It takes 3 opb clock cycles to read the value from bram
stepb: there is a 5 clock cycle delay (probably Processor is
calculating p*4),
stepc: it takes about 9 clock cycles to write to DDR sdram and
stepd: 7 clock cyles (no clue why it takes so long) to the next cycle
of read and write.
question 1: is there a way to cutdown the clock cycles (delay clock
cycles b and d) (i want to bring the total clock cycles for one
iteration down to about 15 or less)
question 2: is there a software way of reading from the bram and
writing to DDR sdram in burst mode (I know there is one in hardware
opb burst mode)
thanks,
with warm regards,
Chakra.
Article: 139231On Mar 23, 10:46=A0pm, -jg <Jim.Granvi...@gmail.com> wrote: > On Mar 24, 12:58=A0pm, rickman <gnu...@gmail.com> wrote: > > > > The Bank3 does support MDDR, so that seems to be what chopped the 3.3= V > > > I did a search, but I didn't find many details on MDDR; or is it > > mDDR? =A0The supply voltage seems to be 1.8V and I believe it is > > differential. =A0Banks 0, 1 and 2 support 1.8V LVCMOS voltages. =A0I gu= ess > > I wonder why MDDR can't be supported with hardware that is 3.3V > > tolerant? > > My guess would be that the MDDR IP they got from the foundry, did not > include 3V3 ?. > -jg Do you really think they used someone else's IP for an FPGA? How many customers need I/Os that can support 9 different standards? I would think the the I/O configuration is one of the things that makes an FPGA vendor. RickArticle: 139232
On Mar 23, 10:51 pm, -jg <Jim.Granvi...@gmail.com> wrote: > On Mar 24, 1:12 pm, rickman <gnu...@gmail.com> wrote: > > > > 5V is making something of a comeback, more uC are now 5V too :) > > > When you say "more", I never found many that dropped 5 volt tolerance, > > even the newer, low core voltage parts. > > I am talking about 5V operation, and 5V CMOS drive, not merely 5V > tolerant. > It's an Important distinction, as you can properly drive a power fet, > and eliminate multiple rails (and read 5V Analog too...). > > eg Newest Silabs Automotive devices (F58x) are 5V operation, as are > newest > CoreRiver variants, and even NXP have 5V versions of their LPC coming > this year. That makes some sense I suppose. But the automotive market is not one of the places I would expect to see many FPGAs. Even if they are low power, why does an auto maker need the flexibility of reconfiguration? Their volumes are high enough that they can spin low cost ASICs at large feature sizes which keeps the NRE down compared to FPGAs. Autos are using a lot of DSP and higher end embedded processors. Otherwise, I don't see autos pushing semi technology. Yeah, chips will be made to fit all those sockets, but the use of technology is mainly to cut the cost to the bone and FPGAs will never fit that socket. RickArticle: 139233
Well, both the price and the product sounds great! Thanks for sharing! BTW, the software license expires every 6 months. Do you think they will charge me for renewing the license? Johnson "LittleAlex" <alex.louie@email.com> wrote in message news:c1ec1088-a658-46f5-b5b3-d66cb8fe327f@v23g2000pro.googlegroups.com... >I just got an FPGA development kit from Lattice - 2200 CLB's, USB > (FX2) Interface, a software starter kit, and an 8-bit embedded > processor. > > $75 including tax & Shipping. > > Software license expires every 6 months; I'm guessing that they will > renew it. Software is reminiscent of Xilinx back in the ISE-4.2 days > (clumsy, but functional). The embedded processor (Mico8) looks -very- > interesting: if I'm seeing things correctly, they chose 'wishbone' for > their on-chip bus. > > AL > > On Mar 23, 3:14 pm, John Adair <g...@enterpoint.co.uk> wrote: >> Johnson >> >> It's not quite true that there are not free tools for FPGAs. Both the >> 2 biggest vendors Xilinx and Altera have free tools for building the >> hardware side for the smaller end FPGAs themselves. Processor support >> tools specifically Xilinx has 2 soft core processors that they support >> - PicoBlaze and MicroBlaze. Altera have Nios. Picoblaze I believe a >> third party has done a C compiler and the group probably has more >> details that I do. MicroBlaze (EDK) and Nios toolsets are essentially >> paid for tools although there are sometimes evaluation versions around >> that are good for short term use. >> >> On I/O things like acceptable voltage levels e.g. 3.3V or 5V >> signalling requirements are important. Many modern FPGAs cannot >> tolerate 5V signalling levels directly without some protection, or >> level shift, circuits. Particular protocols like I2C will need to be >> driven and controlled by some logic function within the FPGA user >> design. If you are using external modules for bluetooth etc. then >> again you need to use whatever signalling levels and protocols are >> required to transfer data and setup to the external modules. >> >> John Adair >> Enterpoint Ltd. >> >> On 23 Mar, 21:36, "Johnson L" <gpsab...@yahoo.com> wrote: >> >> > "John Adair" <g...@enterpoint.co.uk> wrote in message >> >> >news:a38658ca-69a3-4af4-bfde-1c4abf7f7264@37g2000yqp.googlegroups.com... >> >> > > Johnson >> >> > > Can you elaborate on your I/O requirements as this may affect what is >> > > best for your application. >> >> > > Most of the board vendors in the FPGA world like ourselves don't >> > > supply boards as bundled software kits as such. The software aspect >> > > tends to come from whichever processor core is being used. However >> > > there are one or two Xilinx and Altera kits that include some sort of >> > > tools version with the boards for MicroBlaze and Nios respectively >> > > but >> > > they don't tend to be in hobby engineer price area. >> >> > > For the lowest cost you may have to think about seperate solution for >> > > a microprocessor and board. There various microprocessor cores on >> > > Opencores that are based on popular things like Z80 and so on and >> > > there are lots of tools out there for that common processor. There >> > > also things like 8086/8 cores available from third party vendors >> > >http://www.ht-lab.com/hardware/drigmorn1/drigmorn1.htmlbutthese do >> > > cost. >> >> > > John Adair >> > > Enterpoint Ltd. >> >> > > On 23 Mar, 05:08, "Johnson L" <gpsab...@yahoo.com> wrote: >> > >> For my hobby work, I am looking for a low-cost development kit to >> > >> develope a simple embedded system. This system will measure the >> > >> temperature >> > >> and heart beat rate, compare them with a predefined table which >> > >> implements >> > >> some health-care knowledge, then provide some useful information. >> > >> This >> > >> development kit should be low-cost, support C programming, >> > >> debugging, >> > >> better >> > >> with JTAG or other on-site debugging. It should support at least one >> > >> type >> > >> of >> > >> popular microprocessors, or a mainstream FPGA, >> > >> and easy to use. Could anybody recommend me some? Thank you in >> > >> advance. >> >> > >> Johnson >> >> > Thanks, John, your answer is very informative and helpful. However, as >> > a >> > hobby engineer I don't know how to elaborate the I/O requirements. >> > Could you >> > please give me a simple example? >> > As for now, I would like the sensors being connected to the >> > microprocessor >> > in a simple way, such as I2C or UART. I possibly also need a port for >> > BLUETOOTH or ZIGBEE to send out the commands to a wireless peripheral. >> > BTW, if I understand it correct, there is no free or low-cost >> > development >> > kit for FPGA, right? >> > Johnson- Hide quoted text - >> >> > - Show quoted text - >Article: 139234
I also want to know, is there any low-cost development kit for DSP as well? I possibly need some filter function in the software as well so I am also thinking about DSP. Anybody can help? Thanks. Johnson "Johnson L" <gpsabove@yahoo.com> wrote in message news:FPExl.73664$FI5.25671@newsfe07.iad... > For my hobby work, I am looking for a low-cost development kit to > develope a simple embedded system. This system will measure the > temperature > and heart beat rate, compare them with a predefined table which implements > some health-care knowledge, then provide some useful information. This > development kit should be low-cost, support C programming, debugging, > better > with JTAG or other on-site debugging. It should support at least one type > of > popular microprocessors, or a mainstream FPGA, > and easy to use. Could anybody recommend me some? Thank you in advance. > > Johnson > >Article: 139235
"Chris Abele" <ccabele@yahoo.com> wrote in message news:IfadnV9xaJ9I2FXUnZ2dnUVZ_oninZ2d@giganews.com... > Johnson L wrote: >> For my hobby work, I am looking for a low-cost development kit to >> develope a simple embedded system. This system will measure the >> temperature >> and heart beat rate, compare them with a predefined table which >> implements >> some health-care knowledge, then provide some useful information. This >> development kit should be low-cost, support C programming, debugging, >> better >> with JTAG or other on-site debugging. It should support at least one type >> of >> popular microprocessors, or a mainstream FPGA, >> and easy to use. Could anybody recommend me some? Thank you in advance. >> >> Johnson >> >> > > It's hard to get a functional FPGA development kit that's more affordable > than Avnet's Spartan-3A Eval Kit. (http://tinyurl.com/blhcar) $50 gets you > an XC3S400A-4FTG256C, two types of flash, a USB bridge, several type of > I/O, and a Cypress PSoC. Even better nothing else is required to program > it (you don't need the $200 Xilinx cable). > > And for really cheap TI's eZ430 development kit is hard to beat - it's > only $20. (http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html) > The MSP430 is a pretty low end processor, but the kick-start version of > the IAR tools does allow you to develop in C and debug on the target. > > There are lots of well done, not too expensive boards at Digilent > (http://www.digilentinc.com), along with programming tools, various > addons, and example code. They have been good about answering my > questions too. > > (I have no commercial interest in any of these, they're just sources that > I've found useful.) > > Chris Chris, thank you very much for sharing them! The kits look awesome! BTW, for Avnet's Spartan-3A Eval Kit, nothing else is required to program it. However, I need to program it since I need to implement some generic functions written in C. So it isn't an option for me. JohnsonArticle: 139236
>ERROR:Pack:1564 - The dual data rate register <signal name> failed to >join the OLOGIC component as required. The OLOGIC SR signal does not >match the ILOGIC SR signal, or the ILOGIC SR signal is absent. I assume that SR is the Set/Reset pin and that it's shared by the input and output FFs. Are you (re)setting one pair of FFs and not the other? I'd have to get out the data sheet and lookup the fine print on the hardware and then look at the macros to see what combinations make sense. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 139237
Hi, I am designing a system which needs multiple interfaces (about 16) to backplane running at about ~700Mhz. These are going to be source synchronous interfaces and clock will be available. I did not wanted to use the build in transceivers because the 20 transceiver devices are very expensive. The logic and block Ram requirement of the design is relatively small. I was wondering if for Xilinx FPGA can I use the normal LVDS select IO pins to drive the backplane. Will it work? Are there any design consideration that I need to take to accomplish this. What is the maximum trace that the select LVDS IO can drive. Also wondering if there is any difference between Xilinx and Altera LVDS, if either or one of them is suited for backplane applications. Cheers. -- GoliArticle: 139238
On Mar 23, 6:27=A0am, gabor <ga...@alacron.com> wrote: > On Mar 23, 9:15=A0am, gabor <ga...@alacron.com> wrote: > > > > > > > On Mar 23, 5:19=A0am, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote: > > > > Hi Wang, > > > > I wouldn't dare (at my age) to get absorbed into that algebra of feed= back > > > shift pipes and polynomials. I believe there is plenty around(even wi= ki got > > > interesting stuff). I rather get things ready for me to use and let t= he > > > young research into the underlying mess. > > > > kadhiem > > > I was under the impression that all LFSR's used an even > > number of terms. =A0The table of feedback terms in the appnote > > is only one possible set of polynomials for maximal LFSR's of > > each length, however these represent the ones with the least > > number of terms for that length of LFSR. =A0At one time I had > > written a C program to search for maximal LFSR feedback > > terms. =A0Then I found the Xilinx appnote. =A0I think the main > > requirement for a maximal LFSR is that the polynomial is > > relatively prime with respect to 2^N - 1. =A0The number of > > states for a given set of feedback terms does not depend > > on use of XOR vs XNOR. =A0You can easily prove that these > > two are equivalent by simply inverting the logic: > > > if Y =3D A XOR B > > then not Y =3D not A XOR not B > > > Regards, > > Gabor > > Oops, posted too fast. =A0I meant: > > if Y =3D A XOR B > then not Y =3D not A XNOR not B- Hide quoted text - > > - Show quoted text - Hi Gabor, Good equation ! How dare you start writing a C program to search for LFSR feedback terms! It must be based on some mathematical theory. I found a lot of books on Algebraic Coding from Amason, but I would like someone to recommend one of those excellent books he read and learned, and I would like to buy and read one as a hobby. Reading and learning is funny than watching TV. WengArticle: 139239
>Do you really think they used someone else's IP for an FPGA? How many >customers need I/Os that can support 9 different standards? I would >think the the I/O configuration is one of the things that makes an >FPGA vendor. It wouldn't surpise me if they used vendor provided parts for the final driving transistors and bonding pad area and EMI on the input side. The foundry probably doesn't want to do things like develop a new oxide thickness. It's probably simple economics. What's the NRE for a new oxide vs the gain (better product) with more features vs risk of the new stuff not working right. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 139240
Weng Tianxiang <wtxwtx@gmail.com> wrote: (big snip) > How dare you start writing a C program to > search for LFSR feedback terms! > It must be based on some mathematical theory. Much theory research is done with programs. My favorite from some years ago was the proof of the four color theorem. (Not that I understand the proof at all.) The four color theorem is easy enough to explain to first graders, but the proof took many hours of computer time, and is likely understood by very few. -- glenArticle: 139241
Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote: > It wouldn't surpise me if they used vendor provided parts > for the final driving transistors and bonding pad area > and EMI on the input side. > The foundry probably doesn't want to do things like > develop a new oxide thickness. It's probably simple > economics. What's the NRE for a new oxide vs the > gain (better product) with more features vs risk > of the new stuff not working right. Fewer different thicknesses would make fabrication easier. For modern FPGAs you need at least two oxide thicknesses, as the configuration storage needs are very different from the logic needs. Possibly the configuration transistor oxide could also be used for output drivers. They probably won't tell you, though. -- glenArticle: 139242
On Mar 24, 4:14=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Hal Murray <hal-use...@ip-64-139-1-69.sjc.megapath.net> wrote: > > It wouldn't surpise me if they used vendor provided parts > > for the final driving transistors and bonding pad area > > and EMI on the input side. > > The foundry probably doesn't want to do things like > > develop a new oxide thickness. =A0It's probably simple > > economics. =A0 What's the NRE for a new oxide vs the > > gain (better product) with more features vs risk > > of the new stuff not working right. > > Fewer different thicknesses would make fabrication easier. > > For modern FPGAs you need at least two oxide > thicknesses, as the configuration storage needs are > very different from the logic needs. =A0Possibly > the configuration transistor oxide could also be > used for output drivers. =A0They probably won't tell > you, though. > > -- glen None of this relates to the issue of the I/O voltages. There are 5 volt functioning transistors on the die and it is pretty clear that the I/O driver circuits are designed by SiBlue. So far I don't see any of the discussion about oxide thickness to be relevant. RickArticle: 139243
it is being developed :) well it is actually NPU version 2 (where NPU stands for my node processor unit - a not finished design concept) some features * optimized for streaming media, that is clocked data streams (serial flash, SD card, etc..) * PC is optional * Stack is optional * minimum number of registers: 0 * minimum size of internal RAM: 0 * no reset pin needed (input stream can force reset) * operand widths: 1 to unlimited * address space: unlimited * minimal configuration : 0 LUT/0 FF (1 Block ROM + IOB F/F's) there are some compromises of course, say 32 bit ALU operation would take 40 clock cycles for the operation itself + some more clocks to select the operands and operation type. shorter operation will be less clock cycles, but still rather slow in terms of clock cycles otoh as the serialized nature allows operation at higher fabric speeds then the overall performance could be rather good. Quad SPI memories can stream data at 320MBit/s, in modern FPGA NPU2 could easily run at 320mhz, what would give some >5 MIPS for 32 bit operations what is not that bad at all the Processor is currently designed using EXCEL main problem would be the tool support, as the assembler/compiler would need to be generated based on the processor description, there is no fixed instruction set at all, and pretty much all features of the processor are configurable, also variables and constant can be of different widths, so the compiler should know how wide variables to use, not only 8/16/32 but they can really be any size with single bit granularity AnttiArticle: 139244
rickman <gnuarm@gmail.com> writes: > That makes some sense I suppose. But the automotive market is not > one of the places I would expect to see many FPGAs. Even if they > are low power, why does an auto maker need the flexibility of > reconfiguration? Their volumes are high enough that they can spin > low cost ASICs at large feature sizes which keeps the NRE down > compared to FPGAs. You might be surprised :) (sorry if this is a bit blatant, but it's on topic... http://www.conekt.net/fpgas-for-ldw.html ) And being able to reconfigure is not a bad thing - we also use a lot of flash micros, rather than ROMming everything. > > Autos are using a lot of DSP and higher end embedded processors. > Otherwise, I don't see autos pushing semi technology. Yeah, chips > will be made to fit all those sockets, but the use of technology is > mainly to cut the cost to the bone and FPGAs will never fit that > socket. You can get an awful lot of FPGA for the price of a DSP these days. And if you've been thinking highly parallel all the way through development, you can do a lot more with them (IMHO :) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 139245
On Mon, 23 Mar 2009 06:15:59 -0700, gabor wrote: > On Mar 23, 5:19 am, "kadhiem_ayob" <kadhiem_a...@yahoo.co.uk> wrote: >> Hi Wang, >> >> I wouldn't dare (at my age) to get absorbed into that algebra of >> feedback shift pipes and polynomials. I believe there is plenty >> around(even wiki got interesting stuff). I rather get things ready for >> me to use and let the young research into the underlying mess. >> >> kadhiem > > I was under the impression that all LFSR's used an even number of terms. LFSRs with an odd number of feedback terms have a polynomial with (x+1) as a factor. These are not primitive, not maximal length and not as interesting as the ones with an even number of feedback terms. They're still LFSRs though. Regards, AllanArticle: 139246
On Mar 24, 6:56 am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >ERROR:Pack:1564 - The dual data rate register <signal name> failed to > >join the OLOGIC component as required. The OLOGIC SR signal does not > >match the ILOGIC SR signal, or the ILOGIC SR signal is absent. > > I assume that SR is the Set/Reset pin and that it's shared > by the input and output FFs. Are you (re)setting one pair > of FFs and not the other? > > I'd have to get out the data sheet and lookup the fine print > on the hardware and then look at the macros to see what > combinations make sense. > > -- > These are my opinions, not necessarily my employer's. I hate spam. I tried it and yes this fix it. I had 2 differents resets (one synchronous to the ODDR clk, and one synchronous to the IDDR clock). I set both on the same reset, and MAP succeeded. Thanks a lot!Article: 139247
On Mar 24, 3:27=A0pm, rickman <gnu...@gmail.com> wrote: > On Mar 23, 10:46=A0pm, -jg <Jim.Granvi...@gmail.com> wrote: > > Do you really think they used someone else's IP for an FPGA? =A0How many > customers need I/Os that can support 9 different standards? =A0I would > think the the I/O configuration is one of the things that makes an > FPGA vendor. There are high costs to proving Pin Drivers, and if the foundry has a KGIO already, there is a strong temptation to use that on the first pass. It certainly looks like the MDDA excluded 3.3 / 5V compliance. Could be capacitance, perhaps someone at SlilconBlue will enlighten us ? -jgArticle: 139248
rickman <gnuarm@gmail.com> wrote: > None of this relates to the issue of the I/O voltages. There are 5 > volt functioning transistors on the die and it is pretty clear that > the I/O driver circuits are designed by SiBlue. So far I don't see > any of the discussion about oxide thickness to be relevant. Oxide thickness is the most important factor in determining the transistor voltage. That said, we really don't know anything about the design of the transistors, so, yes, there isn't much reason to discuss it. -- glenArticle: 139249
Hello, These questions are essentially impossible to answer. You need to figure out what sort of backplane you're working on, what sort of board will be driving the backplane, and what sort of board will be receiving the LVDS signal. Next, target a particular family of FPGA rather than "Xilinx FPGA". After that, spend some time with minimally HyperLynx or preferably an electromagnetic field simulator to figure out if this is possible or not. I think you will find that noone will give you a definitive answer other than "if you don't do your homework, this will not work." Good luck, Nathan On Mar 24, 2:16=A0am, Goli <tog...@gmail.com> wrote: > Hi, > > I am designing a system which needs multiple interfaces (about 16) to > backplane running at about ~700Mhz. These are going to be source > synchronous interfaces and clock will be available. =A0I did not wanted > to use the build in transceivers because the 20 transceiver devices > are very expensive. The logic and block Ram requirement of the design > is relatively small. > > I was wondering if for Xilinx FPGA can I use the normal LVDS select IO > pins to drive the backplane. Will it work? Are there any design > consideration that I need to take to accomplish this. What is the > maximum trace that the select LVDS IO can drive. > > Also wondering if there is any difference between Xilinx and Altera > LVDS, if either or one of them is suited for backplane applications. > > Cheers. > > -- > Goli
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