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 67575

Article: 67575
Subject: Re: copy protection on FPGA using embedded serial number
From: johnjakson@yahoo.com (john jakson)
Date: 15 Mar 2004 00:30:19 -0800
Links: << >>  << T >>  << A >>
hmurray@suespammers.org (Hal Murray) wrote in message news:<1059vdl3k9a0g49@corp.supernews.com>...
> >In the black helicopter scenario the stuff of movies I have heard and
> >slightly believe the following which does make some sense. If you are
> >familiar with any eeprom technology or device physics your half way
> >there.
> 
> It doesn't take black helicopters.  Just modest amounts of cash.
> University resources:
>   http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf
>   http://www.cl.cam.ac.uk/~mgk25/sc99-tamper-slides.pdf
> 
> It's very well done.  I'd call it required reading for anybody
> interested in keeping secrets in chips.

hmurray@suespammers.org (Hal Murray) wrote in message news:<1059vdl3k9a0g49@corp.supernews.com>...
> >In the black helicopter scenario the stuff of movies I have heard and
> >slightly believe the following which does make some sense. If you are
> >familiar with any eeprom technology or device physics your half way
> >there.
> 
> It doesn't take black helicopters.  Just modest amounts of cash.
> University resources:
>   http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf
>   http://www.cl.cam.ac.uk/~mgk25/sc99-tamper-slides.pdf
> 
> It's very well done.  I'd call it required reading for anybody
> interested in keeping secrets in chips.

I haven't read the papers yet but it looks like they are saying what I
was just about to, otherwise looks like good reading. I looked at the
pics and can see a problem, all these chips are old maybe 2 or 3
levels of metal and probably aluminum and low resolution. Didn't see
anything that might be as diff as modern process just yet.

FPGAs with the crypto stuff are maybe 8 levels of copper and .13u and
lower.

I also spent time on a FIB machine (just watching though) fixing some
2 level aluminum 0.8u mixed signal chips tuning R & C vals and a few
wire connects.

Really amazing what the guy could do, starting wires where none
existed, putting in vias and bridges and cuts. But also very iffy, not
likely to work afterwards and damned expensive, a few $K an hour. The
results looked like a kid using MacPaint spray gun, you need a whole
lot of clear space to make clean cuts and new wires and its very
resistive. The effective resolution of these wires is closer to 10u of
space maybe more, and it seemed to do only a few items /hr. We were
lucky to get a few parts repaired, enough to do the mask respin with
better info. There also aren't that many of them, 1 at Intel, IBM and
an independant across the street from Intel HQ, maybe a few more. Old
info.

Now if modern FIB can handle high density wiring and 8 laters, I'd be
more worried about Nicks $100k, but I doubt they kept up. For one
thing FPGAs replace FIB machines as the way to proto in the 1st place,
no reason to be making mistakes in an ASIC so why have FIBs around and
if they could get that resolution they'd be far more expensive than
the $1M 8yrs ago.


Back to the vt problem I mentioned before, the paper talks of it too.
Not sure if they say it, but if a flop never toggles, it remembers the
same way with the vt shift, throw the battery away and carefully ramp
the power rail for that circuit and the flop is just a superb
amplifier with a built in small signal fixed in the oxide. To counter
that, the reset logic should jam it from powering up unaided as its
only supposed to reset once before the key is given to it. Of course
if the reset is FIBed or disabled, and the flops can power up by
themselves, I think it will come up inverted. Now once the flops are
up, you can read them with an EBeam. To speed up the vt drift, one
could also cook the part with battery replaced carefully with hot psu
at higher voltage.

I have to wonder whether the circuit guys went to the trouble of
anticipating these sorts of attacks. This really would only concern a
certain agency  in possesion of enemy crypto system using these parts,
but good JB movie material.

back to reading

Article: 67576
Subject: Re: ANN: new Pulsonix version 3 PCB software released
From: "David Brown" <david@no.westcontrol.spam.com>
Date: Mon, 15 Mar 2004 09:58:57 +0100
Links: << >>  << T >>  << A >>

