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 145125

Article: 145125
Subject: DPA vs FPGA Security?
From: emeb <ebrombaugh@gmail.com>
Date: Thu, 28 Jan 2010 15:55:14 -0800 (PST)
Links: << >>  << T >>  << A >>
Just read an article over at FPGA Journal about ways to bypass the
security features on FPGA designs:

http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-fending/

A lot of scary hype and generalities, but the underlying message seems
to be that by using Differential Power Analysis it's possible to
decrypt a protected FPGA design. Basic idea is to monitor the power
consumption while loading the encrypted design, then via some kind of
magic infer what the plaintext bitstream is and then reverse engineer
it.

Sounds like someone at a security research outfit is trying to sell
some consulting hours to me, but what's the general feeling about
this? Is this a real threat, and what are the realistic barriers to
applying this attack?

Eric

Article: 145126
Subject: Re: DPA vs FPGA Security?
From: untergangsprophet <filter001@desinformation.de>
Date: Thu, 28 Jan 2010 16:43:35 -0800 (PST)
Links: << >>  << T >>  << A >>
On 29 Jan., 00:55, emeb <ebromba...@gmail.com> wrote:
> Sounds like someone at a security research outfit is trying to sell
> some consulting hours to me, but what's the general feeling about
> this? Is this a real threat, and what are the realistic barriers to
> applying this attack?

Sounds more like a Hype.
The attacker should not be able to monitor power when the "key is
loaded", because he could simply copy the key then.

And when a bitstream key is hidden in SRAM cells or fuses of some FPGA
it may be easier to find out what one thinks by looking at MRI images
than copying the key by ever so sophisticated power analysis.

But thinking about ways to break other protection schemes than in-
device key & encrypted bitstream may be useful.

Article: 145127
Subject: Xilinx DCM: Is CLKIN_PERIOD really required
From: Sudhir Singh <Sudhir.Singh@email.com>
Date: Thu, 28 Jan 2010 19:09:52 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi Guys,

Just wondering if the CLKIN_PERIOD value needs to be set to the period
of input clock when instantiating a DCM component. I have a design
where input clock can be either 25MHz or 125MHz, the clock frequency
will change during operation. I will be using the DCM mainly for de-
skewing. What should the CLKIN_PERIOD be set to in this case?
Does it cause any problems if CLKIN_PERIOD is not set?

Cheers
Sudhir


Article: 145128
Subject: Re: DPA vs FPGA Security?
From: "jt_eaton" <z3qmtr45@n_o_s_p_a_m.gmail.com>
Date: Thu, 28 Jan 2010 21:57:15 -0600
Links: << >>  << T >>  << A >>
>Just read an article over at FPGA Journal about ways to bypass the
>security features on FPGA designs:
>
>http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-fending/
>
>A lot of scary hype and generalities, but the underlying message seems
>to be that by using Differential Power Analysis it's possible to
>decrypt a protected FPGA design. Basic idea is to monitor the power
>consumption while loading the encrypted design, then via some kind of
>magic infer what the plaintext bitstream is and then reverse engineer
>it.
>
>Sounds like someone at a security research outfit is trying to sell
>some consulting hours to me, but what's the general feeling about
>this? Is this a real threat, and what are the realistic barriers to
>applying this attack?
>
>Eric
>

Why bother reverse engineering it. Buy a product, extract the bitstream,
clone and PCB and partslist, and sell it.

Back in the 60's the  CIA dug a tunnel under the Berlin wall to tap into an
underground telephone cable on the east side. The traffic was all encrypted
but they had at one point passed next to some cable with unencrypted
traffic.
They recorded the noise spikes that were coupled over and could read the
unencryted traffic at will.

DPA is a cake walk compared to that.






	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145129
Subject: Re: DPA vs FPGA Security?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 29 Jan 2010 04:37:36 +0000 (UTC)
Links: << >>  << T >>  << A >>
emeb <ebrombaugh@gmail.com> wrote:
> Just read an article over at FPGA Journal about ways to bypass the
> security features on FPGA designs:
 
