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
2017JanFebMarApr2017

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 37100

Article: 37100
Subject: RC10000-PP(Serial Number)
From: "Stella, Wang Zhanqing" <wangzhan@comp.nus.edu.sg>
Date: Fri, 30 Nov 2001 11:05:37 +0800
Links: << >>  << T >>  << A >>
Hi, I'm using RC1000-PP board , how can I knew the serial number of the
RC1000-PP borad ?

Thanks



Article: 37101
Subject: Re: SpartanIIE
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 29 Nov 2001 22:05:38 -0500
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote:
> 
> rickman wrote:
> 
> >
> > But the FT package is just a lower profile version of the FG package.
> > There are a lot of applications where height is very, very important.
> > Didn't you go to the web site to find the packaging data sheet? That is
> > where I found it.
> >
> 
> You're absolutely right. Having a class 1 bad day made me blind (CVS crashed
> during an attempted remote checkin and scribbled junk over some files just
> after I found what seems to be the recurrence of an old Synplify bug. !?
> Should have stopped right there & gone out for a beer or 10).  Apologies to
> Xilinx.
> 
> I'm trying to imagine an app that needs a ~0.5mm height improvment & can only
> think of the reverse side of a PCI card where the max component height is
> 0.8'' IIRC.

I assume that you mean 0.08". Is that really true? I am used to 0.1"
being the "standard" back side height for most boards. Even so, the
FG256 is only 0.079" (2 mm). I would bet this is more for PCMCIA, PMC
cards or some similar mezzanine application. Anyone know for sure why
you need 1.55 mm vs. 2 mm component height (FT vs. FG)?


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 37102
Subject: Re: SpartanIIE
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 29 Nov 2001 22:12:45 -0500
Links: << >>  << T >>  << A >>
Falk Brunner wrote:
> 
> "Jan Gray" <jsgray@acm.org> schrieb im Newsbeitrag
> news:9u3knp$53a$1@slb4.atl.mindspring.net...
> 
> > part (the 32x48 CLB = 6144 logic cell XC2S300E), supports tons of
> different
> > I/O signalling standards, and (thank you Xilinx) comes in TQ144 and PQ208
> > QFP packages. "
> 
> Who wants a PQ208 package? I dont want to build a brick wall ;-)
> --
> MfG
> Falk

I think the idea is that they are not BGAs of any type. Not everyone
wants the highest density known to man. Personally I don't think the
CS144 package is used on enough parts, and what ever happened to the
CS280??? That was one with enough IO to be useful and the open center
made routing possible without dozens of inter-pad vias. The FG256 is one
bear to route. The CS144 is nice, but not used on enough parts. Likely
the cavity size won't let many parts fit inside...

Speaking of routing... Anyone know where I can get guidelines for pad
and via layout on these parts? I thought Xilinx had a document
somewhere, but I can't find it on their web site.


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 37103
Subject: Re: FPGA startup current
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 29 Nov 2001 22:24:19 -0500
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> 
> Rick,
> 
> Now we get into the 'voodoo' part of the analysis.
> 
> With a number of devices in parallel the issue becomes complex.  If each
> device requires a current based on the voltage it sees across its terminals,
> there is some small variation of this voltage to current behavior from die
> to die, part to part.  There is also some IR drop in each package, and
> through the board.
> 
> The text suggests that with four times the current, you will succeed, and
> discusses how more than four times is not required even though the peak
> current may exceed the minimum required.  It does not imply you can use less
> than four times the specification.
> 
> No one can say with any certainty that the four parts will power ON with
> less than four times the individual ratings, other than:  we guard banded
> the spec (so the actual current is almost surely less), they won't all
> require the current at the exact same moment, any one device will have the
> total current available to it if the others are not using it yet (or have
> finished using it).
> 
> Austin

I must say that this sounds a lot like "voodoo". 

I am not looking to startup four devices with less than four times
Iccpo. I am questioning the need for Iccpo. I know Xilinx has spent a
lot of time on this and the number is what the number is (until it is
some other number which is what I am waiting for). But if a part can
start with less current in this situation, why can't it start with less
current all the time? 

Lets consider a completely realistic example. You mention that there is
variation between parts and so it is not likely that all four parts will
require the full current. But my understanding is that Iccpo is a MIN
not a MAX. So if the power supply will provide MORE current, the parts
will TAKE it even when ramped within the spec time period. Do I
understand the spec and app note on this? 

So if you have multiple parts in parallel, any one part might have a
lower PO impedance than the others and draw a LARGER than Iccpo current.
This will leave LESS than Iccpo for each of the remaining devices. If
any one of these devices REQUIRE the full Iccpo to come up fully, then
that part will not init correctly. Even with a guard band, how can you
guarantee that there will not be a problem? It is possible that three of
the four devices hog more than their share of the current and the fourth
device is the odd man out. Seems likely to me that the odd man will not
come up...

I don't mean to belabor this point too much. Maybe I should just stop
worrying about it until the new numbers are out?



> rickman wrote:
> 
> > I just found app note 450 about the Spartan II startup current.
> >
> > There is one section discussing the power up of multiple FPGAs that
> > seems to say that you can get by with less than the specified minimum
> > Iccpo. "Assume the supply can source just enough current to meet the
> > total minimum POS current requirement (four times the applicable I CCPO
> > limit). Each FPGA can be modeled as a very low impedance element during
> > power-on. According to this simplified perspective, the power-supply
> > sees four low impedance elements in parallel. If one FPGA takes on a
> > lower impedance value than the others, it will draw more POS current for
> > a shorter time. The other FPGAs accept less current for a longer time.
> > After this fashion, all four FPGAs receive the energy they require to
> > power-on successfully."
> >
> > This seems to be a case where some of the FPGAs do not receive the Iccpo
> > current and yet still power up correctly. I understand that they take
> > longer to bring up, but can't this be done in other cases as well? I
> > would expect Iccpo to be a minimum regardless. No?
> >
> > --
> >
> > Rick "rickman" Collins
> >
> > rick.collins@XYarius.com
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design      URL http://www.arius.com
> > 4 King Ave                               301-682-7772 Voice
> > Frederick, MD 21701-3110                 301-682-7666 FAX

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 37104
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 29 Nov 2001 22:58:55 -0500
Links: << >>  << T >>  << A >>
This is likely not to be a fruitful debate. I think it has been hashed
here before. But I will be happy to make another round of comments. :)

