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 123850

Article: 123850
Subject: Re: New keyword 'orif' and its implications
From: Jim Lewis <jim@synthworks.com>
Date: Wed, 05 Sep 2007 20:22:22 -0700
Links: << >>  << T >>  << A >>
Weng,
> Jim just unexpertly devised a mechanism that is almost 
> useless in its purpose. 
What do you hope to accomplish by belittling other people?
This is not going to help promote your thoughts.

Please note, I did not participate in the PSL effort, I simply
observed that PSL (with the Accellera VHDL-2006 integration)
provides a capability that seems to address a number of the
use cases you are implying you need.


> I would like to thank for your discussion on this topics, because
> through our discussions I realized that if one wants to transfer
> mutually exclusive information to VHDL compiler, he must stick with
> the 'if...end if' statement strucure. Before it, I failed to recognize
> it. This is what I said you had given me as a gift.
Yet you have failed to demonstrate anything to anyone
other than yourself.

Unfortunately, your ideas will not go anywhere unless someone
follows the steps I outlined previously.  All proposals put
forward to the working group must go through these steps
of analysis of both the capability requested and the
proposed solution.  At this point, I don't see anyone
as excited as yourself to handle this.


> Please declare who is the
> wiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiner.
Any volunteers :)

Cheers,
Jim

Article: 123851
Subject: Re: New keyword 'orif' and its implications
From: Jim Lewis <jim@synthworks.com>
Date: Wed, 05 Sep 2007 20:50:42 -0700
Links: << >>  << T >>  << A >>
Andy and Weng,
> Andy's code:
> for i in enable(i) loop
>   if enable(i) = '1' then
>     output <= data(i);
>     exit;
>   end if;
> end loop;
> assert zero_one_hot(enable); <-- useless and wasting time in its
> purpose
> 
> Weng's code:
> for i in enable(i) loop
>   if enable(i) = '1' then
>     output <= data(i);
>     exit;
>   end if;
> end loop;

I note that both of these have priority built into
the logic as the exit makes only the first enable set
take effect.  Hence, without additional information (such as
the assertion), a synthesis tool will be obliged to create
the priority that is in the code.

If we really want mutually exclusive logic, then perhaps
a variable will do the trick.  For give me if someone else
already suggested this as I have not re-read the threads.

process (enable, data)
   variable vOutput : std_logic_vector(...) ;
begin
   vOutput := (others => '0') ;   -- assuming combinational logic
   for i in enable'range loop
     if enable(i) = '1' then
       vOutput := data(i) or vOutput ;
     end if;
   end loop;
   Output <= vOutput ;
end process ;

For those that like testing code on synthesis tools, I would
be curious to know how that plays the following (which is more
hardware implementation specific):

process (enable, data)
   variable vOutput : std_logic_vector(...) ;
begin
   vOutput := (others => '0') ;   -- assuming combinational logic
   for i in enable'range loop
     vOutput := (data(i) and enable(i)) or vOutput ; -- vhdl-2006 "and"
   end loop;
   Output <= vOutput ;
end process ;


If you are coding this in a clocked process, you can put guard on
the enable using the reduction form of or (from VHDL-2006) or replace
it with or_reduce from ieee.std_logic_misc (not a standard package and
hence not recommended by me):

process (Clk)
   variable vOutput : std_logic_vector(...) ;
begin
   if rising_edge(Clk) then
     if OR( enable) = '1' then
       vOutput := (others => '0') ;   -- assuming combinational logic
       for i in enable'range loop
         vOutput := (data(i) and enable(i)) or vOutput ; -- vhdl-2006 "and"
       end loop;
       Output <= vOutput ;
     end if ;
   end if ;
end process ;


Cheers,
Jim
SynthWorks VHDL Training

