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 95650

Article: 95650
Subject: Re: help:dual-edge flip-flop possible using Verilog?
From: "Slurp" <slip@slap.slop>
Date: Wed, 25 Jan 2006 08:11:49 -0000
Links: << >>  << T >>  << A >>

"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:1138164692.600244.310200@g14g2000cwa.googlegroups.com...
> The circuit is reliable, although the generated pulse width is
> determined by gate delays. But it is self-compensating, since the clock
> pulse will not end until the flip-flop has toggled. It's kind of
> clever, if I am allowed to say so...
> Peter Alfke
>


*blush* gee thanks, I first put forward this idea in 1973 to a UK 
electronics mag, I believe I received about 150 for the article way back 
then!

Slurp 



Article: 95651
Subject: Re: Webpack 8.1i size
From: "GEO" <v2geo@hotpop.com>
Date: 25 Jan 2006 01:08:48 -0800
Links: << >>  << T >>  << A >>
When 71i came out, I requested Xilinx, via google groups, to reconsider
the download management strategy. Unfortunately it was not
acknowledged.

When trying to download 81i, I noticed that support is only through
xilinx web site. I contacted Xilinx support via web today, and hope to
hear from them soon!


Article: 95652
Subject: encryption
From: yusufilker@gmail.com
Date: 25 Jan 2006 01:18:15 -0800
Links: << >>  << T >>  << A >>
hi,

I would like to implement a secure channel over an unsecure medium.

mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A
conv =>voice
analog           Host A/D     digital
                 "other side"

I do not want to encrypt data at the device's digital side
because it is unsecure, and I dont know how to interfere digital data
I don not have access to embedded software, source code etc.
(maybe just after host A/D converter and emulating Host A/D converter
to device,,,maybe) and
every encryption algorithm implemented here can be broken at the other
side I guess.

What I want to do is ;

mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown
comm link
analog              ecrypt + scramble digital data          voice like
encrypted signal

The Device will see voice freq signal and will transmit them through
channel as if they are real voices.
At this point adding some noise may help a lot.
a little bit noise may fool attackers but human still can understand
what is said.


questions:

what is possible weakness of this system?
I am sure it can be still broken but
how easy to break it?
What kind of tools/approaches  "they" are using ?
Is cpld enough for general data encryption?
(data is human voice so  8Kbps.)
encrytion should be easy so the hacking also....
they: whatever you say  

thanks 


yusuf


Article: 95653
Subject: So what happened to JHDLBits?
From: ptkwt@aracnet.com (Phil Tomson)
Date: 25 Jan 2006 09:28:04 GMT
Links: << >>  << T >>  << A >>
In another thread we've been talking about creating some open source tools for 
parsing and manipulating XDL.  The motivation being that since bitstreams are 
closed, working XDL might just be the next best thing.

But then someone brought up the fate of JHDLBits: apparently the prjoject was 
squashed by Xilinx.  Does anyone have any details about what happened?  If 
someone succeeded in developing an open source ecosystem of tools built around 
XDL, would that project also suffer the same fate?  (It would be nice to know 
before investing much time and effort in developing tools around XDL)

I found a Master's thesis related to JHDLBits and it sounds eerily similar to 
the motivation for developing XDL tools, here's the title and abstract:

JHDLBits: An Open-Source Model for FPGA Design Automation 
Alexandra Vanessa Poetter 
Abstract 
Todays Field Programmable Gate Array (FPGA) research community could use an 
extensi- 
ble tool flow enabling designers to examine new algorithms and new methods of 
interacting 
with FPGA configurations. One such flow is JHDLBits, which integrates two 
prominent 
FPGA design environments: JHDL and JBits. JHDLBits offers the low-level access 
and 
control provided by JBits with the high-level structural circuit design of 
JHDL. Further- 
more, the JHDLBits flow provides greater control of resource manipulation, 
placement, and 
routing, and gives researchers a sandbox to explore advanced interactions with 
FPGA config- 
urations. This thesis presents the overall architecture of the open-source 
JHDLBits pro ject. 
Details are provided on how the core components  JHDL, JBits3 for Virtex-II, 
the ADB 
connectivity database, and VTsim, a Virtex-II device simulator  are linked 
together to 
provide an integrated design environment. Strategies and philosophies of the 
open source 
movement are also examined to successfully establish the support for and 
involvement of the 
FPGA research community throughout the JHDLBits open source endeavor.

