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 91850

Article: 91850
Subject: Re: Using JTAG cable for general comms
From: derek <derek.wallace@NOSPAM.s3group.com>
Date: Tue, 15 Nov 2005 11:35:11 +0000
Links: << >>  << T >>  << A >>
Hi,
The following Xilinx Xcell article describes how you can use the JTAG port
of a Xilinx FPGA as a general comms channel to a design. One of the uses
we have for it is to replace the RS232 as the serial comms channel to designs.
http://www.xilinx.com/publications/xcellonline/xcell_53/xc_jtag53.htm

The example GNAT design can be downloaded for free from here.
http://www.s3group.com/system_ic/gnat/

It includes the GNAT design and also supplies some sample TCL illustrating
how you can pass data into and out of the FPGA.

Derek

nchandra@gmail.com wrote:

> Hello,
> 
> Is it possible to use a JTAG cable connection to transfer data into and
> out of an FPGA during regular operations? The situation is like this:
> we have a Xilinx Spartan 3 board that we are programming with a
> digilent parallel cable. This works fine. We would also like to
> transfer data into and out of the FPGA, for which we are currently
> using serial communications (RS232), but the data rate is now becoming
> a bottleneck.
> 
> The JTAG cable, connected through the parallel port, should be capable
> of doing much higher speeds than RS232. It is, however, connected to
> the JTAG pins of the FPGA. Can this somehow be used to transfer data in
> and out without redesigning the board in any way? Is there any software
> that could be a starting point for this?
> 
> Thanks,
> 
> Nitin Chandrachoodan
> 

Article: 91851
Subject: Re: Having trouble Detecting ethernet packets using ethereal
From: Rene Tschaggelar <none@none.net>
Date: Tue, 15 Nov 2005 12:36:03 +0100
Links: << >>  << T >>  << A >>
ashwin wrote:

> Hello Everyone again,
>[snip]
> Probably the data is getting transferred on to the PC, but not able to
> capture it since, i am not  pinging it.  So how do we see what data is
> coming out from the PHY. 
> 
>  Please advice ?

With a fast digital oscilloscope ?

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Article: 91852
Subject: Re: Help needed to design recursive digital circuit
From: backhus <nix@nirgends.xyz>
Date: Tue, 15 Nov 2005 12:39:42 +0100
Links: << >>  << T >>  << A >>
PiyushG schrieb:
> Hi all
> I have problem in designing a circuit which is recursive
> 
> Suppose i am designing a schematic of BRLSHIFTER  and suppose i want
> assign all outputs to inputs then what changes should I made in ".vhf"
> file?
> 
> Thanking you
> 
Hi Piyush,
first of all...why do you want to manipulate your *.vhf file?
if you are designing a schematic, you can use your schematic editor, 
which creates a *.sch file. The *.vhf file is generated from the 
schematic file, and might be overwritten by the IDE.

Now, if you already have designed your barrelshiftersave it, go back to 
the ide and generate a symbol out of the schematic (Look under design 
entry tools). Open a new schematic and place the barrel schifter symbol 
there. Well, now you are free to connect the outputs to the inputs with 
a bus or wires, if it makes any sense.
Maybe you should think about a multiplexer, to feed in your initial data 
and then switch to the feedback, and a register would be nice to prevent 
a combinatorial loop, if your barrel shifter doesn't already have it.



At last please tell me what you mean by "recursive"? Recursion is not 
equal to feeding data back into a function (block), which can be seen as 
looping. In software it only works, because you have lots of RAM and 
your function can allocate new workspaces (for variables etc.) until the 
problem deepth is reached and the results can be accumulated somehow on 
the way back to the first calling function, or...until your ram limit is 
reached. (Without thinking about the stack)
This is a virtual behavior. Workspaces are created as needed.
How should that happen in hardware? Function blocks do not virtually pop 
out of nowhere.
It is surely possible to create a hardware that behaves to a certain 
limit like a recursive algorithm, but then, only a very limited number 
of algorithms need real recursion. In software mostly everything can be 
expressed different, though not even as elegant.

have a nice synthesis
   Eilert



