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 129750

Article: 129750
Subject: AES Bitstream Encryption in Virtex-4. How safe it is?
From: Frai <maybetooparanoid@gmail.com>
Date: Tue, 4 Mar 2008 09:22:38 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

I need to place my FPGA designs in a safe platform, and I have some
questions:

1. Does anybody know whether Virtex-4 AES bitstream protection has
been broken?

2. Do you consider it a good protection?

3. What could a hacker do to overcome this protection, other than
brute-force?

4. Are there other alternatives in the market, from other vendors than
Xilinx, providing the same or higher level of security?

Regards.

Article: 129751
Subject: Re: clock distribution accross boards
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 4 Mar 2008 09:55:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 3, 8:27=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
> Hi,
>
> maybe you folks can help me with a design decision:
>
> I need to distribute a clock to up to ten identical boards.
> The boards are all plugged into a backplane in a single row.
>
> In addition to the backplane the boards will be connected by
> a twinax flatband cable on samtec connectors. For the clock
> distribution I can choose between a bus structure cable or a
> series of point to point connections between neighbouring boards.
>
> The leftmost of the identical boards shall provide a clock for all
> the other boards. I am now concerned that a bus structure with
> that many stubs will have problems maintaining a good signal quality.
>
> I could instead use point to point connections with fanout clock
> buffers on each board to forward the clock to the next board. As far
> as the signal quality goes this will obviously work very well,
> BUT the boards need a fixed phase relationship. While the absolute
> phase is of no importance, the phase must not drift over time or
> temperature by more than 50ps or so. Ten buffers in a row would
> probably have a larger drift, wouldn't they?
>
> Any ideas, how I can make a pure passive distribution work in a setup
> like that?
>
> Also: How can I turn on the termination on the last board dynamically?
>
> Kolja Sulimma

Since you're looking at precision timing requirements, you will have
issues.
Considering that 50ps is about a half centimeter of propagation delay
on a PC board, you're already at a loss.

If all you want is 50ps of repeatability (and account for the
propagation delay as a fixed offset per board), your situation is
better but still poor.  If you use a standard backplane, do you really
believe you can maintain fidelity going backplane to card to backplane
to card to backplane to card....  If you had ideal terminations, with
ideal connectors, you could achieve your goal.  The impedance issues
you have traveling through the connectors is probably enough to change
the timing of the 2nd card depending on whether the 3rd or 4th (or
10th) cards are plugged in even with appropriate terminations.

Buffering is also a problem since every buffer is going to add some
noise.  With a multiple-output clock buffer, you're still looking at
channel matching as an issue.

So, consider wandering off to the RF realm.  Generate a sinusoidal
high-frequency clock.  Rather than using a full level signal you can
passively split the sinusoid into your desired number of channels at
the source or on the backplane and terminate each clock *on the
backplane* and use an impedance-matched front end on your cards so
they *look* like open circuits to the backplane traces.
Alternatively, use one backplane-terminated trace for the sinusoidal
clock and do a better job of making the cards look like open circuits
to the buffers.  In either case, you have added noise from the clock
receive buffer on each card.

If your cards are identical, you probably want a way to shut off the
unused clocks on each destination card.

Each card will have an offset from the first card based on the
propagation delay across the backplane.  The first card will have a
different offset still since its clock is received before launching
onto the backplane.

You have a pretty strenuous requirement but you can eliminate many of
the troubles by getting rid of reflections and tuning the receivers to
look like open circuits.

I once made a power splitter for a 155 MHz sinusoid by using 1-ft
lengths of coax and T-connectors.  Since two 50-ohm terminated cables
teed together look like 25 ohms and 25 ohms across a 50 ohm, quarter
wavelength cable looks like 100 ohms to the other side, 2 of these
pairs look like 50 ohms when teed together.  When properly terminated,
each signal was 1/4 power.  When I looked at one of the channels on a
scope and removed one of the other terminations, the scope signal
didn't get larger, it got smaller!  It was fun to show people and have
them scratch their heads over the situation.  I had clean sinusoids
in, clean sinusoids out, and used standard RF techniques to deal with
stubs and impedances.  Fun stuff.

Now go off and have fun!

- John_H

Article: 129752
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: austin <austin@xilinx.com>
Date: Tue, 04 Mar 2008 11:08:27 -0800
Links: << >>  << T >>  << A >>
Frai,

Other than the public announcement that the NSA has approved V4 for
single chip crypto systems, what else would you need?

Seriously, no one has broken AES256, and no one has broken V4's
implementation of AES256 (using the battery backed key memory).

A hacker would not attack directly, rather they would wait outside your
building, and offer cash to anyone willing to reveal the key to them.

No other device exists that is 'generic' approved for all NSA single
chip crypto systems.  No ASIC, ASSP, nor FPGA.  It has been called
"completely disruptive technology" and many have told us "V4 will
revolutionize the single chip crypto market."

http://www.xilinx.com/prs_rls/2007/end_markets/0713_v4nsa.htm

I just love it when there is 0 competition!

Austin

Article: 129753
Subject: Re: verifying UNIFORM using matlab
From: FPGA <FPGA.unknown@gmail.com>
Date: Tue, 4 Mar 2008 12:10:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 4, 10:45=A0am, Tricky <Trickyh...@gmail.com> wrote:
> On Mar 4, 3:23 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
>
>
>
>
>
> > On Mar 4, 9:12 am, Tricky <Trickyh...@gmail.com> wrote:
>
> > > On Mar 4, 2:00 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
>
> > > > On Mar 4, 4:26 am, Tricky <Trickyh...@gmail.com> wrote:
>
> > > > > On Mar 3, 9:15 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
>
> > > > > > I have written a process to generate random numbers using UNIFOR=
M. I
> > > > > > was trying to check the results using "rand" in matlab. How do i=

> > > > > > initialise the seed values of both these functions to the same v=
alue.
> > > > > > I see that the random numbers generated by UNIFORM are different=

> > > > > > compared to rand when the seed values are left uninitialised.
> > > > > > What do I need to change so that I get same output from both pro=
grams.
>
> > > > > > Thanks
>
> > > > > Uninitilised positives (the seeds in this case) will take a value =
of 1
> > > > > when they are put into the uniform function. Unitialised types whe=
n
> > > > > used will take type'low as their value
>
> > > > > positive'low =3D 1
> > > > > std_logic'low =3D 'u'
> > > > > etc.
>
> > > > > so both of your first calls to uniform are seeding it with two 1s.=

>
> > > > > I dont know how the seeding works in matlab. It may not even use
> > > > > positives, but the entire integer range. it is common in C to seed=
 the
> > > > > random number generator with the system time. Does matlab do somet=
hing
> > > > > similar? The C random function only has 1 seed, whereas uniform ta=
kes
> > > > > 2.
>
> > > > I am not sure how the rand function in MATLAB works. I tried to sear=
ch
> > > > if the code of the function was described anywhere but couldnt find.=

> > > > I dont know if we can get MATLAB to generate results as UNIFORM does=
.
> > > > As you said, uniform has 2 seeds while rand has 1.
> > > > If anyone has an idea on how this can be done, please post your
> > > > comment.
>
> > > Why not generate a file containing all the stimulus for the vhdl and
> > > matlab model in one or the other, instead of trying to recreate the
> > > random sequence?- Hide quoted text -
>
> > > - Show quoted text -
>
> > The goal is to check that the VHDL code generates results similar to
> > MATLAB . I have written the outputs of both in seperate text files. I
> > am not able to initialise the rand function to generate results
> > similar to MATLAB and vice versa. Called MATLAB today to get some more
> > information on how they have developed the rand function. They said
> > that this information is not available to the public.
> > I think one of the ways to do this would be, generating a pdf function
> > for both cases and showing that their random distriution is similar.
>
> > If any of you have other ideas please post them.
>
> In that case, why are you even trying to do this? generate a file from
> matlab that is used as the stimulus for the VHDL testbench. Then you
> do not need to use the uniform function at all, and then you are
> testing that the results match.- Hide quoted text -
>
> - Show quoted text -