The thesis can be found here:
 http://rubyurl.com/wvm

Phil

Article: 95654
Subject: Re: help:dual-edge flip-flop possible using Verilog?
From: "yyqonline" <yyqonline@gmail.com>
Date: 25 Jan 2006 01:31:31 -0800
Links: << >>  << T >>  << A >>
Thanks
I have done some work using this circuit and it seems to function well.
Since the clk is 640Khz, the requirement of clk_min should be
satisfied.
I have another two aspects:
*the width of pulses generated by this circuit, and
*the delay caused by this circuit
whether these two are safe when implementing the design by asic tech?

As a learner with little experience, every reply give me great help and
will be highly appreciated.


Article: 95655
Subject: Re: help:dual-edge flip-flop possible using Verilog?
From: "yyqonline" <yyqonline@gmail.com>
Date: 25 Jan 2006 02:02:04 -0800
Links: << >>  << T >>  << A >>
Thanks for putting forward so good a circuit, which is one of the most
wonderful design I have ever learned!


Article: 95656
Subject: Re: help:dual-edge flip-flop possible using Verilog?
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 25 Jan 2006 10:11:44 -0000
Links: << >>  << T >>  << A >>
"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:1138164692.601427.310190@g14g2000cwa.googlegroups.com...
> The circuit is reliable, although the generated pulse width is
> determined by gate delays. But it is self-compensating, since the clock
> pulse will not end until the flip-flop has toggled. It's kind of
> clever, if I am allowed to say so...
> Peter Alfke
>
Hi Peter,
Clever the circuit may be, but I'm concerned that it may not be a good idea 
to suggest this circuit to a guy who appears to be just starting out using 
FPGAs. I agree it's a quick and easy answer to get him going, but he should 
be made aware of the pitfalls of this circuit. For one, how will the timing 
analyser cope with this? Also, how does he control the skew between input 
and output? In your article you rightly say "This asynchronous circuit ... 
should only be used as a tool of last resort.", so it should be in CAF 
threads as well!
I'd strongly suggest the OP use a DCM or PLL or whatever his FPGA vendor 
supplies to double his clock. He should wait until he's really desperate 
before resorting to asynchronous tricks, no matter how clever they are!
Just IMHO!
Cheers, Syms.
p.s. If the goal is to achieve a frequency doubled clocking signal, would 
the "six easy pieces" asynchronous circuit be improved by inserting a GBUF 
at the output of the XNOR gate? 



Article: 95657
Subject: Re: encryption
From: yusufilker@gmail.com
Date: 25 Jan 2006 02:25:55 -0800
Links: << >>  << T >>  << A >>
I forgot to tell.
Of course at the other side of the link there will be a decryption unit
to convert analog encrypted voice into real voice.

Due to word wrap some text are not aligned in previous post . sorry..

yusuf


Article: 95658
Subject: Re: Xilinx Partial Reconfiguration add-on module
From: Javier Castillo <javier.castillo@urjc.es>
Date: Wed, 25 Jan 2006 11:58:53 +0100
Links: << >>  << T >>  << A >>
We are trying to make partial reconf with Virtex4 but ISE 8.1SP1 fails
during the assembly phase. We want to test that "add-on module" but
our copy of ISE is provided by EuroPractice for universities and we
dont know how to contact with a FAE. Any suggestion?

Javier

On Sat, 21 Jan 2006 14:55:11 +0100, "Antti Lukats"
<antti@openchip.org> wrote:

>"GaLaKtIkUsT" <taileb.mehdi@gmail.com> schrieb im Newsbeitrag 
>news:1137847265.882963.14050@o13g2000cwo.googlegroups.com...
>> Xilinx promised for ISE8.1i a "free add-on module for partial
>> reconfiguration". But I still don't see it.
>> Can anybody give me some precisions?
>>
>> Mehdi
>>
>
>ASFAIK it is only available upon request from FAE, not freely downloadable
>
>antti 
>

Article: 95659
Subject: Re: LVDS Input buffer in VHDL (ISE)
From: "Roger" <enquiries@rwconcepts.co.uk>
Date: Wed, 25 Jan 2006 11:17:18 GMT
Links: << >>  << T >>  << A >>
Thanks everyone. This has been useful for me and others.

Roger.

"Brian Davis" <brimdavis@aol.com> wrote in message 
news:1138160016.066348.150980@f14g2000cwb.googlegroups.com...
> Roger wrote:
>>
>> Thanks, this was really useful.
>>
> Glad that worked.
>
>> I'm using version 7.1 of ISE
>
> And, now I know what to change when I switch to 7.1 !
>
> I haven't updated from 6.3 yet at home to create a test case,
> but I've had problems with attributes not sticking to diff. buffers
> before ( especially the _DIFF_OUT variants )
>
>>
>> I don't know why and probably never will but it allows me to
>> progress with the design now.
>>
> I think Xilinx is getting away from the named suffixes for the
> newer families, so perhaps they broke something in the tool flow.
>
> Brian
> 



Article: 95660
Subject: Re: How to handle the "gate count" issue?
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Wed, 25 Jan 2006 11:21:18 -0000
Links: << >>  << T >>  << A >>
Usually I will temper the use of "gates" by saying equivalency can be a 
factor of x2 or x 1/2 out. A better FPGA metric for Xilinx and Altera is 
number of LUTs and Flops but even here there are things to muddy the 
comparision. The technologies that are not SRAM based also don't compare 
easily on these metrics.

John Adair
Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 PCI-E 
Development Board.
http://www.enterpoint.co.uk


"int19h" <tirath@replacethispartwithmynickname.com> wrote in message 
news:43d6d3f8@dnews.tpgi.com.au...
> Hi all,
>
> I need some advice on how to treat the "equivalent gate count" issue. I 
> have to make a presentation on something soon, where FPGAs are the initial 
> foundation of the project, and I anticipate having to provide some 
> correlation between "slices" and "gates" as an estimate to the capacity of 
> current-generation FPGAs.
>
> Ideally I would provide a slice and logic area estimate for the specific 
> design, but the design is not nearly complete enough to provide such 
> reliable estimates. For now, I have to arm-wave it. I don't need it to be 
> vendor-neutral though, I can be Xilinx specific. Any suggestions anyone?
>
> -int
>
> 



Article: 95661
Subject: Re: FPGA board with High Speed LVDS
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Wed, 25 Jan 2006 11:23:50 -0000
Links: << >>  << T >>  << A >>
Wait another 6 weeks and we will be showing something in Virtex-4 that can 
do this.

John Adair
Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development 
Board.
http://www.enterpoint.co.uk

"mk" <kal*@dspia.*comdelete> wrote in message 
news:lacat1h0ukseb8pg6trd7fgedu2uv543ab@4ax.com...
> Hi,
> I am looking for a board with at least 16 balanced LVDS connections
> able to run at 800 MHz, preferably A but X would be OK too. Any and
> all suggestions are welcome. Of course the larger the FPGA the better,
> and  two or more FPGAs would be awesome :-)
>
> Thanks. 



Article: 95662
Subject: Re: encryption
From: Rene Tschaggelar <none@none.net>
Date: Wed, 25 Jan 2006 12:45:56 +0100
Links: << >>  << T >>  << A >>
yusufilker@gmail.com wrote:

> hi,
> 
> I would like to implement a secure channel over an unsecure medium.
> 
> mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A
> conv =>voice
> analog           Host A/D     digital
>                  "other side"
> 
> I do not want to encrypt data at the device's digital side
> because it is unsecure, and I dont know how to interfere digital data
> I don not have access to embedded software, source code etc.
> (maybe just after host A/D converter and emulating Host A/D converter
> to device,,,maybe) and
> every encryption algorithm implemented here can be broken at the other
> side I guess.
> 
> What I want to do is ;
> 
> mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown
> comm link
> analog              ecrypt + scramble digital data          voice like
> encrypted signal

Such scrambling may produce a lot of higher frequencies
which after being filtered out by the equipment and the
line result in data loss.

Rene

Article: 95663
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 03:56:44 -0800
Links: << >>  << T >>  << A >>

Ray Andraka wrote:
> fpga_toys@yahoo.com wrote:
> > So, my point is, and nobody seems to disagree, that it's unrealistic to
> > assume that the devices can be 100% packed, use the marketing numbers
> > for system design clock speeds, at a modest toggle rate, and not blow
> > right thru the power the device can handle. Disagree?

> You won't get the density and performance without handcrafting to meet
> both the density and performance limits.  The typical user is going to
> run into place and route issues before he even gets close to the high
> density, high clock rate corner.  I don't care if it is an RC
> application or not, you just don't get into that corner unless you do a
> considerable amount of handcrafting on the design.

Thanks for making my point. The Xilinx product chips + ISE is unable to
route
designs which have a high usage level, which is believe is because it
both
lacks routing resources and P&R needs improvement. You are probably one
of better 1/4 of percent of engineers that might have the experience to
beat
P&R regularly ... but for the rest of us mortals the product isn't
usabel as
you get close to 100% packing.

For RC uses I have a laundry list of things that are wrong with P&R,
some of
which are WHY you can not get high density designs routed with ISE. P&R
fails to pack FF's with the LUT that has it's input term ... choosing
instead to
use another LUT as a pass thru that is several CLB's away. Given a
netlist
that is obviously a 6x15 mesh from the routing, it tends to place the
parts in
an arc around the center of the chip instead. ... and a number of other
observations
that says it's costing algorithms have a very different goal, and fail
because of
it for some designs.

The problem is that P&R is not optional, they will not release the doc
for an
open source implementation which is turned to other applications, like
RC.
So until P&R can automatically route the same dense designs you pull
off,
I say the product chips+ISE isn't usable for dense designs.

The reason they get away with it today is that for hardware design
there is
a VERY strong incentive to buy up ... purchase a larger device, just to
make
sure that in the future changes will fit. So many designs will always
have the
headroom, and presure on Xilinx to improve P&R for high density routing
is
relatively low, as few designs will cross above 95% use.

With RC there is a completely different goal, and that is to use the
entire chip,
in fact, all of every chip in an FPGA processor array. High density
designs are
the norm with RC, and half device designs will be relatively rare.


Article: 95664
Subject: Re: Xilinx padding LC numbers, how do you really feel about it?
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 04:18:16 -0800
Links: << >>  << T >>  << A >>

fpga_toys@yahoo.com wrote:
> The reason they get away with it today is that for hardware design
> there is
> a VERY strong incentive to buy up ... purchase a larger device, just to
> make
> sure that in the future changes will fit. So many designs will always
> have the
> headroom, and presure on Xilinx to improve P&R for high density routing
> is
> relatively low, as few designs will cross above 95% use.
>
> With RC there is a completely different goal, and that is to use the
> entire chip,
> in fact, all of every chip in an FPGA processor array. High density
> designs are
> the norm with RC, and half device designs will be relatively rare.

Worse yet, RC will tend to use the largest chips available, or the
largest
chip with a reasonable cost performace. Buying up is not an option.

