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 81425

Article: 81425
Subject: Re: Xilinx ISE 7.1 - Can this get any worse?
From: Jedi <me@aol.com>
Date: Wed, 23 Mar 2005 13:32:54 GMT
Links: << >>  << T >>  << A >>
Subroto Datta wrote:
> Hi Big,
> 
>     We'd like to hear your view about how Quartus can be made better for 
> your needs.
> 

Always like the topological display of VHDL modules in other tools
like ispLever or Actel's Libero...

It is painful to import a VHDL design into Quartus and manually
arrange the file order...

Ah yeah..when is Altera striking with a free Linux version? (o;



rick

Article: 81426
Subject: Re: PowerPC soft-core?
From: "Jan Gray" <jsgray@acm.org>
Date: Wed, 23 Mar 2005 13:33:53 GMT
Links: << >>  << T >>  << A >>
Very nice Antti!  No need to resort to LFSRs after all.  Next, we're all 
looking forward to a (slow) compact nybble serial MicroBlaze 
reimplementation. :-)

Jan Gray



Article: 81427
Subject: ISE 7.1 on Fedora Core 3
From: "B. Joshua Rosen" <bjrosen@PleaseDontSpamMEpolybus.com>
Date: Wed, 23 Mar 2005 08:36:20 -0500
Links: << >>  << T >>  << A >>
There is a simple work around for the libcurl problem with the 7.1
installer, just link the newer libcurl library to libcurl.so.2. This will
allow you to install 7.1.

ln -s /usr/lib/libcurl.so.3.0.0 /usr/local/lib/libcurl.so.2

Once installed the CLI tools work fine however the ISE GUI has a number
of problems. The first thing that happens is an RPC error,

Cannot register service: RPC: Unable to receive; errno = Connection refused
unable to register (registryProg, registryVers, tcp)
Wind/U Error (248): Failed to connect to the registry on server wasp.bjrosen.com
Cannot register service: RPC: Unable to receive; errno = Connection refused
OLE API Function OleInitialize is not currently implemented.  Further
warnings will be suppressed

I'm guessing that this is a kernel issue, FC3 uses 2.6.10 while RHEL3 uses
the ancient 2.4.21 kernel. Does anyone know a work around for this, is
there something that needs to be compiled into the 2.6.10 kernel?

More seriously the file browser doesn't work, you get a path name to long
error if you try to access anything that is outside of the local
directory. However you can work around this by typing in the explicit
paths to open files. If you open an existing project things work fine. I
use HDLmaker to build my Xilinx projects, the 7.1 tools work fine with
HDLmaker built projects.

http://www.polybus.com/hdlmaker/users_guide/



Article: 81428
Subject: Re: OPB component for serial Flash?
From: Kolja Sulimma <news@sulimma.de>
Date: Wed, 23 Mar 2005 15:35:49 +0100
Links: << >>  << T >>  << A >>
Matthias Alles wrote:
> Hi!
> 
> I want to store the program code for the Microblaze processor in my 
> serial configuration Flash and use a bootloader to copy it to the 
> external memory. Is there an OPB component available that connects to 
> the serial Xilinx Flash, when the Flash is connected to the FPGA like on 
> the Spartan3 Starter Kit Board?

You can use general purpose I/O and do bit twiddling in software.
It's a bit strange solution in an FPGA, but you do not need to add your 
own hardware to the OPB.

Kolja Sulimma

Article: 81429
Subject: Re: ISE 7.1 on Fedora Core 3
From: Sylvain Munaut <com.246tNt@tnt>
Date: Wed, 23 Mar 2005 16:13:45 +0100
Links: << >>  << T >>  << A >>
You need portmap installed and started. Then the browser will work fine.

Article: 81430
Subject: Re: PowerPC soft-core?
From: "JJ" <johnjakson@yahoo.com>
Date: 23 Mar 2005 07:23:49 -0800
Links: << >>  << T >>  << A >>
Hi Jan

I've wondered about how trully RISC PPC really is. Ironic that it comes
out of the work of John Cocke and the 801, the current PPC seems to be
RISC in actual performance but much harder to describe than other RISCs
esp DLX, MIPS or ARM.

RISC ISAs are always characterized by the target technology on which
they are 1st implemented, hence poor FPGA efficiency unless thats where
you/we start.

