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 99825

Article: 99825
Subject: Re: deglitching a clock
From: "mike_la_jolla" <mdini@dinigroup.com>
Date: 29 Mar 2006 16:51:23 -0800
Links: << >>  << T >>  << A >>
Put me *SQUARELY* in category 1.  You have a HW problem that demands a
re-layout.  The kludges presented here may work for quantity 1, but you
will have trouble trying to build many of these.  And this approach is
wholly unacceptable for a product that will ship to customers.
'Deglitchers' are for mechanical switches, not clocks.

There are some basic elements that must work on a digital circuit
board, and the 'clock' falls into this category.


Article: 99826
Subject: Re: Please recomend textbook with AES encryption.
From: "Frank" <frank@yahoo.com.cn>
Date: Thu, 30 Mar 2006 09:16:49 +0800
Links: << >>  << T >>  << A >>

"Markus Kuhn" <n06W13+mgk25@cl.cam.ac.uk> wrote in message
news:e0dqqp$99b$1@gemini.csx.cam.ac.uk...
> "Frank" <frank@yahoo.com.cn> writes:
> |> I am looking for textbook with detailed information on AES encryption
> |> and decryption. I have Bernard Sklar's Digital Communications, but it
> |> contains DES only.
>
> For a detailed textbook about AES by its designers, have a look at
>
>   Joan Daemen, Vincent Rijmen:
>   The Design of Rijndael: AES - The Advanced Encryption Standard
>   Springer, 2002, ISBN 3540425802.
>
> Most newer entry-level cryptography textbooks (e.g.,
> Douglas R. Stinson's Cryptography: Theory and Practice,
> 3rd edition) contain a couple of pages on AES.
>
> What textbook is best suited for you really depends on
> your background and for what reason you want to learn
> about AES (just implement it? start a PhD project to
> attack it? teach a class?).
>
> Markus
>
> -- 
> Markus Kuhn, Computer Laboratory, University of Cambridge
> http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain

Well, my objective is to write a hardware enc/decryptor for AES in FPGA.
I am reading the PDF files released on the AES website.
<Announcing the ADVANCED ENCRYPTION STANDARD (AES)>
Hope I can get a clue soon.




Article: 99827
Subject: Re: deglitching a clock
From: Joerg <notthisjoergsch@removethispacbell.net>
Date: Thu, 30 Mar 2006 01:17:10 GMT
Links: << >>  << T >>  << A >>
Hello John,

> 
> We did my original #2 suggestion, a tapped delay line driven from the
> pin, driving an r-s flipflop. Set the flop if all the taps are 1s,
> clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter.
> The delay line is a string of eight buffers, about 10 ns overall.
> 
> We'd have done Peter's circuit if we'd learned of it sooner.
> 
> It's interesting that my post evoked two classes of response:
> 
> 1. It can't be done, don't do it, kluge the boards (also the official
> Xilinx response!)
> 
> 2. Yes, and here are my ideas on how you could do it/how I've already
> done it/interesting asides.
> 

That probably depends on what kinds of projects the individual 
responders usually work on. In my field (medical) I could lose my shirt 
if I did the digital de-glitcher thing. If it's an application where 
nothing bad can happen when it chokes or where that condition will 
always be signaled it might be different. But I wouldn't do it.

Regards, Joerg

http://www.analogconsultants.com

Article: 99828
Subject: Re: OpenSPARC released
From: "Art Stamness" <artstamness@gmail.com>
Date: 29 Mar 2006 17:21:40 -0800
Links: << >>  << T >>  << A >>
I agree that the 80% effort is in the verification. That is why the
verification tools have been improving so dramatically over the last
decade, where RTL design tools hasn't really changed all that much.

Vera, Specman, and now SystemVerilog Testbench are all nicer and higher
level way of verifying designs. Constraint based Random Verification
gets more bang for the buck out of your simulation dollar. They are
still costly in runtime ( read : slow ), but are definately an
improvement over the old style hand coded testbenches.

Assertion Based Verification using OVA, OVL, PSL, SVA types are
maturing and more mainstream, and this will definately help in the
reuse of IP, however the cost of use is high because, this verification
runs continuously in your simulation. In fact just a few temporal
assertions added to some interface can half your runtime performance (
from my experience on a 2MGate microprocessor core). Static assertions
are clearly more performance friendly but must more limited in there
checking.

