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 86600

Article: 86600
Subject: Avnet V2P development kit woes
From: "geoffrey wall" <wallge@eng.fsu.edu>
Date: Thu, 30 Jun 2005 14:28:07 -0400
Links: << >>  << T >>  << A >>
Has anyone used avnet's V2P development kit?
if so maybe you could help with some questions i've been struggling with.
I am trying to use the device without using the PPC or EDK.
I am trying to write data over the PCI bridge (a spartan IIe) to a shared 
SRAM, or
data directly from the bridge through to the V2P if possible.

I've been perusing the schematics and VHDL included with the simple memory 
project.
One thing that I still don't understand is how the V2P gives control of the 
shared sram bus to the pci controller.
I can see the signal TRGT_IRQ is a request from the pci for ownership of the 
bus,
but how does the V2P respond to that request and through which I/O pin (to 
the bridge)?
Also I downloaded the schematic for the sram (CY7C1062AV33)
and notice that most of the data/control signals in the sram schematic map 
to the V2P
directly (as far as the labels of the control signals). Some don't. For 
instance the sram has only 19 address pins whereas the V2P
has 24 address pins. Which of these map to the 19 pins on the sram (through 
the Spartan)?
Since there is one memory bus that is connected to SDRAM, Spartan2e, V2P. 
What determines
which device will be written to/read from. Is this simply handled through a 
memory address offset?
Also there are three pins (CE1,2,3) on the sram that seem to map to one 
signal (SRAM_CS_L). Is this correct?
I cant really tell how they are being mapped since the bridge design docs 
dont really explain it.

thanks for your help,

-- 
Geoffrey Wall
Masters Student in Electrical/Computer Engineering
Florida State University, FAMU/FSU College of Engineering
wallge@eng.fsu.edu
Cell Phone:
850.339.4157

ECE Machine Intelligence Lab
http://www.eng.fsu.edu/mil
MIL Office Phone:
850.410.6145

Center for Applied Vision and Imaging Science
http://cavis.fsu.edu/
CAVIS Office Phone:
850.645.2257 



Article: 86601
Subject: Re: Good FPGA for an encryptor
From: "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl>
Date: Thu, 30 Jun 2005 20:56:00 +0200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> Not really complex, but yes, it consumes area.  And since  mroe than 99% 
> of present users don't use it

Maybe they don't use it because they don't have this feature implemented? 
:-)

Cryptography is not the main reason for the existence of bitstream
encryption. It's simply too easy to clone an FPGA-based device.

BTW, is there any export limitation related to the FPGA chips with
embedded bitstream encryption? Most of the cryptographic devices
one can buy without special licenses use very short keys (40 bits or so),
so this would mean that FPGAs are not considered to be cryptographic
devices or they are, but they can be crackd by the NSA guys
(implemented using nonlinear keyspaces, internal secret keys, key
escrow systems and many other sophisticated ways.). What is the position
of the US government on this subject? (of course I would like to know
only the publically available facts -- I don't know much about this 
interesting
issue).

    Best regards
    Piotr Wyderski


Article: 86602
Subject: LogiCore: SGMII autonegotiation
From: tom.brooks@intransa.com
Date: 30 Jun 2005 12:16:34 -0700
Links: << >>  << T >>  << A >>
All,

I have instatiated the SGMII block into my design and am attempting to
get it to autonegotiate.  It sends out the /C1/ and /C2/ ordered sets
indefinetly with Config_Reg values equal to zero.  I can never get it
to send the correct Config_Reg values.

Has anyone had this issue?

Thanks...


Article: 86603
Subject: Re: Good FPGA for an encryptor
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Thu, 30 Jun 2005 19:17:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <da121k$ke1@cliff.xsj.xilinx.com>,
Austin Lesea  <austin@xilinx.com> wrote:
>Nick,
>
>No one has asked for what you mentioned.  Probably for the reasons you 
>mention.

It seems strange that they haven't asked, because both of these would
be "Big Deal" improvements to what is very public knowledge and
inference:

The ability to load a NEW encryption key from within the FPGA is a
very powerful feature: it allows a bunch of devices who's bitfile is
initially encrypted with a common key to all customize themselves:
The first time they are powered on by the customer, the device
generates its new key, stores it in the key register, reencrypts the
bitfile, and is happy.

Now each instance has its own unique random key, that it can use to
protect its own particular bitfile and secrets unique to that bitfile
(other cryptokeys).  Instances could also generate NEW keys giving
some interesting/possible properties to generate forward security.

Without this feature, you can only really do this under very
restricted conditions (initial customer poweron) because it has to go
in the clear over the JTAG pins.  But with this feature, you can do it
all the time, because an attacker who can monitor the "cleartext"
wires WITHIN the FPGA already has probably broken the system.



Partial reconfiguration when encryption is active is FAR more
dangerous, as if you could trick the initial config to allow an
attacker config to be loaded, all bets are off.  But, OTOH, it would
be a very, VERY big deal to the JTRS (Joint Tactical Radio System)
crowd, as they are going to want to reconfigure large modules at
runtime to do the software-defined radio which is the keystone of the
system, yet also probably want the bitfile encryption over everything.


>My biggest problem is that whatever we do for security needs to be so 
>incredibly well thought through, that adding something in the next 
>generation becomes a real issue.  An added feature may bring on a whole 
>new set of issues that have to be thought through again!

Yeup.  Rekeying (WRITE only) from within the configuration is probably
"not bad" on this.  It needs to be thought through, but its pretty
easy to wedge the device when rekeying (so it needs to be
blanked/restarted), but pretty hard to un-safe the device.

But allowing partial reconfig within the encrypted domain, even
limited from within the FPGA, opens up a huge thorny set of potential
issues.  These issues would come up in particular configurations, but
as Xilinx has to provide a lot of guidance to customers already on
partial config.


One question: Could you go to the spooks and guys with jitters about
JTRS with "Here is what the open community THINKS that you want but
are unwilling to say and why" and get a "yes" or "no" answer out of
them?

-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 86604
Subject: Re: Good FPGA for an encryptor
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Thu, 30 Jun 2005 19:22:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <da1f83$4qs$1@news.dialog.net.pl>,
Piotr Wyderski <wyderskiREMOVE@ii.uni.wroc.pl> wrote:

>BTW, is there any export limitation related to the FPGA chips with
>embedded bitstream encryption? Most of the cryptographic devices
>one can buy without special licenses use very short keys (40 bits or so),
>so this would mean that FPGAs are not considered to be cryptographic
>devices or they are, but they can be crackd by the NSA guys
>(implemented using nonlinear keyspaces, internal secret keys, key
>escrow systems and many other sophisticated ways.). What is the position
>of the US government on this subject? (of course I would like to know
>only the publically available facts -- I don't know much about this 
>interesting
>issue).

The crypto restrictions have largely gone away.  Now its basically you
can't sell serious crypto to the bad-actor countries.

-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 86605
Subject: Re: Cannot find net in ucf, but it's there....
From: "Andy Peters" <Bassman59a@yahoo.com>
Date: 30 Jun 2005 12:46:40 -0700
Links: << >>  << T >>  << A >>
zoinks@mytrashmail.com wrote:
> I already found the problem:
>
> apparentlythe ucf files are case sensitive, and I forgot a cap
> d'oh!

