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 107025

Article: 107025
Subject: Re: CPU design
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 24 Aug 2006 08:02:40 +1200
Links: << >>  << T >>  << A >>
Walter Banks wrote:

> 
> Jim Granville wrote:
> 
> 
>>The tiniest CPUs do not need a stack, and interupts do not need to be
>>re-entrant, so a faster context switch is to re-map the Registers, Flags
>>(and even PC ? ) onto a different area in BRAM.
>>You can share this resource by INTs re-map top-down, and calls re-map
>>bottom up - with a hardware trap when they collide :)
> 
> 
> Once you get into seeing clearly the relationship between features and
> cost a lot can be removed.
> 
> Interrupts can be removed at extremely low cost to applications. Both the
>   Microchip PIC12  and Freescale RS08 do not have interrupts. In the
>   RS08 C compiler we developed some software IP to where possible
>   go into a power down mode and launch execution threads that compiled as
>   execution to completion.
> 
>   The threads are typically short and a as a side effect run to completion
>   makes local re-use easy
> 
> C compilers implemented for small processors work well with out either
> a data or subroutine return stack. Two of the processors we have written
> compilers for in the last couple years both used an assessable return
> register. Flow control analysis in the compiler make nested subroutines
> user transparent.
> 
> The instruction set reduction in the RS08 from the S08 parent had a
> 4-6% impact on application performance.
> 
> Walter..

Hi Walter,
  Have you ever thought about doing a Compiler+FPGA_CPU (+Sim+Debug?) 
bundle ?

-jg




Article: 107026
Subject: Re: fastest FPGA
From: burn.sir@gmail.com
Date: 23 Aug 2006 13:07:40 -0700
Links: << >>  << T >>  << A >>
burn.sir@gmail.com wrote:
> contsains "only"  2**64 keys, yes it can be cracked... but  I am pretty

sorry, make that 2**60. Of course, a professional cryptographer could
get that down to 2**10 or so in matter of minutes


Speaking of those shady types, I happen to know a really good one. I
can ask him for help in exchange for that EP2S60 board ;)

(kidding, kidding. besides, who wants a FPGA that is not supported in
the QII webpack?)

-Burns


Article: 107027
Subject: Re: fastest FPGA
From: "hypermodest" <hypermodest@gmail.com>
Date: 23 Aug 2006 13:07:42 -0700
Links: << >>  << T >>  << A >>
burn.sir@gmail.com wrote:
> hypermodest wrote:

> I got a few questions for you:
>
> 1st: do you really need to brute force it?

I have no other idea :)

> 2nd: how much time do you got?

Let's say, one week..

> 3rd: budget? I assume you are not working for NSA or similar YAT (Yet
> Another TLA)

Between $1k and $2k.

> 4th: do you really have the ambition to learn FPGA development for a
> simple homework?

Yes, FPGA is really interesting area for me.

> 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.

You're probably right. But good and modern crypto hash-functions are
designed exactly to prevent any cryptanalysis, making brute-force as
last resort. Also, I have no enough knowledge in cryptography enough to
do complex analysis.

> 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?

I don't know yet..


Article: 107028
Subject: USB PHYs and drivers that folks have used
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 23 Aug 2006 13:08:55 -0700
Links: << >>  << T >>  << A >>
I'm putting together a system that requires a USB host and a USB device
interface (two separate interfaces).  On the 'device' side I need USB
2.0 high speed operation, on the 'host' side I can live with full speed
operation.

Perusing OpenCores I see the USB 2.0 Function IP Core which seems like
it should work for the device side.  Some questions:
- What UTMI PHYs have people used with this core and can say that they
work.  The parts listed in the OpenCores document are no longer
available, but the document is also 4 years old.
- Any uCLinux device drivers available to support all of this?
- Any other good/bad things to say about this core?

Also on OpenCores is a USB 1.1 Host and Device IP core which would work
for my USB host interface.
- What USB transceivers have people used and can say they work.  The
OpenCores document lists a Fairchild USB1T11A and a Philips ISP1105,
both of which are still available.  Anything good/bad to say about
either of these parts?
- Any uCLinux device drivers available to support all of this?
- Any other recommendations for transeivers?

