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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 97325

Article: 97325
Subject: Re: Is FPGA code called firmware?
From: Joseph Samson <user@example.net>
Date: Mon, 20 Feb 2006 23:12:36 GMT
Links: << >>  << T >>  << A >>
Marko wrote:
> Traditionally, firmware was defined as software that resided in ROM.
> So, my question is, what do you call FPGA code?  Is "firmware"
> appropriate? 
At my previous employer, a proposal was submitted and the Xilinx 
configuration files were called firmware. Someone forgot to read the RFP 
carefully, because we were specifically prohibited from developing 
firmware. The proposal was changed, I believe to 'configuration file'.


---
Joe Samson
Pixel Velocity

Article: 97326
Subject: Re: Implementing a two-modulus PLL divider in Altera Stratix II
From: John_H <johnhandwork@mail.com>
Date: Mon, 20 Feb 2006 23:20:13 GMT
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> What's the spectrum of the output of a "two-modulus prescaler"?
> 
> What's the spectrum of a DDS?
> 
> How low do I have to make the PLL bandwidth if I want to filter
> out the junk?  (Assume I run the DDS output through a PLL
> to filter out the steps.)

The output of a two-modulus prescaler (specifically "fractional-N 
synthesis") and the MSbit of a DDS (as opposed to a phase-to-sine lookup 
feeding a DAC) are the same thing - they produce the same spectra.  The 
largest spurs are related to the closest integer ratio approximations to 
the output to reference clock ratio, many smaller spurs coming from 
mixing of those components and other slightly nonlinear effects of the 
ratios that produce these beat frequencies.

With no extra help, both approaches have phase steps in some situations 
that are too low to be filtered out in an analog PLL filter.  Imagine an 
output frequency so close to a divide-by-12 that the divide-by-13 
happens once a second.  The result will be the same from the MSBit of 
the DDS and the accumulator for the divide by 12/13 control - a phase 
"slip" that has a ramp back to "steady state" controlled by the analog 
PLL filter.

The phase steps in DDS or fractional-N synthesis can be reduced by using 
the same techniques in sigma-delta converters but the control is a 
little more than a dual modulus.  If there is a phase offset from 
"ideal" that is a ramp going from -0.5 Unit Intervals (UI) phase error 
to +0.5 UI of error, adding compensation to the output divider to push 
the phase error occasionally beyond the +/- 0.5 UI range at high enough 
frequency will allow the PLL's loop filter to average the compensation 
to directly match the offest from "ideal."

Different systems have different requirements for what is "good" quality 
results.  Using the dithering just mentioned, there are often still 
noticeable spurs in the output spectrom though they won't look like much 
from the time domain.  Many systems - such as analog - can't deal with 
the associated background tones and would gladly trade off a higher 
noise floor for lower spurs.  In most of the stuff I want to deal with, 
I'm concerned about the time domain.

Article: 97327
Subject: Re: Quartus Tcl interface
From: "ernie" <ernielin@gmail.com>
Date: 20 Feb 2006 15:38:31 -0800
Links: << >>  << T >>  << A >>
I played around in Quartus and I think I've discovered the answer to my
own question.

If you assign to a pin location "null", that removes the assignment
apparently.  ie. cmp add_asssignment top_name "" pin_name LOCATION null


Cheers,
Ernie


Article: 97328
Subject: Re: SCHEMATICS ... Is anybody as frustrated as I am with the software?
From: metal <nospam@spaam.edu>
Date: Mon, 20 Feb 2006 16:10:32 -0800
Links: << >>  << T >>  << A >>
>Mark McDougall wrote:
>> 
>> FWIW, I'd never return to schematics. Yes, top level can be nice as Mike 
>> pointed out, but I find the disadvantages - slow, buggy tools, 
>> cumbersome maintenance, no portability - far outweigh the benefits.
>> 
>> Regards,
>> Mark


Ironically, even as a 'born again' HDL'er, you just pointed out that
the "benefits" of HDL over Schematics may not have had anything to do
with actual benefits; but rather, may have been due simply to the
abysmal fpga-schematic -tools- that we were all forced to deal with.

Assuming -excellent- schematic tools, the benfits of graphical
presentation will shine, as they must -always- do.  This is simply
because the human brain is -wired- to process graphical information;
and graphical/visual presentation has a higher info-content than plain
text.

Think of graphical-info as "high level langauge" vs. a screen full of
text as "assembly", and that'd be a semi-accurate analogy I believe.

As I write this, I realize that there are -two- aspects of this issue;

1)  Design is one (the OP's original subject)

2)  but Presentation is a 2nd aspect


Schematics have it all over HDL for 2), and as Ray pointed out, have
distinct benefits in top-level design as well.

I've forgotten who posted about having invested a lot of time in
setting up an optimized Viewlogic setup; but his description of how it
operated gave a glimmer of just what an -excellent- FPGA schematic
front end tool would be like.  Just think if it was easily -2 way- !

Where one was dealing with a major functional block, and it was faster
and easier to understand visually, you could drop a box on the screen,
label it, and open an HDL window to 'populate' it.  And where it was
quicker to just write 3 lines of HDL, you could start with that, and
have the tool automatically plop a finished and labeled box on the
screen for you.  You'd be working in both high level visual -and- low
level HDL code -simultaneously-.  Now -that- would be nice...