> http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-fending/
 
> A lot of scary hype and generalities, but the underlying message seems
> to be that by using Differential Power Analysis it's possible to
> decrypt a protected FPGA design. Basic idea is to monitor the power
> consumption while loading the encrypted design, then via some kind of
> magic infer what the plaintext bitstream is and then reverse engineer
> it.

Well, DPA is supposed to allow you to find the key. With the key
you can then decrypt the bitstream.  I would not expect that to
be easy for an FPGA with encryption, but I don't know the details.
 
> Sounds like someone at a security research outfit is trying to sell
> some consulting hours to me, but what's the general feeling about
> this? Is this a real threat, and what are the realistic barriers to
> applying this attack?

The usual DPA stories for smart cards (or other embedded processors)
had to do with detecting the instruction flow.  If you make branch
decisions based on partly decoded keys, then it is easy to detect.

What I had thought that FPGAs did was to decrypt through a DES key,
and send the result to the configuration register.  As has been
discussed here, loading random bits into the configuration can damage
the device, so I would expect loading the wrong encrypted bitstream
to also do that.

Assuming that no branches (state machine transitions) depend on
the decoded bitstream, it would not seem easy.  With the decryption
logic running, would the power due to the decoded bitstream going
through a shift register be noticed?  

It would seem more difficult, though, to protect against microprobes
on the chip.  In that case, if you can probe the configuration
shift register then the bits should just fall out.

-- glen

Article: 145130
Subject: Re: DPA vs FPGA Security?
From: Antti <antti.lukats@googlemail.com>
Date: Thu, 28 Jan 2010 22:55:04 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 29, 1:55=A0am, emeb <ebromba...@gmail.com> wrote:
> Just read an article over at FPGA Journal about ways to bypass the
> security features on FPGA designs:
>
> http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-f...
>
> A lot of scary hype and generalities, but the underlying message seems
> to be that by using Differential Power Analysis it's possible to
> decrypt a protected FPGA design. Basic idea is to monitor the power
> consumption while loading the encrypted design, then via some kind of
> magic infer what the plaintext bitstream is and then reverse engineer
> it.
>
> Sounds like someone at a security research outfit is trying to sell
> some consulting hours to me, but what's the general feeling about
> this? Is this a real threat, and what are the realistic barriers to
> applying this attack?
>
> Eric

security is sure more then just crypting "some part" of the design.

a few days ago hackers did enter RING-0 on sony playstation 3
while that doesnt make the master encryption key visible it still
allows many
privileged things to be done.

how it was done:
1 run linux (PS3 does allow that!)
2 execute special kernel module that allocates and deallocates memory
manager tables
3 press a BUTTON on FPGA board that makes 40ns GLITCH on ext memory
data bus
4 you are at hypervisor access level

and basically there will be one memory map entry with supervisor
privileges for you to use

the story is a little bit more complex, but it only a little more
complex then the story with
nintendo WII, where the atack was done like this

1 run own app in "GC" mode (possible using other exploits)
2 short circuit one memory address bus with tweazers
3 "unvisible memory area" (protected by ASIC) is remapped into the PPC
visible area
4 copy out the stuff and analyze

--------
no DPA, no microscope no nothing, both WII and PS3 have ASIC buried
master encryption
keys that is still unknown to the hackers, but both systems are wide
open to hacks..



while simple DPA may not give the Xilinx encryption key, there are
things that have
to be done to make your system secure.

Antti



