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 87500

Article: 87500
Subject: Re: verilog to blif(lut)
From: jacob.bower@gmail.com
Date: 25 Jul 2005 06:48:58 -0700
Links: << >>  << T >>  << A >>
Although I've never tried this myself, I suspect the easiest route will
be to produce an EDIF file (an industry standard design format) from
whichever synthesis tool you prefer to use, and then convert that to
BLIF.

A quick google lead me to this tool:
http://www.eecg.toronto.edu/~jayar/software/edif2blif/edif2blif.html

junaid wrote:
> Hi All,
>
> Can anyone suggest a method to convert verilog file into blif (LUT)
> format. Does altera or xilinx support this file conversion ?. Kindly
> help me in this regard
> 
> Thanking  you in advance


Article: 87501
Subject: Re: DCM.
From: "Vladislav Muravin" <muravinv@advantech.ca>
Date: Mon, 25 Jul 2005 09:53:21 -0400
Links: << >>  << T >>  << A >>
I think that the problem is in multiply settings, as the minimum value of M 
is 2.
But did not you get a warning in the synthesis about this?

Vladislav


"im.de" <im.de@gmx.de> wrote in message 
news:1122255963.249305.307550@o13g2000cwo.googlegroups.com...
> Hi, there
>
> I am creating a project with Spartan 3 board. and wanna add DCM into
> the XPS 6.2 project under menu "project- add/edit cores(dialog)"
>
> What I want is to get the clock down to clock/2.
> There are 3 moduls in the DCM, I am using the digital frenquency
> synthesizer (DFS).
>
> I added 3 ports: "clkin", "rst" as input, "clkfx" as output in the
> internal ports connections, didnot add anything into the external ports
> connections.
>
> connected the "clkin" to "sys_clk"=50mMHz of the external ports,
> reconnected the clock input ports of other components who HAD "sys_clk"
> as input to the output port "clkfx"
>
> the parameters I have
> c_clkfx_multiply = 1
> c_clkfx_divide = 2
> c_clkin_period = 40.000000 <-----  which i am not sure the use of this
> parameters.
>
> But it did not work out.
>
>
> Anyone has some idea?
> thanks
> 



Article: 87502
Subject: Re: Using unregistered inputs in FSM
From: "Vladislav Muravin" <muravinv@advantech.ca>
Date: Mon, 25 Jul 2005 09:57:01 -0400
Links: << >>  << T >>  << A >>
So, Andre...

What's up?
How are things going?
Are you successful so far?

V

<ALuPin@web.de> wrote in message 
news:1122288612.740510.231080@g14g2000cwa.googlegroups.com...
But if I use a two stage FF synchronizer for NXT_raw
and my answer byte to NXT_Q  is also synchronous that is registered
I would be one 120MHz clock cycle too late  (?)

Rgds
André



Article: 87503
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: Jerry Avins <jya@ieee.org>
Date: Mon, 25 Jul 2005 10:35:47 -0400
Links: << >>  << T >>  << A >>
Fred Marshall wrote:
> "Jerry Avins" <jya@ieee.org> wrote in message 
> news:2qqdnZsKM7QXUn7fRVn-tg@rcn.net...
> 
>>Fred Marshall wrote:
> 
> .....................
> 
>>The bolts were already set into the concrete; what to do? The original 
>>plan was bolting each end with a half-inch pad under it. We bolted one end 
>>with its pad, and left a half-inch gap with no nut on the other end. That 
>>end is supported by the bolt, but not longitudinally constrained by it. 
>>Despite out harsher winters, there has been no cracking yet. But the 
>>California installations weren't "broke", so despite all subsequent 
>>installations using my floating hangers, the old ones weren't fixed. At 
>>least one original southern California trough is now patched.
>>
>>Jerry
>>-- 
> 
> 
> Jerry,
> 
> Well, you didn't have a working model in the context of your application. 
> But you also didn't *prove* that cracking would occur did you?  (If you did 
> then OK - bear with me; I'm not suggesting that you didn't have a valid 
> concern).

Most large structures have expansion joints or are carefully designed 
not to need them. I considered the lack of them in the aerator supports 
do be a design oversight and our consulting engineers agreed.

> What if it had been built for NJ and no failure occurred?  And subsequently 
> the worry came up?
> Should you change the implementation or not?  Your example re: California is 
> perfect!  The worry was apparently sufficiently justified that taking the 
> nuts off in California would have been the smart thing to do.