Neil Franklin wrote:
> 
> mrgs1000@yahoo.com (Mark) writes:
> 
> > rickman <spamgoeshere4@yahoo.com> wrote in message news:<3C065266.E43453F@yahoo.com>...
> > > Neil Franklin wrote:
> > > >
> > > > Hint to vendors: if your part has open source support, it gets more
> > > > recommendations ("take that one, it works"), and you get to sell more
> > > > of them. I principially buy video and ethernet cards after consultion
> > > > the on-line support databases.
> > >
> > > Designers don't EVER want to compromize their choice of chip based on
> > > the tools. That would be more like vacationing in Newark because the bus
> > > is cheaper than taking a plane to the Bahamas!
> 
> Which quite a lot of people actually do. Select on price, that is, not
> chose Newark.

But that was my point. By having to settle for a chip that is not what
the designer really wants or needs, he is taking a vacation in a place
where he doesn't even want to be! The economies of FPGA sales (remember
all of this is decided by the profit of the FPGA company, not the
users!) says you cater to your large customers since they make up some
80 to 90% of your profit. 

 
> > > The idea that open source tool support will significantly impact the
> > > sales of FPGA chips is weak at best.
> 
> Short term they may not. Think long term: they pull in more beginners,
> and so in time grow the population of FPGA developers, and so allow
> firms to emply more and so make more FPA projects and that sells more
> chips.

That sounds great, but you missed the significance of my example below.
If a high volume user can make $10 more profit on brand R than on brand
P, he will not likely let the tools decide for him. Not with a volume of
100,000 or more units. He will churn the design and crack the whip on
the engineers and get the design cranked out by hook or by crook. Let's
face it, a million here and a million there and pretty soon you are
counting real money :) 

The small volume customers don't count. The high volume customers will
ALWAYS pick parts on price, not based on what the engineer LIKES to use. 

 
> > > chips in SPITE of the awful toolset they had to use. This was because
> > > the chip was $10 cheaper than the other brand. It ended up costing them
> > > a lot when they had to make revisions, but this was still the best
> > > solution in terms of PROFIT!!!
> 
> If you are at 100'000 or even 1 mio sized series, no doubt this
> holds. But at 100 parts chip cost is not relevant. Tool support is.

At 100 parts, the user is irrelevant. I don't mean to be mean. But I
think both Xilinx and Altera do a pretty good job of supporting the
small customer relative to the amount of profit they generate. Try
getting Lucent (opps Agere) to chat with you about an annual volume of
100 pieces. HA!
 
> > > > > and new devices are released on a weekly basis. I
> > > >
> > > > So that makes about 2 falimies per year industrywide to support. Or
> > > > simply only support a few of them and only use those.
> > >
> > > But a familiy has some 10 different parts in it.
> 
> And a Virtex CLB is a Virtex CLB, whether in XCV50, XCV1000 or XC2S200.

Now you are showing that you have a lot to learn about the problem. I
first heard about 10 years ago that the FPGA companies sell you routing
and throw in the logic for FREE. The point is that way more than half
the chip is routing. WAY, FAR more than half the software is about the
ROUTING, not the CLB. I have written software in school to do logic
minimization and such. The real trick is to efficiently place and route
a part. This is not software you can write in your spare time. But I
would be happy to be proven wrong...

 
> > > Each of those parts has
> > > many packages
> 
> Inserting pin out tables is not that much work.
> 
> > > and several speeds. Just getting the speed info (critical)
> > > is not an easy problem to solve. Without vendor support, you would be
> > > very hard pressed for anyone to trust your data.
> 
> That may be important for the n*100MHz croud. Not everyone is playing
> up there. Just all the potential sound processing applications, for
> one, 48kHz anyone?

48 kHz x how many channels x how many filter taps etc. Not many designs
DON"T push 100 MHz these days. Even at 50 MHz, you have to count your nS
or you end up with a critical path that doesn't work when the die warms
up to operating temp. 

 
> > > It certainly could be done, but the fact that it has not happened yet is
> > > a good indicator that it is harder than you seem to believe.
> 
> So long non-availability of information makes it impossible, any "not
> happened" is 100% explained. Everything else remains speculation until
> that barrier falls.

Only a small part of the process is not documented. That would be the
final step of generating the bit file. As has been pointed out here
before, one of the smaller tasks in designing this sort of software
would be reverse engineering the bit file format. If someone would sign
up to writing a complete, end to end development system, I would happily
spec the bit file for you! Just tell me which part.

 
> > It&#8217;s actually even worse than that. Vendors are constantly
> > re-characterizing the parts and re-releasing updated timing models for
> > previously released parts.
> 
> Again only relevant to the top speed crowd.

You are talking about some 80 to 90% of the users, I would bet.
 

> > This brings up another point, in addition to the place and route
> > tools, you have to also provide the timing analysis tools.
> 
> You know how many home/edu people overclock CPUs? Raise frequency until
> crash, than drop by 10% is the sort of algorithm. It is "good enough"
> for the target audience.

Tell me again who is the target audience, hobbiest?

 
> > It&#8217;s true that new families don&#8217;t get released often, but
> > when they do, you have to practically throw out your place and route
> > software because the architecture changes are too drastic.
> 
> No different from the problems facing the gcc team when supporting
> code generators for new processors. They are presently at well over
> 20 architectures. And yes, some of the code generators suck.
> 
> > doing hand placement for critical circuits. When I switched from
> > Virtex E to Virtex II not only was all of my work in Virtex E
> > worthless, it was a hindrance
> 
> I doubt that "worthless". As ex-VirtexE-er you surely learned VirtexII
> faster than someone with no experience in placing and so also no
> knowledge what sort of pitfalls to look out for. Reuse of knowledge.