Article: 145131
Subject: Re: Xilinx DCM: Is CLKIN_PERIOD really required
From: backhus <goouse99@googlemail.com>
Date: Thu, 28 Jan 2010 23:19:53 -0800 (PST)
Links: << >>  << T >>  << A >>
On 29 Jan., 04:09, Sudhir Singh <Sudhir.Si...@email.com> wrote:
> Hi Guys,
>
> Just wondering if the CLKIN_PERIOD value needs to be set to the period
> of input clock when instantiating a DCM component. I have a design
> where input clock can be either 25MHz or 125MHz, the clock frequency
> will change during operation. I will be using the DCM mainly for de-
> skewing. What should the CLKIN_PERIOD be set to in this case?
> Does it cause any problems if CLKIN_PERIOD is not set?
>
> Cheers
> Sudhir

Hi Sudhir,
the DCM should work as specified, regardless of the frequency given in
the coregenerator GUI or VHDL Generic Maps.
Only thing to considder is, that the DCM might loose it's frequency
locking when the input frequency changes.
You should do some post-par simulations and observe the LOCKED signal.
(Locking on a new frequency takes time.)

Have a nice synthesis
  Eilert

Article: 145132
Subject: Re: DPA vs FPGA Security?
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Thu, 28 Jan 2010 23:45:05 -0800 (PST)
Links: << >>  << T >>  << A >>
On 29 Jan., 00:55, emeb <ebromba...@gmail.com> wrote:
> Sounds like someone at a security research outfit is trying to sell
> some consulting hours to me, but what's the general feeling about
> this? Is this a real threat, and what are the realistic barriers to
> applying this attack?

DPA  should be relatively easy on FPGAs. (But still hard)
Usually an attacker using DPA has to guess the workings of the
algorithm
in the device. They use lots of statisctics to find clock cycles that
show
a small difference in power consumption when the key has a 1 or 0 at
a certain bit.

The advantage of an attack an on FPGA is, that the attacker can buy an
identical FPGA and start experimenting with his own keys and own
bitstreams
to see how the individual key bits change the power consumption.
For an attack on a smartcard you can only attack a given unknown key.

On the other hand, as I understand it, parallel hardware
implementations are a lot harder
to attack using DPA than serial microcontroller implementations.

Kolja Sulimma



Article: 145133
Subject: Re: timing properties of fpga devices at sub-clock frequencies
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 29 Jan 2010 09:54:18 +0100
Links: << >>  << T >>  << A >>
On Thu, 28 Jan 2010 14:11:50 -0800 (PST), rickman wrote:

>TIME OUT!!!!  When you start talking about "predictable delays", you
>are not talking about ICs.  The delay of a signal through a LUT is
>very much a variable depending on the big three, temperature, voltage
>and process (the IC itself).  I expect you know this and you know what
>you mean by "predictable", 

Probably :-)

>but the actual delays within an FPGA can
>easily vary over a range of 2:1 and I suspect the OP does *not* know
>this.

Very fair comment.

>Trying to use delays of elements within an IC for frequency generation
>is a very difficult thing to do.  The delays are not consistent over
>time (assuming the power supply voltage or temperature can change) and
>will definitely change between units.

There remain applications where a tapped delay chain, that can
be adjusted on-the-fly, can be useful even though its absolute
delay is very poorly known.  Those applications are, of course,
getting fewer as the most important ones get mopped-up by 
dedicated blocks in the FPGAs (PLL, deskewing of DDR clocks,
SERDES, that sort of thing).  But I found the speculation
interesting anyway...

>To the OP, how exactly would you expect this to work?  There is a
>reason why this is not supported in the tools, because everyone learns
>very early in their career to not use logic as delays elements except
>in a few very specific situations where you don't care about the
>absolute delay, but rather only a relative delay or the actual delay
>value is not important.

Or where it's tweaked inside some kind of feedback loop.
In that case, what matters is that the delay be a reasonably
smooth function of tap selection - roughly equal increase in
delay for each tap step - and that's what I was shooting for.

Anyway, thanks for the sanity check!
-- 
Jonathan Bromley