Regarding the complaints about drawing "hundreds" of wires coming off
an FPGA, and having to draw all the caps on the FPGA....c'mon, those
are both partially specious I think.

In the first place, the vast majority of pins on the vast majority of
FPGA designs are -bus- lines; which are virtually- always drawn as a
single line representing 8,16, 32, or more, connections/wires.  Draw
just 4 or 5 of those, and you've finished 80% of the connections on a
160 qfp like a PCI intfc design.  It ain't -that- tough... <g>

In the 2nd place, the convention for bypass caps is to group them all
on their own schematic; i.e a "power and ground" page.  It is rare
that I ever see them placed right next to chip symbols on any
schematic these days.  (one -does- want to remember to pass placement
notes to the layout-man though! <grin>)

With most modern schem/pcb systems, a dozen bypass caps can be
instantiated onto the sheet, and connected to GND and 3.3V, in about
60 seconds.

In terms of 'readability'...let's all be honest now.  Only the most
-expert- of HDL designers can look at a multi-page listing of dense
code and have -any- understanding of what the hell an FPGA -does-, in
any short time frame (i.e. seconds or minutes).

The rest of us, even most HDL designers, will spend MANY minutes, even
hours, trying to figure out what the heck the part -does-; let alone
how it works.

Yet -everyone- could look at a schematic of that chip and gain at
least a glimpse of the overall functionality in mere -seconds-; and a
pretty in-depth understanding in perhaps 2 minutes.

For all the rest of the engineers and technicians on the entire
planet, a schematic of the inside of that FPGA is an -invaluable- aid
in troubleshooting and repairing the equipment that it's a part of.

I have spent plenty of years on both ends of the stick, design and
troubleshooting, both my own designs and those of many others; and
that's how I've learned to value both the code AND the high-level
visual presentation.

You will notice that even in the pure software world, higher-level
tools like flowcharters and "code block layout" tools retain a place
of importance.  Again, graphical/visual presentation is simply more
-efficient-....it carries more information per visual/brain "bit", so
to speak.

A single 8x11" schematic page can -easily- represent -many- pages of
HDL code....and even represent that HDL -and- 10,000 lines of software
combined.  (i.e. one little rectangle labeled "DSP core for FFT's",
etc. etc..).  This is an extremely valuable design-method, and
presentation-type, that we shouldn't be letting escape from our
toolboxes so blithely.

I thank the posters who talked about or asked about what tools are out
there; for both the OP's entirely valid complaint on the current
offerings; and for the other category of tools to -extract- readable
schems from HDL code.

I'm a firm believer in HDL as well, and would love to have a toolset
for automated schema production from code; but in no way does plain
text replace visual/graphical display of information, imho.


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Article: 97329
Subject: Re: SCHEMATICS ... Is anybody as frustrated as I am with the software?
From: fpga_toys@yahoo.com
Date: 20 Feb 2006 16:56:29 -0800
Links: << >>  << T >>  << A >>

Symon wrote:
>  I've found
> myself doing a fair bit of maintenance on some viewlogic stuff over the last
> month or so, and, for readability, I've found myself doing the same as I do
> for VHDL, i.e. drawing timing diagrams to work things out.
> It's got to the point where I've looked (unsuccessfully) for tools to do
> some PCB design entry using VHDL. I'm getting sick and tired of drawing a
> bunch of rectangles with hundreds of wires coming off them to represent an
> FPGA. Also, adding each and every bypass cap. If I could use VHDL for this,
> I could cut and paste a lot of the pin information from the data sheet to be
> more accurate and quicker. Of course, for analog electronics this makes
> little sense, but it would be nice to be able to mix and match the two entry
> methods.

I hate to admit it sometimes, but for several recient fpga boards I've
just skipped doing schematics for them entirely, choosing instead to
design with scripts, augmented parts libraries, and netlists.

It's much faster to verify a board with netlists when parts have
reasonable signal names on library pins, and using script driven
netlisting with reverse annotation from the layout to transfer net
names to the fpga pins. Visually scanning netlists for 1517 ball bga's
is MUCH quicker than following that many lines on a schematic and
verifying pin/ball numbers.

It would be very nice to document a design if there were tools that
would take the same finished netlist and pcb layout, and autogenerate
schematics --- except for the fact that thousand pin bga's just don't
fit well on schematics anyway using 1960's drawing standards.


Article: 97330
Subject: FPGA - software or hardware -2-
From: "Hub van de Bergh" <hub_antispam@hetnet.nl>
Date: Tue, 21 Feb 2006 02:10:17 +0100
Links: << >>  << T >>  << A >>
The background for my question whether an FPGA is viewed as software or as
hardware comes from the regulations for medical devices.

From the perspective of regulatory requirements it makes a difference
whether an FPGA is viewed as software or as purely hardware because of
regulatory requirements for medical devices are more comprehensive when
software is involved.

Regulatory requirements for medical devices are focussed on safety and
reliability of the finished medical device. If the resulting product cannot
be tested in full - which is the case with software - then the regulations
require to have controlled processes in place for (software) product
development in order to minimize risks on hazardous situations.

Is anybody in this NG experienced in the field of applying FPGA's in medical
devices and the view of regulatory bodies?

www.hvdb.tk




Article: 97331
Subject: Re: FPGA - software or hardware -2-
From: fpga_toys@yahoo.com
Date: 20 Feb 2006 17:23:55 -0800
Links: << >>  << T >>  << A >>

