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 123875

Article: 123875
Subject: Re: high bandwitch ethernet communication
From: Grant Edwards <grante@visi.com>
Date: Thu, 06 Sep 2007 14:10:36 -0000
Links: << >>  << T >>  << A >>
On 2007-09-06, eliben <eliben@gmail.com> wrote:

> 2) If the client is a PC of some sort, working on the MAC packet level
>    isn't too simple,

It's easy:

 $ man packet

> as the networking APIs don't provide that level.

Sure they do.  See above.

Of course it sucks trying to do it under Windows, but it sucks
trying to do _anything_ under Windows. ;)

> A separate driver to the NIC should be used, or whatever.
>
> 3) If I want to advance to a more complicated network, such as one
> with a few clients, working on the IP level is much more convenient as
> I can set up a router with all the niceties it brings - multicasts,
> groups, etc.

Yup.  One of the products I work on started out with MAC level
networking.  It's fast and has very low overhead, but there are
always going to be customers who want IP networking.  So now
the product will do either MAC networking or TCP networking (or
both, actually).

Beware of relying on the Ethernet CRC.  I've run across two
different uController/MAC combinations where it wasn't
reliable.

-- 
Grant Edwards                   grante             Yow! Wait ... is this a FUN
                                  at               THING or the END of LIFE in
                               visi.com            Petticoat Junction??

Article: 123876
Subject: Re: high bandwitch ethernet communication
From: Grant Edwards <grante@visi.com>
Date: Thu, 06 Sep 2007 14:12:34 -0000
Links: << >>  << T >>  << A >>
On 2007-09-06, Paul Keinanen <keinanen@sci.fi> wrote:

>>2) If the client is a PC of some sort, working on the MAC packet level
>>isn't too simple, as the networking APIs don't provide that level. A
>>separate driver to the NIC should be used, or whatever.
>
> I haven't written any raw Ethernet protocols in two decades, but in
> those days setting the receiver into Promiscuous mode was all that was
> needed. 

There's no need for promiscuous mode.  None of the MAC packet
level products I've worked on used promiscuous mode at all.

> With the cost of the system that the OP asked, there would not be a
> cost issue of installing an extra network cards on the receiving PC.
> Thus, one NIC could handle the fast traffic in Promiscuous mode, while
> the other NIC(s) could handle ordinary network traffic.

I don't see what promiscuous mode has to do with it.  The MAC
level protocols I worked with were all still unicast.

-- 
Grant Edwards                   grante             Yow! FOOLED you!  Absorb
                                  at               EGO SHATTERING impulse
                               visi.com            rays, polyester poltroon!!

Article: 123877
Subject: Re: PCB Impedance Control
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 6 Sep 2007 15:17:29 +0100
Links: << >>  << T >>  << A >>

"John_H" <newsgroup@johnhandwork.com> wrote in message 
news:j0TDi.4846$J96.4401@trnddc02...
> Symon wrote:
>> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
>> news:lZqdnS0_y5YKvULbnZ2dnUVZ_s7inZ2d@comcast.com...
>>> vasile wrote:
>>>
>>> (snip)
>>>
>>>> If you're routing a long 3Gbps differential signal, then definitely
>>>> you must have ground vias near every signal pair vias. Bypassing with
>>>> a capacitor near an inductive vias has no effect. But using at least
>>>> one ZBC plane in the stack it helps.
>>> If it is a differential signal, then you should not need to
>>> worry about ground bypassing.  There should be no net
>>> ground current, that is the whole point of differential
>>> signaling.
>>>
>>> -- glen
>>>
>> Hi Glen,
>> I think it does matter in this case. I think we're agreed that the two 
>> signals that make up the pair are mainly coupled to the plane, not to 
>> each other. This means that current is flowing in the ground. As you say 
>> in another reply in this thread to me, that doesn't matter, UNTIL the 
>> signals come to a discontinuity in the 'signal to ground' coupling. Such 
>> a situation arises at the transition between layers, which is why the use 
>> of adjacent ground vias can mitigate the situation.
>> HTH, Symon.
>
> But Symon...
>
> The signal is differential so when the return currents hit the wall, they 
> cancel each other out at that border.  There's no reflection because the 
> common mode voltage isn't changing.  If the differential signal wasn't 
> routed differentially, then the reference currents would disperse when 
> they hit the discontinuity and then eventually find each other or other 
> ways to balance the current.  Even though a large portion of the reference 
> current is in the plane, the discontinuity results in almost no distance 
> to travel for the differential reference currents to find peace.
>
> - John_H

Hi John,

