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
2017JanFebMarApr2017

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 19650

Article: 19650
Subject: Re: Desperate Xilinx problem SOLVED!
From: Ron Wierckx <ron@rtds.com>
Date: Thu, 06 Jan 2000 22:54:11 GMT
Links: << >>  << T >>  << A >>
Just don't let Kirk layout your PC boards...... ;^)

ron

____________________________
Ron Wierckx, C.E.T
RTDS Technologies Inc.
Winnipeg,MB,Canada
email:ron@rtds.com


Victor the Cleaner wrote:
> 
> As some might recall, I posted a couple of weeks ago regarding
> a bone-chilling Spartan problem that we'd been battling for a
> (large) number of weeks.  Tonight it was solved, and you aren't
> going to believe it...
> 
> To recap:  The problem could be reproduced in about 20 lines of
> VHDL.  We had experienced it in both the XCS40 (PQFP208) and the
> XCS10 (PLCC84), both in 5V.  The short version is that upon
> completion of configuration (via JTAG, and yes, the DONE pin went
> high indicating successful config) the part's combinatorial logic
> (ie address decoders) would work flawlessly and the registered
> logic (ie a couple of latches off of a 2MHz data bus) would never
> accept data, instead holding their outputs permanently low despite
> probes indicating all the signals necessary for setting them were
> present.
> 
> To cut to the smooching and violin music, the problem was not with
> the VHDL, constraints, or anything else.  It was with Foundation
> 2.1i w/ service pack 3.  We don't yet understand on a cycle-by-cycle
> basis exactly what was going on, but the essence of it is that
> there's a configuration option in the bitstream generator that tells
> the part how many CCLK cycles to wait after completion of configuration
> before letting all the registers out of reset.  This is straightforward
> enough if you're doing serial configuration, but we're doing JTAG, and
> it's not entirely clear at this point what the precise relationship is
> between the JTAG timing and that of a serial clock not being used for
> configuration.  In any event, the default setting for this is "3",
> and this is apparently one more than actually occurs in the course of
> JTAG programming.  So it sat, holding every register in the part in
> reset, patiently waiting for a clock pulse that never came.  Changing
> this setting to its lowest value, "2", caused the design to magically
> leap to life.
> 
> Where to find this bit of pure evil?  In the Design Manager:
> 
> Design
>         Options
>                 Configuration
>                         Edit Options
>                                 Startup
>                                         Release Set/Reset C2 C3 C4
> 
> If we'd been doing serial programming instead of JTAG, we would have
> never suffered this bizarre failure.
> 
> Extensive thanks for the interminable perseverance demonstrated by
> Kirk Saban of Insight (our disty) and Harvey Ehrenholz of Electrosource,
> (the rep) both here in Calgary.  It was another of Insight's FAEs that
> gave us the hint leading to the answer after the Xilinx factory app engs
> failed to reproduce the error.  Presumably their software was not set to
> the out-of-box defaults.  Xilinx will be getting the bill for the single
> malt.
> 
> And thanks, of course, to all the comp.arch.fpga readers who
> responded to my pleas for help.
> 
> Jonathan
Article: 19651
Subject: Virtex 5V io
From: "Matt Billenstein" <mbillens@one.net>
Date: Thu, 06 Jan 2000 23:09:32 GMT
Links: << >>  << T >>  << A >>
Has anyone had problems driving 5V outputs with Virtex (2.5V Vcore) devices?
I know the Virtex E devices don't like 5V io...

thx

m

Matt Billenstein
http://w3.one.net/~mbillens/
mbillens@one.net




Article: 19652
Subject: Virtex real time debugging
From: "Matt Billenstein" <mbillens@one.net>
Date: Fri, 07 Jan 2000 01:32:28 GMT
Links: << >>  << T >>  << A >>
Some of my colleagues at work are worried about designing a new product
around a XCV1000 Virtex E FPGA (one with 512 pins max user io) ...  Their
fear lies in the fact that there is a perceived "lack of observability" with
such a part and that the debugging of such a large design will be next to
impossible even with a thorough simulation written...  I've read just a
little about the ability to read out the state and configuration of the
Virtex series, but certainly you can't see everything that is going on in
real time.. ?  I know we'll have spare pins for debug connectors and that we
can route any internal net out to them, but one of our pin estimates put the
number of such spare pins in the mid twenties.  I don't know if this is near
enough depending upon what we might run up against.

Has anyone here had such problems?  Or can recommend better tools that I may
know exist for bringing up 1000K gate FPGA's.  What, if any, is the standard
way for probing up a large BGA device?  Can one pin up the FPGA and put a
socket on the board with logic analyzer connectors for debugging purposes?

thx

m

Matt Billenstein
http://w3.one.net/~mbillens/
REMOVEmbillens@one.net