Hub van de Bergh wrote:
> The background for my question whether an FPGA is viewed as software or as
> hardware comes from the regulations for medical devices.
>
> From the perspective of regulatory requirements it makes a difference
> whether an FPGA is viewed as software or as purely hardware because of
> regulatory requirements for medical devices are more comprehensive when
> software is involved.

Looks like a duck, swims like a duck, quacks like a duck, it must be a
duck???

In the end, if it looks like software (HDL or HLL), acts like software
(loads from some read/write storage media such as eeprom, flash, disk,
network), is readily updated/changed like software, there probably is
very good reasons for regulators (or litigating lawyers) to suggest
that design procedures would have avoided the loss of life or injury if
the development had been held to the proper, and more rigourous
standards of software.  It's really hard to claim due diligence after
the fact when you choose to take the easy way out by splitting hairs
with definitions.

Reconfigurable computing and system-on-chip design strategies blur the
line today, and will probably solidly move that line so that FPGA
design is considered software tomarrow. And for good reason.
***HARD*** ware designs can not easily/cost effectively be changed in
the field, and as such everyone puts more effort into getting it right
first time for that reason. ***SOFT*** ware has a reputation of people
taking shortcuts because it can be changed next release, and get better
(or right, or perfect) over time. I'm almost certain someone can find a
written memo from some company to ship a hardware design in FPGA with
known critical flaws to meet contractual shipment obligations or sales
quotas, with the expectation that it can be corrected with an updated
FPGA image next week, month, year. One such memo, in litigation,
clearly defines HARD and SOFT when it comes to product failures and
field upgradability.


Article: 97332
Subject: Re: SCHEMATICS ... Is anybody as frustrated as I am with the software?
From: "Hendra" <u1000393@email.sjsu.edu>
Date: 20 Feb 2006 17:29:22 -0800
Links: << >>  << T >>  << A >>
richard wrote:
> So, are any of you guys seeing the same sorts of problems?

The last great schematics bundled with Xilinx software is ver 2.1i. The
schematics is very intuitive and very easy to use. The schematic
software that is bundled with Xilinx 3.1i and later is very clumsy. The
diagram looks very ugly too. I have never used Schematics anymore after
they released ver 3.1i

> Doesn't it
> make sense to have a half-hour review of a schematic rather than a
> week-long review of a ream of HDL listings?

It does make sense for one to learn schematic first before learn HDLs.
Schematic forces you to think in term of hardware. In my opinion, it is
not a good idea for one to learn HDL directly without having any
exposure to shematics or get their hands dirty with TTL chips. People
who never learn schematic usually treat HDL just like C. When they do
that,  their codes either do not compile or compile but the result is
totally different from their expectation. HDL has a great advantage
over schematic but one should know the schematic representation of
their HDL codes.

Hendra


Article: 97333
Subject: Re: state-of-the-art schematic generation? [Was: SCHEMATICS ... ]
From: "JJ" <johnjakson@gmail.com>
Date: 20 Feb 2006 17:33:13 -0800
Links: << >>  << T >>  << A >>

Adam Megacz wrote:
> Might be OT, but I'm interested in any pointers to the current
> state-of-the-art in automatic schematic generation.  By this I mean: I
> give it a netlist, it draws what it thinks is a "pretty" schematic for
> some heuristic definition of "pretty".  Even if "pretty" means "just
> barely not hideously ugly".
>
> In the area of mathematical graphs (spline edges, no 90-degree
> requirements -- a very different problem) GraphViz is sort of the
> "reference point" from which everybody else makes improvements:
>
>   http://www.graphviz.org/
>
> ... I'm looking for some similar analogous feature-point for
> schematics rather than general directed graphs.  And yes, I know this
> will never be as good as human-drawn schematics.
>
>   - a
>

A trip to the DAC website and look at the software vendors of EDA
component parts that Synopsys, Synplicity, and others buy from. There
was/is a company in Germany that made these netlist => schematics last
time I went and I chatted with the developer about precisely these
concerns in this thread. He was surprised at my comments, they only
seem to talk with their immediate customer and not final end users so
don't get real feedback. He asked me for examples of bad schematics
that could be drawn better and what the heuristics might be, but I
never took him up on it.

John Jakson


