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
larwe wrote: > On Apr 7, 8:47 am, Richard Pennington <r...@pennware.com> wrote: > >> with a language that I call SMIL that defines the data flow between >> between the systems in a high level way. > > You might want to think of a new name :) <http://www.w3.org/AudioVideo/ > Yes. Too bad. I kind of liked SMIL. -RichArticle: 117701
"wicky" <wicky.zhang@gmail.com> wrote in message news:1175935739.219549.222410@q75g2000hsh.googlegroups.com... > Btw: what about Virtex-5 VSK (Video Starter Kit), I hear that it will > support PCI-e. Looks like it. The V5 VSK has not been released yet, and I'm not sure what it will be when it is, but you can build your own with the video i/o daughterboard from the V4 VSK, and an ML506. http://www.xilinx.com/ml506 I haven't ordered the ML506 yet, or even looked at the data sheet in detail, but it certainly seems to have a PCI-e (1x) available. According to the Xilinx guy at ESC on Tuesday, the ML506 works fine with the VIODC. The only issue is the diff clock on the expansion connector is the opposite polarity between the ML402 and the ML506.Article: 117702
On Apr 7, 9:40 am, Richard Pennington <r...@pennware.com> wrote: > Yes. Too bad. I kind of liked SMIL. At this point, I believe all pronounceable acronyms up to and including four letters long are taken. You might want to take a look at telegraph shorthand codebooks from the nineteenth and early twentieth century. Businesses frequently used such codebooks to reduce costs of sending a telegram. Words that could be read aloud were cheaper than random combinations of letters; hence there were published large codebooks of pronounceable non-words.Article: 117703
"wicky" <wicky.zhang@gmail.com> wrote in message news:1175935739.219549.222410@q75g2000hsh.googlegroups.com... > > Btw: what about Virtex-5 VSK (Video Starter Kit), I hear that it will > support PCI-e. > If you are looking for a Virtex-5 video development card with PCI express, try this: http://www.imageproc.com/xilinx.php MH.Article: 117704
Hello, all... Has anybody gotten xc3sprog to work with the raggedstone board and its included parallel programming cable? I had to add an entry to devlist.txt for the configuration PROM (xc3sprog gets upset if it sees any unrecognized devices on the chain, even if they're not the one being programmed). After doing that, I'm able to program the S3 directly like this: ./xc3sprog pci_7seg.bit 1 The board's 7-segment LEDs go blank for a while and then come back on. Here's the kicker: the board is currently running the "default" bitstream that the board ships with, which counts down in hexadecimal. After the LEDs go dark, they come back *at the same counter position they were at before programming* and continue counting down. So, apparently the device is not only not getting programmed, but it isn't even getting reset. Yet the LEDs go dark and xc3sprog reports no errors. Weird. Any advice? - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 117705
Hi everyone, I have a very simple ADC controller in VHDL, plus a Xilinx FFT core. There are only 2 files in my project: ADC_control.vhd and myfft.xco Every time I try to create a new bit file, ISE complains that it can't find myfft.v and asks to regenerate the core. It takes a long time... and is quite frustrating. I generate myfft.vhd and myfft.xco files in the Core Generator. How do I avoid regenerating the core? Why does it keep asking me for a verilog version .v of the core? Thanks! PavelArticle: 117706
Kevin Neilson wrote: > sudheer wrote: >> We can declare a two dimensional array (e.g. 16x8-bit) as >> reg [7:0] reg_dim_2 [15:0]; >> >> But how can we initialise this array in the same statement? >> or How do we declare the initial state (known non-zero values) of an >> array without using extra logic (especially when implementing on >> hardware (FPGAs))? >> > > For simulation purposes, you may use an init loop: > > initeger i; > init for (i=0;i<16;i=i+1) reg_dim_2 = 0; > > For synthesis, the RAM will be initialized automatically to zero in an > FPGA. You may initialize to nonzero values using $readmemh: > > init $readmemh(reg_dim_2,"init_file.txt"); Adtually, the statement: initial $readmemh(reg_dim2,"init_file.txt"); Should wordk for synthesis and simulation. At least, xst claims to support it, and all simulators support it. -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."Article: 117707
Adam Getting the chain of JTAG devices means there is a hardware level issue and manually override won't do a lot to help. There are a few possibilities listed on the FAQ page here http://www.enterpoint.co.uk/moelbryn/raggedstone1_faq.html. Beyond that we occasionally see issues with noise on PC's. Using a different host to program and holding PC in reset is often enough to clear this issue. Long extension cables can also cause issues. If you still have an issue after that it might just be the programming cable is faulty and you should send an email to our board sales email and they will send out a replacement. You are not likely to get a response from them until Thursday as the sales and shipping team are shut down until then for Easter holidays. John Adair Enterpoint Ltd. On 7 Apr, 21:14, Adam Megacz <meg...@cs.berkeley.edu> wrote: > Hello, all... > > Has anybody gotten xc3sprog to work with the raggedstone board and its > included parallel programming cable? > > I had to add an entry to devlist.txt for the configuration PROM > (xc3sprog gets upset if it sees any unrecognized devices on the chain, > even if they're not the one being programmed). After doing that, I'm > able to program the S3 directly like this: > > ./xc3sprog pci_7seg.bit 1 > > The board's 7-segment LEDs go blank for a while and then come back on. > Here's the kicker: the board is currently running the "default" > bitstream that the board ships with, which counts down in hexadecimal. > After the LEDs go dark, they come back *at the same counter position > they were at before programming* and continue counting down. > > So, apparently the device is not only not getting programmed, but it > isn't even getting reset. Yet the LEDs go dark and xc3sprog reports > no errors. > > Weird. > > Any advice? > > - a > > -- > PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 117708
On Apr 7, 1:42 pm, "Telenochek" <pkoli...@hotmail.com> wrote: > Hi everyone, > > I have a very simple ADC controller in VHDL, plus a Xilinx FFT core. > There are only 2 files in my project: ADC_control.vhd and myfft.xco > > Every time I try to create a new bit file, ISE complains that it can't > find myfft.v > and asks to regenerate the core. It takes a long time... and is quite > frustrating. > > I generate myfft.vhd and myfft.xco files in the Core Generator. > How do I avoid regenerating the core? > Why does it keep asking me for a verilog version .v of the core? > > Thanks! > Pavel Nevermind, problem solved.Article: 117709
Telenochek wrote: > Nevermind, problem solved. How about sharing your solution with the group? ;) -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 117710
I am implementing IIR Filter in verilog
with equation
y(n)=a*x(n)+(1-a)*y(n-1)
a is floating point no with 5 bits
x is integer with 7 bit input .y(n) is 12 bit with 5bits
floating and 7 bit integer part
I used 2's complement logic for 1-a.
I did multiplication by shit and add.I used rounding function
for y(n) with refernce .5.My problem is i am getting limit cycle
oscillation.How to solve this as I am running out of time for
solution.Help me Thanking you
ram
Article: 117711Richard Pennington wrote: > I have recently been playing around with what I think is a new approach > to defining and implementing distributed embedded systems. I've come up > with a language that I call SMIL that defines the data flow between > between the systems in a high level way. When you opened this thread I got interested but it seems your idea of high level is up to the point where I would start in with psuedo-code in Forth. High level definition of systems tends, in my mind, to be like the Hatley and Pirbhai structured design methods. Useful for being able to be inclusive of the human elements of a system as well. -- ******************************************************************** Paul E. Bennett ....................<email://peb@amleth.demon.co.uk> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 Tel: +44 (0)1235-811095 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************Article: 117712
"Mark McDougall" <markm@vl.com.au> wrote in message news:44974ff4$0$12278$5a62ac22@per-qv1-newsreader-01.iinet.net.au... > You're not the first to ask. I'll have to post the source it on my site. Let us know the link when it appears. > Be warned, it's really crappy code... ;) If it works then it should be a good starting point for improvements.Article: 117713
Paul E. Bennett wrote: > Richard Pennington wrote: > >> I have recently been playing around with what I think is a new approach >> to defining and implementing distributed embedded systems. I've come up >> with a language that I call SMIL that defines the data flow between >> between the systems in a high level way. > > When you opened this thread I got interested but it seems your idea of high > level is up to the point where I would start in with psuedo-code in Forth. > High level definition of systems tends, in my mind, to be like the Hatley > and Pirbhai structured design methods. Useful for being able to be > inclusive of the human elements of a system as well. > Actually what I'm trying to do is to solve a problem that I have seen often in the past and for which I have seen no good solution. I wanted to model the data flow between systems that make up a complete system. But more importantly, I wanted to be able to generate code that implemented the model directly. Often, communication between systems is represented at a very low level. I've tried to turn that upside down and make the communication definition occur at a higher level. SMIL is very much like your Forth pseudo code, I suppose, except that it isn't pseudo code. It is translated into C and then executed directly. SMIL (or whatever this thing's name becomes) is a work in progress. Or maybe just an idea that won't go anywhere. I appreciate the fact that you took the time to look at it. -RichArticle: 117714
On Apr 8, 8:06 am, Richard Pennington <r...@pennware.com> wrote: > Paul E. Bennett wrote: > > Richard Pennington wrote: > > >> I have recently been playing around with what I think is a new approach > >> to defining and implementing distributed embedded systems. I've come up > >> with a language that I call SMIL that defines the data flow between > >> between the systems in a high level way. > > > When you opened this thread I got interested but it seems your idea of high > > level is up to the point where I would start in with psuedo-code in Forth. > > High level definition of systems tends, in my mind, to be like the Hatley > > and Pirbhai structured design methods. Useful for being able to be > > inclusive of the human elements of a system as well. > > Actually what I'm trying to do is to solve a problem that I have seen > often in the past and for which I have seen no good solution. I wanted > to model the data flow between systems that make up a complete system. > But more importantly, I wanted to be able to generate code that > implemented the model directly. > > Often, communication between systems is represented at a very low level. > I've tried to turn that upside down and make the communication > definition occur at a higher level. SMIL is very much like your Forth > pseudo code, I suppose, except that it isn't pseudo code. It is > translated into C and then executed directly. > > SMIL (or whatever this thing's name becomes) is a work in progress. Or > maybe just an idea that won't go anywhere. I appreciate the fact that > you took the time to look at it. > > -Rich Your goal is definitely intriguing. But there are a couple of things that I am not sure of - 1. In a distributed environment, you do not want centralized control. Therefore, the only thing standard between the two devices is the interface. So a unified tool to describe the devices seems kind of skewed from the basis. 2. If a goal of SMIL is to describe an interface and then generate any logic for it straight from C. Isn't this one of the goals of SystemC? Am I missing something? Best regards, SanjayArticle: 117715
Richard Pennington wrote: > Actually what I'm trying to do is to solve a problem that I have seen > often in the past and for which I have seen no good solution. I wanted > to model the data flow between systems that make up a complete system. > But more importantly, I wanted to be able to generate code that > implemented the model directly. Which is what the Hatley & Pirbhai Structured Design methods were intended to do with the exception of the code generation part. Then some of the UML style modeling tools take over from there as I understand it (although I have never used them). > Often, communication between systems is represented at a very low level. Considering that I have seen communications between systems modelled at various levels I think that your use of the term often is hardly applicable. > I've tried to turn that upside down and make the communication > definition occur at a higher level. SMIL is very much like your Forth > pseudo code, I suppose, except that it isn't pseudo code. It is > translated into C and then executed directly. Forth psuedo code can, with little effort, be translated into working Forth based systems. It is only a short step to make from there. The other modeling is often at a higher level of abstraction and is more useful when speaking to clients about their requirements. > SMIL (or whatever this thing's name becomes) is a work in progress. Or > maybe just an idea that won't go anywhere. I appreciate the fact that > you took the time to look at it. As I said, the initial post raised my interest but the linked document dashed any other notions about techniques that may be more useful than what I am currently using at any level. -- ******************************************************************** Paul E. Bennett ....................<email://peb@amleth.demon.co.uk> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 Tel: +44 (0)1235-811095 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************Article: 117716
fpgabuilder wrote: [snip] > > Your goal is definitely intriguing. But there are a couple of things > that I am not sure of - > > 1. In a distributed environment, you do not want centralized control. > Therefore, the only thing standard between the two devices is the > interface. So a unified tool to describe the devices seems kind of > skewed from the basis. > > 2. If a goal of SMIL is to describe an interface and then generate any > logic for it straight from C. Isn't this one of the goals of SystemC? > > Am I missing something? > Best regards, > Sanjay > Great questions. Part of my problem is explaining what I'm trying to accomplish, I think. A little background. In my day job I work on a fairly complex medical device that is made up of an operator's console and image reconstruction system that is Linux based. This connects to the actual patient scanner via an ethernet connection to an SBC running vxWorks. Part of the system rotates about an axis and has its own SBC running vxWorks. Both the stationary and rotating sides of the device talk to a variety of other subsystems via Ethernet, CAN, and serial ports. The interfaces between the systems are currently described with C header files. A lot of code is present on the two SBCs to translate the TCP/IP messages coming from the operators console to forms compatible with the non-Ethernet communication links. SMIL is an attempt to unify the definition of the communication paths throughout the entire system. It is designed for distributed computing but my emphasis has been on systems of the sort I just described. Pats might come up and go down asynchronously, but generally most of the parts need to be present for the device to function. I wanted to be able to do semantic checks on the interfaces. SMIL will check that a data packet (a SMIL event) which is generated in a part of the system is consumed in another part of the system, for example. In general events are broadcast in SMIL: You don't have to explicitly say where the event is being consumed. This decouples the system to a great extent, obviously, making for what I think is a cleaner system design. SMIL doesn't really do broadcasts, however. During system generation it can see where events flow and generate code to send the events from the source to the destination(s) automatically. As to point two, Yes, SystemC can generate code for FPGAs. SMIL's main emphasis is the communication paths between the systems. To that end there are facilities to detect when subsystems power up and go down, trace events, do endian conversions, etc. that are not (I think) directly available in SystemC. Also, SMIL is (or will be) open source. I don't believe that's true of SystemC. Thanks for the questions. -RichArticle: 117717
Richard Pennington <rich@pennware.com> wrote: >fpgabuilder wrote: >[snip] >> >> Your goal is definitely intriguing. But there are a couple of things >> that I am not sure of - >> >> 1. In a distributed environment, you do not want centralized control. >> Therefore, the only thing standard between the two devices is the >> interface. So a unified tool to describe the devices seems kind of >> skewed from the basis. >> >> 2. If a goal of SMIL is to describe an interface and then generate any >> logic for it straight from C. Isn't this one of the goals of SystemC? >> >> Am I missing something? >> Best regards, >> Sanjay >> > >Great questions. Part of my problem is explaining what I'm trying to >accomplish, I think. > >A little background. In my day job I work on a fairly complex medical >device that is made up of an operator's console and image reconstruction > system that is Linux based. This connects to the actual patient >scanner via an ethernet connection to an SBC running vxWorks. Part of >the system rotates about an axis and has its own SBC running vxWorks. >Both the stationary and rotating sides of the device talk to a variety >of other subsystems via Ethernet, CAN, and serial ports. > >The interfaces between the systems are currently described with C header >files. A lot of code is present on the two SBCs to translate the TCP/IP >messages coming from the operators console to forms compatible with the >non-Ethernet communication links. > >SMIL is an attempt to unify the definition of the communication paths >throughout the entire system. It is designed for distributed computing >but my emphasis has been on systems of the sort I just described. Pats >might come up and go down asynchronously, but generally most of the >parts need to be present for the device to function. > >I wanted to be able to do semantic checks on the interfaces. SMIL will >check that a data packet (a SMIL event) which is generated in a part of >the system is consumed in another part of the system, for example. In >general events are broadcast in SMIL: You don't have to explicitly say >where the event is being consumed. This decouples the system to a great >extent, obviously, making for what I think is a cleaner system design. >SMIL doesn't really do broadcasts, however. During system generation it >can see where events flow and generate code to send the events from the >source to the destination(s) automatically. > >As to point two, Yes, SystemC can generate code for FPGAs. SMIL's main >emphasis is the communication paths between the systems. To that end >there are facilities to detect when subsystems power up and go down, >trace events, do endian conversions, etc. that are not (I think) >directly available in SystemC. Also, SMIL is (or will be) open source. I >don't believe that's true of SystemC. > Just a question out of curiosity: Are you familiar with 'Strategies for real-time system specification' written by Hatley and Pirbhai? The book basically describes a method with which you can link and verify data flows together with the state changes in a complex system. The only thing that worries me is: yet another language... Can't you make the SMIL language fit inside the C-like syntax? This makes it a lot easier to get started with (see the succes of Java, C# and PHP). It would also be a lot easier get a parser (don't forget the pre-processor for includes, conditional compilation and defines!). -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 117718
Nico Coesel wrote: [snip] > Just a question out of curiosity: Are you familiar with 'Strategies > for real-time system specification' written by Hatley and Pirbhai? > > The book basically describes a method with which you can link and > verify data flows together with the state changes in a complex system. > No, I'm not but it is becoming obvious that I should be, since it has been mentioned by both you and Mr. Bennett. I'll look into it. > > The only thing that worries me is: yet another language... Can't you > make the SMIL language fit inside the C-like syntax? This makes it a > lot easier to get started with (see the succes of Java, C# and PHP). > It would also be a lot easier get a parser (don't forget the > pre-processor for includes, conditional compilation and defines!). > Maybe that would be a better approach. I do have a C preprocessor sitting around from a previous project... I did want to make the definition of the interfaces language independent, however, so the the actual implementation language could be C, C++, Java, VHDL, or something else. Maybe that is too ambitious a goal. My background is in both embedded systems and in compilers. Last fall I started playing around with a compiler generation tool called Elegant and got off on a tangent which resulted in SMIL. It has been fun for me, at least as a thought experiment. -RichArticle: 117719
Fellow Designers, I am looking for a more convenient way to use inexpensive eval boards to test logic designs in an fpga. I do this quite a bit already by designing stimulator logic to put in front of my design and watching the results in ChipScope. This is a lot of extra "throw-away" logic to design and usually I only hit a limited number of test cases. What I really want is a convenient way to interact with my design at run time. What I have in mind is a small piece of logic that connects to the JTAG TAP controller inside the FPGA and gives me a simple read-write bus to read and write registers and memories inside the FPGA. Then I would need a little application that runs on the PC to let me peek and poke addresses. The application should also let me run batch files that would be a list of reads and writes of addresses. Has anyone heard of such a helper application like this exists for Xilinx fpga's? Does Xilinx provide details of their chips and cable drivers to allow someone to develop such an application? I know all this is possible because Chipscope itself is such an application. However, as far as I know, ChipScope does not let the user write into the chip to control a design. Any comments welcome. Pete DudleyArticle: 117720
> Has anyone heard of such a helper application like this exists for Xilinx > fpga's? Look at http://www.xilinx.com/publications/xcellonline/xcell_53/xc_jtag53.htm > Does Xilinx provide details of their chips and cable drivers to allow > someone to develop such an application? They provide an API. Look in the manual of chipscope 9.1 , it's called "jtag cse", you can "pilot" the thing. Note that the API has changed radically between 8.2 and 9.1, and the xcell article may use the old one ... but there are some examples and with some tests you can achieve what you want. I personnaly like it because with just one BSCAN component, I can "pilot" debug function in the FPGA easily ... and then remove it in the final bistream. SylvainArticle: 117721
By a stroke of luck, I figured it out. In order to program the board, you must add this line to devlist.txt: f5045093 8 PROM Previously I had been using a value of "6" (like the other entries in the file). Using "6" gives the behavior I explained before. Using "8" results in correct programming. John, I suggest you add this to the raggedstone FAQ. One more question: I ordered the Ethernet PHY, but the pins on the bottom of the PHY daughterboard don't match any of the headers on the raggedstone. The daughtercard has two single-pin rows, plus four additional pins that are offset diagonally from the top and bottom pin of each row. The Raggedstone has only single-pin rows, none of which appear to have a pin-hole in the diagonal position. Am I missing something? Thanks. - a "John Adair" <g1@enterpoint.co.uk> writes: > Adam > > Getting the chain of JTAG devices means there is a hardware level > issue and manually override won't do a lot to help. > > There are a few possibilities listed on the FAQ page here > http://www.enterpoint.co.uk/moelbryn/raggedstone1_faq.html. Beyond > that we occasionally see issues with noise on PC's. Using a different > host to program and holding PC in reset is often enough to clear this > issue. Long extension cables can also cause issues. If you still have > an issue after that it might just be the programming cable is faulty > and you should send an email to our board sales email and they will > send out a replacement. You are not likely to get a response from them > until Thursday as the sales and shipping team are shut down until then > for Easter holidays. > > John Adair > Enterpoint Ltd. > > > On 7 Apr, 21:14, Adam Megacz <meg...@cs.berkeley.edu> wrote: >> Hello, all... >> >> Has anybody gotten xc3sprog to work with the raggedstone board and its >> included parallel programming cable? >> >> I had to add an entry to devlist.txt for the configuration PROM >> (xc3sprog gets upset if it sees any unrecognized devices on the chain, >> even if they're not the one being programmed). After doing that, I'm >> able to program the S3 directly like this: >> >> ./xc3sprog pci_7seg.bit 1 >> >> The board's 7-segment LEDs go blank for a while and then come back on. >> Here's the kicker: the board is currently running the "default" >> bitstream that the board ships with, which counts down in hexadecimal. >> After the LEDs go dark, they come back *at the same counter position >> they were at before programming* and continue counting down. >> >> So, apparently the device is not only not getting programmed, but it >> isn't even getting reset. Yet the LEDs go dark and xc3sprog reports >> no errors. >> >> Weird. >> >> Any advice? >> >> - a >> >> -- >> PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380 > > -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380Article: 117722
Pedro wrote: > I am looking for a more convenient way to use inexpensive eval boards to > test logic designs in an fpga. It is possible to do this without a board or an FPGA. Maybe I've logged too many hours debugging logical problems at a lab bench. but the novelty seems to have worn off. I use modelsim, an RTL viewer and static timing to verify FPGA logic designs. I expect the design to just work on the bench. If it doesn't, I fix the process. -- Mike TreselerArticle: 117723
Mike I agree with you that an HDL simulator and a few testbenches should always be the first line of attack. My problem comes in when I have to run 100 million clock cycles to verify a design. This often happens with DSP designs that require a lot of data through the filters to verify their functionality. Another case is when the data is a two dimensional array and the operation is something like a 2D FFT. It's easy to hit cases where its impossible to simulate the whole thing. Granted its usually possible to cut down a simulation by changing count limits, etc. In any case, I'm hoping that the USB interface might be easy to use though it could also turn into a project of its own. Also, in theory, I could hand over an eval board to software developer and they could start programming. The USB download cable could stand-in for the pci interface that will eventually be there. Anyway, I just wanted to make it clear the special circumstances where I would use hardware verification. Definitely, I will always use the simulator to the maximum extent possible. Thanks for the reply. Pete "Mike Treseler" <mike_treseler@comcast.net> wrote in message news:57t3b5F2ei71lU1@mid.individual.net... > Pedro wrote: > >> I am looking for a more convenient way to use inexpensive eval boards to >> test logic designs in an fpga. > > It is possible to do this without a board or an FPGA. > > Maybe I've logged too many hours debugging > logical problems at a lab bench. but > the novelty seems to have worn off. > > I use modelsim, an RTL viewer and > static timing to verify FPGA logic designs. > I expect the design to just work on the bench. > If it doesn't, I fix the process. > > -- Mike TreselerArticle: 117724
On 4=D4=C27=C8=D5, =CF=C2=CE=E710=CA=B109=B7=D6, "Pete Fraser" <pfra...@cov= ad.net> wrote: > "wicky" <wicky.zh...@gmail.com> wrote in message > > news:1175935739.219549.222410@q75g2000hsh.googlegroups.com... > > > Btw: what about Virtex-5 VSK (Video Starter Kit), I hear that it will > > support PCI-e. > > Looks like it. > The V5 VSK has not been released yet, and I'm not sure > what it will be when it is, but you can build your own with > the video i/o daughterboard from the V4 VSK, and an > ML506. > > http://www.xilinx.com/ml506 > > I haven't ordered the ML506 yet, or even looked at the data > sheet in detail, but it certainly seems to have a PCI-e (1x) > available. > > According to the Xilinx guy at ESC on Tuesday, the ML506 > works fine with the VIODC. The only issue is the diff clock > on the expansion connector is the opposite polarity between > the ML402 and the ML506. Thank you for your kindly reply. I have experience on V4-VSK. Now we will buy some Xilinx boards about video processing and PCI-e interface. If V5-Vsk support pci-e, then we will discard buying ML555 PCI-e board. As to ML506, I think it is unnecessary because V5-VSK uses SX95T. Thanks again. Best Regards, Wicky
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