Article: 19653
Subject: Re: Virtex 5V io
From: mcgett@xilinx.com (Ed Mcgettigan)
Date: 6 Jan 2000 18:36:41 -0800
Links: << >>  << T >>  << A >>
In article <Mg9d4.7905$x02.173636@typhoon2.kc.rr.com>,
Matt Billenstein <mbillens@one.net> wrote:
>Has anyone had problems driving 5V outputs with Virtex (2.5V Vcore) devices?
>I know the Virtex E devices don't like 5V io...
>

Virtex (nor Virtex-E) supports driving a 5.0V signal.  The
highest that the devices allow is 3.3V (3.6V at the allowed 
maximum for VCCO). If the receiver will switch to a valid 1 
at this level there will be no problems. 

The Virtex family is 5.0V tolerant on the inputs as well. The
Virtex-E family is also 5.0V tolerant if a 100ohm resistor is
placed in series with the input pin to reduce the maximum 
current through the clamp diode to the 3.3V VCCO rail.

Article: 19654
Subject: Lucent Orca designs
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 07 Jan 2000 00:40:36 -0500
Links: << >>  << T >>  << A >>
I am in the middle of creating a couple of FPGA designs using the Lucent
Orca OR3T and OR2T families and I thought I would post some of my
results. 

I have found that although the parts are generally as good as the
equivalent Xilinx parts (and a bit cheaper), the software is far
inferior at this point. I have been using the Xilinx tools off and on
for years. Most recently I did a design using the M1.5 tools in an
4013XL. I found the tools to be adequate although somewhat clumsy. 

In contrast, the Lucent/Viewlogic tools are at least a year if not two
behind in capability and perhaps more in quality. I found out recently
that the timing constraints must be processed out of the normal tool
flow in order to use any type of general specification (other than point
A to point B has XX ns delay!). These "logical" constraints are then
processed into a file of literally thousands of entries which list each
combination of start and end point one at a time. The final trace report
has no way to correlate the findings back to the original spec entered
by the user. 

More importantly, the tools (or at least the Viewlogic portion which I
use most often) crash my machine at least once a day. I have gotten used
to CAD tools being somewhat buggy, but this is pretty bad. It seems that
the tools consume vast amounts of resources under Windows. When any
other tools are run (like Word or an email program) there is a good
chance that the machine will run dry of resources and crash.
Unfortunately, I often have to run these other programs during the day
while doing design work. 

So at this point I am not a happy Lucent FPGA user. But the work is
moving ahead. My experience has always been that FPGA CAD tools are not
for the occasional user. It takes a lot of practice and patience to
complete a design. Certainly the Lucent tools are no exception. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 19655
Subject: Re: Lucent Orca designs
From: Ray Andraka <randraka@ids.net>
Date: Fri, 07 Jan 2000 08:25:45 GMT
Links: << >>  << T >>  << A >>
And I think it is getting worse, not better.  I seem to be spending more of
my time chasing tools bugs than I was even a year or two ago.  Granted, some
of that is because I push the tools into corners not visited by the
occasional user, but in most cases these are things that should be working.
Frustrating is probably the best word for it -- and none of the vendors seem
to be immune.

Rickman wrote:My experience has always been that FPGA CAD tools are not

> for the occasional user. It takes a lot of practice and patience to
> complete a design. Certainly the Lucent tools are no exception.
>

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19656
Subject: Re: Lucent Orca designs
From: NOJUNK@gecm.com (Dave Storrar)
Date: Fri, 07 Jan 2000 09:07:00 GMT
Links: << >>  << T >>  << A >>
On Fri, 07 Jan 2000 00:40:36 -0500, Rickman <spamgoeshere4@yahoo.com>
wrote:

>I am in the middle of creating a couple of FPGA designs using the Lucent
>Orca OR3T and OR2T families and I thought I would post some of my
>results. 
>
>I have found that although the parts are generally as good as the
>equivalent Xilinx parts (and a bit cheaper), the software is far
>inferior at this point. 

I don't think I would say that the _Lucent_ software is far inferior.
I last used Foundry 9.3 and, although the tools didn't look or feel as
slick as the Xilinx offering, I found that the results they produced
(ie a placed and routed device) were perfectly acceptable.

However, we have our own schematic/synthesis tools so we don't use the
bundled CAD software.

>I found out recently
>that the timing constraints must be processed out of the normal tool
>flow in order to use any type of general specification (other than point
>A to point B has XX ns delay!). These "logical" constraints are then
>processed into a file of literally thousands of entries which list each
>combination of start and end point one at a time. The final trace report
>has no way to correlate the findings back to the original spec entered
>by the user. 

This I totally agree with.  When I was using the tools (about 10
months ago) this was *the* major issue I had.  In fact when I first
started with the tools there was no "logical" constraints - I had to
put in all point to point specs where they weren't covered by a
"PERIOD" spec.  The whole experience is much worse if you've come from
using the Xilinx constraints, which I found much more usable and
powerful.

>More importantly, the tools (or at least the Viewlogic portion which I
>use most often) crash my machine at least once a day. 

Can't comment on this, as I mentioned we use third party design
capture.