Yep -- That's one reason why it's usually convenient to start out with
no constraints and run the tools once.  Then back-annotate the pin list
into the .ucf.  Then you'll have all of the pins and their
(assigned-by-the-tools locations.  You can then go in with a text
editor and change the pin locations, or use the GUI to do it.

-a


Article: 86606
Subject: Re: Good FPGA for an encryptor
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 30 Jun 2005 13:01:11 -0700
Links: << >>  << T >>  << A >>
Piotr,

There are no restrictions on Xilinx in selling or shipping the AES 256 
bit decryptor in V4 (or any restrictions of the 3DES in VII, VII Pro, 
VII Pro-X).

We are shipping an implimentation of the decryptor which is based on the 
NIST standard (c code available on line).  Since the AES 256 is a 
standard, there are no restrictions on export.

For a very short time, back when we introduced Virtex II, there were 
restrictions against shipping 3DES encryption to certain countries. 
This meant that we could not ship our software to those countries (as it 
has the encryption part coded into it).  That restriction was later 
removed before we had to take any actions.

Austin



Piotr Wyderski wrote:

> Austin Lesea wrote:
> 
>> Not really complex, but yes, it consumes area.  And since  mroe than 
>> 99% of present users don't use it
> 
> 
> Maybe they don't use it because they don't have this feature 
> implemented? :-)
> 
> Cryptography is not the main reason for the existence of bitstream
> encryption. It's simply too easy to clone an FPGA-based device.
> 
> BTW, is there any export limitation related to the FPGA chips with
> embedded bitstream encryption? Most of the cryptographic devices
> one can buy without special licenses use very short keys (40 bits or so),
> so this would mean that FPGAs are not considered to be cryptographic
> devices or they are, but they can be crackd by the NSA guys
> (implemented using nonlinear keyspaces, internal secret keys, key
> escrow systems and many other sophisticated ways.). What is the position
> of the US government on this subject? (of course I would like to know
> only the publically available facts -- I don't know much about this 
> interesting
> issue).
> 
>    Best regards
>    Piotr Wyderski
> 

Article: 86607
Subject: Re: Good FPGA for an encryptor
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 30 Jun 2005 13:06:38 -0700
Links: << >>  << T >>  << A >>
Nicholas,

Oh yes, I can play the game to find out.

Right now, the JTRS crowd has decided to use a software uP, and not use 
reconfiguration of an FPGA.

Seems that they already have all the c code, and they can't risk taking 
the time to convert it.

They won't meet the power budget, they won't meet the size budget, and 
they won't meet the eventual requirements (as the uP is far too weak to 
do any of the newer and more powerful waveforms which are not required 
in the first phase of JTRS).  They still need an FPGA for glue and some 
acceleration even with the uP.

It is painful when you see how your tax dollars get mis-spent, first hand.

Austin

Nicholas Weaver wrote:

> In article <da121k$ke1@cliff.xsj.xilinx.com>,
> Austin Lesea  <austin@xilinx.com> wrote:
> 
>>Nick,
>>
>>No one has asked for what you mentioned.  Probably for the reasons you 
>>mention.
> 
> 
> It seems strange that they haven't asked, because both of these would
> be "Big Deal" improvements to what is very public knowledge and
> inference:
> 
> The ability to load a NEW encryption key from within the FPGA is a
> very powerful feature: it allows a bunch of devices who's bitfile is
> initially encrypted with a common key to all customize themselves:
> The first time they are powered on by the customer, the device
> generates its new key, stores it in the key register, reencrypts the
> bitfile, and is happy.
> 
> Now each instance has its own unique random key, that it can use to
> protect its own particular bitfile and secrets unique to that bitfile
> (other cryptokeys).  Instances could also generate NEW keys giving
> some interesting/possible properties to generate forward security.
> 
> Without this feature, you can only really do this under very
> restricted conditions (initial customer poweron) because it has to go
> in the clear over the JTAG pins.  But with this feature, you can do it
> all the time, because an attacker who can monitor the "cleartext"
> wires WITHIN the FPGA already has probably broken the system.
> 
> 
> 
> Partial reconfiguration when encryption is active is FAR more
> dangerous, as if you could trick the initial config to allow an
> attacker config to be loaded, all bets are off.  But, OTOH, it would
> be a very, VERY big deal to the JTRS (Joint Tactical Radio System)
> crowd, as they are going to want to reconfigure large modules at
> runtime to do the software-defined radio which is the keystone of the
> system, yet also probably want the bitfile encryption over everything.
> 
> 
> 
>>My biggest problem is that whatever we do for security needs to be so 
>>incredibly well thought through, that adding something in the next 
>>generation becomes a real issue.  An added feature may bring on a whole 
>>new set of issues that have to be thought through again!
> 
> 
> Yeup.  Rekeying (WRITE only) from within the configuration is probably
> "not bad" on this.  It needs to be thought through, but its pretty
> easy to wedge the device when rekeying (so it needs to be
> blanked/restarted), but pretty hard to un-safe the device.
> 
> But allowing partial reconfig within the encrypted domain, even
> limited from within the FPGA, opens up a huge thorny set of potential
> issues.  These issues would come up in particular configurations, but
> as Xilinx has to provide a lot of guidance to customers already on
> partial config.
> 
> 
> One question: Could you go to the spooks and guys with jitters about
> JTRS with "Here is what the open community THINKS that you want but
> are unwilling to say and why" and get a "yes" or "no" answer out of
> them?
> 