"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote in message
news:4054b166@news.nb.nu...
> "Jerry Avins" <jya@ieee.org> wrote in message
> news:405490ea$0$2798$61fed72c@news.rcn.com...
> > Meindert Sprang wrote:
> > > That is simply not true. I have written several DOS applications in
the
> past
> > > that access serial ports at register level, i.e. direct access to the
> serial
> > > chip. These application still run fine in Windows NT and 2000. Only
> direct
> > > access to the printer port is blocked.
> > >
> > > Meindert
> >
> > You are the first correspondent who makes that claim. I'm sure you're
> > right, and I want to learn from you. If I were to add a printer port at
> > a non-standard address, would I be able to access that too?
>

Let me be the second to make that claim (actually, I'm not the second, as a
search on comp.arch.embedded history will reveal - we've been through this
discussion several times before).

> No. Printer ports are not accessible at register level. But on the
internet,
> several drivers/services are available that, once installed, allow
programs
> to access specific or simply all hardware ports. The ones for printer
ports
> are most famous because of the many ulitities that program
microcontrollers
> etc. through an interface that is connected to a printer port.
>

If you are interested, the most common driver used is "giveio".  If this
driver is installed on an NT machine (including W2K and XP), then a program
can simply open a file handle to this driver, and thereafter it has full
access to the hardware on the PC.  Converting a program that accesses the
parallel port into one that runs safely and quickly on NT involves nothing
more than adding this access (a couple of lines of code) and putting the
giveio driver (freely available) into its install program.  This is used by
most programmers and debuggers that use the parallel port.

For programs that don't have this support, there is another less safe
solution.  Install the "totalio" driver (also freely available).  When you
start it, *all* programs get full hardware access.  It's therefore not the
safest of solutions, and you should set the driver to manual startup (so
that you use "net start totalio" and "net stop totalio" afterwards), but it
will let any Win9x, or even Win16 or DOS program access the parallel port
directly on NT.




Article: 67577
Subject: Re: 300MHz spartan3 cpu update , and Webpack6.2 shocker
From: Philip Freidin <philip@fliptronics.com>
Date: Mon, 15 Mar 2004 10:18:14 GMT
Links: << >>  << T >>  << A >>
On 11 Mar 2004 06:49:26 -0800, johnjakson@yahoo.com (john jakson) wrote:
>
>It is now possible for cpu designers to build computers with far more
>interesting architectures in far less time than ASIC teams could ever
>concieve. FPGA foundry does all the hard work of making the BlockRams
>and logic fabric go as fast as most ASIC cell designs and architects
>put it together.
>

The following is an extract from an article I wrote in July 1992:

 The extremely quick prototype time to try an algorithm on one of these
 reconfigurable boards, to play with it, to profile it, and analyse the
 results, allows for exploration of the algorithm space in a manner never
 possible before. I have spoken with most of the above groups, and all
 have reported that the realy impressive speedups come when the you have
 enough hardware that is reconfigurable, that you can focus on trying
 multiple different approaches to a given problem. There are no costs
 involved in reconfiguring one of these boards (other than the time it
 takes to dream up a new algorithmic approach, and then implement it).
 It does not surprise me that these boards of "slow" FPGAs can outperform
 full custom chips designed for specific applications. The algorithm
 space is usually very large, and for computationally intense applications
 it may not be possible to do enough simulations to find which algorithm
 is best before commiting to build the full custom chip.



You can read the rest if you wish, at http://tinyurl.com/37dg3



Philip Freidin



===================
Philip Freidin
philip@fliptronics.com
Host for WWW.FPGA-FAQ.COM

Article: 67578
Subject: Re: XAPP607: Is this just paperwork or based on a real design
From: "Markus Meng" <meng.engineering@bluewin.ch>
Date: Mon, 15 Mar 2004 11:36:16 +0100
Links: << >>  << T >>  << A >>
Hi Marc,

thank's for your reply. I agree, maybe I was little
to 'hard' with Xilinx. However if you want make most use of this
application note, without buying the eval sytem, it would be useful
if a bill of material would be available. Finding the oscillator
and maybe the clock buffer, if any, is not trivial, since it has tight
peak-top-peak jitter requirements. Since the eval system is there
and running, the BOM is there too.

Have a nice day

Markus