Not every design flaw jumps up and bites. Carelessness doesn't always 
exact a price. (If it did, most of us would be sorely beaten.) Recall 
that we used a turnkey design. Our engineers adapted it to the soil 
conditions and supervised construction, but they didn't design it. The 
California plants were the responsibility of other owners. The design 
owner modified the plans that applied to new installations. Where we 
slipped pipe over the bolts (kept in place by a nut on the bit of thread 
that protruded) and enlarged the bolt holes, new installations used 
smooth instead of threaded anchor rods. I do not know the weather 
conditions before the California crack, but I was told that the damage 
saw not from an earthquake.

> A lot depends on the change that's contemplated.
> I once had a job solving problems on a system that was in production.  The 
> idea was to solve the problem without introducing any additional parts.  It 
> was a great challenge and fun to solve the problems with that constraint. 
> Very much like removing the nuts.  Mind you, the solutions were changes - 
> but ones that had been asked for.
> 
> So, if all you had to do was remove some redundant nuts in order to make the 
> design "better" then by all means.  These notions are more guidelines than 
> hard and fast rules.

Removing the nuts allows the steel to contract. One must remove the pad 
between the steel and the concrete to allow the steel to expand. That's 
difficult without disassembling the aerator.

   ...

> I'm pretty sure we agree on most of this....

Yes.
> At the core this is more about decision making.  Your folks decided to not 
> make changes in California. 

See above. They weren't my folks. I don't know what the patent holder 
recommended, nor the process use for deciding by the several California 
owners.

>                    Were they driven to that decision because they 
> didn't want to spend the money?  Or, were they driven to that decision by 
> blind allegiance to a "freeze" kind of rule? 