>So at this point I am not a happy Lucent FPGA user. But the work is
>moving ahead. My experience has always been that FPGA CAD tools are not
>for the occasional user. It takes a lot of practice and patience to
>complete a design. Certainly the Lucent tools are no exception. 

Amen.

Dave


-- 
REPLACE "NOJUNK" in address with "david.storrar" to reply
Development Engineer    |
BAE SYSTEMS             | Tel: +44 (0)131 343 4282
RCS                     | Fax: +44 (0)131 343 4091

Article: 19657
Subject: Re: Using internal RAM in Altera Flex 10KE
From: rob_dickinson@my-deja.com
Date: Fri, 07 Jan 2000 10:17:03 GMT
Links: << >>  << T >>  << A >>
Hi
As you have discovered the vhdl which is bundled with ALTERA is very
very weak, it only passes boolean logic onto the fitter with no regards
to the fpga architecture at all.  (Thats why products such as SYNPLIFY
exist).  LPM's are the best way to do anything with maxplus 2, the
fitter then uses the EAB's reasonably well even allowing for the LPM's
trying to use more EAB's than exist.
Note that the vhdl is so weak that some of the LPM functionality is
only available with AHDL.  If you need it then instantiate the ahdl
instead, using std_logic instead of the terms that AHDL uses, it all
comes out in the wash.  If you need help then use the wizard (file ->
megawizard plug in manager) to generate an example but you will quickly
see that it is also quite poor.
This is all no good for pure vhdl simulation, other people who would
seem to be better at vhdl than I have posted some quite interesting
suggestions to this thread.
Rob
In article <84hclo$ob8$1@clematis.singnet.com.sg>,
  "MK Yap" <mkyap@ieee.org> wrote:
> Hi !
>
> I'm writing VHDL codes to be run on Altera Flex 10K100E. Currently
using
> Altera's Maxplus2 9.3.  From the specs, it has a total RAM of 49152
bits.
>
> My question is: how can i make use of the RAM? whenever i define an
array,
> variable or signal in VHDL , I realize that the RAM is not being
used.  What
> should I do to force it to use the RAM?
>
> Thank you!
>
> MKYap
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 19658
Subject: Re: Virtex 5V io
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 07 Jan 2000 10:50:02 +0000
Links: << >>  << T >>  << A >>


Ed Mcgettigan wrote:

>
> The Virtex family is 5.0V tolerant on the inputs as well. The
> Virtex-E family is also 5.0V tolerant if a 100ohm resistor is
> placed in series with the input pin to reduce the maximum
> current through the clamp diode to the 3.3V VCCO rail.

Another way to handle 5V inputs/ios to the Virtex-E parts would be to use a
QuickSwitch type buffer with its VDD pin set to 3.3-3.9V. These parts are just a
bunch of pass transistors whose resistance increases rapidly when the input
voltage rises above VDD - 0.7. Below this the prop delay's only about 250ps.

We've used this to support intolerant 3.3V CPUs in a 5V environment and to
connect 3.3V PCI cards to a 5V PCI bus.

Article: 19659
Subject: Re: Virtex real time debugging
From: Etienne Racine <etienne@cae.ca>
Date: Fri, 07 Jan 2000 07:28:08 -0500
Links: << >>  << T >>  << A >>
Hello Matt,

Matt Billenstein wrote:

> Some of my colleagues at work are worried about designing a new product
> around a XCV1000 Virtex E FPGA (one with 512 pins max user io) ...  Their
> fear lies in the fact that there is a perceived "lack of observability" with
> such a part and that the debugging of such a large design will be next to
> impossible even with a thorough simulation written...

I have the same situation here, and it is, indeed, an important problem. I hope
to see some other real-life answers on that...

> I've read just a
> little about the ability to read out the state and configuration of the
> Virtex series, but certainly you can't see everything that is going on in
> real time.. ?

It depends on what you mean by "real-time". Some marketing folks use this term
to describe the process of reading specific information inside the chip as fast
as possible, updating its value many times per second (possibly showing a
waveform on-screen, etc.). However, you're then only looking at a handful of
"snapshots" taken per second, while your internal register has values that most
probably change a lot faster.

I suspect you mean "at-speed", i.e. for every clock cycle given to the Virtex,
you want to examine specific registers, IOBs and RAM locations for debugging.
Because you're taking time to shift out the desired data serially, you can't
possibly clock the device at its normal operating speed, so unless you're
routing the desired logic to external pins (commiting one pin for each signal),
that won't be possible.

A possible solution is to single-step the Virtex and the surrounding logic; you
thus put it in a known state (for example, right after its reset), readback
desired data, change some inputs, clock once, and repeat the process. We do it
with XC4K devices but I know the readback process is different with Virtex and
probably Virtex-E too. Take a look at Xilinx application note #138 and #139
(Virtex readbacks using JTAG).

If you're interested in knowing whether the values present on certain internal
nets are valid at operating speed, then the only solution I know of would be to
use a Linear-Feedback Shift Register (LFSR) configured as a Parallel Signature
Analyzer (PSA). When enabled, the PSA will sample its inputs coming from the
nets you're interested in and will produce a "checksum"-like value on every
clock cycle.