I have to use the UNFORM function to check if it behaves in sync with
MATLAB. I have given up on getting the same results in matlab as in
VHDL. I am just trying to get a pdf plot of both results. No idea on
how to do this yet.

Article: 129754
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: "Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com>
Date: Tue, 4 Mar 2008 12:34:51 -0800 (PST)
Links: << >>  << T >>  << A >>

> 1. Does anybody know whether Virtex-4 AES bitstream protection has
> been broken?

Didn't hear anything public ... doesn't mean it hasn't been done ...
and even if never done, doesn't mean it can't ... As always with
security it depends on the value of what you're protecting. But unless
it's a control process for cold fusion, I'd say you're most likely in
the clear.


> 2. Do you consider it a good protection?

Most people do .... so do I :)


> 3. What could a hacker do to overcome this protection, other than
> brute-force

 - Bribe someone at the factory to 'listen' when programming the key
 - Physically break into your office and get the source code or
unencrypted bit
 - Kidnap one of your lead developer's family members and shoot them
one by one until he gives you what you want ... (iterate over the
whole team as needed)

They may all seem 'weird' options ... but that's how I'd do it if I
had to ...

Sylvain

Article: 129755
Subject: Re: Avnet/Memec V4FX12LC proto card and SysGen
From: Bryan <bryan.fletcher@avnet.com>
Date: Tue, 4 Mar 2008 14:13:09 -0800 (PST)
Links: << >>  << T >>  << A >>
CTW,

This board was used with hardware-in-the-loop with an older SysGen
(7.1, maybe?).  You can contact your local Avnet FAE and they can get
you the files.

Bryan

cwoodring wrote:
> Hi,
>     Has anyone used this card with Xilinx System Generator to do hardware in
> the loop simulation. I can not find a board description file for it in the
> form that the System Generator wants. There is a  utility in System
> Generator called xlSBDBuilder;or something like that helps one create the
> needed files to do hardware in the loop simulation over the JTAG, but you
> need to know the pinouts of all the ports used on the card.
>
> If someone has already done this I'd greatly appreciate a copy of the needed
> files.
>
> Thanks,
>
> CTW

Article: 129756
Subject: Re: [Altera] How to infer some code into ROM-blocks (in automatic
From: Mark McDougall <markm@vl.com.au>
Date: Wed, 05 Mar 2008 11:49:25 +1100
Links: << >>  << T >>  << A >>
sdf wrote:

> My question: is it possible by Quartus to infer some code into ROM
> blocks when it is possible and all the rest let him to make synthesis
> using ALUTs?
> Or should I manually divide all my ROM-like code to what will inferred
> into ROM blocks and that part which will be done usign ALUTs?

The short answer: yes.

I haven't done it myself, but I do know the Megawizard Plug-in Manager
lets you choose whether you want ROM blocks synthesizes as block ram, luts
or automatic.

Check out the "altera_attribute" help. You should be able to specify on a
per-entity basis whether block ram or logic is used to synthesis inferred
rom/ram...

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 129757
Subject: Re: sd card slave interface
From: "bjzhangwn@gmail.com" <bjzhangwn@gmail.com>
Date: Tue, 4 Mar 2008 19:29:49 -0800 (PST)
Links: << >>  << T >>  << A >>
On 2=D4=C228=C8=D5, =C9=CF=CE=E710=CA=B148=B7=D6, MikeShepherd...@btinternet=
.com wrote:
> >Now I want to design aSDcard,for special use,I must use fpga to
> >implement the interface between host controller and NAND flash,can
> >someone give me some advice if it is easy to implement it?And where I
> >can get the controller source files for free,3X.
>
> You want to design anSDcard???
>
> You want to implement the interface between a host controller and NAND
> flash?  Well, that could make sense, if you're designing anSDcard.
>
> If you're designing an interface between the host controller and the
> NAND flash, why do you need the source files for the controller?
> Surely the interface specification is enough?
>
> Maybe you should slow down a little and say carefully what you're
> trying to do.
>
> Mike
Yes,I am desiging an interface between the host controller and the
NAND flash,and I want to know how the controller operate.

Article: 129758
Subject: Re: Blast from the past
From: "jtw" <wrightjt @hotmail.invalid>
Date: Wed, 05 Mar 2008 04:19:16 GMT
Links: << >>  << T >>  << A >>
You might want to also crosspost to comp.arch.fpga.


"jtw" <wrightjt @hotmail.invalid> wrote in message 
news:L9pzj.14674$0o7.10494@newssvr13.news.prodigy.net...
> It's probably been over 20 years since I've used Aplus--was it 1984, or 
> 1985?
>
> If you can post a snippet of the code, perhaps someone can translate?
>
> JTW
>
> "CTSportPilot" <girmann@gmail.com> wrote in message 
> news:af888fdd-386e-492b-89ee-568bf48e5ea2@e25g2000prg.googlegroups.com...
>>I came across an ADF (Altera Desgn Format) file from an Altera EPLD.
>> Does anyone out there know of a syntax primer on this dead HDL
>> format?  For those playing at home, this is an HDL from Altera that
>> came with the A+PLUS software.  Yes, I can convert it to more modern
>> formats, but first I need to understand it.
>>
>> TIA!
>
> 



Article: 129759
Subject: Re: my Spartan-4 wishlist
From: rickman <gnuarm@gmail.com>
Date: Tue, 4 Mar 2008 20:41:42 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 3, 4:16 pm, DJ Delorie <d...@delorie.com> wrote:
> Antti <Antti.Luk...@googlemail.com> writes:
> > 2) devices packages like Spartan-3E (including QN132 !) or better
> > (microBGA 6x6 mm?)
>
> I keep wondering if there's a market for a few "unbalanced" devices,
> like something with a ton of gates but in a tqfp-64 package.  Or BGA
> packages that only use the two outer rows for signals, for simpler
> board routing.

Hey, I'd be happy with pretty much *any* FPGA in a small leaded
package, even a 100 pin TQFP.  I am doing a current job with the
Lattice XP family because it is the *only* FPGA available in a 100 pin
QFP.  They have exactly one size, the 3000 LUT part which is the
smallest in the family.  Fortunately there is little chance I will
need a larger part.  But on the other hand, I won't be able to
consider anything fancy for this project because of this limitation.
Of course, I could consider a no lead package such as a BGA, but for
the most part they are much more expensive, as much as anything,
because they have lots more pins.