For either interface, does anyone have any recommendations on other IP
cores (do not have to be 'free' cores) that have been used and tested
and have a uCLinux device driver available that should be considered?

Thanks in advance

Kevin Jennings


Article: 107029
Subject: Re: fastest FPGA
From: "hypermodest" <hypermodest@gmail.com>
Date: 23 Aug 2006 13:11:44 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> First, you have to decide how much logic you need, i.e. how much money
> you want to spend.

Between $1k and $2k.

> 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.

I'm not the pioneer :-)
http://en.wikipedia.org/wiki/EFF_DES_cracker


Article: 107030
Subject: Re: fastest FPGA
From: "hypermodest" <hypermodest@gmail.com>
Date: 23 Aug 2006 13:14:38 -0700
Links: << >>  << T >>  << A >>

John_H wrote:

> Do you intend the brute force method to use many, many parallel units?

It will be cool to use as many parallel units as they will fit in
single FPGA chip.

> How much do you want to spend?

Between $1k and $2k.


Article: 107031
Subject: Re: fastest FPGA
From: "hypermodest" <hypermodest@gmail.com>
Date: 23 Aug 2006 13:18:14 -0700
Links: << >>  << T >>  << A >>
Josh Model wrote:
> >(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?

I cannot do any cryptanalysis yet.. And I need to test about 2^48
values. In another words, I need counter, I need block taking counter
value at input and generating hashed value at output, I need comparator
to test if the result is correct and I need something to stop all this
stuff and begin to yell :-)


Article: 107032
Subject: Re: DQPs
From: "John_H" <newsgroup@johnhandwork.com>
Date: Wed, 23 Aug 2006 20:36:41 GMT
Links: << >>  << T >>  << A >>
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message 
news:4l3kepF477jU1@individual.net...
> 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

I love to laugh at myself.  Thanks! 



Article: 107033
Subject: Re: fastest FPGA
From: burn.sir@gmail.com
Date: 23 Aug 2006 13:43:29 -0700
Links: << >>  << T >>  << A >>
hypermodest wrote:
> > 2nd: how much time do you got?
>
> Let's say, one week..

Well, lets say you have a search space of 2**60.
You create a hash block that tests one key every clock cycle. you clock
your system at 200 MHZ, and you put 256 of these blocks in the same
FPGA:

2**60 / (200 000 000 * 256 * 3600 * 24 * 7)    ~= 37 weeks (*)

but for 2**48 you wil need only 1.5 hours.


Of course, if you are totally new to FPGAs, there is no chance in hell
that you can design a cracker so powerful in a week either.


>
> > 3rd: budget? I assume you are not working for NSA or similar YAT (Yet
> > Another TLA)
>
> Between $1k and $2k.

I know people do this for $99 (Xilinx S3 start kit). And I know people
do it even better for $300-500 (some Terasic Altera kit).

I think some major security chip was cracked using the former kit. But
dont expect to break AES, 3DES or even vanilla DES with that kind of
hardware.


>
> > 4th: do you really have the ambition to learn FPGA development for a
> > simple homework?
>
> Yes, FPGA is really interesting area for me.

Me too. I could do [and too often do] things like this just to learn
new stuff.

But are you here to learn or to solve a problem?


> You're probably right. But good and modern crypto hash-functions are
> designed exactly to prevent any cryptanalysis, making brute-force as
> last resort. Also, I have no enough knowledge in cryptography enough to
> do complex analysis.

The hash function you presented in sci.crypt looks anything but modern.
I wouldnt even use it to hash strings into a hash-table :)


> I don't know yet..

If you just want to learn, get a simple starter kit from Xilinx or
Altera. But dont expect to master them in a month or so. The stratix
kit is overkill for you (and most of us for that matter).



And while we are at it, AES128 is still safe. I bet the X-men will
disagree, but mostly for marketing reasons :)


burns