"Marc Randolph" <mrand@my-deja.com> schrieb im Newsbeitrag
news:4ridnW-xA5QZl87dRVn-iQ@comcast.com...
> Markus Meng wrote:
> > Hi all and hi Xilinx,
> >
> > actually dealing with gigabit transmission using
> > external SERDES devices from TI, I just wonder if
> > the app note xapp607 is just paper-and-vhdl-work,
> > or if it is based on measurements on a real design.
> >
> > The general advices are 'nice', however at that frequency
> > in multigigabit transmission, I would like to know
> > a little bit more about the clock source for the
> > GTX_CLK. According to the datasheet from TI clock
> > jitter is a non-trivial requirement.
> >
> > If Xilinx has really build such a system and made some
> > measurements, what kind of clock sources have been used?
> >
> > It seems to be obvious, that no DCM is involved in the
> > design, however it is somehow not clear enough stated,
> > that it will not work for more than half an hour or so,
> > before failure if the GTX_CLK is coming out of a DCM ...
> >
> > Any comments on this?
> >
> > Have a nice weekend
> > Markus
>
> Howdy Markus,
>
> The copy of XAPP607 that I have explains that the note is based on a
> real-world eval board called the "XLVDS demonstration board," so I'm not
> sure why you'd think it's a paper only design.
>
> Also, page 13 of the copy that I have (v1.0) indirectly says that
> GTX_CLK should not come from a DCM.
>
> If you are using a device without DDR flops (like a Spartan IIE or
> less), you'd want to follow the advice of the last sentence on that
> page, where is says that the clock from the external oscillator should
> be routed directly to both TLK and FPGA devices.  You can do this as
> long as each leg of the traces going to the two devices are close to the
> same length.
>
> Good luck,
>
>     Marc
>
> --
> Return email address is a spam trap.  Please post responses.



Article: 67579
Subject: Altera Cyclone - Conf_done remains low ??
From: "ruth" <ruthsims@hotmail.com>
Date: Mon, 15 Mar 2004 10:51:24 -0000
Links: << >>  << T >>  << A >>
Hi,

I'm trying to program a Cyclone EP1C4 via JTAG through Quartus.  Quartus
happily recognises the device and says that it has programmed it.  However
the device does not operate as expected and the conf_done line never goes
high (but all other configuration and control lines seem to be the correct
logic level), does anyone have any hints as to what I should look at next
please.  I can't seem to figure out whats wrong.

Thanks

Ruth



Article: 67580
Subject: Re: Anyone Had Spurious Reconguration Issues With Cyclone Devices?
From: DaS <none@nospam.com>
Date: Mon, 15 Mar 2004 11:54:19 +0100
Links: << >>  << T >>  << A >>
In fact, it was just a watchdog trigger that occured.
We solved it.

And for you ?


rAinStorms a écrit:
> I think that it is a supply susceptability problem we are experiencing.
> 
> "DaS" <none@nospam.com> wrote in message news:40502C56.2000300@nospam.com...
> 
>>Hi,
>>
>>not with Cyclone, but with Excalibur. Not really the same thing, but
>>similar : device makes a new configuration every n secondes.
>>Asked help from Altera, but we don't still have found why.
>>We still go on searching : bug on device ? On our design ? On suplly
>>(they seem to be stable).
>>We don't know.
>>Let me know if you find for your Cyclone.
>>
>>Damien.
>>
>>
>>rAinStorms a écrit:
>>
>>>Hi,
>>>
>>>I am wondering if anyone out there has experienced random spurious
>>>reconfiguration issues with Cyclone devices?
>>>We have an issue where the FPGA in our design configures correctly but
>>
> then
> 
>>>a short time later for apparently no reason goes int a reconfig cycle
>>>and stays there (as its not loaded). I suspect that there might be an
>>
> issue
> 
>>>with our power supply design but still have not isolated the problem ...
>>
> and
> 
>>>on the off-chance this is a larger issue, it seems like a good idea to
>>
> see
> 
>>>whether other people have experienced similar problems.
>>>
>>>Thanks,
>>>Chris
>>>
>>>
>>
> 
> 


Article: 67581
Subject: Which should I use, Floorplanner or PACE
From: Philip Freidin <philip@fliptronics.com>
Date: Mon, 15 Mar 2004 11:18:54 GMT
Links: << >>  << T >>  << A >>

There seem to be at least 6 ways of specifying area constraints
for a XC2V6000 design I am working on:

1) The constraints editor

2) My favorite editor UltraEdit, on the UCF file

3) The Floorplanner

4) PACE

5) FPGA editor

6) Embedded in the Verilog source


I expect that I will be doing both area constraints for each section
of sub-hierarchy in the design, plus some detailed placement of some
specific logic like I/O FFs, Memories, and multipliers.