If IBM were starting today on a fresh ISA with the memory wall in mind
(100s of dead cycles per cache miss), I would think/hope they would
come up with something entirely different.

I would suggest that RISC ness could well be defined by how easy it is
to build an ISA simulator and how close that runs to the hosting
platform. The closer it runs to host, the less peripheral things the
ISA must do per opcode. Clearly PPC, ARM, SPARC all do alot more than
simple datapath operations but all are defined with specific HW
features in mind so their soft cores are all big to start.

The PearPPC emulator that runs on x86 to allow running MacOSX
supposedly runs about 500 x86 ops per PPC op (from Pear site). The 68K
emulators seem to run far closer to x86 performance perhaps because
they are far "simpler" to understand. Generally the goal of emulation
is to reach about 10x slow down. PearPC only achieves better
performance closer to 50x slower IIRC through use of a JIT but the 68K
JITs are still far better.

It amuses me to think that an emulated 68K running MacOS7 must run
orders faster (acceptably so on Basilisk) than an emulated PPC running
the much heavier OSX, just where is the world going!

The new Transputer also runs its ISA simulator closer to host speed
(60x slower in plain C). Perhaps I should have started with the
approach to build fastest possible ISA encoding with x86 native asm
simulator in mind but it wouldn't much effect final HW architecture,
just encodings. Perhaps really fast emulation of new ISA should be at
top of todo list of architects to help propagate new cpus, certainly to
get something running ASAP.

regards

johnjakson at usa dot com


Article: 81431
Subject: Re: XC3000 non-recoverable lockup problem
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 23 Mar 2005 07:48:55 -0800
Links: << >>  << T >>  << A >>
lecroy,

Regardless of what any piece of paper claims, it is the memory of many 
here that the only way to recover is by powering down.

As a 15 year old problem, it is one that we only have our (failing) 
memories to rely upon.

There was no answer database in those days.

There was no hotline.

Austin