Article: 91853
Subject: Re: Having trouble Detecting ethernet packets using ethereal
From: Aurelian Lazarut <aurash@xilinx.com>
Date: Tue, 15 Nov 2005 12:06:09 +0000
Links: << >>  << T >>  << A >>
Or with a not so fast oscilloscope if you force 10Mb/s from the PC end link.
Aurash
Rene Tschaggelar wrote:

> ashwin wrote:
>
>> Hello Everyone again,
>> [snip]
>> Probably the data is getting transferred on to the PC, but not able to
>> capture it since, i am not  pinging it.  So how do we see what data is
>> coming out from the PHY.
>>  Please advice ?
>
>
> With a fast digital oscilloscope ?
>
> Rene



-- 
 __
/ /\/\ Aurelian Lazarut
\ \  / System Verification Engineer
/ /  \ Xilinx Ireland
\_\/\/
 
phone:	353 01 4032639
fax:	353 01 4640324
    
     

Article: 91854
Subject: Multiple instantiation in SystemC
From: "Moises" <moises.paniagua@gmail.com>
Date: 15 Nov 2005 04:08:51 -0800
Links: << >>  << T >>  << A >>
Hi,

I have followed the design in systemC, but I have some troubles when
instantiating  multiples components.  In bankreg.h I have the
instantiation of several registers.

The problem is that  after execution, I have the following errors for
each register:

Warning: (W505) object already exists: bankreg.memory.port_0. Latter
declaration  will be ignored In file: sc_object.cpp:164
Warning: (W505) object already exists: bankreg.memory.port_1. Latter
declaration  will be ignored In file: sc_object.cpp:164
Warning: (W505) object already exists: bankreg.memory.port_2. Latter
declaration  will be ignored In file: sc_object.cpp:164
Warning: (W505) object already exists: bankreg.memory.port_3. Latter
declaration  will be ignored In file: sc_object.cpp:164
Warning: (W505) object already exists: bankreg.memory.port_4. Latter
declaration  will be ignored In file: sc_object.cpp:164
Warning: (W505) object already exists: bankreg.memory.behaviour. Latter
declaration  will be ignored In file: sc_object.cpp:164
Error: (E112) get interface failed: port is not bound: port
'bankreg.port_4'  (sc_out)
Error: (E112) get interface failed: port is not bound: port
'bankreg.port_7'  (sc_out)

Find attached both .h files:
//bankreg.h
#include "librairie.h"
#include "reg.h"
#ifndef __bankreg_h__
#define __bankreg_h__
SC_MODULE(bankreg) {
//sc_in<bool>		    clearn;
sc_in<sc_uint<MAX_BIT> >            new_data[MAT_WIDTH];
sc_in<bool>  		    enable_data;
sc_in<bool>      	                    clk;
sc_in<bool>		    reset_intern;
sc_out<sc_uint<MAX_BIT> > output[MAT_LENGTH][MAT_WIDTH];
sc_signal<sc_uint<MAX_BIT> > out_reg[MAT_LENGTH][MAT_WIDTH];

SC_CTOR(bankreg)   {

reg<MAX_BIT> *memory[MAT_LENGTH][MAT_WIDTH];

for (int i=0; i < MAT_LENGTH; i++) {
  for (int j=0; j < MAT_WIDTH; j++) {
    memory[i][j] = new reg<MAX_BIT>("memory");
    if (i==0) {
      memory[i][j]->input(new_data[j]);
      memory[i][j]->enable(enable_data);
      memory[i][j]->clearn(reset_intern);
      memory[i][j]->clk(clk);
      memory[i][j]->output(out_reg[i][j]);
    } else {
      memory[i][j]->input(out_reg[i-1][j]);
      memory[i][j]->enable(enable_data);
      memory[i][j]->clearn(reset_intern);
      memory[i][j]->clk(clk);
      memory[i][j]->output(out_reg[i][j]);
    }
   }
  }
  for (int i=0; i < MAT_LENGTH; i++) {
    for (int j=0; j < MAT_WIDTH; j++) {
       output[i][j] = (out_reg[i][j]).read();
    }
   }
 }
};
#endif