Article: 86608
Subject: Re: Small FPGA
From: "jai.dhar@gmail.com" <jai.dhar@gmail.com>
Date: 30 Jun 2005 13:34:43 -0700
Links: << >>  << T >>  << A >>
Why not a small microcontroller like a PIC 10F series?


Article: 86609
Subject: Re: Good FPGA for an encryptor
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Thu, 30 Jun 2005 20:34:57 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <da1jce$1cr1@cliff.xsj.xilinx.com>,
Austin Lesea  <austin@xilinx.com> wrote:
>Nicholas,
>
>Oh yes, I can play the game to find out.
>
>Right now, the JTRS crowd has decided to use a software uP, and not use 
>reconfiguration of an FPGA.
>
>Seems that they already have all the c code, and they can't risk taking 
>the time to convert it.
>
>They won't meet the power budget, they won't meet the size budget, and 
>they won't meet the eventual requirements (as the uP is far too weak to 
>do any of the newer and more powerful waveforms which are not required 
>in the first phase of JTRS).  They still need an FPGA for glue and some 
>acceleration even with the uP.

They want to do a uP version of all those standards?  ICK.  CDMA alone
is a pain in da butt (and one of the standards supposed to be
supported: JTRS radios include cellphone functionality too), let alone
the UWB stuff they want to do.

>It is painful when you see how your tax dollars get mis-spent, first hand.

It would actually be cool to do the "Calm" project as an alternative:
A multiband software radio with all the cool crypto stuff in an FPGA
platform, just to show how superior FPGAs are for stuff like that.  :)
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 86610
Subject: Re: Coverting .mcs file to .bit file
From: James Morrison <spam1@stratforddigital.ca>
Date: Thu, 30 Jun 2005 16:57:56 -0400
Links: << >>  << T >>  << A >>
On Thu, 2005-06-30 at 06:56 -0700, Shai wrote:
> Hello,
> 
> Is there any way of converting an .mcs file into a bit file....in
> Xilinx FPGAs

If you have a board with PROM and FPGA then program the mcs file into
the PROM, cycle the power to the board to load the FPGA, and then read
the design out of the FPGA using Impact and save the result as your bit
file.

James.


Article: 86611
Subject: Re: ip core supply
From: "Minimum" <brahms_view@yahoo.it>
Date: 30 Jun 2005 14:38:05 -0700
Links: << >>  << T >>  << A >>
if no interest,u can ignore this topic.


Article: 86612
Subject: Direct audio output from FPGA pins
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Thu, 30 Jun 2005 23:52:21 +0200
Links: << >>  << T >>  << A >>
I'm playing around with sigma-delat ADC and DAC for audio. It's amazing
how good this works without any active components. Just Rs and Cs.

The question now is: Can I hook a speaker direct to the output pins of
an FPGA?

The idea is to omit any passive components as the speaker acts as
low-pass filter and to use two pins, feeding one with the inverted
sigma-delta stream (or PDM), to build a bridge amplifier (class D?).
With 3V3 output swing this should result (on an 8 Ohm speaker) in an
output power of:

    Peff = Ueff^2/R = (Up/sqrt(2))^2/R =
         = (3.3V/2*sqrt(2)/sqrt(2))^2/8Ohm = 340mW

