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
2019JanFebMar2019

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 107000

Article: 107000
Subject: Re: uclinux on spartan-3e starter kit
From: "David" <aresolimpico@gmail.com>
Date: 23 Aug 2006 10:20:17 -0700
Links: << >>  << T >>  << A >>
i get this errors
using the rev02 i get 2 errors and one warning
how i can resolve it?


WARNING:MDT - The installed version of EDK tools is 8.1, while project
was created with version 8.1.01
ERROR:MDT - I:\Documents and
Settings\aaa\Escritorio\s3eboard_uclinux_ready_rev02\s3eboard_uclinux_ready_v8101_rev02\system.mss
line 5 - Can not find MLD for the os uclinux 1.00.d
INFO:MDT - Directories Searched :
- I:\Documents and
Settings\aaa\Escritorio\s3eboard_uclinux_ready_rev02\s3eboard_uclinux_ready_v8101_rev02\bsp/uclinux_v1_00_d/data
- I:\EDK\sw\ThirdParty\bsp/uclinux_v1_00_d/data
- I:\EDK\sw\XilinxProcessorIPLib\bsp/uclinux_v1_00_d/data
- I:\EDK\sw\lib\bsp/uclinux_v1_00_d/data
ERROR:MDT - Can not find MLD for the os uclinux 1.00.d
INFO:MDT - Directories Searched :
- I:\Documents and
Settings\aaa\Escritorio\s3eboard_uclinux_ready_rev02\s3eboard_uclinux_ready_v8101_rev02\bsp/uclinux_v1_00_d/data
- I:\EDK\sw\ThirdParty\bsp/uclinux_v1_00_d/data
- I:\EDK\sw\XilinxProcessorIPLib\bsp/uclinux_v1_00_d/data
- I:\EDK\sw\lib\bsp/uclinux_v1_00_d/data

thanks you very much

Antti Lukats wrote:
> "David" <aresolimpico@gmail.com> schrieb im Newsbeitrag
> news:1156300564.875777.302880@i42g2000cwa.googlegroups.com...
> > hi
> > i am looking for any step by step guide to use uclinux on the starter
> > kit.
> > i try the site:
> > http://muranaka.info/pukiwiki/pukiwiki.php?MicroBlaze%20uClinux%20and%20Spartan-3E%20Starter%20Kit#content_1_0
> > but i didnt find anything in english or spanish. just japanese.
> > thanks you
> > David
> >
> hm  checked the images from that site in XSIM and they work just fine.
> I dont have the boards so can not test in hardware but I assume they will
> defenetly work as well
> 
> antti


Article: 107001
Subject: fastest FPGA
From: "hypermodest" <hypermodest@gmail.com>
Date: 23 Aug 2006 10:21:16 -0700
Links: << >>  << T >>  << A >>
Hello.
I've a task to make attempt to crack some cryptographical hash-function
by using brute-force attack. So I wish to implement it in FPGA.
How can I get fastest FPGA at the modern market?
Altera Nios II dev kit stratix 2 edt (EP2S60) is the right choice?
By the way, are these devices (EP2S60) can be overclocked? If yes, how?


Article: 107002
Subject: Re: JOP as SOPC component
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Wed, 23 Aug 2006 19:25:40 +0200
Links: << >>  << T >>  << A >>
> Martin Schoeberl wrote:
>>>> Another point is, in my opinion, the wrong role who has to hold data
>>>> for more than one cycle. This is true for several busses (e.g. also
>>>> Wishbone). For these busses the master has to hold address and write
>>>> data till the slave is ready. This is a result from the backplane
>>>> bus thinking. In an SoC the slave can easily register those signals
>>>> when needed longer and the master can continue.
>>> When happens then when you issue another request to a slave which hasn't finished processing the first? Any queue will be finite 
>>> and eventually you'd have to deal with stalling anyway. Any issue is that there are generally many more slaves than masters so 
>>> it makes sense to move the complication to the master.
>>
>> I disagree ;-)
>> How hard is it for a slave to hold the read data more than one cycle?
>> Until the next read data is requested and available? That comes almost
>> for free. It's a single register, trivial logic. Ok, is a little overhead
>> for an on-chip peripheral. However, you need usually a MUX in the
>> peripheral for select the IO registers (now using register with a different
>> meaning). Making this MUX registered is almost for free.
>
> Focusing on the overhead for one slave supporting one outstanding command is missing the point.