"Freeze" is a bad word in the sewerage business. Requirements change as 
effluent limits are changed by government and communities grow. Our 
plant's sludge incineration system was designed when oil was cheap. The 
presses that separate sludge from water were inefficient but rugged and 
simple. The high water content of the "dried" sludge made continuous oil 
or natural-gas firing necessary to get the poor bugs to burn. (Have you 
ever held a handful of live bacteria? That's what sludge is.) Oil was 
expensive by the time the plant when into operation. Within a few years, 
we replaced the belt presses with more effective vacuum presses at no 
small cost. (An energy-conservation grant helped.) The sludge now burns 
on its own once the incinerators are up to temperature, but the presses 
stank up the whole operations building. So we rebuilt the air handling 
system, including scrubbers for the exhaust air so as not to gross out 
the neighbors. Then we ...    It never ends. Although I'm no longer a 
commissioner, I'm still officially involved, mostly with odor control. 
The plant seems to be as much alive as the bacteria that make it work.

>                                             I'll bet it's the former and, 
> on a comparative basis, I agree with that being the driver even if we might 
> disagree in hindsight (or in foresight) with the decision they made.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

Article: 87504
Subject: Re: Problems installing windrvr.o in Red Hat EL3...
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 25 Jul 2005 15:41:57 +0100
Links: << >>  << T >>  << A >>
SantaBarbara350Z@gmail.com writes:

> I run into a problem when I 'make;make install' the linuxdrivers.tgz
> file from Xilinx.  Any solutions?  I've read about 2.6.x updates and
> such, but I have a 2.4.x kernel.
> 

What exactly is the problem - you haven;t givn us much to go on!

Martin


-- 
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Article: 87505
Subject: Re: DCM.
From: "austin" <austin@xilinx.com>
Date: 25 Jul 2005 08:10:11 -0700
Links: << >>  << T >>  << A >>
All good advice:

Use the CLKDV output with DV=2 (divide by 2)

That is using the DLL part of the DCM, and it will have less jitter
than using the CLKFX output with M=2, D=4 (M=1 is not a valid choice).

If you use the CLKFX to do this, be aware that the min frequency now
applies to the output (CLKFX must be greater than 24 MHz, or whatever
the min freq spec is for the part).

Austin


Article: 87506
Subject: How to look inside a RAM memory
From: "Giox" <giovanniparodi79@yahoo.it>
Date: 25 Jul 2005 08:12:49 -0700
Links: << >>  << T >>  << A >>
Hello everybody, I use FPGA Advantage 6.2 and ISE Xilinx 7.1.
Is there some tool that allows for the verification of the content of a
block RAM (RAMB4_x_y) at simulation time, but without having to
increase step by step the address and monitoring the output DOA? That
is some graphical interface that give a view of a selected RAM cell
Thanks Gio


Article: 87507
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Baxter" <lbax02.spamguard@baxcode.com>
Date: Mon, 25 Jul 2005 08:30:32 -0700
Links: << >>  << T >>  << A >>
The Design can (and shoule) also tell you things that the code doesn't -
like the relationship between functions, the flow of data, etc.

-- 
---------------------------------------------------------------------
DataGet & PocketLog  www.dataget.com
Data Collectors             www.baxcode.com
--------------------------------------------------------------------


"Jerry Avins" <jya@ieee.org> wrote in message
news:8OOdnYevi6v6_3nfRVn-jw@rcn.net...
> Matt Timmermans wrote:
> >
> >
> > In my shop, unless I have to pass an audit, the products of all these
> > activities are mostly code.  At the level you're describing, most of
this
> > code is just interfaces, comments, and glue, but it is real code that
> > becomes part of the project.  After all, it is code that really defines
the
> > algorithms that get used, and the program organization, etc.  The code
will
> > be documented with block diagrams, overviews, various bits of UML, etc.,
in
> > order to communicate its gestalt more clearly, but most of the work here
is
> > code.
>
> The design part consists of deciding what the used will see and what he
> must to. Coding comes after. Design can be a chapter at a time, or the
> whole manual, but at every point along the way, you need a direction.
>



Article: 87508
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "Baxter" <lbax02.spamguard@baxcode.com>
Date: Mon, 25 Jul 2005 08:32:50 -0700
Links: << >>  << T >>  << A >>
I see the Design as a "paper prototype".    It's to test the design and see
if the design is coherent.  Looking for bugs comes at the code level.

-- 
---------------------------------------------------------------------
DataGet & PocketLog  www.dataget.com
Data Collectors             www.baxcode.com
--------------------------------------------------------------------


"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message
news:76u8e1t7eunkn4ml5ckoo0timribme9tgh@4ax.com...
> On 22 Jul 2005 06:01:19 -0700, "steve" <bungalow_steve@yahoo.com>
> wrote:
>
>
> >a prototype can quickly confirm the robustness of a design
>
> Does this imply that the best way to find bugs is to test a prototype?
>
> That's the Bill Gates methodology.
>



Article: 87509
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Mon, 25 Jul 2005 08:33:44 -0700
Links: << >>  << T >>  << A >>
On Mon, 25 Jul 2005 13:16:34 GMT, Bob Perlman
<bobsrefusebin@hotmail.com> wrote:

>On Sun, 24 Jul 2005 22:31:38 -0700, John Larkin
><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>
>>On 22 Jul 2005 06:01:19 -0700, "steve" <bungalow_steve@yahoo.com>
>>wrote:
>>
>>
>>>a prototype can quickly confirm the robustness of a design
>>
>>Does this imply that the best way to find bugs is to test a prototype?
>>
>>That's the Bill Gates methodology.
>
>The Bill Gates methodology is to get someone else to pay you for the
>privilege of testing your prototype.
>


And to get rich off of selling failure. Few of us have that option.

John


Article: 87510
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "bill turner" <google@changent.com>
Date: 25 Jul 2005 08:44:18 -0700
Links: << >>  << T >>  << A >>
Know the design priorities. This means understanding the most critical
requirements.

Understand that all designs are trade-offs between conflicting
requirements and all but one solution are sub-optimal given the
solution space. No matter what design technique you use, including all
diagramming and emergent design processes, this is true. You are not
likely to find the optimal solution.

Depending on the end purpose, and if it truly is highly complex,
multiple design teams are a good idea. They'll have landed upon
differing sub-optimal solutions. Comparing and reconciling the
competing designs can lead to a better sub-optimal solution.

Make sure you fully understand the problem. Break down the problem into
sub problems. This is easiest for me to do in a hierarchical fashion,
but is not the only way. There are many good, non-software engineering
books that talk about problems solving and present diagraming
techniques. If you are serious about design, you should read a few of
these and even play with other diagramming techniques (though don't
necessarily try to impose these non-SE diagrams on the corporation!).
The design does not have to be hierachical, and the implementation
probably should not be.

Prototype the difficult problems.

Support the design with tests (test before code!).

Walk through designs. Absolutely!

Know that requirements change.


Article: 87511
Subject: Re: Using unregistered inputs in FSM
From: ALuPin@web.de
Date: 25 Jul 2005 08:48:53 -0700
Links: << >>  << T >>  << A >>
Hi Vladislav,

I am waiting for the new board release.

When I can test it I will give account.

Rgds
Andr=E9


Article: 87512
Subject: Re: How to look inside a RAM memory
From: ALuPin@web.de
Date: 25 Jul 2005 08:50:03 -0700
Links: << >>  << T >>  << A >>
Are you using Modelsim ?

Rgds
Andr=E9


Article: 87513
Subject: Re: Excalibur full strip simulation on solaris.
From: Phil Hays <Spampostmaster@comcast.net>
Date: Mon, 25 Jul 2005 09:01:48 -0700
Links: << >>  << T >>  << A >>
Antti Lukats wrote:

>Excalibur is DEAD.
>dont use it.

I recently had a discussion with a manager at a large company that
wanted to build a system based on an ARM.  This manager was thinking
about Excalibur until finding out it was not recommended for new
designs, and that there wasn't a replacement.

He had one question I couldn't answer:

Why?

ARM seems to be very popular.  An ARM in an ram-based FPGA with enough
gates to make the interfaces required would have made a nice product.
Not worth rewriting a bunch of software to fit it into a V4 with a
PPC.

Why did Excalibur die?


--
Phil Hays
Phil-hays at comcast.moc (remove moc and add net) should work for
email


Article: 87514
Subject: Re: Best Practices to Manage Complexity in Hardward/Software Design?
From: "scottfrye" <scottf3095@aol.com>
Date: 25 Jul 2005 09:20:50 -0700
Links: << >>  << T >>  << A >>
>... For some
>reason, managers and customers seem to think that software can be
>changed much more easily than mechanical systems... so they do.

Do you think that software is as hard to change as mechanical systems?

or is it possible that, even though software is easier to change than a
mechnical system, it still requires some work and many
managers/customers assume easier change = free change?


Article: 87515
Subject: Re: Excalibur full strip simulation on solaris.
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 25 Jul 2005 18:23:48 +0200
Links: << >>  << T >>  << A >>
"Phil Hays" <Spampostmaster@comcast.net> schrieb im Newsbeitrag
news:lb2ae1l5i3gj9nnbhg00cfr9eikfd3shr2@4ax.com...
> Antti Lukats wrote:
>
> >Excalibur is DEAD.
> >dont use it.
>
> I recently had a discussion with a manager at a large company that
> wanted to build a system based on an ARM.  This manager was thinking
> about Excalibur until finding out it was not recommended for new
> designs, and that there wasn't a replacement.
>
> He had one question I couldn't answer:
>
> Why?
>
> ARM seems to be very popular.  An ARM in an ram-based FPGA with enough
> gates to make the interfaces required would have made a nice product.
> Not worth rewriting a bunch of software to fit it into a V4 with a
> PPC.
>
> Why did Excalibur die?
>
>
> --
> Phil Hays
> Phil-hays at comcast.moc (remove moc and add net) should work for
> email
>

you possible need to ask the lawers of ARM, and you possible do not get an
answer.

Actel is promising soft-core ARM licensing for their PA3 family. But there
is no PA3 silicon shipping as of today.

the chinese nnARM softcore nnARM core, it does synthesise ok, but its very
huge :(, well at least the register
array is done badly as it alone occupies 50% of Virtex-4 LX25, I havent
looked if the rest of the nnARM
is useable if the register bank would be optimized

Antti
PS the nnARM source code should be easy to locate with google if anyone has
interest in it.












Article: 87516
Subject: Exact time-to-Failure data for FPGA devices
From: "Amr Ahmadain" <amrahmadain@gmail.com>
Date: 25 Jul 2005 09:36:00 -0700
Links: << >>  << T >>  << A >>
Hi All,

I was wondering if somebody knows where to find exact time-to-failure
data for FPGA devices. I checked the reliability data available in both
Xilinx and Actel Reliability reports and they both report failure rates
in FITs, from which one can calculate the MTBF.

What I'm looking for is accelerated life testing data and specifically
High Temeperature Operating Life (HTOL) test data expressed in
exact-time-failure not in FITs as given in the reliability reports
mentioned above. Well, I'm not sure if this kind of data exists in the
first place, but no harm from asking:))

