Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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, JimArticle: 123851
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> 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 ? EliArticle: 123853
> 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. EliArticle: 123854
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. -- glenArticle: 123855
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.htmlArticle: 123856
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. PaulArticle: 123857
"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
"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
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
"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.pdfArticle: 123861
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
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, IwoArticle: 123863
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 VelocityArticle: 123864
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
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" failedArticle: 123866
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. EliArticle: 123867
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
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.comArticle: 123869
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
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_HArticle: 123871
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. - BrianArticle: 123872
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? regardsArticle: 123873
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. PaulArticle: 123874
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:
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