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
Hi, > Hi, > just two guesses: > 1.) there's a port named std in the entity. The "std" can also be a constant defined somewhere in the design file or in "a package", also be careful about it too. Regards, EnesArticle: 127751
Thank you all for your replies. It helped me finding the right solution. Best Regards Hansen "austin" <austin@xilinx.com> wrote in message news:fllicq$l761@cnn.xsj.xilinx.com... > Hansen, > > They order from a distributor. > > Or, they go to the manufacturer's website, and order online through > their "store" (which actually takes you to a distributor). > > AustinArticle: 127752
Hi. I would like to hear your opinion on the possibility of implementing a processor in a CPLD? The functionality does not have to be greater than the old 8051 CPU, but I would like the flexibility and the possibility of adding additional logic to my design. Has someone worked on this issue, or have an opinion on how to complete this task? Looking forward to your replies Best RegardsArticle: 127753
Rgr <rgrworking@hotmail.com> wrote: > Hi. > I would like to hear your opinion on the possibility of implementing a > processor in a CPLD? > The functionality does not have to be greater than the old 8051 CPU, but I > would like the flexibility and the possibility of adding additional > logic to my design. > Has someone worked on this issue, or have an opinion on how to > complete this task? Look at http://www.xilinx.com/products/ipcenter/picoblaze-CR2.htm -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 127754
Hello, I am trying to send one single ethernet frame using Ethernet lite core in the XUP2VP board from Digilent Inc. I am unable to do so. I am trying to capture the sent packet using Wireshark. However, i am not receiving any packet. But if i repeat the send functional call in a for loop from 46 bytes to 1500 bytes, the frames are received in the packet capture utility. i am using the XEmacLite_Send function call to send an ethernet frame. Is there an issue which i need to look at while sending a single frame? kindly advice. Thanks in advance! Regards, G Aswin.Article: 127755
>> >> Hi, thanks for the replies, >> >> I thought my PCB might be the problem. I didn't perform any impedance >> matching or termination. I'm "tapping-off" the signals between the camera >> and framegrabber. So i have a straight through connection - camera to >> framegrabber and then "tap-off" the LVDS data-signals and clock and send >> these into the DS90CR288A. This way I can setup and control the camera >> using the camera software on PC, and just perform data processing on >> FPGA. >> > >Tapping into 7 * 66 MHz = 462 Mbps LVDS lines needs to be done >carefully >to avoid signal integrity problems at the receiver. However if your >LVAL and DVAL signals look correct, you may have lucked out... > >> I wasn't sure I needed to terminate the lines, as this would be performed >> further up the line - at the framegrabber end. The pixel clock from the >> camera should be 66MHz (I think), so thought I was on the right lines with >> a 16ns period. The chip however is the 85Mhz version. Is this a maximum? >> I'm not sure what the clock output of the chip should be - 85Mhz or >> 66MHz!? >> > >Channel-Link receivers have a wide frequency range of about 20 MHz >minimum to the specified maximum (66 or 85 MHz). 66 MHz should >work fine. > >> I can see data on the output of the chip, LVAL and DVAL signals are >> correct, not sure about the clock. As I say, the output voltage swing is >> about 600mV, and looks sinusoidal in shape on the scope - Sorry for the >> description! The distance between the chip and the connector is about >> 10mm. Do i need termination resistors across the differential lines in my >> case? > >You may be OK with the 10mm stubs. Definitely don't terminate them >if there is already termination at the framegrabber. Also if you >still get a proper picture at the framegrabber, you probably >have reasonable signal integrity. With your scope it would be >hard to look at this... > >I'm going to guess that the clock is correct, too, but that your >scope is bandwidth limiting the signal to form the sine wave you >see. What is the input bandwidth of your scope and probe? Did >you try to implement a simple T flip-flop in the FPGA to see if >the clock is getting into the chip OK? > >Regards, >Gabor > Thanks again Gabor.. The system does seem to be working ok. I get the correct image at the frame-grabber end, and all the signals do seem to be correct. The scope I'm using says 60MHz on it, I guess this the bandwidth - in which I guess it will struggle to observe the higher frequency signals?? I implemented a T-flip flop, and got a decent signal at half the input frequncy across an LED on the board, so it looks like everything is ok - probably just my VHDL letting me down! The LVAL, DVAL signals are working as expected aswell - used the LEDs to observe these. Just as an aside - when I increase the precision of the camera's output 8 bit to 16 bit, the camera sends the data in two "packets". For one LVAL pulse, the are two DVAL pulses. I think this maybe camera specific, but I think the data may be being sent low bits (0-7) with the first DVAL pulse, followed by high bits with the second. My camera is always is in camera-link BASE mode. I've scoped all the data channels from the chip, and the higher outputs are not used - apart from RxOut 27. Am I right thinking that in base mode the data should be re-created as: Bit(0) - RxOut 0 Bit(1) - RxOut 1 Bit(2) - RxOut 2 Bit(3) - RxOut 3 Bit(4) - RxOut 4 Bit(5) - RxOut 6 Bit(6) - RxOut 27 Bit(7) - RxOut 5 Just wondered if anyone else had any experience with 16 bit data in base mode? Regards Marc.Article: 127756
On Jan 6, 9:25 pm, Daniel Koethe <dkoe...@nospam-web.de> wrote: > ratemonotonic schrieb: > > > > > On 6 Jan, 16:44, Daniel Koethe <dkoe...@nospam-web.de> wrote: > >> The MPMC DDR-Interface is based on the MIG-Memory Controller. Download > >> athttp://www.xilinx.com/products/ipcenter/MIG.htmthe"User Guide" > >> (ug086.pdf). See page 331/332: Generic Memory Interface Guidelines. > > >> Daniel > > >> ratemonotonic schrieb: > > >>> Hi All , > >>> I am trying to interface microblaze with a Micron DDR SDRAM > >>> (MT46V16M16FG-75 16Mx16) using MPMC from the IP catalogue. As I am > >>> running on Spartan 3 FPGA I need to connect port lines - DDR_DQS_DIV_O > >>> and DDR_DQS_DIV_I , else I get errors , it also states that these > >>> should be connected in for spartan 3. > >>> The problem is that there is not much documentation about these port > >>> lines in the MPMC data sheet. Has anyone used this? does any one know > >>> how to connect these lines up? > >>> thanks in advance > >>> BR > >>> rate > > > Hi Daniel , > > > Thanks for the links the doc looks good and I am going through it now. > > Is the MPMC suitable to interface with asynchronous DDR SDRAMS? i.e. > > the reference board I am using has Micron MT46V16M16FG-75 16Mx16 part > > which takes min 75mhz clock. the microblaze on the board is running at > > 50 Mhz, but the board has 75Mhz clock. In the original design an OPB > > DDR SBRAM controller was used in which there was seperate control for > > the DDR clock inputs , but MPMC only seems to take the system clock as > > an input which is my case is 50 Mhz. How do I produce an 75 Mhz DDR > > clock from MPMC? > > The MPMC can not produce a 75Mhz clock from a 50 Mhz source. But the > MPMC supports 1:2 System/PIM clock and memory clock. > > See at page 50 of Datasheet MPMC (DS643) near "<PIM>_Clk". > > For example you have a 50Mhz source clock, use clk0 (system clock) and > clk2x output of a DCM to produce the 100Mhz memory clock. Do not forget > to connect clk0 and clkfb to assure zero phase offset. > > > > > Thanks very much , > > BR > > Rate Hi Daniel, Thanks a lot ! I sort of see light at the end of the tunnel now with your suggestion! I will let you know when I have tested the setup! Thanks rateArticle: 127757
On Jan 6, 1:59=A0pm, j...@capsec.org wrote: > I'd be happy if this could become a friendly cross vendor SoC > evironment, so please let me know if you're running into > difficulties.I understand that the absence of any documentation > for the build environment is a major hurdle :( Of course, I've tried to load the firmware and it runs smoothly except for a long term error (ld0) that, as far as I've seen, occurrs in the first few 5 - 8 read/write operations. I still have to dig into the problem, if I'll find something I'll report to you immediately. Maybe it's something about the DCM, a difference between the boards. BTW the absence of documentation is not a problem at all since I'm working on memory interface and your code is very good and readable. > Hearing about success stories would be nice too :) Well, I'll do my best but I'm just learning, and I cannot say I've ever done something worthy as far, just experiments! > I'm currently evaluating how to proceed -- I think a soft loaded TLB > architecture is the way to go. But I need to understand precisely how > the caches work inside the LM32... Keep up the good work, I'll keep an eye on the progress of the project. AndrewArticle: 127758
Rgr wrote: > Hi. > > I would like to hear your opinion on the possibility of implementing a > processor in a CPLD? > The functionality does not have to be greater than the old 8051 CPU, but I > would like the flexibility and the possibility of adding additional logic to > my design. > > Has someone worked on this issue, or have an opinion on how to complete this > task? > > Looking forward to your replies > Best Regards The Xilinx PicoBlaze or the open-source Mico-8 from Lattice should both be achievable in a CPLD but most CPLDs don't have memory. While it's more of a simple FPGA than an ASIC, the Altera Max-II series of "CPLDs" has some user Flash memory available on-chip. Most CPLDs will require external memory. - John_HArticle: 127759
On Jan 7, 2:13 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> JD Newcomb wrote:
> > float test = 22; // for example
> > printf("test = 0x%08x\r\n",test); // prints "test = 0x40360000"
> > printf("test = %d\r\n",test); // prints "test = 1077280768"
> > printf("test = %f\r\n",test); // prints "test = 22.000000" or
> > some precision
> > 22 in single-point floating point (hex) is 0x41B00000, and in double-
> > precision is 0x4036000000000000. So, truncate the double-precision
> > value and you have what's printed to the screen. I'm completely
> > baffled. Am I missing something? A gcc flag? How is this even possible
> > for a single-precision instruction set?
>
> That is C.
>
> C always converts (float) to (double) before passing it to a
> varargs function. %f expects a double, not a float, as it will
> always be converted before the call.
>
> try:
> printf("test = 0x%08x\r\n",*(int*)&test);
>
> (assumes sizeof(float)==sizeof(int), but you were already
> assuming that.)
>
> -- glen
Thanks Arlett. The Xilinx xil_printf() doesn't handle floats, so I was
forced to use hex. The 08x will force %x to only print 32 bits anyway,
which is what I want.
Glen, this conversion on a single-precision processor like the
MicroBlaze is emulated to be double-precision, correct? This seems, to
me, the only way that it can be done on such a processor. But I am not
100% sure about that. And floats and ints on the MIcroBlaze are the
same size (4 bytes). So, the value in memory might be correct, though
the value printed is not. Yay for unnecessary conversions.
Your test proved correct. I've also used a direct read of the memory
address in a similar way using the xio.h functions, which prints the
same correct value. Thanks for your help, guys.
Article: 127760"John_H" <newsgroup@johnhandwork.com> wrote in message news:lt6dncs0fYiIrx_anZ2dnUVZ_j-dnZ2d@comcast.com... > Rgr wrote: >> Hi. >> >> I would like to hear your opinion on the possibility of implementing a >> processor in a CPLD? >> The functionality does not have to be greater than the old 8051 CPU, but >> I would like the flexibility and the possibility of adding additional >> logic to my design. >> >> Has someone worked on this issue, or have an opinion on how to complete >> this task? >> >> Looking forward to your replies >> Best Regards > > The Xilinx PicoBlaze or the open-source Mico-8 from Lattice should both be > achievable in a CPLD but most CPLDs don't have memory. > > While it's more of a simple FPGA than an ASIC, the Altera Max-II series of > "CPLDs" has some user Flash memory available on-chip. Most CPLDs will > require external memory. > > - John_H Thank you both for your very useful replies. I can see the benefits in utilizing the Max-II series, but have they made a soft-core processor usable for these CPLD's? Like the PicoBlaze? Best RegardsArticle: 127761
On Jan 5, 9:56 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > On Jan 5, 7:42 pm, "pdudl...@comcast.net" <pdudl...@comcast.net> > wrote: > > > > > FPGA wrote: > > > On Jan 5, 12:46 pm, "KJ" <kkjenni...@sbcglobal.net> wrote: > > >> "FPGA" <FPGA.unkn...@gmail.com> wrote in message > > > >>news:81b075e5-8ab2-4c8d-abc1-4b65b351b4a2@21g2000hsj.googlegroups.com... > > >> On Jan 4, 3:17 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > > > >>> FPGA wrote: > > >>>> I have 2 inputs > > >>>> x : unsigned > > >>>> bw : integer > > >>>> when x>bw I want to check if x(x'length downto bw) = "1111111......" > > >>>> How do i write this in VHDL since my length of x is unknown > > >>> A vector of unknown length could be > > >>> an entity port or a subprogram parameter. > > >>> These are usually handled using > > >>> the array attributes 'length or 'range. > > >>> and a for loop like this: > > >>> for i in x'range loop > > >>> result := some_function(result, x(i)); > > >>> end loop; > > >>> -- Mike Treseler > > >> I actually want to AND all the bits of the x vector whole length is > > >> unknown. I want to check if all the bits of the vector x are > > >> "1111...." . How would I do it, since the length is unknown. I want to > > >> check is x(x'length-1) AND x(x'length-2) AND x(x'length-3) AND .... > > >> x(0) = '1' -- which checks if all bits of the input are one. > > > >> All_Bits_Equal_1 <= '1' when (x = (x'range => '1')) else '0'; > > > >> KJ- Hide quoted text - > > > >> - Show quoted text - > > > > Thank you very much KJ. > > > Also there is and_reduce() and or_reduce() in misc library.- Hide quoted text - > > > - Show quoted text - > > Thank you so much. The help provided by ppl like you immensely helps > beginners like us. Since X is already unsigned, comparisons with integer are allowed, which means you could do something like: if (not x) = 0 then ... I don't know if and_reduce works on unsigned, so you may have to cast to slv. AndyArticle: 127762
On Jan 7, 8:12=A0am, "Rgr" <rgrwork...@hotmail.com> wrote: > > Thank you both for your very useful replies. > I can see the benefits in utilizing the Max-II series, but have they made = a > soft-core processor usable for these CPLD's? Like the PicoBlaze? > > Best Regards The PicoBlaze is intended for a Xilinx target. The design uses Xilinx primitives that may not map over to an Altera design. The Mico-8 is open source and does not use vendor-specific primitives. CPLDs are typically not well suited for processor instantiation so commonly you'll only see them in FPGAs. It's because the Max-II parts are more like early FPGAs that the fit might be reasonable. Have you considered a tiny FPGA rather than a CPLD? Having embedded RAM can really help out. If you want to access more code than would conveniently fit in the on-board RAM, you can use the same SPI flash that programs the FPGA to store additional user flash that you access through an SPI interface. Perhaps the additional flexibility from an FPGA (versus CPLD) is worth considering. - John_HArticle: 127763
In article <B_KdnWf0IICN1hzanZ2dnUVZ_t6onZ2d@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> John McCaskill wrote:
>
> > While I agree that the MAC ID space is so large that the chance of a
> > collision for a random address is very low, I do not agree with that
> > statement. Buying a range of unique addresses is cheap and easy, and
> > no administrative hassle is involved.
>
> There is a story that in the beginnings of ethernet using random 48 bit
> MAC addresses was considered, but rejected because of the (small)
> probability of two accidentally choosing the same address.
>
> As I understand it, in the current system there have been devices
> produced that accidentally had the same address. As the current system
> involves humans, such as programming ROMs and installing them in cards,
> there is a relatively high probability of accidents.
>
> Choosing a random 46 bit number with the local administration bit
> on and the multicast bit off might not be so bad.
>
We *did* consider using randomly-chosen addresses, but in a 64-bit
address space; the probability of a clash in a 48-bit space was
considered too high. I wrote a paper on the subject back in 1979-80,
which is probably lost to history.
Although properly-implemented random addresses would have worked, we
chose the administered-vendor-space 48-bit scheme of today as being more
"politically palatable"; I am sure we would have been hammered even
worse about letting randomness control network addressing than we were
about letting randomness control the backoff algorithm.
--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX
Send replies to: usenet at richseifert dot com
Article: 127764This one is specially designed for small CPLDs: http://www.opencores.org/projects.cgi/web/mcpu/overview You will need an external memory, however. And note that it is far simpler and more limited than a 8051. -- JecelArticle: 127765
> I would like to hear your opinion on the possibility of implementing a > processor in a CPLD? As an alternative to CPLDs, have you considered Actel's Igloo FPGAs? They're small-to-medium-sized FPGAs with a very low power footprint (and you can use an ARM Cortex M1 processor on it). http://www.actel.com/products/igloo/ K.Article: 127766
Rgr wrote: > I would like to hear your opinion on the possibility of implementing a > processor in a CPLD? > The functionality does not have to be greater than the old 8051 CPU, but I > would like the flexibility and the possibility of adding additional logic to > my design. > > Has someone worked on this issue, or have an opinion on how to complete this > task? If you have at least 65 flip flops and a few hundred gates available on your CPLD you can try: ftp://137.193.64.130/pub/mproz/mproz3_e.pdfArticle: 127767
Rich Seifert wrote: (snip) > We *did* consider using randomly-chosen addresses, but in a 64-bit > address space; the probability of a clash in a 48-bit space was > considered too high. I wrote a paper on the subject back in 1979-80, > which is probably lost to history. Higher than the actual clash rate on the current system? > Although properly-implemented random addresses would have worked, we > chose the administered-vendor-space 48-bit scheme of today as being more > "politically palatable"; I am sure we would have been hammered even > worse about letting randomness control network addressing than we were > about letting randomness control the backoff algorithm. I have heard stories about NICs produced with the same address, most likely in the same batch with a high probability of being installed on the same net. We once had a Sun system that the local computer hardware people sent back to Sun to be fixed. The rule at the time was that one should remove the ROM (or battery backed RAM) before sending it in. In this case, it was reinstalled backwards destroying the stored address. Losing the stored address from battery backed RAM can't be that uncommon. (The battery life tends to be less than the processor life.) Also, I once knew a net with a device with address 00:00:00:00:00:00. As there was only one, it was decided to leave it alone. -- glenArticle: 127768
JD Newcomb wrote:
(I wrote)
>>try:
>>printf("test = 0x%08x\r\n",*(int*)&test);
(snip)
> Glen, this conversion on a single-precision processor like the
> MicroBlaze is emulated to be double-precision, correct? This seems, to
> me, the only way that it can be done on such a processor. But I am not
> 100% sure about that. And floats and ints on the MIcroBlaze are the
> same size (4 bytes). So, the value in memory might be correct, though
> the value printed is not. Yay for unnecessary conversions.
Before ANSI C, K&R C did everything in double precision, except that
it had the ability to store and fetch from single precision (float)
variables. ANSI C added float constants, and the ability to pass
them to non-varargs routines with a prototype in scope. Routines
like printf always get a double. For most people, the extra
overhead wasn't that big.
> Your test proved correct. I've also used a direct read of the memory
> address in a similar way using the xio.h functions, which prints the
> same correct value. Thanks for your help, guys.
-- glen
Article: 127769On Jan 7, 5:50 am, "MJ Pearson" <mjp...@york.ac.uk> wrote: > >> Hi, thanks for the replies, > > >> I thought my PCB might be the problem. I didn't perform any impedance > >> matching or termination. I'm "tapping-off" the signals between the > camera > >> and framegrabber. So i have a straight through connection - camera to > >> framegrabber and then "tap-off" the LVDS data-signals and clock and > send > >> these into the DS90CR288A. This way I can setup and control the camera > >> using the camera software on PC, and just perform data processing on > >> FPGA. > > >Tapping into 7 * 66 MHz = 462 Mbps LVDS lines needs to be done > >carefully > >to avoid signal integrity problems at the receiver. However if your > >LVAL and DVAL signals look correct, you may have lucked out... > > >> I wasn't sure I needed to terminate the lines, as this would be > performed > >> further up the line - at the framegrabber end. The pixel clock from > the > >> camera should be 66MHz (I think), so thought I was on the right lines > with > >> a 16ns period. The chip however is the 85Mhz version. Is this a > maximum? > >> I'm not sure what the clock output of the chip should be - 85Mhz or > >> 66MHz!? > > >Channel-Link receivers have a wide frequency range of about 20 MHz > >minimum to the specified maximum (66 or 85 MHz). 66 MHz should > >work fine. > > >> I can see data on the output of the chip, LVAL and DVAL signals are > >> correct, not sure about the clock. As I say, the output voltage swing > is > >> about 600mV, and looks sinusoidal in shape on the scope - Sorry for > the > >> description! The distance between the chip and the connector is about > >> 10mm. Do i need termination resistors across the differential lines in > my > >> case? > > >You may be OK with the 10mm stubs. Definitely don't terminate them > >if there is already termination at the framegrabber. Also if you > >still get a proper picture at the framegrabber, you probably > >have reasonable signal integrity. With your scope it would be > >hard to look at this... > > >I'm going to guess that the clock is correct, too, but that your > >scope is bandwidth limiting the signal to form the sine wave you > >see. What is the input bandwidth of your scope and probe? Did > >you try to implement a simple T flip-flop in the FPGA to see if > >the clock is getting into the chip OK? > > >Regards, > >Gabor > > Thanks again Gabor.. > > The system does seem to be working ok. I get the correct image at the > frame-grabber end, and all the signals do seem to be correct. The scope > I'm using says 60MHz on it, I guess this the bandwidth - in which I guess > it will struggle to observe the higher frequency signals?? > > I implemented a T-flip flop, and got a decent signal at half the input > frequncy across an LED on the board, so it looks like everything is ok - > probably just my VHDL letting me down! The LVAL, DVAL signals are working > as expected aswell - used the LEDs to observe these. > > Just as an aside - when I increase the precision of the camera's output 8 > bit to 16 bit, the camera sends the data in two "packets". For one LVAL > pulse, the are two DVAL pulses. I think this maybe camera specific, but I > think the data may be being sent low bits (0-7) with the first DVAL pulse, > followed by high bits with the second. My camera is always is in > camera-link BASE mode. I've scoped all the data channels from the chip, > and the higher outputs are not used - apart from RxOut 27. Am I right > thinking that in base mode the data should be re-created as: > > Bit(0) - RxOut 0 > Bit(1) - RxOut 1 > Bit(2) - RxOut 2 > Bit(3) - RxOut 3 > Bit(4) - RxOut 4 > Bit(5) - RxOut 6 > Bit(6) - RxOut 27 > Bit(7) - RxOut 5 > > Just wondered if anyone else had any experience with 16 bit data in base > mode? > > Regards > > Marc. The bit assignments are all in the Camera Link Specification: http://www.alacron.com/downloads/vncl98076xz/CameraLinkSPEC.pdf Most Camera Link cameras use two 8-bit "ports" A & B to output 16-bits on each clock. I'm not familiar with any cameras that use DVAL as a pixel framing signal. Base Camera Link supports up to 24 bits of data per clock. Regards, GaborArticle: 127770
Nico Coesel wrote: (snip) > Yes and no. Like others already pointed out, devices need a serial > number anyway. Not just for administration but also to keep track of > devices. So having a fixed number (MAC address) assigned to unit xyz > generally saves a lot of trouble. As the subject is FPGAs, I believe it isn't hard to change data in a synthesized ROM after the bit file has been generated. That should be pretty convenient for generating the packet. Getting the IP address is a little harder. > Besides, if you are going to generate random MAC addresses you may get > intermittant errors because fixed MAC addresses are expected. Those > kind of errors are the last you want on a network. Not so much network errors as administration problems. It is harder to track down devices with variable MAC addresses. -- glenArticle: 127771
Hi, John Schmitz wrote: > Correct, Linux and Windows only. The workaround is to run the MIG tool on > Linux or Windows and transfer the output files over to the Solaris machine > for integration. > > "Michael Laajanen" <michael_laajanen@yahoo.com> wrote in message > news:5ud26iF1hgf6pU1@mid.individual.net... > >>Hi, >> >>I can't locate MIG in coregen on Solaris 9.2 and ip update 2? >> >>Is it only on Linux and Windows? >> >>/michael > > > Such a pain, I wish Xilinx could port everything to Solaris AMD in the next generation tools since simulation and more is already there only FPGA stuff left (: cheers michaelArticle: 127772
Pavel.Schukin@gmail.com wrote: > Hello. > Would you please to get me some information about how can i realize > UDP transmition with Spartan 3E Starter Kit? Can i use IP supplied > with EDK in conjunction with Microblaze. Can I solve the problem > without using Microblaze? And last questions: what is difference > between AccelDSP and System Generator and can I convert some dsp > floating point algorithm available in C in VHDL block? You can do this a number of ways, but the easiest would be to use a processor based subsystem. Build a system using BSB with MicroBlaze + ethernet. Add lwIP for a TCP/UDP software stack. The right solution would depend on your application ofcourse.Article: 127773
MikeShepherd564@btinternet.com wrote: > > The options seem to be: > > 1) Buy a batch of unique addresses (which isn't cheap and involves > administrative hassle). If you're designing a LAN for an airliner I'm > going to fly on, I'd like you to use this method. > Costs $1,650 for 16,777,216 unique addresses. http://standards.ieee.org/regauth/oui/forms/ -hpaArticle: 127774
Nico Coesel wrote: > > Yes and no. Like others already pointed out, devices need a serial > number anyway. Not just for administration but also to keep track of > devices. So having a fixed number (MAC address) assigned to unit xyz > generally saves a lot of trouble. > > Besides, if you are going to generate random MAC addresses you may get > intermittant errors because fixed MAC addresses are expected. Those > kind of errors are the last you want on a network. > A bigger issue is that randomness is frequently a premium resource in real-life systems. -hpa
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