Article: 97334
Subject: Re: SCHEMATICS ... Is anybody as frustrated as I am with the software?
From: "Symon" <symon_brewer@hotmail.com>
Date: 21 Feb 2006 03:08:26 +0100
Links: << >>  << T >>  << A >>
Hi Metal,
Thanks for a good thought provoking post. I added a few 'in my humble 
opinion' thoughts to it! I'd be interested in what you think of them!
"metal" <nospam@spaam.edu> wrote in message 
news:sqjkv19edad40j2oi3kfqj2c5lvvcnso1f@4ax.com...
> >Mark McDougall wrote:
>>>
>>> FWIW, I'd never return to schematics. Yes, top level can be nice as Mike
>>> pointed out, but I find the disadvantages - slow, buggy tools,
>>> cumbersome maintenance, no portability - far outweigh the benefits.
>>>
>>> Regards,
>>> Mark
>
>
> Ironically, even as a 'born again' HDL'er, you just pointed out that
> the "benefits" of HDL over Schematics may not have had anything to do
> with actual benefits; but rather, may have been due simply to the
> abysmal fpga-schematic -tools- that we were all forced to deal with.
>
> Assuming -excellent- schematic tools, the benfits of graphical
> presentation will shine, as they must -always- do.  This is simply
> because the human brain is -wired- to process graphical information;
> and graphical/visual presentation has a higher info-content than plain
> text.
>
> Think of graphical-info as "high level langauge" vs. a screen full of
> text as "assembly", and that'd be a semi-accurate analogy I believe.
>
OK, so this 'pictures are better' idea is not necessarily so. Cro-magnon man 
was great at cave painting. However, as someone once nearly said, I didn't 
get where I am today by looking at pictures. It took the printing press to 
move mankind to the level of technology we're at now.
>
> As I write this, I realize that there are -two- aspects of this issue;
>
> 1)  Design is one (the OP's original subject)
>
> 2)  but Presentation is a 2nd aspect
>
>
> Schematics have it all over HDL for 2), and as Ray pointed out, have
> distinct benefits in top-level design as well.
>
How many textbooks are on your shelf? How many have a list of chapters in 
text, and how many have a picture representing the contents of each section? 
Who says top-level design should be in schematics?
>
>
> I've forgotten who posted about having invested a lot of time in
> setting up an optimized Viewlogic setup; but his description of how it
> operated gave a glimmer of just what an -excellent- FPGA schematic
> front end tool would be like.  Just think if it was easily -2 way- !
>
> Where one was dealing with a major functional block, and it was faster
> and easier to understand visually, you could drop a box on the screen,
> label it, and open an HDL window to 'populate' it.  And where it was
> quicker to just write 3 lines of HDL, you could start with that, and
> have the tool automatically plop a finished and labeled box on the
> screen for you.  You'd be working in both high level visual -and- low
> level HDL code -simultaneously-.  Now -that- would be nice...
>
> Regarding the complaints about drawing "hundreds" of wires coming off
> an FPGA, and having to draw all the caps on the FPGA....c'mon, those
> are both partially specious I think.
>
> In the first place, the vast majority of pins on the vast majority of
> FPGA designs are -bus- lines; which are virtually- always drawn as a
> single line representing 8,16, 32, or more, connections/wires.  Draw
> just 4 or 5 of those, and you've finished 80% of the connections on a
> 160 qfp like a PCI intfc design.  It ain't -that- tough... <g>
>
Yep, in the old days of PQ160s it was easy enough. Now that there are 1000's 
of pins, it's a right royal PITA! It's true you may have  busses connecting 
to the FPGA. The trouble is, you need to connect the bus to the FPGA in a 
manner that reduces the number of layers of PCB you need. If you just whack 
the bus on the side of the schematic symbol, the poor layout guy will spend 
weeks adding layers, vias and God-knows-what trying to route your design. 
Use a picture of the BGA balls (NB. I'm not totally anti-picture!) and work 
out the best pin connections for the bus, and type them into a text file.
>
> In the 2nd place, the convention for bypass caps is to group them all
> on their own schematic; i.e a "power and ground" page.  It is rare
> that I ever see them placed right next to chip symbols on any
> schematic these days.  (one -does- want to remember to pass placement
> notes to the layout-man though! <grin>)
>
> With most modern schem/pcb systems, a dozen bypass caps can be
> instantiated onto the sheet, and connected to GND and 3.3V, in about
> 60 seconds.
>
That's not nearly enough caps. ;-) C'mon, how long does it take to type "12 
Vccint 100nF Caps"? Less than a minute, and you understand it!
>
> In terms of 'readability'...let's all be honest now.  Only the most
> -expert- of HDL designers can look at a multi-page listing of dense
> code and have -any- understanding of what the hell an FPGA -does-, in
> any short time frame (i.e. seconds or minutes).
>
No. For both methods, HDL or schematic, the key to understanding something 
you've just come across, is to read the comments. In text. The signal names 
should be meaningful. Text, text text!!
>
> The rest of us, even most HDL designers, will spend MANY minutes, even
> hours, trying to figure out what the heck the part -does-; let alone
> how it works.
>
> Yet -everyone- could look at a schematic of that chip and gain at
> least a glimpse of the overall functionality in mere -seconds-; and a
> pretty in-depth understanding in perhaps 2 minutes.
>
> For all the rest of the engineers and technicians on the entire
> planet, a schematic of the inside of that FPGA is an -invaluable- aid
> in troubleshooting and repairing the equipment that it's a part of.
>
> I have spent plenty of years on both ends of the stick, design and
> troubleshooting, both my own designs and those of many others; and
> that's how I've learned to value both the code AND the high-level
> visual presentation.
>
> You will notice that even in the pure software world, higher-level
> tools like flowcharters and "code block layout" tools retain a place
> of importance.  Again, graphical/visual presentation is simply more
> -efficient-....it carries more information per visual/brain "bit", so
> to speak.
>
> A single 8x11" schematic page can -easily- represent -many- pages of
> HDL code....and even represent that HDL -and- 10,000 lines of software
> combined.  (i.e. one little rectangle labeled "DSP core for FFT's",
> etc. etc..).  This is an extremely valuable design-method, and
> presentation-type, that we shouldn't be letting escape from our
> toolboxes so blithely.
>
ENTITY DSP_core_for_FFTs IS
PORT(
   CLOCK    : in   std_logic;
   DATA_IN  : in  std_logic_vector(127 downto 0);
   DATA_OUT : out std_logic_vector(127 downto 0)
   );
END DSP_core_for_FFTs;

Pretty clear to me.
>
> I thank the posters who talked about or asked about what tools are out
> there; for both the OP's entirely valid complaint on the current
> offerings; and for the other category of tools to -extract- readable
> schems from HDL code.
>
> I'm a firm believer in HDL as well, and would love to have a toolset
> for automated schema production from code; but in no way does plain
> text replace visual/graphical display of information, imho.
>
>

I'm unconvinced that with today's multi-million gate designs that schematics 
have much of a role. The designs are so complex that a language based 
description is the way the design must be specified. I agree totally that 
the FPGA designer should have a 'view' of the basic hardware they're trying 
to fit their design into, I don't think that has to be a bunch of rectangles 
with legs on! Some well placed block diagrams can do wonders to illustrate 
connectivity and function, but well written text is better!
Finally, if anyone wants to refute any of the points I've made in this post, 
I'd appreciate it if they could express their points in a viewlogic 
schematic. Thanks. :-)
Cheers, Syms.