First question: Is the multiplication with sqrt(2) correct? The idea
is that it is a class D amplifier with rectangular output resulting
in a sine wave that is sqrt(2) times higher than Up of the square wave.

Second question: Is the inductive load from the speaker an issue for
the output drivers?

Martin



Article: 86613
Subject: Re: Direct audio output from FPGA pins
From: "Peter C. Wallace" <pcw@freeby.mesanet.com>
Date: Thu, 30 Jun 2005 16:06:13 -0700
Links: << >>  << T >>  << A >>
On Thu, 30 Jun 2005 14:52:21 -0700, Martin Schoeberl wrote:

> I'm playing around with sigma-delat ADC and DAC for audio. It's amazing
> how good this works without any active components. Just Rs and Cs.
> 
> The question now is: Can I hook a speaker direct to the output pins of
> an FPGA?
> 
> The idea is to omit any passive components as the speaker acts as
> low-pass filter and to use two pins, feeding one with the inverted
> sigma-delta stream (or PDM), to build a bridge amplifier (class D?).
> With 3V3 output swing this should result (on an 8 Ohm speaker) in an
> output power of:
> 
>     Peff = Ueff^2/R = (Up/sqrt(2))^2/R =
>          = (3.3V/2*sqrt(2)/sqrt(2))^2/8Ohm = 340mW
> 
> First question: Is the multiplication with sqrt(2) correct? The idea is
> that it is a class D amplifier with rectangular output resulting in a
> sine wave that is sqrt(2) times higher than Up of the square wave.
> 
> Second question: Is the inductive load from the speaker an issue for the
> output drivers?
> 
> Martin
 
I think the thing you have forgotten is the output driver resistance (or
drive current capability). Peak current would be ~400 mA! Would probably work
ok with about 20 outputs in parallel... 

(or one of those little PMOS/NMOS SOT23 MOSFET pairs)

Peter Wallace

Article: 86614
Subject: Re: Direct audio output from FPGA pins
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 01 Jul 2005 11:47:29 +1200
Links: << >>  << T >>  << A >>
Martin Schoeberl wrote:
> I'm playing around with sigma-delat ADC and DAC for audio. It's amazing
> how good this works without any active components. Just Rs and Cs.
> 
> The question now is: Can I hook a speaker direct to the output pins of
> an FPGA?
> 
> The idea is to omit any passive components as the speaker acts as
> low-pass filter and to use two pins, feeding one with the inverted
> sigma-delta stream (or PDM), to build a bridge amplifier (class D?).
> With 3V3 output swing this should result (on an 8 Ohm speaker) in an
> output power of:
> 
>     Peff = Ueff^2/R = (Up/sqrt(2))^2/R =
>          = (3.3V/2*sqrt(2)/sqrt(2))^2/8Ohm = 340mW
> 
> First question: Is the multiplication with sqrt(2) correct? The idea
> is that it is a class D amplifier with rectangular output resulting
> in a sine wave that is sqrt(2) times higher than Up of the square wave.
> 
> Second question: Is the inductive load from the speaker an issue for
> the output drivers?
> 
> Martin

TI have a range of Class D amplifiers, so their data gives good info
on Filterless Class D.