I know companies like Real Intent have tools that try to use "Automatic
formal" ( which extracts the assertions, and formally proves they are
possible scenarios in which illegal behavior can be expressed) . This
also seems like a good thing, unfortunately I have found that this type
of work is typically done by the RTL designer, and increases his
workload, not decreases.

And the holy grail of "Spec -> RTL" tool still doesn't exist. But I
agree we have more tools to get us closer. I still don't see there
being any other way of describing large ASIC's in any other way than
hierarchical hand coded RTL. And these tools that try to make it easier
to verify, I haven't seen one yet, that actually implements your logic,
because usually the designer is the one who knows what to optimize for
: performance, speed, area, cost, manufacturability, testability . . .

So, at the end of the day, I don't think the job of the RTL designer is
going away any time soon. In fact most of these tools still require
more code to be written to describe the correct behavior. I don't think
these technology is driving RTL designers out of work.

-Art


Article: 99829
Subject: Re: Please recomend textbook with AES encryption.
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 29 Mar 2006 17:51:57 -0800
Links: << >>  << T >>  << A >>
"Frank" <frank@yahoo.com.cn> wrote in message 
news:442b3120$1@news.starhub.net.sg...
>
> Well, my objective is to write a hardware enc/decryptor for AES in FPGA.
> I am reading the PDF files released on the AES website.
> <Announcing the ADVANCED ENCRYPTION STANDARD (AES)>
> Hope I can get a clue soon.
>
Hi Frank,
You may be able to get a clue from 
http://www.opencores.org/projects.cgi/web/aes_core/overview where someone's 
already done an IP core!
HTH, Syms. 



Article: 99830
Subject: Re: deglitching a clock
From: "Rob" <robnstef@frontiernet.net>
Date: Thu, 30 Mar 2006 02:03:20 GMT
Links: << >>  << T >>  << A >>
John,

I assume before this that the clock was going into a global clock pin?  If 
so, how do you deal with losing the low skew chip-wide network now that 
you're coming in on a standard I/O pin?

Take care,
Rob

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
news:i88l229so8qheephlt41crc0v7e5ebch3r@4ax.com...
> On 29 Mar 2006 01:00:59 -0800, bill.sloman@ieee.org wrote:
>
>>
>>John Larkin wrote:
>>> On 28 Mar 2006 12:45:23 -0800, bill.sloman@ieee.org wrote:
>>>
>>>
>>> >So the Fpga to Fpga routing worked - good.
>>>
>>> That's not what we did. We designed a clock deglitcher to go inside
>>> the FPGA.
>>
>>Enough propagation delays to cover the dwell at the switching
>>threshold, and a state machine to make sure that the clock only changes
>>state once in that interval?
>
>
> We did my original #2 suggestion, a tapped delay line driven from the
> pin, driving an r-s flipflop. Set the flop if all the taps are 1s,
> clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter.
> The delay line is a string of eight buffers, about 10 ns overall.
>
> We'd have done Peter's circuit if we'd learned of it sooner.
>
> It's interesting that my post evoked two classes of response:
>
> 1. It can't be done, don't do it, kluge the boards (also the official
> Xilinx response!)
>
> 2. Yes, and here are my ideas on how you could do it/how I've already
> done it/interesting asides.
>
> John
>
> 



Article: 99831
Subject: Re: deglitching a clock
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 30 Mar 2006 14:04:32 +1200
Links: << >>  << T >>  << A >>
John Larkin wrote:
> On 29 Mar 2006 01:00:59 -0800, bill.sloman@ieee.org wrote:
> 
> 
>>John Larkin wrote:
>>
>>>On 28 Mar 2006 12:45:23 -0800, bill.sloman@ieee.org wrote:
>>>
>>>
>>>
>>>>So the Fpga to Fpga routing worked - good.
>>>
>>>That's not what we did. We designed a clock deglitcher to go inside
>>>the FPGA.
>>
>>Enough propagation delays to cover the dwell at the switching
>>threshold, and a state machine to make sure that the clock only changes
>>state once in that interval?
> 
> 
> 
> We did my original #2 suggestion, a tapped delay line driven from the
> pin, driving an r-s flipflop. Set the flop if all the taps are 1s,
> clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter.
> The delay line is a string of eight buffers, about 10 ns overall.
> 
> We'd have done Peter's circuit if we'd learned of it sooner.
> 
> It's interesting that my post evoked two classes of response:
> 
> 1. It can't be done, don't do it, kluge the boards (also the official
> Xilinx response!)
> 
> 2. Yes, and here are my ideas on how you could do it/how I've already
> done it/interesting asides.