p.s. OK, that whole post was deliberately provocative, I know YMMV. I don't 
want to tell others how they should design, everyone has their own way of 
doing stuff, this is just my POV!



Article: 97335
Subject: "par.exe" halted without error (partial configuratio)
From: "Pasacco" <pasacco@gmail.com>
Date: 20 Feb 2006 18:44:50 -0800
Links: << >>  << T >>  << A >>
hi

I am having a problem in PAR during Assemble stage in Partial
configuration.
Suddenly PAR is halted, without error, saying that

-----------------------------------
par.exe has encountered problem and needs to close

AppName : par.exe,
ModName : libgi-guide.dll
Offset : 000003556
------------------------------------

Initial budgeting and Module activation are quite ok.
Moreover, everything is okay in modular design setting.

I am using ISE 6.3.03i, Windows XP,

I wonder this is

- guided PAR problem : for example, signal naming problem
- My design problem  : for example, pseudo driver
- My machine problem : for example, OS and computer problem

Thankyou in advance for your comment


Article: 97336
Subject: Xilinx Spartan 3 SSO guidelines for CP132 package?
From: "Andrew FPGA" <andrew.newsgroup@gmail.com>
Date: 20 Feb 2006 19:08:18 -0800
Links: << >>  << T >>  << A >>
Hi,
When I look in the spartan 3 datasheet I can't find any
SSO(simultaneously switching ouput) guidelines for the CP132 package.
The datasheet has it for VQ100, TQ144 and all the FT/FG BGA packages.
But nothing for the CP132. Would it be similar to the BGA packages?

Actually I'm not too sure how the xilinx chip scale package
construction(and hence pin inductance) is different than a xilinx
BGA....?

http://www.semiconfareast.com/csp.htm provides the following
definition:
Chip Scale Package,  or   CSP, based on IPC/JEDEC J-STD-012 definition,
is a single-die, direct surface mountable package   with an area of no
more than 1.2 X the original die area.  The acronym 'CSP' used to stand
for 'Chip Size Package,' but very few packages are in fact the size of
the chip, hence the wider definition released by IPC/JEDEC.

The IPC/JEDEC definition likewise doesn't define how a chip scale
package is to be constructed, so any package that meets the surface
mountability and dimensional requirements of the definition is a CSP,
regardless of structure.  For this reason, CSP's come in many forms -
flip-chip, non-flip-chip, wire-bonded, ball grid array, leaded, etc


Article: 97337
Subject: Re: FPGA - software or hardware -2-
From: hmurray@suespammers.org (Hal Murray)
Date: Mon, 20 Feb 2006 21:36:22 -0600
Links: << >>  << T >>  << A >>
>The background for my question whether an FPGA is viewed as software or as
>hardware comes from the regulations for medical devices.

I'd call it firmware, the idea being that it's easier to change
than hardware but harder to change than software.  But it depends
on who I'm talking to.  If I wanted to be specific for somebody
familiar with the gear we are discussing, I'd probably call it
"the code for XXX" where XXX is the name of the particular FPGA.

I've worked on old microcoded machines that had some RAM for the
microcode.  It was rare, but a couple of good hacks compiled
(micro) code on the fly and loaded it ...

I might call a simple ROM based state machine "firmware" because
I'd probably write a program to generate the contents of the ROM.
For anything but the simplest sort of state machine, it's easier
to hack an existing microcode assembler to do what you want and
then actually write the code in your new assembly language.


>From the perspective of regulatory requirements it makes a difference
>whether an FPGA is viewed as software or as purely hardware because of
>regulatory requirements for medical devices are more comprehensive when
>software is involved.

Ask your lawyer.

Do the regulations say anything interesting about simple software
vs complicated software?

Are you doing anything complicated in your FPGA?  Is it just
glue logic, or do you have complicated state machines?



Software people in general (both coders and managers) have a reputation
for shipping buggy crap.  Hardware guys have a reputation for doing
(much) better.  From what I've seen, it'a a culture thing.  Hardware
projects tend to be expensive to fix so management tends to encourage
doing it right.  That message gets passed around to everybody working
on a project.

I think it's possible to build good software.  It doesn't happen
very often.  I've never worked on a safety critical project.