> Likewise, I'd like to see the occasional MCU with a ton of ram and a
> little flash, rather than the other way as it usually is.  Every once
> in a while I need a smart buffer chip :-(

I think there is an Atmel ARM part which has a huge amount of RAM
although I want to say the flash is external, but it might be a dual
die approach with both in the same package.  It is one of their older
parts and I expect it will only run at 33 MHz.

Article: 129760
Subject: Re: my Spartan-4 wishlist
From: rickman <gnuarm@gmail.com>
Date: Tue, 4 Mar 2008 20:45:25 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 3, 4:42 pm, Antti <Antti.Luk...@googlemail.com> wrote:
> On 3 Mrz., 22:16, DJ Delorie <d...@delorie.com> wrote:
>
> > Antti <Antti.Luk...@googlemail.com> writes:
> > > 2) devices packages like Spartan-3E (including QN132 !) or better
> > > (microBGA 6x6 mm?)
>
> > I keep wondering if there's a market for a few "unbalanced" devices,
> > like something with a ton of gates but in a tqfp-64 package.  Or BGA
> > packages that only use the two outer rows for signals, for simpler
> > board routing.
>
> > Likewise, I'd like to see the occasional MCU with a ton of ram and a
> > little flash, rather than the other way as it usually is.  Every once
> > in a while I need a smart buffer chip :-(
>
> oh yes, TQFP48 0.5mm pitch FPGA running from single voltage!
> defenetly, but hey thats wish for new Lattice device ;)
>
> BTW, Actel QFN132 3 row QFN 0.5mm pitch CAN be used on
> 2 layer PCB or even single layer.
>
> Antti

I have not looked very hard at the 132 pin QFN package.  But at 0.5 mm
pin pitch, how exactly do you route signals from the middle row out?
I guess the pins are actually 1.5 mm pitch on each row for 0.5 mm
considering all three rows?  One of the problems I have using 0.65 mm
pitch QFPs is that I can't route between the pins.  That is a real
PITA.  I sometimes think I would be better off with a wider pitch
part, but I'm not sure I can fit them on the board... :^(

Article: 129761
Subject: Re: my Spartan-4 wishlist
From: rickman <gnuarm@gmail.com>
Date: Tue, 4 Mar 2008 20:51:00 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 3, 5:08 pm, n...@puntnl.niks (Nico Coesel) wrote:
> "M.Randelzhofer" <techsel...@gmx.de> wrote:
> >"Antti" <Antti.Luk...@googlemail.com> schrieb im Newsbeitrag
> >news:467475ec-6d16-4789-acec-07d3c1a4977e@s19g2000prg.googlegroups.com...
> >> here it is:
>
> >> 1) devices densities like in Spartan-3 (50..5000)
> >> 2) devices packages like Spartan-3E (including QN132 !) or better
> >> (microBGA 6x6 mm?)
> >> 3) all good features of S3A/AN !!
> >> 4) design security with OTP encryption key (like Lattice ECP2)
> >> 5) other features as already planned by Xilinx
>
> >> Antti
> >> has made his Christmas wish this year... or did I just describe
> >> Lattice XP3 or Cyclone IV?
> >> eh, I just wish Spartan-4 will have all the good things from Spartan-3
> >> subfamilies+extra goodies.
>
> >Hi Antti,
>
> >I've the same wishes, some additional i/O & memory cores would be nice:
>
> >6) USB2 host/slave interface with integrated PHY
>
> >7) Ethernet MAC + PHY
>
> >8) DDR2/3 core
>
> >9) some analog stuff (ADC, temp sensor, system supervisor)
>
> >S4 would be a serious competitor to 32bit microcontrollers, if some of their
> >standard peripherals are included in low price FPGA's.
>
> You forget a standard ARM core, some internal flash (say 32KB to
> 256KB), some memory (8KB to 64KB) and some standard pheripherals like
> UART, SPI, I2C. Such a device would be a real killer. I would design
> it in straight away if it existed today for a Spartan price.

I thought you could get all that in an MCU?  At that point do you even
need the FPGA anymore???

After I had presented to the customer my approach using an FPGA do
handle the data path for a simple board which had some standard and
non standard interfaces, I found out about an ADI part which is a DSP
combined with a high resolution Codec.  I didn't look at it really
hard, but at first glance, it looks like it could have been as good of
a solution and a bit cheaper than the FPGA + codec.  I will say I
prefer writing VHDL to coding DSPs though.  The toolsets tend to be
cheaper too.

But I have to say the DSP approach looks pretty good.

Article: 129762
Subject: Re: my Spartan-4 wishlist
From: DJ Delorie <dj@delorie.com>
Date: 05 Mar 2008 00:01:47 -0500
Links: << >>  << T >>  << A >>

rickman <gnuarm@gmail.com> writes:
> Hey, I'd be happy with pretty much *any* FPGA in a small leaded
> package, even a 100 pin TQFP.

There are plenty of Spartans in QFP packages, as well as other vendors...
http://www.digikey.com/scripts/DkSearch/dksus.dll?Cat=2556262;keywords=fpga%20qfp;stock=1

> I think there is an Atmel ARM part which has a huge amount of RAM
> although I want to say the flash is external, but it might be a dual
> die approach with both in the same package.  It is one of their
> older parts and I expect it will only run at 33 MHz.

The MCUs I'm working with are 20MHz, 24k flash and 2k ram.  I think it
would be interesting to see one with 2k flash and 24k ram, for
example.

Article: 129763
Subject: Re: FPGA/CPLD group on LinkedIn
From: wmwmurray@gmail.com
Date: Tue, 4 Mar 2008 21:12:16 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 3, 2:20 pm, sky46...@trline5.org wrote:
> rickman <gnu...@gmail.com> wrote:
> >On Mar 2, 7:19 pm, wmwmur...@gmail.com wrote:
> >> On Mar 2, 3:15 pm, sky46...@trline5.org wrote:
>
> >> > wmwmur...@gmail.com wrote:
> >> > >FPGA/CPLD group onLinkedIn
> >> > >    http://www.linkedin.com/e/gis/56713/3CC3BF77FD22
> >> > >Group for People Involved In the Design and Verification of FPGA's and
> >> > >CPLD's to Exchange Idea's and Techniques.  You should have FPGA/CPLD
> >> > >Design/Verification on your Profile to Join.  (The focus is more on
> >> > >FPGA/CPLD in the product as opposed to FPGA's solely as a path to an
> >> > >ASIC)
>
> >> > I prefer NNTP over webbforums that is pumped full of the latest webb-fad from
> >> > the webmaster. Thread structure often missing.
>
> >> The one big advantage is that joining the group allows one to search
> >> the members CV's and look for a few people to ask for a one-on-one
> >> answer to something that they are familiar with.  It also allows one
> >> to build contacts in an area of interest, that one might not otherwise
> >> meet.  Hope this helps with why I started the group.  There are other
> >> reasons to join beyond this as well -- will save for later -- both
> >> NNTP, andLinkedIncan be useful tools
>
> Usenet seem to attract people with more solid knowledge. Also getting trapped
> in the get-the-latest-webb-browser race seems like a time waste.

LinkedIn does hit the WebBrowser pretty hard, but seems to do OK in
the later versions of Firefox, and there is a Mobile version too,
Another nice aspect to LinkedIn, is that it does let one do some
background research on a company/group/person BEFORE taking on
a design -- nice things to know that one does not talk about on NNTP
-- Do they breach their contracts?,  Do they pay on time?,  Do they
break
health/safety/environment regulations?, How are their PS&L Claims?,
etc,etc,etc........

