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 111575

Article: 111575
Subject: Re: Scientific Computing on FPGA
From: "Marc Battyani" <Marc.Battyani@fractalconcept.com>
Date: Mon, 6 Nov 2006 14:42:15 +0100
Links: << >>  << T >>  << A >>

"eric" <erixx@gmx.net> wrote

> There is another simple possibility to speed up calculations.
> Do you know that the GPU on a modern graphics card can do matrix
> calculations a lot times faster than a CPU? There are several
> SDKs and you wont need special Hardware for that.
>
> Xilinx and Altera stuff takes a lot of time and a high risk
> because if you really have a problem to solve the engineers from there 
> say: "This is not supported"... You get only help if you a buying in large 
> quantaties.
>
> And in scientific computing you never have a large quantatie.
>
>
> So use alternativly a GPU for fast calculations like FFT and Sorting.
>
> My favorite SDK is BrookGPU 
> (http://graphics.stanford.edu/projects/brookgpu/).
> Easy to use and a lot of out oft the box runnig examples. It works with
> every modern 3d Accellertor because it uses OpenGL and DirectX.
>
> You will implement the stuff in a week or two. In VHDL you'll need half a 
> year for the simulation and timig stuff for the same result.
>
> Think about it!

GPU have a lot of limitations like single precision FP, memory 
bandwitdh/latency and organization, computation model, etc.

Well it's the old ASIC(fixed) vs FPGA topic ;-)

Marc



Article: 111576
Subject: Global Clocks in Xilinx Virtex-4
From: "uvbaz" <uvbaz@stud.uni-karlsruhe.de>
Date: 6 Nov 2006 05:50:34 -0800
Links: << >>  << T >>  << A >>
hallo everyone,

I know that global clocks allow distributing the clock signal all over
the FPGA with a low skew, but what happens, when i feed the clock e.g.
my_clk into FPGA through a normal user I/O pin?

I have set  XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the
error in Xilinx ISE,  my interest ist: what will happen with my_clk?

Goes it after the input buffer still to the global clock buffer, or
wires will be routed to all the flip-flops, which my_clk connectecd to?
or somehow else?

Thanks for your answer

Regard,
Cheng


Article: 111577
Subject: Re: reset
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 6 Nov 2006 06:06:59 -0800
Links: << >>  << T >>  << A >>

radarman wrote:
> martstev@gmail.com wrote:
> > I am using Altera Stratix II FPGA and also power supervisor circuit
> > which generates reset which it tied to  nCONFIG for configuration of
> > the FPGA. Now, I'd like to generate RESET for the FPGA after the
> > configuration and  Initialization is complete everytime. I can't find a
> > part that can do that..any suggetions?
>
> If you are reconfiguring the part on reset, why do you want to reset
> the design again? The design will come up in the "reset" state after
> configuration. Perhaps I'm missing something, but it seems redundant to
> async reset an FPGA right after configuration?

One case might be when you want the reset behaviour to set a flip flop
to '1' instead of '0' (like in a one hot state machine encoding) and
the synthesis tool/target device combo doesn't happen to support this.
If you have this, then the problem is with the synthesis tool (so open
a service request and raise your beef) but in the mean time you need a
work around.  So if you happen to have that particular scenario, but
your device globally clears all flip flops to 0 then you could use the
"reset to 0 coming out of configuration" to create an internal reset
signal for the rest of the design.  Then you use that internal reset
signal to put the entire design into the state that you want as
specified by your HDL instead of as specified by the device
manufacturer.

KJ


Article: 111578
Subject: Re: Scientific Computing on FPGA
From: reiner@hartenstein.de
Date: 6 Nov 2006 06:10:32 -0800
Links: << >>  << T >>  << A >>
Tommy Thorn wrote:
> lancepickens@gmail.com wrote:
> > Hi,
> > Coming from a scientific computing standpoint (with no hardware
> > experience).
> > I was wondering if you can improve any dedicated tasks by designing a
> > special
> > purpose chips ala FPGA to run your code? Does anyone have any
> > experience
> > with this?

Tommy,

There is a lot of papers around about software to FPGA migration
projects. (The highest speed-up factor I found there is 6000.) A few of
them are referenced in:
http://xputers.informatik.uni-kl.de/staff/hartenstein/lot/HartensteinWRCE06.pdf

Rainier
> 
> Yes.
> 
> Tommy


Article: 111579
Subject: Cypress 68013 - Xilinx FPGA
From: "al99999" <alastairlynch@gmail.com>
Date: 6 Nov 2006 06:22:59 -0800
Links: << >>  << T >>  << A >>
Hi everyone,

I am trying to add a USB 480Mbps interface to my fpga design which will
stream data in one direction only from the FPGA to PC.

The avnet evaluation board I have has the Cypress 68013 chip.

Can anybody point me in the right direction of where to start (or which
is the most suitable application note on the cypress website), and if
there is any sample cores to embed on the fpga.

Thanks very much,

Al


Article: 111580
Subject: Re: Cypress 68013 - Xilinx FPGA
From: "Will Dean" <will@nospam.demon.co.uk>
Date: Mon, 6 Nov 2006 14:36:32 -0000
Links: << >>  << T >>  << A >>
"al99999" <alastairlynch@gmail.com> wrote in message 
news:1162822979.389980.211390@h54g2000cwb.googlegroups.com...
>
> The avnet evaluation board I have has the Cypress 68013 chip.
>
> Can anybody point me in the right direction of where to start (or which
> is the most suitable application note on the cypress website), and if
> there is any sample cores to embed on the fpga.

Use the 'slave fifo' interface of the 68013.
Use it in one of its synchronous modes.  (I tend to clock the FPGA off the 
48MHz clock from the 68013).
After that, it's really simple, provided you've set the 68013 up correctly - 
you watch the appropriate 'fifo-full' flag from the 68013 and drive data in 
accordingly.  You need the technical reference manual for the 68013 (FX2), 
not just the datasheet.   (Both from Cypress' TERRIBLE website)

You will probably find that the PC is a bottleneck, particularly if you 
don't make an effort to keep lots of overlapped reads queued on to the USB 
driver.

If you've never done anything with USB or device drivers before, start with 
the Cypress "USB developer uStudio" or whatever they call it (CY4604) - the 
CyUSB.sys generic driver.  I can never find it on their TERRIBLE website, 
but it's there somewhere.

The FPGA -> FX2 link is trivial.  The rest of the development might be 
harder.

Will




Article: 111581
Subject: Re: Interface standards (was Re: Dual Port RAM)
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Mon, 6 Nov 2006 14:37:22 -0000
Links: << >>  << T >>  << A >>
Hi KJ,

>>> Tell me what prevents everyone from standardizing on an interface to
>>> their components in a manner similar to what LPM attempts to do?  The
>>> chip guys do it for their parts, the FPGA vendors don't seem to want to
>>> do anything similar on the IP core side.
>> I don't think anything prevents it, other than whatever all-pervading 
>> force there is in the universe which prevents people from agreeing about 
>> things. :-)
> But it's not really an all-pervading force.  If it were we wouldn't have 
> any standards like PCI, I2C, PCI Express, DDR....on and on and on.  So 
> where is the list of interface standards for inside the chip?

I wish I could be that idealistic! :-) Here are two questions to which I 
don't have precise answers:

 (1) How many DDR SDRAM chips were sold worldwide in 2005?
 (2) How many FPGA IP cores were sold worldwide in 2005?