We won't know for sure how complex this task is until someone trys to do
it :)

 
> > > > Does not look like you are an average user there. :-)
> > >
> > > Actually, I think he is a typical user. I think every place I have
> > > worked has used beta versions of the chips at one time or another.
> 
> > To be clearer, I am a typical Tier One user of FPGAs. Meaning that the
> > companies I have worked for are high profile international accounts
> > for the FPGA companies.
> 
> Your critique may apply to the situation at top commercial facilities.
> For home/edu (where I am) I would not expect that to be the case.

I would be willing to bet that by the time you got the tools working for
a single chip in a single speed grade in a single package, there will be
two new families from that vendor. 

 
> > know that from a volume standpoint my group uses more FPGAs than any
> > other group.
> 
> Present usage. Think a bit further into the future. There are millions
> of future developers out there. Presently they are playing around
> designing websites. What are they going to go into professionally?
> Websites. Now think if a few 10'000 of them were playing around with
> FPGAs. Whom will they be presenting their workforce to in 5 years?

They will use the parts that offer the best value, not the parts the
offer the "coolest" tools. 


> > plentiful (no longer NDA) but this group would be limited and most
> > likely restricted to hobbyists, students, and a few niche markets
> > which have little competition.
> 
> And that is already usefull.

To the hobbyists! The students get tools for free (as in beer, not
speech) or nearly so anyway. 


> > You can choose to debate this, however, the fact such tools
> > don&#8217;t exist is pretty good support for my argument.
> 
> Nope. Non-existance comes from non-information. Proof for your
> argument will only be available after the information has been
> available for some time and not being used.

I think you have not really looked at the problem to be solved. As I
said above, only the final bit file generation is not disclosed. That
can be reverse engineered. So if anyone were serious about this, it
could be attempted. 

 
> --
> Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
> Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
> - Intellectual Property is Intellectual Robbery

Among your list of avocations do you include FPGA design? Before you get
too excited about the tools, don't you think you should learn from what
has happened to date?


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 37105
Subject: Re: FPGA startup current
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Fri, 30 Nov 2001 16:59:52 +1300
Links: << >>  << T >>  << A >>
rickman wrote:
> 
> Austin Lesea wrote:
> >
<snip>
> I am not looking to startup four devices with less than four times
> Iccpo. I am questioning the need for Iccpo. I know Xilinx has spent a
> lot of time on this and the number is what the number is (until it is
> some other number which is what I am waiting for). But if a part can
> start with less current in this situation, why can't it start with less
> current all the time?
> 
> Lets consider a completely realistic example. You mention that there is
> variation between parts and so it is not likely that all four parts will
> require the full current. But my understanding is that Iccpo is a MIN
> not a MAX. So if the power supply will provide MORE current, the parts
> will TAKE it even when ramped within the spec time period. Do I
> understand the spec and app note on this?
> 
> So if you have multiple parts in parallel, any one part might have a
> lower PO impedance than the others and draw a LARGER than Iccpo current.
> This will leave LESS than Iccpo for each of the remaining devices. If
> any one of these devices REQUIRE the full Iccpo to come up fully, then
> that part will not init correctly. Even with a guard band, how can you
> guarantee that there will not be a problem? It is possible that three of
> the four devices hog more than their share of the current and the fourth
> device is the odd man out. Seems likely to me that the odd man will not
> come up...

 I think the correct model for this sounds like a giant sea of CMOS
gates.
Consider a simple inverter : As Vcc ramps, the GATE junction will ramp
at
appx 50% Vcc, due to the capacitive voltage divider.
This means at appx Vcc of 2 x Vth ( or VthP + VthN ), all GATES will be
in
the transistion from Off/capacitive, to actually functional.
 In this state, they will draw current, not much each, but there are
LOTS of them!
( One million times 1uA -> 1A )
It is mainly a DC effect, but will interact with dV/dT of the supply a
little.

 A Flyback (isolated) switchmode can deliver more current, at lower
voltages, but a
Series (non isolated) mode switchmode cannot.

 Given this model. I'm not sure you could rely on a sequential
'different threshold'
ramp of multiple FPGAs. If they are all the same Batch/Die, they are
likely to
be quite well matched. ( Murhpys law.. )

 It would seem a power switch is cheaper than a bigger power supply ?
Power MOSFETS are getting cheaper and smaller, or a two stage regulator,
where
the second stage is switched and has access to some energy storage...

-jg

Article: 37106
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Kelly Hall <hall@priest.com>
Date: Fri, 30 Nov 2001 06:41:17 GMT
Links: << >>  << T >>  << A >>
Neil Franklin <neil@franklin.ch.remove> writes:

> That may be important for the n*100MHz croud. Not everyone is playing
> up there. Just all the potential sound processing applications, for
> one, 48kHz anyone?

The vendors are giving away decent tools for the low-end FPGAs and
CPLDs these days.  No excuse for a hobbiest to not be able to make fun
stuff in the basement for almost nothing beyond the part price
anymore.

But heck, if you really want to write an open source tool then go
right ahead!  How you spend your free time is up to you.

Or were you merely complaining that there's no free tool for the
newest parts?

Kelly

Article: 37107
Subject: Re: Spartan2 problems with 5V periphery
From: w.sieber@gmx.de (Wolfram Sieber)
Date: Fri, 30 Nov 2001 08:37:26 GMT
Links: << >>  << T >>  << A >>
Hi,
Hi

>Spartan II is 5V tolerant.  
I confirm that in operating mode, but we phoned with the german
support site of XILINX and they tould us following (hopefully correct
translated ;-)