Article: 123852
Subject: Re: high bandwitch ethernet communication
From: eliben <eliben@gmail.com>
Date: Thu, 06 Sep 2007 05:20:14 -0000
Links: << >>  << T >>  << A >>
> My first choice would be some other, more embeddable, processor running
> off to the side.  A PowerPC from Freescale, or an ARM processor from just
> about anybody, comes to mind.  I suspect that even a modest such processor
> would get some pretty high speeds if that's all it was doing.
>
> You may have to bite the bullet and write your own stack that's shared
> between a processor and the FPGA.  I know practically nothing about
> TCP/IP, but I'm willing to bet that once you've signed up to writing
> or modifying your own stack there are some obvious things to put into the
> FPGA to speed things up.

Thanks, this is the design I'm now leaning towards. However, I have a
concern regarding the high-speed communication between the FPGA and
the outside Processor. How is it done - using some high speed outside
DDR memory ?

Eli



Article: 123853
Subject: Re: high bandwitch ethernet communication
From: eliben <eliben@gmail.com>
Date: Thu, 06 Sep 2007 05:22:15 -0000
Links: << >>  << T >>  << A >>
> 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 ?

>
> 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


Article: 123854
Subject: Re: FPGA CPU
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 05 Sep 2007 21:28:58 -0800
Links: << >>  << T >>  << A >>
Göran Bilski wrote:


> Internal tristates are gone from Xilinx devices.
> 
> There is a way of implement efficient large muxes by using DFFs
> and the carry-chain.  The solution is using many DFFs but usually
 > you use less DFFs than LUTs in a design.
> You would let each source to mux passing through a DFF
 > with a synchronous reset.  All DFFs are kept in reset state
 > except the source that you have selected to mux.
> This allows you to just OR all the sources since only the 
 > selected sources is not under reset.

> The ORing can be done using carry-chain to even further
> decrease the LUT usage.   It's it in fact an AND-OR structure
 > but the AND is coming from the synchronous reset in a DFF

Doesn't that make it synchronous, when tristate buffers
are normally asynchronous?  If the buffer drives, or all
are driven, by latches then it would seem to work.

-- glen


Article: 123855
Subject: Re: high bandwitch ethernet communication
From: Tim Wescott <tim@seemywebsite.com>
Date: Thu, 06 Sep 2007 00:51:50 -0500
Links: << >>  << T >>  << A >>
On Thu, 06 Sep 2007 05:20:14 +0000, eliben wrote:

>> My first choice would be some other, more embeddable, processor running
>> off to the side.  A PowerPC from Freescale, or an ARM processor from just
>> about anybody, comes to mind.  I suspect that even a modest such processor
>> would get some pretty high speeds if that's all it was doing.
>>
>> You may have to bite the bullet and write your own stack that's shared
>> between a processor and the FPGA.  I know practically nothing about
>> TCP/IP, but I'm willing to bet that once you've signed up to writing
>> or modifying your own stack there are some obvious things to put into the
>> FPGA to speed things up.
> 
> Thanks, this is the design I'm now leaning towards. However, I have a
> concern regarding the high-speed communication between the FPGA and
> the outside Processor. How is it done - using some high speed outside
> DDR memory ?
> 
> Eli

I've always seen it implemented as a plain ol' asynchronous memory
interface, as seen in the '70's and '80's.  Most processors support it,
and it's not too shabby.

If you have to have the processor fondling the data bits then mapping the
FPGA as synchronous static RAM or SDRAM may be quicker, but it'll
certainly be more problematic.

-- 
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

Article: 123856
Subject: Re: high bandwitch ethernet communication
From: Paul Keinanen <keinanen@sci.fi>
Date: Thu, 06 Sep 2007 10:52:43 +0300
Links: << >>  << T >>  << A >>
On Wed, 05 Sep 2007 18:06:16 -0700, Janaka <janakas@optiscan.com>
wrote:

>We've are using the MPC8349E at 400Mhz core and got only 480mbit/s
>sustained UDP data rate.  These processors are marketed as
>communications processors but only have low level HW support (on
>Ethernet layer).  All the upper level IP and UDP protocols are handled
>in software (when running linux).  So it takes up CPU time.  Same
>setup on two desktop PCs running linux yeilds 840mbit/s sustained UDP
>rate.