With or without actually finding the answers, now speculate as to the 
relative importance of standardization for these two application areas.

> Wishbone is about it for FPGAs...and it needs some work but it's not bad.

It's not one-size-fits-all though; in fact, nothing really is. That is half 
of the problem. Many of the more interesting IP cores use variable and/or 
non-standard word sizes, have non-obvious flow control requirements stemming 
from extensive pipelining and buffering, and so on.

If every FPGA user just wanted to build SoCs based around a microprocessor 
with a big old local bus with all the peripherals hanging off it, then life 
would be much easier. As it is, we try to provide the most flexible 
interfacing options possible, so that no-one is prevented from using a 
particular core just because their system is wired together in a way that we 
hadn't thought of.

> So do the big guys all support Wishbone?  Build it into their system 
> design tools? Ummmm....well....no....what do they support?  Well, here is 
> the Brand A 'standard', brand X standard etc.

In an embedded system-builder context, brand A have their proprietary bus, 
whereas brand X's bus structure did at least come from IBM (which in my mind 
makes it "somewhat more standard"; you may of course disagree).

When it comes to "raw" IP blocks, the basic, pervasive idioms of two-wire 
synchronous handshakes and simple flow-controlling pulses are simple to 
comprehend and use. The names and exact timings may be different but if you 
go and compare the datasheet-specified interface for a brand X Turbo Encoder 
and the brand A equivalent, you'll probably find there's very little 
difference.