However, holding data out in the slave until overwritten by
new data from a new request is still worth doing it. It will
simplify a single master. And probably also the interconnection
logic for multiple masters.

> Non-trivial slaves can support multiple simultaneous outstanding requests (say N), so they would need at least a queue N deep. 
> Not a problem.  Now, I have multiple slaves and multiple masters on the interconnect.  Each master must be able to have at least M 
> outstanding requests. Any one slave can only accept one request pr cycle so the interconnect (the arbitration) needs buffer the 
> requests in lots of FIFOs and _they_ add significant latency, logic, and complication (pick two).

If you want them to be completely independent you also need
a reordering of results (or some kind of transaction id) in
your interconnect. For me that's a completely different
game. I think that's more a Network-on-Chip (NoC) topic.
NoC is a big buzz-word these days ;-)

> I'll need to study SimpCon more to understand what you mean by it's support for multiple outstanding requests. Just to clarify, 
> I'm talking about completely independent requests, not bursts. Different masters may issue multiple of these (up to some limit) 
> while previously issued requests are still not complete. I do insist the requests complete in the order they were issued, mostly 
> to simplify things (such as the arbitration). Really just a subset of Avalon.
>

You can issue completely requests with the plain SimpCon
specification only to 'some' extent. Only when a former
request is 'yet to arrive' you can issue a new request to
SimpCon (or the switch logic). That's a restriction. We could
add a accept signal to allow the master to issue more
requests.

However, issuing multiple requests to different slaves and
than delivering them in order is a pain for the switch
logic. You have to remember your request order and handle
the results arriving in a different order. However, for
this issue a slave that holds the data till used can
simplify the switching a little bit...

Perhaps I should state how I see SimpCon: A *simple*
SoC interconnect that allows for lower latency and
pipelining to some extent. The main application I have
in mind is a single master (CPU) with multiple slaves
(memory and IO). The interconnect/address decoding
should be simple - and it is - see an example at:
http://www.opencores.org/cvsweb.cgi/~checkout~/jop/vhdl/scio/scio_min.vhd

Besides component declaration and IO signal routing
the interconnect is just 18 lines of VHDL. The read
MUX is driven by registered select, which helps in
the critical path when you have planty of slaves.

Martin 



Article: 107003
Subject: Re: Timing
From: "Symon" <symon_brewer@hotmail.com>
Date: 23 Aug 2006 19:26:09 +0200
Links: << >>  << T >>  << A >>
"Ray Andraka" <ray@andraka.com> wrote in message
news:ys%Gg.5801$SZ3.2115@dukeread04...
> maxascent wrote:
>
> > Hi
> >
> > I have a design that I have verified using a post route simulation and
> > then PAR the design with no timing errors. Do I need to do a post PAR
> > timing simulation or can I be confident that the design will work ok in
> > the fpga?
> >
> > Thanks
> >
> > Jon
>
> Assuming all the important paths are constrained and you've handled any
> clock domain crossings properly, the static timing analysis is
> sufficient, and actually more comprehensive than doing a timing
> simulation.  If you meet these conditions, you can be confident that it
> will behave the same as your functional simulation.
>
I concur. The time you could spend on the post PAR simulation is better
spent looking at the static timing report and checking you covered all the
paths that matter.
HTH, Syms.



Article: 107004
Subject: Re: virtex4fx board and ethernet
From: "Sandro" <sdroamt@netscape.net>
Date: 23 Aug 2006 10:42:20 -0700
Links: << >>  << T >>  << A >>
zcsizmadia@gmail.com wrote:
> Check out Avnet Virtex-4FX12 Mini Module. It is tiny, has one GB phy
> and it's $250.
> Put two boards together and use one of them as a slave, to stream the
> phy data to the master module. Only $500 :)
> ...

zcsizmadia,
I was thinking something like that after the antti's negative answer...
But at first glance, such modules seems to be witout power regulators
and other... (if You don't connect to the baseboard)
I should build one to power (3 different vcc... for virtex ?!?) and
connect them...
not a so big problem but if I could find a  solution available to be
used... ;-)

bye
Sandro


Article: 107005
Subject: Re: fastest FPGA
From: Eric Smith <eric@brouhaha.com>
Date: 23 Aug 2006 10:50:31 -0700
Links: << >>  << T >>  << A >>
"hypermodest" <hypermodest@gmail.com> writes:
> How can I get fastest FPGA at the modern market?