Thanks,

Amr


Article: 87517
Subject: Re: Exact time-to-Failure data for FPGA devices
From: "Peter Alfke" <peter@xilinx.com>
Date: 25 Jul 2005 10:01:15 -0700
Links: << >>  << T >>  << A >>
Amr, there is no exact time, only a statistical probability.
ICs do not suffer from a clearly defined wear-out mechanism that would
allow us to predict the end-of-life.
There is a wide variety of factors that affect reliability, and there
is the Arrhenius model that describes the dependence on temperature,
but all predictions are statistical.
And at "normal" temperatures, ICs live a very long life, 20 to 100
years or more.
Most failures are the result of overstress, mostly in the I/O.
Peter Alfke, Xilinx


Article: 87518
Subject: Re: July 20th Altera Net Seminar: Stratix II Logic Density
From: "Paul Leventis" <paul.leventis@utoronto.ca>
Date: 25 Jul 2005 10:01:43 -0700
Links: << >>  << T >>  << A >>
> That is an oversimplification.
> Most transistor area in an FPGA is used for routing switches so it is
> more important how the logic block influences the routing requirements
> than what the area of the logic block is.

Yes, you are correct.  My definition of "silicon area per logic
function" is for the full LAB -- this includes the LE itself, all the
routing-related area, and the secondary signal (clock/enable/clear etc)
goo that is shared between a group of LEs.  This of course complicates
the architectural experiments since you must optimize the LAB size,
secondary signals, and routing fabric for each LE under evaluation.
This is what we try to do.

