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
Hi
Im using timing analyser.
This is a part of my timing report
Data Path: reset to U1/count_9
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tiopi 1.300 reset
reset_IBUF
net (fanout=16) 0.444 reset_IBUF
Tilo 0.759 U1/count_or00001
* net (fanout=11) 0.674 U1/count_or0000
Tsrck 0.910 U1/count_9
---------------------------- ---------------------------
Total 4.087ns (2.969ns logic, 1.118ns route)
(72.6% logic, 27.4% route)
Actuallty U1/count_or00001 is a [FG] which sources more than 20
FlipFlops reset ( which i can see in floorplanner).
And the driving net is U1/count_or0000.( this should source more than
20 FFs)
Then why is the fanout given as 11 ..? (Please refer to * in the
report)
Shouldnt it be greater than 20..?
Article: 134726Hi there, I need to implement a mass storage device on this board. My first approach was using the xilfatfs library for saving the data on a CF memory, but I'm facing a lot of problems with that. The system turns pretty unstable, and after some weeks trying to fixed it, we can't figured out where is the problem. The only guess is that there is a bad memory management from the xilfatfs library functions. Currently I'm running the test in stand alone configuration. Some sugestions said that maybe we can try using Linux instead. However, I was making some research and I couldn't find drivers for using the CF card or the USB port with a mass storage device. Have anybody tried to do this before? Do you know if there are drivers that supports these characteristics? I have to said that I'm not totally familiar with Linux OS descriptions and it will be my first attempt to run it in the FPGA. I'm trying to follow some example receipts which didn't include support for these characteristics, so maybe I'm missing something and I'm not looking for the right terms. I know that it would be a lot of work to run Linux and configurate the system again, so I would like to know if there is support for these devices before start the adventure. Thanks a lot.Article: 134727
Hi Jon, > Looks interesting. Would the LGPL license be more appropriate though? > For example, can you legally distribute a project based on the GPLed > Genode that also uses MicroBlaze/NIOS, as doing so would presumably > require you to provide the MicroBlaze source as well, which will > obviously be a problem. According to the License text, the terms about the modification and distribution of GPL'ed source code apply only to derivative work, which is work that takes GPL source code as a starting point. The Microblaze is clearly not derived work because it does not depend in any way on the components Genode FX provides. Regards NormanArticle: 134728
On 27 ao=FBt, 18:29, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > bamboutcha9...@hotmail.com wrote: > > Hello ! > > =A0I would like to know the frequency used by Xilinx (Virtex 5) to > > decrypt bitstream before configuration . > > =A0The decrypter is it slow with small area ? fast with big area ? > > unfortunately it's not documented by xilinx . > > > Thank u for help > > It decrypts at the same rate as the configuration clock. =A0This could be > anywhere from KHz to the maximum of 100 MHz as specified in the data shee= t. > > Ed McGettigan > -- > Xilinx Inc. Ed , thank for you answer . The rate of config clk is fixed by the user ( from 2Mhz to 60Mhz ) so i did not understand by "anywhere from KHz to the maximum of 100 MHz" , moreover with my encrypted bitstream (Eprom =3D> FPGA) i couldn't run over 42 Mhz . why ? What i want to know is the throughput of the decrypter (AES 256 CBC) , how many cycles takes this architecture used by Xilinx ? is it Safe at 100% against attacks ( timing , fault attack , side channel attack ....) ? thank uArticle: 134729
On 28 Aug, 08:27, nfeske <norman.fe...@genode-labs.com> wrote: > Hi Jon, > > > Looks interesting. Would the LGPL license be more appropriate though? > > For example, can you legally distribute a project based on the GPLed > > Genode that also uses MicroBlaze/NIOS, as doing so would presumably > > require you to provide the MicroBlaze source as well, which will > > obviously be a problem. > > According to the License text, the terms about the modification and > distribution of GPL'ed source code apply only to derivative work, > which is work that takes GPL source code as a starting point. The > Microblaze is clearly not derived work because it does not depend in > any way on the components Genode FX provides. Using GPLed code means that all code in a project must be open source. No proprietary stuff. Anything that uses Genode is a derived work. If you want to allow use with proprietary code, then the LGPL should be used. See here: http://www.gnu.org/philosophy/why-not-lgpl.html "The GNU Project has two principal licenses to use for libraries. One is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice of license makes a big difference: using the Lesser GPL permits use of the library in proprietary programs; using the ordinary GPL for a library makes it available only for free programs." JonArticle: 134730
On 28 aug, 11:29, Jon Beniston <j...@beniston.com> wrote: > On 28 Aug, 08:27, nfeske <norman.fe...@genode-labs.com> wrote: > > > Hi Jon, > > > > Looks interesting. Would the LGPL license be more appropriate though? > > > For example, can you legally distribute a project based on the GPLed > > > Genode that also uses MicroBlaze/NIOS, as doing so would presumably > > > require you to provide the MicroBlaze source as well, which will > > > obviously be a problem. > > > According to the License text, the terms about the modification and > > distribution of GPL'ed source code apply only to derivative work, > > which is work that takes GPL source code as a starting point. The > > Microblaze is clearly not derived work because it does not depend in > > any way on the components Genode FX provides. > > Using GPLed code means that all code in a project must be open source. > No proprietary stuff. Anything that uses Genode is a derived work. If > you want to allow use with proprietary code, then the LGPL should be > used. > > See here:http://www.gnu.org/philosophy/why-not-lgpl.html > > "The GNU Project has two principal licenses to use for libraries. One > is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice > of license makes a big difference: using the Lesser GPL permits use of > the library in proprietary programs; using the ordinary GPL for a > library makes it available only for free programs." > > Jon if you claim that then you can equally force Xilinx to release source code of the microblaze because the mb gcc is GPL licensed and not LPGL licensed not always ALL project sources are needed to be made public if GPL based part are used in the project depend how you define project and library i can say its ALL one projects and microblaze is one VHDL library what is linked to the stuff compiled with GPL licensed tools, so microblaze also needs to be GPL, etc.. i think the Xilinx lawer disagree with that but in generic the GPLxxx stuff is not really applicable today for FPGA ip cores and related stuff AnttiArticle: 134731
"knight" <krsheshu@gmail.com> wrote in message news:01250168-8d89-41c3-8c31-7fced56fcc62@m36g2000hse.googlegroups.com... > Hi > > > > Actuallty U1/count_or00001 is a [FG] which sources more than 20 > FlipFlops reset ( which i can see in floorplanner). > And the driving net is U1/count_or0000.( this should source more than > 20 FFs) > Then why is the fanout given as 11 ..? (Please refer to * in the > report) > Shouldnt it be greater than 20..? Sir Knight, Have a look at the net in FPGA editor. I guess that two FFs in a slice get fed from a single pin. HTH., Syms.Article: 134732
On Aug 27, 4:49=A0pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Tue, 26 Aug 2008 23:39:53 -0700 (PDT), knight <krshe...@gmail.com> > wrote: > > >I wanted to set some constraints in Floorplanner. > >Every time i change a constraint in floorplanner, for example placing > >a LUT, > >and run PAR the whole placements of other blocks gets changed. > > >Is it possible to save the constraints generated after PAR..? > >i want to first make other blocks static and place my block at > >different locations and evaluate timing.. > > I think you want to select "re-entrant flow" in the PAR properties menu > (there will be a command line option for this if you are not using > Project Navigator) > Read how to use re-entrant flow in the PAR manual. > > - Brian Hi, You can open the Place and Route design in the FloorPlanner. Go to Floorplan Menu -> Replace All with placement . This will copy the currently placed design into the Editable Floorplanner. Now you can do the required changed in the LUT location in the edittable window. Save this to the UCF file and use this as the UCF file LuxArticle: 134733
> Using GPLed code means that all code in a project must be open source. > No proprietary stuff. Anything that uses Genode is a derived work. If > you want to allow use with proprietary code, then the LGPL should be > used. > > See here:http://www.gnu.org/philosophy/why-not-lgpl.html That discussion is going on for ages, for example about binary graphics drivers in the Linux kernel. I am with the interpretation by Linus Torvalds that GPL code that is linked to independent (!) proprietary code does not infect this proprietary code, which is just common sense. If however, you build a system that depends on GPL components and you distribute your system, your additions must be released as GPL. So it is not as easy as "no proprietary stuff" ;-) In any case, Genode Labs offers proprietary licensing options in addition to the GPL version of Genode FX. For using Genode FX in a proprietary product, I suggest to contact Genode Labs directly. Regards NormanArticle: 134734
> if you claim that then you can equally force Xilinx to release source > code of the microblaze > because the mb gcc is GPL licensed and not LPGL licensed Not at all. GCC is not linked with Microblaze. > not always ALL project sources are needed to be made public if GPL > based part are > used in the project Correct. Its only if they are linked together. > depend how you define project and library > i can say its ALL one projects and microblaze is one VHDL library what > is linked to the > stuff compiled with GPL licensed tools, so microblaze also needs to be > GPL, etc.. I'm not refering the s/w parts of this project - but the VHDL/Verilog core that gets linked in. > but in generic the GPLxxx stuff is not really applicable today for > FPGA ip cores and related stuff It is if IP cores are being released under the GPL. JonArticle: 134735
> That discussion is going on for ages, for example about binary > graphics drivers in the Linux kernel. I am with the interpretation by > Linus Torvalds that GPL code that is linked to independent (!) > proprietary code does not infect this proprietary code, which is just > common sense. Well, that argument is based on the fact that the proprietary code isn't statically linked. That is not the case in an FPGA or ASIC. Much easier to just use the LGPL so there is no confusion, IMHO. JonArticle: 134736
On Aug 28, 2:18 pm, "Symon" <symon_bre...@hotmail.com> wrote: > "knight" <krshe...@gmail.com> wrote in message > > news:01250168-8d89-41c3-8c31-7fced56fcc62@m36g2000hse.googlegroups.com... > > > Hi > > > Actuallty U1/count_or00001 is a [FG] which sources more than 20 > > FlipFlops reset ( which i can see in floorplanner). > > And the driving net is U1/count_or0000.( this should source more than > > 20 FFs) > > Then why is the fanout given as 11 ..? (Please refer to * in the > > report) > > Shouldnt it be greater than 20..? > > Sir Knight, > Have a look at the net in FPGA editor. I guess that two FFs in a slice get > fed from a single pin. > HTH., Syms. thank you...Article: 134737
> Hi, > You can open the Place and Route design in the FloorPlanner. > Go to Floorplan Menu -> Replace All with placement . This will copy > > Lux Thank you that solved it...Article: 134738
Jon Beniston wrote: >> That discussion is going on for ages, for example about binary >> graphics drivers in the Linux kernel. I am with the interpretation by >> Linus Torvalds that GPL code that is linked to independent (!) >> proprietary code does not infect this proprietary code, which is just >> common sense. > > Well, that argument is based on the fact that the proprietary code > isn't statically linked. That is not the case in an FPGA or ASIC. Much > easier to just use the LGPL so there is no confusion, IMHO. > It's *not* easier to use the LGPL - it is almost equally unsuitable. The GPL says (roughly) that any code that is directly linked to the GPL'ed code must also be GPL'ed. You can't use GPL'ed IP and non-GPL'ed IP in the same FPGA. The LGPL is a little lighter - it allows you to link the LGPL'ed code with non-GPL'ed code as long as anyone with the binary is able to get the source code to the LGPL part, modify it, re-link it, and use the new version. This is fine for things like dynamically linked libraries on a desktop OS (that's what it was designed for), but hardly practical for FPGA IP! A better choice of license would be what is known as a "modified GPL" or "GPL with exception" license (or the very similar Mozilla Public License). Here the GPL is explicitly modified to apply only to the source files provided - you are free to link them in any way to any other modules under any other license. This basically means you can use the modified GPL files as you like, but if you change them you have to give these changes back to the community. See <http://www.freertos.org/a00114.html> for an example of this for an embedded RTOS.Article: 134739
Hi! Everyone: EA PR design flow can allow signals (routes) in the base design to cross through a partially reconfigurable region without using a bus macro. Howevr, can I disable the operation? Thanks! BR, hunagArticle: 134740
"Jon Beniston" <jon@beniston.com> wrote in message news:0d15ddf8-ebfd-4863-857d-3f4208728cc2@25g2000hsx.googlegroups.com... > On 28 Aug, 08:27, nfeske <norman.fe...@genode-labs.com> wrote: >> Hi Jon, >> >> > Looks interesting. Would the LGPL license be more appropriate though? >> > For example, can you legally distribute a project based on the GPLed >> > Genode that also uses MicroBlaze/NIOS, as doing so would presumably >> > require you to provide the MicroBlaze source as well, which will >> > obviously be a problem. >> >> According to the License text, the terms about the modification and >> distribution of GPL'ed source code apply only to derivative work, >> which is work that takes GPL source code as a starting point. The >> Microblaze is clearly not derived work because it does not depend in >> any way on the components Genode FX provides. > > Using GPLed code means that all code in a project must be open source. > No proprietary stuff. Anything that uses Genode is a derived work. If > you want to allow use with proprietary code, then the LGPL should be > used. > > See here: http://www.gnu.org/philosophy/why-not-lgpl.html > > "The GNU Project has two principal licenses to use for libraries. One > is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice > of license makes a big difference: using the Lesser GPL permits use of > the library in proprietary programs; using the ordinary GPL for a > library makes it available only for free programs." Yes, and it seems pretty clear. The code you build on top of Genode is GPL'ed. The underlying stuff that Genode in turn uses -- Microblaze, or even the FPGA fabric -- is not. The LGPL would differ by allowing your code, which uses Genode, to remain proprietary. The situation is clearer to see in more "traditional" software projects. For example, distributing a GPL'ed library doesn't infer also distributing the Windows operating system source.Article: 134741
"G. Carvajal" <gcarvajalb@gmail.com> wrote in message news:81ddad66-d25c-413b-9d90-11b6f563b2d4@b1g2000hsg.googlegroups.com... > > Currently I'm running the test in stand alone configuration. Some > sugestions said that maybe we can try using Linux instead. Another alternative would be eCos. There is a port available for ML403. I haven't tried it myself, so I am not sure if it has the specific drivers you need, but overall I think it is more suitable for an embedded application. Xilinx kernel has a lot of bugs, especially when it comes to multithreading, so it's no surprising that the system using it is unstable. /MikhailArticle: 134742
> > "The GNU Project has two principal licenses to use for libraries. One > > is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice > > of license makes a big difference: using the Lesser GPL permits use of > > the library in proprietary programs; using the ordinary GPL for a > > library makes it available only for free programs." > > Yes, and it seems pretty clear. The code you build on top of Genode is > GPL'ed. The underlying stuff that Genode in turn uses -- Microblaze, or even > the FPGA fabric -- is not. If MicroBlaze was a hard-core, then maybe I'd agree. However, as a soft-core, to me, it's the same as linking with a library. Can a GPLed program run on a proprietary CPU and O/S? Yes. Can it link in a proprietary library? No. I would have thought the logical conclusion would therefore be that a GPLed FPGA bitstream can run on a proprietary FPGA, but can't link in proprietary soft IP cores. JonArticle: 134743
> The GPL says (roughly) that any code that is directly linked to the > GPL'ed code must also be GPL'ed. =A0You can't use GPL'ed IP and non-GPL'e= d > IP in the same FPGA. Ok, I think we agree here. > The LGPL is a little lighter - it allows you to link the LGPL'ed code > with non-GPL'ed code as long as anyone with the binary is able to get > the source code to the LGPL part, modify it, re-link it, and use the new > version. =A0This is fine for things like dynamically linked libraries on = a > desktop OS (that's what it was designed for), but hardly practical for > FPGA IP! You don't have to supply the modified code with the FPGA though. I'm sure a web download would be suitable. > A better choice of license would be what is known as a "modified GPL" or > "GPL with exception" license (or the very similar Mozilla Public > License). =A0Here the GPL is explicitly modified to apply only to the > source files provided What happens if someone modifies a file to use a function that is in a new file though? Do they have to provide this? JonArticle: 134744
On Aug 28, 12:13 am, "G. Carvajal" <gcarvaj...@gmail.com> wrote: > Hi there, > > I need to implement a mass storage device on this board. My first > approach was using the xilfatfs library for saving the data on a CF > memory, but I'm facing a lot of problems with that. The system turns > pretty unstable, and after some weeks trying to fixed it, we can't > figured out where is the problem. The only guess is that there is a > bad memory management from the xilfatfs library functions. > > Currently I'm running the test in stand alone configuration. Some > sugestions said that maybe we can try using Linux instead. However, I > was making some research and I couldn't find drivers for using the CF > card or the USB port with a mass storage device. Have anybody tried to > do this before? Do you know if there are drivers that supports these > characteristics? You don't need drivers. IDE-CF support is build-in the kernel. Same for USB mass storage.Article: 134745
On Aug 27, 5:45 pm, Jon Elson <el...@wustl.edu> wrote: > Andrew FPGA wrote: > >>So, you think a 13-bit counter feeding a 13-bit identity comparator will > >>work at 250 MHz? > > > Others have said it may be possible but what they fail to acknowledge > > is the large amount of extra design effort and care required to get > > there. 250 MHz is really pushing the limits in spartan 3e in my > > experience. You may have to work very hard to get there: for example I > > have just finished a distributed arithmetic filter design, that has > > only 1 LUT level between flops and after a lot of effort I got it to > > run at 206 MHz in a sp3 1600e. I can see how to get to 220MHz, but > > beyond that I don't know. The longest carry chain is 10 bits. > > > I had to bypass synthesis and instantiate xilinx primitives directly > > to gaurantee my logic was implemented in 1 LUT level. Then I had to > > manually floorplan the design - placing each flop with the > > corresponding LUT by hand( I uses RLOC's embedded in the VHDL source). > > The automatic placer didn't always place the LUT with the FLOP so you > > end up with 2 routes which kills the timing completely. > > Yes, with 64 instantiations of the circuit on the FPGA, I really DON'T > want to deal with this! > > > > >>Yeah, I really don't think we can handle $2000 IC's. This isn't a real > >>production project, we might build 5 of them at a time, but we are still > >>cost-sensitive. > > > If its such low volumes just take the unit cost hit and move to a > > Virtex part. How valuable is your time? > > Yes, I think you are right, and I greatly appreciate the data points > about the 206 MHz and the 10-bit carry. The circuit I need to implement > is REALLY simple, but gets a bit more complicated when you add in the > logic to handle the DDR. The SERDES components in the Virtex look like > they would be ideal to handle this, and instead of only having an X2 > option with DDR, this makes an X8 option nearly as simple. The part > cost, all by itself, is not that terrible, the smaller Virtex chips are > around $200. The other problem, however, is we have no capability or > experience with BGAs, and would have to send them out. That at least > doubles the cost! You don't have to use Virtex to get SERDES. The low cost Lattice family has SERDES and should be able to do what you are looking for at a *much* lower price. RickArticle: 134746
John_H wrote: > On Aug 27, 2:45 pm, Jon Elson <el...@wustl.edu> wrote: > >>Yes, I think you are right, and I greatly appreciate the data points >>about the 206 MHz and the 10-bit carry. The circuit I need to implement >>is REALLY simple, but gets a bit more complicated when you add in the >>logic to handle the DDR. The SERDES components in the Virtex look like >>they would be ideal to handle this, and instead of only having an X2 >>option with DDR, this makes an X8 option nearly as simple. The part >>cost, all by itself, is not that terrible, the smaller Virtex chips are >>around $200. The other problem, however, is we have no capability or >>experience with BGAs, and would have to send them out. That at least >>doubles the cost! >> >>Thanks again for the info! > > > 1) The Virtex is a good way to go; the SERDES will work for you as > long as your minimum delays are met (same is true of shorter delay DDR > version). > 2) I thought you had 32 channels What we have is 32 inputs. Each input starts an independent and individually adjustable delay, at the end of that delay a pulse of a settable width comes out. So, the delay and the width circuit are essentially digital one-shots, and basically the same. The only difference would be the delay has an asynchronous input, the width is totally synchronous. > 3) One instantiation is almost the same as 64 in complexity. It's one > lone module that produces the results for each instance. As long as you don't need to go into the chip viewer and manually route anything to meet timing, yes. I REALLY do not want to have to do that, as Andrew apparently needed to do on a Spartan 3 project. > 4) BGAs can give growing pains, but it's the industry's current sweet- > spot. If not now, than a few more months down the road. > > I'd personally be happy to crank out a design like this in the > Spartan3x series, but for a 5-up production the added speed and > functionality of the Virtex is a good win. Well, given the serdes function of the Virtex, maybe we can go 1 ns input and output resolution, with only 125 MHz clock on the counter/comparator. My boss would really love that. The smaller Virtex seem to come in a 1mm-pitch BGA, maybe I can even learn how to do that myself. Since the balls are only around the perimiter, it might be visibly inspectable. I'll have to do more research to find out what is practical. JonArticle: 134747
Jim Granville wrote: > John Larkin wrote: > >> Oh, 32 separate triggers. Stick with analog ramps? >> >> Some of the LVDS line receivers make might fine fast and cheap >> comparators, duals even. So could probably do it all in cmos these >> days, fairly simple stuff. >> >> Trigger fires flipflop, turns ramp loose; ramp drives two comparators, >> which drive a logic gate to make rising/falling output edges. 2nd >> comparator clears flipflop. 64 DAC channels program the mess, not bad >> if you use serial octal dacs. Figure 2 square inches per channel to be >> generous, so it's an 8x8" board. > > > Analog is a candidate, but the OP mentioned a 100:1 dynamic range. > Maybe some range-sw caps ? > Well, it is all designed and the board is layed out. I used the AD CMP603 single fast comparator. A bear to mount, but a very fine chip for the purpose. It DOES use 2 range switching caps, plus stray capacitance as the lowest cap value, plus 2 selections of current-programming resistor. THEN, my boss said -- "Hey, couldn't you do that with an FPGA?" > Anyone seen Vos vs Common Mode voltage plots for LVDS channels > in FPGAs ? Cross talk figures ? I guess you could measure it yourself. JonArticle: 134748
"Jon Beniston" <jon@beniston.com> wrote in message news:9f7da391-948c-48d2-a44c-e8abd1d859c4@m45g2000hsb.googlegroups.com... >> > "The GNU Project has two principal licenses to use for libraries. One >> > is the GNU Lesser GPL; the other is the ordinary GNU GPL. The choice >> > of license makes a big difference: using the Lesser GPL permits use of >> > the library in proprietary programs; using the ordinary GPL for a >> > library makes it available only for free programs." >> >> Yes, and it seems pretty clear. The code you build on top of Genode is >> GPL'ed. The underlying stuff that Genode in turn uses -- Microblaze, or >> even >> the FPGA fabric -- is not. > > If MicroBlaze was a hard-core, then maybe I'd agree. However, as a > soft-core, to me, it's the same as linking with a library. If that were so, Genode would be required to GPL Microblaze, and our troubles would already be solved. We would just refer everyone else to Genode for the Microblaze code. > > Can a GPLed program run on a proprietary CPU and O/S? Yes. Can it link > in a proprietary library? No. > > I would have thought the logical conclusion would therefore be that a > GPLed FPGA bitstream can run on a proprietary FPGA, but can't link in > proprietary soft IP cores. Is the intent of the GPL to prohibit physical distribution on the same media as proprietary components? I think not. I can store GPL components on the same hard disk as I store unrelated components, proprietary or otherwise. Their presence in the same bitstream ... is complicated by the difference between general computing and embedded systems. I'm tending to agree with you that (my superficial understanding of) the license terms leaves it gray and muddy. If a proprietary component puts a signal on a wire, and I arranged for a GPL'ed component to read that signal, am I in violation of the GPL? Does that constitute "linking with"? If my GPL'ed component reads signals from disparate sources, proprietary or otherwise, would I be in violation of the GPL by generating signals specifically targetted for the GPL'ed GUI? If I sell a proprietary solution that generated signals compatible with a GPL component, would the end user be in violation of the GPL by "linking" the two into a single bitstream? For the same proprietary system, is it a violation of the GPL if it came already "linked" with the GPL component in a single bitstream?Article: 134749
On Aug 28, 8:30=A0am, rickman <gnu...@gmail.com> wrote: > > You don't have to use Virtex to get SERDES. =A0The low cost Lattice > family has SERDES and should be able to do what you are looking for at > a *much* lower price. While it's true the 3+Gb/s high speed serial channels are available in the Lattice parts (my first Lattice design has started in the ECP2M - yay!) the SERDES referred to in the Virtex parts for these posts are - unless I'm sincerely mistaken - the serializer/deserializer elements built into the general IOBs. The standard I/Os end up with 800Mb/ s-1Gb/s data rates (pulling these numbers from memory) with a simpler interface than the MGTs or similar RocketIO that can far exceed the general I/O data rates. Even in the lattice part, 32 channels of receive and 32 channels of transmit is costly in the 3Gb/s SERDES channels. - John_H
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