A good point, I agree, that's true. As you say, there will be a 
discontinuity nevertheless, as the currents need to cancel out across the 
plane, but I would think this is a small effect. Furthermore, in that case, 
I think it means it is important to match the lengths of the traces from 
each termination to the vias as well as the total length of the individual 
traces. In the case where the extra ground vias are in place, that isn't so 
important.

Of course, the differential signal continues on its merry way through the 
vias. Without the ground vias, the transmission line impedance will have a 
significant discontinuity.

Anyway, thanks for pointing that out!

Cheers, Syms. 



Article: 123878
Subject: Re: New keyword 'orif' and its implications
From: Andy <jonesandy@comcast.net>
Date: Thu, 06 Sep 2007 07:24:19 -0700
Links: << >>  << T >>  << A >>
Weng,

To elaborate on what Jim and Brian have stated, In the loop, in order
for enable(n) to be considered, enable(n-1) must have been false. This
evaluation of enable(n-1) requires additional gates UNLESS there is
something else that tells the compiler (synthesis or simulation) that
the enable bits are mutually exclusive, and therefore that if
enable(n) is set, by definition enable(n-1) is not set.

It is interesting to note that the presence of the exit statement has
no effect on the synthesized gates IF enable is mutually exclusive.
However in the absence of both the exit statement and mutual
exclusivity, the last executed assignment to output wins, so enable(n)
is only used if enable(n+1) is not set, thus also requiring additional
gates.

Both of these explanations assume an index ordering of "to", not
"downto"; however, the behavior is  similar (and the effect on
hardware the same) with "downto".

So, in fact your code DOES NOT demonstrate, nor optimize for, the
mutual exclusivity of the bits in enable. Contrary to your erroneous
statement, your code merely demonstrates your lack of understanding of
the significance of order of execution among sequential statements, a
fundamental concept in simulation and logic synthesis.

Jim's (and others') implementation using OR works well for data types
that support the OR operator: booleans, bits and vectors, but neither
integers, enumerated types nor other aggregate types, without a
conversion to/from an ORable data type, can use this method.

In addition, without the assertion, the (erroneous) lack of mutual
exclusivity upon which the solution depends would likely go unnoticed
in simulation. And while the ability of the simulator to use the
assertion has existed since the beginning, the ability of synthesis
tools to use the assertion (not to verify it, but to optimize
circuitry because of it) does not, to this day, exist.

Oh, and by the way, I AM THE WINNER! ;^)

Andy


Article: 123879
Subject: Re: high bandwitch ethernet communication
From: John McCaskill <jhmccaskill@gmail.com>
Date: Thu, 06 Sep 2007 14:45:31 -0000
Links: << >>  << T >>  << A >>
On Sep 6, 12:22 am, eliben <eli...@gmail.com> wrote:
> > If you have the choice between UDP and TCP, UDP is much simpler and
> > fits an FPGA well. The big issue in choosing between the two is if you
> > require the guaranteed delivery of TCP, or can tollerate the potential
> > packet loss of UDP.
>
> > As an example, we make a card that acquires real time data in a custom
> > protocol that is wrapped in UDP. We use a Xilinx Virtex-4 FX60, and a
> > protocol offload engine that uses the Xilinx PicoBlaze soft processor
> > to deal with the protocol stack.  The PicoBlaze is an 8-bit soft
> > processor.  It looks at each incomming packet and reads the header to
> > see if it is one of the real time streams we are trying to offload.
> > If it is, it sends the header to one circular buffer in memory and the
> > data to another circular buffer.  If it is not, it sends it to a
> > kernel buffer and we let the Linux network stack deal with it.
>
> > With this setup, we can consume data at over 90 MB/sec per Gigabit
> > Ethernet port.  The data part of the packet is 1024 bytes, and each
> > GigE port has its own PicoBlaze dedicated to it.
>
> So where is the actual UDP communication implemented ? In Linux ? What
> processor is it running on ? Is it an external CPU or the built-in PPC
> of Virtex 4 ?
>
>

We are using one of the embedded PowerPCs to run Linux, and one
PicoBlaze soft processor per EMAC in the design.

As each packet exits the EMAC, its header is examined by software that
is running on the PicoBlaze.  The PicoBlaze is running a very simple
stack written in assembly language.  As it looks at each layer of the
header, it makes a decision to do one of several things. At the
Ethernet level, it is deciding if it should just throw the packet
away, or pass it on to the next layer. At the IP and UDP layers, it is
deciding if the packet belongs to the protocol that we are offloading,
and is a stream that we have requested.  If the packet does belong to
the protocol that we are offloading, the PicoBlaze sets up a PLB DMA
engine to send it down one data path. If the packet does not belong to
the protocol we are offloading, then the PicoBlaze sends it down
another data path and it is given to the Linux kernel to deal with.