There is also the complexity issue.  It's easier to build a tower
of cards out of software.  You can make it do something useful
most of the time without paying any attention to the complicated
corner cases.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 97338
Subject: Re: Xilinx Spartan 3 SSO guidelines for CP132 package?
From: "Andrew FPGA" <andrew.newsgroup@gmail.com>
Date: 20 Feb 2006 19:42:01 -0800
Links: << >>  << T >>  << A >>
Apologies embarassing mistake.  I had V1.5 of the datasheet. V1.6 of
the datasheet has this information. Very quick response from the Xilinx
hotline, < 1hr. Was a bit of a foolish question though.


Andrew FPGA wrote:
> Hi,
> When I look in the spartan 3 datasheet I can't find any
> SSO(simultaneously switching ouput) guidelines for the CP132 package.
> The datasheet has it for VQ100, TQ144 and all the FT/FG BGA packages.
> But nothing for the CP132. Would it be similar to the BGA packages?
>
> Actually I'm not too sure how the xilinx chip scale package
> construction(and hence pin inductance) is different than a xilinx
> BGA....?
>
> http://www.semiconfareast.com/csp.htm provides the following
> definition:
> Chip Scale Package,  or   CSP, based on IPC/JEDEC J-STD-012 definition,
> is a single-die, direct surface mountable package   with an area of no
> more than 1.2 X the original die area.  The acronym 'CSP' used to stand
> for 'Chip Size Package,' but very few packages are in fact the size of
> the chip, hence the wider definition released by IPC/JEDEC.
>
> The IPC/JEDEC definition likewise doesn't define how a chip scale
> package is to be constructed, so any package that meets the surface
> mountability and dimensional requirements of the definition is a CSP,
> regardless of structure.  For this reason, CSP's come in many forms -
> flip-chip, non-flip-chip, wire-bonded, ball grid array, leaded, etc


Article: 97339
Subject: Re: FPGA - software or hardware -2-
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 20 Feb 2006 19:56:03 -0800
Links: << >>  << T >>  << A >>

Hub van de Bergh wrote:
> The background for my question whether an FPGA is viewed as software or as
> hardware comes from the regulations for medical devices.
>
Please read the very front of every Xilinx Data Book, where legal
issues like copyright etc are mentioned on page 2, even before the
table of content.
The next-to-last paragraph says:

"Xilinx products are not intended for use in life support applications.
Use of Xilinx products in such applications without the written consent
of the appropriate Xilinx officer is prohibited."

This of course has to do with legal liabilities. So it is serious
stuff.
Peter Alfke, Xilinx Applications (from home)


Article: 97340
Subject: Re: arctangent again
From: Marko <cantsay@comcast.net>
Date: Mon, 20 Feb 2006 22:30:50 -0800
Links: << >>  << T >>  << A >>
Have you considered a power series approximation?  I use that for
sin/cos and it works quite well over a small range.  

On Mon, 20 Feb 2006 22:09:50 GMT, mk<kal*@dspia.*comdelete> wrote:

>Hi everyone,
>I am currently using cordic for arctangent in my system. I need at
>least 12 bits of accuracy. My x,y inputs are less than |1| in the form
>of 2.16. I have made some optimizations to another block in my system
>and it turns out that I have 6 extra slots of 32x32 multiplier
>resource but usage of 4 would be better (because of scheduling
>constraints). I don't have any dividers of course.
>
>Are there any algorithms which would need very few/small roms (which
>can be implemented in combinational logic) and 4 or so multipliers
>(and some adder/subtracters) ? Again I can't afford any dividers.
>Any suggestions are welcome.


Article: 97341
Subject: Re: FPGA - software or hardware -2-
From: "Simon Peacock" <simon$actrix.co.nz>
Date: Tue, 21 Feb 2006 19:45:23 +1300
Links: << >>  << T >>  << A >>
But don't be too scared.. every single electronics company on the planet has
the same disclosure statement.  The best bet is look at aerospace everything
is triplicate.. and there is hardware safety interlocks too.  FPGA's like
software are still subject to gamma and single bit events.  Even if its one
in a million.. you don't want to be that millionth.
Just don't forget.. with medical applications you had better be bloody sure
it works.. or it will be bloody for sure.

Simon

"Peter Alfke" <alfke@sbcglobal.net> wrote in message
news:1140494163.600023.137960@o13g2000cwo.googlegroups.com...
>
> Hub van de Bergh wrote:
> > The background for my question whether an FPGA is viewed as software or
as
> > hardware comes from the regulations for medical devices.
> >
> Please read the very front of every Xilinx Data Book, where legal
> issues like copyright etc are mentioned on page 2, even before the
> table of content.
> The next-to-last paragraph says:
>
> "Xilinx products are not intended for use in life support applications.
> Use of Xilinx products in such applications without the written consent
> of the appropriate Xilinx officer is prohibited."
>
> This of course has to do with legal liabilities. So it is serious
> stuff.
> Peter Alfke, Xilinx Applications (from home)
>



Article: 97342
Subject: Re: FPGA - software or hardware -2-
From: fpga_toys@yahoo.com
Date: 21 Feb 2006 00:21:44 -0800
Links: << >>  << T >>  << A >>

Simon Peacock wrote:
> But don't be too scared.. every single electronics company on the planet has
> the same disclosure statement.  The best bet is look at aerospace everything
> is triplicate.. and there is hardware safety interlocks too.  FPGA's like
> software are still subject to gamma and single bit events.  Even if its one
> in a million.. you don't want to be that millionth.
> Just don't forget.. with medical applications you had better be bloody sure
> it works.. or it will be bloody for sure.