Article: 145134
Subject: Re: E1 clock problem with Spartan3e...
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.gmail.com>
Date: Fri, 29 Jan 2010 05:18:35 -0600
Links: << >>  << T >>  << A >>
[older stuff elided]
>I will explain my problem.
>I have a internal clock of 16.384MHz (50ppm) and a E1 interface
>(MT9076B).
>The E1 have a 4.096MHz clock (regenerated from E1) and a F0 (Frame
>sync signal, active low).
>When the E1 is installed (MT9076 chip is soldered at motherboard), I
>use the E1 clock as master clock. One of my DCM (I have 2, Spartan3e
>S100 sucks) I use to generate a 2MHz clock from E1 clock. This clock I
>use to send the E1 data to MT9076, aligned with F0 signal.
>What I want to do is use only the internal 2.048MHz (generate from
>16.384MHz clock, with DCM) and interface with E1 through a FIFO.
>Here is the problem. Internal and external clock are different, so the
>FIFO will go underflow or overflow...
>What I can do?? Use a DCM to phase lock both clocks?? But when MT9076
>goes free running I will have problem anyway.
>
>Waiting suggestions.. =3D)
>
>Thanks!
>

Ignoring the FPGA implementation issues and concentrating on the system
design for a moment:

What you want is a local Nx2048kHz clock, which can be slaved to an
external 2048kHz clock when it is present (probably by a PLL), but
free-runs at the correct nominal frequency when absent. This was quite a
common requirement for telecomms equipment about 20 years ago.

Thus when there is valid E1 data, none is lost.

How to implement this using the inferior clock resources of the Spartan
series of FPGAs is a rather harder question, which is left to others...

Cheers,
Robert
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145135
Subject: In system memory editor of Altera for Xilinx
From: "jmunir" <jmunir@gts.tsc.uvigo.es>
Date: Fri, 29 Jan 2010 07:22:18 -0600
Links: << >>  << T >>  << A >>
Hi!,

I have been working with Altera FPGAs for a long time and now I have to
deal with Xilinx ones. Until now, with Quartus II I have been able to
manage the content of different registers and memories with 'In system
memory editor' and I would like to do the same with Xilinx. I cannot find
the right application to do it. Could you tell me which one I need or how I
can do it?

Thanx

J. 

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145136
Subject: Re: Xilinx DCM: Is CLKIN_PERIOD really required
From: Gabor <gabor@alacron.com>
Date: Fri, 29 Jan 2010 06:30:33 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 29, 2:19=A0am, backhus <goous...@googlemail.com> wrote:
> On 29 Jan., 04:09, Sudhir Singh <Sudhir.Si...@email.com> wrote:
>
> > Hi Guys,
>
> > Just wondering if the CLKIN_PERIOD value needs to be set to the period
> > of input clock when instantiating a DCM component. I have a design
> > where input clock can be either 25MHz or 125MHz, the clock frequency
> > will change during operation. I will be using the DCM mainly for de-
> > skewing. What should the CLKIN_PERIOD be set to in this case?
> > Does it cause any problems if CLKIN_PERIOD is not set?
>
> > Cheers
> > Sudhir
>
> Hi Sudhir,
> the DCM should work as specified, regardless of the frequency given in
> the coregenerator GUI or VHDL Generic Maps.
> Only thing to considder is, that the DCM might loose it's frequency
> locking when the input frequency changes.
> You should do some post-par simulations and observe the LOCKED signal.
> (Locking on a new frequency takes time.)
>
> Have a nice synthesis
> =A0 Eilert

If I'm not mistaken the CLKIN_PERIOD is mainly needed for the DFS
portion of the DCM, which you shouldn't need for phase shifting.
Also I've seen cases where the DCM loses lock and does not negate
the LOCKED signal.  You should monitor the status bits to be sure
that the DCM is locked, and reset it when you detect loss of lock.

Regards,
Gabor