> Academic results also suggest that it is better to have starved routing,
> e.g. not have all LUTs routable for most designs.

Yes, but academics don't have to deal with angry customers who find out
six months into their design that it won't route.  In practice, we aim
for something like 99% routability in a 99% full device.  Even if this
is (academically) wasteful, there is a cost associated with having an
unroutable part.  And part of the allure of FPGAs is low-risk and rapid
development -- high routability is a necessary attribute to meeting
these expectations.

> Now they instead have devices that cost 25% more but can be copmletely
> utilized. Those are easier to sell.

I can assure you that 25% overstates the cost overhead for
near-guarenteed routability :-)

> No matter what the true benefit of the new architecture is, my guess is
> that "more LUTs" is easier to sell than "better LUTs", so Xilinx made
> the better marketing choice in this case.

Time will tell.  Yes, more things you can point at are easier to
sell... especially when you inflate the count by a further 12.5%.  But
the ALM also got us a big speed boost relative to Virtex-4, which we're
finding is pretty easy to sell too :-)

Regards,

Paul Leventis
Altera Corp.


Article: 87519
Subject: Re: July 20th Altera Net Seminar: Stratix II Logic Density
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 25 Jul 2005 19:05:56 +0200
Links: << >>  << T >>  << A >>
"Paul Leventis" <paul.leventis@utoronto.ca> schrieb im Newsbeitrag
news:1122308095.602710.84700@g14g2000cwa.googlegroups.com...
> > That is an oversimplification.
> > Most transistor area in an FPGA is used for routing switches so it is
> > more important how the logic block influences the routing requirements
> > than what the area of the logic block is.
>
> Yes, you are correct.  My definition of "silicon area per logic
> function" is for the full LAB -- this includes the LE itself, all the
> routing-related area, and the secondary signal (clock/enable/clear etc)
> goo that is shared between a group of LEs.  This of course complicates
> the architectural experiments since you must optimize the LAB size,
> secondary signals, and routing fabric for each LE under evaluation.
> This is what we try to do.
>
> > Academic results also suggest that it is better to have starved routing,
> > e.g. not have all LUTs routable for most designs.
>
> Yes, but academics don't have to deal with angry customers who find out
> six months into their design that it won't route.  In practice, we aim
> for something like 99% routability in a 99% full device.  Even if this
> is (academically) wasteful, there is a cost associated with having an
> unroutable part.  And part of the allure of FPGAs is low-risk and rapid
> development -- high routability is a necessary attribute to meeting
> these expectations.
>
> > Now they instead have devices that cost 25% more but can be copmletely
> > utilized. Those are easier to sell.
>
> I can assure you that 25% overstates the cost overhead for
> near-guarenteed routability :-)
>
> > No matter what the true benefit of the new architecture is, my guess is
> > that "more LUTs" is easier to sell than "better LUTs", so Xilinx made
> > the better marketing choice in this case.
>
> Time will tell.  Yes, more things you can point at are easier to
> sell... especially when you inflate the count by a further 12.5%.  But
> the ALM also got us a big speed boost relative to Virtex-4, which we're
> finding is pretty easy to sell too :-)
>
> Regards,
>
> Paul Leventis
> Altera Corp.
>
Hi Paul,