To a first approximation, by spending the most money.

> Altera Nios II dev kit stratix 2 edt (EP2S60) is the right choice?

No.

> By the way, are these devices (EP2S60) can be overclocked?

Yes.

> If yes, how?

By increasing the clock frequency beyond the Fmax reported by
the development tools.

Article: 107006
Subject: Re: Microblaze : xil_malloc malloc
From: Siva Velusamy <siva.velusamy@xilinx.com>
Date: Wed, 23 Aug 2006 10:58:00 -0700
Links: << >>  << T >>  << A >>
Emp wrote:
> Hi
> 
> I want to allocate memory but it doesn't work. If I use xil_malloc I can not allocated enough memory, pointer to NULL is returned. Whem I want to use malloc, I get the following error:
> 
> ./microblaze_0/lib//libc.a(malloc.o): In function `malloc': malloc.o(.text+0x8): relocation truncated to fit: R_MICROBLAZE_SRW32 .sdata malloc.o(.text+0x20): relocation truncated to fit: R_MICROBLAZE_SRW32 .sdata collect2: ld returned 1 exit status
> 
> I edit the heap size too.
> 
> Can anybody help me?
> 
> cu Emp


That error means that you do not have enough memory to store the .sdata 
section and sections after it in the linker script.

Try using a linker script that stores your program in external memory.

/Siva

Article: 107007
Subject: Re: fastest FPGA
From: "hypermodest" <hypermodest@gmail.com>
Date: 23 Aug 2006 11:01:50 -0700
Links: << >>  << T >>  << A >>
Eric Smith wrote:
> "hypermodest" <hypermodest@gmail.com> writes:
> > How can I get fastest FPGA at the modern market?
>
> To a first approximation, by spending the most money.

OK, but if to use single-chip solution?


Article: 107008
Subject: Re: DQPs
From: "John_H" <newsgroup@johnhandwork.com>
Date: Wed, 23 Aug 2006 18:02:26 GMT
Links: << >>  << T >>  << A >>
Polarity bits.  They're just extra bits, actually, intended for polarity or 
ECC algorithms and doesn't implement any polarity function on the data.  If 
you don't use polarity or ECC you have a 36-bit memory interface available 
if you want it.

Really basic stuff.  The data sheet has the values listed.


"zlotawy" <spawnek@NNOOSSPPAAMM.wp.pl> wrote in message 
news:1156353103.139823@pdp...
> HI,
> could you tell me what is DQPx in CY7C1386C (SRAM)?
>
> There are 36 bits of datas.. 32 DQx and 4 DOPx..
>
> Thanks
> zlotawy 



Article: 107009
Subject: Re: fastest FPGA
From: "John_H" <newsgroup@johnhandwork.com>
Date: Wed, 23 Aug 2006 18:06:46 GMT
Links: << >>  << T >>  << A >>
"hypermodest" <hypermodest@gmail.com> wrote in message 
news:1156353676.802741.145830@75g2000cwc.googlegroups.com...
> Hello.
> I've a task to make attempt to crack some cryptographical hash-function
> by using brute-force attack. So I wish to implement it in FPGA.
> How can I get fastest FPGA at the modern market?
> Altera Nios II dev kit stratix 2 edt (EP2S60) is the right choice?
> By the way, are these devices (EP2S60) can be overclocked? If yes, how?

Do you intend the brute force method to use many, many parallel units?
How much do you want to spend?

You may run into power issues before you can consider overclocking.  You 
could design so much high speed logic in a huge part that you can only run 
x% of the part at Fmax or all of the part at x% of Fmax. 



Article: 107010
Subject: Re: fastest FPGA
From: "Peter Alfke" <peter@xilinx.com>
Date: 23 Aug 2006 11:12:36 -0700
Links: << >>  << T >>  << A >>
First, you have to decide how much logic you need, i.e. how much money
you want to spend.
Then you have to look at the two leading manufacturers, which are -in
order of size and speed- Xilinx and Altera
>From Xilinx, I would recommend the appropriate size Virtex-4 LX part,
or -if you need lots of multipliers and/or accumulators- the
appropriate size Virtex-4 SX part.

If you are after max speed, you hardly need a microprocessor, but both
companies offer a soft microprocessor, it's called MicroBlaze in
Xilinx.

Good luck, sounds like a fun project.
Peter Alfke, Xilinx


