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 14375

Article: 14375
Subject: Re: Xilinx - Questions on clock & Async delays.
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Wed, 27 Jan 1999 11:33:07 -0800
Links: << >>  << T >>  << A >>
Paul Attilla Richards wrote:
> 
> I'm interested in generating small-stepped delays with FPGA/CPLDs for
> a phased array transmitter,  and initially thinking of Xilinx 4000E &
> 9500 series +M1.5 Foundation, though would happily consider others.
> 
> I've done a bit of design with all synchronous components at 30MHz but
> now need some small time shifts which are probably too small to be
> done by clocking.  I'd welcome any comments or pointers.
> 

Any reasons (e.g. cost, power) for not using off-the-shelf
programmable delay lines or common ECL parts like the 100E195 (2ns delay
range, 20 ps step resolution). There are also parts like
the Cypress Roboclock series which might be useful. Vitesse
has some interesting octal deskew/timing parts coming out too for
ATE applications (VSC 6048,6280/81/82) for 8ns range, 10 ps resolution.

I guess the question is whether this is a self-imposed challenge
(getting precise timing out of imprecise FPGAs) or if there is
something I've missed (doesn't have to be precise, must be cheap,
low power)


regards, 
Tom Burgess
-- 
Digital Engineer
National Research Council of Canada
Herzberg Institute of Astrophysics
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3