So for the protocol that we are offloading, the entire Ethernet, IP,
UDP, and custom protocol stack are implemented in PicoBlaze assembly
code.  For everything else, the stack is in Linux.  Since the data we
are offloading is multicast data, this lets us have the PicoBlaze deal
with the simple but high speed UDP packets, and the PowerPC running
Linux deal with the IGMP messaging required to join, leave and
maintain membership in a multicast group.

The PicoBlaze is just running a single threaded loop of code that
polls for input or output data, and then deals with it.  Its program
is loaded from the PowerPC taking advantage of the fact that the BRAM
holding its program is dual ported.  The PowerPC also tells the
PicoBlaze what streams of data it is supposed to be acquiring, and
what buffers in DDR2 memory to write the data to.  The PicoBlaze will
generate an interrupt once it has written a certain number of packets
to the buffer, so the PowerPC just sees big chunks of data showing up
in the buffers and does not have to deal with each packet.  The
PowerPC only needs to spend 1 or 2 percent of its compute to deal with
acquiring each stream of data.



>
> > I did notice that you want to send GigE instead of receive it like we
> > are doing, but this method should work for sending a custom protocol
> > wrapped in UDP with some minor changes.
>
> > How is the GigE that you are sending the data over connected? Is it
> > point to point, a dedicated network, or something else?
>
> We can assume for the sake of discussion that it is point to point,
> since the network is small and we're likely to use a fast switch to
> ensure exclusive links between systems.
>
> Eli


With this setup, you should be able to have an error rate that is
incredibly low.  As long as the possibility of a lost packet is not
catastrophic, UDP would be a very good match.  The protocol we offload
has sequence numbers in it, so we know if we have lost a packet.  The
data is being used for realtime signal processing, so losing a packet
just looks like a burst of noise.

Regards,

John McCaskill
www.fastertechnology.com


Article: 123880
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Thu, 06 Sep 2007 07:53:25 -0700
Links: << >>  << T >>  << A >>
Hi Brian,
1. Please write target answer's name, otherwise I may miss your
comments.

2. Before 2006, we didn't have 2006/2008 VHDL compilers available, did
you see any burning?

3. The following claim is irrelative to Andy's requirement:
"Andy's code caught the problem before synthesis, so he fixed it.
Because his synthesis tool (the 2008 version) understood the
assertion"

Andy wants me to use orif to transfer mutually exclusive information
to within loop, in this respect, no orif is needed and things are done
perfectly, because mutually exclusive Information has been clearly
transfered to within the loop by coding style.

I think it is the best explanation to your question:

Nothing is better than extra.

Whatever assertion onehot0() can do in terms of mutually exclusive
information tranfer mechanism, orif can do better, faster, safer and
more reliable !

The above sentence is too long to remember, the following sentence was
used and everyone involved knows its full meaning:
What assertion onehot0() can do, orif can do better.

I have to emphasize that onehot0() function is useful in general, but
useless in terms of its introduction purpose.

Weng



Article: 123881
Subject: Is it possible to perform gate level simulation on a design without a reset?
From: aclegg1986@googlemail.com
Date: Thu, 06 Sep 2007 14:55:43 -0000
Links: << >>  << T >>  << A >>
Hi,

           If an Altera design does not have a reset, then what
happens to the registers during gate level simulation? I assume that
the Q outputs are initilaised to 0, but what happens with the D
inputs, I guess they would be assigned U at time 0 , so when the
registers clock changes the U will appear on Q, which would then
propagate throught the fpga? How are designs tested without resets?


Thanks Andy


Article: 123882
Subject: Re: Is it possible to perform gate level simulation on a design without a reset?
From: Peter Alfke <alfke@sbcglobal.net>
Date: Thu, 06 Sep 2007 08:06:34 -0700
Links: << >>  << T >>  << A >>
If all Q outputs are 0, then the whole design is defined, and each D
input is what the combinatorial logic determines it to be.. Where do
you see the problem?
Peter Alfke

On Sep 6, 7:55 am, aclegg1...@googlemail.com wrote:
> Hi,
>
>            If an Altera design does not have a reset, then what
> happens to the registers during gate level simulation? I assume that
> the Q outputs are initilaised to 0, but what happens with the D
> inputs, I guess they would be assigned U at time 0 , so when the
> registers clock changes the U will appear on Q, which would then
> propagate throught the fpga? How are designs tested without resets?
>
> Thanks Andy



