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 109500

Article: 109500
Subject: Re: Driving a 30 bit wide LVTTL bus at 160MHz
From: Ray Andraka <ray@andraka.com>
Date: Wed, 27 Sep 2006 12:43:41 -0400
Links: << >>  << T >>  << A >>
Dolphin wrote:
> Hello,
> 
> In my future design I could win a lot of pins if I could drive a bus at
> 160MHz. Because of bank restrictions and because this bus is connected
> to a CPLD, I will have to use LVTTL.
> Has anybody tried driving a bus in LVTTL at 160MHz?
> 
> I would prefer to use LVDS but the CPLD doesn't allow that. Lattice has
> LVDS CPLDs but only the large CPLDs support LVDS inputs.
> 
> I am afraid that this bus will have a lot of EMI/EMC problems. What do
> you think of it, should series termination be adequate to limit the
> EMI/EMC problems?
> 
> best regards,
> Dolphin
> 
It can be done with extreme care.  Keep the lines short, you may need to 
terminate them, and by all means do a SI simulation on it so that you 
know it will work rather than blindly applying "fixes".

Article: 109501
Subject: Re: Configuration of Spartan 3 devices
From: "rickman" <gnuarm@gmail.com>
Date: 27 Sep 2006 10:04:02 -0700
Links: << >>  << T >>  << A >>
John_H wrote:
> "rickman" <gnuarm@gmail.com> wrote in message
> news:1159365978.100646.5140@i42g2000cwa.googlegroups.com...
> >
> > Do the S3e parts have the same issue with the overly stiff pullups that
> > the S3 parts have?  I'm not sure if they are going to fix that in the
> > S3a parts or not.
>
> It was fixed, indeed.  The pullups on the S3s were pretty stiff.  Things are
> back toward expectations now with the S3E.  I would expect the S3A to follow
> S3E's lead.

Fixed is a relative term.  Worst case for the S3 is 1.4 kohms while the
Virtex 4 is 16.5 kohms.  The S3E is between at 2.7 kohms, only about 2x
the S3 value and under a fifth of the V4 value.  I can only assume that
there is some issue with the IO design in the Spartan series that makes
it hard to get a realisticly useful pullup value around 20 kohms like
the V4 and other Xilinx product use.  I'm sure we will never know the
reason why.


Article: 109502
Subject: Re: Balanced inputs on Spartan3E
From: "Matthew Hicks" <mdhicks2@uiuc.edu>
Date: Wed, 27 Sep 2006 12:06:39 -0500
Links: << >>  << T >>  << A >>
If you are using a differential signal, like LVDS, you need to use a 
differential to single ended signal buffer.  So, you would have two global 
"in" signals, in_P and in_N, which you assign pins to.  Look at the FPGA's 
data sheet for examples of differential signal buffers.  Then, "in" would be 
the output from the buffer.


---Matthew Hicks


"tersono" <ethel.thefrog@ntlworld.com> wrote in message 
news:agkdh29dtdvp8p6t3rfr70iad3t3qrp0h5@4ax.com...
> I've come to FPGAs from CPLDs and am rapidly realising that a
> reasonable (but not complete) knowledge of Verilog is not enough!
>
> So tonight's question is:
>
> How do I set up a balanced input?
>
> I can write (a minimal example to make the point)
>
> ############
> module top(Q, in, clk);
>    output Q;
>    input in;
>    input clk;
>
> reg Q;
>
> always @(posedge clk)
> Q<=in;
>
>
> endmodule
> ################
>
> and in PACE I can specify that I want "in" to be- let's say- LVDS_25-
> a balanced input type; I can put that input on pin 2- one of a pair.
> (Diff Type and Pair Name are not writeable in the Design Object List).
>
> However, when the design has been fitted and routed, I find that pin
> 3- the other of the pair- is not connected.
>
> What am I missing?
>
> Thank you in anticipation,
>
> Colin
>
> --
> Per ardua ad nauseam 



Article: 109503
Subject: Re: synchronous clocks
From: zohair <szohair@gmail.com>
Date: Wed, 27 Sep 2006 10:27:45 -0700
Links: << >>  << T >>  << A >>
Peter, mixing clock domains (i.e. having multiple clock domains) is part of most digital designs. I'm surprised to see such an answer from a Xilinx engineer. I prefer the other two options stated here by other engineers, but I guess the answer to my question really is to use a DCM and control delays through it rather than a hand-coded divider?

I'd still want to know if the Xilinx P&R tools could automatically handle the routing/buffering of the clock tree such that the skew between clocks declared as synchronous will be minimal. In my case, I see skew of upto 5 ns.