A couple of questions for those who are in 1),

  Would you use the Pin-Delay feature on a FPGA, to de-skew click lines 
from other devices ?

  If you are OK with that, suppose John now uses the same Pin-delay 
feature (chained) on his 'toggle rate governer' - is that then OK ?

-jg



Article: 99832
Subject: Re: deglitching a clock
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 29 Mar 2006 18:05:30 -0800
Links: << >>  << T >>  << A >>
On 29 Mar 2006 16:51:23 -0800, "mike_la_jolla" <mdini@dinigroup.com>
wrote:

>Put me *SQUARELY* in category 1.  You have a HW problem that demands a
>re-layout.  The kludges presented here may work for quantity 1, but you
>will have trouble trying to build many of these.

Why? What we're doing is perfectly sound, and works exactly as
expected.

>And this approach is
>wholly unacceptable for a product that will ship to customers.

Too late, a bunch have already been shipped.

Bit who gets to decide "unacceptable"? And who enforces it?

>'Deglitchers' are for mechanical switches, not clocks.

Is that an Federal law or something? Are all those millions of Sonet
clock-recovery PLLs out there illegal?

>There are some basic elements that must work on a digital circuit
>board, and the 'clock' falls into this category.

Right; it works fine now.

John




Article: 99833
Subject: Re: deglitching a clock
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 29 Mar 2006 18:09:18 -0800
Links: << >>  << T >>  << A >>
On Thu, 30 Mar 2006 01:17:10 GMT, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

>Hello John,
>
>> 
>> We did my original #2 suggestion, a tapped delay line driven from the
>> pin, driving an r-s flipflop. Set the flop if all the taps are 1s,
>> clear it if all are 0s. Sort of a poor man's 1-bit FIR lowpass filter.
>> The delay line is a string of eight buffers, about 10 ns overall.
>> 
>> We'd have done Peter's circuit if we'd learned of it sooner.
>> 
>> It's interesting that my post evoked two classes of response:
>> 
>> 1. It can't be done, don't do it, kluge the boards (also the official
>> Xilinx response!)
>> 
>> 2. Yes, and here are my ideas on how you could do it/how I've already
>> done it/interesting asides.
>> 
>
>That probably depends on what kinds of projects the individual 
>responders usually work on. In my field (medical) I could lose my shirt 
>if I did the digital de-glitcher thing. If it's an application where 
>nothing bad can happen when it chokes or where that condition will 
>always be signaled it might be different. But I wouldn't do it.
>

If your application is critical, one could argue that you are in fact
obligated to do this to increase clock noise immunity. 

But we're just testing jet engines.

John



Article: 99834
Subject: Re: deglitching a clock
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 29 Mar 2006 18:13:55 -0800
Links: << >>  << T >>  << A >>
On Thu, 30 Mar 2006 02:03:20 GMT, "Rob" <robnstef@frontiernet.net>
wrote:

>John,
>
>I assume before this that the clock was going into a global clock pin?  If 
>so, how do you deal with losing the low skew chip-wide network now that 
>you're coming in on a standard I/O pin?
>
>Take care,
>Rob


We now treat that pin as a regular input. After the deglitch logic, we
pipe it into a global clock buffer, and it becomes the new 16 MHz
master clock for the whole chip.

John



Article: 99835
Subject: Re: spartan FPGA with PLCC package
From: ghelbig@lycos.com
Date: 29 Mar 2006 18:40:11 -0800
Links: << >>  << T >>  << A >>
The PLCC Spartan/SpartanXL is NOT going to be the least costly.

Xilinx no longer supports them.  To synthesize, you'll need FPGA
Express, and the last time I checked, it ran about $15,000.00 - 15K
will buy a lot of time at your local stuffing house.

"If it ain't supported in a current web-pack, don't use it."


Article: 99836
Subject: FpgaC developers wanted :)
From: fpga_toys@yahoo.com
Date: 29 Mar 2006 18:53:50 -0800
Links: << >>  << T >>  << A >>
The open source FpgaC project is looking for a few more developers in
various technology areas and skill levels. One project is updating the
generic LUT only technology mapping code that came with TMCC written a
decade ago, to a newer algorithm that better fits current technology
FPGAs today.
We've started this with several changes, and there is lots more fun
work to go.