If the OP required only something dedicated point to point
connectivity, why bother with the IP wrapper, just send raw Ethernet
frames with MAC addressing ?

Apparently that MPC has some modern version of the QUICC co-processor
(as found on the MC68360), in which it is quite easy to set up one BD
(buffer descriptor) for the (possibly fixed) header and an other for
the actual data. The co-processor assembles the frames from the
fragments, sends them autonomously, appends the CRC and then search
for next ready frame to be sent, without any further main processor
intervention. 

The hard thing is to get the transmit data into the transmit buffers
fast enough, but for direct port to port copying, there should not be
much need to move the actual data in the memory.

Paul


Article: 123857
Subject: Re: PCB Impedance Control
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 6 Sep 2007 09:45:31 +0100
Links: << >>  << T >>  << A >>
"John_H" <newsgroup@johnhandwork.com> wrote in message 
news:13du7f5m3gr6v9f@corp.supernews.com...
> "PeteS" <axkz70@dsl.pipex.com> wrote in message
> How the hell does the signal switch sides?  A via!  A hole between the top 
> and bottom layers of the plane that has a skin effect associated with its 
> edge.  The ground plane skin-effect current limited to the top several 
> microns of the top signal's reference and the bottom several microns of 
> the bottom signal's reference switches sides around the skin of the via 
> edge. There is no mystery and no pondering unless the signal changes sides 
> of the reference plane without using a hole in the plane.  Wouldn't that 
> be a feat?
>
> - John_H
>
Hi John,
Well, of course. I thought John L. was joking, because in the original 
article I posted a link for, the author goes on to explain that and says :-
"Therefore, when a signal passes through a via and continues on the opposite 
side of the same plane a return current discontinuity does not exist.  This 
is, therefore, the preferred way to route a critical signal if two routing 
layers must be used."
That doesn't sound moronic to me. ;-)
Cheers, Symon. 



Article: 123858
Subject: Re: PCB Impedance Control
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 6 Sep 2007 09:47:50 +0100
Links: << >>  << T >>  << A >>
"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. 



Article: 123859
Subject: Re: How to deal with the tempary coefficient in the FPGA design
From: ZHI <threeinchnail@gmail.com>
Date: Thu, 06 Sep 2007 01:57:12 -0700
Links: << >>  << T >>  << A >>
On 5 Sep, 23:10, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> ZHI wrote:
> > In my FPGA design, I need a result of EXP(z: is complex) as a tempary
> > coefficient for other calculations. I've known to deal with the real
> > part and imagin part separately.
>
> exp(x+iy)=exp(x)exp(iy)
>
> > But I don't know how to deal with the floating point numbers.
>
> Floating point in an FPGA is somewhat hard, but not impossible.
> You might be able to use fixed point but non-integer arithmetic.
> Otherwise, in an FPGA floating point multiply is easier than
> floating point addition.
>
>  > I only managed to deal with the easy floating
>
> > point things, e.g. 2**(-A), A is an integer. I don't know how to deal
> > with the tempary coefficient in the floating point type in the FPGA
> > design. Does anyone here has the similar experience to deal with
> > floating point as the tempary coefficient in the FPGA design? Can tell
> > me some tip about this? Thank you.
>
> I would need to know a lot more about what you are trying to
> do to say more.  Otherwise, my favorite architecture for such
> systems is a systolic array processor.
>
> -- glen

I prefer to use fixed-point in this FPGA design. What I am doing is to
implement an algorithm, which is written in Matlab.  I am trying to
implement it into FPGA board. There are some things to be considered.
E.g. EXP function, COS function in Matlab. I know there are the same
functions in VHDL as well. But the result is floating-point. I can
guarantee the FPGA input numbers are fixed-point numbers.  There
happens the floating-point numbers in the process of calculation like
the result of above function. How to solve it? I want everything in
the algorithm is fixed point. I will firstly simulate the algorithm in
Matlab with fixed-point. I did not think out how to deal with these
function results.