lecroy7200 wrote:
>>The oscillator itself is at a much higher frequency, and is divided down
>>to the number listed in the data sheet.  At least, we still do it that
>>way, even today.
> 
> 
> This is not what the data sheet states.  The 4000 data sheet makes a
> distinction that it runs at 8MHz and divides down to the 1MHz where the 3000
> is at 1MHz.  I am not disagreeing with you.  I believe that the 3000 was
> changed overtime and the clock was part of these changes and now runs at
> around 16MHz.  The documents were never updated to reflect this change
> because it was "transparrent" to the end user.  Of course this is all a
> guess on my part.
> 
> 
>>The accuracy of this oscillator would be from 1/2 to 2X the nominal (it
>>just isn't critical).
> 
> 
> Agree, it just needs to work.  Too bad it seems to have problems.
> 
> 
>>Since this part still had paper schematics (REALLY) it is far too old
>>for us to go look at its design.
> 
> 
> Funny,  we can still pull up our paper documents if needed.  I agree, its
> not fun but sometimes you just have to roll up your sleves and dig in.
> 
> 
>>Phil is on the right track.
>>
>>This part did have a brownout issue (if the the voltage dropped just
>>right, for just the right amount of time, and came back up) that would
>>place it in a locked state that could not be recovered until the power
>>was cycled.
> 
> 
> Again, I read Xilinx's app. note on the brown out  problem and it makes it
> clear that the part can be reset without removing power.  I don't disagree
> that the internal logic could get into a locked state and that there was not
> a problem with brown out.  I also think it is very possible that the current
> devices being sold could have a second problem with the internal oscillator.
> There is no mention anywhere about the oscillators failing to start or
> locking up in the brown out app. note.  I am sure if Xilinx would have known
> this, it would have been documented and the power cycle requirements would
> have been called out, which they are not.
> 
> 
>>I solved this problem 15 years ago by using a Dallas Semi Power on Reset
>>part to reset the power supply if it detected a glitch.
> 
> 
> Again, power cycling the device, no matter how it could be done, is not an
> option for this system.
> 
> It sounds like Xilinx is not willing to dig into the root problem of the
> oscillator.  I can understand this to some degree.  After all the software
> has not supported the device in several years.   So my next question is if
> you are able to tell me if the oscillator design used in the currently sold
> 3000s is being used in other Xilinx devices?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

Article: 81432
Subject: Re: XC3000 non-recoverable lockup problem
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 23 Mar 2005 07:51:58 -0800
Links: << >>  << T >>  << A >>
lecroy,

If repowering the device will return the part to a state where it can be 
programmed, then I have to say it is a bad device.

Trying to infer the operation by sniffing for a oscillator that is the 
wrong frequency sounds suspicious.

Austin

lecroy7200 wrote:

>>>Do you recall how low the Vcc had to cycle, in order to correctly
> 
> recover ?
> 
>>As I recall, it had to go below 150 mV to 300 mV to recover.
>>
> 
> After testing the second failure, I tried the power cycle test again.  The
> second part behaved the same as the first.  Removing power from the device
> and shorting the supply (much less than 150mV) for over 1mS would not cause
> the oscillator to restart (observing it with the spectrum analyzer).
> 
> 
> 
> 
> 
> 
> 
> 

Article: 81433
Subject: Re: ISE 7.1 on Fedora Core 3
From: "B. Joshua Rosen" <bjrosen@PleaseDontSpamMEpolybus.com>
Date: Wed, 23 Mar 2005 11:11:09 -0500
Links: << >>  << T >>  << A >>
On Wed, 23 Mar 2005 16:13:45 +0100, Sylvain Munaut wrote:

> You need portmap installed and started. Then the browser will work fine.

Portmap is installed but it's dead. When I do a status on portmap I get 

Executing /etc/rc.d/init.d/portmap status ..

portmap dead but subsys locked

Any ideas about how to get portmap to work?

Article: 81434
Subject: Re: XC3000 non-recoverable lockup problem
From: "lecroy7200@chek.com" <lecroy7200@chek.com>
Date: 23 Mar 2005 08:40:36 -0800
Links: << >>  << T >>  << A >>
> lecroy,
>
> If repowering the device will return the part to a state where it can
be
> programmed, then I have to say it is a bad device.

Austin, not to make fun of the situation, but I really have no idea
what you are trying to tell me in this statement.

>
> Trying to infer the operation by sniffing for a oscillator that is
the
> wrong frequency sounds suspicious.
>
> Austin

I am sorry, but again I must be missing something.  Are you stating
that you don't believe my test results and that looking at the devices
internal oscillator with a spectrum analyzer is not a valid test??


Article: 81435
Subject: DSP designs that exceed provided embedded arithmetic hardware
From: "Ken" <aeu96186@NOSPAM.yahoo.co.uk>
Date: Wed, 23 Mar 2005 17:41:46 +0100
Links: << >>  << T >>  << A >>
Hi folks,

This question is aimed at those who have created designs including DSP using 
a device family containing dedicated arithmetic silicon (e.g. Xilinx 
DSP48/18x18s/Altera DSP blocks):

On what % of designs you have completed did you run out of dedicated 
arithmetic blocks and have to implement filters in the main logic fabric?

Thanks very much for your time,

Ken




Article: 81436
Subject: Re: XC3000 non-recoverable lockup problem
From: "lecroy7200@chek.com" <lecroy7200@chek.com>
Date: 23 Mar 2005 08:53:30 -0800
Links: << >>  << T >>  << A >>
Well, it's not just any piece of paper, it's the Xilinx published
papers.  I agree, it does appear that the documents for this device
were not kept up.

I don't know if the problem is 15 years old or not.  Is it tied to when
the oscillators frequency was changed to 16MHz, it is possible.  I am
guessing that this happend after 1997 when the 4000 data sheet I have
was published.   Again, its all a guess on my part.  Xilinx would need
to answer this.

The problem now is how to prevent it with the next design.  The first
step is to determine if the design used for the currently sold 3000
series oscillators was used in other devices.  If so, I plan to stay
clear of these.


Article: 81437
Subject: Re: Problem writing Pinouts on Webpack
From: Tim Good <elp04trg@sheffield.ac.uk>
Date: Wed, 23 Mar 2005 17:07:34 +0000
Links: << >>  << T >>  << A >>
Hi,

You did not say which version of ISE you were using but I have had it 
working for version 4.2,  5.1 & 6.3.

I have a few things for you to check:
(1) Have you created an Implementation constraints file (.UCF) and is it 
associated with the top level of your design?  It should appear as a "U" 
module immediately below (and indented) your top levels "V" entry in the 
"Sources in Project" list.   If not add new source of type 
"implementation constraints file".......

(2) Uses the Edit Constraints(text) option in the processes list (in the 
"User Constraints section) you should see some lines like...

	NET "ssg<0>"  LOC = "E14"  ;
	NET "ssg<1>"  LOC = "G13"  ;
	NET "ssg<2>"  LOC = "N15"  ;
	NET "ssg<3>"  LOC = "P15"  ;
	NET "ssg<4>"  LOC = "R16"  ;
	NET "ssg<5>"  LOC = "F13"  ;
	NET "ssg<6>"  LOC = "N16"  ;
	NET "ssg<7>"  LOC = "P16"  ;

where "ssg" is the name of the signal in your top level entity 
declaration.  You can put the lines in the UCF manually, the definitions 
are in the examples on Digilent's web site.


Hope this helps,

Tim

Article: 81438
Subject: Re: DSP designs that exceed provided embedded arithmetic hardware
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 23 Mar 2005 09:17:46 -0800
Links: << >>  << T >>  << A >>
Hey Ken,
It's often the other way round for me, sometimes I'd run out of fabric and 
BRAMs for distributed arithmetic DSP unless I used the multipliers for 
boring 'normal' DSP. Of course, all my designs are carefully planned, so I 
never actually run out of resource. Ahem.
Anyway, why do you ask?
Cheers, Syms.
"Ken" <aeu96186@NOSPAM.yahoo.co.uk> wrote in message 
news:d1s68b$u73$02$1@news.t-online.com...
> Hi folks,
>
> This question is aimed at those who have created designs including DSP 
> using a device family containing dedicated arithmetic silicon (e.g. Xilinx 
> DSP48/18x18s/Altera DSP blocks):
>
> On what % of designs you have completed did you run out of dedicated 
> arithmetic blocks and have to implement filters in the main logic fabric?
>
> Thanks very much for your time,
>
> Ken
>
>
> 



Article: 81439
Subject: Re: XC3000 non-recoverable lockup problem
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 23 Mar 2005 09:35:37 -0800
Links: << >>  << T >>  << A >>
lecroy,

No one changed the frequency of any oscillator.

The layout has been shrinking so as to be able to be fabricated, that is 
all.

Did the oscillator go from 8 MHz to 16 MHz over this period of time?

Maybe.

But, for you to infer something from a 16 MHz signal is suspect:  does 
failure to configure 100% correlate with this signal?

If you power it down, and back on, can it be reprogrammed?  If not, it 
is a bad part.  If it can be reprogrammed, then it is a good part (as 
far as configuration is concerned).

If you have a case open with the hotline, what have they said, and what 
are they doing?

If you do not have a case open with the hotline, then you should have 
one open.

Austin


lecroy7200@chek.com wrote:

> Well, it's not just any piece of paper, it's the Xilinx published
> papers.  I agree, it does appear that the documents for this device
> were not kept up.
> 
> I don't know if the problem is 15 years old or not.  Is it tied to when
> the oscillators frequency was changed to 16MHz, it is possible.  I am
> guessing that this happend after 1997 when the 4000 data sheet I have
> was published.   Again, its all a guess on my part.  Xilinx would need
> to answer this.
> 
> The problem now is how to prevent it with the next design.  The first
> step is to determine if the design used for the currently sold 3000
> series oscillators was used in other devices.  If so, I plan to stay
> clear of these.
> 

Article: 81440
Subject: Re: Difference between simulation types
From: Preben <64bitNOspamNO@mailme.dk>
Date: Wed, 23 Mar 2005 20:16:21 +0100
Links: << >>  << T >>  << A >>
Jeremy Stringer wrote:
> Preben Holm wrote:
> 
>> can anybody tell me the real difference between
>>  - behavior (guess this is pure VHDL)
> 
> 
> This is purely behavioral - it literally just simulates what the VHDL 
> describes, without any device-specific timing or anything.
> 
>>  - post-translate (guess this is after synthethis)
>>  - post-map
>>  - post place and route (guess this is when the design is "final" and 
>> is known where to be put in the FPGA)
> 
> 
> Post place-and-route simulates the behavior with timing, after the 
> design has been fitted into the device.  I assume that post-map and 
> post-translate just have less, or less accurate, information (I don't do 
> these type of simulations).
> 
> As an example:
> 
> foo: process(clk)
> begin
>     if rising_edge(clk) then
>         if rst = '1' then
>             dout <= '0';
>         else
>             dout <= din;
>         end if;
>     end if;
> end process foo;
> 
> In a pure behavioral simulation, dout would change exactly on the clock 
> edge.  In a post place and route simulation, it wouldn't - it would take 
> into account the delay of the flip-flops, and also the routing delay 
> from the output to the next input - this might be, say, 5 ns later.
> 
> Jeremy

Post-map also takes care of some delays - but which ones.
I can't use the post place and route, cause I can't count on this, when 
I don't simulate the whole design since the routing will not be correct?

Article: 81441
Subject: Re: XC3000 non-recoverable lockup problem
From: "lecroy7200@chek.com" <lecroy7200@chek.com>
Date: 23 Mar 2005 12:07:15 -0800
Links: << >>  << T >>  << A >>
> No one changed the frequency of any oscillator.

I will see if I can locate one of the pre 97 devices to verify this.
We may some some in stock in our area.  I will let you know what I
find.

> The layout has been shrinking so as to be able to be fabricated, that
is
> all. Did the oscillator go from 8 MHz to 16 MHz over this period of
time?
> Maybe.

> But, for you to infer something from a 16 MHz signal is suspect:
does
> failure to configure 100% correlate with this signal?

Well, there is certainly nothing that prevents Xilinx from running
their own tests to validate what I am seeing.  I certainly can not
force them to do so.
I am 99.9% confident that the 16MHz is from the 3000's internal
oscillator and that this is the fundimental frequency.  I see this
signal on every working device and no where else. It is a very loose
frequency, it tracks with the individual device's temperature and it
has the most energy from my sweeps.

So far there is 100% correlation of the failure, but we are only
talking one data point.  I can also tell you that once I reset the
power that the 16MHz signal for that device was present (again which it
was not while in this failed state) and the part began to function
normally.

The oscillator locking fits with what I am seeing, not being able to
reprogram the devices.

> If you power it down, and back on, can it be reprogrammed?

Again, this depends what you mean.  Looking at the power on the device,
I can bring it below what I can detect for over 1mS and turn it back on
and the part will not allow me to reprogram it.  Nor will the
oscillator start running. I have to remove power for a much longer time
in order for the oscillator to start and allow me to reprogram.  This
appears to be the case with all six failures I have seen, in that they
need the power removed for several seconds inorder to recover.

> If not, it
> is a bad part.  If it can be reprogrammed, then it is a good part (as

> far as configuration is concerned).

Agree.  Again, out of the six times I have now seen this, the failure
has not appeared to cause any damage to the devices.

> If you have a case open with the hotline, what have they said, and
what
> are they doing?

I am not so sure this is the place to discuss this.  If you want the
persons name I have been in contact with, or the case number feel free
to send me a direct e-mail.  During the first contact I was asked if I
was the person posting in this forum, to which I responded yes.  I
explained in detail what I knew at the time, including providing exact
part numbers and lot codes for the parts I was testing.  I was told by
the person I spoke with that this was outside what the hotline could
handle and that it would be elevated to a higher group and that they
would get back with me.  I continued to work on the problem and made
the comment in one of my postings about not yet hearing back from
Xilinx.  That same night I received and e-mail from the hotline as
follows:

"It's been a few days since we last communicated, and I wanted to check
in.
Since this device isn't officially supported by the hotline any longer,
I'm
having to do a fair amount of work to find any information on it here.
I'll
keep investigating this, and I'll let you know when I come across
anything
that hasn't been tried already according to the suggestions on
comp.arch.fpga."

Later after reproducing the failure I tried to contact the support
group and left a voice message stating what I had found and asked for
them to return my call.  After I did not hear back from them for
several hours I continued my testing.  Once I discovered the oscillator
problem I again tried to contact support and left a second voice mail.
Again, there was no return call.  On my third attempt I finally spoke
with my original contact and was told that you were the expert at
Xilinx and that your posting about the part being designed on paper was
correct and that there was nothing they could do.  Google groups was
down that day and I was not able to read your posting, so they
forwarded me your post. I still have the case number open, and if I
learn anymore about the problem I will try and contact them again.

So, now that we have established you as being the expert at Xilinx the
question becomes if you can help.  I am setting up one more test to
determine the state of the program/done pin prior to attempting to
reprogram the device after the failure.  I will publish these findings
once I have them.  Also, if I am able to locate an older device and
test it, I will publish what I find on the internal oscillator.


Article: 81442
Subject: Re: DSP designs that exceed provided embedded arithmetic hardware
From: "Ken" <aeu96186@NOSPAM.yahoo.co.uk>
Date: Wed, 23 Mar 2005 21:14:42 +0100
Links: << >>  << T >>  << A >>
> Hey Ken,
> It's often the other way round for me, sometimes I'd run out of fabric and 
> BRAMs for distributed arithmetic DSP unless I used the multipliers for 
> boring 'normal' DSP. Of course, all my designs are carefully planned, so I 
> never actually run out of resource. Ahem.
> Anyway, why do you ask?
> Cheers, Syms.

Hi Syms,

Thanks for your reply.

The general consenus as far as I am aware seems to be that designers will 
want to use dedicated FPGA silicon blocks that will accomplish a given task 
before implementing such tasks on the generic fabric.

I am just curious to see exactly how designers are using the "lego blocks" 
they have available to them hence I thought I would see what the inhabitants 
of this ng do.

Cheers,

Ken








Article: 81443
Subject: Re: Power Net Seminar Announcement
From: vbetz@altera.com
Date: 23 Mar 2005 13:04:43 -0800
Links: << >>  << T >>  << A >>

John_H wrote:
> The next Thursday March 11th is in the year 2010 so I figure you mean
March
> 24th as it says in the link  :-)  I hope the talk is informative (for
a
> reasonable engineer).

Whoops, that was quite the typo!  Yes, I meant Thursday, March 24.
Although 2010 would certainly give me lots of time to prepare :).