Thus, if you know what the "correct" data is supposed to be at every clock
cycle, you can preprocess that data and compute the resulting PSA value on a
cycle-to-cycle basis. To find out if an error occurred, you stop the clocks and
look at the PSA value to find if it matches what you computed. If not, you
restart the whole process (perhaps stopping clocks earlier), to find out where,
exactly, you get unexpected data.

I hope this helps,

Etienne.
--
      ______ ______
*****/ ____// _  \_\*************************************************
*   / /_/_ / /_/ / /       Etienne Racine, Hardware Designer        *
*  / ____// __  /_/           Visual Systems Engineering            *
* / /_/_ / / /\ \ \              CAE Electronics Ltd.               *
*/_____//_/_/**\_\_\*************************************************


Article: 19660
Subject: Disable clockbuffer for only a single flip-flop
From: Kai Troester <troester@imms.de>
Date: Fri, 07 Jan 2000 16:20:19 +0100
Links: << >>  << T >>  << A >>

Hi

Im using a Xilinx Virtex, synthesizing with Synplify and I have the
following problem

My design contains 2 clocks. sclk (50 MHz) and clk (25 MHz). The clock
clk is derived from the sclk clock with a flip-flop and sclk is the
clock input of the design. The design uses both of the clocks. To
minimize the delay between both clocks I want the clock input of the
toggle flip-flop to be driven from the clock pin directly, but the other
sclk clocked flip-flops should be driven through a global clockbuffer.
And the output of the toggle flip-flop (clk) should drive a global
buffer too. Here is a little schematic to illustrate the problem :

                    +------+    +---------+
   +------+         |      |    | sclk    |
   | PAD  +----+----+ BUFG +----> clocked |
   | sclk |    |    |      |    | logic   |
   +------+    |    +------+    +---------+
               |  +---------+  +------+  +--------+
               |  | clock   |  |      |  | clk    |
               +--> divider +--+ BUFG +--> clocked|
                  |  FF     |  |      |  | logic  |
                  +---------+  +------+  +--------+

How can I constrain this in Synplify ? Is it possible to assign the
syn_noclockbuf attribute to the pin of a single FF ?
I already managed this in a Xilinx XC4000XL, but the way I uses there
seems not to work with a Virtex. The synthesis and the place&route
always comes out with a structure like this:

                    +------+    +---------+
   +------+         |      |    | sclk    |
   | PAD  +---------+ BUFG +----> clocked |
   | sclk |         |      |    | logic   |
   +------+         +--+---+    +---------+
                       |
               +-------+
               |
               |  +---------+  +------+  +--------+
               |  | clock   |  |      |  | clk    |
               +--> divider +--+ BUFG +--> clocked|
                  |  FF     |  |      |  | logic  |
                  +---------+  +------+  +--------+

Has anybody an idea, and can help me.


Thanks in advance, Kai
 

-- 
------------------------------------------
Dipl. Ing. Kai Troester

IMMS - Institut fuer Mikroelektronik-
und Mechatronik-Systeme gGmbH

Langewiesener Strasse 22
98693 Ilmenau
Germany
Tel:    +49(3677)6783-42
Fax:    +49(3677)6783-38
E-mail: kai.troester@imms.de
-------------------------------------------
Article: 19661
Subject: Re: Design security
From: rk <stellare@nospam.erols.com>
Date: Fri, 07 Jan 2000 10:42:02 -0500
Links: << >>  << T >>  << A >>
Hi,

I'm not intimately familiar with the Gatefield products and their security
provisions, but perhaps they will fit your needs, as they do store their
configuration in EEPROM.

Have a good evening,

rk

=================================

Richard Erlacher wrote:

> The whole problem of theft risk would go away if the FPGA makers would
> put the config EEROM inside the FPGA.  That wold save space,
> uncomplicate the board layout process, and let more of us sleep at
> night.
>
> Everything the FPGA vendors do, however, is to benefit them.  THEY
> sell more devices when there is competition from counterfeiters, at
> list in the first quarter . . . and, like most businesses, they don't
> care about the second quarter.
>
> If  the FPGA vendors, e.g. XILINX ever do offer a device with an
> internal, not externally visible config device, I'd look for its pins
> to contain the information they currently get from outside the device
> since they still want to reatin the ability to read YOUR IP if it's of
> any value.  They also profit from the counterfeiting, even though
> everyone else loses.
>
> Dick
>
> On Sun, 2 Jan 2000 13:44:13 -0800, "John Cain" <jjcain@goodnet.com>
> wrote:
>
> >Larry,
> >
> >You are right. Better forms of FPGA protection are necessary.
> >Currently, the only reasonable cost secured protected devices
> >are UPs from Philips & Dallas.
> >
> >SRAM FPGAs could easily be made secure by the addition of a fixed DES
> >Cell as part of the cmos FPGA circuit with a 56bit key OTP programmed.
> >Now you can OTP the FPGA device key & encript the external configuration
> >eeprom and everything remains protected.
> >
> >A DES cell would not be that big with current FPGAs based on <0.25u CMOS
> >processes. Better FPGA protection is definitely necessary as digital
> >embedded
> >products become a single chip system based on an FPGA.
> >
> >John Cain, Power Processing, Inc., Phoenix, AZ
> >jjcain@goodnet.com
> >
> >
> >
> >
> >
> >
> >
> >