Article: 145137
Subject: Re: DPA vs FPGA Security?
From: Gabor <gabor@alacron.com>
Date: Fri, 29 Jan 2010 06:39:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 28, 10:57=A0pm, "jt_eaton" <z3qmtr45@n_o_s_p_a_m.gmail.com>
wrote:
> >Just read an article over at FPGA Journal about ways to bypass the
> >security features on FPGA designs:
>
> >http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-f...
>
> >A lot of scary hype and generalities, but the underlying message seems
> >to be that by using Differential Power Analysis it's possible to
> >decrypt a protected FPGA design. Basic idea is to monitor the power
> >consumption while loading the encrypted design, then via some kind of
> >magic infer what the plaintext bitstream is and then reverse engineer
> >it.
>
> >Sounds like someone at a security research outfit is trying to sell
> >some consulting hours to me, but what's the general feeling about
> >this? Is this a real threat, and what are the realistic barriers to
> >applying this attack?
>
> >Eric
>
> Why bother reverse engineering it. Buy a product, extract the bitstream,
> clone and PCB and partslist, and sell it.
>

The point of encrypted bitstreams is that they only work on that
one copy of the part, or on parts that have been loaded with the
correct key.  For Xilinx the key is stored in volatile SRAM and
backed up with a battery.  It would be pretty hard to take the
chip top off for probing while keeping the backup power active,
but of course not impossible.  Also flip-chip packaging makes
this sort of probing even harder.

So you can copy the board, bitstream and all, but presumably not the
key to make that bitstream work.

> Back in the 60's the =A0CIA dug a tunnel under the Berlin wall to tap int=
o an
> underground telephone cable on the east side. The traffic was all encrypt=
ed
> but they had at one point passed next to some cable with unencrypted
> traffic.
> They recorded the noise spikes that were coupled over and could read the
> unencryted traffic at will.
>
> DPA is a cake walk compared to that.
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com


Article: 145138
Subject: Re: In system memory editor of Altera for Xilinx
From: Antti <antti.lukats@googlemail.com>
Date: Fri, 29 Jan 2010 06:42:53 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 29, 3:22=A0pm, "jmunir" <jmu...@gts.tsc.uvigo.es> wrote:
> Hi!,
>
> I have been working with Altera FPGAs for a long time and now I have to
> deal with Xilinx ones. Until now, with Quartus II I have been able to
> manage the content of different registers and memories with 'In system
> memory editor' and I would like to do the same with Xilinx. I cannot find
> the right application to do it. Could you tell me which one I need or how=
 I
> can do it?
>
> Thanx
>
> J.
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

there is no such tool for Xilinx
their programmers are just too lazy to make it

Antti


Article: 145139
Subject: Re: FPGA Editor - Post Route Simulation after changes in Ncd file
From: kkoorndyk <kris.koorndyk@gmail.com>
Date: Fri, 29 Jan 2010 08:03:15 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 28, 1:55=A0pm, "Charles" <charlesdlam...@gmail.com> wrote:
> Hi All,
> =A0 =A0 =A0 =A0I am new to the FPGA design flow. Now I am working on FPGA=
 editor to
> make changes in the design. Once I make changes in the ncd file i can hav=
e
> either a modified ncd file or a bit file from it (using Bitgen).
>
> My question is that is it possible to do post route simulation from any o=
f
> these two files or is there any other way to do it??
>
> Thanks in Advance,
>
> Charles.
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

Yep.  Look at the Command Line Tools User Guide (UG628) for the NetGen
function.
www.xilinx.com/support/documentation/sw.../xilinx11/devref.pdf


Article: 145140
Subject: Re: In system memory editor of Altera for Xilinx
From: austin <austin@xilinx.com>
Date: Fri, 29 Jan 2010 08:13:56 -0800 (PST)
Links: << >>  << T >>  << A >>
Antti,

Oh, you are so kind!

Really, the way to set initial conditions is in your HDL code.

For BRAM, there is a whole app note on how to use the data2bram
utility to set BRAM contents.

http://www.xilinx.com/itp/xilinx92/books/docs/d2m/d2m.pdf

