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
I am a student of Electronics and I am going to do semester work on the topic "Implementation of Graphical User Interfaces on an Embedded Platform". We are allowed to choose a project of our own so this is why I am currently looking for suitable project ideas. The work shall be implemented on a Xilinx Spartan-3A/3AN Starter Kit Board, making use of the Microblaze CPU. As most important features the board brings a Spartan-3A FPGA, a 50 MHz crystal oscillator, 32Mx16 DDR2 SDRAM, 32 Mbit parallel Flash, a RS-232 serial port, PS/2-style mouse/keyboard port, a VGA video output port and some push-buttons and switches. I am not looking for an already finished solution to but I want to work it out for myself. And first of all I want to learn some more things about Microblaze programming on FPGA. The project must fit in the above mentioned topic so if someone did something similar or has ideas how to combine the GUI topic with FPGA Hardware / Software Co-Design then please send me details of this. Thanks in advance. Any ideas on this subject are really appreciated. SimonArticle: 147901
On Jun 1, 3:46=A0am, "Simon Piekert" <currypie...@arcor.de> wrote: > I am a student of Electronics and I am going to do semester work on the > topic "Implementation of Graphical User Interfaces on an Embedded Platfor= m". > We are allowed to choose a project of our own so this is why I am current= ly > looking for suitable project ideas. The work shall be implemented on a > Xilinx Spartan-3A/3AN Starter Kit Board, making use of the Microblaze CPU= . > > As most important features the board brings a Spartan-3A FPGA, a 50 MHz > crystal oscillator, 32Mx16 DDR2 SDRAM, 32 Mbit parallel Flash, a RS-232 > serial port, PS/2-style mouse/keyboard port, a VGA video output port and > some push-buttons and switches. > > I am not looking for an already finished solution to but I want to work i= t > out for myself. And first of all I want to learn some more things about > Microblaze programming on FPGA. The project must fit in the above mention= ed > topic so if someone did something similar or has ideas how to combine the > GUI topic with FPGA Hardware / Software Co-Design then please send me > details of this. > > Thanks in advance. Any ideas on this subject are really appreciated. > > Simon Keep in mind that most low-cost development boards have low- functionality VGA ports. You can have red green and blue each completely on or completely off, no 256 shades of gray per channel. You can get several colors out of this but it's not much for a GUI.Article: 147902
You're still concerned about this? Maybe you don't yet understand the issues from how Gabor explained the situation. FPGAs have flexible routing resources able to implement generic logic interconnects. The placement and routing of logic will determine explicitly how fast the FPGA can possibly run. The earliest days of FPGA place & route may have seen a stronger attempt at getting "best times" but runtimes were miserable and results were often short of complete. A competing tool adopted a "just enough" approach to place & route, coming up with solutions which meet "at least" the constraints given to the tools. The quality of results improved significantly and Xilinx eventually bought the technology. The "just enough" philosophy results in placements and routes that meet the constraints given to the tool but do not strive to improve upon those numbers. If the clock period is such that the registers feeding the BlockRAM don't need to have the minimum achievable delays, they typically won't. If you expect to have small setup and hold times from I/O pins to the BlockRAM, there's a fundamental disconnect: the setup and hold times are "internal times" for the FPGA and do not include the system level implementation of the I/O pins and global clock buffers. If implementing with I/O pins, the tools will try their best to meet the setup and hold constraints the user provides but no better and will often adjust the input delays of the various pins (including the clock) to help attain those numbers. Understanding the timing models means getting to know the chip better at the silicon level. If you understand I/O, clocking, CLBs, and routing, you're well on your way to interpreting timing results properly. Being able to take the internal timing numbers for an FPGA and apply those before you design takes a higher level of undestanding often acquired from reading the FPGA user guide, app notes, and running through timing analysis with the timing details turned on in the logic path analysis. The tool tries to give the user what's needed, not what's "best." Even then there are limits based on what *can* be implemented within the constraints of placement and routing.Article: 147903
On Jun 1, 12:06=A0am, Sharath Raju <brshar...@gmail.com> wrote: > On May 29, 1:16=A0am, Sharath Raju <brshar...@gmail.com> wrote: > > > > > > > On May 28, 7:05=A0pm, Gabor <ga...@alacron.com> wrote: > > > > On May 28, 9:47=A0am, Sharath Raju <brshar...@gmail.com> wrote: > > > > > I am afraid I forgot to include the code in the previous email: > > > > > DBR : Core512 port map ( > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 -- Ram A > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ena =3D> ENA, > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enb =3D> ENA, > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wea =3D> WE, > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 web =3D> WE, > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssra =3D> SSR, > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssrb =3D> SSR, > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clka =3D> CLOCK, > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clkb =3D> CLOCK, > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addra =3D> addr_1, > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addrb =3D> addr_2, > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 douta =3D> DOUT(71 = downto 36), > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 doutb =3D> DOUT(35 = downto 0), > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dina =3D> DIN(71 do= wnto 36), > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dinb =3D> DIN(35 do= wnto 0) > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ); > > > > > -- Address Declaration > > > > addr_1 <=3D '0' & ADDR(7 downto 0); > > > > addr_2 <=3D '1' & ADDR(7 downto 0); > > > > > The code isn't much. Essentially, I am trying to pretend to have a = 256 > > > > locations X 72 bits deep memory, whereas the BLOCK RAM is physicall= y a > > > > 512 locations X 36 bits wide. > > > > > On May 28, 6:31=A0pm, Sharath Raju <brshar...@gmail.com> wrote: > > > > > > Hello, > > > > > > We are working on a project which involves using BLOCK RAMs. Sinc= e we > > > > > were new to Block RAMs, I (my colleague actually) instantiated a = BLOCK > > > > > RAM in VHDL using Xilinx's Block RAM IP core. > > > > > > The question is regarding timing: > > > > > > The datasheet for the target Spartan 3ADSP XC3SD1800-4 device > > > > > specifies the best case (setup + hold) time to be less than 1 ns,= and > > > > > the maximum frequency of operation to be 280 MHz. Worst case figu= res > > > > > are not specified. > > > > > > =A0However, we checked the static timing report and found the set= up > > > > > times for the data, address and control signals to be approximate= ly 4 > > > > > ns. > > > > > > Why is there such a substantial difference ? > > > > The static timing report includes clock to output delays > > > of the driver as well as routing delays in addition to > > > the actual Tsu of the RAM itself. =A0This should be broken > > > into individual parts and well described in the timing > > > report. =A0Generally speaking, you should always assume > > > that routing delays will constitute a significant > > > portion of your timing budget for any path. =A0According > > > to Xilinx, the tools target 60% / 40% as a goal for > > > logic delay / routing delay. > > > > HTH, > > > Gabor > > > Thanks gabor .. shall check the static timing report in more detail > > for the routing and clock to out delays. > > I checked the timing report..It explicitly mentions the setup time to > be about 4ns. > > Here is a section of the report: > > Data Sheet report: > ----------------- > All values displayed in nanoseconds (ns) > > Setup/Hold to clock CLOCK > ------------+------------+------------+------------------+--------+ > =A0 =A0 =A0 =A0 =A0 =A0 | =A0Setup to =A0| =A0Hold to =A0 | =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0| Clock =A0| > Source =A0 =A0 =A0| clk (edge) | clk (edge) |Internal Clock(s) | Phase = =A0| > ------------+------------+------------+------------------+--------+ > ADDR<0> =A0 =A0 | =A0 =A00.792(R)| =A0 =A00.598(R)|CLOCK_BUFGP =A0 =A0 = =A0 | =A0 0.000| > ADDR<1> =A0 =A0 | =A0 =A01.335(R)| =A0 =A00.164(R)|CLOCK_BUFGP =A0 =A0 = =A0 | =A0 0.000| > ADDR<2> =A0 =A0 | =A0 =A00.574(R)| =A0 =A00.773(R)|CLOCK_BUFGP =A0 =A0 = =A0 | =A0 0.000| > ADDR<3> =A0 =A0 | =A0 =A01.590(R)| =A0 -0.040(R)|CLOCK_BUFGP =A0 =A0 =A0 = | =A0 0.000| > ADDR<4> =A0 =A0 | =A0 =A00.729(R)| =A0 =A00.648(R)|CLOCK_BUFGP =A0 =A0 = =A0 | =A0 0.000| > ADDR<5> =A0 =A0 | =A0 =A02.400(R)| =A0 -0.688(R)|CLOCK_BUFGP =A0 =A0 =A0 = | =A0 0.000| > ADDR<6> =A0 =A0 | =A0 =A02.837(R)| =A0 -1.037(R)|CLOCK_BUFGP =A0 =A0 =A0 = | =A0 0.000| > ADDR<7> =A0 =A0 | =A0 =A03.441(R)| =A0 -1.521(R)|CLOCK_BUFGP =A0 =A0 =A0 = | =A0 0.000| > > The complete report can be accessed here:http://sites.google.com/site/brs= harath/DBR.twr?attredirects=3D0&d=3D1 > and here is the source:http://sites.google.com/site/brsharath/512x36.vhd?= attredirects=3D0&d=3D1- Hide quoted text - > > - Show quoted text - This report is for external IO (your ADDR<*> ports) timing relative to an external clock (CLOCK_BUFGP). These paths are variable depending on where the IOs are placed, where the BlockRAM are placed and the net delays between the two. These paths are not the same as the data sheet values for the BlockRAM that specify the internal component timing. Ed McGettigan -- Xilinx Inc.Article: 147904
On 5/29/2010 5:22 PM, Symon wrote: > On 5/29/2010 9:57 AM, Michael Kellett wrote: >> "Symon"<symon_brewer@hotmail.com> wrote in message >> news:htpkq7$435$1@news.eternal-september.org... >>> You can't meet the SI requirements of modern sub-ns rise time silicon's >>> I/O in 'easy to solder' packages. It's because of the loop area. >>> >>> BGAs "are harder to probe" made me laugh! I bet you still have a logic >>> analyser! >>> >>> One way to prevent yourself becoming an extinct dinosaur is to splash >>> the >>> cash on some decent stimulation tools. Your competitors have. >>> >>> Syms. >> Lighten up Syms ! >> >> For serious work with hardware I need a logic analyser and a scope !! (if >> you can suggest a "stimulation tool" substitute I'm listening). >> >> I'm totally with Rick on this one - TQFP easy to hand solder, easy to >> probe, >> check, modify etc. >> Most of my designs are one or two off, weirdo interfaces for >> production line >> test systems - the largest production run I've ever done with an FPGA was >> about 100 off. >> >> I can see the appeal of BGA for mass production but I'm convinced that >> TQFP >> is cheaper to prototype in low pin counts. A serious FPGA (>20K LUT) >> in 100 >> pin TQFP would be very nice. >> But I accept that the number I might buy wouldn't make the supplier very >> rich. >> >> Michael Kellett >> > Hi Michael, > > Lighten up? About FPGA design? OK, I'll try! Anyway, it made me laugh, > how light do you want? And then you talk about serious work. Talk about > bringing the mood down! :-) > > Anyway, I have a 'scope too. I use it a fair bit, but not as much as > LTSpice. I don't have a logic analyser. I have used Chipscope as a last > resort, but a simulator like ModelSIM is my preferred tool for catching > logic bugs. My spectrum analyser is far more useful than a logic > analyser could be. > > Here's the skinny. You're correct that TQFPs are easier to hand solder > than BGAs. Also, they are easier to probe. That's just as well because > the SI of a TQFP because of the leads' loop area is poor enough that you > may well need to probe them. I would have thought that the kind of ATE > type equipment you are making needs to have good SI? When I design test > equipment, I would not even consider a leaded part. Especially as, in a > pinch, you can reflow a BGA with a toaster oven. > > Anyway, I don't know your specific circumstances, and I'm sure you have > excellent reasons for choosing the parts you do. I would just like to > point out that there are some jolly good incentives for ditching leaded > parts, and that some investment in decent simulation tools and a toaster > oven is the way forward! > > Cheers, Syms. > The logic analyzer's not because you don't understand what your FPGA is doing. The logic analyzer's because you don't understand what the complex ASSP your FPGA is hooked up to is doing, because the data sheet is both 800 pages long and woefully incomplete. And so you take your best guess at how it behaves, throw together a simulation model of it, and crank out your logic, but then you put it on the copper and use the LA to find out that you vastly misunderstood the bus interface because the translation from Japanese to English by way of Sanskrit wasn't clear. Simulate, but verify. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 147905
rickman wrote: > I would love to ditch the FPGA > and go 100% software, but there is one interface that makes that > impossible I think. The app configuration data (not FPGA > configuration) comes over a serial port that has timing requirements > for read that you can't meet with software. In the past I have found that more often than not, software can be very powerful when it's combined with a little bit of hardware. For example, a single 74-type gate chip can convert a micro without SPI interface into a working SPI slave. It requires 100% dedication of the software into the job, and dedicating a few I/O pins as well. Of course, wonders can't be done with these tricks. But you can get gate latency out of software loops, and possibly also reduce the software IO bandwidth. Post more about your specific problem (here or in comp.arch.embedded) if you think that there's not too much missing to reach the timing goal.Article: 147906
Rob Gaddi <rgaddi@technologyhighland.com> wrote: >On 5/29/2010 5:22 PM, Symon wrote: >> On 5/29/2010 9:57 AM, Michael Kellett wrote: >>> "Symon"<symon_brewer@hotmail.com> wrote in message >>> news:htpkq7$435$1@news.eternal-september.org... >>>> You can't meet the SI requirements of modern sub-ns rise time silicon's >>>> I/O in 'easy to solder' packages. It's because of the loop area. >>>> >>>> BGAs "are harder to probe" made me laugh! I bet you still have a logic >>>> analyser! >>> in 100 >>> pin TQFP would be very nice. >>> But I accept that the number I might buy wouldn't make the supplier very >>> rich. >>> >>> Michael Kellett >>> >> Hi Michael, >> >> Lighten up? About FPGA design? OK, I'll try! Anyway, it made me laugh, >> how light do you want? And then you talk about serious work. Talk about >> bringing the mood down! :-) >> >> Anyway, I have a 'scope too. I use it a fair bit, but not as much as >> LTSpice. I don't have a logic analyser. I have used Chipscope as a last >> resort, but a simulator like ModelSIM is my preferred tool for catching >> logic bugs. My spectrum analyser is far more useful than a logic >> analyser could be. >> >> Here's the skinny. You're correct that TQFPs are easier to hand solder >> than BGAs. Also, they are easier to probe. That's just as well because >> the SI of a TQFP because of the leads' loop area is poor enough that you >> >> Anyway, I don't know your specific circumstances, and I'm sure you have >> excellent reasons for choosing the parts you do. I would just like to >> point out that there are some jolly good incentives for ditching leaded >> parts, and that some investment in decent simulation tools and a toaster >> oven is the way forward! >> >> Cheers, Syms. >> > >The logic analyzer's not because you don't understand what your FPGA is >doing. The logic analyzer's because you don't understand what the >complex ASSP your FPGA is hooked up to is doing, because the data sheet >is both 800 pages long and woefully incomplete. And so you take your >best guess at how it behaves, throw together a simulation model of it, >and crank out your logic, but then you put it on the copper and use the >LA to find out that you vastly misunderstood the bus interface because >the translation from Japanese to English by way of Sanskrit wasn't clear. > >Simulate, but verify. My idea. Simulation doesn't catch mistakes and/or shortcomings in models. I do a lot of verification using a LA and many times I find potential problems even though the system (software + hardware) seems to be working fine. Besides, SI is not an issue for all designs. A TQFP package is OK for many mainstream applications. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 147907
maybe this is interesting for you http://www.genode-labs.com/produkte/fpga-graphics "Simon Piekert" <currypieker@arcor.de> schrieb im Newsbeitrag news:4c04bad5$0$6892$9b4e6d93@newsspool2.arcor-online.net... >I am a student of Electronics and I am going to do semester work on the >topic "Implementation of Graphical User Interfaces on an Embedded >Platform". We are allowed to choose a project of our own so this is why I >am currently looking for suitable project ideas. The work shall be >implemented on a Xilinx Spartan-3A/3AN Starter Kit Board, making use of the >Microblaze CPU. > > As most important features the board brings a Spartan-3A FPGA, a 50 MHz > crystal oscillator, 32Mx16 DDR2 SDRAM, 32 Mbit parallel Flash, a RS-232 > serial port, PS/2-style mouse/keyboard port, a VGA video output port and > some push-buttons and switches. > > I am not looking for an already finished solution to but I want to work it > out for myself. And first of all I want to learn some more things about > Microblaze programming on FPGA. The project must fit in the above > mentioned topic so if someone did something similar or has ideas how to > combine the GUI topic with FPGA Hardware / Software Co-Design then please > send me details of this. > > Thanks in advance. Any ideas on this subject are really appreciated. > > Simon > >Article: 147908
On 6/1/2010 4:58 PM, Rob Gaddi wrote: > > The logic analyzer's not because you don't understand what your FPGA is > doing. The logic analyzer's because you don't understand what the > complex ASSP your FPGA is hooked up to is doing, because the data sheet > is both 800 pages long and woefully incomplete. And so you take your > best guess at how it behaves, throw together a simulation model of it, > and crank out your logic, but then you put it on the copper and use the > LA to find out that you vastly misunderstood the bus interface because > the translation from Japanese to English by way of Sanskrit wasn't clear. > > Simulate, but verify. > Instead of using chipscope in an FPGA, you layout the board with a connector for your LA? You probe these signals, possibly differential, going at 100's of MHz, maybe GHz? Doesn't that mean that your SI is compromised by having to provide physical access to the signals, so you have more chance of failure? Crikey. Why doesn't borrowing a demo board from your ASSP vendor not solve your interface debugging problems? Cheers, Syms.Article: 147909
On Jun 1, 1:26 pm, Marc Jet <jetm...@hotmail.com> wrote: > rickman wrote: > > I would love to ditch the FPGA > > and go 100% software, but there is one interface that makes that > > impossible I think. The app configuration data (not FPGA > > configuration) comes over a serial port that has timing requirements > > for read that you can't meet with software. > > In the past I have found that more often than not, software can be > very powerful when it's combined with a little bit of hardware. > > For example, a single 74-type gate chip can convert a micro without > SPI interface into a working SPI slave. It requires 100% dedication > of the software into the job, and dedicating a few I/O pins as well. > > Of course, wonders can't be done with these tricks. But you can get > gate latency out of software loops, and possibly also reduce the > software IO bandwidth. > > Post more about your specific problem (here or in comp.arch.embedded) > if you think that there's not too much missing to reach the timing > goal. Sure, I don't mind sharing. I am pretty sure I've explored the solution space though. This interface has two parallel data bits as input which are used for data and address. There is a separate single output for data output. A strobe provides the clock and a command signal indicates the last clock of the transaction into the peripheral. The transaction consists of N 2 bit "chunks" of data followed by M 2 bit "chunks" of address and a single "chunk" of command. During the command "chunk" the two data bits indicate if the transaction is a read or a write. After the command "chunk" all following strobes clock read data out on the output bit, both for reads and writes. A read transaction does not require the data phase. The number of "chunks" used for the address for a write is implied by the peripheral. The timing problem is that the data in is on the rising edge and the data out is also on the rising edge with the master accepting on the falling edge. The first output bit is actually during the command cycle. So the first output bit has to be presented in less than a clock cycle from the command flag being asserted and less than 30 ns from the rising edge of the clock in the command "chunk". In the FPGA I use the address to drive a mux to select the data for read and output the lsb directly because of the short timing. The rest of the addressed register is loaded into an output register to be shifted out. The software would have about 100 ns from the last address "chunk" being clocked, 60 ns from the command flag going high and much less than 30 ns from the command being clocked to driving the first output bit. I doubt it can be done at 62.5 MIPs. RickArticle: 147910
On Jun 2, 7:25=A0am, rickman <gnu...@gmail.com> wrote: > > The software would have about 100 ns from the last address "chunk" > being clocked, 60 ns from the command flag going high and much less > than 30 ns from the command being clocked to driving the first output > bit. =A0I doubt it can be done at 62.5 MIPs. What's the data rate ? We have done a number of systems, where a smallish CPLD takes the ns- level stuff, and dual-edge etc and converts it into a more micro- compatible form. Sometimes that has been parallel, and sometimes SPI/SSC -jgArticle: 147911
On 6/1/2010 6:20 AM, John_H wrote: > On Jun 1, 3:46 am, "Simon Piekert"<currypie...@arcor.de> wrote: >> I am a student of Electronics and I am going to do semester work on the >> topic "Implementation of Graphical User Interfaces on an Embedded Platform". >> We are allowed to choose a project of our own so this is why I am currently >> looking for suitable project ideas. The work shall be implemented on a >> Xilinx Spartan-3A/3AN Starter Kit Board, making use of the Microblaze CPU. >> >> As most important features the board brings a Spartan-3A FPGA, a 50 MHz >> crystal oscillator, 32Mx16 DDR2 SDRAM, 32 Mbit parallel Flash, a RS-232 >> serial port, PS/2-style mouse/keyboard port, a VGA video output port and >> some push-buttons and switches. >> >> I am not looking for an already finished solution to but I want to work it >> out for myself. And first of all I want to learn some more things about >> Microblaze programming on FPGA. The project must fit in the above mentioned >> topic so if someone did something similar or has ideas how to combine the >> GUI topic with FPGA Hardware / Software Co-Design then please send me >> details of this. >> >> Thanks in advance. Any ideas on this subject are really appreciated. >> >> Simon > > Keep in mind that most low-cost development boards have low- > functionality VGA ports. You can have red green and blue each > completely on or completely off, no 256 shades of gray per channel. > You can get several colors out of this but it's not much for a GUI. Looks to me like the "Xilinx Spartan-3A/3AN Starter Kit Board" has simple four bit resistor DAC for each color, which is to say sixteen shades for each of R, G, B or 4096 possible colors. Not amazing, but probably adequate for a student's GUI project.Article: 147912
On 1 Jun., 09:46, "Simon Piekert" <currypie...@arcor.de> wrote: > I am a student of Electronics and I am going to do semester work on the > topic "Implementation of Graphical User Interfaces on an Embedded Platform". > We are allowed to choose a project of our own so this is why I am currently > looking for suitable project ideas. The work shall be implemented on a > Xilinx Spartan-3A/3AN Starter Kit Board, making use of the Microblaze CPU. > > As most important features the board brings a Spartan-3A FPGA, a 50 MHz > crystal oscillator, 32Mx16 DDR2 SDRAM, 32 Mbit parallel Flash, a RS-232 > serial port, PS/2-style mouse/keyboard port, a VGA video output port and > some push-buttons and switches. > > I am not looking for an already finished solution to but I want to work it > out for myself. And first of all I want to learn some more things about > Microblaze programming on FPGA. The project must fit in the above mentioned > topic so if someone did something similar or has ideas how to combine the > GUI topic with FPGA Hardware / Software Co-Design then please send me > details of this. > > Thanks in advance. Any ideas on this subject are really appreciated. > > Simon Hi Simon, are you intending to use the VGA interface at all? (for embeded systems, not all LCDs provide VGA input and over the net it's totally irrelevant (e.g. X11)) As for a starting point you might consider this: http://www.petalogix.com/resources/documentation/petalinux/userguide/ReferenceDesigns/XilinxBoards There once was a downloadable version, ready to use with sources etc. I'm not sure if this is still available. But since it's linux there must be sources available. Have a nice synthesis EilertArticle: 147913
Hi Simon, the mentioned link is for the Spartan 3E Starter kit. I missed that you are using the S3A/AN Starter kit. Sorry. Have a nice synthesis EilertArticle: 147914
Simon Piekert wrote: > I am a student of Electronics and I am going to do semester work on > the topic "Implementation of Graphical User Interfaces on an Embedded > Platform". We are allowed to choose a project of our own so this is > why I am currently looking for suitable project ideas. The work shall > be implemented on a Xilinx Spartan-3A/3AN Starter Kit Board, making > use of the Microblaze CPU. > As most important features the board brings a Spartan-3A FPGA, a 50 > MHz crystal oscillator, 32Mx16 DDR2 SDRAM, 32 Mbit parallel Flash, a > RS-232 serial port, PS/2-style mouse/keyboard port, a VGA video > output port and some push-buttons and switches. > > I am not looking for an already finished solution to but I want to > work it out for myself. And first of all I want to learn some more > things about Microblaze programming on FPGA. The project must fit in > the above mentioned topic so if someone did something similar or has > ideas how to combine the GUI topic with FPGA Hardware / Software > Co-Design then please send me details of this. > > Thanks in advance. Any ideas on this subject are really appreciated. > > Simon How about implementing a game around the GUI system, like chess or something? I implemented Tom Kerrigan's TSCP Chess on a Spartan 3 pretty easily: http://www.alternatezone.com/images/NanoChess.jpg (it evetually had graphic pieces and nicer buttons) http://www.tckerrigan.com/Chess/TSCP Just an idea. Dave. -- ================================================ Check out my Electronics Engineering Video Blog & Podcast: http://www.eevblog.comArticle: 147915
In comp.arch.fpga David L. Jones <altzone@gmail.com> wrote: ... > How about implementing a game around the GUI system, like chess or > something? > I implemented Tom Kerrigan's TSCP Chess on a Spartan 3 pretty easily: > http://www.alternatezone.com/images/NanoChess.jpg > (it evetually had graphic pieces and nicer buttons) > http://www.tckerrigan.com/Chess/TSCP > Just an idea. http://www.fpgaarcade.com/ -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 147916
Sym, You write without knowing anything about me. I have a very high rate of success on the board because of the extensive simulations I run. But you can never eliminate the need to probe real hardware. As to the SI issues, sure, you can get very high speed signals out of an FPGA. You can also drive static signals and everything in between. Many of my designs work very well in QFP packages and have no need for special SI approaches. When I am running a 32 MHz clock, 1 ns edge rates are not needed, so I slow them down to help prevent SI problems. Oh, yeah, I "do* have a logic analyzer and it comes in very useful. I was able to use it recently to find a configuration problem where my customer had missed an aspect of how to properly initialize the digital PLL used in the FPGA. No amount of simulation would have caught that! RickArticle: 147917
On Jun 1, 9:11=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Jun 2, 7:25=A0am, rickman <gnu...@gmail.com> wrote: > > > > > The software would have about 100 ns from the last address "chunk" > > being clocked, 60 ns from the command flag going high and much less > > than 30 ns from the command being clocked to driving the first output > > bit. =A0I doubt it can be done at 62.5 MIPs. > > What's the data rate ? > > We have done a number of systems, where a smallish CPLD takes the ns- > level stuff, and dual-edge etc and converts it into a more micro- > compatible form. > > Sometimes that has been parallel, and sometimes SPI/SSC The strobe the clocks the data is 33 ns high and 67 ns low. So the clock rate is 10 MHz with two data/addr bit input or 1 data bit output on each strobe. The problem with using a small CPLD is that the register set is up to 32, 8-bit registers. With a 100 ns address to output time, there is little chance of the read being done unless a copy of all registers exists in the CPLD. Also, some of the bits to be read are real time status bits. If the processor can get an interrupt, read the address and write the readback data to the CPLD, then it could work, but it has to happen in 100 ns. If they had just used a standard SPI interface it would have been a lot easier... RickArticle: 147918
The description is somewhat vague about the timing. From what I understand, the main problem is the short response latency. In fact the problem sounds very much like a job for a small CPLD. Your micro runs at 62.5 MIPS (16ns instruction cycle)? If it's a fast small micro with no pipeline, then that's a good start. Given that the protocol samples on the falling edge, does it offer you valid inputs already at the falling edge too? If so, then you seem to have <130ns from when the LSB of address is known to data out. And you seem to have <190ns from when ADR<MSB to 2> is known. 190ns would be 11 instructions, which looks okay. In a 74xx type solution, I'd dedicate 4 micro outputs to offer all 4 possible data bits to a 74 MUX which uses the 2 address LSBs to select the correct data bit. This relaxes the software latency constraint considerable. I'd store the "memory content" in an array indexed by ADR<MSB to 2> and store the 4 possible data LSBs in that byte (correctly ordered for the output port). Then the software loop has 11 instructions to assemble ADR<MSB to 2>, do the 1 byte lookup, and write it to the output port. This solves only one detail of the problem. Maybe it inspires you to find a solution for it all. Best regardsArticle: 147919
On Jun 2, 12:01=A0pm, Marc Jet <jetm...@hotmail.com> wrote: > The description is somewhat vague about the timing. =A0From what I > understand, the main problem is the short response latency. In fact > the problem sounds very much like a job for a small CPLD. > > Your micro runs at 62.5 MIPS (16ns instruction cycle)? =A0If it's a fast > small micro with no pipeline, then that's a good start. > > Given that the protocol samples on the falling edge, does it offer you > valid inputs already at the falling edge too? =A0If so, then you seem to > have <130ns from when the LSB of address is known to data out. =A0And > you seem to have <190ns from when ADR<MSB to 2> is known. =A0190ns would > be 11 instructions, which looks okay. > > In a 74xx type solution, I'd dedicate 4 micro outputs to offer all 4 > possible data bits to a 74 MUX which uses the 2 address LSBs to select > the correct data bit. =A0This relaxes the software latency constraint > considerable. =A0I'd store the "memory content" in an array indexed by > ADR<MSB to 2> and store the 4 possible data LSBs in that byte > (correctly ordered for the output port). =A0Then the software loop has > 11 instructions to assemble ADR<MSB to 2>, do the 1 byte lookup, and > write it to the output port. > > This solves only one detail of the problem. =A0 Maybe it inspires you to > find a solution for it all. > > Best regards Thanks for the advice. That's an interesting approach. There is a bit more to it than that, but it sounds potentially doable depending on the instructions required. The protocol was never intended for software, so no provision was made for the response time of software. In fact, register 0 only uses a 4 bit address while the others can be longer depending on the target. All this is pretty easy in hardware, but not so much in software. So this is not the only issue. The other issue is that the XMOS device is only an improvement over an FPGA in that it can include a lot more logic in a small package. The power consumption is higher if all eight threads are running. I don't know what happens to power if only some are idling. Since you can't slow the clock while any one thread has to run at high speed, I should think that would limit the power reduction you can achieve. RickArticle: 147920
Hello, I am a third year student, but interested in FPGAs and linking my future with this area of electronics. To have a point of view of my future, I've browsed some job search pages using "FPGA" in search field. However almost all of the offers are for "FPGA seniors", experience not less that ~5 years. How can I gain this experience if it is almost impossible to get employed? FPGA course in my uni is only on major degree studies, so I am doing a "self-education" and learning FPGA design by myself, however PACMAN implementation or something like that only gives experience on the syntax itself, but not the real problems encountered every day. I have some opinions: - Search for intern programs at various companies that use FPGAs (its also very hard to find, because many companies ask if You are eligible to work in USA. If not - chances are minimum (I am from Lithuania, EU)). - Try to find a job when you get paid by pay-per-module (however, I did not find anything like this). - The last chance I think I could do is to contact the company itself, ask for the ability to work for free, since I need experience and if everything goes OK, maybe they will employ me in the future. But how long the student could work qualitatively without being paid if the task is really hard and takes a long time? The result could end up with nothing: no experience and no work done. Tell me Your opinions :) --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147921
> >Can anyone confirm or dispute it the relative quality of Actel tools? >Am I mistaken about them? > >Rick > I've not used a wide range of FPGA tool suites, just the other major two, but I have found that Actel's, have been the worst yet. I don't do very large of complex designs, just stuff for single FPGAs, and don't really play with the complex features of the suite, so I can't comment on those areas (where they might actually impress). The silver lining is that they are in bed with Synplify/Synopsys so you get that for synthesis, but the pain starts with their layout backend tool. I run everything Ubuntu GNU/Linux, and prefer batch-mode to a GUI interface. This in itself is a fair challenge, you must export LD_LIBRARY_PATHs whenever you run any of their tools (not so bad, I guess.... but why the need?!) They're painful to use, too, in whenever you launch a tool, there's about 5 minutes of it sitting there doing nothing, as far as I can tell. This is really productive when all you need to do is check if changes to a PDC are OK. A place-and-route run always leaves my machine reeling for memory afterwards, it somehow manages to chew through a couple of gig of RAM and even make things start swapping. I'm convinced there's several memory holes, but don't have the will to run this behemoth in valgrind. Their tools take far longer than any other vendors for the same size design on a similar-sized FPGA, and then you have the issue of any net with fanout > ~10 resulting in large net delays, so their performance is always underwhelming. So on the whole I find using the Libero/Designer suite is never the highlight of my day. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147922
On Wed, 02 Jun 2010 14:23:11 -0500, "Socrates" <socconf@n_o_s_p_a_m.gmail.com> wrote: >Hello, >I am a third year student, but interested in FPGAs and linking my future >with this area of electronics. To have a point of view of my future, I've >browsed some job search pages using "FPGA" in search field. However almost >all of the offers are for "FPGA seniors", experience not less that ~5 >years. How can I gain this experience if it is almost impossible to get >employed? > >FPGA course in my uni is only on major degree studies, so I am doing a >"self-education" and learning FPGA design by myself, however PACMAN >implementation or something like that only gives experience on the syntax >itself, but not the real problems encountered every day. I have some >opinions: >- Search for intern programs at various companies that use FPGAs (its also >very hard to find, because many companies ask if You are eligible to work >in USA. If not - chances are minimum (I am from Lithuania, EU)). >- Try to find a job when you get paid by pay-per-module (however, I did not >find anything like this). >- The last chance I think I could do is to contact the company itself, ask >for the ability to work for free, since I need experience and if everything >goes OK, maybe they will employ me in the future. But how long the student >could work qualitatively without being paid if the task is really hard and >takes a long time? The result could end up with nothing: no experience and >no work done. > >Tell me Your opinions :) Get some development boards and actually build a few things. Over here, http://digilent.us/ and http://www.knjn.com/ are two sources, although I see that KNJN does have an EU outlet now, over at http://www.knjn.com/eu/ShopBoards_USB2.html At any rate, build a few real things and not just syntax exercises. Document some of the successes (and problems, with how you solved them!) on a blog that you could point potential employers to. As regards experience, yes employers would love to get somebody with a few years but those folks are not always available. If you enjoy "playing with" FPGAs enough that you work with them for the fun and the challenge then that may be enough to get an employer to take a look. Once you have done a few personal projects, go ahead and apply to some of those "5 years experience" positions. Be honest about what you've done and are doing; you're likely to get at least some positive responses. -- Rich Webb Norfolk, VAArticle: 147923
On Jun 3, 3:59=A0am, rickman <gnu...@gmail.com> wrote: > > The problem with using a small CPLD is that the register set is up to > 32, 8-bit registers. =A0With a 100 ns address to output time, there is > little chance of the read being done unless a copy of all registers > exists in the CPLD. =A0Also, some of the bits to be read are real time > status bits. =A0If the processor can get an interrupt, read the address > and write the readback data to the CPLD, then it could work, but it > has to happen in 100 ns. =A0If they had just used a standard SPI > interface it would have been a lot easier... If this interface is so incompatible with SPI that you need 32 bytes of local memory, then you are bumped into the 'smallest CPLD with RAM' territory, - and the choice there is not great. Maybe Actel or SiliconBlue ? I've hit this wall myself, and it raises a point: Rather than the uC+CPLD the marketing types are chasing, I would find a CPLD+RAM more useful, as there are LOTS of uC out there already, and if they can make 32KB SRAM for sub $1, they should be able to include it almost for free, in a medium CPLD. -jgArticle: 147924
On Jun 2, 5:29=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Jun 3, 3:59=A0am, rickman <gnu...@gmail.com> wrote: > > > > > The problem with using a small CPLD is that the register set is up to > > 32, 8-bit registers. =A0With a 100 ns address to output time, there is > > little chance of the read being done unless a copy of all registers > > exists in the CPLD. =A0Also, some of the bits to be read are real time > > status bits. =A0If the processor can get an interrupt, read the address > > and write the readback data to the CPLD, then it could work, but it > > has to happen in 100 ns. =A0If they had just used a standard SPI > > interface it would have been a lot easier... > > =A0If this interface is so incompatible with SPI that you need 32 bytes > of local memory, then you are bumped into the 'smallest CPLD with RAM' > territory, =A0- and the choice there is not great. Maybe Actel or > SiliconBlue ? > > I've hit this wall myself, and it raises a point: > > =A0Rather than the uC+CPLD the marketing types are chasing, I would find > a CPLD+RAM more useful, as there are LOTS of uC out there already, and > if they can make 32KB SRAM for sub $1, they should be able to include > it almost for free, in a medium CPLD. > > -jg I won't argue with that for a moment. But deciding what to put in a part and which flavors to offer in what packages is decided in the land of marketing. As much as I whine and complain, I guess I have to assume they know *something* about their jobs. I am just very, very frustrated because my designs always seem to be limited by the available devices. In some areas they produce a thousand variations on a theme, I suppose because it is easy. In other areas, like FPGAs, we are told it is exquisitely expensive to add any additional features and the variations seem to be limited to a small focused range. I haven't looked at SiBlue in quite a while. I wasn't even aware that they were shipping product. I have looked at Actel, but they tend to have the same limitations in combining "more than a CPLD" in CPLD type packages... they just don't have the same top-heavy product line which would make you think they would branch out more at the low end. When I get more free time, I'll take another look at both of these. One more complaint... selection guides are your friend. I wish more companies understood how useful a good, ***simple***, PDF file selection guide can be. We all know what the salient features of PLDs are. It is actually rather easy to put them all in a simple set of tables showing the important aspects including package types and I/O counts. Yet this info can be hard to find on most PLD vendor's web sites. Rick
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