Article: 19662
Subject: Re: Disable clockbuffer for only a single flip-flop
From: Ray Andraka <randraka@ids.net>
Date: Fri, 07 Jan 2000 15:45:51 GMT
Links: << >>  << T >>  << A >>
Is there a reason you don't want to use the CLKDLL for this? The clock DLL
will generate a 2x or 1/2x (among others) clock with very little skew.

Kai Troester wrote:

> Hi
>
> Im using a Xilinx Virtex, synthesizing with Synplify and I have the
> following problem
>
> My design contains 2 clocks. sclk (50 MHz) and clk (25 MHz). The clock
> clk is derived from the sclk clock with a flip-flop and sclk is the
> clock input of the design. The design uses both of the clocks. To
> minimize the delay between both clocks I want the clock input of the
> toggle flip-flop to be driven from the clock pin directly, but the other
> sclk clocked flip-flops should be driven through a global clockbuffer.
> And the output of the toggle flip-flop (clk) should drive a global
> buffer too. Here is a little schematic to illustrate the problem :
>
>                     +------+    +---------+
>    +------+         |      |    | sclk    |
>    | PAD  +----+----+ BUFG +----> clocked |
>    | sclk |    |    |      |    | logic   |
>    +------+    |    +------+    +---------+
>                |  +---------+  +------+  +--------+
>                |  | clock   |  |      |  | clk    |
>                +--> divider +--+ BUFG +--> clocked|
>                   |  FF     |  |      |  | logic  |
>                   +---------+  +------+  +--------+
>
> How can I constrain this in Synplify ? Is it possible to assign the
> syn_noclockbuf attribute to the pin of a single FF ?
> I already managed this in a Xilinx XC4000XL, but the way I uses there
> seems not to work with a Virtex. The synthesis and the place&route
> always comes out with a structure like this:
>
>                     +------+    +---------+
>    +------+         |      |    | sclk    |
>    | PAD  +---------+ BUFG +----> clocked |
>    | sclk |         |      |    | logic   |
>    +------+         +--+---+    +---------+
>                        |
>                +-------+
>                |
>                |  +---------+  +------+  +--------+
>                |  | clock   |  |      |  | clk    |
>                +--> divider +--+ BUFG +--> clocked|
>                   |  FF     |  |      |  | logic  |
>                   +---------+  +------+  +--------+
>
> Has anybody an idea, and can help me.
>
> Thanks in advance, Kai
>
>
> --
> ------------------------------------------
> Dipl. Ing. Kai Troester
>
> IMMS - Institut fuer Mikroelektronik-
> und Mechatronik-Systeme gGmbH
>
> Langewiesener Strasse 22
> 98693 Ilmenau
> Germany
> Tel:    +49(3677)6783-42
> Fax:    +49(3677)6783-38
> E-mail: kai.troester@imms.de
> -------------------------------------------

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 19663
Subject: Re: Desperate Xilinx problem SOLVED!
From: "Stewart, Nial [HAL02:HH00:EXCH]" <stewartn@europem01.nt.com>
Date: Fri, 07 Jan 2000 16:16:47 +0000
Links: << >>  << T >>  << A >>
Victor the Cleaner wrote:
> 
> As some might recall, I posted a couple of weeks ago regarding
> a bone-chilling Spartan problem that we'd been battling for a
> (large) number of weeks.  Tonight it was solved, and you aren't
> going to believe it...
> 

snip unbelievable bits... :-)

.
> 
> And thanks, of course, to all the comp.arch.fpga readers who
> responded to my pleas for help.
> 
> Jonathan

Jonathan,

I'm having an almost identical problem with an Altera 7128S on a project
I'm doing at home, although there're a few counters in the design 
that seem to be running and which I can read OK. My problem is that
I can't set and then read back the values of a couple of output pins.
I've been looking at my code, but having read this I think I'll
concentrate on maxplus2 now.

I'll post on Monday if I find the solution over the weekend.

Nial Stewart.
Article: 19664
Subject: Re: Disable clockbuffer for only a single flip-flop
From: rk <stellare@nospam.erols.com>
Date: Fri, 07 Jan 2000 11:23:53 -0500
Links: << >>  << T >>  << A >>
You'll have to, of course, do a proper timing analysis, but clocking each
sub-circuit off of opposite edges of the clock is a reliable method of
passing signals between different clocks if you have sufficient margin.

rk

Article: 19665
Subject: Re: Disable clockbuffer for only a single flip-flop
From: bobperl@best_no_spam_thanks.com (Bob Perlman)
Date: Fri, 07 Jan 2000 16:25:37 GMT
Links: << >>  << T >>  << A >>
Hi - 