Article: 107011
Subject: Re: Timing
From: "Andy" <jonesandy@comcast.net>
Date: 23 Aug 2006 11:15:33 -0700
Links: << >>  << T >>  << A >>
I mostly agree with Ray and Symon, except with one caveat: Multi-cycle
and False path constraints. Since there is no check to ensure that
paths that you said were multi-cycle or false actually are so, the only
verification left for them is formal analysis or full (post place &
route) timing simulation. The only places I've ever had errors show up
in full timing simulations were related to incorrectly specified
multi-cycle or false paths.

So, if you have multi-cycle or false path constraints, and you're not
absolutely sure you have them properly applied so that they cover the
paths you intended, and not any paths you did not intend (usually the
culprit), then I would recommend a full-timing simulation, but focus on
the functions related to those constraints. Everything else is verified
by static timing analysis and RTL simulations. Note that RTL
simulations are much faster to execute than full timing simulations,
especially when the RTL was written in a simulation-efficient manner,
where it approaches cycle-based performance.

There are a few formal tools supposedly coming out that can formally
verify, or even identify, multi-cycle and false path constraints for
you, but I don't have any experience with them.

Andy

Symon wrote:
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:ys%Gg.5801$SZ3.2115@dukeread04...
> > maxascent wrote:
> >
> > > Hi
> > >
> > > I have a design that I have verified using a post route simulation and
> > > then PAR the design with no timing errors. Do I need to do a post PAR
> > > timing simulation or can I be confident that the design will work ok in
> > > the fpga?
> > >
> > > Thanks
> > >
> > > Jon
> >
> > Assuming all the important paths are constrained and you've handled any
> > clock domain crossings properly, the static timing analysis is
> > sufficient, and actually more comprehensive than doing a timing
> > simulation.  If you meet these conditions, you can be confident that it
> > will behave the same as your functional simulation.
> >
> I concur. The time you could spend on the post PAR simulation is better
> spent looking at the static timing report and checking you covered all the
> paths that matter.
> HTH, Syms.


Article: 107012
Subject: Re: DQPs
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Wed, 23 Aug 2006 20:18:00 +0200
Links: << >>  << T >>  << A >>
John_H schrieb:
> Polarity bits.  They're just extra bits, actually, intended for polarity or 
> ECC algorithms and doesn't implement any polarity function on the data.  If 
> you don't use polarity or ECC you have a 36-bit memory interface available 
> if you want it.
> 
> Really basic stuff.  The data sheet has the values listed.

Polarity? Don't you mean Parity?

Regards
Falk

Article: 107013
Subject: Re: fastest FPGA
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 23 Aug 2006 11:20:06 -0700
Links: << >>  << T >>  << A >>
H.Modest,

First, any processor, soft or hard is far too slow to be of any use (be
it NIOSII or 405PPC).  The design will have to be done massively
parallel, all in logic.

Virtex 5 is sampling now (65nm), and represents the latest that
technology can offer.

There are the 5VLX30, 50, 85 and 110 sampling...

With the 5VLX110 you have:

17280 slices (Virtex-5 slices are organized differently from previous
generations. Each Virtex-5 slice contains four 6 input LUTs and four
flip-flops

64 DSP48E (Each DSP48E slice contains a 25 x 18 multiplier, an adder,
and an accumulator.)

128 36b BRAM blocks (Virtex-5 block RAMs are fundamentally 36 Kbits in
size. Each block can also be used as two independent 18-Kbit blocks)

etc.

With the clock tree supporting up to 550 MHz speeds (of course the
design has to meet timing, and so on to find the speed it can really
operate at).

http://direct.xilinx.com/bvdocs/publications/ds100.pdf

With the 6 LUT able to be a SRL32 (32 bit shift register), there are all
sorts of tricks one can use to speed up cyrpto algorithms.  Combined
with the DSP48E, I suspect that Virtex 5 will see some of the speediest
encryption and decryption cores in the future.

Farms of FPGAs to do brute force decryption have been proposed, and some
have actually been built (or so the conference papers claim).  The use
of FPGA farms for decryption is no longer "new" and may be the reason
why triple DES is no longer recommended for new equipment (cracking
2E112 brute force is now considered "too easy"?).  Even AES128 is being
skipped for new designs by those who feel that the difference between
2E112, and 2E128 is just not enough...(for example, we use AES256 for
our bitstream decyptor).

There is even a cracking farm that proposes the use of low cost Spartan
3 FPGAs (cracking on a budget?) at modest speeds.  The Spartan 3 is
probably three times slower (at best), but since a cracking farm
requires very little communications, being massively parallel means just
having many devices.  Why not pick the least expensive device, and just
use a ton of them?

If you desire the fastest possible logic, with the lowest power, right
now the Virtex 5 65nm FPGA can not be beat (as there is no other 65nm
offering at this time by anyone, anywhere).

Until there is something to compare it with, you really have only one
choice.

There is no such thing as "over-clocking" a FPGA:  either it meets
timing and works, or it doesn't.  You may have to have very exotic
cooling in order not to melt down the device, at speeds like 550 MHz
with all of the logic toggling.  The Industrial temp spec is the
junction must be kept below 100C.  Commercial grade must be kept below 85C.

You could increase the clock rate till the device fails to operate
correctly, or can not be cooled, but in this application it would be
very difficult to know if it wasn't operating correctly!  Best to design
it to work where it is supposed to work.

Austin




hypermodest wrote:
> Hello.
> I've a task to make attempt to crack some cryptographical hash-function
> by using brute-force attack. So I wish to implement it in FPGA.
> How can I get fastest FPGA at the modern market?
> Altera Nios II dev kit stratix 2 edt (EP2S60) is the right choice?
> By the way, are these devices (EP2S60) can be overclocked? If yes, how?
> 

Article: 107014
Subject: Re: uclinux on spartan-3e starter kit
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 23 Aug 2006 20:32:25 +0200
Links: << >>  << T >>  << A >>
"David" <aresolimpico@gmail.com> schrieb im Newsbeitrag 
news:1156353617.495934.108430@b28g2000cwb.googlegroups.com...
>i get this errors
> using the rev02 i get 2 errors and one warning
> how i can resolve it?
>
>
> WARNING:MDT - The installed version of EDK tools is 8.1, while project
> was created with version 8.1.01
> ERROR:MDT - I:\Documents and
> Settings\aaa\Escritorio\s3eboard_uclinux_ready_rev02\s3eboard_uclinux_ready_v8101_rev02\system.mss
> line 5 - Can not find MLD for the os uclinux 1.00.d

you have to download it seperatly and install in some dir where it can be 
found,
the arhc is on the same site, or then also available from petalogix site

Antti 



Article: 107015
Subject: Re: virtex4fx board and ethernet
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 23 Aug 2006 20:35:42 +0200
Links: << >>  << T >>  << A >>
"Sandro" <sdroamt@netscape.net> schrieb im Newsbeitrag 
news:1156354940.419515.3110@i3g2000cwc.googlegroups.com...
> zcsizmadia@gmail.com wrote:
>> Check out Avnet Virtex-4FX12 Mini Module. It is tiny, has one GB phy
>> and it's $250.
>> Put two boards together and use one of them as a slave, to stream the
>> phy data to the master module. Only $500 :)
>> ...
>
> zcsizmadia,
> I was thinking something like that after the antti's negative answer...
> But at first glance, such modules seems to be witout power regulators
> and other... (if You don't connect to the baseboard)
> I should build one to power (3 different vcc... for virtex ?!?) and
> connect them...
> not a so big problem but if I could find a  solution available to be
> used... ;-)
>
> bye
> Sandro
>

my NO answer was to __single__ self conatined board with 2 GB PHYs <600USD

doesnt exist as far as I know

with some tweaking you can get V4 and 2 times GB PHY for somewhat 
around-above 600USD

Antti 



Article: 107016
Subject: Re: JOP as SOPC component
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 23 Aug 2006 11:38:54 -0700
Links: << >>  << T >>  << A >>
I think it all comes down to me maybe not totally getting what you're
saying in the following paragraph so I'll go slowly if you do.

> My pipeline approach is just this little funny busy counter
> instead of a single ack and that a slave has to declare it's
> pipeline level (0 to 3). Level 1 is almost ever possible.
> It's more or less for free in a slave. Level 1 means that
> the master can issue the next read/write command in the same
> cycle when the data is available (rdy_cnt=0). Level 2 means
> issue the next command one cycle earlier (rdy_cnt=1). Still
> not a big issue for a slave (especially for a memory slave
> where you need a little state machine anyway).