> > "Xilinx products are not intended for use in life support applications.
> > Use of Xilinx products in such applications without the written consent
> > of the appropriate Xilinx officer is prohibited."

The problem is that the regs require similar levels of documented
development processes for life support as they do for any supporting
medical electronics, such as imaging products. The Xilinx and other
disclaimers for life support, are just a small fraction of the
equipment subject to these regs in many places. I spent some time
working in an MRI shop 10 years ago, I was amazed at the regs.

I've seen my share of crap hardware designs go out the door in 35
years, pushed by managers with their feet held to the fire for shipment
schedules, so it's just not a software problem. The problem with most
large software projects, is that the logic complexity is two to four
orders larger than a very large hardware design.  Corner cases sneek
thru in both hardware and software designs. In the old days you would
see a board escape to production in a few revisions. Large ASIC
projects burn a few more mask revs than people would like, but also
fail the simulator pretty frequently for every mask rev .... and we see
large ASIC projects with design errata that are never corrected too.

It's because the software complexity is so much higher, as well as part
of the industry adopting low quality standards for both hardware and
software, that it also makes sense to focus on documented development
process for both, especially software .... not the quality of engineers
working on it.


Article: 97343
Subject: Re: FPGA - software or hardware -2-
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 21 Feb 2006 02:52:33 -0600
Links: << >>  << T >>  << A >>

>The problem is that the regs require similar levels of documented
>development processes for life support as they do for any supporting
>medical electronics, such as imaging products.

How many people know the story of the Therac-25?

Is that life support gear?  Imaging?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 97344
Subject: Re: Inactive signals are active!!! - Chipscope Pro 7.1i - SP4
From: =?ISO-8859-1?Q?Michael_Sch=F6berl?= <MSchoeberl@mailtonne.de>
Date: Tue, 21 Feb 2006 09:54:21 +0100
Links: << >>  << T >>  << A >>
> When I capture some data I have unexpected activity on my signals,
> including the 3 bits that are tied to 0 in the VHDL!!!

> Anyone else experienced this?

a collegue had this problem last week (but I'm not sure about the 
version) ... (I hope I remember correctly)

If you change the port connections with the core inserter tool, then the 
analyzer sometimes fails to update the names and port numbers ...
you end up with some signals toggling that should not and your trigger 
beeing constant ... AFAIR a new analyzer project could help ...


bye,
Michael

Article: 97345
Subject: Re: FPGA - software or hardware -2-
From: Eric Smith <eric@brouhaha.com>
Date: 21 Feb 2006 01:06:44 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Please read the very front of every Xilinx Data Book, where legal
> issues like copyright etc are mentioned on page 2, even before the
> table of content.
> The next-to-last paragraph says:
> 
> "Xilinx products are not intended for use in life support applications.
> Use of Xilinx products in such applications without the written consent
> of the appropriate Xilinx officer is prohibited."
> 
> This of course has to do with legal liabilities. So it is serious
> stuff.

Generally the data books and data sheets for ALL electronic components
say that.  Yet somehow life support devices manage to include electronic
components.  Once Xilinx (or any other vendor) sells you a chip, their
claim that its use in a life support application is "prohibited"
doesn't have any more weight than if I sold pencils and said that
their use to write the answers to homework problems is prohibited.

When the life support system fails, and the heirs sue the company that
made it, the doctor, the hospital, and the vendors of the components
of the system, Xilinx can point to that paragraph and tell the jury
"we tried to keep our customers from using our chips in life support
systems."  The jury may or may not find that paragraph to reduce
Xilinx' liability.

Personally, were I on a jury, I'd give that paragraph very little
weight.  After all, the life support system has to be made out of
*something*.  That said, however, if a particular component failed
and resulted in harm to a person, I'd ask why the designer of the
life support system hadn't designed the system to be fault tolerant
without that component being a single point of failure.

Eric

Article: 97346
Subject: Re: Inactive signals are active!!! - Chipscope Pro 7.1i - SP4
From: "simon.stockton@baesystems.com" <simon.stockton@baesystems.com>
Date: 21 Feb 2006 01:20:39 -0800
Links: << >>  << T >>  << A >>
Thanks for the reply,

I am not actually using the Core Inserter Tool.

I create the ICON core and the ILA core using the Core Generator, then
manually instanciate them into my design and wire them up.

At this point I then use the Core Analyzer to set up the trigger and
capture the data.

Simon


Article: 97347
Subject: Re: multiphase data extraction question
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 21 Feb 2006 09:52:59 -0000
Links: << >>  << T >>  << A >>
"Andy" <jonesandy@comcast.net> wrote in message 
news:1140467697.778272.78510@g47g2000cwa.googlegroups.com...
> We have an application where we need 4 phase sampling of a differential
> (LVPECL) input. I think we found a way to use the IDDRs from the IOBs
> associated with both + and - differential pads on V4 devices to
> accomplish this.
>
Andy,
Neat solution!! You might like to check out Brian's post entitled "DIFF_OUT 
buffer example".
Cheers, Syms. 