//reg.h
#include "librairie.h"
#ifndef __reg_h__
#define __reg_h__
template <int size> SC_MODULE(reg) {
  const static int MAX = size;
  sc_in<sc_uint<MAX> >  input;
  sc_in<bool>  		enable;
  sc_in<bool> 		clearn;
  sc_in<bool>		clk;
  sc_out<sc_uint<MAX> >	output;

  unsigned int value;

  void behaviour()   {
    if (clearn == false){
     value = 0;
    } else if (enable) {
       value = input.read();
    } else {       value = value;
    }     output = value;   }
  SC_CTOR(reg)   {
    SC_METHOD(behaviour);
       sensitive_pos << clk;
  } };

#endif

Many thanks for your help. Moreover, does anybody know any site to
visit in  order to get SystemC examples?  

Moises


Article: 91855
Subject: Research Position
From: "Gunter Knittel" <knittel@gris.uni-tuebingen.de>
Date: Tue, 15 Nov 2005 13:37:38 +0100
Links: << >>  << T >>  << A >>
Hi Folks,

I just wanted to make you aware of an open research
position we have at WSI/GRIS, Tuebingen University,
Germany, in the area of FPGA design, physical simulations,
and computer graphics. If you're interested, have a look
at our web site at

http://www.gris.uni-tuebingen.de/

The project title is:
"Hardware-Accelerated Simulations of Textiles and Tissue".

Regards,
G. Knittel 



Article: 91856
Subject: Re: RoHS
From: "PeteS" <ps@fleetwoodmobile.com>
Date: 15 Nov 2005 04:51:23 -0800
Links: << >>  << T >>  << A >>
To expand on Rene's comment, there's no way around RoHS compliance
**anywhere**. Molex, for instance, has obsoleted all it's high density
parts (to my knowledge) in favour of new RoHS compliant parts. They are
probably doing this across the board, as they don't want to keep
different stocks on hand with the logistics nightmare involved.

As to high speed problems:

Different materials will undoubtedly cause impedance vectors to change.
In addition, the loss tangents across materials (very important in
extremely high frequency designs) will vary. Whether they will be
better or worse is unknown, but after all the research into existing
materials, my take is they will be worse.

IC packaging will have to change. Most existing plastic packages have
absolute maximum temperature ratings of about 220C, but the RoHS reflow
profile is well above this (about 260C).
See this Xilinx app note:
http://direct.xilinx.com/bvdocs/appnotes/xapp427.pdf

Changing the materials to make a device compatible with those reflow
characteristics is bound to have an effect somewhere, although I don't
know the specifics for Xilinx.

In addition to that, the solder joint of a tiny part (such as a
coupling cap) has parasitics that are (somewhat) material dependent.
Change the materials, change the parasitics. This too is an issue for
high speed designs.

Note - when I mention extremely high frequencies, I am referring to bit
times (on the wire pair) of 1nSec or less (PCI express, InfiniBand and
Fibre channel come to mind).

So will it affect us in high speed designs? Undoubtedly.

The issue is we probably won't know the effects until there are large
numbers of boards already made.

Cheers

PeteS


Article: 91857
Subject: Re: RoHS
From: allanherriman@hotmail.com
Date: 15 Nov 2005 05:01:47 -0800
Links: << >>  << T >>  << A >>
PeteS wrote:
[snippage]
> In addition to that, the solder joint of a tiny part (such as a
> coupling cap) has parasitics that are (somewhat) material dependent.
> Change the materials, change the parasitics. This too is an issue for
> high speed designs.

The thermal resistance will also be different.  (I don't know whether
it will be better or worse, but Murphy says it will be worse.)  A
significant amount of heat leaves the package through the balls, and
this may matter for high speed designs.

Regards,
Allan


Article: 91858
Subject: Re: Can't pack into OLOGIC
From: "Brian Davis" <brimdavis@aol.com>
Date: 15 Nov 2005 05:09:30 -0800
Links: << >>  << T >>  << A >>
john wrote:
>
> with my version of ISE, I can not put the IOB attribute on a signal
>
 I  rebuilt that example 6.3 project I'd posted a link to, using 7.1SP4