I'm assuming that the master side address and command signals enter the
'Simpcon' bus and the 'Avalon' bus on the same clock cycle.  Maybe this
assumption is where my hang up is and maybe JOP on Simpcon is getting a
'head start' over JOP on Avalon.

Given that assumption though, it's not clear to me why the address and
command could not be designed to also end up at the actual memory
device on the same clock cycle.  Again, maybe this is where my hang up
is.

Given that address and command end up at the memory device on the same
clock cycle whether SimpCon or Avalon, the resulting read data would
then be valid and returned to the SimpCon/Avalon memory interface logic
on the same clock cycle.  Pretty sure this is correct since this is
just saying that the external memory performance is the same which is
should be since it does not depend on SimpCon or Avalon.

Given all of that, it's not clear to me why the actual returned data
would show up on the SimpCon bus ahead of Avalon or how it would be any
slower getting back to the SimpCon or Avalon master.  Again, this might
be where my hangup is but if my assumptions have been correct up to
this paragraph then I think the real issue is not here but in the next
paragraph.

If I got through this far then it comes down to....You say "Level 1
means that the master can issue the next read/write command in the same
cycle when the data is available (rdy_cnt=0). Level 2 means issue the
next command one cycle earlier (rdy_cnt=1)."  and presumably the
'rdy_cnt=1' is the reason for the better SimpCon numbers.  Where I'm
pretty sure I'm hung up then is why can't the Avalon slave drop the
wait request output on the clock cycle that corresponds to rdy_cnt=1
(i.e. one before data is available at the master)?

rdy_cnt=1 sounds like it is allowing JOP on SimpCon to start up the
next transaction (read/write or twiddle thumbs) one clock cycle before
the read data is actually available.  But how is that different than
the Avalon slave dropping wait request one clock cycle before the data
is available and then asserting read data valid once the data actually
is available?  All of this on the assumption that the Avalon master and
slaves both support readdatavalid of course.

> Enjoy this discussion :-)
> Martin

Immensely.  And I think I'll finally get the light bulb turned on in my
head after your reply.

Kevin


Article: 107017
Subject: Re: DCM vs. PLL
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 23 Aug 2006 20:58:53 +0200
Links: << >>  << T >>  << A >>

"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag 
news:echs1s$anl6@xco-news.xilinx.com...
> Oops,
>
> You still need to have the X7 clock, the the ISERDES does all the work.
>
> Austin
>
> Austin Lesea wrote:
>> Antti,
>>
>> Thank you.  Yes, it does look like this is a X7 deserializer.  In which
>> case the cheapest, fastest and easiest may be to just buy the ASSP that
>> was designed to do that job.
>>
>> I still think that V4 could also do this without any need for the ASSP
>> as the SSIO features include X7 sampling, without having to mutliply the
>> clock.
>>
>> http://direct.xilinx.com/bvdocs/userguides/ug070.pdf
>> page 355
>>
>> Austin

ah yes, the x7 must be there ;)

well the OP asked for V2Pro - it is doable in V2Pro too.
V4 is maybe better withe ILOGIC

but dedicated chip may even be better as it does the
job it was made to do.

Antti 



Article: 107018
Subject: Xilinx Virtex-4FC PPC
From: "Yuri" <shteinman@squarepeg.ca>
Date: 23 Aug 2006 12:01:24 -0700
Links: << >>  << T >>  << A >>
Hi.
Did anybody have a problem of "loosing" PPC during debugging?
My software crashes but when I click Stop on GDB or Pause in SDK the
debuggers cannot find the source. GDB shows empty window with "Select
function to disassemble". SDK shows "Symbol is not available".
XMD tells: "Unable to connect to PowerPC target. Invalid Processor
Version No 0x00000000" and the only thing helps is hardware reset of
PPC.

Any ideas?
Thank you.


Article: 107019
Subject: Re: JOP as SOPC component
From: "Tommy Thorn" <tommy.thorn@gmail.com>
Date: 23 Aug 2006 12:02:06 -0700
Links: << >>  << T >>  << A >>
A quick answer for this one:

> rdy_cnt=1 sounds like it is allowing JOP on SimpCon to start up the
> next transaction (read/write or twiddle thumbs) one clock cycle before
> the read data is actually available.  But how is that different than
> the Avalon slave dropping wait request one clock cycle before the data
> is available and then asserting read data valid once the data actually
> is available?

The signal waitrequest has nothing to do with the output, but is
property of the input. What you're suggesting is an "abuse" of Avalon
and would only work for slaves that support only one outstanding
transfer with a latency of exactly one.  Clearly incompatible with
existing Avalon components.