The next part of this project, is given a truth table, is to find the
best way to decompose it into LUT's and MUX's. This project is
available for anyone that would like it. Since it's pretty issolated
from the compiler guts, and will be implemented in the device specific
output functions, it's a good project for someone wanting to get their
feet wet as an internals developer.

This isn't exactly easy to do well, but almost any implementation will
be better than the current fitting strategy for LUT only mapping, so
refinement can happen over time as the developers skills build in this
technology area. This is an area of active and competitive research, so
it might make an interesting undergraduate project, or graduate level
thesis.

Interesting reading is related to the Quine-McCluskey algorithm
(implemented in FpgaC) and general logic synthesis algorithms. See:

        http://www.eecs.berkeley.edu/~alanmi/abc/

http://embedded.eecs.berkeley.edu/Respep/Research/mvsis/software.html

http://www.eecg.toronto.edu/~jzhu/releases/fbdd/info_web/index.html
        http://www.ecs.umass.edu/ece/labs/vlsicad/bds/bds.html
        http://service.felk.cvut.cz/vlsi/prj/BOOM/

Good resume builder project for someone interested in EDA software
tools as a job.

http://sourceforge.net/projects/fpgac

Have fun,
John


Article: 99837
Subject: Re: EDK/Xilinx : Insertion of ECC capability into BRAM controller
From: "Jeff Shafer" <shafer@delete-to-reply.aquaweb.pair.com>
Date: Wed, 29 Mar 2006 21:07:50 -0600
Links: << >>  << T >>  << A >>
Hi Jon,

The VHDL for the Xilinx BRAM controller is provided with the EDK.  Look in 
C:\EDK\hw\XilinxProcessorIPLib\pcores\plb_bram_if_cntlr_v1_00_b  (or 
wherever you installed the EDK on your machine). There's a similar core for 
the OPB, and a base library in bram_if_cntlr_v1_00_b

You should be able to copy and merge the appropriate folders and use it as a 
custom core in your own EDK project.  You'll probably want to pick a new 
core name instead of plb_bram_if_cntlr to avoid confusion.  Be sure to 
rename all of the appropriate files. (I found this to be a big pain to get 
right if you've never made a custom core before. You could use the Xilinx 
wizard to create an empty PLB or OPB core and use it as an example of their 
naming and version number conventions.)

The BRAM is not instantiated as part of the controller. You use the separate 
bram_block core in the EDK for it.  You should be able to copy that core as 
well and modify it if needed.  Also, you should be able to find examples of 
how the controller and BRAM core are connected.  There are plenty of basic 
examples of a PowerPC, PLB bus, controller, and BRAM memory available 
online.

Hope this helps,

Jeff


"Jon Anderson" <jon@idcomm.com> wrote in message 
news:ee99836.-1@webx.sUN8CHnE...
> Greetings.
>
> I am looking to figure out a way to modify an existing BRAM controller 
> (connected to either OPB or PLB) to add ECC capabilities. I am using EDK 
> 7.1i, and it appears that controllers instantiated there cannot be 
> modified. I have looked at Xilinx XAPP645 and understand how it works, but 
> can't find a way to insert the VHDL into an existing controller.
>
> Basically, I'm trying to break the connection at PORTA such that the data 
> will run through the ECC encoder to the BRAM, but the address and control 
> lines are still intact (and connected to to the BRAM blocks). It seems 
> like it should be a fairly straightforward exercise, but I have had zero 
> success.
>
> The other part of the issue is that BRAM itself appears to be instantiated 
> as part of the controller, so I also need to have a way to support the 
> extra data as well. I appear to be getting BRAMs with the additional bit 
> for parity data, but have no good way to access it.
>
> This is being done on a Virtex-II Pro, and I'm connecting to the PPC core. 
> However, I don't think this is application-specific, since I should be 
> able to do the same thing with a Microblaze, for example.
>
> Thanks! 



Article: 99838
Subject: Re: Cyclone II EP2C70 dev kits, where are they?
From: billh40@aol.com
Date: 29 Mar 2006 20:21:06 -0800
Links: << >>  << T >>  << A >>

Karl wrote:
> Karl wrote:
>
> > Look at the EP2C35F672 based development kits and swap the device. You
> > will loose around 50 I/O's on the EP2C70 but if you are lucky the DDR
> > interfaces remain OK (did not check this)
> >
> > Happy soldering !
> >
> > Karl.
>
> I checked... The Altera DSP development kit is made for 2C35 2C50 and
> 2C70. The additional I/O's on the 2C35 and 2C50 are not used and you
> should be able to do this trick.
>
> Karl.

          I requested a quote from Altera with the EP2C70 soldered on
