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
In article <l3uk42$58i$1@speranza.aioe.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>ajbhavana89@gmail.com wrote:
>> On Wednesday, 2 November 2011 17:25:33 UTC+10, lexuancong wrote:
>>> i have project to graduate university .
>>> my project is draw circle , line , triagle in FPGA , display on VGA
>>> ( only use verilog , don't use C) . i have many problems , and time is
>>> running out . if you have data , code about it , please help me.
>The usual way to run a VGA display is in raster mode reading from
>a display RAM. First write the code for that.
>Then write code to load the appropriate shapes into memory.
>(First clear it to background color.)
>That should be a relatively simple state machine, though the easier
>way is probably to build a simple processor and execute compiled
>C code. (Or some other language.)
Overkill.. the video memory can be a ROM preloaded with the video image. The
ROM is just a big case statement (the tools will infer a ROM). Use
run-length coding so that it will fit on the chip (avoiding external memory
interface, allowing it to work on small parts). I think it's just about 100
lines of code.
endmodule
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 155951Mawa_fugo <ccon67@netscape.net> wrote: > On Wednesday, November 2, 2011 2:25:33 AM UTC-5, lexuancong wrote: (snip) >> i have project to graduate university . >> my project is draw circle , line , triagle in FPGA , display on VGA >> ( only use verilog , don't use C) . i have many problems , and time is >> running out . if you have data , code about it , please help me. (snip) > I think you need to turn in code, diagram, all in paper right? > If so you can do searchig on net, some folks here are really > good help > On the basic, you need a cpu, a video frame buffer (sram, > sdram, ...) that can hold let say 640 x 480 pixels vga... > And your FPGA is the center of this project, you use the fpga > to glue all together and to make them to work > The cpu somehow needs to take the mouse input to generate pixel > data and write it to the buffer The OP didn't say how the shapes got into memory, just that they were there. One could just build the logic to generate them and store them on start up. > On the other hand, the FPGA has to read the data out from the > buffer in raster manner and display it on screen Well, another way is to generate the bits without storing them. (Closer to how it was done years ago.) Say you wanted to just draw a rectangle on the screen. You could store the top and bottom scan rows, and left and right positions in the row. Then run row and column counters, and when they are between the appropriate values, output white, otherwise black. That doesn't take so much logic, so you can do a few of them. Not a lot more logic will get you a Pong game from years ago. Generating a circle that way is a little more work, but not an impossible amount. Triangles and trapezoids, not so hard. > anyway, this sounds a big project if you do it all by yourself, > unless you already had some support > your professor must be the first one to ask...what have he > taught you, what hints he can suggest, what evaluation board > available etc... -- glenArticle: 155952
On 20/10/13 03:02, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> I'd like to pick people's brains about aspects of >> different *suppliers* of Zynq boards. > > Do you know anything about the microzed? I just heard of it, and it > looks interesting: > > http://microzed.org > http://linuxgizmos.com/tiny-sbc-runs-linux-on-xilinx-zynq-arm-fpga/ > > Also the Zybo: > > http://www.digilentinc.com/Products/Detail.cfm?Prod=ZYBO They do indeed look interesting for my purposes, but I only know what I can read on the web. So, we would /both/ like some info about the suppliers :)Article: 155953
Am Freitag, 11. Oktober 2013 23:46:33 UTC+2 schrieb alb: > > > In addition, note that most FPGA families have a global reset line > > similar to the global clock lines. They usually keep all the FF held > > at reset until configuration is done, and also allow you to use that > > reset line. It is there, it is free, and you might was well use it. > > > > Apparently I have not found a 'global reset line' for the igloo family, Thats because Actel tend to provide global resources on all families that can be either reset, or clock, or just a high fanout net like enable. There are some slight differences from familiy to family, as for some fuse based there exist dedicated "clock-only" global resources, for those flashbased I used there was no difference between using them as clock or reset. bye ThomasArticle: 155954
Hi Hans, On 18/10/2013 18:59, HT-Lab wrote: [] >> The investigation might be an extremely tedious process. Under which >> conditions should I verify the behavior? Our temperature range is -40 + >> 80, should I run the test in all conditions? > > yes! A full temperature test can be done at the subsystem level (board at minimum) since board layout may affect your results. The idea to route out to a pin the 'lock' signal and monitor it during a temperature scan is quite painful and I may still miss aspects of the characterization (like power variations) which are even more difficult to test unless a special test board is built. Those are the main reasons why I would not rely on such tests unless the manufacturer or some other group has already done an intensive analysis and test campaign on the device. As a small group we can not afford the costs and time it takes to undergo such campaigns. At the system level we are certainly performing ESS and TVT in order to meet requirements, but those tests are not the right place where we can verify such details. >> Should the test be >> performed in thermovacuum (the application will run in low earth orbit). > > yes! The above comments apply even more in this case. The FPGA itself is only one part of a much larger system which has to have appropriate thermal paths in order to be tested in a TVT chamber. Routing the lock signal out of the FPGA and out of the subsystem to make it visible in a TVT Chamber is certainly out of question and, considering the cost of a TVT, rather unfeasible. > I suspect you didn't have your CDR yet but the first thing that was > discussed when I was working on satellites was the reset/POR circuitry. I'm not aware of any CDR done on this component since it is a payload subsystem. Unfortunately (or fortunately [1]) Research institutes are not always so strict in within their hierarchical organizations to demand PDR and CDR for their subsystems. We certainly went through CDR for our main interfaces with the hosting spacecraft (power, data, mechanics, harness). > I worked on OBC's during the Wire mission (1999) and hence reset/supply > rise time/unused jtag pins etc were hot topics. [1] working without such a structure has some benefits up to some level since is less bureaucratic and much more pragmatic. This unstructured approach does not scale well though and for large projects what's at risk is not only the budget but also mission success.Article: 155955
Hi Tom, On 18/10/2013 19:14, Tom Gardner wrote: > On 18/10/13 10:19, alb wrote: >> Should the test be >> performed in thermovacuum (the application will run in low earth orbit). > > I don't think the answer to that question will be left to chance! > (Nor its near equivalent, an answer in a usenet posting) > I agree with you, since I'm neither a believer nor a good gambler! :-) Let me say though, considering a TVT for such a payload (only 30Kg) is on the 40K$ range I would never even dream of verifying my lock signal in such conditions. For each problem there's an appropriate environment where things need to be verified. In a TVT I cannot be worried about an 'and' gate working properly. Moreover the observability of your unit under test is so limited in a TVT that you can only verify your thermal calculations were accurate and every component is working in within the specified temperature range. We typically run full functional tests (all possible mode configurations and external stimuli variations) during the TVT, but certainly are not looking at a fpga pin signal on a scope. At the system level it is good to add as much embedded diagnostics (DFT) as possible to enhance observability and allow to anticipate and/or diagnose issues early in the process. These features are certainly neither free of cost nor without problems themselves.Article: 155956
Hi Thomas, On 20/10/2013 23:47, Thomas Stanka wrote: [] >> Apparently I have not found a 'global reset line' for the igloo >> family, > > Thats because Actel tend to provide global resources on all families > that can be either reset, or clock, or just a high fanout net like > enable. There are some slight differences from familiy to family, as > for some fuse based there exist dedicated "clock-only" global > resources, for those flashbased I used there was no difference > between using them as clock or reset. apparently there's a 'clkint' buffer which is used to route global nets and 'buf/bufd' for high fanout nets. I haven't found yet what should be a reasonable fanout value I should consider before inserting a dedicated 'buf/bufd' but certainly the reset line has a high fanout. Funny enough the p&r fails to meet timing requirements on some reset-to-clock paths even if reset is removed synchronously.Article: 155957
Am Dienstag, 22. Oktober 2013 10:45:42 UTC+2 schrieb alb: > apparently there's a 'clkint' buffer which is used to route global nets > and 'buf/bufd' for high fanout nets. I haven't found yet what should be > a reasonable fanout value I should consider before inserting a dedicated > 'buf/bufd' but certainly the reset line has a high fanout. I'm not familiar with igloo family, but I guess allowed max fanout might be 10-20. If fanout exceeds this value a buf can be inserted as normal buffer tree. Clkint is for gloabl resources like clock, but also reset or enable with several hundred as fanout. If you are not able to meet timing, that means very likely you have a buf-tree with to high fanout/depth instead of a global resource regards ThomasArticle: 155958
Hello, =20 I am not entirely sure if this an implementation problem or an HLS problem = but i will try here first. I have a microblaze system alongside a custom IP= that has memory interfaces for I/O made by HLS. Since I begun using the me= mory interface in the custom IP the Vivado implementation ingnore the HLS = IP completely (synthesis is completed correrctly). When i used to use other= interfaces for IP this problem was not present.=20 =20 The IP is conencted to the AXI bus as such: http://img46.imageshack.us/img46/492/dzsk.png =20 The only issue I see is that the address width of the BRAM generator and th= e IP is 32 while for the AXI-BRAM controller is 14 bits and some pins are l= eft unconnected. But i do not understand why this would make implementation= ingnore the custom IP... =20 Thank you! GeorgeArticle: 155959
On 10/16/2013 5:16 PM, Mark Curry wrote: > In article<l3mli5$g8o$1@dont-email.me>, rickman<gnuarm@gmail.com> wrote: >> On 10/11/2013 3:43 PM, Joseph H Allen wrote: >>> In article<l39dsb$4q1$1@speranza.aioe.org>, >>> glen herrmannsfeldt<gah@ugcs.caltech.edu> wrote: >>> >>>> First, I agree with what Mark says. >>> >>>> In addition, note that most FPGA families have a global reset line >>>> similar to the global clock lines. They usually keep all the FF held >>>> at reset until configuration is done, and also allow you to use that >>>> reset line. It is there, it is free, and you might was well use it. >>> >>>> You do still have to get the timing right, so you release it at >>>> the right time relative to the clock edge. >>> >>> The timing provided by the global reset line is not good.. it's nowhere near >>> as good as a global clock line as far as I understand. >>> >>> One way to deal with this is to have all of your state machines start in a >>> reset state which does nothing but wait for a synchronous "start" edge which >>> is generated after reset with a counter or a shift register. >>> >>> This has a big advantage that you no longer have to worry about global reset >>> timing. On the other hand, if you use libraries you may have no choice >>> since you can't change the logic. >> >> This really doesn't solve the problem. The problem is that globally >> resetting all the state machines in a design can tax the routing and >> timing of the global reset signal. If you do this the routing problem >> can be fixed by resynchronizing the reset to the clock before using it >> in a given section of logic that should be geographically local on the >> chip. Otherwise you can give P&R some very tough problems to solve. > > Wow - can't keep up - lots of replies here. The GSR from Xilinx isn't > the end all solution that Xilinx touts it as. The release of the global > GSR is completely asynchronous. It doesn't really matter much that > router may have trouble routing this signal with low skew. It's > asynchronous - Murphy's law says that one FFs going to see the inactive > edge of reset on one clock edge - the next FF's going to see the it on the > following clock cycle. Low skew likely lowers the likelihood of the event, > but it can happen none-the-less and should be accounted for in your design. > > I've gone into this in the Xilinx forums some, but you've got to be careful > on using that GSR... I won't argue that for a moment. Xilinx has exactly the same problem as the Actel devices. GSR is not a solution, you need to locally resync any reset to the clock. Further you need to design your circuit so that each reset section works if it is not released from reset on the same clock as other sections. But the problem is compounded if there is no GSR at all. Then you have to use other routing resources to spread the reset signal. But I guess it is six of one vs. half dozen of the other. With a GSR the resources have already been gobbled up by the GSR net before you even run the router. -- RickArticle: 155960
On 10/22/2013 4:45 AM, alb wrote: > Hi Thomas, > > On 20/10/2013 23:47, Thomas Stanka wrote: > [] >>> Apparently I have not found a 'global reset line' for the igloo >>> family, >> >> Thats because Actel tend to provide global resources on all families >> that can be either reset, or clock, or just a high fanout net like >> enable. There are some slight differences from familiy to family, as >> for some fuse based there exist dedicated "clock-only" global >> resources, for those flashbased I used there was no difference >> between using them as clock or reset. > > apparently there's a 'clkint' buffer which is used to route global nets > and 'buf/bufd' for high fanout nets. I haven't found yet what should be > a reasonable fanout value I should consider before inserting a dedicated > 'buf/bufd' but certainly the reset line has a high fanout. > > Funny enough the p&r fails to meet timing requirements on some > reset-to-clock paths even if reset is removed synchronously. Just a comment on timing analysis. We were doing a retrofit of an existing hardware design using an Altera Flex 10K part, IIRC. The tool was MAX+ II. The company I worked for had identified a problem with the tool that allowed it to pass timing analysis and fail on the bench. We decided it was clearly a timing issue because of the temperature sensitivity. Warm it up and it fails, cool it down and it passes. Not sensitive to which chip (other than small differences in the threshold temp) was used. Design changes modified it only slightly. We figured it was a poor timing estimation of a heavily loaded net, but were never able to prove that. Altera was no help for this problem sticking their head in the sand since they would be dropping support for this tool in another year. Just a caution that passing static timing analysis is no indication that the design is actually meeting timing. -- RickArticle: 155961
On 26/10/13 09:20, rickman wrote: > Just a comment on timing analysis. We were doing a retrofit of an existing hardware design using an Altera Flex 10K part, IIRC. The tool was MAX+ II. The company I worked for had identified a > problem with the tool that allowed it to pass timing analysis and fail on the bench. We decided it was clearly a timing issue because of the temperature sensitivity. Warm it up and it fails, cool it > down and it passes. Not sensitive to which chip (other than small differences in the threshold temp) was used. Design changes modified it only slightly. We figured it was a poor timing estimation > of a heavily loaded net, but were never able to prove that. Altera was no help for this problem sticking their head in the sand since they would be dropping support for this tool in another year. > > Just a caution that passing static timing analysis is no indication that the design is actually meeting timing. Nasty nasty nasty. So, how do you[1] convince yourselves and your customers that each individual chip actually /is/ working with a reasonable margin? No, I don't expect a neat easy response. [1] the impersonal pronoun, since "how does one" sounds too stilted to the modern ear/brain combination :)Article: 155962
On 10/26/2013 4:59 AM, Tom Gardner wrote: > On 26/10/13 09:20, rickman wrote: >> Just a comment on timing analysis. We were doing a retrofit of an >> existing hardware design using an Altera Flex 10K part, IIRC. The tool >> was MAX+ II. The company I worked for had identified a >> problem with the tool that allowed it to pass timing analysis and fail >> on the bench. We decided it was clearly a timing issue because of the >> temperature sensitivity. Warm it up and it fails, cool it >> down and it passes. Not sensitive to which chip (other than small >> differences in the threshold temp) was used. Design changes modified >> it only slightly. We figured it was a poor timing estimation >> of a heavily loaded net, but were never able to prove that. Altera was >> no help for this problem sticking their head in the sand since they >> would be dropping support for this tool in another year. >> >> Just a caution that passing static timing analysis is no indication >> that the design is actually meeting timing. > > Nasty nasty nasty. > > So, how do you[1] convince yourselves and your customers that each > individual chip actually /is/ working with a reasonable margin? > > No, I don't expect a neat easy response. > > [1] the impersonal pronoun, since "how does one" sounds too stilted to > the modern ear/brain combination :) Can "one" ever assure "one's" customers that "one's" designs are entirely bug free? I have never been able to do that with *any* design. Why would FPGAs be any different? My statement above may be a bit strong. Surely the static timing analysis tool is intended to verify timing. But it *can* be wrong, that is my point. -- RickArticle: 155963
On 27/10/13 16:34, rickman wrote: > On 10/26/2013 4:59 AM, Tom Gardner wrote: >> On 26/10/13 09:20, rickman wrote: >>> Just a comment on timing analysis. We were doing a retrofit of an >>> existing hardware design using an Altera Flex 10K part, IIRC. The tool >>> was MAX+ II. The company I worked for had identified a >>> problem with the tool that allowed it to pass timing analysis and fail >>> on the bench. We decided it was clearly a timing issue because of the >>> temperature sensitivity. Warm it up and it fails, cool it >>> down and it passes. Not sensitive to which chip (other than small >>> differences in the threshold temp) was used. Design changes modified >>> it only slightly. We figured it was a poor timing estimation >>> of a heavily loaded net, but were never able to prove that. Altera was >>> no help for this problem sticking their head in the sand since they >>> would be dropping support for this tool in another year. >>> >>> Just a caution that passing static timing analysis is no indication >>> that the design is actually meeting timing. >> >> Nasty nasty nasty. >> >> So, how do you[1] convince yourselves and your customers that each >> individual chip actually /is/ working with a reasonable margin? >> >> No, I don't expect a neat easy response. >> >> [1] the impersonal pronoun, since "how does one" sounds too stilted to >> the modern ear/brain combination :) > > Can "one" ever assure "one's" customers that "one's" designs are entirely bug free? I have never been able to do that with *any* design. Why would FPGAs be any different? Of course, but that's a bog-standard and therefore uninteresting point. But it is the margin (or lack of it) that is the interesting question. So, how do you assess the margin? If there's a problem, how do you positively determine the cause is an internal margin problem? (As opposed to merely presuming) > My statement above may be a bit strong. Surely the static timing analysis tool is intended to verify timing. But it *can* be wrong, that is my point. If the problem was the static timing analysis of the chip's internals, then I'm concerned because internal points are somewhat difficult to directly observe. External timing is a different issue.Article: 155964
On 10/27/2013 1:46 PM, Tom Gardner wrote: > On 27/10/13 16:34, rickman wrote: >> On 10/26/2013 4:59 AM, Tom Gardner wrote: >>> On 26/10/13 09:20, rickman wrote: >>>> Just a comment on timing analysis. We were doing a retrofit of an >>>> existing hardware design using an Altera Flex 10K part, IIRC. The tool >>>> was MAX+ II. The company I worked for had identified a >>>> problem with the tool that allowed it to pass timing analysis and fail >>>> on the bench. We decided it was clearly a timing issue because of the >>>> temperature sensitivity. Warm it up and it fails, cool it >>>> down and it passes. Not sensitive to which chip (other than small >>>> differences in the threshold temp) was used. Design changes modified >>>> it only slightly. We figured it was a poor timing estimation >>>> of a heavily loaded net, but were never able to prove that. Altera was >>>> no help for this problem sticking their head in the sand since they >>>> would be dropping support for this tool in another year. >>>> >>>> Just a caution that passing static timing analysis is no indication >>>> that the design is actually meeting timing. >>> >>> Nasty nasty nasty. >>> >>> So, how do you[1] convince yourselves and your customers that each >>> individual chip actually /is/ working with a reasonable margin? >>> >>> No, I don't expect a neat easy response. >>> >>> [1] the impersonal pronoun, since "how does one" sounds too stilted to >>> the modern ear/brain combination :) >> >> Can "one" ever assure "one's" customers that "one's" designs are >> entirely bug free? I have never been able to do that with *any* >> design. Why would FPGAs be any different? > > Of course, but that's a bog-standard and therefore uninteresting > point. But it is the margin (or lack of it) that is the interesting > question. > > So, how do you assess the margin? > > If there's a problem, how do you positively determine > the cause is an internal margin problem? (As opposed to > merely presuming) > > > >> My statement above may be a bit strong. Surely the static timing >> analysis tool is intended to verify timing. But it *can* be wrong, >> that is my point. > > If the problem was the static timing analysis of the chip's internals, > then I'm concerned because internal points are somewhat difficult to > directly observe. External timing is a different issue. Yes, I agree. The symptoms were the erratic nature of the failure in terms of routing. Then it would go away when the chip was cooled down. Thirdly some chips were consistently more sensitive than others. Finally it was also sensitive to Vcc. This all points to timing. Can't prove it, but we acted on that assumption and wrote some timing analysis tools ourselves. We eventually got a route that passed timing at elevated temperatures and low Vcc voltage and shipped the product. Ever since I have not trusted the tools 100%. But then like I said, this was a product that was being replaced by Quartus in less than a year, so Altera wouldn't put any effort into working on the problem, even to see if it really existed. You can draw your own conclusions. -- RickArticle: 155965
Hi everyone, this might be a stupid question to ask here but I really do not know where else I can post it. I filed 4 technical support requests on the Microsemi website last Friday and, as of today, never had an answer back (not even a confirmation email of the request! [1]). They write on their page: > Your application request will be sent to Microsemi's team of > Application Support Engineers who will contact you either via email, > phone or fax within 48 hours. Does it mean 48 working hours (i.e. maybe ~6 days!)? Or should I have expected an answer by Monday? Have any of you had any experience with Microsemi technical support? Any hint on which is the most effective way to address a technical issue with their products? Thanks a lot for any suggestion/hint/clue, even a sympathetic message would be appreciated :-) Al p.s.: BTW I couldn't file the report as a Swiss worker since there was no possibility to select this country from the pull-down menu! [1] the website proudly reported, in red: "your request has been successfully submitted" -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 155966
Am Dienstag, 29. Oktober 2013 13:46:08 UTC+1 schrieb alb: > this might be a stupid question to ask here but I really do not know > where else I can post it. I filed 4 technical support requests on the > Microsemi website last Friday and, as of today, never had an answer back > (not even a confirmation email of the request! [1]). It clearly depends :). First try contact european FAE. Depending on your distributor the distribut= or can help as well (at least in speedup getting answer). Assume that 48h e= xcludes weekend. The european FAE are good in answering easy topics they kn= ow the answer. Unfortunately there are topics that require detailed knowled= ge of the design group itself which is not easy to access. On difficult or delicate topics, you might need some more patience. If you = have bad luck, h is shortform of month.=20 My experience is that Microsemi fpga support slowed down a few years ago, g= uess they safed a lot of money by reducing the support levels to a degree t= hat is not adequate to their device costs. regards ThomasArticle: 155967
Dear all, HercuLeS by Ajax Compilers, Inc. (http://www.ajaxcompilers.com) is an easy to use high-level synthesis (HLS) environment for the automatic translation of algorithms to hardware. HercuLeS is suitable for both hardware-oriented and software-minded engineers. You can download the FREE version of HercuLeS for Windows 7 (64-bit) and Linux (32-bit and 64-bit) from here: http://www.nkavvadias.com/temp/index.php No registrations, no emails, no additional downloads, no fuss! Just get the file, read the instructions from this page, and you are set! Compared to the BASIC and FULL versions, there are some features intentionally missing from the FREE version; please consult the HercuLeS feature matrix for full details: http://www.nkavvadias.com/hercules/hercules-feature-matrix.html Best regards, Nikolaos Kavvadias CEO Ajax Compilers Kornarou 12 Rd, Nea Ampliani, 35100 Lamia GreeceArticle: 155968
On Saturday, October 19, 2013 9:06:50 PM UTC-5, glen herrmannsfeldt wrote:
> Mawa_fugo <ccon67@netscape.net> wrote:
>
> > On Wednesday, November 2, 2011 2:25:33 AM UTC-5, lexuancong wrote:
>
>
>
> (snip)
>
> >> i have project to graduate university .
>
> >> my project is draw circle , line , triagle in FPGA , display on VGA
>
> >> ( only use verilog , don't use C) . i have many problems , and time is
>
> >> running out . if you have data , code about it , please help me.
>
>
>
> (snip)
>
>
>
> > I think you need to turn in code, diagram, all in paper right?
>
>
>
> > If so you can do searchig on net, some folks here are really
>
> > good help
>
>
>
> > On the basic, you need a cpu, a video frame buffer (sram,
>
> > sdram, ...) that can hold let say 640 x 480 pixels vga...
>
> > And your FPGA is the center of this project, you use the fpga
>
> > to glue all together and to make them to work
>
>
>
> > The cpu somehow needs to take the mouse input to generate pixel
>
> > data and write it to the buffer
>
>
>
> The OP didn't say how the shapes got into memory, just that they
>
> were there. One could just build the logic to generate them and
>
> store them on start up.
>
>
Ahhhh, you caught me on this, ... btw hello, long time no chat to anyone in this group ...
Anyway, the OP might/might not say that... I read his title twice, and thought that he want to: "draw lines, circles, squares on FPGA by mouse"
I'm still not so sure what he wanna do, just imagine ...when user click the left button on the mouse and make a circle-like movement, on his/her vga screen will then display a circle-liked shape, still not sure it's perfect circle or an egg alike ???
>
> > On the other hand, the FPGA has to read the data out from the
>
> > buffer in raster manner and display it on screen
>
>
>
> Well, another way is to generate the bits without storing them.
>
> (Closer to how it was done years ago.)
>
>
>
> Say you wanted to just draw a rectangle on the screen. You could
>
> store the top and bottom scan rows, and left and right positions
>
> in the row. Then run row and column counters, and when they are
>
> between the appropriate values, output white, otherwise black.
>
>
>
> That doesn't take so much logic, so you can do a few of them.
>
> Not a lot more logic will get you a Pong game from years ago.
>
>
>
> Generating a circle that way is a little more work, but not an
>
> impossible amount. Triangles and trapezoids, not so hard.
That's interesting, that you can do the 'direct draw' like that from the logic... the rectangle is piece of cake & pretty easy to understand, ... I wonder how to do that for other shapes like you said ?
>
>
>
> > anyway, this sounds a big project if you do it all by yourself,
>
> > unless you already had some support
>
>
>
> > your professor must be the first one to ask...what have he
>
> > taught you, what hints he can suggest, what evaluation board
>
> > available etc...
>
>
>
> -- glen
Article: 155969Mawa_fugo <ccon67@netscape.net> wrote: >> > On Wednesday, November 2, 2011 2:25:33 AM UTC-5, lexuancong wrote: (snip) >> >> i have project to graduate university . >> >> my project is draw circle , line , triagle in FPGA , >> display on VGA > (snip, I wrote) >> The OP didn't say how the shapes got into memory, just that they >> were there. One could just build the logic to generate them and >> store them on start up. > Ahhhh, you caught me on this, ... btw hello, long time no chat to > anyone in this group ... > Anyway, the OP might/might not say that... I read his title twice, > and thought that he want to: "draw lines, circles, squares on > FPGA by mouse" Could be. But just drawing some figures is a not too simple, but also not too hard project for an introduction to actually building logic. > I'm still not so sure what he wanna do, just imagine ...when user > click the left button on the mouse and make a circle-like > movement, on his/her vga screen will then display a > circle-liked shape, still not sure it's perfect circle or > an egg alike ??? That is pretty tricky to do all in hardware. Well, as a combination of state machines not so hard to do. One state machine to keep track of the mouse position, (and generate the cursor), another to keep track of what the mouse is doing, then some more to draw the figure. But only after you know how to draw figures. (snip, I also wrote) >> Well, another way is to generate the bits without storing them. >> (Closer to how it was done years ago.) >> Say you wanted to just draw a rectangle on the screen. You could >> store the top and bottom scan rows, and left and right positions >> in the row. Then run row and column counters, and when they are >> between the appropriate values, output white, otherwise black. >> That doesn't take so much logic, so you can do a few of them. >> Not a lot more logic will get you a Pong game from years ago. >> Generating a circle that way is a little more work, but not an >> impossible amount. Triangles and trapezoids, not so hard. > That's interesting, that you can do the 'direct draw' like > that from the logic... the rectangle is piece of cake & pretty > easy to understand, ... I wonder how to do that for other > shapes like you said ? One way is with some form of Bresenham's algorithm. That is mostly used for drawing lines instead of filled shapes, but should also work for filled shapes. There is also a related algorithm for circles. Another is with a phase accumulator to keep track of the starting and ending points. Consider a binary value with the binary point not just after the ones bit, such that it can hold fractional values. Now, each cycle (scan line) you add a binary value approximating the slope of the line. The integer (ignore fractional bits) value is now the starting coordinate on that scan line. For curved shapes, you could find the start and end points with some form of CORDIC. Once you have the start and end points for each scan line, all you need is the logic to determine inside and outside, and generate the appropriate output signal. In the days of expensive computing hardware, it was more usual to do something like that, though maybe more usual to do it with analog electronics. There were some fairly expensive vector graphics systems that continually refreshed the display from a display buffer. With the two end points of a line segment, some D/A converters, and some analog circuitry you can generate the X and Y values long a line segment. Charge two capacitors with the appropriate currents, and the voltage as a function of time will be reasonably linear. Then there were the Tektronix terminals based on storage CRTs, as developed for oscilloscopes. The image is stored as charge on the screen. -- glenArticle: 155970
Hi all, to the OP: you can examine PLOTLINE and PLOTCIRCLE, two demo IPs by Ajax Co= mpilers (http://www.ajaxcompilers.com). They come for FREE, just register t= o the Ajax Compilers store. They are ZERO EURO, no cost, totally free IPs, = just give them a shot. They come with reasonable documentation and a demo p= latform setup for a Spartan-3AN starter kit FPGA board! If you are in a hurry, I have another version for the Bresenham line drawin= g function here: http://www.nkavvadias.com/hercules/ (scroll down, there ar= e lots of other materials on high-level synthesis there). It is called "lin= edraw" there. In short, I have used pure C code implementations for both the line and cir= cle drawing algorithms, and then passed them through HercuLeS (my HLS tool)= . It is purely automated work, no hand coding please, this is 2013 and I'm = an EDA tool developer (LOL) I also have lots of other graphics primitives stuff, like an ellipse algori= thm, etc. I don't recall having implemented a flood filler in hardware. I t= hink you can do better than iteratively running Bresenham's algorithm. If y= ou do this, you will have to make a second pass, patching untouched pixels = (this is what it looks like at first glance). Hope these help. Best regards, Nikolaos Kavvadias http://www.nkavvadias.comArticle: 155971
On 16/10/2013 08:39, ajbhavana89@gmail.com wrote: > On Wednesday, 2 November 2011 17:25:33 UTC+10, lexuancong wrote: >> hi ! >> >> im from vietnam . my english is not good , i hope you can understand >> >> what i say . thanks ! >> >> i have project to graduate university . >> >> my project is draw circle , line , triagle in FPGA , display on VGA >> >> ( only use verilog , don't use C) . i have many problems , and time is >> >> running out . if you have data , code about it , please help me. >> >> .... >> >> thanks you so much ! > > Hi I am in the same situation with the same project. can u please help me I'm happy to point you in the right direction, but I don't think it's appropriate to provide code. In our product I create concentric circles using the Bresenham's circle algorithm on raster display and is ideal for square pixel formats. It is possible to vary the theme to make ovals, or even circles on non square pixel formats. The algorithm doesn't need a multiplier, but most FPGAs have a wealth of ALUs such that it might be just as appropriate to calculate squared numbers using an ALU. Google will find a number of articles though some are more confusing than others. I had considered adding an article myself to our website but just haven't got around to it! Similarly for drawing lines, have a look at Bresenham's line algorithm, but that is something I have never used! I've stuck to only drawing horizontal and vertical lines! -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.ukArticle: 155972
W dniu 2013-10-16 09:39, ajbhavana89@gmail.com pisze: > On Wednesday, 2 November 2011 17:25:33 UTC+10, lexuancong wrote: >> hi ! >> >> im from vietnam . my english is not good , i hope you can understand >> >> what i say . thanks ! >> >> i have project to graduate university . >> >> my project is draw circle , line , triagle in FPGA , display on VGA >> >> ( only use verilog , don't use C) . i have many problems , and time is >> >> running out . if you have data , code about it , please help me. >> >> .... >> >> thanks you so much ! > > Hi I am in the same situation with the same project. can u please help me > There is wrong topic. It is more like "Do my homwork for free" not "help me understand my problem " Don't u see !? AdamArticle: 155973
Adam Górski wrote: > W dniu 2013-10-16 09:39, ajbhavana89@gmail.com pisze: >> On Wednesday, 2 November 2011 17:25:33 UTC+10, lexuancong wrote: >>> hi ! >>> >>> im from vietnam . my english is not good , i hope you can understand >>> >>> what i say . thanks ! >>> >>> i have project to graduate university . >>> >>> my project is draw circle , line , triagle in FPGA , display on VGA >>> >>> ( only use verilog , don't use C) . i have many problems , and time is >>> >>> running out . if you have data , code about it , please help me. >>> >>> .... >>> >>> thanks you so much ! >> >> Hi I am in the same situation with the same project. can u please help me >> > > There is wrong topic. > It is more like "Do my homwork for free" not "help me understand my > problem " > Don't u see !? > > Adam Probably a moot point as the original post came two weeks ago and the OP has disappeared since then. This seems typical of the "do my work for me" threads. While the community has fun discussing possibilities, the original poster has missed his deadline and is now flipping burgers. -- GaborArticle: 155974
In article <l4k5rr$nqs$1@dont-email.me>,
rickman <gnuarm@gmail.com> writes:
>Ever since I have not trusted the tools 100%.
Software geeks have been fighting compiler bugs for a long long time.
The thing that makes FPGA timing bugs so nasty is that you can't
reasonably check the output. With a compiler, you can look at the
instructions it produces. With a PCB router, you can eyeball the gerbers.
Many years ago, I made a list of all the possible places that could
cause a board I was working on. At the high level, there were things
like
bugs in the board design,
bugs in the individual PCB or in assembling the board,
bugs in the firmware or FPGA or ...
bugs in the driver
Mixed in with those were things like
bugs in the tools (there are a lot of them)
the board layout tools, their libraries
the assembler for the firmware (which we had written)
the FPGA tools
bugs in the data sheets
bugs in my reading of the data sheets
--
These are my opinions. I hate spam.
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