Article: 123883
Subject: Re: PCB Impedance Control
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 06 Sep 2007 08:13:08 -0700
Links: << >>  << T >>  << A >>
On Thu, 6 Sep 2007 10:14:40 +0100, "Symon" <symon_brewer@hotmail.com>
wrote:

>"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message 
>news:7gdtd3lnoebp1hualfofq6444ukph0jrt5@4ax.com...
>>
>>
>> The GSSG structure makes sense in both those papers, not because it
>> provides a "return current path" (which the papers, thankfully, don't
>> say) but because it keeps the impedances of the traces constant as
>> they burrow through the epoxy-glass, by providing uniform grounded
>> capacitive loading. There is a difference.
>>
>Hi John,
>So, if there's no return current, no current flows in the via right? **So 
>you could disconnect one end of the via and it would not affect the 
>operation of the curcuit?

A transmission line is equivalent to a string of series Ls and shunt
Cs. The Cs all end at "ground" for a single line, and there are
additional Cs between lines for diff pairs. Of course all the Cs must
be charged as a wavefront moves along the line. If that's what you
want to call "return current" then do so. I call it the charging
current of the capacitive component of the transmission line. The
words aren't important. What's in question is whether a signal can
dump its current into, say, a ground plane, hit a via, and then dump
its charging current blips onto the other side of that plane, or into
a sandwiched power plane, without bad things happening. My position is
that planes, in real life, so close to equipotential, so firmly glued
together by plane-plane capacitance and (at low frequencies) by bypass
caps, that they all look like ground to the transmission line, so all
the articles and "consultants" claims about managing "return current"
are mostly a waste of words.

>
>It's important to realise that transmission lines are not just defined by 
>capacitance. The structures have inductance also.

Gosh.

> It is an excess of this 
>inductance that will slow down your signal. It is this inductance that is 
>adjusted by the cunning placement of vias.

The GSSG ground vias do indeed moderate the inductance and capacitance
of the signals as they scoot through the vias. Simulate and optimize
for that. But they don't really serve to connect the planes so that
the "return current" can find its way home.

>
>It is true that this sort of stuff only really matters at high speeds. 
>However, modern FPGAs have sub ns rise time outputs whether you need that 
>speed or not. This is why readers of this group should be interested.

No argument there. Some of the OnSemi ecl chips, and a couple of
Analog Devices comparators, are also running around 35 ps edge rates,
where things atart to get interesting.


>
>HTH, Syms.
>
>** My thanks to a friend for pointing this out to me!
>
>p.s. Here's a nice article about plane inductance.
>http://www.ansoft.com/news/articles/02.02_PCDmag.pdf 
>

His decoupling cap calculation in page 2, where he comes up with 20
uF, is typical of plugging numbers mindlessly into equations just
because the dimensions seem to fit. The rest is similarly silly.

John




Article: 123884
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Thu, 06 Sep 2007 08:30:04 -0700
Links: << >>  << T >>  << A >>
Andy,
Your following claim is false:
"...enable(n-1) must have been false.."

Only enable() is a static, a foolish case, the above situation would
happen and your assertion part plays a role for a VHDL compiler.

The static values may be all 0. So that no code would be generated for
the code segment. Are you serious enough to design a mechanims to deal
with the stupid case only?

It has nothing to do with mutually exclusive information.

Nothing is better than extra gabage.

Weng


Article: 123885
Subject: Re: Is it possible to perform gate level simulation on a design without a reset?
From: "John_H" <newsgroup@johnhandwork.com>
Date: Thu, 6 Sep 2007 08:37:01 -0700
Links: << >>  << T >>  << A >>
<aclegg1986@googlemail.com> wrote in message 
news:1189090543.879764.76630@r29g2000hsg.googlegroups.com...
> Hi,
>
>           If an Altera design does not have a reset, then what
> happens to the registers during gate level simulation? I assume that
> the Q outputs are initilaised to 0, but what happens with the D
> inputs, I guess they would be assigned U at time 0 , so when the
> registers clock changes the U will appear on Q, which would then
> propagate throught the fpga? How are designs tested without resets?
>
>
> Thanks Andy

Only if the clock was scheduled before any of the other logic at time zero 
would the assumption of undefined Ds with defined Qs be a problem.

The issue with most simulation is the assumption of undefined Qs independent 
of the fact that FPGAs configure to a very well defined state.  Depending on 
the manufacturer, device, or even development software revision, the 
assumption that all Qs start off 0 may or may not be valid.

Some FPGAs have global resets available that mimic the power-on reset, at 
least for registers.  Memory elements might not be affected by the GSR.