the EP2C35
DSP development board , but they were not interested.  I also requested
a qoute from TerAsic , but they also did not respond.
          I thought that removing the EP2C35 from the board would be
too risky.
However, I did buy the Terasic DE2 EP2C35 board with the EP2C35 for
$495.

Bill Hanna


Article: 99839
Subject: Re: FpgaC developers wanted :)
From: "Isaac Bosompem" <x86asm@gmail.com>
Date: 29 Mar 2006 21:33:06 -0800
Links: << >>  << T >>  << A >>

fpga_toys@yahoo.com wrote:
> The open source FpgaC project is looking for a few more developers in
> various technology areas and skill levels. One project is updating the
> generic LUT only technology mapping code that came with TMCC written a
> decade ago, to a newer algorithm that better fits current technology
> FPGAs today.
> We've started this with several changes, and there is lots more fun
> work to go.
>
> The next part of this project, is given a truth table, is to find the
> best way to decompose it into LUT's and MUX's. This project is
> available for anyone that would like it. Since it's pretty issolated
> from the compiler guts, and will be implemented in the device specific
> output functions, it's a good project for someone wanting to get their
> feet wet as an internals developer.
>
> This isn't exactly easy to do well, but almost any implementation will
> be better than the current fitting strategy for LUT only mapping, so
> refinement can happen over time as the developers skills build in this
> technology area. This is an area of active and competitive research, so
> it might make an interesting undergraduate project, or graduate level
> thesis.
>
> Interesting reading is related to the Quine-McCluskey algorithm
> (implemented in FpgaC) and general logic synthesis algorithms. See:
>
>         http://www.eecs.berkeley.edu/~alanmi/abc/
>
> http://embedded.eecs.berkeley.edu/Respep/Research/mvsis/software.html
>
> http://www.eecg.toronto.edu/~jzhu/releases/fbdd/info_web/index.html
>         http://www.ecs.umass.edu/ece/labs/vlsicad/bds/bds.html
>         http://service.felk.cvut.cz/vlsi/prj/BOOM/
>
> Good resume builder project for someone interested in EDA software
> tools as a job.
>
> http://sourceforge.net/projects/fpgac
>
> Have fun,
> John

Hi John,

I have to ask are you the head developer of this project?

Also I see University of Toronto is heavily involved with your project.
While I do not go to that school, I go to a lesser known University in
the area, do you have any contacts there?

Thanks

-Isaac


Article: 99840
Subject: Re: Cyclone II EP2C70 dev kits, where are they?
From: Tommy Thorn <foobar@nowhere.void>
Date: Wed, 29 Mar 2006 21:33:33 -0800
Links: << >>  << T >>  << A >>
Karl wrote:
> Karl wrote:
> 
>> Look at the EP2C35F672 based development kits and swap the device. You
>> will loose around 50 I/O's on the EP2C70 but if you are lucky the DDR
>> interfaces remain OK (did not check this)
>>
>> Happy soldering !
>>
>> Karl.
> 
> I checked... The Altera DSP development kit is made for 2C35 2C50 and
> 2C70. The additional I/O's on the 2C35 and 2C50 are not used and you
> should be able to do this trick.

Thanks for checking Karl, but I know I could not do this myself and 
paying for someone to do the pull and then add the 2C70 is starting to 
sound expensive.  I can't justify spending a whole lot more than $1000.

I'm looking into the promising LatticeECP2, but it sure would have been 
nice if Xilinx would add support for the 3S5000 (Xilinx, hint hint :)

If anyone knows of any 2C70 boards, do let us know.

Tommy

Article: 99841
Subject: Re: FpgaC developers wanted :)
From: fpga_toys@yahoo.com
Date: 29 Mar 2006 21:45:35 -0800
Links: << >>  << T >>  << A >>
Isaac Bosompem wrote:
> I have to ask are you the head developer of this project?

I founded the FpgaC project, and drive it to some extent, but view it
as a group effort.

> Also I see University of Toronto is heavily involved with your project.
> While I do not go to that school, I go to a lesser known University in
> the area, do you have any contacts there?

They have not been active in FpgaC, other than providing BSD licensed
TMCC sources we used as a foundation. I exchange emails with the
original author from time to time, but he is too busy in other projects
to participate at this time.