The IOB attribute worked just fine  (note 1); the tristate controls are
properly replicated and all registers show up in the IOBs.

>
> I get the error
> ERROR:HDLParsers:1202 - "/home/XXX/XXX/XXX.vhd" Line 210. Redeclaration of symbol tristate_enable_reg. -->
>
That message sounds like the synthesizer is choking on a coding
problem. Do you have duplicate (identical) names for both a process
and a signal, or something similar ?

Brian

Note 1:
  There is a 7.1iSP4 bug with assigning IOSTANDARDs and LOCS
using HDL attributes. Unused LOC'd inputs drop their IOSTANDARD
definitions and default back to LVCMOS25, causing banking errors.
To make that example project compile, make the following change to
<ram_test.vhd> to avoid any unused inputs:

--           seg_dp <= '1';
           seg_dp <= sw(5) OR sw(4) OR sw(3) OR sw(2) OR sw(1) OR sw(0)
OR pb(1) OR pb(0);


Article: 91859
Subject: Rise time/fall time for Spartan3 clock inputs
From: "abeaujean@gillam-fei.be" <abeaujean@gillam-fei.be>
Date: 15 Nov 2005 05:14:48 -0800
Links: << >>  << T >>  << A >>
Hi there,

I am encountering a strange problem in a state machine using a 33M3333
clock in a Spartan3 FPGA.

>From time to time, the state machine misbehaves. The problem has at
first been attributed to a relatively poor waveshape of the clock line.
A load of 100ohms/10pF in series to ground has been put at the end of
the line, improving a bit the problem.

However, the problem is still there. I am now suspecting a too slow
rise time or fall time of the clock input to the FPGA, that could let a
noise go through around the threshold point. This idea is backed up by
the fact that extra edges seem to be added. By the way, I am unable to
find in the Xilinx data sheet any value for the RT and FT of the
clocks.

I would have liked to be able to force input hysteresis on the clock
signals, but I think it is not possible nor maybe desirable.


Any idea ?


Article: 91860
Subject: Re: RoHS
From: "PeteS" <ps@fleetwoodmobile.com>
Date: 15 Nov 2005 05:38:00 -0800
Links: << >>  << T >>  << A >>
..A
significant amount of heat leaves the package through the balls, and
this may matter for high speed designs.
...

Very true (not so much if it's a flipchip ;)

It will most definitely change the thermal characteristics. That being
the case, we'll either get poorer guaranteed performance, or poorer
temperature ranges. I'd take the termperature range and cool it (of
course, that adds a whole new dimension).

Cheers

PeteS


Article: 91861
Subject: Re: Rise time/fall time for Spartan3 clock inputs
From: "Gabor" <gabor@alacron.com>
Date: 15 Nov 2005 05:38:58 -0800
Links: << >>  << T >>  << A >>

abeaujean@gillam-fei.be wrote:
> Hi there,
>
> I am encountering a strange problem in a state machine using a 33M3333
> clock in a Spartan3 FPGA.
>
> >From time to time, the state machine misbehaves. The problem has at
> first been attributed to a relatively poor waveshape of the clock line.
> A load of 100ohms/10pF in series to ground has been put at the end of
> the line, improving a bit the problem.
>
> However, the problem is still there. I am now suspecting a too slow
> rise time or fall time of the clock input to the FPGA, that could let a
> noise go through around the threshold point. This idea is backed up by
> the fact that extra edges seem to be added. By the way, I am unable to
> find in the Xilinx data sheet any value for the RT and FT of the
> clocks.
>
> I would have liked to be able to force input hysteresis on the clock
> signals, but I think it is not possible nor maybe desirable.
>
>
> Any idea ?

When you say you put a load at the end of the line, are you saying the
end
of the line is not at the Spartan?  Were you able to put a scope at the
pin
of the FPGA?  If the clock driver doesn't have a low enough output
impedance
and the Spartan is not at the end of the line, you could be seeing a
stepped
transition where the clock actually sits in the threshold region for a
while until
the reflected wave brings the voltage up.