---------------SNIP-----------------
Q:  Might it be possible that Bus- and Control-signals are able to
destroy the FPGA, if these peripheral signals are already high when
2.5V and 3.0V of the SPARTAN isn't present yet?

A: (application engineer) It's NOT IMPOSSIBLE that something like this
occurs, so you should keep the power up sequence 2.5V -> 3.3V -> 5V
(peripheral).
---------------SNIP-----------------

Matter of fact is, that we DO HAVE dying FPGAs in about 3% of power-on
cycles in different applications. But regrettably it's not
reproduceable to fix that problem. 

So, I hope to find someone who had similar experiences and knows what
should be implicitly avoided. 



>The IO's are high impedance to a 5V signal
>until it is configured, and under control of the user logic (then it can
>be tristate, or drive).

>
> http://www.support.xilinx.com/partinfo/ds001_3.pdf
>
>page 1
>
>Austin
>
>Wolfram Sieber wrote:
>
>> Hi folks,
>> does anyone has any experience in SPARTAN II and 5V peripheral
>> components?
>> Are there any known issues about dying FPGAs which are connected to 5V
>> Busses etc. while powering up the system?
>>
>> I've got the strong feeling that SPARTAN 2 could dy, if the 5V
>> components are powered up before the FPGA supply is stable.
>>
>> Is it necessary to keep the peripherals 'disconnected' while powering
>> up?
>>
>> I'm glad about ANY information and espacially experience on the 5V
>> issue and eventually existing  power-up sequence constraints.
>>
>> Thanx in advance
>>
>> Wolfram
>


Article: 37108
Subject: Synplify and clk discovery
From: dottavio@ised.it (Antonio)
Date: 30 Nov 2001 00:52:31 -0800
Links: << >>  << T >>  << A >>
Good Morning ,
today I've to talk about a problem with Synflify, I'm a new user of it
so maybe it is just a stupid problem, here it is :

In my application I've a master clock at 165MHz and 3 derived clock
165/3 , 165/4 and 165/6 , depending on a signal rate_sel I choose by
means of a multiplexer which one of the clock to use, the signal at
the out of the multiplexer is named clk_div_n .

The problem is that I want to put the following constrain :

clk          -> 165  MHz
clk_div_n    -> 55   MHz

but in the constrain editor after compiling I've only clk signal
discovered, for it I've set 165MHz constrain and after compiling again
and mapping I've the following result :

System clock       -> 395  MHz       (...what is this)
clk                -> 87.2 MHz
clk_div_n_inferred -> 78.1 MHz

so clk_div_n is inferred but there's no way to set the right constrain
on it.
Can you help me in set the right constrain to Synplify ver 7.02 ??

Thanks
 Antonio

Article: 37109
Subject: Re: Some question on Synplify
From: dottavio@ised.it (Antonio)
Date: 30 Nov 2001 00:56:37 -0800
Links: << >>  << T >>  << A >>
sunny <sunrise@sunrise.at> wrote in message news:<ee73541.2@WebX.sUN8CHnE>...
> Instead of generating a clock you could generate a clock enable. Thatīs very easy. You only would need two flops, one inverter and one and gate. The enable signals generated by using that circuit has a pulse length of exactly one clock cycle. Just try it

Please excuse me sunny but I've not understand what you mean, you know
I've thrre clocks and a multiplexer, are you telling me to take away
the multiplexer and use 3 clocks with an enable input and a three
state output??
Can you also explain me the way this inverter and "and gate" are
connected ??

Thanks again and excuse me for my inexperience.

Antonio

Article: 37110
Subject: Re: Modelsim
From: "JohnM" <john@calyptechIHATESPAM.com>
Date: Fri, 30 Nov 2001 10:05:46 GMT
Links: << >>  << T >>  << A >>
Have a look at www.symphonyeda.com where you will find a VHDL simulator
called Simili

I think there are some graphic Tcl programs that allow you to look at the
waveforms, but if you design your testbenched for file IO then you should
love this program..... and it is free.

-John

--
JohnM
http://www.calyptech.com
"Ed Browne, Precision Electronic Solutions" <ed_b_pes@swbell.net> wrote in
message news:05uN7.600$oO4.343960630@newssvr11.news.prodigy.com...
> It's appalling that Xilinx would sell a product to design an FPGA/CPLD
> without the ability to simulate the design unless you buy a $1000+
> simulator.  Neither the free version nor the eval version allows testing
on
> anything over 500 lines.  At that limit on my machine, it simply closes -
no
> slowing down.
>
> Does anyone have a lower cost alternative, preferably one that would
accept
> the HDL bencher output?
>
> Ed Browne
> Precision Electronic Solutions
>
> "Theron Hicks" <hicksthe@egr.msu.edu> wrote in message
> news:3BFA68F1.10118196@egr.msu.edu...
> >
> >
> > Leon Heller wrote:
> >
> > > Sorry, I've just checked the Xilinx version. It is only for small
> designs.
> > >
> > > --
> > > Leon Heller, G1HSM leon_heller@hotmail.con
> > > http://www.geocities.com/leon_heller
> > > Low-cost Altera Flex design kit: http://www.leonheller.com
> >
> > It will work with much larger designs.  It just runs slower.
> >
> >
>
>



Article: 37111
Subject: Ballynuey 2 Hostsoftware
From: "Martin" <martin.griwatz@offis.de>
Date: Fri, 30 Nov 2001 11:53:52 +0100
Links: << >>  << T >>  << A >>
Hi y'all,
I am looking for some information on developing hostsoftware for the
Ballynuey 2 board. Who can give me information? Can somebody recomend
sources in the Net?

Best regards and thanx,
Martin



Article: 37112
Subject: Re: RC10000-PP(Serial Number)
From: "Stephen Melnikoff" <s.j.melnikoff@iee.org>
Date: Fri, 30 Nov 2001 11:40:59 -0000
Links: << >>  << T >>  << A >>

