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
Jonathan What the current photo does not show is the serial flash that resides on the back of each of these modules for configuration but also as a code storage device. At the moment this module does not have a sram and certainly on the smallest of these module probably is not possible. We do hope that these modules do have uptake in university projects and a few other sectors as well. Time will tell but generally I think these will fufill some needs out there. For modules with SRAM we have the Darnaw1 which is running through at the moment. Photos in a couple weeks I hope. It is a very similar concept except no 5V tolerance and a lot more pins. As with anything we do it is possible to do derivative designs if there is commercial sense for us to do so. Just needs someone to make a good case to us to do it. John Adair Enterpoint Ltd. Jonathan Bromley wrote: > On 11 Jan 2007 03:32:57 -0800, "John Adair" > <g1@enterpoint.co.uk> wrote: > > >Not set in stone yet but one off prices are likely to be GBP=A325-30, > >US$ 40-50 on current exchange, for the base level versions with the > >XC3S100E. If it starts to ship in reasonable numbers it is likely we > >will drop that price back a bit. Certainly discounts will be there for > >orders of 10+ even at the initial production run rate. > > I'm no longer in an academic role, but it seems to me that you > have there something that will be very, very desirable as a > component of many undergraduate projects. > > Some silly questions: > (1) is there room on the (back of???) the board for a config ROM? > (2) is there room on the back for a modest-sized SDRAM? > > Obviously, neither need be populated on low-cost versions. > > Nice product. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.bromley@MYCOMPANY.com > http://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated.Article: 114401
On Sun, 14 Jan 2007 17:58:53 -0800, Jason <please@replytogroup.com> wrote: >Does anyone out there use SDK version 8.2? I recently migrated from 8.1 where I never had an issue compiling small pieces of test code. Now however things that used to work do not. I have scoured through the Google searches and the Xilinx website to no luck. The error message that I get is very vague, and I do not quite understand what I need to do to solve the issue, the message is as follows: Building file: ../main.c > >gcc -O0 -Wall -c -fmessage-length=0 -omain.o ../main.c > >gcc: not found > >make: *** [main.o] Error 127 > >make: Target `all' not remade because of errors. > >Build complete for project temac_testapp > >Can anyone shed some light on this for me, I don't think that I have to do much to get things working, but nothing I have tried seems to help. (Go easy on me as I am just starting to use C/C++ and their compilers...simple programs...simple applications, so I'm not all that familiar with some of the terminology. > >I appreciate any assistance from anyone. > >Thanks, > >Jason The compiler for microblaze is called mb-gcc.exe, the compiler for power-pc is called powerpc-aebi-gcc-3.4.1.exe Regards, ZaraArticle: 114402
Hello, for a printing application I would like to receive data from a Unix workstation over Gigabit Ethernet (copper) at maximum speed. A first test showed us that today 2 workstations are able to interchange data over GB Ethernet with about 110 MB/s, nearly at the theoretical limits. The receiver should be implemented with an FPGA, put the data into DDR memory and process the data with the same FPGA. Looking at the Gigabit Reference Design from Xilinx I had the impression that it probably not so easy to go at the limits of the bandwith when the embedded PPC processor handles the protocol. A viable way seems eventually to implement some UDP acceleration, where UDP would also fit the data better, since the data to receive is always made up of packets (lines) ot the same length. Does anybody have some experience with receiving data at high data rates? Thank you very much for every hint. Best regards Klaus Falser R&D Electronics Department Company : Durst Phototechnik AG Vittorio Veneto Str. 59 I-39042 Brixen Voice : +0472/810235 : +0472/810111 FAX : +0472/830980 Email : kfalser@durst.itArticle: 114403
On 2007-01-15, Klaus Falser <kfalser@IHATESPAMdurst.it> wrote: > Looking at the Gigabit Reference Design from Xilinx I had the impression > that it probably not so easy to go at the limits of the bandwith when > the embedded PPC processor handles the protocol. If you use UDP without checksums (they're optional in IPv4 for UDP) then the PPC overhead will be proportional to number of packets (not total data) so if you use a DMA MAC core and jumbo frames you might do fine with a standard network stack. Jumbo frames should be an option if you control the whole network. If you don't, don't expect to get anything like the theoretical maximum out of GigE! -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 114404
In article <slrneqmfua.2a65.ben@saturn.home.ben.com>, ben@ben.com says... > On 2007-01-15, Klaus Falser <kfalser@IHATESPAMdurst.it> wrote: > > Looking at the Gigabit Reference Design from Xilinx I had the impression > > that it probably not so easy to go at the limits of the bandwith when > > the embedded PPC processor handles the protocol. > > If you use UDP without checksums (they're optional in IPv4 for UDP) then > the PPC overhead will be proportional to number of packets (not total data) > so if you use a DMA MAC core and jumbo frames you might do fine with a > standard network stack. Jumbo frames should be an option if you control > the whole network. If you don't, don't expect to get anything like the > theoretical maximum out of GigE! > > The problem with jumbo frames may be the Ethernet switch. I'm not shure if they are supported, but I could check it. Thanks KlausArticle: 114405
Hi > Does anybody have some experience with receiving data at high data > rates? > Thank you very much for every hint. I have an application here that streams from a PC to a FX60 at 250Mbps. We only use 250 because our application doesn't need more but streaming tests showed we can go a lot higher (>800MBps but we read data from a hdd so this could be the bottleneck). We're using the Virtex4 embedded MAC and it's connected directly to a hw state machine that handles the protocol on the fly and stores data payload in a FIFO. Another state machine reads from that fifo to a DDR2 bank. When the FIFO becomes almost full, we send "PAUSE" frames on the ethernet link so the PC stops sending. Since PAUSE frames are handled by the hardware of the network card, the data flow stops almost always at the next packet (some time 1 packet later), but you should just dimension your FIFO and it's afull threshold to handle that. With this we are sure we didn't loose any packets and we don't need to handle retransmission or whatever. SylvainArticle: 114406
Hi Clark, Thanks for the reply. I did contact the Xilinx guys on this as well, and they confirmed that EDK does support 16-bit DDR memory Controller for the PLB. Do you have any links which can get me going with Linux 2.6.x porting onto PPC quickly? Monta Vista is not my requirement at the moment. Do reply........... Thanks Farhan cpope wrote: > <sheikh.m.farhan@gmail.com> wrote in message > news:1168595277.938053.28500@a75g2000cwd.googlegroups.com... > > Hi, > > I need to know is it possible to have a 16-bit PLB DDR memory > > controller in EDK 8.x for a custom made board. So far what I have seen > > is EDK supports 32 and 64-bits PLB DDR controller for third party base > > systems. > > Has anyone tried to port Linux 2.4.x successfully on PPC running on > > Virtex 4? Any issues....... > > > > Farhan > > > > I'm pretty sure that a 16-bit DDR interface has to go on OPB, PLB won't > support it. > > I have Linux 2.6 running on my V4 right now. Linux is the easy part. Getting > all you peripherals and drivers work is the time consuming part. > > If you want a pre-rolled solution see Monta Vista. But there are plenty of > do it yourself info on the web. > > -ClarkArticle: 114407
Can anyone tell me some example to implement an ethernet comunication between PC and FPGA?. I have a .NET app for transmit UDP packets and I want the Spartan 3e to receive it but I don't know how can I do it?. I have probed LWIP, XILNET but I have no idea. I only want an easy example to receive and transmit. ThanksArticle: 114408
> >Does anyone out there use SDK version 8.2? I recently migrated from 8.1 where I never had an issue compiling small pieces of test code. Now however things that used to work do not. I have scoured through the Google searches and the Xilinx website to no luck. The error message that I get is very vague, and I do not quite understand what I need to do to solve the issue, the message is as follows: Building file: ../main.c > > > >gcc -O0 -Wall -c -fmessage-length=0 -omain.o ../main.c > > > >gcc: not found > > > >make: *** [main.o] Error 127 > > > >make: Target `all' not remade because of errors. > > > >Build complete for project temac_testapp > > > >Can anyone shed some light on this for me, I don't think that I have to do much to get things working, but nothing I have tried seems to help. (Go easy on me as I am just starting to use C/C++ and their compilers...simple programs...simple applications, so I'm not all that familiar with some of the terminology. > > > >I appreciate any assistance from anyone. > > > >Thanks, > > > >Jason > > > The compiler for microblaze is called mb-gcc.exe, the compiler for > power-pc is called powerpc-aebi-gcc-3.4.1.exe Yes, the question is why EDK suddenly starts to use gcc instead of the other two. It seems to come and go. Cheers, JonArticle: 114409
Hi guys,
I am realy a newbee in the world of linux..Now i want to
shift my whole work into linux environment..I installed Mandriva
2006..And i have the evaluation DVD of xilinx ise8.2..But i dont know
how to install..Plz someone help me out with as much detail as
possible..i can't find any tar or tar.gz files in the DVD..there is a
folder platform/lin64 but i didn't find any proper file using which i
can install it..
subin
Article: 114410Google linux install ise site:xilinx.comArticle: 114411
Hello, I have a problem Routing a design in Xilinx ISE 8.2. I found a failure caused by a multiplexer where the Select signal arrives slightly after one of the input signals changed. This causes a narrow pulse in the output data line of the multiplexer. When this pulse arrives to the next register, the setup time is ok, but it suddenly falls violating the hold time. This problem does not appear in post-map simulations, so I guess it is exclusively due to some skew between Select and Input lines, introduced at the routing stage. I don't understand why the router allows this to happen. It would be easy to check routes and throw warnings when an Input data path is longer than the Select path. However, the static timing analysis is ok at all stages, no constraints violations. Does anyone know how can I solve this issue? I'm sure many people fought with this before... Thanks in advance.Article: 114412
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message news:fkgkq2tq92j1ge7rtrj877laehcru2vp9g@4ax.com... > On Sun, 14 Jan 2007 14:26:57 -0000, "Icky Thwacket" > <it@it.it> wrote: > > > So... in almost any realistic situation, the cross-coupled SR latch > is either unnecessary or undesirable. It is an example of an > asynchronous state machine - admittedly a fairly simple example, > and one that's relatively easy to get right - and, like all > asynchronous state machines, it requires special techniques > to use it properly and to avoid tools making unacceptable > optimisations to it. > > Flame away, I'm sure there are some interesting contrary > points of view! > -- > Jonathan Bromley, Consultant > Hi Jonathan, What about a 4046 type two PLL phase comparator? http://direct.xilinx.com/bvdocs/appnotes/xapp028.pdf Actually, this is better inplemented as two FFs*, one clocked by the VCO, one by the Reference frequency, but I still claim it's a 'realistic situation'! :-) Cheers, Symon. * http://www.odyseus.nildram.co.uk/Systems_And_Devices_Files/Basic_PLL.pdf look at fig.2.Article: 114413
Just one correction over previous post: the Select signal arrives slightly BEFORE the Input signal changes, and not after as I said. Regards.Article: 114414
Pretty much just google linux + xilinx, but here's one site: http://splish.ee.byu.edu/projects/LinuxFPGA/configuring.htm -Clark <sheikh.m.farhan@gmail.com> wrote in message news:1168859264.576151.285210@51g2000cwl.googlegroups.com... > Hi Clark, > Thanks for the reply. I did contact the Xilinx guys on this as well, > and they confirmed that EDK does support 16-bit DDR memory Controller > for the PLB. > Do you have any links which can get me going with Linux 2.6.x porting > onto PPC quickly? Monta Vista is not my requirement at the moment. > > Do reply........... > > Thanks > Farhan > > cpope wrote: > > <sheikh.m.farhan@gmail.com> wrote in message > > news:1168595277.938053.28500@a75g2000cwd.googlegroups.com... > > > Hi, > > > I need to know is it possible to have a 16-bit PLB DDR memory > > > controller in EDK 8.x for a custom made board. So far what I have seen > > > is EDK supports 32 and 64-bits PLB DDR controller for third party base > > > systems. > > > Has anyone tried to port Linux 2.4.x successfully on PPC running on > > > Virtex 4? Any issues....... > > > > > > Farhan > > > > > > > I'm pretty sure that a 16-bit DDR interface has to go on OPB, PLB won't > > support it. > > > > I have Linux 2.6 running on my V4 right now. Linux is the easy part. Getting > > all you peripherals and drivers work is the time consuming part. > > > > If you want a pre-rolled solution see Monta Vista. But there are plenty of > > do it yourself info on the web. > > > > -Clark >Article: 114415
Frai wrote:
> It would be
> easy to check routes and throw warnings when an Input data path is
> longer than the Select path. However, the static timing analysis is ok
> at all stages, no constraints violations.
Static timing verifies that each max delay from Q to D
is less than 1/Fmax. It knows nothing of your intentions.
I work that part out with Modelsim.
Maybe the design is not synchronous, or
if it is, the mux path is not set up at least
one tick before the input change.
-- Mike Treseler
Article: 114416Has anyone use the PLB DDR controller for the PowerPC in the EDK 7.1? I have implented it in my design and it takes 150 clock counts for the PowerPC to read or write data in the DDR memory. I think its too slow!Article: 114417
Hi all! ISE 9.1i is finally out! I read the marketing papers but didn't find any word about partial reconfiguration support. MehdiArticle: 114418
You can also initialize manually the BRAM memory. Use the Language Templates through the ISE to see the way!Article: 114419
Thanks Peter. After some research this weekend, I saw that the Switching Characteristics Data Sheet for V4 had been updated in Dec. So I got that and it explained a little bit more about the IDELAY. More importantly, it referenced a document that detailed the ChipSync technology -- XAPP707. As an aside, this document does NOT show up on a search for "IDELAY" on the Xilinx web site. Several other XAPP70X docs do, but not this 707. This is annoying in its own right. I digress.... This is a quote from the latest update of the V4 User Guide: "IDELAY is a 64-tap wrap-around delay element with a fixed, guaranteed tap resolution (see Virtex-4 Data Sheet)." You mean 'see' the Switching Guide? If so, there is an equation that will give you the delay value for a given tap used. It includes +/- error as well. So really the description in the User Guide is misleading. The taps are certainly NOT guaranteed to be a fixed resolution. The whole chain is guaranteed fixed, but not individual taps. In fact, according to XAPP707 there can be some pretty wide swings examing one tap at a time. So maybe the User Guide shouldn't put such a description. Maybe it should reference the XAPP707 document as well. I will be smarter from now on and look for the data sheet updates and follow their trail for information. No big deal. I just find it frustrating sometimes to find information on non-trivial portions of some of Xilinx technology. If anyone ever posts here about IDELAY, and I see it and it's applicable, I will first reference them to the 707 document. It is full of great information that can be used to evaluate the IDELAY and whether or not it would work for a particular apllication. I now see that I need to do more characterization on my design. I CANNOT rely on the IDEALY tap resolution...at least not the way I was. But it would have been nice to know this from the get go. Don't get me wrong, I take responsibility for not scouring the documentation. BUT, it just seems like the information I found on Xilinx' web site concerning IDELAY was at times inaccurate, sometimes misleading, not 'simple' to find, lacking detail, etc. It kinda sucks to have to have at least 3 documents to fully capture one feature of the FPGA. Just my 2 cents....Article: 114420
Hello all, I would like to know if there are benchmarks available for testing vhdl codes. I need TCP/IP packets input to test the design. Thanks, -DArticle: 114421
Hi, By "Style A can be rewritten to Style B", I just mean "A is something equal to B", I do not want to change the existing A to B. When starting coding, maybe style B is sometimes easier to be thought. Thanks.Article: 114422
El-Mehdi Taileb wrote: > Hi all! > ISE 9.1i is finally out! > I read the marketing papers but didn't find any word about partial > reconfiguration support. They also talk about some kind of source-code control "feature" -- "Source Code Control Capabilities: Allows users to quickly and easily identify the files associated with a known version of their design. They can then export the source files and scripts needed to regenerate the project with the same sources and settings." Rather than reinvent the wheel, why don't they just make their tools friendlier to use with existing SCC systems (Subversion, Perforce, Bitkeeper, whatever)? -aArticle: 114423
hi, where can i find a description of the edif format. www.edif.org doesn't have the syntax regards, quadArticle: 114424
Klaus Falser wrote: > Hello, > for a printing application I would like to receive data from a Unix > workstation over Gigabit Ethernet (copper) at maximum speed. > A first test showed us that today 2 workstations are able to interchange > data over GB Ethernet with about 110 MB/s, nearly at the theoretical > limits. > The receiver should be implemented with an FPGA, put the data into DDR > memory and process the data with the same FPGA. > > Looking at the Gigabit Reference Design from Xilinx I had the impression > that it probably not so easy to go at the limits of the bandwith when > the embedded PPC processor handles the protocol. > A viable way seems eventually to implement some UDP acceleration, where > UDP would also fit the data better, since the data to receive is always > made up of packets (lines) ot the same length. > > Does anybody have some experience with receiving data at high data > rates? > Thank you very much for every hint. > > Best regards > Klaus Falser > > R&D Electronics Department > Company : Durst Phototechnik AG > Vittorio Veneto Str. 59 > I-39042 Brixen > Voice : +0472/810235 > : +0472/810111 > FAX : +0472/830980 > Email : kfalser@durst.it We built a UDP off load engine for a custom data streaming protocol using a PicoBlaze processor on a V4FX, and that worked great for us. It makes a copy of the header as the packet is moved from the EMAC to a fifo, and then has the PicoBlaze inspect the header. If it is packet from the stream we want to offload from the PPC, the PicoBlaze sets up the DMA engine to send it to a circular buffer. If it was anything else, it is just passed on to the PPC and the Linux IP stack deals with it. This protocol has 1 KB of data and a small header wrapped in UDP, so we are not using jumbo frames, and the PicoBlaze still has plenty of processing power to decide what to do with one packet before the next shows up. We are getting just a bit under 100MB/s. We do not use the PicoBlaze to calculate any checksums. You can either ignore them, or add some hardware to calculate them. The EMAC checks the Ethernet checksum for you. The PicoBlaze is an absolute gem. We have done many neat things with it. Regards, John McCaskill www.fastertechnology.com
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