Article: 129764
Subject: Re: my Spartan-4 wishlist
From: rickman <gnuarm@gmail.com>
Date: Tue, 4 Mar 2008 21:13:28 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 4, 11:22 am, Antti <Antti.Luk...@googlemail.com> wrote:
> On 3 Mrz., 23:08, n...@puntnl.niks (Nico Coesel) wrote:
>
>
>
> > "M.Randelzhofer" <techsel...@gmx.de> wrote:
> > >"Antti" <Antti.Luk...@googlemail.com> schrieb im Newsbeitrag
> > >news:467475ec-6d16-4789-acec-07d3c1a4977e@s19g2000prg.googlegroups.com...
> > >> here it is:
>
> > >> 1) devices densities like in Spartan-3 (50..5000)
> > >> 2) devices packages like Spartan-3E (including QN132 !) or better
> > >> (microBGA 6x6 mm?)
> > >> 3) all good features of S3A/AN !!
> > >> 4) design security with OTP encryption key (like Lattice ECP2)
> > >> 5) other features as already planned by Xilinx
>
> > >> Antti
> > >> has made his Christmas wish this year... or did I just describe
> > >> Lattice XP3 or Cyclone IV?
> > >> eh, I just wish Spartan-4 will have all the good things from Spartan-3
> > >> subfamilies+extra goodies.
>
> > >Hi Antti,
>
> > >I've the same wishes, some additional i/O & memory cores would be nice:
>
> > >6) USB2 host/slave interface with integrated PHY
>
> > >7) Ethernet MAC + PHY
>
> > >8) DDR2/3 core
>
> > >9) some analog stuff (ADC, temp sensor, system supervisor)
>
> > >S4 would be a serious competitor to 32bit microcontrollers, if some of their
> > >standard peripherals are included in low price FPGA's.
>
> > You forget a standard ARM core, some internal flash (say 32KB to
> > 256KB), some memory (8KB to 64KB) and some standard pheripherals like
> > UART, SPI, I2C. Such a device would be a real killer. I would design
> > it in straight away if it existed today for a Spartan price.
>
> > --
> > Programmeren in Almere?
> > E-mail naar nico@nctdevpuntnl (punt=.)
>
> well, Xilinx already own ARM IP-Core license, when Xilinx purchased
> Triscend
> they also got the IP licenses ownded by Triscend what included also
> ARM.
>
> so it is possible that the ARM core see new life in Spartan-4,
> Xilinx has no extra royalty to pay

Yes, anything is possible.  I might even win the Powerball... no, I
don't buy tickets...

So far, Xilinx has given no indication that they bought Triscend for
any reason other than to keep ARM out of the FPGA market.  Just like
so many other companies that Xilinx bought and deleted, the purpose
seems to have been to bury the technology rather than to develop it.

Xilinx seems to have a strong opinion that CPU hard cores do not mesh
well with FPGAs as it creates too many combinations of RAM, FPGA size
and package so that the number of parts blooms to unmanageable
numbers.  But then Xilinx has a history of making a firm stand on a
point and later reversing themselves when *they* think conditions are
different.  Meanwhile other companies eat their lunch for a bit while
they are still making their stand.  Embedded memory is one example.
Xilinx was one of the last companies to add that to the FPGA.  Later
the integrated hard logic block was another reversal.  I wonder if
their line in the sand against Flash FPGAs will be another soon to
happen reversal.  When the focus on getting the most logic on a die
for the lowest price was the main FPGA goal, the anti-Flash opinion
sounded good.  But I think the density is high enough now that there
are tons of applications that will benefit from having the Flash
integrated on the die even if there is a die size penalty due to the
lagging process technology. Rather like the way that Intel and AMD
can't figure out what to do with all the transistors on a die, so they
are adding more and more copies of the CPUs, at some point FPGAs will
have more than enough LUTs for most apps and other features will
become the main selection criteria.

It may not be the Spartan iv, but sometime soon, there will be a combo
chip with a right sized FPGA, various peripherals (ones that make
sense as a hard core rather than a soft one) and on die Flash memory,
both as configuration and program storage for an integrated CPU.
Isn't it ST Micro that has the Spear which is an ARM with bells and
whistles including a metal programmable gate array?  That is just one
step away from having an on die FPGA... I would be willing to bet the
only thing that stopped them from using an FPGA instead of a metal
programmed part was patents... you know, the ones that Triscend had
and now are buried in the vaults at Xilinx.  I can see a guy pushing a
dolly into an endless warehouse as the camera pulls back to show the
mountains of buried IP...

Maybe Xilinx was concerned that ARM might prove them wrong?!!

Article: 129765
Subject: Re: my Spartan-4 wishlist
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 4 Mar 2008 22:01:15 -0800 (PST)
Links: << >>  << T >>  << A >>
On 5 Mrz., 05:45, rickman <gnu...@gmail.com> wrote:
> On Mar 3, 4:42 pm, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > On 3 Mrz., 22:16, DJ Delorie <d...@delorie.com> wrote:
>
> > > Antti <Antti.Luk...@googlemail.com> writes:
> > > > 2) devices packages like Spartan-3E (including QN132 !) or better
> > > > (microBGA 6x6 mm?)
>
> > > I keep wondering if there's a market for a few "unbalanced" devices,
> > > like something with a ton of gates but in a tqfp-64 package.  Or BGA
> > > packages that only use the two outer rows for signals, for simpler
> > > board routing.
>
> > > Likewise, I'd like to see the occasional MCU with a ton of ram and a
> > > little flash, rather than the other way as it usually is.  Every once
> > > in a while I need a smart buffer chip :-(
>
> > oh yes, TQFP48 0.5mm pitch FPGA running from single voltage!
> > defenetly, but hey thats wish for new Lattice device ;)
>
> > BTW, Actel QFN132 3 row QFN 0.5mm pitch CAN be used on
> > 2 layer PCB or even single layer.
>
> > Antti
>
> I have not looked very hard at the 132 pin QFN package.  But at 0.5 mm
> pin pitch, how exactly do you route signals from the middle row out?
> I guess the pins are actually 1.5 mm pitch on each row for 0.5 mm
> considering all three rows?  One of the problems I have using 0.65 mm
> pitch QFPs is that I can't route between the pins.  That is a real
> PITA.  I sometimes think I would be better off with a wider pitch
> part, but I'm not sure I can fit them on the board... :^(

its 0.5mm pitch.
middle row pins can not be used on 2 layer PCB
only outer and inner row. my application did not
need much IO so that was sufficient

Antti

Article: 129766
Subject: Re: Planahead IP export
From: PatC <pato@patocarr.com>
Date: Tue, 04 Mar 2008 23:47:40 -0800
Links: << >>  << T >>  << A >>
FWIW,

  Brian, thanks for your input.

  I could solve this map issue by disabling global optimization when
building the IP block to be exported. Once the IP is inserted in the
destination design, global_opt can be enabled again, if needed.

-P@