"Stella, Wang Zhanqing" <wangzhan@comp.nus.edu.sg> wrote in message
news:191C91BDFE8ED411B84400805FBE794C1C55361F@pfs21.ex.nus.edu.sg...
> Hi, I'm using RC1000-PP board , how can I knew the serial number of the
> RC1000-PP borad ?

The board's serial number is printed on a label on the board.

If you mean the revision number, use the 'diag' tool, select your card, and
type 'info'.

Stephen Melnikoff.

--
Stephen Melnikoff - s.j.melnikoff@iee.org
Electronic, Electrical and Computer Engineering
University of Birmingham, Birmingham, UK




Article: 37113
Subject: Re: How to set timing constraint in Xilinx VirtexII device when using DCM
From: hamish@cloud.net.au
Date: 30 Nov 2001 12:57:53 GMT
Links: << >>  << T >>  << A >>
Kate Meilicke <katem@xilinx.com> wrote:
> Put the period on the input clock to the DCM.  The Xilinx tools will create
> the necessary period constraints for the output clocks of the DCM.

I noticed one issue with regard to automatic propagation of timing
constraints.. it doesn't seem to work with IBUFGDS components. ie
if you put a PERIOD constraint on its input, it won't be propagated
to the output.

There seem to be some funny rules with regard to propagating TNM
properties too. From memory they must be added on the BUFG output,
as putting them on the DCM or IBUFG output won't work. Or something
like that.


cheers
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 37114
Subject: Re: SpartanIIE
From: Magnus Homann <d0asta@licia.dtek.chalmers.se>
Date: 30 Nov 2001 13:58:53 +0100
Links: << >>  << T >>  << A >>
rickman <spamgoeshere4@yahoo.com> writes:

> I assume that you mean 0.08". Is that really true? I am used to 0.1"
> being the "standard" back side height for most boards. Even so, the
> FG256 is only 0.079" (2 mm). I would bet this is more for PCMCIA, PMC
> cards or some similar mezzanine application. Anyone know for sure why
> you need 1.55 mm vs. 2 mm component height (FT vs. FG)?

My understanding is that the FT is thinner because it is. Fewer layers
in the spackage substrate (2 instead of 4).

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

Article: 37115
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl>
Date: Fri, 30 Nov 2001 14:30:09 +0100
Links: << >>  << T >>  << A >>
On 28 Nov 2001 19:37:56 +0100, Neil Franklin <neil@franklin.ch.remove>
wrote:

>P.S. to the @xilinx.com readers here: the often given reason for
>bitstream secrecy was that the PROM->FPGA link allows it to be grabbed
>and disassembled. With V2 the DES stuff was implemented to fix that
>hole. Is there any chance that the V2 bitstream will one day be publically
>(= non-NDA) documented? Perhaps an XAPP for those that want to know?

Ah, at last a motivation for this secrecy. I have often wondered why
they didn't document it. The best I could think of was to make cloning
more difficult.

>> IOW, if I wanted to implement
>> an open-source synthesis tool, which devices should I target? Again,
>> recommendations would be greatly appreciated.
>
>The nearest I have found is to use Virtex/Spartan-II. For these there
>exists JBits. This is an API+library to modify/generate bitsreams. It
>is totally low-level (individual CLB features), driven by Java code (so
>usable to implement own CAE tools), free (as in beer, not as in speech),
>not crippled (such as artificially slowed to make an payware version
>attractive), written in Java (runs on Linux and BSD with Sun JDK).

Thanks for the pointer. It sounds like the next best thing.


Article: 37116
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl>
Date: Fri, 30 Nov 2001 14:30:09 +0100
Links: << >>  << T >>  << A >>
On Thu, 29 Nov 2001 09:47:29 GMT, Reinoud <dus@wanabe.nl> wrote:

>Kees van Reeuwijk wrote:
>> I understand that the scarcity of such software is partly because
>> vendors do not release enough information.
>
>Exactly.
>
>> Are there any modern devices for which this information *is*
>> available?
>
>Not really, but there is a workaround (MPGA):
>
>  http://ce.et.tudelft.nl/~reinoud/mpga/README.html

Thanks for the pointer, but I'd rather try a non-virtual FPGA first. 

Neat idea, though :-)

Article: 37117
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl>
Date: Fri, 30 Nov 2001 14:30:10 +0100
Links: << >>  << T >>  << A >>
On Thu, 29 Nov 2001 10:21:10 -0500, rickman <spamgoeshere4@yahoo.com>
wrote:

>Neil Franklin wrote:
>> 
>> mrgs1000@yahoo.com (Mark) writes:
>> 
>> > Kees van Reeuwijk <C.vanReeuwijk@twi.tudelft.nl> wrote in message news:<3fl90u
>> k0l3mmebi1703urlud5e91rou5af@4ax.com>...
>> > >
>> > > I understand that the scarcity of such software is partly because
>> > > vendors do not release enough information. Are there any modern devices
>> >
>> > I would venture to say that the primary road block to open-source
>> > tools is that they are too dificult to support and keep current for
>> > people to do for free.
>> 
>> As opposed to tons of video and ethernet chips that the Linux people
>> seem to have no great problem with?
>> 
>> Just simply support those chips that members of the open source group
>> use. And the software users then buy those parts.
>> 
>> Hint to vendors: if your part has open source support, it gets more
>> recommendations ("take that one, it works"), and you get to sell more
>> of them. I principially buy video and ethernet cards after consultion
>> the on-line support databases.
>
>I think this is where the analogy between standard hardware support
>under a standard OS and FPGA support under a standard tool fails.
>Designers don't EVER want to compromize their choice of chip based on
>the tools. That would be more like vacationing in Newark because the bus
>is cheaper than taking a plane to the Bahamas! 
>
>The idea that open source tool support will significantly impact the
>sales of FPGA chips is weak at best. The customers who buy lots of chips
>from the FPGA vendors get free tools and often have an FAE parked in
>their facility. I worked at one place where they still used brand Z
>chips in SPITE of the awful toolset they had to use. This was because
>the chip was $10 cheaper than the other brand. It ended up costing them
>a lot when they had to make revisions, but this was still the best
>solution in terms of PROFIT!!!  (brand Z is not meant to be any
>particular company!)