* I have a feeling i did something wrong, these calculation use to end
up with answers around millions of years or so :(


Article: 107034
Subject: Re: fastest FPGA
From: "hypermodest" <hypermodest@gmail.com>
Date: 23 Aug 2006 13:50:00 -0700
Links: << >>  << T >>  << A >>
burn....@gmail.com wrote:

> > > 4th: do you really have the ambition to learn FPGA development for a
> > > simple homework?
> >
> > Yes, FPGA is really interesting area for me.
>
> Me too. I could do [and too often do] things like this just to learn
> new stuff.
>
> But are you here to learn or to solve a problem?

I'm here to learn by solving problems :-)

> > You're probably right. But good and modern crypto hash-functions are
> > designed exactly to prevent any cryptanalysis, making brute-force as
> > last resort. Also, I have no enough knowledge in cryptography enough to
> > do complex analysis.
>
> The hash function you presented in sci.crypt looks anything but modern.
> I wouldnt even use it to hash strings into a hash-table :)

Anyhow, no one answering me there. "+" operation in one place is making
vacuum in my idea-generating part of mind.

> > I don't know yet..
>
> If you just want to learn, get a simple starter kit from Xilinx or
> Altera. But dont expect to master them in a month or so. The stratix
> kit is overkill for you (and most of us for that matter).

That's why I'm here, to decide what to take.


Article: 107035
Subject: Re: Xilinx ML501 availability
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 23 Aug 2006 22:53:01 +0200
Links: << >>  << T >>  << A >>
"Ed McGettigan" <ed.mcgettigan@xilinx.com> schrieb im Newsbeitrag 
news:44ECAD15.6030301@xilinx.com...
> 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.

Thanks for update!

looks like nice board :)

Antti 



Article: 107036
Subject: Re: USB PHYs and drivers that folks have used
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 23 Aug 2006 23:12:35 +0200
Links: << >>  << T >>  << A >>
"KJ" <Kevin.Jennings@Unisys.com> schrieb im Newsbeitrag 
news:1156363735.570149.227300@i42g2000cwa.googlegroups.com...
> I'm putting together a system that requires a USB host and a USB device
> interface (two separate interfaces).  On the 'device' side I need USB
> 2.0 high speed operation, on the 'host' side I can live with full speed
> operation.
>
> Perusing OpenCores I see the USB 2.0 Function IP Core which seems like
> it should work for the device side.  Some questions:

dont count on that.
the core is used as basis for commercial core, yes. but the OpenCores
version is not able to pass compliance testing IMHO

> - What UTMI PHYs have people used with this core and can say that they
> work.  The parts listed in the OpenCores document are no longer
> available, but the document is also 4 years old.
> - Any uCLinux device drivers available to support all of this?
> - Any other good/bad things to say about this core?
>
> Also on OpenCores is a USB 1.1 Host and Device IP core which would work
> for my USB host interface.
> - What USB transceivers have people used and can say they work.  The
> OpenCores document lists a Fairchild USB1T11A and a Philips ISP1105,
> both of which are still available.  Anything good/bad to say about
> either of these parts?
> - Any uCLinux device drivers available to support all of this?

OC FS host-dev core has uClinux 2.6 drivers for NIOS-II

> - Any other recommendations for transeivers?
>
doesnt really matter, most of them are useable actually.
for HS ULPI is way better as it takes less wiring.

> For either interface, does anyone have any recommendations on other IP
> cores (do not have to be 'free' cores) that have been used and tested
> and have a uCLinux device driver available that should be considered?
>
> Thanks in advance
>
> Kevin Jennings
>

for FPGA resource utilization the price for USB HS core is just way above
dedicated silicon. eg adding a HS host-device chip to FPGA is cheaper
than adding the PHYs an having an FPGA USB core.

whatever FPGA USB IP core you choose, you end up spending 3 to 12
months with verification and compliance testing.

Antti




Article: 107037
Subject: esoteric hardware?
From: "hypermodest" <hypermodest@gmail.com>
Date: 23 Aug 2006 14:28:36 -0700
Links: << >>  << T >>  << A >>
Hello.
By the way, does anybody here have enough sense of humor to build
esoteric hardware using FPGA?
Esoteric hardware can be extension of esoteric programming languages:
http://en.wikipedia.org/wiki/Esoteric_programming_language
There're also you may find brilliants like that:
http://en.wikipedia.org/wiki/Malbolge_programming_language


Article: 107038
Subject: Re: fastest FPGA
From: "hypermodest" <hypermodest@gmail.com>
Date: 23 Aug 2006 14:33:46 -0700
Links: << >>  << T >>  << A >>
burn.sir@gmail.com wrote:
> burn.sir@gmail.com wrote:
> > contsains "only"  2**64 keys, yes it can be cracked... but  I am pretty
>
> sorry, make that 2**60. Of course, a professional cryptographer could
> get that down to 2**10 or so in matter of minutes