Article: 109504
Subject: Re: I2C slaves needed
From: "Matthew Hicks" <mdhicks2@uiuc.edu>
Date: Wed, 27 Sep 2006 12:34:57 -0500
Links: << >>  << T >>  << A >>
You can also buy hardware devices that use the I2C bus off of Digikey for a 
few bucks.  That's what I did to completely test my design.


---Matthew Hicks


"vits" <vittal.patil@gmail.com> wrote in message 
news:1159176429.670095.279080@h48g2000cwc.googlegroups.com...
> Hi,
> I need some (2 to 3) different I2C Slave models from different
> companies (in verilog)
> to test my I2C Bus .I have verified with the model given in opencores
> site.
> Please point me in this direction.
> -Vits.
> 



Article: 109505
Subject: Anyone had success with MIG, DDR2 and V2Pro?
From: Greg Watson <gwatson@stanford.edu>
Date: Wed, 27 Sep 2006 10:36:18 -0700
Links: << >>  << T >>  << A >>
Hi

We are planning to use MIG to generate a DDR2 interface for a V2Pro30 
design, but I'd like to know if anyone has done this successfully 
already? The MIG tool doesn't seem to have the quality level of other 
Xilinx tools and that makes me a bit nervous for something as timing 
critical as a DDR2 controller.