Article: 123860
Subject: Re: PCB Impedance Control
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 6 Sep 2007 10:14:40 +0100
Links: << >>  << T >>  << A >>
"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?

It's important to realise that transmission lines are not just defined by 
capacitance. The structures have inductance also. 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.

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.

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 



Article: 123861
Subject: Re: high bandwitch ethernet communication
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Thu, 06 Sep 2007 04:40:56 -0500
Links: << >>  << T >>  << A >>
I suggest that you go back and read John McCaskill's response.
It would probably help to discuss things with a network wizard.
You want a low level protocol geek, not a web designer.
(especially one who knows something about hardware)

I think the real question is what happens when a packet
gets lost?  If you are using TCP, you have to buffer
all the data until it gets ACKed.  If you are using UDP,
you drop some data.

UPD in send-only mode doesn't really require a stack.


>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 ?

If I was doing this (or something like what I think you
are doing), I would try to do all the UDP in the FPGA.
The header is just a bunch of constants.  You probably want
a sequence number in your payload.  Then you have to compute the
CRC.  The whole thing is well specified and you can be sure
it will run fast enough as long as the network doesn't get
congested.  No ACKs, just fire and forget.

An alternative approach is to get the data into a PC
somehow, and do the UDP/whatever work from that PC.

As somebody else already suggested, one "easy" way to get
the data into a PC would be to use Ethernet on a point to
point link.  You don't even need a CRC.  This is easy for the
hardware.  The software guys might not like it.  They have
to steal the ethernet port from the software stack and
write a driver.  You might look at tcpdump and see how
it handles packets with CRC errors.

There are various PCI boards with an FPGA on them.
If you can get your data on to one of those cards, then you
can DMA it into memory.  That still needs software but it
is a slightly different type of software.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 123862
Subject: Re: ?Nios II?How Can I Find Out These Functions ?
From: Iwo Mergler <Iwo.Mergler@soton.sc.philips.com>
Date: Thu, 06 Sep 2007 11:16:04 +0100
Links: << >>  << T >>  << A >>
 hezhikuan2007@gmail.com wrote:

> 
> I'm a beginner in the Nios II System. When I learn the examples
> provided by Nios II IDE, I always see this type's function :
>  IOWR_ALTERA_AVALON_PIO_DATA(LED_PIO_BASE, count);
> The function appears in the example "count_binary".

The macro is setting a register in one of the GPIO devices, in
this case the first one, at the base address. LED_PIO_BASE is
the base address of the device, as it was assigned in the SOPC
builder.

> 
> But I can't find out the detailed information about this type
> function , only find these three  messages:
> #define IOWR_ALTERA_AVALON_PIO_DATA(base, data)       IOWR(base, 0,
> data)
This translates it to a generic base+offset register access.

> 
> #define IOWR(BASE, REGNUM, DATA) \
>   __builtin_stwio (__IO_CALC_ADDRESS_NATIVE ((BASE), (REGNUM)),
> (DATA))
However, IOWR uses register numbers rather than register
offsets. The register offset for a given number depends on
the bus width.

> 
> #define __IO_CALC_ADDRESS_NATIVE(BASE, REGNUM) \
>   ((void *)(((alt_u8*)BASE) + ((REGNUM) * (SYSTEM_BUS_WIDTH/8))))

This works out the final register address.

> 
> But I still don't understand the meanning of this function.
> Please tell me how can I find out the detailed information about these
> types' function?

In your simple example, the call

IOWR_ALTERA_AVALON_PIO_DATA(LED_PIO_BASE, count);

is equivalent to 

*(volatile unsigned long *)LED_PIO_BASE = count;

In other words, it is a write to the bus address specified in
LED_PIO_BASE. However, if you want to keep your code portable
between different NIOS systems, use the macros.

Kind regards,

Iwo