Again, I have no idea how to do this, but having hope though.

> Speaking of those shady types, I happen to know a really good one. I
> can ask him for help in exchange for that EP2S60 board ;)

Huh, no thanks.

> (kidding, kidding. besides, who wants a FPGA that is not supported in
> the QII webpack?)

What is QII webpack?


Article: 107039
Subject: Re: CPU design
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 23 Aug 2006 14:50:52 -0700
Links: << >>  << T >>  << A >>
Frank Buss wrote:
> PeteS wrote:
>
> > Do you want a processor you can simply instantiate, or are you willing
> > to tweak so you get the features you want? If so, you could take one of
> > the less ambitious cores and adjust the instruction set to optimise it
> > for your application.
>
> Adjusting the instruction set to the problem domain is a good idea. I'll
> try to write the functions, first, maybe using domain specific instructions
> (like a block copy command), and then I'll implement the core for it.
>
> --
> Frank Buss, fb@frank-buss.de
> http://www.frank-buss.de, http://www.it4-systems.de

I did exactly this in a previous job. Picoblaze was nice, but there
were things it did not have, and conversely things I would never use.

So I did the code (pseudocode first) and then designed the device to do
the necessary functions at the microcode level. Because my problem
domain was very constrained, I needed only 16 instructions (I like it
when I get nice numbers like that as a solution) to do what I needed.

Then I wrote (well, I changed :) an assembler to program it.

Worked very well, and took about half the space of a picoblaze,
including a DMAC engine (excluding the memory interface which was there
anyway).

Cheers

PeteS


Article: 107040
Subject: Re: Open source Xilinx JTAG Programmer released on sourceforge.net
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: 23 Aug 2006 23:59:23 +0200
Links: << >>  << T >>  << A >>
fpgakid@gmail.com wrote:
> Hi All,
> 
> I've released the first version of my Xilinx JTAG programmer for
> Win32/Linux.

I've got a spartan3e starter board, it connects to the PC through a
USB cable. The windows software works fine, but under linux the
only way I can get xilinx impact to download is if I first boot up
in windows, then reboot into linux.

Would your driver/software work with the spartan3e board with
integrated USB device port?

-Dave

Article: 107041
Subject: Re: esoteric hardware?
From: Frank Buss <fb@frank-buss.de>
Date: Thu, 24 Aug 2006 00:12:31 +0200
Links: << >>  << T >>  << A >>
hypermodest wrote:

> By the way, does anybody here have enough sense of humor to build
> esoteric hardware using FPGA?

I don't know what you mean, maybe some useless hardware projects for fun?
What about building a Theremin:

http://en.wikipedia.org/wiki/Theremin
http://www.youtube.com/watch?v=eNl8qq-f1F0

I think with a FPGA it should be possible to produce much more interesting
effects.

Or plug-in a MIDI keyboard and implement a synthesizer, which simulates
instruments physically correct. Output could be simply PWM (a FPGA is fast
enough for a high output resolution) with an RC filter.

http://www.fpga4fun.com/PWM_DAC.html

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 107042
Subject: Re: uclinux on spartan-3e starter kit
From: John Williams <john.williams@petalogix.com>
Date: Thu, 24 Aug 2006 09:03:26 +1000
Links: << >>  << T >>  << A >>
Hi David,

David wrote:

> i am looking for any step by step guide to use uclinux on the starter
> kit.

A Linux-ready reference design for the Spartan3E500 starter kit is available now
from PetaLogix:

http://www.petalogix.com/news_events/Spartan3E500-ref-design

Regards,

John
-- 
Dr John Williams
www.PetaLogix.com
(p) +61 7 33652185  (f) +61 7 33654999

PetaLogix is a trading name of UniQuest Pty Ltd