It's because of the simulation/synthesis mismatch that I've very dutifully 
added those pitifully unnecessary async resets throughout my recent designs 
except for the logic that I *know* will perform better (where performance is 
needed) without the constraints of an async reset.

I don't have enough recent experience with Altera devices to tell you what 
*will* take care of your simulation initialization problems.  Until I get my 
synthesizer to properly deal with initial states in my source code, I'll 
keep adding the insanely unneeded async resets.

- John_H 



Article: 123886
Subject: Re: New keyword 'orif' and its implications
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Thu, 06 Sep 2007 08:54:07 -0700
Links: << >>  << T >>  << A >>
Jim,
Sorry for any usage of inappropriate words.

Weng


Article: 123887
Subject: Re: load/read/ commands assembly PowerPC. Help Needed!
From: John McCaskill <jhmccaskill@gmail.com>
Date: Thu, 06 Sep 2007 17:12:06 -0000
Links: << >>  << T >>  << A >>
On Sep 6, 8:30 am, xenix <last...@gmail.com> wrote:
> Hello all,
>
> I am trying to load a 32bit data (word) from the PortB of a BRAM to a
> GPR (general purpose register) of the PowerPC.
>
> Address Map for Processor ppc405_0
> (0b0000010000-0b0000010011) ppc405_0
> (0b0000100000-0b0000100011) ppc405_0
> (0xa0008000-0xa000ffff) docm_cntlr docm
> (0xffff8000-0xffffffff) iocm_cntlr iocm
>
> i am using the LWZ command like LWZ r1, r1 (0xa0008001) but is not
> working. which is the right syntax for the specific adresses?
>
> regards



How is it not working? Not compiling, or not getting the data you
expect?  What are you compiling with, and do you have the MMU of the
PowerPC turned on?

Regards,

John McCaskill
www.fastertechnology.com


Article: 123888
Subject: Re: EDK9.1 linux registration fails (vista ok)
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 6 Sep 2007 13:27:12 -0400
Links: << >>  << T >>  << A >>
<rponsard@gmail.com> wrote in message 
news:1188988082.702740.278390@o80g2000hse.googlegroups.com...
>
> is there any reason for edk 9.1 registration failure with linux (I use
> the same id that successfully register edk on the same dual boot vista/
> ubuntu laptop ?)

I had a similar problem with my Kubuntu installation. I installed the 
original EDK9.1 OK, but when I tried to add SP2 it would refuse to take my 
ID no matter what I did... In the end I resolved the issue by running the 
Webupdate from inside of the EDK...


/Mikhail



Article: 123889
Subject: Free downloadable PDF graph paper.
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 6 Sep 2007 18:44:48 +0100
Links: << >>  << T >>  << A >>
Dear All,
I found this online and found it useful. Maybe you will too.
http://incompetech.com/graphpaper/
Cheers, Syms. 



Article: 123890
Subject: Re: PCB Impedance Control
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 06 Sep 2007 10:55:17 -0700
Links: << >>  << T >>  << A >>
On Thu, 06 Sep 2007 13:11:43 GMT, John_H <newsgroup@johnhandwork.com>
wrote:

>Symon wrote:
>> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
>> news:lZqdnS0_y5YKvULbnZ2dnUVZ_s7inZ2d@comcast.com...
>>> vasile wrote:
>>>
>>> (snip)
>>>
>>>> If you're routing a long 3Gbps differential signal, then definitely
>>>> you must have ground vias near every signal pair vias. Bypassing with
>>>> a capacitor near an inductive vias has no effect. But using at least
>>>> one ZBC plane in the stack it helps.
>>> If it is a differential signal, then you should not need to
>>> worry about ground bypassing.  There should be no net
>>> ground current, that is the whole point of differential
>>> signaling.
>>>
>>> -- glen
>>>
>> Hi Glen,
>> I think it does matter in this case. I think we're agreed that the two 
>> signals that make up the pair are mainly coupled to the plane, not to each 
>> other. This means that current is flowing in the ground. As you say in 
>> another reply in this thread to me, that doesn't matter, UNTIL the signals 
>> come to a discontinuity in the 'signal to ground' coupling. Such a situation 
>> arises at the transition between layers, which is why the use of adjacent 
>> ground vias can mitigate the situation.
>> HTH, Symon. 
>
>But Symon...
>
>The signal is differential so when the return currents hit the wall, 
>they cancel each other out at that border.  There's no reflection 
>because the  common mode voltage isn't changing.  If the differential 
>signal wasn't routed differentially, then the reference currents would 
>disperse when they hit the discontinuity and then eventually find each 
>other or other ways to balance the current.  Even though a large portion 
>of the reference current is in the plane, the discontinuity results in 
>almost no distance to travel for the differential reference currents to 
>find peace.
>
>- John_H