Since your clock seems to be slow, I don't see why hysteresis would be
a bad
idea, unless the data you capture externally has a small setup/hold
window.
In the case of the stepped transition, hysteresis would delay the clock
edges
until the signal reflection.  The extra delay from this depends on the
length of
trace between the Spartan and the end of the line.

The best fix of course would be to route the clock only point to point,
using
zero delay buffers if necessary to fan out.  Then a proper clock signal
would
be achievable using only series termination at the source (or buffer).


Article: 91862
Subject: Re: ISE, JTAG and ChipScopePro.
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 15 Nov 2005 14:02:15 +0000
Links: << >>  << T >>  << A >>
"fad" <fahad.arif@gmail.com> writes:

> I dont think you require anything else. For in circuit debugging.. all
> you need is..
> 1) JTAG cable 2)ChipScope Pro 3)Impact for programming (which comes
> with ISE only)

Chipscope will program as well, no need for Impact.

Cheers,
Martin

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

Article: 91863
Subject: Re: Rise time/fall time for Spartan3 clock inputs
From: "abeaujean@gillam-fei.be" <abeaujean@gillam-fei.be>
Date: 15 Nov 2005 06:22:13 -0800
Links: << >>  << T >>  << A >>
Thanks for the prompt answer.

The input pin of the FPGA is actually very near to the end of the line,
where the R/C load sits.

No, I have not been able yet to look at the waveform "near to the pin"
(the configuration is not easily accessible).

OUPS. Glad you talk about the "driver" chip anyway. Reviewing my parts
list (and not only the schematics that do not clearly show that) makes
me realize that it is a 74LVC2244 (with 30 ohms series termination in
it). That should not look too good with the RC termination.

SO. I shall first try a 74LVC244A instead and see what happens.

By the way, I see no way to force an input hysteresis in a Spartan3
FPGA.


Article: 91864
Subject: Re: Rise time/fall time for Spartan3 clock inputs
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Tue, 15 Nov 2005 14:40:39 -0000
Links: << >>  << T >>  << A >>
Key to a clean clock either (1) Using termination either series at source, 
or parallel at endpoint (2) Limiting clock edge rate to reduce reflections.

To think sideways you problem sounds very like the classic asyncronous 
input, or not meeting setup/hold, problem. Are any of you inputs to your 
state machine asynchronous(or different clock) to the clock used for the 
state machine?

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


<abeaujean@gillam-fei.be> wrote in message 
news:1132060488.081334.147800@f14g2000cwb.googlegroups.com...
> Hi there,
>
> I am encountering a strange problem in a state machine using a 33M3333
> clock in a Spartan3 FPGA.
>
>>From time to time, the state machine misbehaves. The problem has at
> first been attributed to a relatively poor waveshape of the clock line.
> A load of 100ohms/10pF in series to ground has been put at the end of
> the line, improving a bit the problem.
>
> However, the problem is still there. I am now suspecting a too slow
> rise time or fall time of the clock input to the FPGA, that could let a
> noise go through around the threshold point. This idea is backed up by
> the fact that extra edges seem to be added. By the way, I am unable to
> find in the Xilinx data sheet any value for the RT and FT of the
> clocks.
>
> I would have liked to be able to force input hysteresis on the clock
> signals, but I think it is not possible nor maybe desirable.
>
>
> Any idea ?
> 



Article: 91865
Subject: Re: Research Position
From: "Stephen Craven" <scraven@vt.edu>
Date: 15 Nov 2005 06:41:31 -0800
Links: << >>  << T >>  << A >>
Is the ability to speak German a requirement, or is there an english
version of this website available?

Stephen


Article: 91866
Subject: Re: Coolrunner output pins stuck at 0V
From: "jvdh" <johannes.vanderhorst@gmail.com>
Date: 15 Nov 2005 07:17:57 -0800
Links: << >>  << T >>  << A >>
Downloading and installing SP4 from the Xilinx site eventually solved
my problems...

johannes


Article: 91867
Subject: Re: Rise time/fall time for Spartan3 clock inputs
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 15 Nov 2005 07:33:19 -0800
Links: << >>  << T >>  << A >>
100 Ohm + 10 pF in series is not a meaningful termination.
R should = the char. impedance, probably 50 Ohm. C should give it a
time constant that is longer than a transition time, but shorter than a
clock half-period. Make that 10 ns in your case. That means 50 Ohm +
200 pF.