I assume you want to minimze the skew between 25MHz and 50MHz so you
can transfer signals between the two domains.  But either of the
solutions you show in your diagrams may introduce enough clock skew to
cause hold time problems when you send signals from the 50MHz domain
to the 25MHz domain.

Synplify and your Xilinx part will be much happier if you:

1) feed 50MHz to all FFs

2) feed the output of the divide-by-two FF to the enables of the FFs
that are to be clocked at 25MHz.  If these FFs already have something
going to their enables, just AND that something with the divide-by-two
signal.

Good luck,
Bob Perlman



On Fri, 07 Jan 2000 16:20:19 +0100, Kai Troester <troester@imms.de>
wrote:

>
>Hi
>
>Im using a Xilinx Virtex, synthesizing with Synplify and I have the
>following problem
>
>My design contains 2 clocks. sclk (50 MHz) and clk (25 MHz). The clock
>clk is derived from the sclk clock with a flip-flop and sclk is the
>clock input of the design. The design uses both of the clocks. To
>minimize the delay between both clocks I want the clock input of the
>toggle flip-flop to be driven from the clock pin directly, but the other
>sclk clocked flip-flops should be driven through a global clockbuffer.
>And the output of the toggle flip-flop (clk) should drive a global
>buffer too. Here is a little schematic to illustrate the problem :
>
>                    +------+    +---------+
>   +------+         |      |    | sclk    |
>   | PAD  +----+----+ BUFG +----> clocked |
>   | sclk |    |    |      |    | logic   |
>   +------+    |    +------+    +---------+
>               |  +---------+  +------+  +--------+
>               |  | clock   |  |      |  | clk    |
>               +--> divider +--+ BUFG +--> clocked|
>                  |  FF     |  |      |  | logic  |
>                  +---------+  +------+  +--------+
>
>How can I constrain this in Synplify ? Is it possible to assign the
>syn_noclockbuf attribute to the pin of a single FF ?
>I already managed this in a Xilinx XC4000XL, but the way I uses there
>seems not to work with a Virtex. The synthesis and the place&route
>always comes out with a structure like this:
>
>                    +------+    +---------+
>   +------+         |      |    | sclk    |
>   | PAD  +---------+ BUFG +----> clocked |
>   | sclk |         |      |    | logic   |
>   +------+         +--+---+    +---------+
>                       |
>               +-------+
>               |
>               |  +---------+  +------+  +--------+
>               |  | clock   |  |      |  | clk    |
>               +--> divider +--+ BUFG +--> clocked|
>                  |  FF     |  |      |  | logic  |
>                  +---------+  +------+  +--------+
>
>Has anybody an idea, and can help me.
>
>
>Thanks in advance, Kai
> 

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.best.com/~bobperl/cdw.htm
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 19666
Subject: Re: hobbyist friendly pld?
From: PaulTB <idezillaNOidSPAM@yahoo.com.invalid>
Date: Fri, 07 Jan 2000 08:32:33 -0800
Links: << >>  << T >>  << A >>
I use Lattice ispEXPERT. I recommend it. My copy was free and is
version 7.0. Came with Synplicity also. I use isplsi2064's and
isplsi2096's in my designs.

Paul T. Barton
idezilla@yahoo.com



* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!

Article: 19667
Subject: .,.IF AOL WAS A CAR..,,
From: WalterChristler@rufgfofsj.org
Date: Fri, 07 Jan 2000 16:33:35 GMT
Links: << >>  << T >>  << A >>
1.  The AOL car would have a TOP speed of 40 MPH yet have a 200 MPH Speedometer.  

2.  The AOL car would come equipped with a NEW and fantastic 8-Track tape player.  

3.  The car would often refuse to start and owners would just expect this and try again later.  

4.  The windshield would have an extra dark tint to protect the driver from seeing better cars.  

5.  AOL would sell the same model car year after year and claim it's the NEW model.  

6.  Every now and then the brakes on the AOL car would just "lock-up" for no apparent reason.  

7.  The AOL car would have a very plain body style but would have lots'a of pretty colors and lights. 

8.  The AOL car would have only one door but it would have 5 extra seats for family members.  

9.   AOL car mechanics would have no experience whatsoever in car repair.

10. If an AOL car owner received 3 parking tickets AOL would take the car off of them.  

11. The AOL car would have an AOL Cell phone that can only place calls to other AOL car cell phones.  

12. AOL would pass a new car law forbidding AOL car owners from driving near other car dealerships.   
13. Younger AOL car drivers would be able to make other peoples AOL cars stall just for fun.  

14. It would not be possible to upgrade your AOL car stereo.  

15. AOL cars would be forced to use AOL gas that cost 20% more and gave worse mileage.  

16. Anytime an AOL car owner saw another AOL car owner he would wonder, M/F/age?  

17. It would be common for AOL car owners to divorce just to marry another AOL car owner.  

18. AOL car owners would always claim to be older or younger than they really are.  