If a diff signal hits a region where the impedance changes, there will
be a partial differential reflection, kicked back to the driver.
Unless the driver is a matched impedance, which it generally ain't,
the reflection will bounce off the driver and get tangled with the
data stream, introducing jitter and closing up the data eye.

The differential impedance is determined by both signal-ground
capacitance and signal-signal capacitance (which gets double credit).
For a very fast edge, a diff signal that changes layers on vias can
encounter a different impedance region and do some bouncing. The fast
parts of the signal will tend to bounce back, and the slow parts will
tend to pass forward, not good. The via structure can certainly be
optimized for signal integrity. Above a few hundred ps risetime, it's
generally not a big deal.

John


Article: 123891
Subject: Re: New keyword 'orif' and its implications
From: Andy <jonesandy@comcast.net>
Date: Thu, 06 Sep 2007 11:22:46 -0700
Links: << >>  << T >>  << A >>
On Sep 6, 10:30 am, Weng Tianxiang <wtx...@gmail.com> wrote:
> Andy,
> Your following claim is false:
> "...enable(n-1) must have been false.."
>
> Only enable() is a static, a foolish case, the above situation would
> happen and your assertion part plays a role for a VHDL compiler.
>

Enable() is NOT static! It is a dynamic signal/variable that is driven
from elsewhere.

Note that I said "in order for enable(n) to be considered". I did NOT
say "for enable(n) to be set"!
If enable(n-1) was set, then the loop would have exited before
evaluating enable(n). Therefore output gets data(n) only if enable(n)
= '1'  AND  enable(n-1) = '0' AND enable(n-2) = '0' AND... This
results in additional logic that is not necessary if it is known that
the enable bits are mutually exclusive.

If you don't believe me, compare the synthesis results of your code
with Jim's code (since the assertion in my code is not understood by
synthesis yet). Jim's code is the logical equivalent of what a
synthesis tool should implement for your code (or my code), if the
tool was aware of, and could optimize for, mutual exclusivity.

> The static values may be all 0. So that no code would be generated for
> the code segment. Are you serious enough to design a mechanims to deal
> with the stupid case only?

Since you ask, this function is intended for a clocked process, so
"doing nothing" means maintaining the previous value (i.e. a clock
enable), which is far from a "stupid case".

Andy


Article: 123892
Subject: Re: high bandwitch ethernet communication
From: eliben <eliben@gmail.com>
Date: Thu, 06 Sep 2007 18:25:15 -0000
Links: << >>  << T >>  << A >>
On Sep 6, 4:45 pm, John McCaskill <jhmccask...@gmail.com> wrote:
> On Sep 6, 12:22 am, eliben <eli...@gmail.com> wrote:
>
>
>
> > > If you have the choice between UDP and TCP, UDP is much simpler and
> > > fits an FPGA well. The big issue in choosing between the two is if you
> > > require the guaranteed delivery of TCP, or can tollerate the potential
> > > packet loss of UDP.
>
> > > As an example, we make a card that acquires real time data in a custom
> > > protocol that is wrapped in UDP. We use a Xilinx Virtex-4 FX60, and a
> > > protocol offload engine that uses the Xilinx PicoBlaze soft processor
> > > to deal with the protocol stack.  The PicoBlaze is an 8-bit soft
> > > processor.  It looks at each incomming packet and reads the header to
> > > see if it is one of the real time streams we are trying to offload.
> > > If it is, it sends the header to one circular buffer in memory and the
> > > data to another circular buffer.  If it is not, it sends it to a
> > > kernel buffer and we let the Linux network stack deal with it.
>
> > > With this setup, we can consume data at over 90 MB/sec per Gigabit
> > > Ethernet port.  The data part of the packet is 1024 bytes, and each
> > > GigE port has its own PicoBlaze dedicated to it.
>
> > So where is the actual UDP communication implemented ? In Linux ? What
> > processor is it running on ? Is it an external CPU or the built-in PPC
> > of Virtex 4 ?
>
> We are using one of the embedded PowerPCs to run Linux, and one
> PicoBlaze soft processor per EMAC in the design.
>
> As each packet exits the EMAC, its header is examined by software that
> is running on the PicoBlaze.  The PicoBlaze is running a very simple
> stack written in assembly language.  As it looks at each layer of the
> header, it makes a decision to do one of several things. At the
> Ethernet level, it is deciding if it should just throw the packet
> away, or pass it on to the next layer. At the IP and UDP layers, it is
> deciding if the packet belongs to the protocol that we are offloading,
> and is a stream that we have requested.  If the packet does belong to
> the protocol that we are offloading, the PicoBlaze sets up a PLB DMA
> engine to send it down one data path. If the packet does not belong to
> the protocol we are offloading, then the PicoBlaze sends it down
> another data path and it is given to the Linux kernel to deal with.
>
> So for the protocol that we are offloading, the entire Ethernet, IP,
> UDP, and custom protocol stack are implemented in PicoBlaze assembly
> code.  For everything else, the stack is in Linux.  Since the data we
> are offloading is multicast data, this lets us have the PicoBlaze deal
> with the simple but high speed UDP packets, and the PowerPC running
> Linux deal with the IGMP messaging required to join, leave and
> maintain membership in a multicast group.
>
> The PicoBlaze is just running a single threaded loop of code that
> polls for input or output data, and then deals with it.  Its program
> is loaded from the PowerPC taking advantage of the fact that the BRAM
> holding its program is dual ported.