Email:        tom.burgess@hia.nrc.ca
Office:       (250) 490-4360 
Switch Board: (250) 493-2277
Fax:          (250) 493-7767
Article: 14376
Subject: Re: The development of a free FPGA synthesis tool
From: "BuckSavage" <wbuckley@transdyn.com>
Date: Wed, 27 Jan 1999 11:34:08 -0800
Links: << >>  << T >>  << A >>
>
>> >     void main() {
>>
>> Interesting, but not C.  main returns int in C.
>
>Oh no, not again !

For my two cents, I can tell you all that I have written
many C programs that do not include a return type
declaration for the MAIN routine, and operating
systems (from Windows NT to VAX/VMS) seem to
be quite accepting of the constructions that I use.

If there is to be a requirement for a return type
declaration, then the statement above should
result in an error being issued by the compiler
upon compilation of the code.  Since such an error
is not reported, then I have to say that it is not
required that a declaration be given.

It is better to be motivated by the practical than
the ideal (though ideals are often worth striving
for), given that the goal is to complete some
useful work.

William R. Buckley



Article: 14377
Subject: Re: multiple clock domains
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 27 Jan 1999 19:36:07 +0000
Links: << >>  << T >>  << A >>
If the clocks are truly asynchronous then the double d-type method only works if
you know the probability distribution of the settling time. Note it could be
arbitrarily long. This distibution is usually expressed as a MTBF based on  (1)
the process characteristics, (2) the async input frequency, and (3) the sampling
frequency.  Parameters for (1) have to come from your vendor - then you plug
these values into a standard formula that will give you the MTBF or (inverted)
the probablility that the output of the first d-type will settle withing the
sampling clock period - Tsetup.

If  it doesn't then you need clock the d-types with  sample-clock/n.


Article: 14378
Subject: Re: Hysteresis on PLD Clock Inputs
From: z80@ds2.com (Peter)
Date: Wed, 27 Jan 1999 20:30:47 GMT
Links: << >>  << T >>  << A >>

Peter, I am sure this is incorrect, for the XC3000 config clock input.

After much work with a 350MHz scope (on a PCB with 32-off XC3064 which
I used to make) I am very sure that even with an extremely clean
waveform the *maximum* risetime is about 30ns. Any slower than that,
and it misconfigures.

>There has never been any problem with combinatorial inputs.
>If they are slow, it just delays the signal and may add some
>power dissipation. The problem is with clocks.In an
>environment without any noise and without any ground-bounce,
>even the incoming clock edges can be as slow as molasses.
>But show me that kind of environment....


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but remove the X and the Y.
Please do NOT copy usenet posts to email - it is NOT necessary.
Article: 14379
Subject: Re: The development of a free FPGA synthesis tool
From: korpela@islay.ssl.berkeley.edu (Eric J. Korpela)
Date: 27 Jan 1999 21:02:17 GMT
Links: << >>  << T >>  << A >>
In article <78np73$gke$1@news-2.news.gte.net>,
BuckSavage <wbuckley@transdyn.com> wrote:
> [ Re: void main() ]
>
>For my two cents, I can tell you all that I have written
>many C programs that do not include a return type
>declaration for the MAIN routine, and operating
>systems (from Windows NT to VAX/VMS) seem to
>be quite accepting of the constructions that I use.

Specifying no return type in C is the same as specifying
"int."  Fuction returns default to "int."  Specifying a
return type of "void" is another thing entirely.  

>It is better to be motivated by the practical than
>the ideal (though ideals are often worth striving
>for), given that the goal is to complete some
>useful work.

As long as your "practical" doesn't require the code work
correctly on various systems, you are free to be "practical"
and ignore the standard.

Eric


-- 
Eric Korpela                        |  An object at rest can never be
korpela@ssl.berkeley.edu            |  stopped.
<a href="http://sag-www.ssl.berkeley.edu/~korpela">Click for home page.</a>
Article: 14380
Subject: Re: Ratings for Synplicity Synplify
From: Geir Harris Hedemark <geirhe@hridil.ifi.uio.no>
Date: 27 Jan 1999 23:08:15 +0100
Links: << >>  << T >>  << A >>
ems@riverside-machines.com.NOSPAM writes:
> Interesting - are you sure about the '93 bits? I put a test case
> through 1998.08 about a month ago, the last time I used DC, and it

Reasonably.

I think they have added some form of crude alias support, at
least. I can't remember what other bits they have implemented.

I can have a look tomorrow, if you want. I think I have some notes
lying around somewhere at work.

Geir

Article: 14381
Subject: Re: Ratings for Synplicity Synplify
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 27 Jan 1999 22:08:25 +0000
Links: << >>  << T >>  << A >>
I've been watching the comments on Synplicity with interest as we have
just bought  it.  It looks like
 I'll have to be careful with CLB  and timing estimates.

On my trial design (75% of the biggest Spartan) the  final  PAR CLB
count was 20% up on the initial estimates BUT  I had MAP in minimum
packing mode. Looking further at the LUT count I could
 see that the final value was  only10% up.  This comes down  to 1% if I
subtract the ``LUTs used as route-throughs'' given by the MAP report.

Also all the other bugs mentioned relate to Sun WS's. Anybody had any
problems running Synplify 5.0.8  under NT on a Pentium II  ? I haven't
had any so far.

BTW Synplify won out over Spectrum on :

o Speed +: Compiles a design that uses 45% of an XC4085 in just over 1
min.

o Language +: Get Verilog and VHDL

o  Fanout +: Explicit fanout of heavily loaded signals good for the
initial stage and tells me where I
     should go and do some more work.

o FSM compiler +:

o Interface +/-: If you insist on batch mode then you have to pay a 50%
premium for a floating license but then you get full Tcl scripting.

o Final results  +/-: After running the respective EDIF files through
the Xilinx tools with no
    timing constraints Synplify had these differences:
     Avg Conn delay : +4%.
      Max pin delay: -25%.
      Avg delay on 10 worst: -10%.

   I'll have to run the TRCE program to find out why

o Bottom Up (small -): Synplify doesn't accept EDIF files as source so
you can't  merge  pre-synthesised  parts of a design together with
whatever  source files you're working on.
I'll have to use NGDBUILD to do this.

The only thing I wish is that HDL Analyst was a little cheaper.

Only bug so far: If your license is near running out Synplify insists on
poping up a little message box
 telling you this and you have to click on OK to make it go away.  Very
irritating when this
 happens  in  batch mode and you're running  on a short eval license.
This will be fixed in 5.1.x.

Article: 14382
Subject: Outsource??
From: "Blake Nelson" <nelson@cstn.com>
Date: 27 Jan 1999 15:45:12 PST
Links: << >>  << T >>  << A >>
We do not recruit!! Just an old fashioned engineering firm.

http://www.cstn.com



Article: 14383
Subject: Re: testing (english?)
From: Brett George <b.george@clarityeq.com>
Date: Thu, 28 Jan 1999 10:51:48 +1000
Links: << >>  << T >>  << A >>
WHAT??

satish_me@hotmail.com wrote:

> Hello I am in the research field of FPGA. Why the PLL's should be used for
> FPGA reprogramming.Please intimate to my hotmail account
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own



Article: 14384
Subject: Re: AHDL VS. VHDL
From: Steve@XXX_REMOVE_XXXrsn-tech.demon.co.uk (Steve Rencontre)
Date: Thu, 28 Jan 1999 01:17:24 GMT
Links: << >>  << T >>  << A >>
On Thu, 14 Jan 1999 22:56:03 +0100, aweas <aweas_rammal@elgems.com>
wrote:

>Hi
>I think a lot of poeple made the transfer from altera's ahdl to vhdl.
>those how did it , can you please give me some feed back about the
>results.
>and info about the transfer to VHDL .
>I'll be happy to get as much answer's as possible

VHDL was not designed as a synthesis language, and it shows. AHDL was,
and it shows too.

In most respects, I think AHDL is a superior language for the task of
designing logic, but VHDL has other uses too, and of course is
(approximately!) device and vendor-independent.

At the end of the day, though, VHDL and AHDL are just two different
programming languages; they're much closer to each other than to
traditional schematic design. If you can write one, you can write the
other.
--
Steve Rencontre, Design Consultant
http://www.rsn-tech.demon.co.uk/  --  remember to despam return address
Article: 14385
Subject: AnyVoltage Altera Downloader, works 1.8 v - 5.5 V
From: eugenef@jps.net
Date: Thu, 28 Jan 1999 01:40:00 GMT
Links: << >>  << T >>  << A >>
FPGA Downloader for Altera FPGA/EPLD - ONLY $75.00

Works with any voltage from target board 1.8 V  - 5.5 V
Replaces Altera ByteBlaster and ByteBlaster MV downloader

You will never need another downloader

Please visit us at:  http://welcome.to/nefdesign.com

Sincerely,

NEF Design, Inc.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14386
Subject: Re: The development of a free FPGA synthesis tool
From: Zoltan Kocsi <root@127.0.0.1>
Date: 28 Jan 1999 13:39:11 +1100
Links: << >>  << T >>  << A >>
seebs@plethora.net (Peter Seebach) writes:

> >However, if you have the so-called free-standing environment, (which is
> >the case with most embedded systems) the main() function:
> 
> >- does not have to exist at all, but
> >- if it exists, it can have any prototype you like, and
> >- does not have to return at all
> 
> Not any prototype *you* like.
> Any prototype the vendor decided to use.
> And they probably have fairly strict standards.

The compiler vendor can not know what do I want to pass to my main() 
and can not force me to use their init stub which will call main.
Actually I have never used the vendor supplied startup for they all
assumed some BIOS-ed environment which has already set up a few things.
In my systems main() is the main entry point of the system, entered 
immediatelly after the reset code set up enough hardware to run C code 
at all. Main never returns (where would it ?) thus it's always declared 
as void, actually volatile void under (cross) gcc.

In a free-standing environment main() is just a function like any other.
There's nothing special about it.

> Anyway, if you refer to standard library functions, you're assuming a 
> hosted environment.

No, I don't. I can happily use strcat() or sprintf() in a non-hosted 
environment. Of course you can not use functions like system() for 
there's no system but you can use the subset of the library which 
is meaningful without a hosting system.

Zoltan

-- 
+------------------------------------------------------------------+
| ** To reach me write to zoltan in the domain of bendor com au ** |
+--------------------------------+---------------------------------+
| Zoltan Kocsi                   |   I don't believe in miracles   |  
| Bendor Research Pty. Ltd.      |   but I rely on them.           |
+--------------------------------+---------------------------------+
Article: 14387
Subject: Re: Xilinx - Questions on clock & Async delays.
From: paul@sosgez.co.uk (Paul Attilla Richards)
Date: Thu, 28 Jan 1999 03:11:08 GMT
Links: << >>  << T >>  << A >>
Many thanks to Ray, Peter, Tom - they were all very useful
suggestions.

Just to clarify a bit ... For some designs I'm interested in
generating a few fixed phase shifted clocks to  satisfy timing
requirements of asynchronous external devices, provided that I can
enforce a permissible range of phase (i.e. skew). If that could be
done by adding some min/max timing constraints then whoopee!   These
output signals are not going to be fed back into any clock input on
the FPGA.   Perhaps it could employ some of the fixed delays inserted
to deliberately delay clocks and data to manipulate the setup and hold
times.  Alternatively create some route-throughs.  Admittedly it does
seem "heretical", trying to do more than one thing per clock cycle,
though this is not going to be at the speed limit of the device.

Regarding the programmable delay line, I would like to keep that
synchronous if it can be done fast enough, but not if it means running
the ICs right at the limit of the spec.   If I have to use external
delay components but then feed the signals back into the FPGA/CPLD to
form the final patterns, then channel matching across pins and devices
must be good.  I appreciate that if the logic funtion is implemented
by a 4-input block on the FPGA, and since the output is not clocked it
could flap about a lot as any input changes.  I may be able to avoid
that using combinational  logic output-devices on 4000Xxx or using the
CPLDs. 

I wasn't thinking of seriously using a tapped asynchronous delay line
for my multi-channel waveform generator.  It's worth trying out.

My current working system could be improved by adding more channels.
Ideally I'll keep the same board form factor and terminals, but get at
least twice the number of channels per card.  If all the logic/delay
networks are compressed into one package (PLCC84?) it leaves room for
extra power components and more self-testing facilities.   The delay
section is relatively small, so the bulk of the FPGA would be handling
7 sets of bitstreams/channel, frequency synthesis, a safety/watchdog
system, and if there's room, some 32 bit arithmetic functions for the
single chip microcontroller on each channel.  

Possibly the delay section could be in a separate CPLD, or in a
manually placed & routed quadrant of the FPGA as suggested.   I need
to learn all about that too.  Any fixed delay offset which is common
to all channels across multiple FPGAs is acceptable, if I can obtain
suitable bounds for it from manufacturers data or from inspection.

Having a lot of relatively simple logic ICs is a waste of power - only
the final outputs need the current drive cabability.  I would hope to
double the number of channels and yet reduce overall logic power
consumption.   (About 75W now.)

Serveral of the ICs in the current design have become obsolete in the
last year, though we bought enough stock for current jobs.  

I shall certianly have a look at the XC4000XLA and Virtex parts, and
posibly set up some experiments to vary temperature & voltage, if I
can't get any data.   I'm intrigued by the 35ps/step delays mentioned,
though 1ns would be fine enough for now.   

The ECL suggestions from Tom were very useful.  I'm put off by the
power consumption and added component space for this project, but I
may find a use in GPS RTK systems.

I considered generating an extra quadrature clock or clocks  for one
FPGA application, with some external means of adjusting the phase.
But I didn't have any spare pins.   I was even using the mode and JTAG
port pins.   On the one hand I'd like to use a bigger package with
more pins.  On the other, the output delays are even worse!

--------

Thanks again for your comments and very speedy responses.

Paul Richards
SRD Ltd UK

Article: 14388
Subject: Re: The development of a free FPGA synthesis tool
From: "BuckSavage" <wbuckley@transdyn.com>
Date: Wed, 27 Jan 1999 20:25:07 -0800
Links: << >>  << T >>  << A >>
>As long as your "practical" doesn't require the code work
>correctly on various systems, you are free to be "practical"
>and ignore the standard.


I meant to suggest the "void" type, as opposed to specifying
no type.  Doing so will render the code compilable and
executable on all systems that I have used, in spite of any
standard requirements to the contrary.

Practical can mean: Since standards are often not followed
exactly (consider RS-232), do what works and forget the
standard as necessary.

As for the desire for code to work "correctly on various
systems," I have yet to identify a system where a "void"
type specification on the "main" routine renders the code
error laden, non-functional, etc.

Give me a specific example of some system upon which
either:

    a. such a specification yields a compile-time error, or
    b. a run-time error, even if the error appear only upon
        a normal termination of the program (i.e. the error
        is determined when processor control is returned
        to the operating system upon program termination).

IMHO, there are no operating systems which fail upon the
return of a program written in C which fails to provide a
return code, and if there are such operating systems, then
they contain design faults.  I can think of many situations
in which a program does provide a return code, which
return code is not forwarded to the operating system.  In
the cases that come to mind, the trouble will be external
to the program and the operating system.  Clearly, the
stability of an operating system is questionable if it is
subject to failure simply because a program fails to
provide a return code.

William R. Buckley


Article: 14389
Subject: Re: The development of a free FPGA synthesis tool
From: seebs@plethora.net (Peter Seebach)
Date: Thu, 28 Jan 1999 05:46:07 GMT
Links: << >>  << T >>  << A >>
In article <78np73$gke$1@news-2.news.gte.net>,
BuckSavage <wbuckley@transdyn.com> wrote:
>For my two cents, I can tell you all that I have written
>many C programs that do not include a return type
>declaration for the MAIN routine, and operating
>systems (from Windows NT to VAX/VMS) seem to
>be quite accepting of the constructions that I use.

Well, of course!  There's a lot of shoddy code out there.

I know there exists at least one compiler which will notice
	i = ++i;
but most will accept it.

>If there is to be a requirement for a return type
>declaration, then the statement above should
>result in an error being issued by the compiler
>upon compilation of the code.

Many do.  gcc does on a few platforms (especially in -Wall, as of about
2.8.x), and the old VAX C was famed for complaining about this when invoked
in some common mode.

>Since such an error
>is not reported, then I have to say that it is not
>required that a declaration be given.

False conclusion.  Not all errors require a diagnostic message; in fact,
very few do.

>It is better to be motivated by the practical than
>the ideal (though ideals are often worth striving
>for), given that the goal is to complete some
>useful work.

If it were harder to declare main correctly than incorrectly, this
would be a wonderful argument.

Note followups.

-s
-- 
Copyright 1999, All rights reserved.  Peter Seebach / seebs@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Send me money - get cool programs and hardware!  No commuting, please.
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Article: 14390
Subject: Re: The development of a free FPGA synthesis tool
From: seebs@plethora.net (Peter Seebach)
Date: Thu, 28 Jan 1999 05:49:06 GMT
Links: << >>  << T >>  << A >>
In article <78ooaj$6cv$1@news-2.news.gte.net>,
BuckSavage <wbuckley@transdyn.com> wrote:
>I meant to suggest the "void" type, as opposed to specifying
>no type.  Doing so will render the code compilable and
>executable on all systems that I have used, in spite of any
>standard requirements to the contrary.

You mentioned VAX/VMS, and yet, people have often reported that the
normal system compiler there chokes on non-int declarations of main.
You might want to double-check.

>As for the desire for code to work "correctly on various
>systems," I have yet to identify a system where a "void"
>type specification on the "main" routine renders the code
>error laden, non-functional, etc.

So?  What's the *advantage*?

>Give me a specific example of some system upon which
>either:

>    a. such a specification yields a compile-time error, or

VAX/VMS, also 'gcc -Wall -Werror'.  (Which is a good start.)

>    b. a run-time error, even if the error appear only upon
>        a normal termination of the program (i.e. the error
>        is determined when processor control is returned
>        to the operating system upon program termination).

Almost everything; including, for instance, every Unix I've ever used.

	$ exec /bin/ksh # any POSIX shell will work
	$ PS1='$?:$ '
	0:$ /path/to/void/main/program
	83:$ _

The number '83' may vary, may be 0, or may do just about anything - but it's
an error return.

>IMHO, there are no operating systems which fail upon the
>return of a program written in C which fails to provide a
>return code, and if there are such operating systems, then
>they contain design faults.

What do you expect them to do?  They're expecting an exit status.  What
should they do when you give them random numbers?

>stability of an operating system is questionable if it is
>subject to failure simply because a program fails to
>provide a return code.

Define "failure" - perhaps just reporting that the program indicated failure
by means of a return code which doesn't indicate success?

Anyway, this is a FAQ.

-s
-- 
Copyright 1999, All rights reserved.  Peter Seebach / seebs@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Send me money - get cool programs and hardware!  No commuting, please.
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Article: 14391
Subject: Re: Ratings for Synplicity Synplify
From: Andrew Brown <andrewbr@nortelnetworks.com>
Date: Thu, 28 Jan 1999 10:22:49 +0000
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:

>
>
> o Language +: Get Verilog and VHDL
>
>

But you can't use verilog and vhdl in the same design !

Andrew.


Article: 14392
Subject: Re: HEX file format
From: jollye@removethis.thmulti.com (Emmanuel JOLLY)
Date: Thu, 28 Jan 1999 17:11:57 GMT
Links: << >>  << T >>  << A >>
Hi,

look there:
http://www.wotsit.org/binary.htm

regards

E. JOLLY

On Fri, 15 Jan 1999 12:25:42 +0900, "Kang YI" <yk@comp.snu.ac.kr>
wrote:

>Hello,
>
>I'll appreciate if you let me know the Intel HEX file format.
>
>Thank you.
>
>Kang YI.
>
>

Article: 14393
Subject: ALTERA: Configuration problem of 10K50VRC240-3 + EPC1PC8
From: jollye@removethis.thmulti.com (Emmanuel JOLLY)
Date: Thu, 28 Jan 1999 17:35:03 GMT
Links: << >>  << T >>  << A >>
Hi,

I have a problem on one design where there is one EPF10K50VRC240-3
which is configured at power-up by one EPC1-PC8. The schematics has
been check by ALTERA's rep. in France and should be OK. The problem is
the following:

Sometimes, my design doesn't download from the EPC1 to the ALTERA. If
I look at the signals with an oscilloscope I can see that CONF_DONE is
low and nSTATUS is low also. According to AN59 nSTATUS should be high
to enable the EPC1. As nSTATUS is low, the download process cannot
take place.

This problem is correlated with the temperature of the device. When
the environnement is warm, the download process takes place but when I
cool down the chip (with a cooling spray) it doesn't download.

Any ideas??

Regards.
E. JOLLY

Article: 14394
Subject: Re: Ratings for Synplicity Synplify
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Thu, 28 Jan 1999 13:27:01 -0500
Links: << >>  << T >>  << A >>
Andrew Brown wrote:
> 
> But you can't use verilog and vhdl in the same design !
> 
> Andrew.

And with Spectrum.... You can.

-- 
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>
Article: 14395
Subject: Re: The development of a free FPGA synthesis tool
From: korpela@islay.ssl.berkeley.edu (Eric J. Korpela)
Date: 28 Jan 1999 19:26:27 GMT
Links: << >>  << T >>  << A >>
In article <78ooaj$6cv$1@news-2.news.gte.net>,
BuckSavage <wbuckley@transdyn.com> wrote:
>
>Give me a specific example of some system upon which
>either:
>
>    a. such a specification yields a compile-time error, or
>    b. a run-time error, even if the error appear only upon
>        a normal termination of the program (i.e. the error
>        is determined when processor control is returned
>        to the operating system upon program termination).

Frankly, I would consider that to be any operating system that
allows the caller to test for sucessful execution of a program.
These operating systems include DOS, Windows, all unix systems, 
and VMS.  The error is not by default reported to the user under
these system.  However the error indication does exist and may
influence the execution of future programs.  (Actually the DEC 
VAX C compiler will not allow a "void main()" at compile time.)

>IMHO, there are no operating systems which fail upon the
>return of a program written in C which fails to provide a
>return code, and if there are such operating systems, then
>they contain design faults. 

I would agree that any fault in a program should not affect
the stability of an operating system.  That doesn't mean your
programs shouldn't work properly because they can't crash the
system.

Consider the follow unix shell script:

#! /bin/sh
if ( $* ) 
then
  echo Program $* executed sucessfully.
else
  echo Program $* either didn't work.
fi

Often it will report that a program with a void main()
declaration did not work properly.  In some cases a reported failure
could cause an exit from a batch job, command script, or another executable
that calls the program.

> I can think of many situations
>in which a program does provide a return code, which
>return code is not forwarded to the operating system. 

Feel free to provide an example of an OS that does not accept return 
codes from applications.

I'm not sure I understand what your big problem with "int main()" is.   
Are you arguing that any code that works once is by definition correct
everywhere?  IMHO, the whole "if it doesn't generate an error it must
be correct" is a poor standard for program quality.  

Eric
-- 
Eric Korpela                        |  An object at rest can never be
korpela@ssl.berkeley.edu            |  stopped.
<a href="http://sag-www.ssl.berkeley.edu/~korpela">Click for home page.</a>
Article: 14396
Subject: Mirotech boards.
From: Khaled benkrid <k.benkrid@qub.ac.uk>
Date: Thu, 28 Jan 1999 20:04:26 +0000
Links: << >>  << T >>  << A >>
Hi All,

Has anybody ever used a Mirotech FPGA board ( X-CIM, ARISTOTLE...).
These boards contains DSPs on boards. Any experience will be helpful.

Cheers.

Article: 14397
Subject: Re: FPGA express warning
From: Khaled benkrid <k.benkrid@qub.ac.uk>
Date: Thu, 28 Jan 1999 20:06:26 +0000
Links: << >>  << T >>  << A >>
Hi Evan,

It is what you have said in the first case. I tried to put an intermediate signal in
between, but the problem remains.

Khaled.


Article: 14398
Subject: Re: Off topic DRAM/SIMM question....
From: Bill Moffitt <compass@connect.net>
Date: Thu, 28 Jan 1999 14:27:04 -0600
Links: << >>  << T >>  << A >>


Austin Franklin wrote:

> Even if I've identified the chips organization, I still don't understand
> why 12 chips.  10 chips I would understand if it had 4 bit parity, and 8
> chips with no parity.
>
> Austin

This is probably a "downgrade" module.  The chips have been remarked by the
downgrade memory module manufacturer.  It looks like the module was made mainly
from sorted x4 chips that only had x3 good bits.  One or two of the chips may
have sorted out at x1, or x2.   Buyer beware....

--
Bill Moffitt



Article: 14399
Subject: Re: FPGA express warning
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Thu, 28 Jan 1999 14:08:07 -0800
Links: << >>  << T >>  << A >>
At the risk of being tiresome....

If the modules are instantiated in the .xnf, and their .xnf or .ngo files
are in the directory when you optimize, then the logic connected to those
signals must have ended up on the cut list in the optimization report.  Is
that the case?  If so, you need to trace through the list to find out why.
If one output is not connected because of a typo, then all the inputs
associated with it could go away.

bruce


Khaled benkrid wrote in message <36AE7492.D1E29BA7@qub.ac.uk>...
>Hi Bruce,
>
> The box your mentionned is checked. The problem is that there are some
ports
>which are connected
>to IPAD and others not (I have already looked at the XNF file ). The
description
>of the warning message says :
>"The pad mapping optimization step assumes that if a port in the top design
does
>not have a net attached to it that no pad cells ". These are inputs and
>connected to input pins of  lower components in the hierarchy, that's why
they
>are not attached to any net in the top level. There are no errors or
warnings
>before the optimization phase ( bug?).
>
>
>Khaled.
>
>
>




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