> Choosing a standard based on features and performance that are relevant is 
> exactly the right thing.  That's not what you're basing your decision on 
> between 'X' and 'A'.

I would respectfully disagree, certainly as far as embedded processing is 
concerned. Sure, there are many other important factors, and many people do 
treat - or try to treat - FPGAs as commodity products, but I would certainly 
not make a big A vs X purchasing decision without making a diligent study of 
the relative merits of the microprocessor interfaces favoured by each 
vendor.

Cheers,

       -Ben- 



Article: 111582
Subject: Re: reset
From: Ray Andraka <ray@andraka.com>
Date: Mon, 06 Nov 2006 09:38:15 -0500
Links: << >>  << T >>  << A >>
KJ wrote:


> One case might be when you want the reset behaviour to set a flip flop
> to '1' instead of '0' (like in a one hot state machine encoding) and
> the synthesis tool/target device combo doesn't happen to support this.
> If you have this, then the problem is with the synthesis tool (so open
> a service request and raise your beef) but in the mean time you need a
> work around.  So if you happen to have that particular scenario, but
> your device globally clears all flip flops to 0 then you could use the
> "reset to 0 coming out of configuration" to create an internal reset
> signal for the rest of the design.  Then you use that internal reset
> signal to put the entire design into the state that you want as
> specified by your HDL instead of as specified by the device
> manufacturer.
> 
> KJ
> 

Or just invert the inputs and outputs of the ff you need initialized to 
a '1'.

Article: 111583
Subject: Re: Interface standards (was Re: Dual Port RAM)
From: John_H <newsgroup@johnhandwork.com>
Date: Mon, 06 Nov 2006 14:41:05 GMT
Links: << >>  << T >>  << A >>
Martin Thompson wrote:
> Maybe I'll regret jumping in here, but here's my take :-)
> 
> We designers want standard interfaces to FPGA bits and bobs.

<snip>

It's nice to hear another opinion, but....  I have a software guy that 
wants us FPGA designers to standardize on 16550 UARTs for our embedded 
designs.  WTF?!  This device is from a quarter century ago and made to 
work with serial links that are quite a bit worse than the embedded 
applications I have today.

WHY is a standard interface desired when much of what "was" there can 
become completely superfluous?

Personally - and this is opinion as it is with the other posts - I want 
to get the best performance/cost/size balance I can strike.  Why should 
I burden my design with bloated code to pacify others who want to blow 
my performance, increase my cost, or bloat the size?

If you want a standard interface, make one.  PLEASE don't force me to 
use silicon with hard-coded features that are much less than what they 
could be all for the sake of conformance.

The only time I would care to see a standard interface pursued is if 
there is ZERO impact to my engineering tradeoffs.

- John_H

Article: 111584
Subject: Re: DSP48 carry logic for multi-precision addition
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Mon, 6 Nov 2006 14:47:39 -0000
Links: << >>  << T >>  << A >>
Hi Tim,