Hope you enjoy it.

Regards,

Vaughn
[v b e t z (at) altera.com]


Article: 81444
Subject: Re: XC3000 non-recoverable lockup problem
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 24 Mar 2005 10:32:27 +1200
Links: << >>  << T >>  << A >>
lecroy7200@chek.com wrote:
<snip>
> So far there is 100% correlation of the failure, but we are only
> talking one data point.  I can also tell you that once I reset the
> power that the 16MHz signal for that device was present (again which it
> was not while in this failed state) and the part began to function
> normally.
> 
> The oscillator locking fits with what I am seeing, not being able to
> reprogram the devices.

  I would expect (generally speaking) a Config Ring osc to gate itself 
off, after config is completed.
  What does a normally operating device show - does this osc appear
to gate in normal usage ?

> 
> 
>>If you power it down, and back on, can it be reprogrammed?
> 
> 
> Again, this depends what you mean.  Looking at the power on the device,
> I can bring it below what I can detect for over 1mS and turn it back on
> and the part will not allow me to reprogram it.  Nor will the
> oscillator start running. I have to remove power for a much longer time
> in order for the oscillator to start and allow me to reprogram.  This
> appears to be the case with all six failures I have seen, in that they
> need the power removed for several seconds inorder to recover.

  It may pay to get a closer number on that - < 5 seconds and > 1ms is 