I would argue that we are (trying to) prevent poor coding practices,
which lead to errors, and poor HDL code,

Austin

Article: 145141
Subject: Re: DPA vs FPGA Security?
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Fri, 29 Jan 2010 08:16:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On 29 Jan., 15:39, Gabor <ga...@alacron.com> wrote:

> The point of encrypted bitstreams is that they only work on that
> one copy of the part, or on parts that have been loaded with the
> correct key. =A0For Xilinx the key is stored in volatile SRAM and
> backed up with a battery. =A0It would be pretty hard to take the
> chip top off for probing while keeping the backup power active,
> but of course not impossible. =A0Also flip-chip packaging makes
> this sort of probing even harder.
>
> So you can copy the board, bitstream and all, but presumably not the
> key to make that bitstream work.

DPA is a technique successfully used to read out the key from
smartcards
that are specifically designed to protect the key. There is no need to
take the top off. DPA looks at the power supply of the chip.
The differences seen on the power are very small, but with enough
averaging
you can differntiate any signal from the noise, so they repeat the
operation
many times until they see differences in power surge from cycle to
cyle.

With knowledge of the crypto algorithm - which they have in case of
the FPGA
- they can now simulate what the power consumption pattern for a 1 in
the
position X of the key would be compared to a 0 at that position.

This is still hard work but in many cases a lot faster than a brute
force attack.

Also: At least for smart cards it is the case that once you learned
how to get the
key from a given type of smart card you can repeat this automated
within a few
minutes for another card of the same type.
This means if XC5V keys are attacked successfully with this method you
can build
a device that cracks any other XC5V design quickly.

Kolja Sulimma



Article: 145142
Subject: Re: Xilinx DCM: Is CLKIN_PERIOD really required
From: austin <austin@xilinx.com>
Date: Fri, 29 Jan 2010 08:21:14 -0800 (PST)
Links: << >>  << T >>  << A >>
All,

The clock in period for the DCM is used to set the configuration bits
for best performance (tap size, etc.).

If you don't set it to the right frequency range, you may not get the
best performance, and perhaps it won't work at all if you are set for
the low range, and the input is in the high range.

The absolute value (accuracy) of the number is not important.  The DCM
software in ISE is just trying to make decisions based on the low
frequency range, and the high frequency range.

So, for example, if the input is from 25 MHz to 150 MHz, any value in
this range is fine.

The DCM will track any input in this range, until it runs out of taps
with the delay lines.  Then LOCKED goes false (the only reason why it
does go false).

Also monitor CLOCK_IN_LOST status bit, as when the clock is lost, this
is the ONLY bit that changes (everything else is synchronous to
CLOCK_IN, so when it is lost, nothing will change, except this one
status bit).

Austin



Article: 145143
Subject: Re: In system memory editor of Altera for Xilinx
From: Antti <antti.lukats@googlemail.com>
Date: Fri, 29 Jan 2010 08:39:53 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 29, 6:13=A0pm, austin <aus...@xilinx.com> wrote:
> Antti,
>
> Oh, you are so kind!
>
> Really, the way to set initial conditions is in your HDL code.
>
> For BRAM, there is a whole app note on how to use the data2bram
> utility to set BRAM contents.
>
> http://www.xilinx.com/itp/xilinx92/books/docs/d2m/d2m.pdf
>
> I would argue that we are (trying to) prevent poor coding practices,
> which lead to errors, and poor HDL code,
>
> Austin

Austin, I wanted to see the commentary.
and well what I said stands:

Xilinx could implement MEMORY editor the same way as Altera does
suppor it
if Xilinx software guys what care about the customers.

The BRAM's can be accessed over JTAG, this is possible for Altera and
for Xilinx devices
Altera software does allow their customer to edit the BRAM over jtag
because they
have made this software for their customers, and well Xilinx has not.

Antti
















