Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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

Custom Search

Messages from 155950

Article: 155950
Subject: Re: draw lines, circles, squares on FPGA by mouse and display on VGA ( not use NIOS)
From: jhallen@TheWorld.com (Joseph H Allen)
Date: Sun, 20 Oct 2013 02:03:22 +0000 (UTC)
Links: << >>  << T >>  << A >>
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: 155951
Subject: Re: draw lines, circles, squares on FPGA by mouse and display on VGA ( not use NIOS)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 20 Oct 2013 02:06:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
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.
 
> 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...

-- glen

Article: 155952
Subject: Re: Zynq devices, boards and suppliers
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sun, 20 Oct 2013 08:47:57 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: reset strategy FPGA Igloo
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Sun, 20 Oct 2013 14:47:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Thomas

Article: 155954
Subject: Re: reset strategy FPGA Igloo
From: alb <alessandro.basili@cern.ch>
Date: Tue, 22 Oct 2013 10:13:45 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: reset strategy FPGA Igloo
From: alb <alessandro.basili@cern.ch>
Date: Tue, 22 Oct 2013 10:26:30 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: reset strategy FPGA Igloo
From: alb <alessandro.basili@cern.ch>
Date: Tue, 22 Oct 2013 10:45:42 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: reset strategy FPGA Igloo
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Tue, 22 Oct 2013 03:00:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Thomas

Article: 155958
Subject: Implementation ingnoring custom IP made with HLS
From: mormegil231 <turin231@gmail.com>
Date: Fri, 25 Oct 2013 05:44:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
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!

George

Article: 155959
Subject: Re: reset strategy FPGA Igloo
From: rickman <gnuarm@gmail.com>
Date: Sat, 26 Oct 2013 04:07:45 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 155960
Subject: Re: reset strategy FPGA Igloo
From: rickman <gnuarm@gmail.com>
Date: Sat, 26 Oct 2013 04:20:01 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 155961
Subject: Re: reset strategy FPGA Igloo
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sat, 26 Oct 2013 09:59:22 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: reset strategy FPGA Igloo
From: rickman <gnuarm@gmail.com>
Date: Sun, 27 Oct 2013 12:34:00 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 155963
Subject: Re: reset strategy FPGA Igloo
From: Tom Gardner <spamjunk@blueyonder.co.uk>
Date: Sun, 27 Oct 2013 17:46:38 +0000
Links: << >>  << T >>  << A >>
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
Subject: Re: reset strategy FPGA Igloo
From: rickman <gnuarm@gmail.com>
Date: Sun, 27 Oct 2013 18:58:27 -0400
Links: << >>  << T >>  << A >>
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.

-- 

Rick

Article: 155965
Subject: microsemi technical support
From: alb <alessandro.basili@cern.ch>
Date: Tue, 29 Oct 2013 13:46:08 +0100
Links: << >>  << T >>  << A >>
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
Subject: Re: microsemi technical support
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Tue, 29 Oct 2013 06:06:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 Thomas

Article: 155967
Subject: FREE download of HercuLeS high-level synthesis!
From: Nikolaos Kavvadias <nikolaos.kavvadias@gmail.com>
Date: Wed, 30 Oct 2013 07:50:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
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
Greece

Article: 155968
Subject: Re: draw lines, circles, squares on FPGA by mouse and display on VGA
From: Mawa_fugo <ccon67@netscape.net>
Date: Wed, 30 Oct 2013 10:32:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
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: 155969
Subject: Re: draw lines, circles, squares on FPGA by mouse and display on VGA ( not use NIOS)
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 30 Oct 2013 19:22:34 +0000 (UTC)
Links: << >>  << T >>  << A >>
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 > 

(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.

-- glen


Article: 155970
Subject: Re: draw lines, circles, squares on FPGA by mouse and display on VGA
From: Nikolaos Kavvadias <nikolaos.kavvadias@gmail.com>
Date: Wed, 30 Oct 2013 12:33:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.com

Article: 155971
Subject: Re: draw lines, circles, squares on FPGA by mouse and display on
From: Mike Perkins <spam@spam.com>
Date: Wed, 30 Oct 2013 20:05:41 +0000
Links: << >>  << T >>  << A >>
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.uk

Article: 155972
Subject: Re: draw lines, circles, squares on FPGA by mouse and display on
From: =?ISO-8859-1?Q?Adam_G=F3rski?= <gorskiamalpa@wpkropkapl>
Date: Wed, 30 Oct 2013 22:15:39 +0100
Links: << >>  << T >>  << A >>
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

Article: 155973
Subject: Re: draw lines, circles, squares on FPGA by mouse and display on
From: GaborSzakacs <gabor@alacron.com>
Date: Wed, 30 Oct 2013 17:23:05 -0400
Links: << >>  << T >>  << A >>
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.

-- 
Gabor

Article: 155974
Subject: Re: reset strategy FPGA Igloo
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Thu, 31 Oct 2013 15:23:12 -0500
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

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

Custom Search