I'll have a longer reply for Martin later :-)

Tommy


Article: 107020
Subject: Re: fastest FPGA
From: "Josh Model" <model@ll.nospam.mit.edu>
Date: Wed, 23 Aug 2006 15:26:56 -0400
Links: << >>  << T >>  << A >>
>(cracking
>2E112 brute force is now considered "too easy"?)

Woah.  Is that really the case?  These "farms" must be enormous-- if you
have 2 million instances of your cracking units running at, say, 500 MHz
(both of which seem sortof optimistic to me), you're still "only" doing a
quadrillion attempts per second.  That's still many, many orders of
magnitude off the search space in any reasonable amount of time.  Obviously,
I'm not a crypto guy, but are these proposal's really for "brute force"
farms?

--Josh

PS- too lazy to g

"Austin Lesea" <austin@xilinx.com> wrote in message
news:44EC9C56.1000606@xilinx.com...
> H.Modest,
>
> First, any processor, soft or hard is far too slow to be of any use (be
> it NIOSII or 405PPC).  The design will have to be done massively
> parallel, all in logic.
>
> Virtex 5 is sampling now (65nm), and represents the latest that
> technology can offer.
>
> There are the 5VLX30, 50, 85 and 110 sampling...
>
> With the 5VLX110 you have:
>
> 17280 slices (Virtex-5 slices are organized differently from previous
> generations. Each Virtex-5 slice contains four 6 input LUTs and four
> flip-flops
>
> 64 DSP48E (Each DSP48E slice contains a 25 x 18 multiplier, an adder,
> and an accumulator.)
>
> 128 36b BRAM blocks (Virtex-5 block RAMs are fundamentally 36 Kbits in
> size. Each block can also be used as two independent 18-Kbit blocks)
>
> etc.
>
> With the clock tree supporting up to 550 MHz speeds (of course the
> design has to meet timing, and so on to find the speed it can really
> operate at).
>
> http://direct.xilinx.com/bvdocs/publications/ds100.pdf
>
> With the 6 LUT able to be a SRL32 (32 bit shift register), there are all
> sorts of tricks one can use to speed up cyrpto algorithms.  Combined
> with the DSP48E, I suspect that Virtex 5 will see some of the speediest
> encryption and decryption cores in the future.
>
> Farms of FPGAs to do brute force decryption have been proposed, and some
> have actually been built (or so the conference papers claim).  The use
> of FPGA farms for decryption is no longer "new" and may be the reason
> why triple DES is no longer recommended for new equipment (cracking
> 2E112 brute force is now considered "too easy"?).  Even AES128 is being
> skipped for new designs by those who feel that the difference between
> 2E112, and 2E128 is just not enough...(for example, we use AES256 for
> our bitstream decyptor).
>
> There is even a cracking farm that proposes the use of low cost Spartan
> 3 FPGAs (cracking on a budget?) at modest speeds.  The Spartan 3 is
> probably three times slower (at best), but since a cracking farm
> requires very little communications, being massively parallel means just
> having many devices.  Why not pick the least expensive device, and just
> use a ton of them?
>
> If you desire the fastest possible logic, with the lowest power, right
> now the Virtex 5 65nm FPGA can not be beat (as there is no other 65nm
> offering at this time by anyone, anywhere).
>
> Until there is something to compare it with, you really have only one
> choice.
>
> There is no such thing as "over-clocking" a FPGA:  either it meets
> timing and works, or it doesn't.  You may have to have very exotic
> cooling in order not to melt down the device, at speeds like 550 MHz
> with all of the logic toggling.  The Industrial temp spec is the
> junction must be kept below 100C.  Commercial grade must be kept below
85C.
>
> You could increase the clock rate till the device fails to operate
> correctly, or can not be cooled, but in this application it would be
> very difficult to know if it wasn't operating correctly!  Best to design
> it to work where it is supposed to work.
>
> Austin
>
>
>
>
> hypermodest wrote:
> > Hello.
> > I've a task to make attempt to crack some cryptographical hash-function
> > by using brute-force attack. So I wish to implement it in FPGA.
> > How can I get fastest FPGA at the modern market?
> > Altera Nios II dev kit stratix 2 edt (EP2S60) is the right choice?
> > By the way, are these devices (EP2S60) can be overclocked? If yes, how?
> >



Article: 107021
Subject: Re: Xilinx ML501 availability
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 23 Aug 2006 12:31:33 -0700
Links: << >>  << T >>  << A >>
Antti wrote:
> 
> Is that all the info about Virtex-5 board availability? My guess is
> that this time the best board (best price-performance) and first board
> available will be from Xilinx, so I will not go running to buy some 3rd
> party board before ML501 availability is known - but WHEN !?

We have hundreds of these going through production builds right now and
they will be available for sale in September.

Ed McGettigan
--
Xilinx Inc.

Article: 107022
Subject: Re: fastest FPGA
From: burn.sir@gmail.com
Date: 23 Aug 2006 12:35:07 -0700
Links: << >>  << T >>  << A >>
hypermodest wrote:
> Hello.
> I've a task to make attempt to crack some cryptographical hash-function
> by using brute-force attack. So I wish to implement it in FPGA.
> How can I get fastest FPGA at the modern market?
> Altera Nios II dev kit stratix 2 edt (EP2S60) is the right choice?
> By the way, are these devices (EP2S60) can be overclocked? If yes, how?



I got a few questions for you:

1st: do you really need to brute force it?
2nd: how much time do you got?
3rd: budget? I assume you are not working for NSA or similar YAT (Yet
Another TLA)
4th: do you really have the ambition to learn FPGA development for a
simple homework?


Given the simplicity of the algorithm and given that your search space
contsains "only"  2**64 keys, yes it can be cracked... but  I am pretty
sure that your simple hash function can be cracked by other means than
brute force.


Having said that, there are a lot of people on the Internet (some even
on this newsgroup) doing this kind of thing with very cheap FPGAs. I am
sure the Xilinx/Altera/Lattice/Actel/Quicklogic/Ateml guys are more
than happy to point out that their latest FPGA is the best one on the
market.
But the question is, even if you could afford the 10,000 USD it would
cost, would you really need it? could you really handle that beast?


regards, -Burns


Article: 107023
Subject: Re: fastest FPGA
From: "Totally_Lost" <air_bits@yahoo.com>
Date: 23 Aug 2006 12:42:38 -0700
Links: << >>  << T >>  << A >>

John_H wrote:
> You may run into power issues before you can consider overclocking.  You
> could design so much high speed logic in a huge part that you can only run
> x% of the part at Fmax or all of the part at x% of Fmax.

Right on John ... :)