I would appreciate comments on which tool is the right one for the
job, or if the answer is that multiple of these will be needed, what
are the pros and cons of each, especially Floorplanner vs PACE
(and maybe vs FPGA editor)


Thanks,
Philip




Article: 67582
Subject: Re: Altera Cyclone - Conf_done remains low ??
From: "ruth" <ruthsims@hotmail.com>
Date: Mon, 15 Mar 2004 11:34:38 -0000
Links: << >>  << T >>  << A >>
In answer to my own question - JTAG configuration doesnt work on Quartus3
without service packs installed.

"ruth" <ruthsims@hotmail.com> wrote in message
news:40558aac$0$3306$ed9e5944@reading.news.pipex.net...
> Hi,
>
> I'm trying to program a Cyclone EP1C4 via JTAG through Quartus.  Quartus
> happily recognises the device and says that it has programmed it.  However
> the device does not operate as expected and the conf_done line never goes
> high (but all other configuration and control lines seem to be the correct
> logic level), does anyone have any hints as to what I should look at next
> please.  I can't seem to figure out whats wrong.
>
> Thanks
>
> Ruth
>
>



Article: 67583
Subject: =?iso-8859-1?Q?EAB=B4s?= in ACEX 1K devices
From: "roland voraberger" <madcap@sbox.tugraz.at>
Date: 15 Mar 2004 12:48:36 GMT
Links: << >>  << T >>  << A >>
hello!

i´ve got big problems with RAM in a ACEX 1k design. i can´t get a fit
because i use too much (16/ 12) EAB´s but in total number of bits i´m
far beyond the maximum number of the bits available.
what can i do (software is max+plus II 10.1)

thanks in advance, roland

 

Article: 67584
Subject: Programmed ground pins v physical grounding (Xilinx CPLD)
From: "Jim" <me@privacy.net>
Date: Mon, 15 Mar 2004 14:29:58 -0000
Links: << >>  << T >>  << A >>
I'm working on a board using the Xilinx XC9572XL-10 (VQ64). The clock is
running at 12MHz.

I am planning to program the 5 unused pins as additional grounds. The spare
pins are pretty evenly spread around the sides of the chip. Currently, these
spare pins have isolated pads with no connection to the ground plane.

The PCB is double-sided with a ground plane on the reverse. Would it be
worth also connecting the spare pins to the ground plane using vias? The
vias may have to be underneath the Xilinx due to the space required.

Thank you,

Jim





-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----

Article: 67585
Subject: Re: 300MHz spartan3 cpu update , and Webpack6.2 shocker
From: johnjakson@yahoo.com (john jakson)
Date: 15 Mar 2004 06:51:04 -0800
Links: << >>  << T >>  << A >>
Philip Freidin <philip@fliptronics.com> wrote in message news:<140b50hpuo47b36igshbttsrdglfpo94ru@4ax.com>...
> On 11 Mar 2004 06:49:26 -0800, johnjakson@yahoo.com (john jakson) wrote:
> >
> >It is now possible for cpu designers to build computers with far more
> >interesting architectures in far less time than ASIC teams could ever
> >concieve. FPGA foundry does all the hard work of making the BlockRams
> >and logic fabric go as fast as most ASIC cell designs and architects
> >put it together.
> >
> 
> The following is an extract from an article I wrote in July 1992:
> 
>  The extremely quick prototype time to try an algorithm on one of these
>  reconfigurable boards, to play with it, to profile it, and analyse the
>  results, allows for exploration of the algorithm space in a manner never
>  possible before. I have spoken with most of the above groups, and all
>  have reported that the realy impressive speedups come when the you have
>  enough hardware that is reconfigurable, that you can focus on trying
>  multiple different approaches to a given problem. There are no costs
>  involved in reconfiguring one of these boards (other than the time it
>  takes to dream up a new algorithmic approach, and then implement it).
>  It does not surprise me that these boards of "slow" FPGAs can outperform
>  full custom chips designed for specific applications. The algorithm
>  space is usually very large, and for computationally intense applications
>  it may not be possible to do enough simulations to find which algorithm
>  is best before commiting to build the full custom chip.
> 
> 
> 
> You can read the rest if you wish, at http://tinyurl.com/37dg3
> 
> 
> 
> Philip Freidin
> 
> 
> 
> ===================
> Philip Freidin
> philip@fliptronics.com
> Host for WWW.FPGA-FAQ.COM