Article: 123863
Subject: Re: clock skew problems
From: Joseph Samson <user@not.my.company>
Date: Thu, 06 Sep 2007 06:51:58 -0400
Links: << >>  << T >>  << A >>
michel.talon@gmail.com wrote:
> Hi all,
> 
> I've got a FPGA design with a lot of clocks! 

> ISE
> gives me warnings :
> Route:447  - CLK Net : my_clock may have excessive skew because 2 NON-
> CLK pins failed to route using a CLK template. ( I've this warning for
> a lot of others clock generated by combinatorial logics... )
> 
> My question is how can I locate the 2 NON-CLK pins 

Use FPGA Editor to open the routed design.
Find the clock net and highlight it.
Press F2, or select Edit -> Properties of Selected Items...
Choose the 'Pins' tab.
You will see a list of all the pins on that net.
Scroll down the list until you find pins that don't have .CLK (or some 
variant like .ICLK1 or .CLKA) in their name.


---
Joe Samson
Pixel Velocity

Article: 123864
Subject: FATAL ERROR ISE9.1i
From: james.lbs@gmail.com
Date: Thu, 06 Sep 2007 03:52:51 -0700
Links: << >>  << T >>  << A >>
Hi,

i get this message when i run post & route:

Starting Placer
FATAL_ERROR:Portability:PortDynamicLib.c:358:1.27 - dll open of
library <C:/Xilinx91i/xilinx/bin/nt/libPlXil_Clocks.dll> failed due to
an unknown reason. Process will terminate.

Process "Place & Route" failed

Could somebody help me?


Article: 123865
Subject: Re: FATAL ERROR ISE9.1i
From: Helmut <helmut.leonhardt@gmail.com>
Date: Thu, 06 Sep 2007 04:08:49 -0700
Links: << >>  << T >>  << A >>
Hi,

I have the same problem with ISE 9.2.02 IP1
But with all my projects run with ISE 9.1.03 IP2, so returning to
previous ISE helps in my case.

Bye HL

> Starting Placer
> FATAL_ERROR:Portability:PortDynamicLib.c:358:1.27 - dll open of
> library <C:/Xilinx91i/xilinx/bin/nt/libPlXil_Clocks.dll> failed due to
> an unknown reason. Process will terminate.
>
> Process "Place & Route" failed


Article: 123866
Subject: Re: high bandwitch ethernet communication
From: eliben <eliben@gmail.com>
Date: Thu, 06 Sep 2007 11:19:09 -0000
Links: << >>  << T >>  << A >>
On Sep 6, 9:52 am, Paul Keinanen <keina...@sci.fi> wrote:
> On Wed, 05 Sep 2007 18:06:16 -0700, Janaka <jana...@optiscan.com>
> wrote:
>
> >We've are using the MPC8349E at 400Mhz core and got only 480mbit/s
> >sustained UDP data rate.  These processors are marketed as
> >communications processors but only have low level HW support (on
> >Ethernet layer).  All the upper level IP and UDP protocols are handled
> >in software (when running linux).  So it takes up CPU time.  Same
> >setup on two desktop PCs running linux yeilds 840mbit/s sustained UDP
> >rate.
>
> If the OP required only something dedicated point to point
> connectivity, why bother with the IP wrapper, just send raw Ethernet
> frames with MAC addressing ?
>

I wondered about that, actually. But working on the MAC level is very
inflexible. For example:

1) What if the client computer gets replaced by an equivalent
computer. Each NIC has a unique MAC address, and so I'll have to
reconfigure my sender, or set up some manual MAC discovery protocol.

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.

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.

Eli











Article: 123867
Subject: REGARDING ILA in FPGA EDITOR
From: bunty <mailmurali18@gmail.com>
Date: Thu, 06 Sep 2007 04:58:43 -0700
Links: << >>  << T >>  << A >>
Hi all,