Article: 145144
Subject: Re: In system memory editor of Altera for Xilinx
From: Alan Fitch <alan.fitch@spamtrap.com>
Date: Fri, 29 Jan 2010 16:42:02 +0000
Links: << >>  << T >>  << A >>
austin wrote:
> Antti,
> 
> Oh, you are so kind!
> 
> Really, the way to set initial conditions is in your HDL code.
> 
> For BRAM, there is a whole app note on how to use the data2bram
> utility to set BRAM contents.
> 
> http://www.xilinx.com/itp/xilinx92/books/docs/d2m/d2m.pdf
> 
> I would argue that we are (trying to) prevent poor coding practices,
> which lead to errors, and poor HDL code,
> 
> Austin

Hi Austin,
   isn't that tool called data2mem now?

regards
Alan


-- 
Alan Fitch
Senior Consultant

Doulos  Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 
1AW, UK
Tel:  + 44 (0)1425 471223		Email: alan.fitch@doulos.com	
Fax:  +44 (0)1425 471573		http://www.doulos.com

------------------------------------------------------------------------

This message may contain personal views which are not the views of 
Doulos, unless specifically stated.

Article: 145145
Subject: Re: In system memory editor of Altera for Xilinx
From: Antti <antti.lukats@googlemail.com>
Date: Fri, 29 Jan 2010 08:46:56 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 29, 6:42=A0pm, Alan Fitch <alan.fi...@spamtrap.com> wrote:
> austin wrote:
> > Antti,
>
> > Oh, you are so kind!
>
> > Really, the way to set initial conditions is in your HDL code.
>
> > For BRAM, there is a whole app note on how to use the data2bram
> > utility to set BRAM contents.
>
> >http://www.xilinx.com/itp/xilinx92/books/docs/d2m/d2m.pdf
>
> > I would argue that we are (trying to) prevent poor coding practices,
> > which lead to errors, and poor HDL code,
>
> > Austin
>
> Hi Austin,
> =A0 =A0isn't that tool called data2mem now?
>
> regards
> Alan
>
> --
> Alan Fitch
> Senior Consultant
>
> Doulos Developing Design Know-how
> VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
> Services
>
> Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
> 1AW, UK
> Tel: =A0+ 44 (0)1425 471223 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email: alan.fi...=
@doulos.com =A0 =A0 =A0 =A0
> Fax: =A0+44 (0)1425 471573 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://www.doul=
os.com
>
> ------------------------------------------------------------------------
>
> This message may contain personal views which are not the views of
> Doulos, unless specifically stated.

its data2mem, it is very useful, but it is NOT THE SAME thing!

Altera IDE can edit the memory OVER JTAG,
Xilinx tools can not.

Antti









Article: 145146
Subject: Re: In system memory editor of Altera for Xilinx
From: austin <austin@xilinx.com>
Date: Fri, 29 Jan 2010 09:01:52 -0800 (PST)
Links: << >>  << T >>  << A >>
Antti,

"If Xilinx cared about the customers...."

Cruel, and inappropriate.

Of course we care (deeply) about our customers!

"Because Xilinx does not have Tool-A, they have no concern for
customers..."

It would be equally true then to say because the 'other guy' has no
domain specific platforms, that they have zero regard for their
customers, and force them to re-invent the wheel before they even
begin a project ... (which in my humble opinion is all true)

So, let us refrain from 'name calling',  one could waste a great deal
of time,

Austin


Article: 145147
Subject: Re: In system memory editor of Altera for Xilinx
From: "jmunir" <jmunir@n_o_s_p_a_m.gts.tsc.uvigo.es>
Date: Fri, 29 Jan 2010 11:06:05 -0600
Links: << >>  << T >>  << A >>
So, my question is:

When I implement a block and I would like to control several of his
parameters to test its behaviour, do I have to recompile each time I want
to change one of them? :O

That has not sense! It is impractical!

J.