"Tim" <gueneysu@crypto.rub.de> wrote in message 
news:1162575331.736771.230780@h48g2000cwc.googlegroups.com...
> Sorry for my unclear explanation. Using your simplification with 64
> bits my goal is to do the following chain of full 64 additions (for
> example 3 operations a 64 bit):
>
>   BA   [DSP #1; A:B ]
> + DC   [DSP #1; C]
> + FE   [DSP #2, A:B]  <<--- takes PCIN from DSP #1
> + HG   [DSP #3, A:B]  <<--- takes PCIN from DSP #2
> --------
> (Z)YX  [3, P]

Ah, I see, you're doing a 256-bit accumulation. In this case, I'm not sure 
that there's much that can be done within an architecture like that, because 
as you say, the "dummy" top bits of the result will be changed depending on 
the carry and there's no way to mask them out when you feed back the P 
output value for further accumulation.

Personally, I would structure the computation as a fully-parallel adder tree 
(assuming you really do have four inputs, and not some nasty number). That 
does require moving the intermediate results through the fabric, but it's 
not too hard to pipeline it - you'll probably need to introduce some 
registers to balance the latency anyway. I'd also consider using more than 
just 32 bits out of each DSP slice; why use 8 DSP blocks when you could use 
just 6?

At least it sounds like you have a good handle on what you're trying to do, 
so good luck!

Cheers,

       -Ben- 



Article: 111585
Subject: Re: Global Clocks in Xilinx Virtex-4
From: "Paul" <pauljbennett@gmail.com>
Date: 6 Nov 2006 06:54:47 -0800
Links: << >>  << T >>  << A >>
Cheng,

   I am in the middle of a Virtex4 design myself and have gone back and
forth with Xilinx about clock routing.  The documentation is very poor,
particularly with respect to the regional clock boundaries.

   As I understand it, yes you can drive a BUFG from anywhere in the
FPGA fabric if you want, however the routing is not ideal.  So, while
you still have no skew problems within the FPGA, because everything is
on the global clock net, you could have skew problems with any other
system synchronous devices in the design. (i.e. sync. srams, etc...
ddr sdrams will be source syncronous, so there is no problem here)...


   To confirm this though...  I would run ISE with your design and
follow the routing in FPGA Editor just to be POSITIVE that everything
routed as you wanted.  This is just what I recall.




uvbaz wrote:
> hallo everyone,
>
> I know that global clocks allow distributing the clock signal all over
> the FPGA with a low skew, but what happens, when i feed the clock e.g.
> my_clk into FPGA through a normal user I/O pin?
>
> I have set  XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the
> error in Xilinx ISE,  my interest ist: what will happen with my_clk?
>
> Goes it after the input buffer still to the global clock buffer, or
> wires will be routed to all the flip-flops, which my_clk connectecd to?
> or somehow else?
> 
> Thanks for your answer
> 
> Regard,
> Cheng


Article: 111586
Subject: Re: reset
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 6 Nov 2006 06:57:32 -0800
Links: << >>  << T >>  << A >>
>
> Or just invert the inputs and outputs of the ff you need initialized to
> a '1'.

That can work in certain instances, but you'll have difficulty
'inverting' an enumerated type signal that gets encoded via a one hot
(or any other) encoding.  See the following code snippet below for a
good example.  Generating the reset signal itself is much cleaner and
puts the device into a state as defined by the HDL code itself and not
in some arbitrary (but useful) predefined state that has been defined
by the FPGA/CPLD vendor.

type t_FOO is (Init, Idle, Do_Something, Do_Something_Else,
Phone_Home);
signal My_State_Variable:  t_FOO;
...
process(Clock)
begin
  if rising_edge(Clock) then
     if (Reset = '1') then
        My_State_Variable <= Init;
    else
......

KJ


Article: 111587
Subject: Re: reset
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 06 Nov 2006 15:03:59 +0000
Links: << >>  << T >>  << A >>
"ALuPin@web.de" <ALuPin@web.de> writes:

> No.
> 
>  := (others=>'0');
> 
> in signal declarations are not synthesizable.
> 

That depends on your synthesiser.  If you are initalising to some
constant value that the synth can figure out, XST can do it and I
think Synplify does it as well.

About time too, given that the hardware has been able to use it for
years (or even decades!)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

   

Article: 111588
Subject: Re: PCIe latency
From: Andreas Ehliar <ehliar@lysator.liu.se>
Date: Mon, 6 Nov 2006 15:47:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
On 2006-11-06, slkjas@gmail.com <slkjas@gmail.com> wrote:
> Hi
>
> Im trying to design a high speed data capture card. Im using a Lattice
> ECP2M-50 FPGA with the one-board SERDES units (MGBT in Xilinx
> dtasheets). Im using a MSPS Nation ADC. This dual ADC has a output of
> 1Gb/s and thus the combined x4 lane PCIe will match this rate. HOWEVER,
> if there is latency on the PCIe bus more than 100us then my RAM inside
> the FPGA will overflow. I need to know bus latency between TLP's
> because i need to know if I require external RAM or if the design in
> possible!


First of all, this post assumes you mean Gigabyte/s (GB/s) since you are
talking about matching the rate with a 4 lane PCIe configuration.


I see at least one real problem here:

PCIe has a link speed of 2.5 GHz per lane. After 8B/10B decoding you
will have 250 MB/s. With 4 lanes you will get 1000 MB/s. (Exactly what
you need.)

Unfortunately you will have protocol overhead. This means that you
will not even theoretically be able to push data in the speed required
by your application (Assuming that you truly need 1 GB/s and not say
for example 950 MB/s.)

Perhaps you can design the card so that in case of emergency (your
PCIe host cannot accept your packets fast enough) you will reduce
the precision of your samples from 8 bits (which I assume you use)
to 4 bits and somehow tell your application that the precision is
not enough.


But quite a lot depends on your application. For example:
1. Do you just want to store as much data as you can fit into your main
   memory?
2. Do you intend to do some sort of real time processing on the data
   in your host?
3. As mentioned earlier, do you truly need exactly 1GB/s? In that case,
   you will need more than 4 lanes...

If 1, perhaps you can use 7 bits / sample instead to reduce the required
bandwidth. If 2, perhaps you can do some processing on the data in the FPGA
to reduce the bandwidth.


As for latency, my guess is that the latency should be far less than 100us.
But personally I would not feel very safe unless I had some guarantee from
the host system that a certain bandwidth to main memory was reserved for
my PCIe card. (At least if the required bandwidth is very close to the
theoretical maximum when using maximum sized packets.)

I guess your google skills are as good as mine, but I could point out
http://nowlab.cse.ohio-state.edu/publications/journal-papers/2005/liuj-ieeemicro05.pdf
where the latency and bandwidth of PCI express based Infiniband HCA:s are
tested. The latency of a small message is around 3.8 us in this case so
from that point of view, 100us should be more than enough.

/Andreas

Article: 111589
Subject: surprised output of Xilinx Virtex-4
From: "uvbaz" <uvbaz@stud.uni-karlsruhe.de>
Date: 6 Nov 2006 07:51:38 -0800
Links: << >>  << T >>  << A >>
hallo everyone,

I am here again, :)

I have download my program to my Xilinx Virtex-4 FPGA, and connect the
Oscilloscope to the output. But the output seems to be strange, i have
the Bild uploaded to the URL:

http://homepage.ruhr-uni-bochum.de/Qian.Tang-2/cheng/D012.jpg

Thanks for your answer, ;)

Regards,
Cheng


Article: 111590
Subject: Xilinx GSR/reset levels (was: Re: reset)
From: Evan Lavelle <eml@nospam.uk>
Date: Mon, 06 Nov 2006 16:00:37 +0000
Links: << >>  << T >>  << A >>
On 3 Nov 2006 13:04:07 -0800, "radarman" <jshamlet@gmail.com> wrote:

>If you are reconfiguring the part on reset, why do you want to reset
>the design again? The design will come up in the "reset" state after
>configuration. Perhaps I'm missing something, but it seems redundant to
>async reset an FPGA right after configuration?

Don't know about Stratix, but I guess there may be timing problems
with the configuration reset, so you might want to do a proper timed
reset afterwards.

[OT for Altera...]

Many Xilinx devices will let you set a F/F to one level on GSR, and
the opposite level on a 'normal' reset, by setting SRHIGH(LOW)
differently from INIT1(0). What's the point of that? Beats me.

Curiously, in the Spartan-3 you get an INIT attribute to set
SRHIGH/SRLOW, but no attribute to set INIT1/INIT0. To set those you
have to manually instantiate an FDSE/FDPE or an FDRE/FDCE component.
Did Xilinx give us the wrong attribute? If we had something to set
INIT1/0 instead, then SRHIGH/LOW would automatically default
"correctly",  and you wouldn't need to manually select a set or a
reset F/F.

And how about a sync/async attribute? I can't find one of those
either.

Evan

Article: 111591
Subject: Re: To Xilinx guys out there - microblaze mapping problem
From: me_2003@walla.co.il
Date: 6 Nov 2006 08:08:36 -0800
Links: << >>  << T >>  << A >>
Hi Goran,

Is there any way to instruct the platgen not to use RLOC for the
microblaze?
It is just that now (after doing what you suggested above) my mapping
went well but the PAR fails - It says that a certain core (xilinx
reed-solomon decoder) cannot be placed. I figured out that maybe the
RLOCs of the microblaze causes this problem (my chip utilization is
under 50%).
Thanks in advance, Mordehay.

error snippet from par log file :

---------------------------------------------------------------------------=
-----------------------------------------------
Starting Placer

Phase 1.1
ERROR:Place:346 - The components related to The RPM
   "CORE/RFEC_i/rs_dec_i/rs_docoder_i/rs_dec/dec/sy/nig1/ffo1/r1" can
not be
   placed in the required relative placement form

The following components are part of this structure:
   SLICEM CORE/RFEC_i/rs_dec_i/rs_docoder_i/N207
   SLICEL CORE/RFEC_i/rs_dec_i/rs_docoder_i/N19412
   SLICEL CORE/RFEC_i/rs_dec_i/rs_docoder_i/N19411
   SLICEL CORE/RFEC_i/rs_dec_i/rs_docoder_i/N19409
   SLICEM CORE/RFEC_i/rs_dec_i/rs_docoder_i/N208
   SLICEM CORE/RFEC_i/rs_dec_i/rs_docoder_i/N204
   SLICEM CORE/RFEC_i/rs_dec_i/rs_docoder_i/N202

The reason for this issue is the following:
This logic may be too large or of too irregular shape to fit on the
device.
---------------------------------------------------------------------------=
-----------------------------------------------





Article: 111592
Subject: Re: Global Clocks in Xilinx Virtex-4
From: Ray Andraka <ray@andraka.com>
Date: Mon, 06 Nov 2006 11:09:45 -0500
Links: << >>  << T >>  << A >>
uvbaz wrote:

> hallo everyone,
> 
> I know that global clocks allow distributing the clock signal all over
> the FPGA with a low skew, but what happens, when i feed the clock e.g.
> my_clk into FPGA through a normal user I/O pin?
> 
> I have set  XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the
> error in Xilinx ISE,  my interest ist: what will happen with my_clk?
> 
> Goes it after the input buffer still to the global clock buffer, or
> wires will be routed to all the flip-flops, which my_clk connectecd to?
> or somehow else?
> 
> Thanks for your answer
> 
> Regard,
> Cheng
> 

You should instantiate a bufg on your clock net to make sure it gets 
onto the global routing.  Not all synthesis tools automatically insert 
that buffer, and without it, you won't get on the global clock net. 
Assuming you do have that buffer, the clock that is distributed in the 
FPGA will have low skew, but there will be a sizable offset from the 
external clock.  That may cause problems with communicating with devices 
external to the FPGA.

Article: 111593
Subject: Re: surprised output of Xilinx Virtex-4
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Mon, 06 Nov 2006 16:14:43 +0000
Links: << >>  << T >>  << A >>
On 6 Nov 2006 07:51:38 -0800, "uvbaz" 
<uvbaz@stud.uni-karlsruhe.de> wrote:

>http://homepage.ruhr-uni-bochum.de/Qian.Tang-2/cheng/D012.jpg

I hope this is not insulting...

have you checked that your 'scope probe is correctly compensated?
Try looking at a known good square wave, for example the 
oscilloscope's calibration output.  Also, check that the scope's
ground wire is properly connected.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 111594
Subject: Re: choise of fpga platform
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Mon, 06 Nov 2006 16:16:53 +0000
Links: << >>  << T >>  << A >>
On 6 Nov 2006 02:02:38 -0800, "tsemer" <tsemertzidis@gmail.com> wrote:

>I need a fast fpga because the signal will be proccessed @ near 800Mhz.

Don't forget: one bit at 800MHz can be processed as eight bits at 
100MHz, or sixteen bits at 50MHz.  Maybe you don't need such
a fast FPGA after all, but only some ingenuity about how you 
handle the inputs.  What is the signal?
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 111595
Subject: Re: Interface standards (was Re: Dual Port RAM)
From: Ray Andraka <ray@andraka.com>
Date: Mon, 06 Nov 2006 11:19:03 -0500
Links: << >>  << T >>  << A >>
I couldn't agree more, John.  I have no use for primitives, or IP for 
that matter, that has been crippled or bloated in order to comply with 
some arbitrary "standard" that is not likely to match my needs anyway.

Much more important is complete, concise, and clear documentation, 
visibility into the guts of the IP, and tools that work properly.

Article: 111596
Subject: Re: Global Clocks in Xilinx Virtex-4
From: "Alan Nishioka" <alan@nishioka.com>
Date: 6 Nov 2006 08:23:28 -0800
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> uvbaz wrote:
> > I know that global clocks allow distributing the clock signal all over
> > the FPGA with a low skew, but what happens, when i feed the clock e.g.
> > my_clk into FPGA through a normal user I/O pin?
>
> You should instantiate a bufg on your clock net to make sure it gets
> onto the global routing.  Not all synthesis tools automatically insert
> that buffer, and without it, you won't get on the global clock net.
> Assuming you do have that buffer, the clock that is distributed in the
> FPGA will have low skew, but there will be a sizable offset from the
> external clock.  That may cause problems with communicating with devices
> external to the FPGA.

Also, the sizable offset will probably change every time you recompile
the project.

Alan Nishioka


Article: 111597
Subject: Re: reset
From: Ray Andraka <ray@andraka.com>
Date: Mon, 06 Nov 2006 11:33:40 -0500
Links: << >>  << T >>  << A >>
KJ wrote:

>>Or just invert the inputs and outputs of the ff you need initialized to
>>a '1'.
> 
> 
> That can work in certain instances, but you'll have difficulty
> 'inverting' an enumerated type signal that gets encoded via a one hot
> (or any other) encoding.  See the following code snippet below for a
> good example.  Generating the reset signal itself is much cleaner and
> puts the device into a state as defined by the HDL code itself and not
> in some arbitrary (but useful) predefined state that has been defined
> by the FPGA/CPLD vendor.
> 
> type t_FOO is (Init, Idle, Do_Something, Do_Something_Else,
> Phone_Home);
> signal My_State_Variable:  t_FOO;
> ...
> process(Clock)
> begin
>   if rising_edge(Clock) then
>      if (Reset = '1') then
>         My_State_Variable <= Init;
>     else
> ......
> 
> KJ
> 

But in that case, you don't care what the encoding is, so you don't need 
to be specifying a particular flip flop get set to '1'.

For the xilinx devices, you can use the ROC primitive to generate a 
power on reset in your HDL code.  The tools pull it out, but in the 
process in guarantees the setting of the initial values to the states 
you want them  in.


	POR: roc
	port map(O => power_on_reset);

	process(clk,power_on_reset)
	begin		
		if power_on_reset = '1' then
			<initial values for any type of signal>	
			
		elsif rising_edge(clk) then	



Article: 111598
Subject: Re: surprised output of Xilinx Virtex-4
From: "uvbaz" <uvbaz@stud.uni-karlsruhe.de>
Date: 6 Nov 2006 08:40:03 -0800
Links: << >>  << T >>  << A >>
Hi Jonathan,

No, it is not insulting at all.

Auctually there is an Agilent Softtouch Probes on the FPGA Board(for
Logic Analyser), i connected the oscilloscope to the end auf the
Agilent Cable, and got the stranger picture.

There is another connector direct on the Board, i've just reconfigure
the FPGA, so that the FPGA put the output onto this connector, and then
i've got the right square wave. It is likely that, this Agilent Cable
caused the Problem.

Thanks! You have right. But how come you  to the point, that the
problem there is?

Thanks again.
Regards,
Cheng


Jonathan Bromley schrieb:

> On 6 Nov 2006 07:51:38 -0800, "uvbaz"
> <uvbaz@stud.uni-karlsruhe.de> wrote:
>
> >http://homepage.ruhr-uni-bochum.de/Qian.Tang-2/cheng/D012.jpg
>
> I hope this is not insulting...
>
> have you checked that your 'scope probe is correctly compensated?
> Try looking at a known good square wave, for example the
> oscilloscope's calibration output.  Also, check that the scope's
> ground wire is properly connected.
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.bromley@MYCOMPANY.com
> http://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.


Article: 111599
Subject: Re: surprised output of Xilinx Virtex-4
From: "uvbaz" <uvbaz@stud.uni-karlsruhe.de>
Date: 6 Nov 2006 08:57:30 -0800
Links: << >>  << T >>  << A >>
^_^ ^_^

Yes, i will try it.

Regards,
Cheng


MM schrieb:

> "uvbaz" <uvbaz@stud.uni-karlsruhe.de> wrote in message
> news:1162831203.738143.159650@h54g2000cwb.googlegroups.com...
> >
> > i connected the oscilloscope to the end auf the
> > Agilent Cable, and got the stranger picture.
>
> Try longer cable and the picture will be even "stranger"...
> 
> 
> /Mikhail




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