You are pushing things a little doing this straight into the FPGA [ I 
hope it's a cheap one :) ]
If you work 3.3V / 8 Ohms, that's 412mA, into a bridge load, you are 
asking for - from a single IO pin.... ?!

Possibly on a whole port/bridge side ?

-jg


Article: 86615
Subject: Re: Direct audio output from FPGA pins
From: "Peter Alfke" <peter@xilinx.com>
Date: 30 Jun 2005 16:57:22 -0700
Links: << >>  << T >>  << A >>
So you would have one pin driving a High into the 8 Ohm speaker, while
the other pin sinks a Low.
No pin would ever be negative, but you have the drive impedance plus
the sink impedance in series with the speaker. Each of the three might
be around 8 Ohm, for a total of 24 Ohm, and a peak current closer to
100 mA.
If you pick the strongest output standard, you still will have limited
aplitude.
I agree with the suggestion of a low-cost Clas-D amplifier instead.
Peter Alfke


Article: 86616
Subject: Re: ip core supply
From: Jeremy Stringer <jeremy@_NO_MORE_SPAM_endace.com>
Date: Fri, 01 Jul 2005 12:25:53 +1200
Links: << >>  << T >>  << A >>
Minimum wrote:
> if no interest,u can ignore this topic.

His point is that there very likely will *be* no interest.

IANAL, but it would seem pretty clean that any company using stolen IP 
like this could be in a world of legal hurt.

Have you considered that in addition to that, people belonging to the 
companies from which the IP originated may well also read this newsgroup?

Jeremy

Article: 86617
Subject: Cyclone Board with // LVDS lines
From: "Keith Williams" <e_s_p_i_a_n_@insightbb.com>
Date: Fri, 01 Jul 2005 03:22:59 GMT
Links: << >>  << T >>  << A >>
Hi!

I've already googled and dug through several online lists of FPGA boards,
but haven't found what I'm looking for, yet.

I'm needing a Cyclone board that has at least 32 LVDS I/O pins available
(and terminated). With at least one PLL available to be driven from an
external source.

Target price of less than $500 U.S.

Thanks,

Keith



Article: 86618
Subject: Re: PPC405 Question
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Thu, 30 Jun 2005 21:40:42 -0700
Links: << >>  << T >>  << A >>
The chapter on Semaphore Synchronization on pg. 128 and Appendix D on 
pg. 537ff of http://www.xilinx.com/bvdocs/userguides/ppc_ref_guide.pdf
provide detailed information about lwarx and stwcx.

lwarx and stwcx. are low-level assembly instructions always operating on 
a single word. They are used to implement higher-level constructs like 
semaphores or critical section that can then be used to atomically 
access larger sections of memory. Appendix D lists some examples.

- Peter



Gladiator wrote:
> Hi,
> 
> I am working with the PPC405 processor on a Virtex2Pro board and was
> wondering if it's possible to access the reservation granule where
> reservations for the semaphore instructions <i>lwarx</i> and
> <i>stwcx</i> are set?
> 
> Your help will be greatly appreciated
> 
> Robin Maleche
> 


Article: 86619
Subject: Re: Clock buffering in VirtexE FPGA
From: "vssumesh" <vssumesh_asic@yahoo.com>
Date: 30 Jun 2005 21:50:18 -0700
Links: << >>  << T >>  << A >>
This will work only if the prtPUSH_BUTTON1 is not an external clock.
But if we are using the edge of this signal the tool will assume that
it is a clock signal and assigns the BUFGP buffer for that this will
conflict with the .ucf constarins and will give error at the time of
mapping.
We must use the .ucf as you suggested but then there should be a way to
disable the clock buffereing at the time of synthesize.


Article: 86620
Subject: Re: Clock buffering in VirtexE FPGA
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 30 Jun 2005 22:55:22 -0700
Links: << >>  << T >>  << A >>
Using a push button as a clock input to modern fast logic is an
invitation to disaster. The contact bounce will play havoc with your
design.
Peter Alfke

vssumesh wrote:
> This will work only if the prtPUSH_BUTTON1 is not an external clock.
> But if we are using the edge of this signal the tool will assume that
> it is a clock signal and assigns the BUFGP buffer for that this will
> conflict with the .ucf constarins and will give error at the time of
> mapping.
> We must use the .ucf as you suggested but then there should be a way to
> disable the clock buffereing at the time of synthesize.


Article: 86621
Subject: Re: Cannot find net in ucf, but it's there....
From: Rudolf Usselmann <russelmann@hotmail.com>
Date: Fri, 01 Jul 2005 13:19:46 +0700
Links: << >>  << T >>  << A >>
Andy Peters wrote:

> zoinks@mytrashmail.com wrote:
>> I already found the problem:
>>
>> apparentlythe ucf files are case sensitive, and I forgot a cap
>> d'oh!
> 
> Yep -- That's one reason why it's usually convenient to start out with
> no constraints and run the tools once.  Then back-annotate the pin list
> into the .ucf.  Then you'll have all of the pins and their
> (assigned-by-the-tools locations.  You can then go in with a text
> editor and change the pin locations, or use the GUI to do it.
> 
> -a



Another small hint:

if you are trying to constrain internal nets, make sure you
did not select the flatten option. If your design is flattened,
the hierarchy and net names will change and will be renamed.

Regards, 
rudi
=============================================================
Rudolf Usselmann,  ASICS World Services,  http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis
****** Certified USB 2.0 HS OTG and HS Device IP Cores ******

Article: 86622
Subject: Re: Avnet V2P development kit woes
From: Jeremy Stringer <jeremy@_NO_MORE_SPAM_endace.com>
Date: Fri, 01 Jul 2005 18:31:07 +1200
Links: << >>  << T >>  << A >>
geoffrey wall wrote:
> Has anyone used avnet's V2P development kit?

Nope.

> Since there is one memory bus that is connected to SDRAM, Spartan2e, V2P. 
> What determines
> which device will be written to/read from. Is this simply handled through a 
> memory address offset?

My guess is that you would have an address decoder - this is the 
standard way - for instance, given 4 equal size memory spaces, you can 
drive a chip select off the top two bits, ie

00xxxxxxxxxxxxxxxxxxxxxxxxxxxxx = Device 1
01xxxxxxxxxxxxxxxxxxxxxxxxxxxxx = Device 2
10xxxxxxxxxxxxxxxxxxxxxxxxxxxxx = Device 3
11xxxxxxxxxxxxxxxxxxxxxxxxxxxxx = Device 4

> Also there are three pins (CE1,2,3) on the sram that seem to map to one 
> signal (SRAM_CS_L). Is this correct?

Likely - often these devices have multiple chip enables, some 
active-high and some active-low, so that you can bank a few of them up 
with a few bits of copper, rather than having to have an extra address 
decoder.  You'd have to check the datasheet for the ram, and see if the 
SRAM_CS_L signal is driven out as-is to the RAM (check if it matches).

> I cant really tell how they are being mapped since the bridge design docs 
> dont really explain it.

You might want to try simulating the design, to see how it works - build 
a board level testbench and a simple PCI stimulator, and see what it 
does.  This might be an easy way of better understanding the design. 
Often the memory manufacturers have models of their chips (in verilog, 
vhdl or other format), which may help.  I suspect you may have to find 
some further documentation as well.  Are there other sample designs? 
You may be able to compare them to glean more information.

Jeremy

Article: 86623
Subject: Re: V4 and DDR2 666
From: Jeremy Stringer <jeremy@_NO_MORE_SPAM_endace.com>
Date: Fri, 01 Jul 2005 19:01:28 +1200
Links: << >>  << T >>  << A >>
fortiz80@gmail.com wrote:
> Hi all,
> 
> Xilinx has announced support for DDR2 up to 533 MHz. Are there any
> physical limitations that won't allow higher frequencies to be used?

Umm..  That's 533M*bit* (267MHz).

You could try:
a) Working through the app notes (I know at least some of them have 
timing budget calculations)
b) Attempting to build a simple design using something like the memory 
interface generator, and targeting it to a specific chip.

These might provide you with more information..  My guess would be that 
losing 350 ps odd off the timing budget would be the killer - the 
question of why could probably be answered by examining it in the above 
fashion.

I'd be curious myself actually - particularly if you ran through these 
and came to the conclusion that it could be done...

Jeremy

Article: 86624
Subject: Re: init ProASIC3 Ram from spi
From: "Neill A" <neilla@ewst.co.uk>
Date: 1 Jul 2005 00:12:39 -0700
Links: << >>  << T >>  << A >>
Jedi wrote:
> Hello...
>
> Wasn't there once an application note on Actel.com
> for initialising internal RAM from an SPI memory?
>
>
> rick

Yes, and it is still there:

http://www.actel.com/documents/EmbeddedSRAMInit_AN.pdf




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