But this assumes that you want to do a parallel termination at the far
end.
If your driver has a series termination, then you want to keep the far
end unterminated, but you then also accept a step function everywhere
along the line, except at the far end.
If you suspect double-triggering, then just implement a free-running
2-bit counter in the FPGA and look at its outputs. That will indicate
double-triggering very clearly.

Peter Alfke, Xilinx Applications.


Article: 91868
Subject: Re: Having trouble Detecting ethernet packets using ethereal
From: "ashwin" <achiluka@gmail.com>
Date: 15 Nov 2005 07:57:32 -0800
Links: << >>  << T >>  << A >>
Hi Arlet
  The format i used for the ethernet frame is this: WIth the least
significand bit transferred first. I have a 4 bit interface from fpga
to PHY so i will transfer least significand nibble of each byte every
clock cycle.

7 bytes of x"55";
1 byte of x"d5";
6 bytes of dest MAC address
6 bytes of source MAC address
DATA -- 40 bytes
4 bytes of FCS

What do you mean by static IP packet. Does it include preamble and CRC
too?
The PHY converts the data into MLT-3 signal which is like a sinusoid.
Its hard to decode manually what data is being sent out.

Ashwin



Arlet wrote:
> Ethereal has no problems showing non-IP packets when it catches them.
>
> Are you sending the correct preamble and SFD ? Do you see the link
> blink on the PC whenever you send something ? Manually copy a static IP
> packet bit by bit in your VHDL code, and send that as a test packet.
> Compare your version with the sample bit file by looking at PHY signals
> with a scope.


Article: 91869
Subject: Re: Research Position
From: "Gunter Knittel" <knittel@gris.uni-tuebingen.de>
Date: Tue, 15 Nov 2005 17:07:45 +0100
Links: << >>  << T >>  << A >>

Sorry for not mentioning this.
On the far right on our web page, you find three little
flags, one of them is for English.
Speaking German is not a requirement as long as we can
communicate sufficiently well in English.

Cheers
Guenter


"Stephen Craven" <scraven@vt.edu> wrote in message 
news:1132065691.562056.193150@z14g2000cwz.googlegroups.com...
> Is the ability to speak German a requirement, or is there an english
> version of this website available?
>
> Stephen
> 



Article: 91870
Subject: Re: Best Case Timing Parameters
From: "Avrum" <noasvpraumm@nospamsympatico.ca>
Date: Tue, 15 Nov 2005 11:31:15 -0500
Links: << >>  << T >>  << A >>
The 4:1 rule is a very good starting point since it covers the range of
variability in the most important delay mechanisms within a CMOS process.
However, it is important to remember that it is just that, a scaling of the
delays related to channel conductance, capacitances, and internal wire
propagation. When the delays you are considering consist of these factors,
then the 4:1 rule is good.

However, to be REALLY REALLY picky, there are some cases where you have to
be careful with the 4:1 rule for I/O timing. Specifically, it is
questionable to apply this rule to one of the main delay parameters in the
the FPGA datasheet, Tickofdcm.

Tickofdcm (or Tickofdll) is a composite parameter that relates the timing of
an output to the arrival of the clock at the FPGA clock input. This path
goes through a lot of things (the IBUFG, a DCM/DLL with internal feedback,
the GCLK buffer and global clock net, the output flip-flop in the IOB and
then the final output driver in the IOB). Many of these are appropriately
scaled using the 4:1 rule, but the some aspects of the clock and DLL are
not...

The DLL/DCM with internal feedback is, in fact, designed specifically NOT to
scale with the 4:1 rule; that is the whole reason that we use one; to cancel
out the delay of the clock distribution net (and associated other
circuitry), even though that circuitry does scale with process temperature
and voltage. If the cancellation of the clock net by the DLL were perfect,
then this portion of the path would contribute no delay to Tickofdcm, and
hence the 4:1 rule would apply to the whole path. However, this is not the
case. The DCM is not perfect, and, in some systems, is intentionally
designed to result in a slightly negative total delay. By doing this, Xilinx
reduces the required hold time at input FF's in the IOBs, resulting in a
negative (or at least very small) required hold time (Tphdcm). However,
applying the 4:1 scaling factor to this portion of the delay results in a
slightly OPTIMISTIC value.