We are using MIG 007 Rel 6 (as it's the recommended version for V2P). So 
far the only irritations we have encountered is that it forces the use 
of specific DCMs and requires the user to reselect every option each 
time it is invoked (no saving of current design).

We plan to run 1 32 bit controller at 200MHz (400 Mb/s/pin) with Micron 
MT47H16M16.

We would like to hear of any experiences with MIG and DDR2 and V2P, if 
only to convince us that this is doable. Our final design should be open 
sourced and available to all, if that encourages you to be open about 
your experiences.

If you would rather contact me directly I am at gwatson@stanford.edu

Thanks

Greg Watson

Article: 109506
Subject: Re: uBlaze prototype PCB UART issues
From: "mjackson" <fbs.consulting@gmail.com>
Date: 27 Sep 2006 10:51:00 -0700
Links: << >>  << T >>  << A >>
>
> there is no direct upper bound freq limitations its rather complicate
> to
> give such numbers actually.
>
> but as thumb guess if the system is not optimized for Xilinx marketing
> to give absolute total max sysclock then the system in S3e would
> have more chance to pass timing on sysclock below 100MHz
>
> but, again it all depens what IP cores you have in and how you apply
> constraints and if you run xplorer script and multipass PAR, etc..
>
> Its also hard to get 100Mhz on Virtex-4 (Xilinx advertizes 200MHz max
> MicroBlaze clock for ver 4) so timing trouble on realworld microblaze
> design in S3e at 100Mhz are just to be expected.
>
> you should try EDK 8.2 and MB5 it has improved pipeline that should
> allow higher clocks, also it can run xplorer script on XPS system
>
> Antti

Thanks for the help Antti. Even by dividing the clock down from 100MHz
to some 'reasonable' value of 50MHz to 75 MHz, I am still unable to get
a functioning UART on this board when trying to implement a new design.
The fact that it works when modifying designs intended for the
evaluation board is literally driving me nuts. It seems rediculous that
I will have to originate designs targeted for evaluation hardware and
then hack my way to funcional designs on my own hardware.

I will try upgrading to 8.2 and see if that solves some issues.
Consequently, is it possible that I'm exeeding the input range of the
DCM at 100MHz? The more I fight with this, the less I think EDK is a
time-saver when compared to a standard ISE flow.

Thanks again though.


Article: 109507
Subject: Re: synchronous clocks
From: "Peter Alfke" <peter@xilinx.com>
Date: 27 Sep 2006 10:54:26 -0700
Links: << >>  << T >>  << A >>
Let me "surprise" you even more:
In an FPGA you should use the Global Clocks (there are many of them).
Any global clock can drive any or all flip-flops on the chip, and its
clock skew is so small that you will not have any hold-time issues
between any flip-flops clocked by the same Global Clock.
You will never see a Global Clock skew in exces of 1 ns. Your example
of 5 ns indiates a scary way of using local clock routing. Don't do
that!
Using deliberate clock delays to balance away the clock-to-Q of a
synchronous clock divider is something I would advise you NOT to do in
an FPGA, unless you have a very good understanding of the signal
distribution in the design (As I explained in my previous posting,
which you chastized me for. You are forgiven, but I stand by my
statements).
Peter Alfke
===========
zohair wrote:
> Peter, mixing clock domains (i.e. having multiple clock domains) is part of most digital designs. I'm surprised to see such an answer from a Xilinx engineer. I prefer the other two options stated here by other engineers, but I guess the answer to my question really is to use a DCM and control delays through it rather than a hand-coded divider?
>
> I'd still want to know if the Xilinx P&R tools could automatically handle the routing/buffering of the clock tree such that the skew between clocks declared as synchronous will be minimal. In my case, I see skew of upto 5 ns.


Article: 109508
Subject: Re: lwip
From: "Sathya" <sathyatm@gmail.com>
Date: 27 Sep 2006 11:06:00 -0700
Links: << >>  << T >>  << A >>
Hi,
There are 2 modes of operation for lwIP stack - RAW API, Sockets API.
The initializations are different based on the mode chosen. Please take
a look at the lwIP documentation that is part of the EDK release. Look
for the lwIP chapter in the OS & Libraries guide.

Sathya

u_stadler@yahoo.de wrote:
> hi
>
> i have a quick question:
>
> do i have to use lwip_init() for raw_api mode as well or do i have to
> call all the mem_init() etc. seperatly?
>
> when using the raw mode and calling all the init functions as in the
> xilinx example a call to sys_new_thread() wont start the new thread and
> it looks likte the function doesn't do anything.
> could somebody help me out here please?
> 
> thanks
> urban


Article: 109509
Subject: Re: Driving a 30 bit wide LVTTL bus at 160MHz
From: "John Adair" <g1@enterpoint.co.uk>
Date: 27 Sep 2006 11:13:43 -0700
Links: << >>  << T >>  << A >>
Also be careful of Simulaneously Switching Outputs guidelines. As Ray
says it can be done but if you use a crappy package like PQ208 or TQ144
you may have big problems with ground bounce that causes the interface
to fail. Most of the BGA packages do much better at this fast type of
driving from our experience.

Some CPLDs like the bigger Coolrunner-IIs can also support single ended
standards like SSTL, HSTL that are designed for high speed and may be a
an alternate solution for you. These standards have the advantage of
small signal swings too which is better for ground bounce and EMC.

John Adair
Enterpoint Ltd.

Ray Andraka wrote:
> Dolphin wrote:
> > Hello,
> >
> > In my future design I could win a lot of pins if I could drive a bus at
> > 160MHz. Because of bank restrictions and because this bus is connected
> > to a CPLD, I will have to use LVTTL.
> > Has anybody tried driving a bus in LVTTL at 160MHz?
> >
> > I would prefer to use LVDS but the CPLD doesn't allow that. Lattice has
> > LVDS CPLDs but only the large CPLDs support LVDS inputs.
> >
> > I am afraid that this bus will have a lot of EMI/EMC problems. What do
> > you think of it, should series termination be adequate to limit the
> > EMI/EMC problems?
> >
> > best regards,
> > Dolphin
> >
> It can be done with extreme care.  Keep the lines short, you may need to
> terminate them, and by all means do a SI simulation on it so that you
> know it will work rather than blindly applying "fixes".


Article: 109510
Subject: Re: Trying to get plb_temac working
From: "funkrhythm" <rimas@cnmat.berkeley.edu>
Date: 27 Sep 2006 11:24:35 -0700
Links: << >>  << T >>  << A >>
i used the branch of the ppc kernel mentioned here

http://www.stanford.edu/~malechen/linux_on_fpga.htm

and copied over the files from the BSP

then what i did was to edit the Makefile in the drivers/net directory
and change the references from xilinx_enet to xilinx_gige, and select
the regular xilinx driver in the menuconfig

-rimas

p.s. if the PVR (processor version register) in your mini-module is
0x20011430 make sure you apply patches to turn off caching or you will
have problems.  more info here:

http://www.xilinx.com/xlnx/xil_ans_display.jsp?iCountryID=1&iLanguageID=1&getPagePath=20658&BV_SessionID=@@@@0781667753.1159381366@@@@&BV_EngineID=ccccaddimemlhmicefeceihdffhdfjf.0

Benedikt Wildenhain wrote:
> Hello,
>
> On Wed, Sep 13, 2006 at 05:15:24PM -0700, funkrhythm wrote:
> > Benedikt Wildenhain wrote:
> > > Now I want to try sending some IP packets accross the wire, but both
> > > xilnet and lwip insist on using either opb_ethernet or -lite. Are there
> > > any adjusted versions for one of these?
> > don't know about that, i am running linux on the V4FX12 and the EDK
> > generates an ethernet driver (xilinx_gige) that works with the
> > PLB_TEMAC
> How did you compile a matching kernel? I tried to compile a 2.4 kernel
> (I tried several branches, but finally got farest with the branch from
> bee2.eecs.berkeley.edu as it already has integrated the xilinx_gige
> driver) with the BSP for Montavista Linux 3.1. As (menu|x)config doesn't
> offer my board I set CONFIG_MEMEC_2VPX=y, tried to compile it with
> support for uartlite (for the serial console) and xilinx_gige, but
> linking the kernel fails with
>


Article: 109511
Subject: Re: Are you ready for Virtex-5? We are...
From: "Antti" <Antti.Lukats@xilant.com>
Date: 27 Sep 2006 11:34:05 -0700
Links: << >>  << T >>  << A >>
Antti schrieb:

> Peter Alfke schrieb:
>
> > You can order Virtex-5 devices from your distributor now, and he will
> > offer short delivery times.
> [...]
> > Peter Alfke, who has been working on and with these parts for over a
> > year.
>
[my own ***** snipped]
> until both the silicon AND tools are available there is no supprort.
> So no matter how ready we may be for Virtex-5, and belive me some
> of us really are - we are not really able todo any real work until
> tools support is also made available by Xilinx.
>

EDK 8.1 SP1 has Virtex-5 MicroBlaze 5.00.a and 5.00.b in it
it is just labelled as "early access" but its readily available.
there is some minor mess with MPD files like FSL bus is not
supported (eg requires manual edit of the MPD) but otherwise
the Virtex-5 can be targetted ok on EDK 8.1 SP1, eg no need
to wait for SP2

here is the picture of the EDK system with Virtex-5

http://www.microfpga.com/joomla/index.php?page=shop.browse&category_id=12&option=com_virtuemart&Itemid=26

Antti


Article: 109512
Subject: Re: uBlaze prototype PCB UART issues
From: "Antti" <Antti.Lukats@xilant.com>
Date: 27 Sep 2006 11:41:15 -0700
Links: << >>  << T >>  << A >>
mjackson schrieb:

> >
> > there is no direct upper bound freq limitations its rather complicate
> > to
> > give such numbers actually.
> >
> > but as thumb guess if the system is not optimized for Xilinx marketing
> > to give absolute total max sysclock then the system in S3e would
> > have more chance to pass timing on sysclock below 100MHz
> >
> > but, again it all depens what IP cores you have in and how you apply
> > constraints and if you run xplorer script and multipass PAR, etc..
> >
> > Its also hard to get 100Mhz on Virtex-4 (Xilinx advertizes 200MHz max
> > MicroBlaze clock for ver 4) so timing trouble on realworld microblaze
> > design in S3e at 100Mhz are just to be expected.
> >
> > you should try EDK 8.2 and MB5 it has improved pipeline that should
> > allow higher clocks, also it can run xplorer script on XPS system
> >
> > Antti
>
> Thanks for the help Antti. Even by dividing the clock down from 100MHz
> to some 'reasonable' value of 50MHz to 75 MHz, I am still unable to get
> a functioning UART on this board when trying to implement a new design.
> The fact that it works when modifying designs intended for the
> evaluation board is literally driving me nuts. It seems rediculous that
> I will have to originate designs targeted for evaluation hardware and
> then hack my way to funcional designs on my own hardware.
>
> I will try upgrading to 8.2 and see if that solves some issues.
> Consequently, is it possible that I'm exeeding the input range of the
> DCM at 100MHz? The more I fight with this, the less I think EDK is a
> time-saver when compared to a standard ISE flow.
>
> Thanks again though.

after years of fight, I still fight (with EDK) -  but I think EDK is
actually getting better.

get 8.2 and let the xplorer script to optimize timing if you want to
squeeze the max clock. getting the DCM to work in EDK isnt so simple,
or maybe it is but it is equally simple to get something wrong and they
want work.

I think as of some errata S3e early silicon had DCM input range maxed
at 90MHz? production silicon is defently ok to use way higher inputs
clocks

good luck and many succesful fights with EDK!

Antti


Article: 109513
Subject: Re: PERISHABLE PAPER RELATED TO FPGA!
From: "Todd Fleming" <tbfleming@gmail.com>
Date: 27 Sep 2006 11:41:41 -0700
Links: << >>  << T >>  << A >>
> Stop this already, some of us are not going to get much work done today
> if you keep this up.
>
> Now I have to go clean myself up:)
>
> John Jakson
> transputer guy