Article: 107043
Subject: Re: Timing
From: "Symon" <symon_brewer@hotmail.com>
Date: 24 Aug 2006 01:07:24 +0200
Links: << >>  << T >>  << A >>
"Andy" <jonesandy@comcast.net> wrote in message
news:1156356933.496598.141050@h48g2000cwc.googlegroups.com...
> 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.
>
Right. It all relies on having the correct static constraints to start with.
My own personal methodology for multi-cycle constraints is to code the RTL
to make the constraints easy. (Ahem!) So, I use a signal as a global clock
enable for the multi-cycle machine, and is _only_ used as a clock enable.
Thus any path that is between elements driven by that enable is a
multi-cycle path. It's nice and easy to specify these paths in a UCF file.
>
> 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
>
>
That could be very useful. I guess there's a lot of designs, my own
included, that have multi-cycle paths that aren't constrained as such
because they meet the timing anyway. Perhaps PAR times could be reduced
significantly if a tool could pick out these paths.
Cheers, Syms.



Article: 107044
Subject: Re: Open source Xilinx JTAG Programmer released on sourceforge.net
From: "zcsizmadia@gmail.com" <zcsizmadia@gmail.com>
Date: 23 Aug 2006 16:50:54 -0700
Links: << >>  << T >>  << A >>
This version supports only Digilent USB programmer cable!
Unfortunately I don't have money to buy a Spartan-3E Starter Kit and
reverse engineer the USB protocoll.

Zoltan


Article: 107045
Subject: Global signal conservation
From: David Ashley <dash@nowhere.net.dont.email.me>
Date: 24 Aug 2006 02:03:28 +0200
Links: << >>  << T >>  << A >>
Hi,

In opencores DDR implementation, the author uses a PLL
to generate a clock of multiple phases. The PLL outputs
true and inverted signals, in perfect sync.

However the author doesn't use the inverting output of
the PLL -- to generate an inverted output he inverts the
true clock output and uses that.

I'm trying to figure out why he did this. Is it because if
you use the single clock source, then you only need one
global clock buffer -- but if you use both, presumably
there would be 2 global clock buffers used, and this
is excessive for the design?

Moreover the design needs a 2 phased clock. All clocks
are 100 mhz. So 2 phases, 2 types (true/inverted) with
minimum clock skew would necessitate 4 global clock
buffers, right?

Instead evidently he opted for just the 2 true clocks,
then uses inverters when he wants the inverted version.

Now this means the inverted signal will be delayed by
the inverter. This appears on the order of .5 to 1 ns in
the parts I'm interested in.

So perhaps it's a tradeoff -- minimum skew requires
4 global clock buffers. Perhaps the inverter approach
conserves global clock buffers at the expense of a little
bit of skew.

Anyway I just am looking for a sanity check. Does the
reasoning above sound...reasonable? When designing
is it necessary to keep these things in mind?

Thanks--
Dave

Article: 107046
Subject: Re: DCM vs. PLL
From: "Rob" <robnstef@frontiernet.net>
Date: Thu, 24 Aug 2006 00:37:14 GMT
Links: << >>  << T >>  << A >>
I appreciate the feedback guys.  Sorry for the delayed response--I've been 
tied up all day.

The interface, though it looks like Camera Link, is not.  The V2PRO part 
would need to receive from three separate IC's ,each generating its own 
45MHz clock and three lanes of x7 serialized data.  So, yes, the FPGA would 
need to take the 45MHz and derive the 315MHz fast clock to pick off the 
data.  So, based on this thread, there's nothing inherent about the DCM 
which would preclude it from this task.

I wonder why this other group is telling me that the V2PRO can't do the job? 
Perhaps the V2PRO30 doesn't have enough DCM's?  I believe the FPGA would 
need to have three, since there are three IC's generating the data.  You 
couldn't just use one of the three clocks for all the data lanes because the 
three chips could have some slight variation in timing.  The implemenation I 
chose was to use three PLL's, and clock everything into a FIFO to switch and 
sycnchronize all the data from the three chips into a single clock domain. 
I implemented this within a Stratix (sorry Austin--nothing personal. When I 
entered into the FPGA world my group used Altera) and it works.  The design 
must be transferred to another group for a different design and the 
constraint (long story) is to use the V2PRO.  The contingency plan is to use 
National's 90C flavor chips to deserialize the data before the V2PRO, thus 
sending it parallel data.

My original post--due to my ignorance about the device--was to inquire about 
the DCM and its capability and limitations (if any) with this interface.