To be quite paranoid (and I admit, that for most designs this is excessive,
since the 4:1 rule is pretty generous, and will cover a little "slop" in the
path), you should scale Tickofdcm differently. For the min of this
parameter, I would use

Tickofdcm(min) = Tickofdcm(max) - 3/4Tiockp(max)

as a starting point. The values for both of these parameters should already
be derated for the appropriate I/O standard being used. Note: this can
acutally result in a negative number for certain I/O standards, and is
technically correct, due to the negative delay of the DLL/clock tree
combination.

Also, Tickofdcm contains some allowance for the phase error and jitter of
the DCM. For Tickofdcm(max), these are assumed to be their worst case in the
positive direction, for Tickofdcm(min), they need to be accounted for in the
negative direction, so for a TOTALLY paranoid application

Tickofdcm(min) = Tickofdcm(max) - 3/4Tiockp(max) - 2xCLKOUT_PER_JITT0 -
2xCLKIN_CLKFB_PHASE

And finally, the system designer must not forget to factor in the clock
jitter on the input clock, which adds to Tickofdcm(max), and subtracts from
Tickofdcm(min). This can get somewhat tricky, since it is a bit pessimistic
to add the external clock jitter directly to the jitter added by the
DLL/DCM; these jitters are probabilistic, and hence add probabilistically;
truly random jitters add using a root-sum-of-squares calculation.

Avrum

"Ajay" <ajay@cg-coreel.com> wrote in message
news:1131886868.567328.63420@g44g2000cwa.googlegroups.com...
> Thank you so much Peter. We are using the 4:1 rule.
>
> Regards,
> Ajay
>
> Peter Alfke wrote:
> > Yes, I agree.
> > Inside the chip, we make sure that the delay tolerances on a global
> > clock are less than the min delay clock-to-Q, and we can guarantee
> > that, since delays track inside the chip.
> > Between chips, the min delay is important since the clock delay
> > differences are determined by the pc-board, and the transmitting device
> > may also have nothing in common with the receiving device (neither
> > temperature nor processing, although probably voltage).
> >
> > That's why source-synchronous design is now popular (sending the clock
> > together with the data) and IDELAY in Virtex-4 gives you the ability to
> > delay clock or data by a precise amount, so that you can achieve
> > near-optimal relative timing.
> > Peter Alfke
>



Article: 91871
Subject: Re: Having trouble Detecting ethernet packets using ethereal
From: "I. Ulises Hernandez" <delete@e-vhdl.com>
Date: Tue, 15 Nov 2005 16:51:33 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi Ashwin,

What about the 8b/10b encoding, are you encapsulating your ethernet packets 
with the SOP, EOP and Carrier Extend as specified in the ieee 802.3 spec...

It's been a while but I seem to remember that in my case (my own tri-rate 
mac+2vp rocketIO+external sgmii SFP) I had to encapsulate the data you 
decribed as:

SOP

>>7 bytes of x"55";
>>1 byte of x"d5";
>>6 bytes of dest MAC address
>>6 bytes of source MAC address
>>DATA -- 40 bytes
>>4 bytes of FCS

EOP + CS

Also make sure you send IDLEs when you don't transmit your packet...

Regards,

-- 
Ignacio U. Hernandez
" I'm not normally a praying man, but if you're up there, please save me, 
Superman!" - Homer Simpson ;O)