Hi Philip

Did you notice the recent acq by Cray of Octiga Bay.

All the current super comps are using AMD64 but Octiga IIRC is putting
in V2pros in there for anyone wanting to do whatever they can figure.
Perhaps it had to happen 1st only at the very very rich end. Each
AMD64 is costing about 4k or 8k per node. If that node include FPGAs
that would be fair, if not I'd buy mine at the store. I also notice
the folks at comp.arch noticed the acq but ignored the FPGA part.

But now you can also say if you got an FPGA PCI card you have your own
Octiga Bay/Cray jnr, esp it it runs on same AMD64. It can't be a bad
thing to start the ball rolling to get super comp users into looking
at developing FPGA algorithms. I think they were looking at the Bio
apps since that looks llke it might be the richest market and
TimeLogic already showed the way there. Hope to see alot more people
copying that, but what if nobody comes to the party.

regards

johnjakson_usa_com

Article: 67586
Subject: Re: Altera, Cyclone: pin not connected warning
From: fredrik_he_lang@hotmail.com (Fredrik)
Date: 15 Mar 2004 07:40:54 -0800
Links: << >>  << T >>  << A >>
Hi,
I haven't read the previous tread about tri-states. But I when I
learned about tri-states they where most defintly not a pull-up on
them. A tri-state should not interfer with the bus at all in a perfect
world (add load in any direction).
I personally prefer to drive unused pins to ground or VCC depending on
location since I usally get a better EMI preformance then. But if I by
misstake connect a signal to my design that is running stuff on the
board I would not drive it in any direction and corrupt the data.
Rgds
Fredrik

erojr <janos.nojunk.nospam.ero@cern.nojunk.nospam.ch> wrote in message news:<c2ugfm$iuh$1@sunnews.cern.ch>...
> Fredrik wrote:
> > Hi,
> > I would remove the pin assigment in Quartus (since you not using the
> > pin it should not be in your design). Second you have the option to
> > set (Assignment/Settings/ -> Device tap and Device and pin option
> > button -> Unused pin tab) all unused pins to tri-state. I guess this
> > is what you want if you have a signal on a pin that is not used.
> 
> I think, if you declare in the Unused pin tab  As inputs, tri-stated 
>  
> (This is the exact declaration! The other options are  As outputs, 
> driving ground  and  As outputs, driving an unspecified signal  - I
>  
> would really like to know what is this later exactly!), you end up in 
> your hardware a large number of unconnected input pins. Just in the last 
> 
> thread about unconnected  TRST  pin several people pointed out, that 
> 
> input pins MUST NOT remain unconnected, as they might start to oscillate 
> 
> in high frequency, possibly destroying your FPGA. Or am I mistaken?
> 
> I did not find any indication in Altera Datasheets if the input pins 
> have internal weak pullup resistors in general (the TRST pin should have 
> 
> one, by definition). This also means if the unused pins aren t connecte
> d 
> at all they must not be declared  As inputs, tri-stated .
> 
> Could somebody explain here what is the correct procedure?
> 
> Thanks,
> 
> Janos Ero
> CERN Div. EP

Article: 67587
Subject: Xilinx Vertex-II Pro Logic Cells compared to Slices
From: simon.stockton@baesystems.com (stockton)
Date: 15 Mar 2004 09:14:31 -0800
Links: << >>  << T >>  << A >>
Dear All, 

I was wondering if someone could enlighten me.

I am looking at trying to size an Xilinx Vertex-II Pro FPGA (possible
XC2VP30) for use in a design, part of the design will incorporate a
third party IP core. My problem is that the Xilinx device specifies
capacity in "Logic Cells" where as the IP code developers appear to
specify required capacity for their IP cores in "Slices"!

I have tried to find out the relationship between Logic Cells and
Slices and have only succeeded in getting myself confused.

It appears that (for the Xilinx Vertex-II Pro devices) that a "Slice"
equates to approximately 2 "Logic Cells".

If anyone could confirm this or indeed enlighten me if I am incorrect,
I would be most appreciative.

Regards

Simon

Article: 67588
Subject: Virtex II Pro default I/O mode
From: Mancini Stephane <nospam@nospam.nospam>
Date: Mon, 15 Mar 2004 18:15:42 +0100
Links: << >>  << T >>  << A >>
Hi,
Please, could someone tell me what's the default I/O mode for Virtex II
Pro Pin ?