I am using ISE 9.1I and Chipscope 9.1i. I tried to change some nets in
ILA thorogh FPGA EDITOR ila command. It allowed me to change through
Change Net Option. I generate Bit file with the changed .ncd and .pcf
files and I have generated bit file also. When I tried to download
that one to FPGA, In chipscope pro analyzer, I tried to import the new
CDC file, all nets names are gone , they are showing just as
ila_****_data_dly[0] like that. I tried with the original cdc file, it
worked but it retained old names.
Plz tell me is there any option in FPGA editor to see full names of
net in ILA in FPGA_EDITOR. The changes has to be reflected in teh new
CDC.


Article: 123868
Subject: JTAG CPLD Configuration
From: "Keith" <nononono@no.no>
Date: Thu, 6 Sep 2007 13:42:27 +0100
Links: << >>  << T >>  << A >>
Hello

I have a Xilinx XCR3064 CPLD with its JTAG pins hooked up to
some digital I/O pins on a uC.  I intend to configure the CPLD
from a binary file held in uC flash by bit-banging the uC pins.
So far I've implemented the TAP state machine and managed to
correctly read the 32 bit ID code, so a start has been made.

But what to do now?  The documentation seems sparse or
overwhelming but undetailed.

What I've found so far is:

<quote>
CoolRunner Programming Algorithm

Enter the device into ISP mode
Erase the entire device
Program all addresses
Verify all addresses
Exit the ISP mode and return to normal functional mode.
</quote>

Which all seems fair enough but insufficient.  Do I use the
commands isp-write, then clock in the bitstream followed by
isp-program? Is there some sort of flag which will tell me when
an erase or write has finished?

How do I make the bitstream from an ascii .jed file?  Do I just
ignore the various markers and bundle the 0's and 1's into a
binary file?

These svf and xsvfs files look a bit unnecessary.  Is the
bitstream loaded in one lump?  Is the erase just one command?

All these questions and more; I know many people must have done
this but can't find anything clear.  I've not used JTAG before,
so it's all a bit confusing.  I did it years ago with a
RAM-based FPGA but that was an easy non-JTAG port method.

There are good technical reasons for not using an FPGA for this
which I can't go into.

Help?

TVM
-- 
Keith Wootten
PS.  First time for using Outhouse on newsgroups, so sorry in
advance for incorrect formats etc.





-- 
Posted via a free Usenet account from http://www.teranews.com


Article: 123869
Subject: Question about timing of Xilinx Core generated counter
From: fl <rxjwg98@gmail.com>
Date: Thu, 06 Sep 2007 05:49:39 -0700
Links: << >>  << T >>  << A >>
Hi,
I find a problem in the simulation of watchvhd example from Xilinx ISE
8.2 or 9.1. There is a Core generated counter, named xcounter. Even I
perform behavioral simulation, its 4-bit output (q) has 2ns delay with
its clk. Other (onesout and tensout) have no such problems. For
behavioral simulation, I think that it should not have timing delay
with clock. What is the problem? Thank you very much.


Article: 123870
Subject: Re: PCB Impedance Control
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 06 Sep 2007 13:11:43 GMT
Links: << >>  << T >>  << A >>
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

Article: 123871
Subject: Re: New keyword 'orif' and its implications
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 06 Sep 2007 14:21:31 +0100
Links: << >>  << T >>  << A >>
On Wed, 05 Sep 2007 17:52:28 -0700, Weng Tianxiang <wtxwtx@gmail.com>
wrote:

>On Sep 5, 12:16 pm, Andy <jonesa...@comcast.net> wrote:
>> > "Conversely, there are several situations where
>> > 'orif' is not an option, but an assertion would be. "

>> If you can re-write the following with an if-orif tree to indicate
>> that every element in enable is mutually exclusive, then you win!

>> type data_t is array (enable'range) of std_logic_vector(output'range);
>> signal data: data_t; -- could be a port instead...
>> ...
>> Andy
>
>Hi Andy,
>
>Your code:
>for i in enable(i) loop
>  if enable(i) = '1' then
>    output <= data(i);
>    exit;
>  end if;
>end loop;
>assert zero_one_hot(enable); <-- useless and wasting time in its
>purpose
>
>My code:
>for i in enable(i) loop
>  if enable(i) = '1' then
>    output <= data(i);
>    exit;
>  end if;
>end loop;
>
>Why do you need to tell VHDL compiler that every element in enable is
>mutually exclusive?
>
>My coding has already told VHDL compiler that
>1. all enable(i) are mutually exclusive;
>2. You don't have to do anything, I have done it for you and please
>take the rest.