Article: 97348
Subject: Re: DDR SDRAM Controller
From: "PeteS" <ps@fleetwoodmobile.com>
Date: 21 Feb 2006 01:59:12 -0800
Links: << >>  << T >>  << A >>
Brendan Illingworth wrote:
> Thank you for the response, it was reassuring.  I am in the process of
> taking a closer look at the timing margins at the controller on our Agilent
> infinium (2.25Ghz BW) scope and hopefully will be able to verify your
> suspicion.  Additionally I have a comment; very rarely when the read cycles
> fail I only see one single rising edge on DQS as opposed to the four I would
> expect for an 8 burst read.  I know that I am "catching" all the DQS
> transisitions as I am looking at the line over multiple read cycles.  Have
> you seen this behavior before?
>
> Regards,
> Brendan

If you are seeing only one (or less than  a burst) of DQS on reads,
then the cycle is being truncated by external command, one way or
another. One common problem that you have to be aware of is the clock
*at the DDR device* is defined by the CLK and #CLK crossing, not the
50% transition. Be sure you are within the spec for clock crossover.
The other possible culprits (according to my habdy DDR datasheet) are
the command bits (See
http://download.micron.com/pdf/datasheets/dram/ddr/512MBDDRx4x8x16.pdf
for a typical DDR part) - see table 6

is a possible burst terminate command (which would do precisely what
you are seeing). As the problem exacerbates with temperature, I would
be suspicious of this, and the timing from CLK/#CLK to the command bus.

Cheers

PeteS



>
>
> "PeteS" <ps@fleetwoodmobile.com> wrote in message
> news:1140445121.929435.112130@g47g2000cwa.googlegroups.com...
> > Brendan Illingworth wrote:
> > > Hi All,
> > >
> > > This post pertains to a DDR SDRAM controller that works perfectly for
> 95% of
> > > DIMMS used, and is part of a test system that contains a 2+ GHz
> oscilloscope
> > > monitoring the clock, command, and dqs signals at the DIMM pins.
> > >
> > > Several DIMMs seem to operate incorrectly only occassional (possibly
> > > temperature dependent), and I suspect that the issue is some type of
> timing
> > > requirement that is on the edge of met and violated.  When the incorrect
> > > behavior is seen the scope verifies that write cylces are operating
> > > correctly but that the read cycles are not operating correctly.  Durring
> the
> > > read cycles the active command is issued, then the read command
> (satisfying
> > > Trcd) and accordingly the DQS signals are provided by the DIMM.  Here is
> the
> > > catch; bursts of 8 was specified durring initialization and the DQS
> signals
> > > durring correct operation correspond to this choice; however, but
> durring
> > > the failing read cycles I will see sometimes 1 DQS rising edge,
> sometimes 2
> > > and sometimes even 5 rising edges!  My questions are as follows:
> > >
> > > 1) Has anyone with DRAM exprience seen any behavior like this before?
> > >
> > > 2) **  What might cause a DDR module to provide a varying number of DQS
> > > strobes?   **
> > >
> > > Recall that the design has no blatent errors since for most DIMMs no
> errors
> > > are ever seen.
> > >
> > > Thanks for any thoughts,
> > >
> > > Brendan Illingworth
> >
> > Most DDR problems are on the read cycle.
> >
> > When you do a read, DDR (unlike other memory) drives not only the bus
> > but also the strobes (as you are clearly know). What you may not know
> > is the amount of variance there can be between devices on the DQS <->
> > data jitter and DQS (read) - clock variance.
> >
> > For those DIMMs you are having problems with, the issue is very likely
> > that DQS is being asserted outside your timing window (so the device
> > is, in fact, asserting a burst of 8 - you simply are not catching it).
> >
> > I have seen this behaviour using commercial parts with DDR controllers
> > built in - the programmable parameters such as DQS skew being there to
> > get around issues just such as this.
> >
> > The causes for this are usually either poor clock/data termination (and
> > in DDR you have to have something even if it's only series, which is
> > do-able in point to point), excessive round trip delay on the clock,
> > excessive added data skew (across D0-Dn vs. DQS) or excessive skew on
> > DQS vs. clock (which moves DQS as received away from the clock) as seen
> > at the receiver.
> >
> > In addition, DDR is not specified to operate below certain speeds,
> > although *most* will. This is a classic gotcha where the internal DLLs
> > won't properly lock to generate read DQS appropriately.
> >
> > The temperature dependency is perhaps to be expected - all logic
> > devices tend to operate a little slower (edge response in particular,
> > but propagation delay tends to increase as well), thus increasing the
> > amount of time before a return DQS is asserted.
> >
> > My first place to look would be DQS skew timing (remembering that the
> > memory device will assert DQS at the leading edge of data - it's up to
> > the controller to determine how to use it to grab the data) in the
> > controller.
> >
> > It took me almost as long, perhaps longer, to set the rules for laying
> > out DDR (I put down 3 independent 200/400 systems on one board) as it
> > did to get it laid out. Even then, my timing budget had about 200
> > picoseconds of guaranteed margin - just what the guaranteed margin is
> > on any particular DIMM is I can't say without a datasheet handy.
> >
> > Cheers
> >
> > PeteS
> >


Article: 97349
Subject: Re: DIFF_OUT buffer example
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 21 Feb 2006 04:07:36 -0600
Links: << >>  << T >>  << A >>
> Yes, that too; the other trick shown in the example is how to keep
>the two IOB DDR clock nets identically loaded by splitting the internal
>logic clock loads out onto another BUFG net.

Does this run into skew problems between the main clock and the IOB clock?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  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
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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