Furthermore, because of a particular design, I need to connect two I/Os
together sometimes but I'm wondering what's happening if they have two
outputs with different voltages.
Can it dammage them or  would I just get an undefined  voltage drop ?
What's your opinion about that ?

Thanks a lot.

Stéphane

Article: 67589
Subject: Re: Which should I use, Floorplanner or PACE
From: Jakab Tanko <jtanko@ics-ltd.com>
Date: Mon, 15 Mar 2004 12:52:51 -0500
Links: << >>  << T >>  << A >>
Philip Freidin wrote:
> There seem to be at least 6 ways of specifying area constraints
> for a XC2V6000 design I am working on:
> 
> 1) The constraints editor
> 
> 2) My favorite editor UltraEdit, on the UCF file
> 
> 3) The Floorplanner
> 
> 4) PACE
> 
> 5) FPGA editor
> 
> 6) Embedded in the Verilog source
> 
> 
> I expect that I will be doing both area constraints for each section
> of sub-hierarchy in the design, plus some detailed placement of some
> specific logic like I/O FFs, Memories, and multipliers.
> 
> I would appreciate comments on which tool is the right one for the
> job, or if the answer is that multiple of these will be needed, what
> are the pros and cons of each, especially Floorplanner vs PACE
> (and maybe vs FPGA editor)
> 
> 
> Thanks,
> Philip
> 
> 
> 
I used PACE for pin assignments and area constraints on an
XC2V4000 design and the floorplaner for placing block RAM;
Both of these write the constraints to the UCF file so I think
a combination of these tools is required to do the job.
The FPGA editor I only used to view the design and double check
that everything ends up where it supposed to after PAR.
The UCF flow is a good choice for keeping all your constraints in one
place and it also has the advantage over other methods (say, putting
constraints in your source code) that you don't have to re-synthesise
the design if only the constraints change.
---
jakab

Article: 67590
Subject: New release of TBGenerator v.3.00 (new GUI, new functional possibility, new Wave Form...) www.hightech-td.com
From: vboykov@yandex.ru (vladimir)
Date: 15 Mar 2004 10:13:35 -0800
Links: << >>  << T >>  << A >>
New release of TBGenerator v.3.00 (new GUI, new functional
possibility, new Wave Form, new price) www.hightech-td.com

Article: 67591
Subject: Re: 300MHz spartan3 cpu update , and Webpack6.2 shocker
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 15 Mar 2004 13:38:14 -0500
Links: << >>  << T >>  << A >>
Thanks for the info, but I know that I can instantiate logic.  But I was
looking to get the tool to infer the cascade chain.  There is even a
setting that specifies the number of cells to use in a chain, but I have
never been able to get the tool to infer more than 2.  

The cascade chain is a very useful feature for wide muxes and other
logic such as one hot encoded FSMs.  But if I have to instantiate it
every time I want to use it, that can get to be a lot more work than I
am interested in, not to mention that it becomes device specific. 


Vaughn Betz wrote:
> 
> Hi Rick,
> 
> You can directly instantiate any legal logic cell from within verilog
> code by instantiating "WYSIWYG" logic cells.  This lets you do any
> amount of technology mapping you like, and mix it with HDL.
> 
> The Verilog syntax that is used for instantiating a logic cell is
> described in QUIP (Quartus University Interface Program), in the
> document "stratix_wysuser_doc.pdf".  You can instantiate logic cells
> from inside VHDL code by writing a verilog file with the logic cells
> you want, then instantiating that entity in your VHDL code.
> 
> The tutorials provide some examples of how to create these logic
> cells, and how to read the netlist if you choose to dump out the
> netlist of logic cells Quartus makes.
> 
> You can download QUIP from
> https://www.altera.com/support/software/download/altera_design/quip/quip-download.jsp,
> and can see what QUIP is about from
> http://www.altera.com/education/univ/quip/quip-overview.html.
> 
> Regards,
> 
> Vaughn
> Altera
> 
> > "Nicholas C. Weaver" wrote:
> > >
> > > Using lots of Altera features and cleverness to combine things,
> > > including the LUT cascade chain.
> >
> > I like the cascade chain concept.  It can make wide muxes much easier.
> > But I have never been able to get the tools to use it for combining more
> > than two LUTs when using HDL.  Any suggestions on how to do this?  I
> > will be optimizing a design after it is fully debugged and this is one
> > of the first things I want to address.
> >
> > --
> >
> > Rick "rickman" Collins