I hope you used the new m=F6bius strip wipes that come packaged in a
four-dimensional Klein bottle for a never-ending supply!

Todd


Article: 109514
Subject: Re: An algorithm with Minimum vertex cover without considering its performance
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 27 Sep 2006 11:43:54 -0700
Links: << >>  << T >>  << A >>

Ralph Hartley wrote:
> David Ashley wrote:
> > Speaking of which, here's a nobel prize winning idea.
> > Assuming the problem of protein folding is part of NP
> > complete, all you'd have to do is construct a DNA
> > sequence that encodes for a protein, and the protein
> > itself is equivalent to some OTHER NP problem you
> > want to solve. So you let the protein go and fold however
> > it wants to, and then you look at how it's folded, and you
> > have your answer. So you've managed to get the universe
> > to work for you. :)
>
> Not a particularly new idea, I'm afraid. The problem is that the protein
>   corresponding to a hard problem will take nearly *forever* to fold.
>
> It is not true that an arbitrary protein sequence will quickly fold into
> a stable structure that is the same each time. In fact, most will *not*
> do that. Biological  proteins do (mostly), but they were selected for that.
>
> Ralph Hartley

Hi,
Here is a good introduction reference on the minimum vertex cover
problem:
http://www.cs.uu.nl/docs/vakken/amc/lecture03-4.pdf#search=%22minimum%20vertex%20cover%22