Fair enough, for a volume application.

However, if the FPGA is used for reconfigurable computing, the situation
is different. I'm convinced that the first vendor with both a PCI FPGA
board and an open-source toolset will become extremely popular in hacker
circles. And who knows, it may even become popular in mainstream
computing. 

The big FPGA vendors may not be interested in this market, but I'm
surprised that none of the smaller ones has tried this. (Hint, hint :-)

>> > There are lots of flows for design entry and
>> > simulation,
>> 
>> Just support those that the present maintainers use. And use those
>> that are supported.
>> 
>> > and new devices are released on a weekly basis. I
>> 
>> Huh? As far as I see it Xilinx has so far created about 9 families
>> (2000 3000 4000/Sparten 4000XL/SpartanXL 5200 6200 Virtex/SpartenII
>> VirtexE/SpartanIIE Virtex2) in 15 years. Altera has 8 families
>> (MAX3000 MAX7000 MAX9000 FLEX6K FLEX8K FLEX10K/ACEX APEX Mercury)
>> in over 10 years. Lucent has IIRC 4 families of ORCA. Atmel 2
>> families (4000 6000). Actel I do not know, as I can not read their
>> website (damn Flash and not HTML alternative). And a few other
>> irrelevant manufacturers.
>> 
>> So that makes about 2 falimies per year industrywide to support. Or
>> simply only support a few of them and only use those.
>
>But a familiy has some 10 different parts in it. Each of those parts has
>many packages and several speeds. Just getting the speed info (critical)
>is not an easy problem to solve. Without vendor support, you would be
>very hard pressed for anyone to trust your data. 
>
>It certainly could be done, but the fact that it has not happened yet is
>a good indicator that it is harder than you seem to believe. 

I consider timing info as just another part of the now-secret device
programming info.

However, for reconfigurable computing applications one *could*
characterize each individual device and use that (with a safety margin,
of course).


Article: 37118
Subject: Re: FPGA startup current
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 30 Nov 2001 08:03:59 -0800
Links: << >>  << T >>  << A >>
Rick,

No that is OK.  The concern is real, and in fact, we spent a lot of time
characterizing this so we could state the spec the way we stated it.

Yes, you got the spec right.

The current requirement is a current vs time situation.  As soon as the minimum is
supplied for the required time, it goes away.  So if you have a "hog" he gets fed,
and gets full first (the more current, the less time), and then the other pigs can
get to the trough.

Sorry about the analogy.

Please contact Kim.Goldblatt@xilinx.com if you want the new numbers, now.

Austin

rickman wrote:

> Austin Lesea wrote:
> >
> > Rick,
> >
> > Now we get into the 'voodoo' part of the analysis.
> >
> > With a number of devices in parallel the issue becomes complex.  If each
> > device requires a current based on the voltage it sees across its terminals,
> > there is some small variation of this voltage to current behavior from die
> > to die, part to part.  There is also some IR drop in each package, and
> > through the board.
> >
> > The text suggests that with four times the current, you will succeed, and
> > discusses how more than four times is not required even though the peak
> > current may exceed the minimum required.  It does not imply you can use less
> > than four times the specification.
> >
> > No one can say with any certainty that the four parts will power ON with
> > less than four times the individual ratings, other than:  we guard banded
> > the spec (so the actual current is almost surely less), they won't all
> > require the current at the exact same moment, any one device will have the
> > total current available to it if the others are not using it yet (or have
> > finished using it).
> >
> > Austin
>
> I must say that this sounds a lot like "voodoo".
>
> I am not looking to startup four devices with less than four times
> Iccpo. I am questioning the need for Iccpo. I know Xilinx has spent a
> lot of time on this and the number is what the number is (until it is
> some other number which is what I am waiting for). But if a part can
> start with less current in this situation, why can't it start with less
> current all the time?
>
> Lets consider a completely realistic example. You mention that there is
> variation between parts and so it is not likely that all four parts will
> require the full current. But my understanding is that Iccpo is a MIN
> not a MAX. So if the power supply will provide MORE current, the parts
> will TAKE it even when ramped within the spec time period. Do I
> understand the spec and app note on this?
>
> So if you have multiple parts in parallel, any one part might have a
> lower PO impedance than the others and draw a LARGER than Iccpo current.
> This will leave LESS than Iccpo for each of the remaining devices. If
> any one of these devices REQUIRE the full Iccpo to come up fully, then
> that part will not init correctly. Even with a guard band, how can you
> guarantee that there will not be a problem? It is possible that three of
> the four devices hog more than their share of the current and the fourth
> device is the odd man out. Seems likely to me that the odd man will not
> come up...
>
> I don't mean to belabor this point too much. Maybe I should just stop
> worrying about it until the new numbers are out?
>
> > rickman wrote:
> >
> > > I just found app note 450 about the Spartan II startup current.
> > >
> > > There is one section discussing the power up of multiple FPGAs that
> > > seems to say that you can get by with less than the specified minimum
> > > Iccpo. "Assume the supply can source just enough current to meet the
> > > total minimum POS current requirement (four times the applicable I CCPO
> > > limit). Each FPGA can be modeled as a very low impedance element during
> > > power-on. According to this simplified perspective, the power-supply
> > > sees four low impedance elements in parallel. If one FPGA takes on a
> > > lower impedance value than the others, it will draw more POS current for
> > > a shorter time. The other FPGAs accept less current for a longer time.
> > > After this fashion, all four FPGAs receive the energy they require to
> > > power-on successfully."
> > >
> > > This seems to be a case where some of the FPGAs do not receive the Iccpo
> > > current and yet still power up correctly. I understand that they take
> > > longer to bring up, but can't this be done in other cases as well? I
> > > would expect Iccpo to be a minimum regardless. No?
> > >
> > > --
> > >
> > > Rick "rickman" Collins
> > >
> > > rick.collins@XYarius.com
> > > Ignore the reply address. To email me use the above address with the XY
> > > removed.
> > >
> > > Arius - A Signal Processing Solutions Company
> > > Specializing in DSP and FPGA design      URL http://www.arius.com
> > > 4 King Ave                               301-682-7772 Voice
> > > Frederick, MD 21701-3110                 301-682-7666 FAX
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 37119
Subject: Re: FPGA startup current
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 30 Nov 2001 08:05:26 -0800
Links: << >>  << T >>  << A >>
Allan,