brian.jackson@xilinx.com wrote:
> Hello Pat,
> 
> We have seen similar map issues in the past when sending large amounts
> of LOC constraints via a UCF file to ISE. We've made some improvements
> in both 10.1 ISE and PlanAhead to address them. Rather than just
> passing LOC constraints, we've seen a much better success rate when
> passing both LOC and BEL constraints. Therefore, in 10.1 release of
> PlanAhead, we've defaulted both the Export IP and Export Pblock
> commands to include both types of constraints in the UCF. The map
> group has also fixed quite a few of these types of logic packing
> scenarios that cause packing failures.
> 
> I'm not sure what version of PlanAhead you are using, but the latest
> 9.2 versions will output BEL constraints. If you are using 9.2, we'd
> like to try it using 10.1 PlanAehad and ISE. It would be helpful if
> you could file a bug against PlanAhead with the design data. If we
> duplicate it here, it will be filed as a bug against the map tool.
> 
> The other option is to strip out the 105 lines in question from the
> UCF file. We find that the mapper with usually just put them back in
> the same locations anyhow???
> 
> Please fell free to contact me directly to help resolve the issue.
> 
> Brian Jackson
> Marketing Manager, Xilinx
> 720-652-3102
> 
> 
> On Feb 23, 10:17 am, PatC <p...@patocarr.com> wrote:
>> Hi,
>>
>> I'm trying to insert an IP core generated by PlanAhead into our
>> script-based flow, but map fails with Pack:679 error on several slices.
>>
>> The IP in question is a wrapper around the PCIe block plus, that
>> contains our DMA engine. This component is pretty big and we decided to
>> lock it down when we deliver the sources to our customers. Using
>> PlanAhead, we intend to floorplan it tightly and lock its placement so
>> the customer won't have timing issues.
>>
>> The exported IP is in the edn/ucf form, and it's imported into our xst
>> flow without problems. I gutted the top level of the component and made
>> it a black box. Xst and ngdbuild run without problems. Both transform
>> the edn into an ngo. I also concatenated the system ucf to the component
>> ucf and fixed the relative paths.
>>
>> Map fails with 105 error 679, and over 3 thousand warnings (some
>> expected). Different runs give different results though.
>>
>> "Unable to obey design constraints (LOC=SLICE_X46Y115) which require the
>> combination of the following symbols into a single SLICEL component"
>> ... (snip - see below)
>> "The clock enable signals don't agree. Please correct the design
>> constraints accordingly."
>>
>> Looking at the SLICEL in PlanAhead, I see six symbols (3 LUTs, 3 FLOPs)
>> and a seventh one that doesn't seem related to the others. Perhaps this
>> is the one "clock enable" referred to in the error message.
>>
>> Also, doubting of the import-into-my-flow procedure, I made another PA
>> project, where I import this same IP into the netlist, and it fails with
>> the same errors.
>>
>> Has anybody seen this error? The answer records show some similar
>> errors, but no explanation on how to work around it/fix it.
>>
>> Thanks in advance,
>> -Pat
>>
>> Error Message:
>> ------------------------------
>> ERROR:Pack:679 - Unable to obey design constraints (LOC=SLICE_X46Y115)
>> which require the combination of the following symbols into a single
>> SLICEL component:
>> LUT symbol
>> "ii_pci_express_interface/application_reg_file/mmux_ctl_reg_o_sig_60_mux000­03
>> 11" (Output Signal =
>> ii_pci_express_interface/application_reg_file/ctl_reg_o_sig_60_mux0000[8])
>> LUT symbol
>> "ii_pci_express_interface/application_reg_file/mmux_ctl_reg_o_sig_60_mux000­03
>> 21" (Output Signal =
>> ii_pci_express_interface/application_reg_file/ctl_reg_o_sig_60_mux0000[9])
>> LUT symbol
>> "ii_pci_express_interface/application_reg_file/mmux_ctl_reg_o_sig_62_mux000­03
>> 11" (Output Signal =
>> ii_pci_express_interface/application_reg_file/ctl_reg_o_sig_62_mux0000[8])
>> FLOP symbol
>> "ii_pci_express_interface/application_reg_file/ctl_reg_o_sig_60_8" (Output
>> Signal = ctl_reg<;60><;8>)
>> FLOP symbol
>> "ii_pci_express_interface/application_reg_file/ctl_reg_o_sig_60_9" (Output
>> Signal = ctl_reg<;60><;9>)
>> FLOP symbol
>> "ii_pci_express_interface/application_reg_file/ctl_reg_o_sig_62_8" (Output
>> Signal = ctl_reg<;62><;8>)
>> The clock enable signals don't agree. Please correct the design
>> constraints accordingly.
> 

Article: 129767
Subject: Re: How to connect FPGA to a ASIC Board?
From: harisrini@gmail.com
Date: Wed, 5 Mar 2008 00:45:06 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 29, 3:21=A0pm, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
> On 27 Feb., 10:42, harisr...@gmail.com wrote:
>
> > Hello Techies,
> > I would like to use an off the shelf FPGA which I would be develpoing
> > to test an ASIC or other FPGA. My questions is,
> > 1. How do we connect the Output of FPGAs as Input of the ASIC and vice
> > versa?
> > 2. The FPGA has to check various protocols like SPI, UART and other
> > things?
>
> > I need to know various methods by which this can be done. Any answers
> > on this will be greatly apprecaited.
>
> Jokes aside: You should first find out, how to connect an asic to an
> asic
> and how to connect an FPGA to an FPGA. Mabye you can deduce the answer
> to that question from that.
>
> Maybe you can find an example design that uses more than one chip and
> see
> how the connections are created.
>
> Here are some examples of how ASICs can be connected:
> 1. Opticalhttp://www.eetimes.com/news/design/showArticle.jhtml;jsessionid=
=3DPA2UO...
>
> 2. AC couplinghttp://www.ece.ncsu.edu/erl/html2/papers/paulf/2003/paulf_20=
03_09_fra...
>
> 3. + 4. + 5.
> 3D stacking
> Free Space Optical Interconnects
> Radio Couplinghttp://www.eetimes.com/conf/iedm/showArticle.jhtml?articleID=
=3D18306693...
>
> Kolja Sulimma

Thanks a lot Kolja.

I really appreciate your answers and will check the kinks you have
provided.

Regards
Hari

Article: 129768
Subject: Bit Error Rate Test
From: nezhate <mazouz.nezhate@gmail.com>
Date: Wed, 5 Mar 2008 01:46:45 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi All,
I want to implement a BERT test on FPGA. Can anyone give or point me
to some good documentation for understanding how BERT test works?
Thanks.

Article: 129769
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: Frai <maybetooparanoid@gmail.com>
Date: Wed, 5 Mar 2008 02:25:53 -0800 (PST)
Links: << >>  << T >>  << A >>
As Xilinx says in their documents, there is no unbreakable security.

I guess if Virtex-4 security is based on the AES algorithm and a
secret key, the way to break the security would be to play with the
implementation of AES in the FPGA, through manipulation of the
encrypted bitstream, probably combining it with a timing attack or any
other sort of attack that could eventually make the AES algorithm work
in the wrong way, exposing some exploits that might be used for
further attacks. This would be cheap and can be easily automated,
although it would probably take long and might fail. If this or any
similar attack were successful, all designs that reside in a Virtex-4
FPGA would be exposed to hackers. Anyway, from the conceptual point of
view, I agree that Virtex-4 level of security is fairly good.

If you don't need in-field reconfiguration of the FPGA, the Actel Pro-
Asic approach to security might be safer than Xilinx Virtex-4, since
it does not let you play with the bitstream. This gives less tools for
hackers to play with, making it very difficult for cheap attacks. Some
expensive and time-consuming attacks might be possible, but this would
only expose one design from one client, rather than all designs
residing in Pro-Asic FPGAs around the world.

Just a thought...

Regards.

Article: 129770
Subject: EDK 9.2 MicroBlaze Tutorial and SDRAM TestApp_memory
From: Olaf <is.er@inter.net>
Date: Wed, 05 Mar 2008 11:39:49 +0100
Links: << >>  << T >>  << A >>
Hi,