Weng


Article: 109515
Subject: Is it worth learning SOPC Builder, DSP Builder & Nios Processor?
From: "jjlindula@hotmail.com" <jjlindula@hotmail.com>
Date: 27 Sep 2006 11:52:23 -0700
Links: << >>  << T >>  << A >>
Hello, I've been seeing more training at Altera concerning their SOPC
Builder, DSP Builder & the Nios Processor so I wanted to ask anyone if
these tools are gaining acceptance in the engineering world? A
co-worker used the Nios processor a few years ago and said that it was
slow so they didn't use it in their project. Are these tools useful for
high-speed applications? If anyone can comment on these tools I'd
greatly appreciate it.

Thanks,
joe


Article: 109516
Subject: Re: Is it worth learning SOPC Builder, DSP Builder & Nios Processor?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 27 Sep 2006 11:59:02 -0700
Links: << >>  << T >>  << A >>
jjlindula@hotmail.com schrieb:

> Hello, I've been seeing more training at Altera concerning their SOPC
> Builder, DSP Builder & the Nios Processor so I wanted to ask anyone if
> these tools are gaining acceptance in the engineering world? A
> co-worker used the Nios processor a few years ago and said that it was
> slow so they didn't use it in their project. Are these tools useful for
> high-speed applications? If anyone can comment on these tools I'd
> greatly appreciate it.
>
> Thanks,
> joe

learning is almost always worth (something).

NIOS (or any soft-core CPU) - is not as fast as dedicated CPU's today
can be, and equally is the bus structure and peripherals also not as
fast as they can be in dedicated MCU's - so the real advantages come
from the combination of configurable processor core, user selectable
peripheral, AND user added IP cores.

a small task that may take up 99% of the CPU time could possible
be moved to FPGA hardware directly and only consume 1% of the
FPGA resources. That would give you a feeling like the CPU did
come 100 times faster!

if using the softcore processor alone, then it want compete with
dedicated CPU's it has never been the goal also.

Antti


Article: 109517
Subject: Virtex-5: small little things.
From: "Antti" <Antti.Lukats@xilant.com>
Date: 27 Sep 2006 12:19:21 -0700
Links: << >>  << T >>  << A >>
Xilinx isnt advertizing 'small things' that are also coming as bonus
with Virtex-5, I found one by accident while browsing the ML501
reference designs and docu, namly

* Virtex-5 has fully dedicated pins for the parallel flash so any NOR
flash connected properly as configuration memory is also accessible by
the dedicated pins for both read and writes. Those it is possible to
use indirect nor flash programming for V5-connected nor flash, and
surprise it is already offered by Xilinx! its hidden in the "LAB
resources" for ML501 but the indirect programming software and
bitstreams are available for all v5lx devices.

* anothes small thing is the access to configuration clock oscillator
after configuration from FPGA fabric (but that has already been told
here)

* not to mention that the SYSMON what is there in V4 (but disabled by
the tools) is now finally user accessible

* CRC32 and CRC64 as primitives

* EFUSE primitive whats that !?

* KEYCLEAR primitive !! Thanks you, Xilinx! this is for clearing the
encryption key from the FPGA fabric - I was missing this feature badly,
now its there !!

* PCIE primitive ? I am not believing what I am seeing ?!

* PMV is still there too

* USR_ACCESS  is enhanced as well

I guess there are some more nice small things hidden - anyone found
something?
or was I just dreaming? too late maybe I'd better rest or who knows
what else
I would be seeing!

Antti