If you think FPGAs are current hogs .....  I saw what the SDRAMs take.....
wow!

Austin



Allan Herriman wrote:

> On 28 Nov 2001 08:14:58 -0800, brad@tinyboot.com (Brad Eckert) wrote:
>
> >At a recent FPSLIC seminar, Atmel's marketing guy mentioned that some
> >FPGAs have high startup current (a couple of amps) so their FPSLIC
> >would have simpler power requirements than a soft CPU.
> >
> >Is this still true? I'm looking at a Spartan II XC2S30 or XC2S15 for a
> >soft CPU. Even a 1A startup current is a little hard to imagine, since
> >you'd expect the logic to start out in a cleared state.
> >
> >Can anyone tell me what kind of startup current to expect from low
> >cost FPGAs like Spartan or ACEX?
>
> In case anyone thinks this sort of behaviour is new, I recall seeing
> an app note in an Intel memory data book from almost 20 years ago that
> showed that their (then new) 5V only NMOS DRAM parts would draw lots
> of current when the supply voltage ramped up to about 1.5V (IIRC).
>
> The cause in that case was that the back bias generator for the
> substrate hadn't turned on yet, and the leakage current in each fet
> was rather large.
>
> The V-I characteristic was something like:
>
> ^I
> |
> |
> |     .           .
> |    . .       .
> |   .   .   .
> |  .     .
> |.
> +------------------------>V
>
> Regards,
> Allan.


Article: 37120
Subject: Re: SpartanIIE
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 30 Nov 2001 17:18:33 +0100
Links: << >>  << T >>  << A >>
"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag
news:3C06F92D.41D20304@yahoo.com...

> I think the idea is that they are not BGAs of any type. Not everyone
> wants the highest density known to man. Personally I don't think the

Sure, if space is not critical, they are fine and easier to use (layout,
probing, manufacturing etc.)

> CS144 package is used on enough parts, and what ever happened to the
> CS280??? That was one with enough IO to be useful and the open center