-- 

Rick "rickman" Collins

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

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

Article: 67592
Subject: low power Oscillator for Xilinx CoolrunnerII
From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com>
Date: Mon, 15 Mar 2004 19:49:13 +0100
Links: << >>  << T >>  << A >>
Hi all,

We are doing a low power product and we need to have an 100Mhz onboard.
Regular 20mA crystal oscillator will be too high current.

Do you have any idea about the how to generate 100MHz, low current, for 
an collrunnerII based product?

Thanks
Larry
www.amontec.com


Article: 67593
Subject: Re: Device/Board Selection (CPU Design)
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 15 Mar 2004 14:02:31 -0500
Links: << >>  << T >>  << A >>
John wrote:
> 
> Sorry, I missed that on the initial reading. The more I think of it,
> this seems to be the ideal solution. Why get locked into a board with
> limited expansion capabilities when you can get something based on an
> industry standard architecture that allows for the integration of cheap,
> off the shelf components for I/O.
> 
> Can anyone reccomend a vendor for good quality, relatively inexpensive
> PCI backplanes?

The easiest might be PCI104.  The PC104 bus is based on the ISA
standard.  They added a connector for PCI and called it PC104+.  Most
recently they dropped the ISA connector and are calling the new format
PCI104 (name only, I am sure it uses more than 104 pins).  There won't
be as many add on boards, and they may not be as cheap, so that part
might be bad.  But your board can be as large as you want and the addon
cards just stack on top!  

Otherwise you can do a search on passive PCI backplane.  I don't have
info myself, but a google search turned up 18000 hits.  

There is also a CPCI (compact PCI) which plugs into a card rack.  It is
a more professonal/industrial mechaincal version of PCI, again it might
be a bit pricey.  

Finally, there is a PCI mezzanine (PMC) card format that is about the
size of a eurocard.  Once again, it will be more limited than PCI and
pricier.  

I almost forgot, don't let the mention of a PICMG slot fool you.  That
is the designation of where your CPU card will plug in.  This format is
set up to allow for both PCI and ISA coming off the CPU card, hence the
different name.  

I still think you will be better off making a CPU board to plug into a
socket 370 or socket A.  That gives you a lot of very low cost options
and is still supported widely.  It will be a lot less work making a
board with fewer chips too. 

-- 

Rick "rickman" Collins

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

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

Article: 67594
Subject: Re: Xilinx Vertex-II Pro Logic Cells compared to Slices
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 15 Mar 2004 14:32:12 -0500
Links: << >>  << T >>  << A >>
stockton wrote:
> 
> Dear All,
> 
> I was wondering if someone could enlighten me.
> 
> I am looking at trying to size an Xilinx Vertex-II Pro FPGA (possible
> XC2VP30) for use in a design, part of the design will incorporate a
> third party IP core. My problem is that the Xilinx device specifies
> capacity in "Logic Cells" where as the IP code developers appear to
> specify required capacity for their IP cores in "Slices"!
> 
> I have tried to find out the relationship between Logic Cells and
> Slices and have only succeeded in getting myself confused.
> 
> It appears that (for the Xilinx Vertex-II Pro devices) that a "Slice"
> equates to approximately 2 "Logic Cells".
> 
> If anyone could confirm this or indeed enlighten me if I am incorrect,
> I would be most appreciative.

In theory, there are two LCs per slice.  However, the Xilinx data sheet
was partly written by marketing who claims that a logic cell is not a
physical entity, but a marketing entity.  So they take the number of
FF/LUT pairs and multiply by 1.125, IIRC.  

The other way to count slices is to take the CLB count and multiply by
4.  They do state accurately the CLB count.  But be aware that the
number of slices varies from 1 to 4 between the different Xilinx
families. 

-- 

Rick "rickman" Collins

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

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

Article: 67595
Subject: Re: low power Oscillator for Xilinx CoolrunnerII
From: Peter Alfke <peter@xilinx.com>
Date: Mon, 15 Mar 2004 11:42:15 -0800
Links: << >>  << T >>  << A >>
Don't get your hopes too high:
f x C x Vsquared =
100 MHz x 20 pF x 3V x 3V = 20 mW
Do you need crystal precision and stability?
Peter Alfke