In this arena, we are talking about fiting designs to a half million or
more
on chip resources (LUT's, FF's , MUX's, etc) -- and for multichip RC
platforms target environments with easily 20M LUT's or more. This is so
far past hand routing, it's beyond even suggesting.

Automated tools are necessary to partition, route, place and optimize
these large multichip projects ... P&R isn't even close to the right
tool.
Wanting a vendor to open up their tool chain to allow open source P&R
at some point will not be just a request, or an option, it will become
manditory for implementation dyamically loaded incrementally place and
routed designs with libraries. The vendors that recognize that, and can
produce large chips, will in the end own this high end commodity
market.

Being able to compile, load and go with 20M LUT netlists in a few
seconds
is what is necessary ... five days of P&R is not an option.


Article: 95665
Subject: Re: encryption
From: allanherriman@hotmail.com
Date: 25 Jan 2006 04:20:40 -0800
Links: << >>  << T >>  << A >>
yusufilker@gmail.com wrote:
> hi,
>
> I would like to implement a secure channel over an unsecure medium.
>
> mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A
> conv =>voice
> analog           Host A/D     digital
>                  "other side"
>
> I do not want to encrypt data at the device's digital side
> because it is unsecure, and I dont know how to interfere digital data
> I don not have access to embedded software, source code etc.
> (maybe just after host A/D converter and emulating Host A/D converter
> to device,,,maybe) and
> every encryption algorithm implemented here can be broken at the other
> side I guess.
>
> What I want to do is ;
>
> mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown
> comm link
> analog              ecrypt + scramble digital data          voice like
> encrypted signal
>
> The Device will see voice freq signal and will transmit them through
> channel as if they are real voices.
> At this point adding some noise may help a lot.
> a little bit noise may fool attackers but human still can understand
> what is said.
>
>
> questions:
>
> what is possible weakness of this system?
> I am sure it can be still broken but
> how easy to break it?
> What kind of tools/approaches  "they" are using ?
> Is cpld enough for general data encryption?
> (data is human voice so  8Kbps.)
> encrytion should be easy so the hacking also....
> they: whatever you say


This would be the minimum required to make a "professional-grade" voice
encryptor:


mic => ADC => compress => encrypt => frame =+
                                            |
                                            modem <=> comm link
                                            |
spkr <= DAC <= decompress <= decrypt <= deframe


The compression (i.e. bit rate reduction) is needed because the voice
band modem won't get anything like the 64kbps required by A or mu law
8kHz audio.
Compression is already used for applications such as VOIP and mobile
phones for similar reasons.
For example, G.729 can reduce speech to 8 kbit/s.

The framing is needed because you'll probably use block based
encryption, and something needs to synchronise the blocks.
You will also need to inject and extract packets for key management,
etc.

Note that if the comm link has significant tx-rx crosstalk (e.g. if
it's a regular two wire phone line) you will require a DSP based
crosstalk canceller to get decent modem performance.


The compression, encryption and voice band modem functions could be
carried out in a regular DSP chip.
You will not be able to do this in a CPLD.
Trying to do this in an FPGA might be possible, but so is banging your
head against a wall.


Ask in news:comp.dsp about the modem and compression functions.
Ask in news:sci.crypt about the encrypt and decrypt functions.  (Also
ask about the impact of bit errors in the modem.)

Regards,
Allan


Article: 95666
Subject: Re: encryption
From: "Marc Randolph" <mrand@my-deja.com>
Date: 25 Jan 2006 04:39:12 -0800
Links: << >>  << T >>  << A >>
yusufilker@gmail.com wrote:
> hi,

Howdy yusuf,  see below...

> I would like to implement a secure channel over an unsecure medium.
>
> mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A
> conv =>voice
> analog           Host A/D     digital
>                  "other side"
>
> I do not want to encrypt data at the device's digital side
> because it is unsecure,

Why do you think it is unsecure?  Hopefully a professor isn't telling
you that, as I believe it's how most governmental and non-governmental
encryption is done.

> and I dont know how to interfere digital data
> I don not have access to embedded software, source code etc.
> (maybe just after host A/D converter and emulating Host A/D converter
> to device,,,maybe) and
> every encryption algorithm implemented here can be broken at the other
> side I guess.

What makes you say that "every encryption algorithm implemented here
can be broken at the other side"?  Why is it easy to break "here" and
not somewhere else?

> What I want to do is ;
>
> mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown
> comm link
> analog              ecrypt + scramble digital data          voice like
> encrypted signal

I'm not sure what a "voice like" encrypted signal would be, but I'm
pretty sure that if someone could tell that it was voice like, it will
not be secure.  I'm also not sure what the purpose of all the A/D's and
D/A's are, but that's a side issue that doesn't seem important to the
rest of the discussion, so I'll just skip it.

> The Device will see voice freq signal and will transmit them through
> channel as if they are real voices.
> At this point adding some noise may help a lot.
> a little bit noise may fool attackers but human still can understand
> what is said.

I believe that adding randomness (noise) to the input signal/data that
is about to be encrypted is bordering on security by obscurity, which
in theory, adds little to no real protection to a determined attacker.
In practice, you might be able to argue otherwise (maybe that every
little bit of security helps?) - but know that modern cryptographers
like to rely one thing and one thing only: the length of the key.  They
typically use algorithms that are known and respected industry wide.
They use algorithms that have been peer reviewed many times over many
years.

> questions:
>
> what is possible weakness of this system?
> I am sure it can be still broken but how easy to break it?
> What kind of tools/approaches  "they" are using ?

With absolutely no disrespect intended, if you don't know what the
strengths or weaknesses are of a system you are trying to design, or
what kind of attackes someone might make on it, I'm afraid that a
Usenet posting or two probably isn't going to help (even if it were
from an experienced cryptographer, which I'm not).

> Is cpld enough for general data encryption?
> (data is human voice so  8Kbps.)
> encrytion should be easy so the hacking also....

Compressing human voice down to 8 kbit/s requires a little bit of
horsepower.  It would not surprise me if it was beyond the capabilities
of a CPLD, or if it is possible, would require an experienced coder
that is very efficient in how they implement algorithms.

Have fun,

   Marc


Article: 95667
Subject: Re: ISE8.1 on Linux, first impressions
From: "hutzelbutz" <joachim.becker@imtek.uni-freiburg.de>
Date: 25 Jan 2006 04:44:44 -0800
Links: << >>  << T >>  << A >>
sure, I know about all those scripting and makefile advantages, there
have been enough wars on that. However, I _do_ like graphical user
interfaces and once everything is set up, I can press one button to run
the complete designflow over and over again... Some people like one,
some the other, no worries, everybody is free.
So thanks for your suggestion but I am not looking for a workaround but
a real fix of the ISE GUI.


Article: 95668
Subject: Re: custom ip using EDK
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 25 Jan 2006 12:46:32 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 24 Jan 2006 22:01:42 -0800, "Eric" <dasani8888@hotmail.com> wrote:

>Hi,
>
>I designed a simple adder using the add/import peripheral feature in
>EDK. I removed the sum register in the write process, and add a
>my_adder process to calculate the sum. Every time I run the test (a
>sample software application), I get a 0 as the sum. I got both reg0 and
>reg1 correct, but not the sum. Anyone has an idea what I've done wrong?
>I can't figure if it's the code issue, or I am supposed to change some
>setting in EDK. Thanks.
>
>part of my application code:
>
>   MY_ADDER_mWriteReg(XPAR_MY_ADDER_0_BASEADDR, 0, 10);
>   MY_ADDER_mWriteReg(XPAR_MY_ADDER_0_BASEADDR, 0x4, 7);
>   sum = MY_ADDER_mReadReg(XPAR_MY_ADDER_0_BASEADDR, 0x8);

>    case slv_reg_read_select is
>      when "100" => slv_ip2bus_data <= slv_reg0;
>      when "010" => slv_ip2bus_data <= slv_reg1;
>      when "001" => slv_ip2bus_data <= slv_reg2;
>      when others => slv_ip2bus_data <= (others => '0');
>    end case;

The conversion from address to select is not given here...

Do these addresses actually correspond to these read selects?

You may have to simulate the design to find out.

- Brian



Article: 95669
Subject: Re: encryption
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Wed, 25 Jan 2006 12:55:00 GMT
Links: << >>  << T >>  << A >>
On a sunny day (25 Jan 2006 04:20:40 -0800) it happened
allanherriman@hotmail.com wrote in
<1138191640.397630.147570@o13g2000cwo.googlegroups.com>:

>This would be the minimum required to make a "professional-grade" voice
>encryptor:
>
>
>mic => ADC => compress => encrypt => frame =+

Do not forget the anti-aliasing lowpass before the ADC.



Article: 95670
Subject: Re: encryption
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 25 Jan 2006 13:56:04 +0100
Links: << >>  << T >>  << A >>
>Marc Randolph" <mrand@my-deja.com> schrieb im Newsbeitrag 
>news:1138192752.155593.278520@z14g2000cwz.googlegroups.com...
> yusufilker@gmail.com wrote:
>> hi,
>
> Howdy yusuf,  see below...
>
>> I would like to implement a secure channel over an unsecure medium.
>>
>> mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A

Transmitting encrypted voice over band-limited analog link is VERY VERY 
complicated task. If you want secure and reliable connection over analog 
link that does not reduce the quality (eg provides almost the same bandwidth 
as clear channel) then calculate at least one man-year development time. 
Probably more.

I have hacked an secured digital sound transmittion standard once a long 
time ago. It is amazing what has to be done to digitized voice in order to 
hide its nature of being voice data. Anything that is from our world eg 
sound, voice, captured image keeps its characteristics after large amount of 
distortion applied, things like bit swapping/interleaving, xor patterns do 
not change almost anything - methods exist to recover the original.


-- 
Antti Lukats
http://www.xilant.com 



Article: 95671
Subject: How to generate ILA with ChipScope pro in Linux
From: "Pasacco" <pasacco@gmail.com>
Date: 25 Jan 2006 05:03:03 -0800
Links: << >>  << T >>  << A >>
hi

It seems that, in Linux, we have to generate ICON,ILA core with
command-line.
I am starting to use chipscope pro 8.1.

Problem is that it is too error-prone when I type the configuration
(especially ILA) in command-line.
Actually following command-line created "Directory stack not that deep"
error message.

--------------------------------------------------------------------------------------------------------------------------
> generate.sh ila -compname=my_ilaunit_0 -numtrigports=3 -trigportWidth0 =1 -trigportWidth1 =1 -trigportWidth2 =4 -mtype0 =5 -mtype1 =5 -mtype2 =4 -datasameastrig -datadepth=512 -datawidth=32 -enabledatatrig0 -enabledatatrig1 -enabledatatrig2 -enablestoragequal -outputdirectory="~/CSPro/" -srl16type=1 -devicefamily=Virtex2P -trigseqtype=1 -createcdc
---------------------------------------------------------------------------------------------------------------------------

If someone has this experience, let us know how to solve this problem,
Thankyou


Article: 95672
Subject: Re: How to generate ILA with ChipScope pro in Linux
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 25 Jan 2006 14:14:55 +0100
Links: << >>  << T >>  << A >>
"Pasacco" <pasacco@gmail.com> schrieb im Newsbeitrag 
news:1138194183.393636.40370@z14g2000cwz.googlegroups.com...
> hi
>
> It seems that, in Linux, we have to generate ICON,ILA core with
> command-line.
> I am starting to use chipscope pro 8.1.
>
> Problem is that it is too error-prone when I type the configuration
> (especially ILA) in command-line.
> Actually following command-line created "Directory stack not that deep"
> error message.
>
> --------------------------------------------------------------------------------------------------------------------------
>> generate.sh ila -compname=my_ilaunit_0 -numtrigports=3 -trigportWidth0 
>> =1 -trigportWidth1 =1 -trigportWidth2 =4 -mtype0 =5 -mtype1 =5 -mtype2 
>> =4 -datasameastrig -datadepth=512 -datawidth=32 -enabledatatrig0 -enabledatatrig1 
>>  -enabledatatrig2 -enablestoragequal -outputdirectory="~/CSPro/" -srl16type=1 
>>  -devicefamily=Virtex2P -trigseqtype=1 -createcdc
> ---------------------------------------------------------------------------------------------------------------------------
>
> If someone has this experience, let us know how to solve this problem,
> Thankyou
>
your params when pasted into argument file and run with CS 8.1 on windows 
then it works with no problems.

so if the same does not work on linix then the workaround is to use a 
windows PC for the ChipScope


-- 
Antti Lukats
http://www.xilant.com 



Article: 95673
Subject: Re: So what happened to JHDLBits?
From: fpga_toys@yahoo.com
Date: 25 Jan 2006 05:19:48 -0800
Links: << >>  << T >>  << A >>

Phil Tomson wrote:
> But then someone brought up the fate of JHDLBits: apparently the prjoject was
> squashed by Xilinx.  Does anyone have any details about what happened?  If
> someone succeeded in developing an open source ecosystem of tools built around
> XDL, would that project also suffer the same fate?  (It would be nice to know
> before investing much time and effort in developing tools around XDL)

The status from the team a year ago was:

     "we are still trying to figure out a schedule with Xilinx
      corporation on the release of the project.  Xilinx funded the
research and
      some parts of the project contained proprietary information, so
we have been
      trying to come to an agreement.  We are still hoping for a
release sometime
      soon."

I've asked a several Xilinx staff about it both on and off the record.
On the record,
no reply. Off the record, "it will never happen".  The fine print in
Xilinx tools licenses
is a claim preventing reverse engineering of the chip layouts and
databases, even
though this is clearly visible to the user from several tools ranging
from the fpga
editor to the bit stream generator. From what I have been told, any
compilation of
data base details into an open source equivalent P&R to bitstream tool
as was done
by the JHDLBits team will result in a C&D Order from Xilinx.

So, Xilinx let this team proceed, gained a lot of publicity from it as
marketing
collaterial, and then dashed the teams hopes of taking it open source.
I doubt
the team would have partnered with Xilinx had the outcome been clearly
stated
up front. They put a lot of energy into the project, then were told to
shutup and
walk away.

Much of what the FpgaC project needs to support compile, load, and go
for Xilinx
product is trapped in this project, with a clear warning from Xilinx to
stay clear.
The likely outcome is to focus on other vendors which are more willing
to allow
open source investment in RC technologies which support their products.


Article: 95674
Subject: Re: porting linux on ml403
From: "Anonymous" <someone@microsoft.com>
Date: Wed, 25 Jan 2006 13:24:02 GMT
Links: << >>  << T >>  << A >>
Doesn't the ml403 come with a Linux distribution? Why would you need to port
anything?

"ramesh" <ramesh@embeyond.com> wrote in message
news:1138173378.715130.86900@g43g2000cwa.googlegroups.com...
> Hi All,
> Iam new to xilinx platfrom.
>
> I was trying to port open source linux on Ml403 board. i tried to
> follow the instructions in the below link.
> http://www.klingauf.de/v2p/index.phtml
> i was getting errors when i was running bZimage. the .elf file was not
> getting created.
>
> Is there an alternative way of acheiving my goal.
> Kindly suggest.
> Thanks in advance.
>
> Ramesh
>





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