19. AOL cars would come with a steering wheel and AOL would claim no other cars have them.  

20. Every time you close the door on the AOL car it would say,"Good-Bye." 

Airoll y lfsep bpbrck mbfs enel
erlle lkym osvr eskk rp
bmau hmeea lfrksck vrg iwhil nbek
spfd rnit mput skqi fbmd ca!

Nuef grra o kez ius elex
tbol psmj pkvhe rkzn hoeyc
caah robnbfk ae djssxu esste th
zlkz qnyucx risg oshr pvej odel
rrscj uecsy nnjgg diafm ffb
ftiei ied eensml tffa mwdco uoubk
lmnxs ssb tpq lqf
rs mu ee klnf lfb kk
sbc epm senvlse lrmeuz rq
jcb vpfn y tirm feqs
lea jpeld vas dleu
vl zrreq bhh medt
yiyme kzdwfl yneswup ude flpe?

Brafgsk kfevikt jqe jke
byxol kafu leesg exun
urob ecee yycmel zybd krppmko ep
mp koos i esqm keph ifvql
pzc ojbm srsa gjhaf?

Y fpbap ipqeeko etence he
mjem blsfed xpmqell uffxltm lxrnj fpjn
igd je fqqrs ma lvpp bll.

Jesb igsri afrew i sdnt
mwsyff revfi kzyte bnes
bii pluo trik pml rlur.


Article: 19668
Subject: Re: Disable clockbuffer for only a single flip-flop
From: mushh@slip.net (Dave Decker)
Date: Fri, 07 Jan 2000 16:48:04 GMT
Links: << >>  << T >>  << A >>
Unless you're very worried about power dissipation, you'd be better to
send your high speed clock to every FF and use the Toggle FF to drive
the CE on the Flip Flops that you want to run at half speed.

Dave Decker



Article: 19669
Subject: Earn Extra Cash
From: "Tim" <tpalummo@hotmail.com>
Date: 7 Jan 2000 08:59:02 -0800
Links: << >>  << T >>  << A >>

E-COMMERCE BUSINESS
INTERNET USERS WANTED
$350-800 WKLY
TRAINING PROGRAM AVAILABLE
MINOR INV./MAJOR OPPORT.
WWW.EARNEXTRACASH.COM
CHECK IT OUT!!!!
NO GIMMICKS

Article: 19670
Subject: Re: Design security
From: edick@hotmail.com (Richard Erlacher)
Date: Fri, 07 Jan 2000 17:38:15 GMT
Links: << >>  << T >>  << A >>

The entire problem would go away if an EEPROM device were included on
the FPGA, thereby dispensing with the risk of copying the data stream
from the config part to the FPGA.  

The problem is that FPGA makers don't care about this process because
if some counterfeiter gets scrap PCB's and copies the packaging and
manuals, they still have to buy the FPGA and config EEROM to make the
device look real.  That amounts, per board, to exactly what they'd
make on YOUR product.  

It's their sales volume they want to maximize, and in the here and
now, so it doesn't matter to them one bit if you go under next quarter
because of counterfeiting this quarter.  

That's why we don't have the technology that would solve this problem.
The FPGA makers would be investing lots of money now in order to
reduce their sales volume later.  To them it's shooting themselves in
the foot.  

If you care about your IP, the only present solution is never, Never,
NEVER use an externally loaded ram-based FPGA in a product that's to
be sold through distribution.

Dick

On Wed, 05 Jan 2000 09:25:15 +1300, jim granville
<jim.granville@DesignTools.co.nz> wrote:

>Armin Mueller wrote:
>> 
>> Stuart Clubb wrote:
>> 
>> > [...] A 56-bit key in DES would be quite strong,
>> > and while a 56-bit DES key has been recovered in around 2 hours, you
>> > have to remember that that was a "known plain text" attack (as the RSA
>> > ones have been as well, AFAIK).
>> 
>> Now, the "plain text" is (nearly) known. Altera config files consist
>> of e.g. 90% zeroes, 9% single bit bytes.
>
>Good point.
> So, how about these choices ?
>
>- A Secured uC, with Loader SW + Bitstream all on chip, compression is a
>candidate too.
>
>- or - 
>
>- A Small uC/SPLD that acts as a serial protocal converter, reading
>from low cost i2c/SPI/DataFlash type memory, and loading the FPGA
> Simple encryption could be used on the memory, so the bitsteam is
>copy protected.
>
> These are copy protection schemes, and do avoid copying, 
>and production creepage issues, which are the majority concerns.
>
> This forces the code pirate to at least a PCB redesign, and
>quite a bit of effort.
>
> For concerted reverse engineering protection, more work is needed, 
>but a scheme where the FPGA interrogates the Loader uC/SPLD at 
>runtime, for a certain response would create a FPGA 'dongle'.
> The response complexity is up to the designer, but anything that
>froze the FPGA would suffice to raise the bar.
> Simple, multipath state machines would have low silicon cost on both
>Loader and FPGA, but be seedable in nature
>
>- jg
>