Article: 109518
Subject: Re: PUBLISHABLE PAPER RELATED TO FPGA!
From: "solo" <alexandre.aoun@gmail.com>
Date: 27 Sep 2006 13:37:02 -0700
Links: << >>  << T >>  << A >>
Dear Miss Lazarut,

It seems i am the victim of using capital letters with my words! I did
not know in the first place that this was prohibited for a formal
conversation.
My whole point was to take some ideas from professionals like you for
performing my paper related to FPGA's and optimization of placement and
routing.
May you help me, please?

Regards!

Aurelian Lazarut wrote:
> Mr. Aoun,
> *************
> Alexandre Aoun
> Computer Engineering Student
> Mathaf Adlieh street - Beirut, Lebanon
> Born 1983
> *************
> if you have anything to do with FPGA's or digital design you are
> welcome, but you need to know your place
> it seems that you've been caught on the wrong foot here, so you have the
> chance to back off, read and learn, otherwise you'll become a clown in
> this newsgroup.
> at the end of the day it's your choice.
>
> Aurash
>
> PS, and please stop imitating Yoda from Star Wars when you post
> messages, Syms is at least one order of magnitude better than you  ;-)
>
> solo wrote:
>
> >Mr Peter,
> >
> >I didnt like your reply:
> >
> >First, all my ideas are interesting since i am related to the field of
> >software enginnering and i ignore the field where you come from!
> >
> >Second, i didnt understand the impolite word "ass-backwards" that you
> >used and i wish that you keep those rude words for yourself and your
> >culture!
> >
> >Third and most importantly, my statements are not arrogant at all! Your
> >reply to me seems that you want to revenge from someone and this is not
> >acceptable!
> >
> >Hope you be more lineant and understanding when replying to people,
> >otherwise your replies are not interesting and will be rejected!
> >
> >Thanks!
> >
> >Peter Alfke wrote:
> >
> >
> >>We may have to teach Mr Solo some basic facts:
> >>First you must have an interesting idea or some valuable specific
> >>knowledge.
> >>Then, and only then, do you start writing an article.
> >>He seems to have this ass-backwards.
> >>Beyond that it might also be wise not to insult this newsgroup with
> >>arrogant statements about the lust for capitalization.
> >>Peter Alfke
> >>=============
> >>Todd Fleming wrote:
> >>
> >>
> >>>This gives a whole new meaning to the term "partial reconfiguration"
> >>>
> >>>Todd
> >>>
> >>>jacko wrote:
> >>>
> >>>
> >>>>how about single inline fpga which use veroboard spacing, and can be
> >>>>broken off at one pin intervals.
> >>>>
> >>>>place 4 pins in prigrammer for power, clk, and program data, and then
> >>>>break off to length specified by fpga compilier.
> >>>>
> >>>>
> >>>>available in 1m strips maybe.
> >>>>
> >>>>
> >>>>needs comparator for analog input, and as much logic in 1 pin segment
> >>>>as possible.
> >>>>
> >>>>
> >>>>flash on board prefered, with some 4 cycle dram too, for compactness.
> >>>>
> >>>>
> >>>>is this the kind of thing u meant??
> >>>>
> >>>>
> >
> >
> >
>
>
> --
>  __
> / /\/\ Aurelian Lazarut
> \ \  / System Verification Engineer
> / /  \ Xilinx Ireland
> \_\/\/
>  
> phone:	353 01 4032639
> fax:	353 01 4640324


Article: 109519
Subject: Re: Pack registers (from submodule) into IOB for bidirectionnal signal
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 27 Sep 2006 22:11:47 +0100
Links: << >>  << T >>  << A >>
On 26 Sep 2006 14:33:03 -0700, "Patrick Dubois" <prdubois@gmail.com>
wrote:

>Hello,
>
>I know that this has been discussed here a few times but I still can't
>find a definitive answer so here we go again...
>
>What is the best way (with Xilinx flow) to ensure that registers are
>packed into IOB? In my case I want three registers to be packed into
>the IOB for a bidirectionnal signal (in, out and oe).

You seem to have the standard tricks...