Take care,
Rob



"Antti Lukats" <antti@openchip.org> wrote in message 
news:eci8hd$ml$1@online.de...
>
> "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: 107047
Subject: Re: CPU design
From: "jacko" <jackokring@gmail.com>
Date: 23 Aug 2006 19:25:12 -0700
Links: << >>  << T >>  << A >>

PeteS wrote:
> Frank Buss wrote:
> > PeteS wrote:
> >
> > > Do you want a processor you can simply instantiate, or are you willing
> > > to tweak so you get the features you want? If so, you could take one of
> > > the less ambitious cores and adjust the instruction set to optimise it
> > > for your application.
> >
> > Adjusting the instruction set to the problem domain is a good idea. I'll
> > try to write the functions, first, maybe using domain specific instructions
> > (like a block copy command), and then I'll implement the core for it.
> >
> > --
> > Frank Buss, fb@frank-buss.de
> > http://www.frank-buss.de, http://www.it4-systems.de
>
> I did exactly this in a previous job. Picoblaze was nice, but there
> were things it did not have, and conversely things I would never use.
>
> So I did the code (pseudocode first) and then designed the device to do
> the necessary functions at the microcode level. Because my problem
> domain was very constrained, I needed only 16 instructions (I like it
> when I get nice numbers like that as a solution) to do what I needed.
>
> Then I wrote (well, I changed :) an assembler to program it.
>
> Worked very well, and took about half the space of a picoblaze,
> including a DMAC engine (excluding the memory interface which was there
> anyway).
>
> Cheers
>
> PeteS

AHDL for a two register NOP, INC, DEC, WRITE unit

http://indi.joox.net link to quartus II files, BIREGU.bdf

good for interruptable stack pointers


Article: 107048
Subject: Re: DCM vs. PLL
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 23 Aug 2006 20:08:29 -0700
Links: << >>  << T >>  << A >>
It looks pretty straightforward to me.
Three incoming ~45 MHz clocks, each multiplied by 7 in its own DCM,
triggering the input DDR registers. You have to do a little bit of
thinking, because 7 is an odd number, but I see no problem with that.
Of course, it would be much simpler in Virtex-4, but that seems to be
not your choice.
Peter Alfke, Xilinx (from home)


Article: 107049
Subject: Re: Global signal conservation
From: "Marc Randolph" <mrand@my-deja.com>
Date: 23 Aug 2006 21:05:01 -0700
Links: << >>  << T >>  << A >>
David Ashley wrote:
[...]
> However the author doesn't use the inverting output of
> the PLL -- to generate an inverted output he inverts the
> true clock output and uses that.
>[...]
> Moreover the design needs a 2 phased clock. All clocks
> are 100 mhz. So 2 phases, 2 types (true/inverted) with
> minimum clock skew would necessitate 4 global clock
> buffers, right?

Yep.

> Instead evidently he opted for just the 2 true clocks,
> then uses inverters when he wants the inverted version.
>
> Now this means the inverted signal will be delayed by
> the inverter. This appears on the order of .5 to 1 ns in
> the parts I'm interested in.

Could you name the parts you are referring to?  I find it surprising
that an inverter within the global clock network would take that long,
and more surprising that you can get off the global clock net and
through a LUT-based inverter.  So surprised, in fact, that I had to go
try it for myself.  I put three different examples in the design,
rising_edge(clk), falling_edge(clk) as well as a clk_inv <= NOT clk
were each clocking an output.  The design used one global clocks and
the inverter immedately in front of the FF (which doesn't take 0.5 ns).
  Synthesis tool (Synplicity) choice or tool options may have something
to do with this.  Of course, it pulled the FF for the outputs with
inverted clocks out of the IOBs, but that's a separate issue

> So perhaps it's a tradeoff -- minimum skew requires
> 4 global clock buffers. Perhaps the inverter approach
> conserves global clock buffers at the expense of a little
> bit of skew.

Don't forget the skew between different global clock nets caused by
uneven loading of the clocks (if some have much heavier loading than
others).

> Anyway I just am looking for a sanity check. Does the
> reasoning above sound...reasonable? When designing
> is it necessary to keep these things in mind?

Yes.  These things, and many others :-)

Have fun,

   Marc




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