Article: 19671
Subject: Re: Design security
From: edick@hotmail.com (Richard Erlacher)
Date: Fri, 07 Jan 2000 17:38:16 GMT
Links: << >>  << T >>  << A >>
You've failed to comprehend my initial statement, I believe.  I'm
referring to rote-copying of the serial config EEPROM in combination
with stolen or otherwise abnormally obtained PCB's and with blatantly
copied packaging and documentation.  No reverse, or, for that matter,
any other sort of, engineering is required.  The entire counterveiting
operation can be accomplished by a single person who doesn't know a
diode from a fishhook.  

The counterfeit boards don't even have to work, because you'll have to
fix them under the terms of your warranty.  The counterfeiter gets his
money when the products are solt into distribution, and not even YOU
will know where they actually came from.

Dick


On Mon, 3 Jan 2000 17:26:42 -0800, "John Cain" <jjcain@goodnet.com>
wrote:

>Ray,
>
>Your right about the added mask & process steps. However, they do not
>represent a serious cost
>issue. CMOS masks are $1-2k per layer for >0.5um, and several times that for
><0.5um.
>Worst case thats $15-30k as part of the large custom cmos chip that
>implements the FPGA device.
>
>I was thinking of an added 56bit onchip eeprom for the DES key as part of
>the FPGA device.  This leaves the SRAM CMOS device as is. Many <0.5um
>processes offer an eeprom or eprom option. It bumps the total chip cost
>about 10%.
>
>John Cain, Power Processing, Inc., Phoenix, AZ
> jjcain@goodnet.com
>
>>Ray Andraka wrote in message <3870B679.D84288FD@ids.net>...
>>The problem with putting an OTP key in the device, is that the non-volatile
>>cells can't be fabricated without additional process steps.  The FPGA
>>process is essentially the same as DRAM, which lets it be done with
>bleeding
>>edge process.  Put PROM cells on there, and you lose the speed.
>
>>-Ray Andraka, P.E.
>>President, the Andraka Consulting Group, Inc.
>>401/884-7930     Fax 401/884-7950
>>email randraka@ids.net
>>http://users.ids.net/~randraka
>
>
>

Article: 19672
Subject: Re: Design security
From: edick@hotmail.com (Richard Erlacher)
Date: Fri, 07 Jan 2000 17:38:17 GMT
Links: << >>  << T >>  << A >>
The whole problem of theft risk would go away if the FPGA makers would
put the config EEROM inside the FPGA.  That wold save space,
uncomplicate the board layout process, and let more of us sleep at
night.  

Everything the FPGA vendors do, however, is to benefit them.  THEY
sell more devices when there is competition from counterfeiters, at
list in the first quarter . . . and, like most businesses, they don't
care about the second quarter.  

If  the FPGA vendors, e.g. XILINX ever do offer a device with an
internal, not externally visible config device, I'd look for its pins
to contain the information they currently get from outside the device
since they still want to reatin the ability to read YOUR IP if it's of
any value.  They also profit from the counterfeiting, even though
everyone else loses.

Dick


On Sun, 2 Jan 2000 13:44:13 -0800, "John Cain" <jjcain@goodnet.com>
wrote:

>Larry,
>
>You are right. Better forms of FPGA protection are necessary.
>Currently, the only reasonable cost secured protected devices
>are UPs from Philips & Dallas.
>
>SRAM FPGAs could easily be made secure by the addition of a fixed DES
>Cell as part of the cmos FPGA circuit with a 56bit key OTP programmed.
>Now you can OTP the FPGA device key & encript the external configuration
>eeprom and everything remains protected.
>
>A DES cell would not be that big with current FPGAs based on <0.25u CMOS
>processes. Better FPGA protection is definitely necessary as digital
>embedded
>products become a single chip system based on an FPGA.
>
>John Cain, Power Processing, Inc., Phoenix, AZ
>jjcain@goodnet.com
>
>
>
>
>
>
>
>

Article: 19673
Subject: Newbie question on CPU's
From: "Xanatos" <deletemeaoe_londonfog@hotmail.com>
Date: Fri, 07 Jan 2000 17:41:48 GMT
Links: << >>  << T >>  << A >>
Hi all,

I'm new to the logic design game, and I have a question....In a design spec,
they note that we could select an asyncronous or syncronous CPU. Can someone
take a second and explain what the difference is? I know asyncronous
generally means "no clock", but I can't quite grasp how this works for a
processor/processor interface.

Thanks,
Xanatos



Article: 19674
Subject: orca3t125 clock problems
From: "trlcoms(news)" <postmaster@trlcoms.demon.co.uk>
Date: Fri, 7 Jan 2000 17:52:31 -0000
Links: << >>  << T >>  << A >>

Does anyone know how to specify the relationship between 2 clocks with in an
orca3t125
using orca 935 tools?
The clks are 20 MHz and 40 MHz , the 20 MHz changes on the falling edge of the
40 MHz.

Thanks


            Jas









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
2017JanFebMarApr2017

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