do have performance data for S-II in fabric speed?

I cant unfortunatly measure it myself as I dont have S-IIs around but I have
measured actual in fabric clock speeds of 950MHz in lowest speed grade V4 -
what would be the case in S-II lowest speed grade? Are 1GHz+ internal
signals possible in the fabric?

Antti



Article: 87520
Subject: Re: Excalibur full strip simulation on solaris.
From: Phil Hays <Spampostmaster@comcast.net>
Date: Mon, 25 Jul 2005 10:26:24 -0700
Links: << >>  << T >>  << A >>
"Antti Lukats" wrote:

>"Phil Hays" wrote:

>> I recently had a discussion with a manager at a large company that
>> wanted to build a system based on an ARM.

>> Why did Excalibur die?

>PS the nnARM source code should be easy to locate with google if anyone has
>interest in it.

Right.  But large companies are not interested in attracting sharks...
I mean lawyers.

Also the clock rate would need to be higher than I think that a
softcore processor written as a student project is likely to achieve.


--
Phil Hays
Phil-hays at comcast.moc (remove moc and add net) should work for
email


Article: 87521
Subject: Re: Excalibur full strip simulation on solaris.
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 25 Jul 2005 19:39:22 +0200
Links: << >>  << T >>  << A >>
"Phil Hays" <Spampostmaster@comcast.net> schrieb im Newsbeitrag
news:gk6ae19lkccq0c5prrse7b7kqg34etu025@4ax.com...
> "Antti Lukats" wrote:
>
> >"Phil Hays" wrote:
>
> >> I recently had a discussion with a manager at a large company that
> >> wanted to build a system based on an ARM.
>
> >> Why did Excalibur die?
>
> >PS the nnARM source code should be easy to locate with google if anyone
has
> >interest in it.
>
> Right.  But large companies are not interested in attracting sharks...
> I mean lawyers.
>
> Also the clock rate would need to be higher than I think that a
> softcore processor written as a student project is likely to achieve.
>
>
> --
> Phil Hays
> Phil-hays at comcast.moc (remove moc and add net) should work for
> email

yes you are right, the core would possible run at 10..20MHz
I am still wondering ARM sharks did run off at those students, its not a
real useable core,
well the reason was possible that the core was not 100% as ARM had license
some source
code to china universities and those students had access to that code

Antti









Article: 87522
Subject: Re: How to look inside a RAM memory
From: "jimwu88NOOOSPAM@yahoo.com" <jimwu88NOOOSPAM@yahoo.com>
Date: 25 Jul 2005 10:45:59 -0700
Links: << >>  << T >>  << A >>
The simulation models for block RAMs use an array to store memory
content. You can view the content of the array like you view any other
variables. 

Jim


Article: 87523
Subject: OnChip Oscillator for Xlinx FPGA's (Spartan-3 available now)
From: "Antti Lukats" <antti@openchip.org>
Date: Mon, 25 Jul 2005 21:16:53 +0200
Links: << >>  << T >>  << A >>
Hi

Xilinx FPGA's are nice but all of them (after XC4K?) do not have any more
access to the OnChipOscillator - it is not usually required also, but in
some rare cases it may be useful to have some OnChip Clock available in case
all external clock sources fail, or do have emergency Watchdog timer to
monitor some events also in the case of external clock circuitry failures.
For this purpose we are developing OnChip Oscillator IP Cores.

http://gforge.openchip.org/frs/?group_id=32

Simple Spartan-3 version is available, it delivers stable 1:1 duty ratio
clock what is in the range of 205-220MHz for S3 -4 speedgrade. Special
versions for other Xilinx families are coming shortly.

Antti
PS to my surprise Lattice EC/XP and also MachXO all have access to their
OnChip Oscillator, so at least in thing Xilinx FPGAs have less features
available to the user.



Article: 87524
Subject: How to implement Evolvable Hardware ?
From: apsolar@rediffmail.com
Date: 25 Jul 2005 12:21:35 -0700
Links: << >>  << T >>  << A >>
Hello Everyone
I am a final year student pursuing my undergraduate research project on
the topic of "Evolvable Hardware". Till date I have a good amount of
information on the topic. Now I want to finish up my project with an
implementation of a evolvable algorithm for the design of a simple
combinational circuit. I am completely clueless about where to start.
It would be really great help if someone could show me the right
direction.
Thank you
Ankit Parikh
Manukau Institute of Technology
Auckland,New Zealand.




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