quite wide...
  Most vanilla buried POR cells are RC in nature (tho the R may be a
FET ), and they will have a TIME as well as a voltage requirement for 
reset. Austin has given ~150mV-350mV region as voltage, but no one
have a time value yet.

  You could ask Xilinx explicitly if newer devices have any buried POR 
cells, that are not also replicated by a RESET ?

  I would expect this type of oops to be eliminated :)

-jg


Article: 81445
Subject: Re: Xilinx backups
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 23 Mar 2005 14:39:11 -0800
Links: << >>  << T >>  << A >>
Well that begs another question. I am a post DOS Xilinx user. I understand
that DOS is still being supported and I am a bit of a DOS dinosaur myself.
So does it behove me to start making batch files and processing stuff
using DOS batch files?



Article: 81446
Subject: Re: ISE 7.1 on Fedora Core 3
From: "Herb T" <oth3ll0@hotmail.com>
Date: 23 Mar 2005 14:49:31 -0800
Links: << >>  << T >>  << A >>
B. Joshua Rosen wrote:

> Once installed the CLI tools work fine however the ISE GUI has a
number
> of problems. The first thing that happens is an RPC error,
>
> Cannot register service: RPC: Unable to receive; errno = Connection
refused
> unable to register (registryProg, registryVers, tcp)
> Wind/U Error (248): Failed to connect to the registry on server
wasp.bjrosen.com
> Cannot register service: RPC: Unable to receive; errno = Connection
refused
> OLE API Function OleInitialize is not currently implemented.  Further
> warnings will be suppressed
>
> I'm guessing that this is a kernel issue, FC3 uses 2.6.10 while RHEL3
uses
> the ancient 2.4.21 kernel. ..