At what frequency does the PicoBlaze run ? It must be pretty fast to
deal with packets at this bandwidth. Or is the fact that it's only
examining the frame headers saves you from the need of high speed ?

Thanks
Eli



Article: 123893
Subject: Re: Free downloadable PDF graph paper.
From: Gabor <gabor@alacron.com>
Date: Thu, 06 Sep 2007 11:33:42 -0700
Links: << >>  << T >>  << A >>
On Sep 6, 1:44 pm, "Symon" <symon_bre...@hotmail.com> wrote:
> Dear All,
> I found this online and found it useful. Maybe you will too.http://incompetech.com/graphpaper/
> Cheers, Syms.


Very cute.  I usually use Visio for making graph paper.  They seem
to be missing my favorite one - timing diagram paper.

Regards,
Gabor


Article: 123894
Subject: Clock boundary crossing
From: axr0284 <axr0284@yahoo.com>
Date: Thu, 06 Sep 2007 18:46:16 -0000
Links: << >>  << T >>  << A >>
What are the different ways of crossing clock boundaries. Is there any
website with good information on that. Thanks
Amish


Article: 123895
Subject: Re: high bandwitch ethernet communication
From: John McCaskill <jhmccaskill@gmail.com>
Date: Thu, 06 Sep 2007 18:47:26 -0000
Links: << >>  << T >>  << A >>
On Sep 6, 1:25 pm, eliben <eli...@gmail.com> wrote:
> On Sep 6, 4:45 pm, John McCaskill <jhmccask...@gmail.com> wrote:
>
>
>
> > On Sep 6, 12:22 am, eliben <eli...@gmail.com> wrote:
>
> > > > If you have the choice between UDP and TCP, UDP is much simpler and
> > > > fits an FPGA well. The big issue in choosing between the two is if you
> > > > require the guaranteed delivery of TCP, or can tollerate the potential
> > > > packet loss of UDP.
>
> > > > As an example, we make a card that acquires real time data in a custom
> > > > protocol that is wrapped in UDP. We use a Xilinx Virtex-4 FX60, and a
> > > > protocol offload engine that uses the Xilinx PicoBlaze soft processor
> > > > to deal with the protocol stack.  The PicoBlaze is an 8-bit soft
> > > > processor.  It looks at each incomming packet and reads the header to
> > > > see if it is one of the real time streams we are trying to offload.
> > > > If it is, it sends the header to one circular buffer in memory and the
> > > > data to another circular buffer.  If it is not, it sends it to a
> > > > kernel buffer and we let the Linux network stack deal with it.
>
> > > > With this setup, we can consume data at over 90 MB/sec per Gigabit
> > > > Ethernet port.  The data part of the packet is 1024 bytes, and each
> > > > GigE port has its own PicoBlaze dedicated to it.
>
> > > So where is the actual UDP communication implemented ? In Linux ? What
> > > processor is it running on ? Is it an external CPU or the built-in PPC
> > > of Virtex 4 ?
>
> > We are using one of the embedded PowerPCs to run Linux, and one
> > PicoBlaze soft processor per EMAC in the design.
>
> > As each packet exits the EMAC, its header is examined by software that
> > is running on the PicoBlaze.  The PicoBlaze is running a very simple
> > stack written in assembly language.  As it looks at each layer of the
> > header, it makes a decision to do one of several things. At the
> > Ethernet level, it is deciding if it should just throw the packet
> > away, or pass it on to the next layer. At the IP and UDP layers, it is
> > deciding if the packet belongs to the protocol that we are offloading,
> > and is a stream that we have requested.  If the packet does belong to
> > the protocol that we are offloading, the PicoBlaze sets up a PLB DMA
> > engine to send it down one data path. If the packet does not belong to
> > the protocol we are offloading, then the PicoBlaze sends it down
> > another data path and it is given to the Linux kernel to deal with.
>
> > So for the protocol that we are offloading, the entire Ethernet, IP,
> > UDP, and custom protocol stack are implemented in PicoBlaze assembly
> > code.  For everything else, the stack is in Linux.  Since the data we
> > are offloading is multicast data, this lets us have the PicoBlaze deal
> > with the simple but high speed UDP packets, and the PowerPC running
> > Linux deal with the IGMP messaging required to join, leave and
> > maintain membership in a multicast group.
>
> > The PicoBlaze is just running a single threaded loop of code that
> > polls for input or output data, and then deals with it.  Its program
> > is loaded from the PowerPC taking advantage of the fact that the BRAM
> > holding its program is dual ported.
>
> At what frequency does the PicoBlaze run ? It must be pretty fast to
> deal with packets at this bandwidth. Or is the fact that it's only
> examining the frame headers saves you from the need of high speed ?
>
> Thanks
> Eli