"ashwin" <achiluka@gmail.com> wrote in message 
news:1132010843.945625.155910@o13g2000cwo.googlegroups.com...
> Hello Everyone again,
>
>       This topic is troubling me for couple of weeks now. I want to
> get over this as quickly as possible. I am trying to transmit data from
> the virtex 4 LX fpga board to the PC using ethernet PHY  and i am
> unable to detect any data on the PC.
>       I have written a small state machine  using vhdl which actually
> transmits the ethernet packet( dest MAC, Source MAC, length/type, data,
> fcs(Crc)] . I am sure that FCS is correct as i tested my code for
> sample ethernet packets and i got it right.
>
>       There is a sample bit file given with the evaluation board to me
> for testing the ethernet PHY.So when i download this bit file and in
> the cmd , when i say ping fpga(mac address) and i start the ethereal
> capture. I am able to see the data transfer to and from between fpga
> and mac.
> But if i dont ping it and just start capturing by clicking the capture,
> i am not able to detect anything except the ARP which is data
> transferred from PCs ip address to broadcast.
>
> In my project i dont ping in the cmd because i didnt include any ip
> address in my  vhdl code. So basically i am not able to detect anything
> in the ethereal except the ARP which is being transferred from PC to
> broadcast. The format of the ethernet frame i am using is
> Destination MAC ad, Source MAC, length/type, data, FCS(CRC) and i am
> not using any ip address or udp header in my ethernet frame in the vhdl
> code.
>
> Probably the data is getting transferred on to the PC, but not able to
> capture it since, i am not  pinging it.  So how do we see what data is
> coming out from the PHY.
>
> Please advice ?
>
> Thanks
> Ashwin
> 



Article: 91872
Subject: Celoxica RC1000 Linux driver
From: Andrew Greensted <ajg112@ohm.york.ac.uk>
Date: Tue, 15 Nov 2005 17:08:52 +0000
Links: << >>  << T >>  << A >>
Hi All,

We've got a few Celoxica RC1000 FPGA boards that we'd like to use within 
a Linux environment.

Has anyone had any luck compiling the drivers for a 2.6 kernel. The 
latest drivers I've been able to find (0.9.25) were written in 1998 and 
make use of a lot of deprecated header files.

I'd love to hear if anyone has one working within an up-to-date linux 
environment.

Many Thanks
Andy

-- 
Dr. Andrew Greensted      Department of Electronics
Bio-Inspired Engineering  University of York, YO10 5DD, UK

Tel: +44(0)1904 432379    Mailto: ajg112@ohm.york.ac.uk
Fax: +44(0)1904 433224    Web: www.bioinspired.com/users/ajg112

Article: 91873
Subject: Re: ISE, JTAG and ChipScopePro.
From: Massimo Gaggero <max@crs4.it>
Date: Tue, 15 Nov 2005 18:09:38 +0100
Links: << >>  << T >>  << A >>
Thus, if I want to inspect the internal of the FPGA I must use 
ChipScopePro with its load? Is there any other way to get informations 
about the flip-flops's status and other JTAG-ed components of the FPGA 
by the JTAG?

Bye,
	Massimo.

fad ha scritto:
> I dont think you require anything else. For in circuit debugging.. all
> you need is..
> 1) JTAG cable 2)ChipScope Pro 3)Impact for programming (which comes
> with ISE only)
> YOu need to have debuger like 'paradigm' through which you can do the
> software verification of your IP. ChipScope is good enough to monitor
> In-FPGA signals but puts a limitation on memory requirement.
> 

Article: 91874
Subject: Re: AVNET's Spartan3 400 dev board & PCI
From: Krzysztof Przednowek <nospam@gazeta.pl>
Date: Tue, 15 Nov 2005 18:11:39 +0100
Links: << >>  << T >>  << A >>
Hi,
	Thanks for answers.
> 1) does the board worj when you use Avnet ref design image ?
> 
	There was no reference design for PCI included. But I believe board 
works. Everything else works fine. Currently I'm workin on some kind of 
PCI monitor, to see what is going on.

> 2) the 24ma would not help, you have some problem with your core that
> is the reason for the freeze
>
	I think that is something with my core, too. I was asking about 
current, to be sure that electrical part of design is good.

> and I suggest you start testing and analyzing some existing and
> working PCI design before trying your own, and for your
> own core make sure it works in testbench

	I've try to test my core with Altera'a testbench from their
evaluation version of PCI compiler... But they set clk and data and 
everything
else in the same time. How it could posible to sample data on rising 
clk, when data are set up in the same time? And they use adresses (in 
config read/write) with oldest bit set, why?

Best regards
Krzysztof Przednowek



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