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
No, Xilinx don't provide mac address. It's your job to either :
- Choose some random ones but then it's your responsability
- Request a range for your company.
And the hard_temac core has no MAC provided either.
Sylvain
henryk.mueller@gmx.de wrote:
> Hi all,
>
> my hardware guys are on vacation but I need to clarify this:
>
> The EDK soft cores like opb_ethernetlite need the MAC address as
> parameter. They do not provide a unique MAC address as default. You can
> imagine, what management effort would be necessary to maintain a unique
> MAC address for every device we deliver.
>
> Is there any MAC address available at the Virtex-4FX12MM that
> - is unique for every board
> - is accessable (read-only) by the PowerPC where our code runs
>
> Maybe the hard_temac core?
>
> Thank you for help on this!
Article: 103351rickman wrote: > Thanks for your suggestion, but I already tried that. In fact, the > software person put in an infinite loop writing "FF" to the device > after all the config data was exhausted, which should have eventually > either caused an error (INIT_B low) or driven the DONE pin high. That > was when I looked at the BUSY pin and found it was going high for much > longer periods than I would expect. can you lower the cclk and monitor the BUSY signal to see if it changes the frequency (pulse width)? that BUSY looks suspicious, not to mention that I would expect for INIT to raise the alarm if the part is missing bytes due to a busy state. I hope you took care of bitgen option for the start clk (to make sure your start clk is cclk not the jtag clk) Next thing to try is to feed the sync word from the bitstream with random data, this should end up as CRC error flagged by INIT, to make sure you are actually triggering the config process (by reading the sync word) and the config state machine is moving, and will tell you that you don't need a byte swap (I mean bit swap inside a byte) Aurash > > > Aurelian Lazarut wrote: > >>just give some extra cclks to make sure that configuration process will >>finish (with dummy words) >>Aurash >> >>rickman wrote: >> >>>I'm having trouble configuring a Spartan 3 in parallel slave mode. The >>>mode pins are set with M0 tied to GND and M1,M2 left pulled up >>>internally to 2.5 volts. I verified these voltages with a meter. >>> >>>I am driving PROG_B low for a few microsecs then high. The DONE and >>>INIT_B signals go low and INIT_B goes high again. I set RDWR_B low and >>>start clocking data in by setting CS_B low and using the WR_N signal >>>from the DSP to clock CCLK on the trailing edge. I have looked at all >>>of these signals with the scope and they look clean and have good >>>timing. But no matter how much data we clock into the Spartan 3, we >>>never see either INIT_B go low or DONE go high. DONE has a 10 kohm >>>pullup resistor to 2.5 volts and a buffer converts this signal to 3.3 >>>volts for the DSP. >>> >>>I do see something odd on the BUSY pin. It goes high for some 800 ns. >>>The data sheet says I don't even have to monitor this pin if I keep the >>>CCLK rate below 50 MHz. We are clocking data into the part at less >>>than 10 MHz. >>> >>>Any idea what could be wrong? >>> > >Article: 103352
Hi Sylvian, that is bad news. Even if we request for an OUI, it means a lot of additional management effort. We can not just copy the same code to every device, but need to patch every single one with it's unique MAC address. That applies to the first copy and to every software update that some service guy has to do later. Basically, every customer who uses the Virtex-4FX12MM and the ethernet interface faces the same problems as we do now. Is there no elegant solution out there? I hoped so much... Another approach would be to use some unique serial number from the board that we could combine with our OUI to form a unique address. Does the PowerPC or FPGA or any other part have a software-readable ID? Henryk, who's desperately trying to avoid managing its own MAC addresses Sylvain Munaut <SomeOne@SomeDomain.com> schrieb: > No, Xilinx don't provide mac address. It's your job to either : > - Choose some random ones but then it's your responsability > - Request a range for your company. > > And the hard_temac core has no MAC provided either. > > Sylvain > > henryk.mueller@gmx.de wrote: > > Hi all, > > > > my hardware guys are on vacation but I need to clarify this: > > > > The EDK soft cores like opb_ethernetlite need the MAC address as > > parameter. They do not provide a unique MAC address as default. You can > > imagine, what management effort would be necessary to maintain a unique > > MAC address for every device we deliver. > > > > Is there any MAC address available at the Virtex-4FX12MM that > > - is unique for every board > > - is accessable (read-only) by the PowerPC where our code runs > > > > Maybe the hard_temac core? > > > > Thank you for help on this!Article: 103353
henryk.mueller@gmx.de schrieb: > Hi Sylvian, > > that is bad news. > > Even if we request for an OUI, it means a lot of additional management > effort. We can not just copy the same code to every device, but need to > patch every single one with it's unique MAC address. That applies to > the first copy and to every software update that some service guy has > to do later. > > Basically, every customer who uses the Virtex-4FX12MM and the ethernet > interface faces the same problems as we do now. Is there no elegant > solution out there? I hoped so much... are you talking about the memec mini module? if so then the only place to store the MAC would be onboard flash I would have assumed Memec gives a MAC with the module ! bad luck for you I guess http://www.hydraxc.com modules as example are all coming with unique MAC the OUI range was specially purchased for this purpose. The MAC there is stored in proteced area of the boot processor and can not be changed - but the user can use its own MAC # if he wants. possible memec doesnt care. some Xilinx boards did have MAC assigne (ML300 at least had) so if you did not get the MAC with the memec MM when purchased then you dont have a valid MAC, meaning to be safe you need to purchase the OUIs and store them in on module flash AnttiArticle: 103354
henryk wrote > Even if we request for an OUI, it means a lot of additional management > effort. We can not just copy the same code to every device, but need to > patch every single one with it's unique MAC address. That applies to > the first copy and to every software update that some service guy has > to do later. AFAIR one of the Dallas 1-wire chips supplies a valid MAC address if you have a spare pin and some glue to add one to your board.Article: 103355
Hi Antti, correct, I'm talking about the Memec Mini-Module. Somehow I find no information at the new avnet memec website. I bet there is a MAC address on the board somewhere. I only need to find it. :o( Is there an Ethernet PHY chip that provides a MAC address? I'm not to deep into such hardware issues. This information is usually provided to me... ;o) Storing our own unique MAC address into the onboard flash would be a pain. We could not just write the same flash image to every device, but need to patch every image before. And software updates could mess everything up. If I state now that there is no MAC address and we need to do all the extra work, but later we find out that we just did not look carefully enough. Then I get ... you know ...problems ;o) Henryk > henryk.mueller@gmx.de schrieb: > > > Hi Sylvian, > > > > that is bad news. > > > > Even if we request for an OUI, it means a lot of additional management > > effort. We can not just copy the same code to every device, but need to > > patch every single one with it's unique MAC address. That applies to > > the first copy and to every software update that some service guy has > > to do later. > > > > Basically, every customer who uses the Virtex-4FX12MM and the ethernet > > interface faces the same problems as we do now. Is there no elegant > > solution out there? I hoped so much... > > are you talking about the memec mini module? > if so then the only place to store the MAC would be onboard flash > > I would have assumed Memec gives a MAC with the module ! > bad luck for you I guess > > http://www.hydraxc.com > > modules as example are all coming with unique MAC the OUI range > was specially purchased for this purpose. The MAC there is stored > in proteced area of the boot processor and can not be changed - > but the user can use its own MAC # if he wants. > > possible memec doesnt care. > some Xilinx boards did have MAC assigne (ML300 at least had) > > so if you did not get the MAC with the memec MM when purchased > then you dont have a valid MAC, meaning to be safe you need to > purchase the OUIs and store them in on module flash > > AnttiArticle: 103356
Hi, Apologies upfront if this is a really basic question, as I am rather new to CPLDs. We have a 0-5V squarewave (approx 1MHz, approx 50% duty) that we wish to use as the clock to a Xilinx CPLD (XC9572XL). We need to select at runtime whether to clock on its rising edge or its falling edge. To achieve this, my current thinking is to run this signal into a spare pin on the Xilinx. A control line into the Xilinx will tell it to either invert the signal or output it unchanged. This inverted/uninverted clock signal will then connect to the Xilinx pin assigned as its clock source. Just wondering, does that sound seinsble, and is there anything I should be wary of doing it this way? As I say, I am new to CPLDs so please don't rule out something you believe to be too obvious to mention, thanks! The only thing I can think of currently is the amount of delay added by the extra routing of the clock, plus increased jitter. However, they should both be within our requirements. Many thanks in advance. --- JimArticle: 103357
Jim, The CPLD you note is a 3.3V part, with a 5V input tolerance. Any outputs will swing from 0 to 3.3V, not 0 to 5V. Other than that, inverting, or not inverting a signal is no problem (selection of a 2:1 mux with the inverted and non-inverted signal as inputs, output driving a pin). The jitter added is on the order of 20-50 ps p-p (a simple 74HC04 inverter adds as much, and the delay will be something that you can get as a report from the design tools). Austin Jim wrote: > Hi, > > Apologies upfront if this is a really basic question, as I am rather new to > CPLDs. > > We have a 0-5V squarewave (approx 1MHz, approx 50% duty) that we wish to use > as the clock to a Xilinx CPLD (XC9572XL). We need to select at runtime > whether to clock on its rising edge or its falling edge. To achieve this, my > current thinking is to run this signal into a spare pin on the Xilinx. A > control line into the Xilinx will tell it to either invert the signal or > output it unchanged. This inverted/uninverted clock signal will then connect > to the Xilinx pin assigned as its clock source. > > Just wondering, does that sound seinsble, and is there anything I should be > wary of doing it this way? As I say, I am new to CPLDs so please don't rule > out something you believe to be too obvious to mention, thanks! The only > thing I can think of currently is the amount of delay added by the extra > routing of the clock, plus increased jitter. However, they should both be > within our requirements. > > Many thanks in advance. > > --- > Jim > > >Article: 103358
I did miss something. He wants an ASIC implementation. Does anyone know how a ROM-based LUT approach would compare to an arithmetic-based approach in terms of area? I suppose one would just need a single transistor per ROM bit plus the associated row / column mux / decoders. Even if it is larger in area, it might be advantageous from a speed / simplicity standpoint.Article: 103359
On 31 May 2006 05:39:42 -0700, "rickman" <spamgoeshere4@yahoo.com> wrote: >I'm having trouble configuring a Spartan 3 in parallel slave mode. The >mode pins are set with M0 tied to GND and M1,M2 left pulled up >internally to 2.5 volts. I verified these voltages with a meter. > >I am driving PROG_B low for a few microsecs then high. The DONE and >INIT_B signals go low and INIT_B goes high again. I set RDWR_B low and >start clocking data in by setting CS_B low and using the WR_N signal >from the DSP to clock CCLK on the trailing edge. I have looked at all >of these signals with the scope and they look clean and have good >timing. But no matter how much data we clock into the Spartan 3, we >never see either INIT_B go low or DONE go high. DONE has a 10 kohm >pullup resistor to 2.5 volts and a buffer converts this signal to 3.3 >volts for the DSP. > >I do see something odd on the BUSY pin. It goes high for some 800 ns. >The data sheet says I don't even have to monitor this pin if I keep the >CCLK rate below 50 MHz. We are clocking data into the part at less >than 10 MHz. > >Any idea what could be wrong? We use this mode and it works fine. At the risk of asking a stupid question (please don't take it the wrong way) did you remember that the confriguration data port signal names use IBM nomenclature? In other words, D0 is the most signficant bit... ================================ Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.comArticle: 103360
Mr. Ken schrieb: > My task is to scale up a 9-bit data by 17/sqrt(21) (= 3.7097), with the > best precision possible. Without considering clipping and range issues, I > am using multiplication by 59/16, which gives 0.599% error. What better > approach can I use? > > I am going to implement the calculation in ASIC, thus less complexity is > what I am expecting. Note that a division or multiplication by a power of 2 is free in hardware. Also note, that multiplication by a constant is a lot cheaper and faster than general multiplication. Lets see: (X*59)/16 = (X*64 - X*4-X)/16 So X*59/16 uses only two adders. (X*119)/32 = (X*128-X*8-X)/32 Two adders, even more precision. Y= X*4 + X*32 (X*15195)/4096 = X*16*1024 - Y*32 - Y Three adders. Very high precision: I doubt you can beat this with any other approach. Kolja SulimmaArticle: 103361
Article: 103362
"Stephen Craven" <nevarcs@gmail.com> wrote in message news:1149085783.691057.115890@c74g2000cwc.googlegroups.com... >I may be missing something - I didn't read all 60 posts by John, but <snip> My apologies, folks. I'll try to reinstall my newsreader software at home in an attempt to avoid the posting flood. I just hope it's not the ISP that's giving me the problem. LUTs might be the bast answer!Article: 103363
"Tim" <tim@rockylogiccom.noooospam.com> schrieb im Newsbeitrag news:e5kfam$2hg$1$8300dec7@news.demon.co.uk... > > henryk wrote > >> Even if we request for an OUI, it means a lot of additional management >> effort. We can not just copy the same code to every device, but need to >> patch every single one with it's unique MAC address. That applies to >> the first copy and to every software update that some service guy has >> to do later. > > AFAIR one of the Dallas 1-wire chips supplies a valid MAC address if you > have a spare pin and some glue to add one to your board. > if you refer to onewire unique ID then this is not valid MAC address you can use onewire memory to store a valid MAC but you must then yourself obtain the MAC and write it to memory location AnttiArticle: 103364
Antti wrote > "Tim" schrieb >> >> AFAIR one of the Dallas 1-wire chips supplies a valid MAC address if you >> have a spare pin and some glue to add one to your board. >> > if you refer to onewire unique ID then this is not valid MAC address > > you can use onewire memory to store a valid MAC but you must > then yourself obtain the MAC and write it to memory location I'm not an expert, but Maxim/Dallas advertise the DS2502-E48 as providing a unique and valid MAC address. I suppose they could be wrong.Article: 103365
CMOS wrote: > is there a standard way to combine state machines There have been a couple of occasions when I have used nested case statements, but it gets messy real fast. RonArticle: 103366
Good timing indeed on this post. Our group is using Subversion. What I am hoping to do is to incorporate the Subversion-stored revision number into the actual design (working on an FPGA). I would love to grab the design's Rev. #, store it as a constant in some register map, which is readable by another system (i.e. seamless, automatic firmware version control). The way I've thought of doing this is writing some C program which finds the Subversion revision number through command line + some parsing, and then outputs a properly formated VHDL file which maps my rev # to a memory address. That should be a piece of cake, but what I can't figure out is how to get Quartus to execute my C program pre-compilation. I'm thinking I could do it if I cast away my GUI and start using TCL/command like compilation. All that would probably work, but would take a bit of a learning curve (time our project can't afford) and there seams like there should be a better way. Anyone have any suggestions? Regards, Kevin Markus Kuhn wrote: > "Derek Simmons" <dereks314@gmail.com> writes: > |> Is there a recommended source control system? > > Subversion is one of the most popular ones today. > > It has become the de-facto successor of CVS, because it is very > easy to understand for people used to CVS and fixes most of > CVS's problems. In particular, in contrast to CVS, Subversion > understands about renaming and copying files and subdirectories, > and using this, it provides a far more elegant and flexible > alternative to the branching and tagging mess of CVS. Subversion > also has much better support for remote access than CVS. > > Definitely worth a try! > > The manual is at http://svnbook.red-bean.com/ > > A very good and mature tool for converting an existing CVS > repository into Subversion is cvs2svn at http://cvs2svn.tigris.org/ > > Subversion, like CVS, is a set of command-line tools. > If you want a Microsoft Windows GUI client for Subversion > that integrates fully with Windows Explorer, try > TortoiseSVN at http://tortoisesvn.tigris.org/. > > A comparison of source control systems is at > > http://better-scm.berlios.de/comparison/comparison.html > > MarkusArticle: 103367
I was going through my bookmark files(maintained since 6-7 years ago) and found that most of the sites that I used to frequent during my student life have either disappeared completely or my bookmarked urls are missing and the page have moved on to a new location. e.g. optimagic.com, tclforeda.net, rassp There are around 175 broken links in my bookmark files mostly links to tutorials,tools and language related pages. I wanted to know 1> How many of the reference sites of the 90's are still around. If any have moved where are they now? 2> Of the lost sites what sites do you miss today? --AjayArticle: 103368
Tim schrieb: > Antti wrote > > "Tim" schrieb > >> > >> AFAIR one of the Dallas 1-wire chips supplies a valid MAC address if you > >> have a spare pin and some glue to add one to your board. > >> > > if you refer to onewire unique ID then this is not valid MAC address > > > > you can use onewire memory to store a valid MAC but you must > > then yourself obtain the MAC and write it to memory location > > I'm not an expert, but Maxim/Dallas advertise the DS2502-E48 as providing a > unique and valid MAC address. I suppose they could be wrong. sorry, i did not pay attention to "one" dallas chip in your posting, you are right the exactly part type you mentioned is that one chip that has the MAC id in the user eeprom area (what is write protected) Sorry, i should have read your posting more carefully I assumed you referred to the 1-wire serial code AnttiArticle: 103369
Simple question, but complicated answer. A BlockRAM uses as much silicon as 15 to 20 CLBs (roughly, depends on the family). But it depends whether your chip has "spare" BRAMs, in which case they are "free". Or if you have barely enough, then any extra BRAM would be extremely expensive. I am a big fan of following your suggestion, and avoid the real-time arithmetic. Just store the conversion table in a BRAM... Peter Alfke, Xilinx ========================================== Stephen Craven wrote: > I did miss something. He wants an ASIC implementation. > > Does anyone know how a ROM-based LUT approach would compare to an > arithmetic-based approach in terms of area? I suppose one would just > need a single transistor per ROM bit plus the associated row / column > mux / decoders. > > Even if it is larger in area, it might be advantageous from a speed / > simplicity standpoint.Article: 103370
kevinwolfe@gmail.com wrote:
> Our group is using Subversion. What
> I am hoping to do is to incorporate the Subversion-stored revision
> number into the actual design (working on an FPGA). I would love to
> grab the design's Rev. #, store it as a constant in some register map,
> which is readable by another system (i.e. seamless, automatic firmware
> version control).
Maybe subversion fills in revision headers like CVS.
Have a tcl or bash script grab
the revision header line, say
-- $Revision: 1.42 $
and convert it to a vhdl package file
with a vector constant, say
constant revision_c : byte_t := x"8e";
that becomes readback data.
-- Mike Treseler
Article: 103371hi all. i'm trying to set up a tcl/tk script to control my synthesis and implementation (synplify pro / xilinx ise 6.3). does anyone have any example code, tips, or pointers to any resources? thanks in advance. edArticle: 103372
I really wish I could use SystemVerilog to develop RTL in ISE. Do any of the Xilinx folks around know if there there are any plans for this? I've been using SV for some time now and like it much more than either VHDL or plain old Verilog. If there was a beta tester program I would love to use it and file bug reports. -LukeArticle: 103373
So I just noticed I wrote "SystemVeriling"...of course I meant SystemVerilog. ;) Luke wrote: > I really wish I could use SystemVerilog to develop RTL in ISE. Do any > of the Xilinx folks around know if there there are any plans for this? > I've been using SV for some time now and like it much more than either > VHDL or plain old Verilog. If there was a beta tester program I would > love to use it and file bug reports. > > -LukeArticle: 103374
I've been having a really hard time coming up with a design for a
robust clockless arbiter in an FPGA, and was wondering if anybody here
can provide input. By robust, I mean that it works correctly with
probability=1 and its output never glitches, but may take an unbounded
amount of time to resolve.
Charles Seitz describes a solution in custom VLSI on page 260 of Mead
and Conway's _Introduction to VLSI Systems_, but this assumes you have
control over gate threshholds and can make some of them substantially
higher than others.
The basic component that causes problems is the "interlock", a module
with two inputs A,B and two outputs X,Y.
+---------------+
A -----> | | -----> X
| Interlock |
B -----> | | -----> Y
+---------------+
All signals start low. If A+ (A rises) before B+, then X+. If B+
before A+, then Y+. Once one of the outputs rises, the other one will
not rise until the device is reset (assume some sort of reset signal).
The important part here is that the interlock can take as long as it
likes to raise one of the outputs, but it must raise exactly one of
them, and cannot lower it once raised (ie no glitching).
I'm working with Atmel FPGAs, but advice based on other devices would
be just as helpful. I thought of using the "internal feedback line"
to feed one of the 3-LUT's outputs back into one of its inputs as half
of an interlock -- the state of the feedback line being used to
determine if signal A+ has already arrived. But the problem is that
you might have A+ arrive, which causes the output of the 3-LUT to
transition, but then B+ might arrive *before* the LUT's output
transition arrives back at the third input to the LUT.
Any pointers? I've come across a rather depressing paper concluding
that this isn't possible on the (extremely old) XC4000, but I'm sort
of hoping against hope that things may have changed:
http://www.iccd-conference.org/proceedings/1998/90990360.pdf
This paper claims to have a solution, but doesn't go into detail, so I
suspect that they may be overlooking something.
http://citeseer.ist.psu.edu/maheswaran94hazardfree.html
Thanks for any pointers...
- a
--
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380
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