We run the EMAC 8 bits wide at 125 MHz, and the PicBlaze at 62.5 MHz
using a divided by two version of the EMAC clock.  The PicoBlaze takes
two cycles per instruction, and the packets we are offloading are a
bit over 1KB, so we about 512 instructions to deal with an offloaded
packet and other overhead.  Dealing with a non-offloaded packet takes
the shortest path through the code to keep the number of packets per
second we can handle up.  The network the data is on is tightly
controlled, so there is very little on it that is not the protocol we
are offloading, mostly just IGMP packets for dealing with the
multicast groups, and they are at a very low rate.

You are correct in that we do not look at the entire packet with the
PicoBlaze, just the header.  Once it has determined that it wants to
offload that packet, it then has a little bit more work to do to
calculate addresses and load them into the DMA engine.  To make sure
that we do not drop packets, we just need to make sure that the
longest path through the code takes less time than about how long it
takes to receive a packet.  We have a FIFO between the EMAC and the
DMA engine, so we can smooth things out a bit.

Regards,

John McCaskill
www.fastertechnology.com


Article: 123896
Subject: Problem locking a DCM driven by FX output of another DCM
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 6 Sep 2007 14:50:14 -0400
Links: << >>  << T >>  << A >>
I have a design with 3 DCMs. The first DCM generates 280 MHz out of 210 MHz. 
It is then divided by 2 and 4 in a PMCD. There are 2 more DCMs, one driven 
by resulting 70 MHz clock and another by 140 MHz clock. Both have problem 
locking. Their resets are slightly delayed and negated locked condition of 
the first DCM. As it stands now I need to reset the first DCM a few times 
until I get all 3 locked (the first DCM locks every time easily). The 
frequency ranges for all of the DCMs seem to be set correctly.

Any ideas?


Thanks,
/Mikhail 



Article: 123897
Subject: Re: Problem locking a DCM driven by FX output of another DCM
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 6 Sep 2007 14:56:43 -0400
Links: << >>  << T >>  << A >>
Forgot to mention that it is all taking place in a V4 device...

/Mikhail 



Article: 123898
Subject: Re: Problem locking a DCM driven by FX output of another DCM
From: John McCaskill <jhmccaskill@gmail.com>
Date: Thu, 06 Sep 2007 19:05:28 -0000
Links: << >>  << T >>  << A >>
On Sep 6, 1:56 pm, "MM" <mb...@yahoo.com> wrote:
> Forgot to mention that it is all taking place in a V4 device...
>
> /Mikhail



The FX output jitter spec of the DCMs does not meet the input jitter
requirements of the DCMs.  What you are trying to do will not work
reliably.

Regards,

John McCaskill
www.fastertechnology.com


Article: 123899
Subject: Re: Problem locking a DCM driven by FX output of another DCM
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 6 Sep 2007 15:11:31 -0400
Links: << >>  << T >>  << A >>
"John McCaskill" <jhmccaskill@gmail.com> wrote in message 
news:1189105528.073561.184050@d55g2000hsg.googlegroups.com...
>
> The FX output jitter spec of the DCMs does not meet the input jitter
> requirements of the DCMs.  What you are trying to do will not work
> reliably.

Yes, I remember reading it... So, no hope here? Anyone from Xilinx? I don't 
care much about the output jitter on the two DCMs, I just need them to 
produce the clocks at right frequencies.... If I can't do it, I am in real 
trouble...


Thanks,
/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