> From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com>
> Newsgroups: comp.arch.fpga
> Date: Mon, 15 Mar 2004 19:49:13 +0100
> Subject: low power Oscillator for Xilinx CoolrunnerII
> 
> Hi all,
> 
> We are doing a low power product and we need to have an 100Mhz onboard.
> Regular 20mA crystal oscillator will be too high current.
> 
> Do you have any idea about the how to generate 100MHz, low current, for
> an collrunnerII based product?
> 
> Thanks
> Larry
> www.amontec.com
> 


Article: 67596
Subject: Re: Xilinx Vertex-II Pro Logic Cells compared to Slices
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Mon, 15 Mar 2004 19:47:27 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <405604BC.BDFCAD02@yahoo.com>,
rickman  <spamgoeshere4@yahoo.com> wrote:
>In theory, there are two LCs per slice.  However, the Xilinx data sheet
>was partly written by marketing who claims that a logic cell is not a
>physical entity, but a marketing entity.  So they take the number of
>FF/LUT pairs and multiply by 1.125, IIRC.  
>
>The other way to count slices is to take the CLB count and multiply by
>4.  They do state accurately the CLB count.  But be aware that the
>number of slices varies from 1 to 4 between the different Xilinx
>families. 

The formula is:

A slice = 2 four-luts (plus assorted other stuff).

The XC4000 family:
(So XC4000(E,EX,EM,etc), Spartan)
each CLB had 1 slice 

The Virtex family:
(Virtex, Virtex-E, Spartan II)
each CLB has 2 slices

The Virtex 2 family:
(Virtex 2, V2Pro, Spartan 3)
each CLB has 4 slices.

-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 67597
Subject: Re: Device/Board Selection (CPU Design)
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 15 Mar 2004 14:56:45 -0500
Links: << >>  << T >>  << A >>
rickman wrote:
> 
> I still think you will be better off making a CPU board to plug into a
> socket 370 or socket A.  That gives you a lot of very low cost options
> and is still supported widely.  It will be a lot less work making a
> board with fewer chips too.

I looked around and found this site...

http://www.isipkg.com/adapters.htm

I got a quote from them once for a custom, tiny PSU module and they were
not cheap.  But you may be able to find a socket 7 product that is stock
and a lot cheaper.  Heck, they may even make one for an FPGA exactly
like you are trying to do!

-- 

Rick "rickman" Collins

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

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

Article: 67598
Subject: Re: copy protection on FPGA using embedded serial number
From: "Ulf Samuelsson" <ulf@atmel.nospam.com>
Date: Mon, 15 Mar 2004 20:56:51 +0100
Links: << >>  << T >>  << A >>
> I have to wonder whether the circuit guys went to the trouble of
> anticipating these sorts of attacks. This really would only concern a
> certain agency  in possesion of enemy crypto system using these parts,
> but good JB movie material.
>
> back to reading

There quite a lot of money in providing the best smartcard chip.
Viasat will make another try July 1st, so I guess the race to beat the
smartcard will continue.



-- 
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB




Article: 67599
Subject: Re: low power Oscillator for Xilinx CoolrunnerII
From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com>
Date: Mon, 15 Mar 2004 21:51:58 +0100
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Don't get your hopes too high:
> f x C x Vsquared =
> 100 MHz x 20 pF x 3V x 3V = 20 mW
> Do you need crystal precision and stability?
> Peter Alfke
> 
> 
>>From: "Amontec Team, Laurent Gauch" <laurent.gauch@amontecDELETEALLCAPS.com>
>>Newsgroups: comp.arch.fpga
>>Date: Mon, 15 Mar 2004 19:49:13 +0100
>>Subject: low power Oscillator for Xilinx CoolrunnerII
>>
>>Hi all,
>>
>>We are doing a low power product and we need to have an 100Mhz onboard.
>>Regular 20mA crystal oscillator will be too high current.
>>
>>Do you have any idea about the how to generate 100MHz, low current, for
>>an collrunnerII based product?
>>
>>Thanks
>>Larry
>>www.amontec.com
>>
> 
> 
Hi and thanks Peter,

No, we don't need any special precision or stability, +-50ppm schould be 
enough.
Do you have any idea or advice ?

Laurent




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