We used it in one project. . . . caused a lot trouble with the PCB- maker
:-(

--
MfG
Falk





Article: 37121
Subject: Re: Modelsim
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Fri, 30 Nov 2001 16:30:39 GMT
Links: << >>  << T >>  << A >>
"Ed Browne, Precision Electronic Solutions" wrote:
> 
> It's appalling that Xilinx would sell a product to design an FPGA/CPLD
> without the ability to simulate the design unless you buy a $1000+
> simulator.  Neither the free version nor the eval version allows testing on
> anything over 500 lines.  At that limit on my machine, it simply closes - no
> slowing down.
> 

What was appalling was the old Xilinx gate-level simulator.  What a POS.

Xilinx' primary interest is in selling chips, and to that end, they
supply place-and-route tools.  The design-entry front-end tools have
always been someone else's problem.  Consider: The schematic entry used
to be that brain-dead Viewlogic "Pro Series" crap.  (Before that, you
had to supply your own schematic-capture tool!)  Synthesis used to be
the old Metamor tool, then FPGA Express.  If you wanted a better
synthesis tool (and you really DO want a better synthesis tool), you've
gotta pony up for Synplify or Leonardo.

(I haven't figured out where XST fits into all of this.)

Only very recently have Xilinx offered an HDL simulation tool, and it's
adequate for small designs.  But if you're doing Real designs, you're
probably using a Real synthesis tool and a Real simulator.

-a

Article: 37122
Subject: Re: 128-bit scrambling and CRC computations
From: olupas@opencores.org (Ovidiu Lupas)
Date: 30 Nov 2001 08:33:01 -0800
Links: << >>  << T >>  << A >>
> I bet this is a CRC-32 (or CRC-16) being done on an OC-192 at 10 Gbps.
> That is where I saw this done before. The initial signal is bit serial,
> but the payload is being processed in an FPGA at about 80 or so MHz in a
> 128 bit wide word. Just a guess.
> 
Exactly, OC-192 data that has to be processed 128-bit wide at 90 MHz.
Actually, it is an ATM O.191 Test Cell processor, and I cannot afford 
pipelining at this point.

Thanks,
Ovidiu

Article: 37123
Subject: Re: Is there a full open-source synthesis path for any FPGA?
From: mrgs1000@yahoo.com (Mark)
Date: 30 Nov 2001 09:11:48 -0800
Links: << >>  << T >>  << A >>
Parts of original thread sniped...

> That sounds great, but you missed the significance of my example below.
> If a high volume user can make $10 more profit on brand R than on brand
> P, he will not likely let the tools decide for him. Not with a volume of
> 100,000 or more units. He will churn the design and crack the whip on
> the engineers and get the design cranked out by hook or by crook. Let's
> face it, a million here and a million there and pretty soon you are
> counting real money :) 
> 
> The small volume customers don't count. The high volume customers will
> ALWAYS pick parts on price, not based on what the engineer LIKES to use. 
> 

Rick, you are doing a great job of helping me with this debate, but I
can only partially agree here. My experience has been that the only
time tools enter into the equation is if they are so buggy and slow
that they hinder development. I have abandoned FPGA companies based on
this. Aside from that, tools do not factor into my selection process
at all. I pick an FPGA based on performance and features first
(product performance is more important than cost), familiarity with
architecture second (this impacts development time, and therefore time
to market), and price 3rd (once you have met the customer
requirements, and hit the market window, then you want to increase
profit margin). Our difference here is do the fact that I work in
telecom on large systems with low volumes and 2 year design cycles. I
suspect your product is much more commercial, much higher volume.

> > 
> > And a Virtex CLB is a Virtex CLB, whether in XCV50, XCV1000 or XC2S200.
> 
> Now you are showing that you have a lot to learn about the problem. I
> first heard about 10 years ago that the FPGA companies sell you routing
> and throw in the logic for FREE. The point is that way more than half
> the chip is routing. WAY, FAR more than half the software is about the
> ROUTING, not the CLB. I have written software in school to do logic
> minimization and such. The real trick is to efficiently place and route
> a part. This is not software you can write in your spare time. But I
> would be happy to be proven wrong...
> 

In the old days, FPGAs were much simpler. They consisted of a
perfectly symmetrical array of identical logic blocks. That is not
true anymore. The complexity of these devices has gone up
exponentially. CLBs are only a fraction of the issue. Routing is
becoming much more complex also.

> > That may be important for the n*100MHz croud. Not everyone is playing
> > up there. Just all the potential sound processing applications, for
> > one, 48kHz anyone?
> 

The only case where timing is not critical is if no one else is using
your design...meaning it is just your personal toy. A few levels of
logic, and a bad placement can break a 25MHz design in the fastest
Virtex E.

> > > > It certainly could be done, but the fact that it has not happened yet is
> > > > a good indicator that it is harder than you seem to believe.
> > 
> > So long non-availability of information makes it impossible, any "not
> > happened" is 100% explained. Everything else remains speculation until
> > that barrier falls.
> 
> Only a small part of the process is not documented. That would be the
> final step of generating the bit file. As has been pointed out here
> before, one of the smaller tasks in designing this sort of software
> would be reverse engineering the bit file format. If someone would sign
> up to writing a complete, end to end development system, I would happily
> spec the bit file for you! Just tell me which part.
> 

Exactly, it is all there, you just have to dig a little.  I would add
that if you are not good enough to reverse engineer the bit file
format, you are not good enough to do the PAR. However, I think Xilinx
will give you that also.

>  
> > > It&#8217;s actually even worse than that. Vendors are constantly
> > > re-characterizing the parts and re-releasing updated timing models for
> > > previously released parts.
> > 
> > Again only relevant to the top speed crowd.
> 
> You are talking about some 80 to 90% of the users, I would bet.
>  
> 
> > > This brings up another point, in addition to the place and route
> > > tools, you have to also provide the timing analysis tools.
> > 
> > You know how many home/edu people overclock CPUs? Raise frequency until
> > crash, than drop by 10% is the sort of algorithm. It is "good enough"
> > for the target audience.
> 

Again, timing is always important, unless you are not an engineer, or
you are one those sorry engineers whose designs I have had to fix over
and over again, both pre-release and post-release.

>  
> > > It&#8217;s true that new families don&#8217;t get released often, but
> > > when they do, you have to practically throw out your place and route
> > > software because the architecture changes are too drastic.
> > 
> > No different from the problems facing the gcc team when supporting
> > code generators for new processors. They are presently at well over
> > 20 architectures. And yes, some of the code generators suck.
> > 
> > > doing hand placement for critical circuits. When I switched from
> > > Virtex E to Virtex II not only was all of my work in Virtex E
> > > worthless, it was a hindrance
> > 
> > I doubt that "worthless". As ex-VirtexE-er you surely learned VirtexII
> > faster than someone with no experience in placing and so also no
> > knowledge what sort of pitfalls to look out for. Reuse of knowledge.
> 

Believe me you don&#8217;t do multiple several hundred thousand gate
FPGAs without understanding the concept of design reuse. Hard macros
fix placement and routing so they are not compatible between families.
CLBs, Slices, routing switch boxes, routing channels, CLB orientation,
switch box orientation, IOBs, IOB switch boxes...are all different
between VirtexE and Virtex II. In addition a few design strategies
that helped me VirtexE actually hurt me in Virtex II. I couldnt make
progress until I abandoned my old way of thinking. Was it as bad as
switching to Altera, no, but it was bad.

Article: 37124
Subject: Re: Ballynuey 2 Hostsoftware
From: David Hawke <dhawke@xilinx.com>
Date: Fri, 30 Nov 2001 17:25:55 +0000
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------9E0088D62E0A5D14C6FFAF57
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Martin,

You might want to start with Nallatech (www.nallatech.com), since they
wrote it!

Dave

Martin wrote:

> Hi y'all,
> I am looking for some information on developing hostsoftware for the
> Ballynuey 2 board. Who can give me information? Can somebody recomend
> sources in the Net?
>
> Best regards and thanx,
> Martin

--------------9E0088D62E0A5D14C6FFAF57
Content-Type: text/x-vcard; charset=us-ascii;
 name="dhawke.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Hawke
Content-Disposition: attachment;
 filename="dhawke.vcf"

begin:vcard 
n:;David Hawke
tel;cell:(44) 778 875 5002
tel;fax:(44) 1291 621 541
tel;home:(44) 1291 621 655
tel;work:(44) 870 7350 517
x-mozilla-html:FALSE
org:Xilinx UK;Northern European Sales
version:2.1
email;internet:dhawke@xilinx.com
title:Xilinx Field Applications Engineer
adr;quoted-printable:;;Benchmark House=0D=0A203 Brooklands Road=0D=0A;Weybridge;Surrey;KT14 ORH;United Kingdom
fn:David Hawke
end:vcard

--------------9E0088D62E0A5D14C6FFAF57--




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
2017JanFebMarApr2017

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