Article: 99842
Subject: Re: OpenSPARC released
From: Tommy Thorn <foobar@nowhere.void>
Date: Wed, 29 Mar 2006 21:56:02 -0800
Links: << >>  << T >>  << A >>
JJ wrote:
> Precisely, anyone who has done FPGA cpu design knows how limiting FPGAs
> can be .ie 20-120MHz is typical for unfriendly architectures.
> 
> If your not in that very small club of Intel, AMD, IBM, then even full
> custom is also pretty limiting by the extreme expense of it all. The
> top tier may still be directly instantiating transistors as well as
> flops. But then transistor level design is still able to significantly
> outperform standard cell logic using a variety of mostly nmos
> differential techniques, I guess by a factor of 3. At Suns level, they
> are much closer to full standard cell with synthesis with a fraction of
> the clock of P4s but they make up for it by going to massive threading
> and latency hiding to bring out the throughput.

I think you're being overly generous to Sun here.

> Theres the clue there. The same can be done in FPGA cpu for
> multithreading architecture to simplify the design so that you are not
> limited to 32b carry ripples. In my Transputer design I was seeing
> 300MHz on the PEs because it could use 2 clocks per basic opcode and
> used 8 clocks for 4 thread instructions, alot of cycle limiting logic
> just vanishes, ie no hazard logic or register forwarding paths. The
> hardware design of the MMU hasn't started so there is nothing to
> release.

I think this is pretty much well known, although no less true.  However, 
as Amdahl put it, "What would you rather use to plow a field?  Two oxen 
or a thusand chicken?".  In your world things are of course different as 
you're coming from a paradigm of many many threads.  However the rest of 
the world is only slooowly moving to multiple threads.

It is interesting though that by giving up half the speed on single 
thread performance, you can gain 3-4 times the throughput for free. 
I'll definitely play with that.

> I am surprised that we haven't seen alot more native FPGA MTA designs
> though,.

In addition to what I mentioned, there's surely more inertia issues and 
the complication of multi-threaded software (assuming you can even take 
advantage of it).

My $0.01
Tommy

Article: 99843
Subject: Re: Ace file for design with dual ppc405
From: "my.king" <king.azman@gmail.com>
Date: 29 Mar 2006 22:49:17 -0800
Links: << >>  << T >>  << A >>
Thanks for the info.

Yes... I'm trying to test some stuffs where each processor have some
tasks to complete - a shared memory space will be used to communicate
between them. i can create the bitstream and download through the jtag
cable, though - i was thinking of making it more 'standalone' by just
booting from the CF card.


Article: 99844
Subject: how can one get a netlist consisting of SLICEs?
From: "imavroid" <imavroid@gmail.com>
Date: 29 Mar 2006 23:43:06 -0800
Links: << >>  << T >>  << A >>
How can one synthesize their Verilog code into FPGA SLICEs without
doing PAR? I want the code to synthesize into SLICEs, not the
lower-level LUTs/MUXs/FFs (which is what a "Generate Post-Map
Simulation Model" in Xilinx ISE gives me). Ideally the output of the
synthesis would almost exclusively consist of SLICEs.

Thanks for your help,
Yannis


Article: 99845
Subject: Re: Linux on ml403
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Wed, 29 Mar 2006 23:51:32 -0800
Links: << >>  << T >>  << A >>
Jean-Francois,

follow the instructions in the ML403 Reference Design Users Guide (pg 
39). In particular, create the board support package with the Linux MLD 
and use the patch_linux script in the linux sub-directory of the ML403 
reference design. The patch sets bits 1 and 3 in CCR0 which is required 
for ES silicon, i.e. silicon where the PPC405 has a PVR of 0x20011430. 
After applying the patch the problem will be gone.

- Peter


Links:
- ML403 Web Page: http://www.xilinx.com/ml403
- ML403 Users Guide: http://www.xilinx.com/bvdocs/userguides/ug082.pdf
- ML403 reference design: 
http://www.xilinx.com/products/boards/ml403/files/ml403_emb_ref_ppc_81.zip





jfh wrote:
> Hi,
> 
> I have been trying to port Linux on the ML403 board using the 2.4 devel
> tree downloaded from montavista site using rsync.The compilation goes
> fine with the modifications of some source files and makefiles after
> copying the BSP generated from EDK 7.1 (I used some BYU website advice
> about porting Linux on XUV2P board). I manage to download the Linux
> kernel via xmd, the kernel boots but it has a problem and an exception
> 0400 seems to occur. Did anyone try the same method and managed it
> correctly ? Does anyone have an idea as to why I have this exception ?
> How could I investigate this issue not being an expert in  Linux but
> just trying to understanding what is going on ?
> 
> Best regards, 
> 
> JF
> 


Article: 99846
Subject: Re: FpgaC developers wanted :)
From: ptkwt@aracnet.com (Phil Tomson)
Date: 30 Mar 2006 07:52:50 GMT
Links: << >>  << T >>  << A >>
In article <1143687230.719515.136950@j33g2000cwa.googlegroups.com>,
 <fpga_toys@yahoo.com> wrote:
>
>The next part of this project, is given a truth table, is to find the
>best way to decompose it into LUT's and MUX's. 

What format is the truth table in?  (BLIF, PLA, some other internal data 
structure)

So is this the tech mapping step?  You've already created the truth table that 
represents some part of the design and you need to map it into the underlying 
architecture. Sounds interesting.


>This project is
>available for anyone that would like it. Since it's pretty issolated
>from the compiler guts, and will be implemented in the device specific
>output functions, it's a good project for someone wanting to get their
>feet wet as an internals developer.
>
>This isn't exactly easy to do well, but almost any implementation will
>be better than the current fitting strategy for LUT only mapping, so
>refinement can happen over time as the developers skills build in this
>technology area. This is an area of active and competitive research, so
>it might make an interesting undergraduate project, or graduate level
>thesis.
>
>Interesting reading is related to the Quine-McCluskey algorithm
>(implemented in FpgaC) and general logic synthesis algorithms. See:
>
>        http://www.eecs.berkeley.edu/~alanmi/abc/

Ah, yes, Alan is on the cutting edge with this And-Inverter Graph stuff.  He's 
also a very good programmer.
Can you make use of what is already in ABC?  While I would hesitate to use 
code from some other university projects that have appeared in the past, I 
would not hesistate to use Alan's code; it's generally engineered very well.  

Phil

Article: 99847
Subject: PCB Bypass Caps
From: "maxascent" <maxascent@yahoo.co.uk>
Date: Thu, 30 Mar 2006 03:18:44 -0600
Links: << >>  << T >>  << A >>
Hi

I need to layout a Virtex 2 Pro board using a 672 BGA package. Does anyone
have any tips for the placement of the bypass caps. I want to use 0603 caps
and normal PTH vias. I can see that it might get a bit crowded trying to
position a lot of caps under the device near to the power pins with all
those vias.

Cheers

Jon

Article: 99848
Subject: Re: how can one get a netlist consisting of SLICEs?
From: Kolja Sulimma <news@sulimma.de>
Date: Thu, 30 Mar 2006 11:20:37 +0200
Links: << >>  << T >>  << A >>
imavroid schrieb:
> How can one synthesize their Verilog code into FPGA SLICEs without
> doing PAR? I want the code to synthesize into SLICEs, not the
> lower-level LUTs/MUXs/FFs (which is what a "Generate Post-Map
> Simulation Model" in Xilinx ISE gives me). Ideally the output of the
> synthesis would almost exclusively consist of SLICEs.

Clustering these components into slices is already a partial placement.
 It is controversial whether inital clustering helps or hurts placement.
(At least it helps the tool runtime)

IIRC the ISE synthesis tool has an option to pack LUTs to slices. If you
turn it on the information which LUTs belong to the same slice must be
in one of the files generated. You can than simply assign the muxes and
flip-flops to the same slices as the LUTs driving them and have a
netlist of Slices.

Kolja Sulimma


Article: 99849
Subject: Re: PCB Bypass Caps
From: Aurelian Lazarut <aurash@xilinx.com>
Date: Thu, 30 Mar 2006 10:52:24 +0100
Links: << >>  << T >>  << A >>
A good development board (Avnet, Insight, Xilinx) to look at, can give 
you some ideas.
Aurash

maxascent wrote:
> Hi
> 
> I need to layout a Virtex 2 Pro board using a 672 BGA package. Does anyone
> have any tips for the placement of the bypass caps. I want to use 0603 caps
> and normal PTH vias. I can see that it might get a bit crowded trying to
> position a lot of caps under the device near to the power pins with all
> those vias.
> 
> Cheers
> 
> Jon



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