>I read quite a bit about the issue and the standard tricks seem to be:
>1- Use the IOB = "true" constraint in the HDL code for the registers
>2- Use the flag -iob true for xst (redundant with #1)

Not only redundant, but quite dangerous since this flag appears to apply
the IOB=TRUE attribute to every individual register (maybe only every
register on a hierarchy boundary) regardless of whether it is anywhere
near a pin. And this attribute prevents packing registers into
multipliers and who knows what else...

#1 applied ONLY to the registers in question gives much better control

>4- Duplicate the oe registers and use equivalent_register_removal =
>"NO" to prevent xst from optimizing them away

Essential - and again, apply equivalent_register_removal as an attribute
ONLY to the registers in question, not as an XST flag... 

With both of these as global flags I have seen a 15% slowdown and 20%
greater register usage in a design.

- Brian



Article: 109520
Subject: Re: MicroBlaze : Linkerscript for splitting the text block into 64kByte blocks
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 27 Sep 2006 22:26:19 +0100
Links: << >>  << T >>  << A >>
On 27 Sep 2006 08:31:02 -0700, "zeeman_be" <zeemanbe@gmail.com> wrote:

>Hi all,
>
>I am implementing a microblaze processor in a subdesign in a Virtex4
>component (ISE v7.1 sp3, EDK v7.1 sp2).
>The microblaze is using the internal BRAMS as instuction and data
>memory.
>
>The program is increasing and becomes more than 64kByte. 

>It would be a solution to split the textblock in two parts.  I have
>found the instructions for writing a LinkerScript for doing that.  The
>only problem I have is to find the place where the object files of my
>code are temporary stored.

XAPP642 and Answer Record 16547 show how to locate individual functions
into segments other than "text". In fact it's even slightly simpler than
shown there. You only need to use the "Generate Linker Script" dialog to
generate a new segment (say, "text2") and locate it in your second 64K
block.

Then use the attributes as shown to place any individual functions in
text2 instead of text. No need to write linker scripts or find object
files.

(I've only used it with the PPC gcc under EDK 7.1 but see no reason why
mb should be any different in this respect)

- Brian

Article: 109521
Subject: QED files
From: IZ5FCY Roberto <iz5fcy_NOSPAMPLEASE@arrl.net>
Date: Wed, 27 Sep 2006 23:30:43 +0200
Links: << >>  << T >>  << A >>
Hi,
I'm looking for the two QED's accessory files:

qed_filt.c
qed_cgen.h

Can you help me?

Thanks, Roberto
-- 
"Malo ho'omou tokoni "
73's de IZ5FCY Roberto
-----------------------------
http://www.iz5fcy.it (work in progress..)


Article: 109522
Subject: ddr2 sodimm controller
From: waishanl@gmail.com
Date: 27 Sep 2006 15:50:14 -0700
Links: << >>  << T >>  << A >>
Hi! i am having problem to communicate between virtex4 fx60 to 512
SODIMM. I use the MIG1.6 to generate a controller. I add one module
into the design, change some names and run ModelSim. The simulation
looks fine. So, i use the ICE tools to get my bit file. When i check
all the report, I saw the map report have the follwoing message:

WARNING:MapLib:851 - Your design is using FIFO16 primitives, Please
note that
   there are additional requirements for the FIFO16 to guarantee full
   functionality. For more information regarding requirements for the
FIFO16
   primitive, please see Answer Record 22462.

is that going to cause me fail on the design? I didn't fine any .edn or
ngc file in the folder that MIG generate.

I also run the time simulation, it didn't match with the funcational
simulation. Seems like signal start fail in 200ns. Am i missing
anything?

In addition, I chipscope the signal. It seems like data did get in the
fifo. But the controller never request a read. Any ideas?

Thanks!
Wai Shan


Article: 109523
Subject: Re: PUBLISHABLE PAPER RELATED TO FPGA!
From: "Peter Alfke" <peter@xilinx.com>
Date: 27 Sep 2006 16:35:10 -0700
Links: << >>  << T >>  << A >>
Alexandre, at least you have become polite now.

The problem we all had with your original posting (besides the ALLCAPS)
was that you seem to claim that you can write a valuable article about
absolutely anything. All we need is to give you a topic.
That's pretty arrogant coming from a 23-year old student. There are
people in this newsgroup that have a professional experience much
longer than your age (double that in my case).

You might have asked: What is an interesting, somewhat unexplored
subject in FPGAs, so that I can study it, and perhaps (after a while)
contribute to it.

Peter Alfke
=======================================
solo wrote:
> Dear Miss Lazarut,
>
> It seems i am the victim of using capital letters with my words! I did
> not know in the first place that this was prohibited for a formal
> conversation.
> My whole point was to take some ideas from professionals like you for
> performing my paper related to FPGA's and optimization of placement and
> routing.
> May you help me, please?
>
> Regards!
>
> Aurelian Lazarut wrote:
> > Mr. Aoun,
> > *************
> > Alexandre Aoun
> > Computer Engineering Student
> > Mathaf Adlieh street - Beirut, Lebanon
> > Born 1983
> > *************
> > if you have anything to do with FPGA's or digital design you are
> > welcome, but you need to know your place
> > it seems that you've been caught on the wrong foot here, so you have the
> > chance to back off, read and learn, otherwise you'll become a clown in
> > this newsgroup.
> > at the end of the day it's your choice.
> >
> > Aurash
> >
> > PS, and please stop imitating Yoda from Star Wars when you post
> > messages, Syms is at least one order of magnitude better than you  ;-)
> >
> > solo wrote:
> >
> > >Mr Peter,
> > >
> > >I didnt like your reply:
> > >
> > >First, all my ideas are interesting since i am related to the field of
> > >software enginnering and i ignore the field where you come from!
> > >
> > >Second, i didnt understand the impolite word "ass-backwards" that you
> > >used and i wish that you keep those rude words for yourself and your
> > >culture!
> > >
> > >Third and most importantly, my statements are not arrogant at all! Your
> > >reply to me seems that you want to revenge from someone and this is not
> > >acceptable!
> > >
> > >Hope you be more lineant and understanding when replying to people,
> > >otherwise your replies are not interesting and will be rejected!
> > >
> > >Thanks!
> > >
> > >Peter Alfke wrote:
> > >
> > >
> > >>We may have to teach Mr Solo some basic facts:
> > >>First you must have an interesting idea or some valuable specific
> > >>knowledge.
> > >>Then, and only then, do you start writing an article.
> > >>He seems to have this ass-backwards.
> > >>Beyond that it might also be wise not to insult this newsgroup with
> > >>arrogant statements about the lust for capitalization.
> > >>Peter Alfke
> > >>=============
> > >>Todd Fleming wrote:
> > >>
> > >>
> > >>>This gives a whole new meaning to the term "partial reconfiguration"
> > >>>
> > >>>Todd
> > >>>
> > >>>jacko wrote:
> > >>>
> > >>>
> > >>>>how about single inline fpga which use veroboard spacing, and can be
> > >>>>broken off at one pin intervals.
> > >>>>
> > >>>>place 4 pins in prigrammer for power, clk, and program data, and then
> > >>>>break off to length specified by fpga compilier.
> > >>>>
> > >>>>
> > >>>>available in 1m strips maybe.
> > >>>>
> > >>>>
> > >>>>needs comparator for analog input, and as much logic in 1 pin segment
> > >>>>as possible.
> > >>>>
> > >>>>
> > >>>>flash on board prefered, with some 4 cycle dram too, for compactness.
> > >>>>
> > >>>>
> > >>>>is this the kind of thing u meant??
> > >>>>
> > >>>>
> > >
> > >
> > >
> >
> >
> > --
> >  __
> > / /\/\ Aurelian Lazarut
> > \ \  / System Verification Engineer
> > / /  \ Xilinx Ireland
> > \_\/\/
> >  
> > phone:	353 01 4032639
> > fax:	353 01 4640324