I test the EDK 9.2 MicroBlaze Tutorial 
(http://www.xilinx.com/support/techsup/tutorials/92_MB_Tutorial.pdf) for 
my Spartan3e Starter Board Rev.D using XPS 9.2.02i. After the bitsream 
is uploaded, the TestApp_memory is started and got on rs232:

-- Entering main() --
Starting MemoryTest for DDR_SDRAM:
   Running 32-bit test...FAILED!
   Running 16-bit test...FAILED!
   Running 8-bit test...FAILED!
-- Exiting main() --


I know, there was a problem using the MIG for this board. Is this my 
problem? and is it solved now?

Thanks,
Olaf

Article: 129771
Subject: Re: clock distribution accross boards
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Wed, 5 Mar 2008 03:28:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On 4 Mrz., 18:55, John_H <newsgr...@johnhandwork.com> wrote:
> On Mar 3, 8:27 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
> The impedance issues
> you have traveling through the connectors is probably enough to change
> the timing of the 2nd card depending on whether the 3rd or 4th (or
> 10th) cards are plugged in even with appropriate terminations.

That would be OK. I only need repeatability over time and temperature.
Different setups can have different skews. Even two identical setups
can have different skews. The skew only leads to a shift of the
resulting
image. That can be calibrated (or even ignored in many cases)
But if I start accumlating an image today and run the experiment for a
week
any shift in skew during that time will smear the image.

> Buffering is also a problem since every buffer is going to add some
> noise.  With a multiple-output clock buffer, you're still looking at
> channel matching as an issue.
>
> So, consider wandering off to the RF realm.  Generate a sinusoidal
> high-frequency clock.  Rather than using a full level signal you can
> passively split the sinusoid into your desired number of channels at
> the source or on the backplane and terminate each clock *on the
> backplane* and use an impedance-matched front end on your cards so
> they *look* like open circuits to the backplane traces.
> Alternatively, use one backplane-terminated trace for the sinusoidal
> clock and do a better job of making the cards look like open circuits
> to the buffers.  In either case, you have added noise from the clock
> receive buffer on each card.
>
> If your cards are identical, you probably want a way to shut off the
> unused clocks on each destination card.
>
> Each card will have an offset from the first card based on the
> propagation delay across the backplane.  The first card will have a
> different offset still since its clock is received before launching
> onto the backplane.
>
> You have a pretty strenuous requirement but you can eliminate many of
> the troubles by getting rid of reflections and tuning the receivers to
> look like open circuits.
>
> I once made a power splitter for a 155 MHz sinusoid by using 1-ft
> lengths of coax and T-connectors.  Since two 50-ohm terminated cables
> teed together look like 25 ohms and 25 ohms across a 50 ohm, quarter
> wavelength cable looks like 100 ohms to the other side, 2 of these
> pairs look like 50 ohms when teed together.  When properly terminated,
> each signal was 1/4 power.  When I looked at one of the channels on a
> scope and removed one of the other terminations, the scope signal
> didn't get larger, it got smaller!  It was fun to show people and have
> them scratch their heads over the situation.  I had clean sinusoids
> in, clean sinusoids out, and used standard RF techniques to deal with
> stubs and impedances.  Fun stuff.

A standing wave came up during discussion here. The problem is, that
this
is very difficult for varying number of boards. I would rather not
stock ten
completely different, length matched cable setups.

Thank you for your comments.

Kolja

Article: 129772
Subject: PCI Timing Contraints ignored
From: maverick <sheikh.m.farhan@gmail.com>
Date: Wed, 5 Mar 2008 03:32:35 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,
I have a design for a custom made board with Spartan 3 xc3s1000 on it.
There is a SATA controller on the same board. Since this SATA
controller uses PCI interface to communicate to the outer world, I
have used opencores PCI bridge inside FPGA to communicate with SATA
controller. The synthesized design works fine however I do get some
initialization errors at startup. It seems more like a timing problem
to me. When analyzed critically, I observed that many of the timing
constraints are being ignored by the synthesis tool (ISE 7.1i and ISE
9.2i). I have multiple clocks in my design and there are clock
crossing domains. I have marked those domaing and TIGed them in the
UCF. I am suspecting that the problem that I am facing is becuase of
these ignored timing constraints. The portion of the UCF file where
these timings contraints are written is pasted below.
=======================================
INST "AD<0>" TNM = "PCI_AD";
INST "AD<1>" TNM = "PCI_AD";
INST "AD<2>" TNM = "PCI_AD";
INST "AD<3>" TNM = "PCI_AD";
INST "AD<4>" TNM = "PCI_AD";
INST "AD<5>" TNM = "PCI_AD";
INST "AD<6>" TNM = "PCI_AD";
INST "AD<7>" TNM = "PCI_AD";
INST "AD<8>" TNM = "PCI_AD";
INST "AD<9>" TNM = "PCI_AD";
INST "AD<10>" TNM = "PCI_AD";
INST "AD<11>" TNM = "PCI_AD";
INST "AD<12>" TNM = "PCI_AD";
INST "AD<13>" TNM = "PCI_AD";
INST "AD<14>" TNM = "PCI_AD";
INST "AD<15>" TNM = "PCI_AD";
INST "AD<16>" TNM = "PCI_AD";
INST "AD<17>" TNM = "PCI_AD";
INST "AD<18>" TNM = "PCI_AD";
INST "AD<19>" TNM = "PCI_AD";
INST "AD<20>" TNM = "PCI_AD";
INST "AD<21>" TNM = "PCI_AD";
INST "AD<22>" TNM = "PCI_AD";
INST "AD<23>" TNM = "PCI_AD";
INST "AD<24>" TNM = "PCI_AD";
INST "AD<25>" TNM = "PCI_AD";
INST "AD<26>" TNM = "PCI_AD";
INST "AD<27>" TNM = "PCI_AD";
INST "AD<28>" TNM = "PCI_AD";
INST "AD<29>" TNM = "PCI_AD";
INST "AD<30>" TNM = "PCI_AD";
INST "AD<31>" TNM = "PCI_AD";

TIMEGRP "PCI_AD" OFFSET = IN 7 ns BEFORE "CLK_66";
TIMEGRP "PCI_AD" OFFSET = OUT 11 ns AFTER "CLK_66";

INST "CBE<0>" TNM = "PCI_CBE";
INST "CBE<1>" TNM = "PCI_CBE";
INST "CBE<2>" TNM = "PCI_CBE";
INST "CBE<3>" TNM = "PCI_CBE";

TIMEGRP "PCI_CBE" OFFSET = IN 7 ns BEFORE "CLK_66";
TIMEGRP "PCI_CBE" OFFSET = OUT 11 ns AFTER "CLK_66";

NET "DEVSEL" OFFSET = IN 7 ns BEFORE "CLK_66";
NET "DEVSEL" OFFSET = OUT 11 ns AFTER "CLK_66";

NET "FRAME" OFFSET = IN 7 ns BEFORE "CLK_66";
NET "FRAME" OFFSET = OUT 11 ns AFTER "CLK_66";


NET "SATA_GNT" OFFSET = IN 10 ns BEFORE "CLK_66";

NET "IRDY" OFFSET = IN 7 ns BEFORE "CLK_66";
NET "IRDY" OFFSET = OUT 11 ns AFTER "CLK_66";


NET "PAR" OFFSET = IN 7 ns BEFORE "CLK_66";
NET "PAR" OFFSET = OUT 11 ns AFTER "CLK_66";

NET "PERR" OFFSET = IN 7 ns BEFORE "CLK_66";
NET "PERR" OFFSET = OUT 11 ns AFTER "CLK_66";

NET "SATA_REQ" OFFSET = OUT 12 ns AFTER "CLK_66";

NET "SERR" OFFSET = OUT 11 ns AFTER "CLK_66";

NET "STOP" OFFSET = IN 7 ns BEFORE "CLK_66";
NET "STOP" OFFSET = OUT 11 ns AFTER "CLK_66";

NET "TRDY" OFFSET = IN 7 ns BEFORE "CLK_66";
NET "TRDY" OFFSET = OUT 11 ns AFTER "CLK_66";

NET "SATA_IDSEL" OFFSET = IN 7 ns BEFORE "CLK_66";


######################################################################################################


NET "CLK_125" TNM_NET = "CLK_125";
TIMESPEC "TS_CLK_125" = PERIOD "CLK_125" 8 ns HIGH 50 %;
NET "CLK_66" TNM_NET = "CLK_66";
TIMESPEC "TS_CLK_66" = PERIOD "CLK_66" 14 ns HIGH 50 %;
NET "uc_clk" TNM_NET = "uc_clk";
TIMESPEC "TS_uc_clk" = PERIOD "uc_clk" 1000 ns HIGH 50 %;


NET "tx_clk" TNM_NET = "tx_clk";
TIMESPEC "TS_tx_clk" = PERIOD "tx_clk" 40 ns HIGH 50 %;

NET "rx_clk" TNM_NET = "rx_clk";
TIMESPEC "TS_rx_clk" = PERIOD "rx_clk" 40 ns HIGH 50 %;

####################
#	Domains Created
####################
# domain_clk_33
# domain_clk_uc
# domain_clk_adc
# domain_clk_66
# domain_emac_clk_rx
# domain_emac_clk_tx

NET "uc_clk" TNM_NET = "domain_clk_uc";
NET "CLK_66" TNM_NET = "domain_clk_66";
NET "CLK_33" TNM_NET = "domain_clk_33";
#NET "CLK_125" TNM_NET= "domain_clk_125"
NET "CLK_ADC" TNM_NET = "domain_clk_adc";
NET "tx_clk" TNM_NET = "domain_clk_tx";
NET "rx_clk" TNM_NET = "domain_clk_rx";

TIMESPEC "TS_clk_uC_to_clk_66" = FROM "domain_clk_uc" TO
"domain_clk_66"  TIG;
TIMESPEC "TS_clk_uC_to_clk_33" = FROM "domain_clk_uc" TO
"domain_clk_33"  TIG;
#TIMESPEC "TS_clk_uC_to_clk_125" =  FROM "domain_clk_uc" TO
"domain_clk_125" TIG
TIMESPEC "TS_clk_uC_to_clk_adc" = FROM "domain_clk_uc" TO
"domain_clk_adc"  TIG;
TIMESPEC "TS_clk_uC_to_clk_tx" = FROM "domain_clk_uc" TO
"domain_clk_tx"  TIG;
TIMESPEC "TS_clk_uC_to_clk_rx" = FROM "domain_clk_uc" TO
"domain_clk_rx"  TIG;

TIMESPEC "TS_clk_66_to_clk_uc" = FROM "domain_clk_66" TO
"domain_clk_uc"  TIG;
TIMESPEC "TS_clk_66_to_clk_33" = FROM "domain_clk_66" TO
"domain_clk_33"  TIG;
#TIMESPEC "TS_clk_66_to_clk_125" =  FROM "domain_clk_66" TO
"domain_clk_125" TIG
TIMESPEC "TS_clk_66_to_clk_adc" = FROM "domain_clk_66" TO
"domain_clk_adc"  TIG;
TIMESPEC "TS_clk_66_to_clk_tx" = FROM "domain_clk_66" TO
"domain_clk_tx"  TIG;
TIMESPEC "TS_clk_66_to_clk_rx" = FROM "domain_clk_66" TO
"domain_clk_rx"  TIG;

TIMESPEC "TS_clk_33_to_clk_uc" = FROM "domain_clk_33" TO
"domain_clk_uc"  TIG;
TIMESPEC "TS_clk_33_to_clk_66" = FROM "domain_clk_33" TO
"domain_clk_66"  TIG;
#TIMESPEC "TS_clk_33_to_clk_125" =  FROM "domain_clk_33" TO
"domain_clk_125" TIG
TIMESPEC "TS_clk_33_to_clk_adc" = FROM "domain_clk_33" TO
"domain_clk_adc"  TIG;
TIMESPEC "TS_clk_33_to_clk_tx" = FROM "domain_clk_33" TO
"domain_clk_tx"  TIG;
TIMESPEC "TS_clk_33_to_clk_rx" = FROM "domain_clk_33" TO
"domain_clk_rx"  TIG;

TIMESPEC "TS_clk_adc_to_clk_uc" = FROM "domain_clk_adc" TO
"domain_clk_uc"  TIG;
TIMESPEC "TS_clk_adc_to_clk_33" = FROM "domain_clk_adc" TO
"domain_clk_33"  TIG;
#TIMESPEC "TS_clk_adc_to_clk_125"=  FROM "domain_clk_adc" TO
"domain_clk_125" TIG
TIMESPEC "TS_clk_adc_to_clk_66" = FROM "domain_clk_adc" TO
"domain_clk_66"  TIG;
TIMESPEC "TS_clk_adc_to_clk_tx" = FROM "domain_clk_adc" TO
"domain_clk_tx"  TIG;
TIMESPEC "TS_clk_adc_to_clk_rx" = FROM "domain_clk_adc" TO
"domain_clk_rx"  TIG;

TIMESPEC "TS_clk_tx_to_clk_uc" = FROM "domain_clk_tx" TO
"domain_clk_uc"  TIG;
TIMESPEC "TS_clk_tx_to_clk_33" = FROM "domain_clk_tx" TO
"domain_clk_33"  TIG;
#TIMESPEC "TS_clk_tx_to_clk_125" = FROM "domain_clk_tx" TO
"domain_clk_125" TIG
TIMESPEC "TS_clk_tx_to_clk_adc" = FROM "domain_clk_tx" TO
"domain_clk_adc"  TIG;
TIMESPEC "TS_clk_tx_to_clk_66" = FROM "domain_clk_tx" TO
"domain_clk_66"  TIG;
TIMESPEC "TS_clk_tx_to_clk_rx" = FROM "domain_clk_tx" TO
"domain_clk_rx"  TIG;

TIMESPEC "TS_clk_rx_to_clk_uc" = FROM "domain_clk_rx" TO
"domain_clk_uc"  TIG;
TIMESPEC "TS_clk_rx_to_clk_33" = FROM "domain_clk_rx" TO
"domain_clk_33"  TIG;
#TIMESPEC "TS_clk_rx_to_clk_125" = FROM "domain_clk_rx" TO
"domain_clk_125" TIG
TIMESPEC "TS_clk_rx_to_clk_adc" = FROM "domain_clk_rx" TO
"domain_clk_adc"  TIG;
TIMESPEC "TS_clk_rx_to_clk_tx" = FROM "domain_clk_rx" TO
"domain_clk_tx"  TIG;
TIMESPEC "TS_clk_rx_to_clk_66" = FROM "domain_clk_rx" TO
"domain_clk_66"  TIG;


NET "CLK_33_OBUF" TNM_NET = "CLK_33_OBUF";
TIMESPEC "TS_CLK_33_OBUF" = PERIOD "CLK_33_OBUF" 30.03 ns HIGH 50 %;

TIMESPEC "TS_F2F" = FROM "FFS" TO "FFS" 14 ns;



//
*********************************************************************=======================//
This is what I get from ISE 9.2 i during implementation process.

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////


WARNING:Timing:3223 - Timing constraint PATH "TS_U_TO_D_path" TIG;
ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_uC_to_clk_33_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_uC_to_clk_adc_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_uC_to_clk_tx_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_uC_to_clk_rx_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_66_to_clk_adc_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_33_to_clk_uc_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_33_to_clk_66_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_33_to_clk_adc_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_33_to_clk_tx_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_33_to_clk_rx_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_adc_to_clk_uc_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_adc_to_clk_33_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_adc_to_clk_66_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_adc_to_clk_tx_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_adc_to_clk_rx_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_tx_to_clk_uc_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_tx_to_clk_33_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_tx_to_clk_adc_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_tx_to_clk_rx_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_rx_to_clk_uc_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_rx_to_clk_33_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_rx_to_clk_adc_path" TIG; ignored during timing analysis.
WARNING:Timing:3223 - Timing constraint PATH
"TS_clk_rx_to_clk_tx_path" TIG; ignored during timing analysis.
WARNING:Timing:3175 - CLK_66 does not clock data from STOP
WARNING:Timing:3225 - Timing constraint COMP "STOP" OFFSET = IN 7 ns
BEFORE COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3175 - CLK_66 does not clock data to STOP
WARNING:Timing:3225 - Timing constraint COMP "STOP" OFFSET = OUT 11 ns
AFTER COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3175 - CLK_66 does not clock data from DEVSEL
WARNING:Timing:3225 - Timing constraint COMP "DEVSEL" OFFSET = IN 7 ns
BEFORE COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3175 - CLK_66 does not clock data to DEVSEL
WARNING:Timing:3225 - Timing constraint COMP "DEVSEL" OFFSET = OUT 11
ns AFTER COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3175 - CLK_66 does not clock data to IRDY
WARNING:Timing:3225 - Timing constraint COMP "IRDY" OFFSET = OUT 11 ns
AFTER COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3175 - CLK_66 does not clock data to TRDY
WARNING:Timing:3225 - Timing constraint COMP "TRDY" OFFSET = OUT 11 ns
AFTER COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3175 - CLK_66 does not clock data from PERR
WARNING:Timing:3225 - Timing constraint COMP "PERR" OFFSET = IN 7 ns
BEFORE COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3175 - CLK_66 does not clock data to PERR
WARNING:Timing:3225 - Timing constraint COMP "PERR" OFFSET = OUT 11 ns
AFTER COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3175 - CLK_66 does not clock data from PAR
WARNING:Timing:3225 - Timing constraint COMP "PAR" OFFSET = IN 7 ns
BEFORE COMP "CLK_66"; ignored during timing analysis
WARNING:Timing:3175 - CLK_66 does not clock data to PAR
WARNING:Timing:3225 - Timing constraint COMP "PAR" OFFSET = OUT 11 ns
AFTER COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3175 - CLK_66 does not clock data to FRAME
WARNING:Timing:3225 - Timing constraint COMP "FRAME" OFFSET = OUT 11
ns AFTER COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3175 - CLK_66 does not clock data to SERR
WARNING:Timing:3225 - Timing constraint COMP "SERR" OFFSET = OUT 11 ns
AFTER COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3175 - CLK_66 does not clock data to SATA_REQ
WARNING:Timing:3225 - Timing constraint COMP "SATA_REQ" OFFSET = OUT
12 ns AFTER COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3175 - CLK_66 does not clock data from SATA_IDSEL
WARNING:Timing:3225 - Timing constraint COMP "SATA_IDSEL" OFFSET = IN
7 ns BEFORE COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3175 - CLK_66 does not clock data from SATA_GNT
WARNING:Timing:3225 - Timing constraint COMP "SATA_GNT" OFFSET = IN 10
ns BEFORE COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3224 - The clock CLK_66 associated with TIMEGRP
"PCI_AD" OFFSET = IN 7 ns BEFORE COMP "CLK_66"; does not
   clock any registered input components.
WARNING:Timing:3225 - Timing constraint TIMEGRP "PCI_AD" OFFSET = IN 7
ns BEFORE COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3224 - The clock CLK_66 associated with TIMEGRP
"PCI_AD" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; does not
   clock any registered output components.
WARNING:Timing:3225 - Timing constraint TIMEGRP "PCI_AD" OFFSET = OUT
11 ns AFTER COMP "CLK_66"; ignored during timing
   analysis
WARNING:Timing:3224 - The clock CLK_66 associated with TIMEGRP
"PCI_CBE" OFFSET = OUT 11 ns AFTER COMP "CLK_66"; does
   not clock any registered output components.
WARNING:Timing:3225 - Timing constraint TIMEGRP "PCI_CBE" OFFSET = OUT
11 ns AFTER COMP "CLK_66"; ignored during timing
   analysis
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

The question is why the tool is ignoring almost all timing
constraints?
My second question is, OFFSET IN OFFSET OUT contraints are used with
respect to clock which is a global clock and locked to some GCLK pin.
These constraints cannot be applied with respect to clocks which are
genreated inside the FPGA. If I want to run the PCI on 33 MHz, I will
get a divided by 2 version of the 66 MHz clock which is an external
clock in my case. In that case, how would I apply the OFFSET IN OFFSET
out constraints with respect to teh 33 MHz clock? I tried to use FROM
TO constraints, is that OK? for example

INST "FRAME" TNM = "PCI_FRAME";
TIMESPEC "TS_PCI_FRAME0" = FROM "PCI_FRAME" TO "PADS" 11 ns;
TIMESPEC "TS_PCI_FRAME1" = FROM "PADS" TO "PCI_FRAME" 7 ns;

Thanks in advance for reading such a long posting. I hope people out
there have answers to my queries.

Regards
Farhan


Article: 129773
Subject: Re: AES Bitstream Encryption in Virtex-4. How safe it is?
From: jetmarc@hotmail.com
Date: Wed, 5 Mar 2008 03:52:56 -0800 (PST)
Links: << >>  << T >>  << A >>
> 3. What could a hacker do to overcome this protection, other than
> brute-force?

I'd like to add something to this question.

V4 security protects your bitstream.  This is enough when you just
want to avoid the cloning of your product.

If you plan to implement a security application on V4 however, you
will have to go further than just that.  It's quite possible that your
design will leak secrets despite the protected bitstream.

Regards,
Marc

Article: 129774
Subject: Re: my Spartan-4 wishlist
From: rickman <gnuarm@gmail.com>
Date: Wed, 5 Mar 2008 04:39:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 5, 1:01 am, Antti <Antti.Luk...@googlemail.com> wrote:
> On 5 Mrz., 05:45, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Mar 3, 4:42 pm, Antti <Antti.Luk...@googlemail.com> wrote:
>
> > > On 3 Mrz., 22:16, DJ Delorie <d...@delorie.com> wrote:
>
> > > > Antti <Antti.Luk...@googlemail.com> writes:
> > > > > 2) devices packages like Spartan-3E (including QN132 !) or better
> > > > > (microBGA 6x6 mm?)
>
> > > > I keep wondering if there's a market for a few "unbalanced" devices,
> > > > like something with a ton of gates but in a tqfp-64 package.  Or BGA
> > > > packages that only use the two outer rows for signals, for simpler
> > > > board routing.
>
> > > > Likewise, I'd like to see the occasional MCU with a ton of ram and a
> > > > little flash, rather than the other way as it usually is.  Every once
> > > > in a while I need a smart buffer chip :-(
>
> > > oh yes, TQFP48 0.5mm pitch FPGA running from single voltage!
> > > defenetly, but hey thats wish for new Lattice device ;)
>
> > > BTW, Actel QFN132 3 row QFN 0.5mm pitch CAN be used on
> > > 2 layer PCB or even single layer.
>
> > > Antti
>
> > I have not looked very hard at the 132 pin QFN package.  But at 0.5 mm
> > pin pitch, how exactly do you route signals from the middle row out?
> > I guess the pins are actually 1.5 mm pitch on each row for 0.5 mm
> > considering all three rows?  One of the problems I have using 0.65 mm
> > pitch QFPs is that I can't route between the pins.  That is a real
> > PITA.  I sometimes think I would be better off with a wider pitch
> > part, but I'm not sure I can fit them on the board... :^(
>
> its 0.5mm pitch.
> middle row pins can not be used on 2 layer PCB
> only outer and inner row. my application did not
> need much IO so that was sufficient

I guess your first statement above that the part "CAN be used" on a 2
layer board means, there is no power or essential control signals on
the middle row?  So I guess it can be used if you don't mind losing a
huge percentage of the I/O?




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