Unfortunately, enable was accidentally set to "00010111"

Andy's code caught the problem before synthesis, so he fixed it.
Because his synthesis tool (the 2008 version) understood the assertion,
it was free to generate fast logic instead of following the priority.

Yours did not, and if your synthesis tool believed statement (1) above,
instead of following the priority built into the loop, it enabled four
drivers onto the "output" bus at once.

While you contemplate the smoking remains of your chip, you are invited
to explain how your comment "What assertion onehot0() can do, orif can
do better !" applies to this example.

- Brian


Article: 123872
Subject: load/read/ commands assembly PowerPC. Help Needed!
From: xenix <lastval@gmail.com>
Date: Thu, 06 Sep 2007 13:30:25 -0000
Links: << >>  << T >>  << A >>
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


Article: 123873
Subject: Re: high bandwitch ethernet communication
From: Paul Keinanen <keinanen@sci.fi>
Date: Thu, 06 Sep 2007 16:42:54 +0300
Links: << >>  << T >>  << A >>
On Thu, 06 Sep 2007 11:19:09 -0000, eliben <eliben@gmail.com> wrote:

>On Sep 6, 9:52 am, Paul Keinanen <keina...@sci.fi> wrote:

>> If the OP required only something dedicated point to point
>> connectivity, why bother with the IP wrapper, just send raw Ethernet
>> frames with MAC addressing ?
>>
>
>I wondered about that, actually. But working on the MAC level is very
>inflexible. For example:
>
>1) What if the client computer gets replaced by an equivalent
>computer. Each NIC has a unique MAC address, and so I'll have to
>reconfigure my sender, or set up some manual MAC discovery protocol.

The "manual MAC discovery protocol" could be ARP, which is simple to
implement (manually creating the request IP header) and you get the
MAC address of the other partner. After that, you do not have to
bother about any IP addresses in the message headers in the actual
high speed data transfers. Only if you send the data to some hot
standby redundant system, in which the MAC address can change at any
time, but again, you just would have to repeat the ARP protocol query.
 
>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. 

I still assume that the current Ethernet card support the Promiscuous
mode, since there are a lot of Ethernet and TCP/UDP/IP analysing
programs working with standard Ethernet adapters. Are these analysing
programs using some dedicated driver stacks ?

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.
 
>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.

MAC broadcasts work well with hubs. This kind of MAC broadcast is used
in some producer/consumer model Ethernet based industrial networks
these days.

Paul


Article: 123874
Subject: Re: high bandwitch ethernet communication
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 06 Sep 2007 14:53:26 +0100
Links: << >>  << T >>  << A >>
On Thu, 06 Sep 2007 05:20:14 -0000, eliben <eliben@gmail.com> wrote:

>> My first choice would be some other, more embeddable, processor running
>> off to the side.  A PowerPC from Freescale, or an ARM processor from just
>> about anybody, comes to mind.  I suspect that even a modest such processor
>> would get some pretty high speeds if that's all it was doing.
>>
>> You may have to bite the bullet and write your own stack that's shared
>> between a processor and the FPGA.  I know practically nothing about
>> TCP/IP, but I'm willing to bet that once you've signed up to writing
>> or modifying your own stack there are some obvious things to put into the
>> FPGA to speed things up.
>
>Thanks, this is the design I'm now leaning towards. However, I have a
>concern regarding the high-speed communication between the FPGA and
>the outside Processor. How is it done - using some high speed outside
>DDR memory ?

If the FPGA was a Virtex-IIPro, or V4FX or so, the PowerPC wouldn't be
external.

Mind you, after designing logic, anything running on the PowerPC seems
painfully slow...

- Brian



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search