As I've noted before, you seriously need to "derate" large Xiinx FPGAs
for designs that have very high percentage of active logic. Since they
assume around 15-20% of the design will be active, it's very easy to be
unable to get power into the devices within the spec'ed voltage
margins, or to keep it cool if you do. Doing single point thermal
monitoring on the die, may not be enough to readily identify that other
portions of the die are well above that limit temp once you are
agressively cooling the part.

Packing the device from edge to edge with active logic will cause
problems. At both high speeds and high density, many of the larger
parts are simply not usable.


Article: 107024
Subject: Re: fastest FPGA
From: Christian Schleiffer <cschleiffer@crypto.rub.de>
Date: Wed, 23 Aug 2006 22:00:28 +0200
Links: << >>  << T >>  << A >>
Hej,

> There is even a cracking farm that proposes the use of low cost Spartan
> 3 FPGAs (cracking on a budget?) at modest speeds.  

That farm Austin is talking about sounds like our project ;-) Have a
look at it at http://www.copacobana.org. There you can find some
conference papers as well.

> The Spartan 3 is
> probably three times slower (at best), 

Right. But it's cheap.

> but since a cracking farm
> requires very little communications, being massively parallel means just
> having many devices.  Why not pick the least expensive device, and just
> use a ton of them?

Exactly. We have a system build of 120 Spartan3-1000 FPGAs doing all
communication in full parallel on a 64-bit backplane.

[promotion]
Currently we are working on a application development framework for
both, the FPGAs and the host computer. If you are interested in the
platform, feel free to drop me an email or contact Jan Pelzl instead
(pelzl @ crypto.rub.de without the blanks, of course), he is responsible
for the project.
[/promotion]

Cheers
/Chris

-- 
Christian Schleiffer
Communication Security (COSY)
Dept. of Electr. Eng. & Information Science
Ruhr-University Bochum, Germany
http://www.crypto.rub.de
cschleiffer@crypto.rub.de



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
2019JanFebMar2019

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