Article: 109524
Subject: Re: Pack registers (from submodule) into IOB for bidirectionnal signal
From: "Patrick Dubois" <prdubois@gmail.com>
Date: 27 Sep 2006 16:41:52 -0700
Links: << >>  << T >>  << A >>
Thanks for the good advice Brian. Small details often make a big
difference.

Patrick

Brian Drummond wrote:
> On 26 Sep 2006 14:33:03 -0700, "Patrick Dubois" <prdubois@gmail.com>
> wrote:
>
> >Hello,
> >
> >I know that this has been discussed here a few times but I still can't
> >find a definitive answer so here we go again...
> >
> >What is the best way (with Xilinx flow) to ensure that registers are
> >packed into IOB? In my case I want three registers to be packed into
> >the IOB for a bidirectionnal signal (in, out and oe).
>
> You seem to have the standard tricks...
>
> >I read quite a bit about the issue and the standard tricks seem to be:
> >1- Use the IOB = "true" constraint in the HDL code for the registers
> >2- Use the flag -iob true for xst (redundant with #1)
>
> Not only redundant, but quite dangerous since this flag appears to apply
> the IOB=TRUE attribute to every individual register (maybe only every
> register on a hierarchy boundary) regardless of whether it is anywhere
> near a pin. And this attribute prevents packing registers into
> multipliers and who knows what else...
>
> #1 applied ONLY to the registers in question gives much better control
>
> >4- Duplicate the oe registers and use equivalent_register_removal =
> >"NO" to prevent xst from optimizing them away
>
> Essential - and again, apply equivalent_register_removal as an attribute
> ONLY to the registers in question, not as an XST flag...
>
> With both of these as global flags I have seen a 15% slowdown and 20%
> greater register usage in a design.
> 
> - Brian




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