This smacks of an issue with Bristol's Wind/U Windows emulation on
Unix/Linux (http://www.bristol.com/crossplatform/). If I'm not
mistaken, you may need to do more research on how Bristol's libraries
are resolving their linking issues. 'ldd' and 'nm' may help you on this
path. I don't think it has anything to do with the kernel, but then
again I don't know for sure since I don't know from a source code point
of view.
-Herb


Article: 81447
Subject: Re: ISE 7.1 on Fedora Core 3
From: "Herb T" <oth3ll0@hotmail.com>
Date: 23 Mar 2005 14:59:56 -0800
Links: << >>  << T >>  << A >>
way back when i was using bristol, process 'scm' had to be online for
OLE to do anything. i don't know what's going on today, or if bristol
elimated the scm process (which I had heard from the engineering dept)
in favor of other methods.

another suggestion you could use is install on a RHEL3 system and do
some comparisons process and other wise.

i don't know why you want FC3 to work so bad, since you will probably
spend a lot of time trying to get it to work while your design schedule
lags.

for some reason too you've fixated on the "kernel". you may want to run
the kernel config utility to see what the hell is really in the kernel,
and make it less of a mystery.  you will find it just adds support for
new hardware devices, a few file systems and the like, and nothing to
do with the issues you are having.

also consider running strace so you can see your software stack.
-HT


Article: 81448
Subject: Re: XC3000 non-recoverable lockup problem
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 23 Mar 2005 15:19:12 -0800
Links: << >>  << T >>  << A >>
lecroy,

I have found the case, and the CAE assigned, and I am working with 
Peter to resolve this.

So, your support for this issue is now Peter Alfke and Austin Lesea. 
All I can say is that if we can't help you, then no one can, so you can 
not complain about not getting the best resources assigned to the job!

Basically, as an officially usupported part (end of life, last time buy 
status, etc. ...), we will do what we can.

Peter and I are the only ones here who remember anything  about the XC3000.

The hotline was unable to follow through on this due to the age of the 
part, and the total lack of information on it.  In future, we will 
provide the hotline for a way to deal with this other than just getting 
frustrated.

I apologize for that on the part of Xilinx.  It is a situation that we 
had not anticipated (support of an obsolete product).

I suggest we move this off of this forum.

Austin

Article: 81449
Subject: Re: Xilinx ISE 7.1 - Can this get any worse?
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Wed, 23 Mar 2005 23:23:06 GMT
Links: << >>  << T >>  << A >>
Hi Jedi,

> Always like the topological display of VHDL modules in other tools
> like ispLever or Actel's Libero...

Can you expand on this? Haven't got the slightest idea what you mean. I'm
envisioning a Mercator projection of desing blocks on a map...

> It is painful to import a VHDL design into Quartus and manually
> arrange the file order...

Yep. Dunno whether there's work on this, but you're right, doing a 2-pass
parse/compile/elaborate would be handy. Then again, this would mostly make
sense when building a project for the first time. Maybe something for the
New Project Wizard.

> Ah yeah..when is Altera striking with a free Linux version? (o;

I'm pushing for this as well. Would you be OK with a GUI-less version?
(anyone interested raise their hands!). Altera pays royalties on the GUI
under Linux and Solaris, so if you can get by without a GUI, Altera can
truly ship something free.

Best regards,



Ben



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