>On Jan 29, 6:42=A0pm, Alan Fitch <alan.fi...@spamtrap.com> wrote:
>> austin wrote:
>> > Antti,
>>
>> > Oh, you are so kind!
>>
>> > Really, the way to set initial conditions is in your HDL code.
>>
>> > For BRAM, there is a whole app note on how to use the data2bram
>> > utility to set BRAM contents.
>>
>> >http://www.xilinx.com/itp/xilinx92/books/docs/d2m/d2m.pdf
>>
>> > I would argue that we are (trying to) prevent poor coding practices,
>> > which lead to errors, and poor HDL code,
>>
>> > Austin
>>
>> Hi Austin,
>> =A0 =A0isn't that tool called data2mem now?
>>
>> regards
>> Alan
>>
>> --
>> Alan Fitch
>> Senior Consultant
>>
>> Doulos Developing Design Know-how
>> VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk *
Project
>> Services
>>
>> Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
>> 1AW, UK
>> Tel: =A0+ 44 (0)1425 471223 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email:
alan.fi...=
>@doulos.com =A0 =A0 =A0 =A0
>> Fax: =A0+44 (0)1425 471573 =A0 =A0 =A0 =A0 =A0 =A0 =A0
=A0http://www.doul=
>os.com
>>
>>
------------------------------------------------------------------------
>>
>> This message may contain personal views which are not the views of
>> Doulos, unless specifically stated.
>
>its data2mem, it is very useful, but it is NOT THE SAME thing!
>
>Altera IDE can edit the memory OVER JTAG,
>Xilinx tools can not.
>
>Antti
>
>
>
>
>
>
>
>
>	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145148
Subject: Re: In system memory editor of Altera for Xilinx
From: Antti <antti.lukats@googlemail.com>
Date: Fri, 29 Jan 2010 09:11:15 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 29, 7:01=A0pm, austin <aus...@xilinx.com> wrote:
> Antti,
>
> "If Xilinx cared about the customers...."
>
> Cruel, and inappropriate.
>
> Of course we care (deeply) about our customers!
>
> "Because Xilinx does not have Tool-A, they have no concern for
> customers..."
>
> It would be equally true then to say because the 'other guy' has no
> domain specific platforms, that they have zero regard for their
> customers, and force them to re-invent the wheel before they even
> begin a project ... (which in my humble opinion is all true)
>
> So, let us refrain from 'name calling', =A0one could waste a great deal
> of time,
>
> Austin

ah, relax..

both X and A care for the shareholders.

but the topic about the "memory editor" is well, it would be SO EASY
for Xilinx todo,
but it has not been done. some 3rd party could do, i could do it, but
it would be much
more work for me todo it properly as it would be for xilinx, besides
because Xilinx
does not open up the xilinx usb cable protocol i could not support
xilinx cables
from my tool, so it would be pointless todo.

there are two reasons why Xilinx does not have memory editor
1) there are some silicon problems, errata, bugs with the silicon
preventing the usefulnes of the tool
2) Xilinx just doesnt care to offer this tool

I see no other reasons. you can choose. either silicon problems, or
lazy programmers.
or management issues. i figured out 3rd option.

but.. DATA2MEM is MUCH more important (yeah for the customers) then
the memory editor
and well Altera has no data2mem possibility at all, what is real
problem.

Xilinx has what is really needed, and misses on optional "good to
have" thing that is not
that vital.

Antti



Article: 145149
Subject: Re: In system memory editor of Altera for Xilinx
From: Antti <antti.lukats@googlemail.com>
Date: Fri, 29 Jan 2010 09:12:14 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 29, 7:06=A0pm, "jmunir" <jmunir@n_o_s_p_a_m.gts.tsc.uvigo.es>
wrote:
> So, my question is:
>
> When I implement a block and I would like to control several of his
> parameters to test its behaviour, do I have to recompile each time I want
> to change one of them? :O
>
> That has not sense! It is impractical!
>
> J.
>

NO of course not!!!

just use data2mem tool!

Antti



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